Boot like a boss: Why iPXE Anywhere Web Service is the PXE game-changer you never knew you wanted

PXE has a bad rap. For many, it’s an old school BIOS feature that sometimes loads WinPE over a slow TFTP transfer… if you’re lucky.

But here’s the thing, PXE isn’t the problem. The way you use it is.

You probably already know that we love the open-source software iPXE and have been a contributor to that community for many years. We have also extended this and added our own products called iPXE Anywhere 2PXE Server and iPXE Anywhere WebService. We also have our solution working with Secure Boot since the binaries in iPXE Anywhere are signed by Microsoft . What’s so great about iPXE vs regular PXE? Well, we only download 500KB over TFTP, the boot image is then downloaded over https. Making it possible to PXE-boot over internet, it is blazing fast, and supports P2P!

And just like that....this is me now:

Do you want even more intelligence? Enter iPXE Anywhere Web Service (iPXE WS). A lightweight service that transforms 2PXE booting to an intelligent, dynamic solution. It turns your 2PXE environment into a programmable decision engine.

This is PXE with brains.

First thing first: “PXE? Seriously? This isn’t 2009. We’re cloud-native now!”

Yeah, yeah. We’ve heard it all before: “PXE and OSD is dead. Intune is king. We’re using Autopilot and don’t need to care about imaging no more.” But here’s the inconvenient truth:

Your machine isn’t born in the cloud. Autopilot is great - once the device has an OS and is connected to the internet. But for bare metal installs, PXE is still king. There’s no cloud magic when you're staring at a blank SSD.

• Got hit by ransomware? Just initiate a wipe from Intune, right?
  Well, do you really trust any of the files required for a wipe (sitting locally on the drive) in your current situation? You shouldn’t. 2PXE gives you an easy path to a clean, controlled, automated reimage of the device.
• “I already have the bare-metal scenario covered with this super sweet community tool.”
  Awesome, means that you’ve thought of it!
  But let’s be real: most community (and even Microsoft’s own) tools rely on USB sticks. Sure, that works for a few machines… but try scaling that to thousands. That’s a whole lot of USBs, and a whole lot of wasted hours. It’s perfectly fine to boot to your favorite community tool from 2PXE instead, or even better, check out DeployR! 😉
• “I’m fine with using the image shipped by the OEM”
  Sure, you could boot into the bloatware-laced, outdated OEM image that was shipped with the device... if you enjoy outdated drivers, and seven trial antivirus apps. Most orgs want a vanilla image. 2PXE lets you own the complete process.
• “I’m way ahead of you; I deliver my custom WIM to my OEM/partner.”
  Awesome! Then you have a perfect starting point when ordering new devices. Since you already maintain your WIM, it totally makes sense to also host it in your environment to cover break/fixes, and again – ransomware.
• "I get your point, but most of my users are remote now. PXE/TFTP won’t work over the internet, and I have no control over DHCP settings or IP helpers in home networks"
  That's one of the reasons why 2PXE is so good! We only transfer ~500KB over TFTP, then https takes over. This means you actually can PXE-boot over the internet. Doesn't help much if the devices don't know the boot server host name though. To support the rebuild-from-home-scenario you have two options:
  • Use our tool to generate a bootable USB-stick containing ONLY the necessary boot files and the URL to your 2PXE-server. Meaning there's no requirement to keep the USBs updated, these files are pretty much static
  • Instead of PXE boot, do http(s) boot (also known as UEFI boot). Most modern devices supports booting over https. This allows you to inject (scripted approach) the URL to your 2PXE-server to the BIOS/UEFI. Instead of hitting F12 when booting, hit F11! Simple!

Network booting isn’t legacy, it’s your safety net when everything else fails. Fast, repeatable, and fully automated. It just works.

Ok, hope I got your attention by now

What the Web Service actually does

At its core, the iPXE Anywhere Web Service is a smart little service that runs on a server (no IIS required) and listens for boot requests from clients coming from 2PXE.

But unlike your traditional TFTP/boot image combo, this one actually knows things:

• What device is booting - MAC, serial, model, Secure Boot status, and more
• What logic to run - it can call PowerShell, query SQL, hit asset management systems or whatever you can think of
• What to return - dynamic iPXE menus, error messages, BitLocker keys, what to boot to, or just "nope, denied"
• Authenticate the user – Require end-user authentication before giving access to the boot menu(s). And yes, that includes MFA.
• The service runs on your server, meaning a full Windows OS. This opens up a world of possibilities and ease of operation when trying to integrate with external services, compared to doing the same in WinPE.

It’s PXE meets conditional access. And it changes everything.

Real-World Use Case #1: Talk to your asset management system before you boot

Just because a device PXE-boots doesn’t mean it should.

With iPXE WS in place, we can collect the serial number and/or MAC of the booting device. Your backend script then queries your asset management system to check if it’s a known device and if it’s approved for deployment.

If it’s not? Return a “denied” response. Show a message in iPXE that says “You are not welcome here. Talk to IT” Done.

If it is? Proceed with the correct deployment menu or Task Sequence based on model, department, site, or anything else that makes sense for you.

Example:

if ($AssetSystem -notcontains $SerialNumber) {

$menu = @"

#!ipxe

prompt --timeout 300000 You are not welcome here. Talk to IT

"@

return $menu

}

else {

return $NiceBootMenu

}

All of this, without static configurations, or any other manual boring process.

Real-World Use Case #2: BitLocker Recovery Mode = Magic

Let’s talk about real damage control.

During the 2024 CrowdStrike incident, millions of machines bluescreened, but their hard drives and data were intact. Many organizations simply decided to completely rebuild their machines. Time consuming for both IT and the end user.

Before there was an official fix in place, the temp-fix (or workaround) was to manually delete a single file from the local drive, but since our hard drives are now encrypted, and the OS sitting on the hard drive keeps blue screening, booting to another OS (like WinPE or WinRE) required a BitLocker key to access the drive. Sure, you can type it in manually but who wants to do that, and how well does that scale?

What if you could PXE-boot into PE and unlock those drives automatically?

With 2PXE and iPXE WS, you can!

1. Get the serial number of the device at boot (or whatever you can use to match with the computer object in AD or Entra)
2. Query Active Directory (or Entra ID) for the BitLocker recovery key
3. Inject the recovery key to PE, live during boot.
4. Boot to PE, use the key to unlock the drive
5. Delete the file that caused the issue
6. Reboot, go on with your life

No 48-character user input. No USB drives. No manual process

You look like a hero. Your helpdesk breathes easier.

Want an example? This device has a local file (badfile.txt) that we want to get rid of because (we pretend that) it causes a BSOD on the device, and because of that we can’t remediate the issue locally. BitLocker is enabled, making access to the partition outside of the installed OS difficult.

We have a super simple Task Sequence, with an even simpler PowerShell script,

When the device boots via 2PXE, iPXE WS matches the device serial number to a device in the onprem Active Directory, collects the BitLocker Recovery Key, and injects that to WinPE on the fly. 0 manual intervention.

See the process client side here:

We could automate it even further by removing the requirement to authenticate and auto select the Task sequence in question.

So with that we have cut the recover-from-Crowdstrike-process down to ~2 minutes instead of whatever your regular OSD-process takes.

Real-World Use Case #3: Remote user’s SSD fails, support is days away, productivity grinds to a halt.

Who’s been here?
You’ve gone fully cloud, enabling users to work 100% remotely, even from places where you have zero IT presence. Then the SSD fails. Getting replacement hardware to the user will take days, maybe weeks.

But what if you could boot that user into a temporary live OS and have them connect to Windows 365 or Azure Virtual Desktop while they wait for a tech to knock on their door? Sounds too good to be true, right?

It’s not.
It’s actually quite easy with iPXE WS.

1. Create a custom Linux build locked down to kiosk mode with just a browser, pointing to https://windows365.microsoft.com (or whatever fits your environment).
2. Create a custom menu object with the help of iPXE WS to download and boot your Linux kiosk image
3. Have the user log in with their Entra credentials, and they’re back to work!

“But we don’t run Windows 365 or AVD, and it’s too expensive to keep it running just for this.”

No problem. Configure your AVDs to automatically shut down when idle and boot up when someone logs in. From the iPXE WS side, there’s no extra licensing for this feature. Suddenly, you got a super low-cost solution that enables your users to stay productive in the case of hardware failures. Cool!

"Ok, this actually does sound like something I could use. How can I achieve all this?"

Well, you have two options:

1. Create your own menus and customizations with the help of iPXE WS. iPXE-scripts can be a beast to learn, but since the iPXE WS uses PowerShell scripts to help you generate the iPXE menus, we make it much easier for you.
2. Extend with our full 2Pint "OS Deployment Suite" that also includes "RecoveR". With RecoveR we work together with you to customize your environment to suit your specific requirements. We combine our previous experience with different types of recovery scenarios, best practices and knowledge of iPXE-scripting with your expertise in your environment. As a bonus, you also get DeployR as part of the suite for bare metal provisioning! Which is perfect if you're already cloud native, and want to finally get rid of ConfigMgr and/or MDT.

Please contact us if we have sparked your interest!

* With everything discussed above, always consider your design and architecture when exposing components to the internet that interact with backend systems