And using it to bypass Win11 installation checks · November 6th, 2021
This is a short one, and a weird one, obviously my blog is not in any way shape or form geared towards Windows, or anything Microsoft for that matter. Maybe I've mentioned that I've rebuilt my old Zune by hand a while back, maybe not. But that doesn't mean I don't manage a significant share of Windows desktops and servers day to day. Due to that fact, like many other admins, I find myself tinkering with Windows 11, you know, the one that came after the "last version of Windows" Microsoft will ever make.
Anyways, Windows 11 has requirements, we're all aware of them; TPM2.0, 8th gen CPU, 4GB RAM, 64GB of HDD. Nothing alarming, but I happen to have a lot of older hardware lying around that I use for testing, and there are perfectly serviceable systems with 6th and 7th gen CPUs in them that meet all of the other requirements. That's a minor inconvenience, but here's why you're even seeing this post in the first place.
Specifically I've been testing Windows 11 on a Surfacebook, it's retired hardware at the office, but it has great specs for a test machine. It's got a solid i5-6600u CPU, 8gb of RAM, a 128GB SSD, rock solid. It has been my Win10 PXE imagine testing system for about a year now. Hell I even walked it through the manual upgrade process to Win11 and it just worked. Windows 11 ram buttery smooth on it, all the weird Surface components worked just fine, and I got to play around with the new UI which let me get a grip on the new layout before I deploy things. To my chagrin when I setup a image on my iPXE server I was greeted with this lovely little message telling me an utter load of nonsense.
(Yes I know this isn't a picture of the surfacebook, I can't find the actual screenshot, but you get the picture, it's roughly the same thing.)
Fine, the Surfacebook doesn't meet the specs, it's listed as an unsupported device on Microsoft's website too. I get it, BUT it is literally already running Windows 11, so what exactly prevents me from installing it when it's already running it?! It's worth noting that lots of people are running into that and one of the less technical suggestions is to in-fact upgrade from a Win10 install via the insider program, so I guess I had accidentally worked around the problem, but I just want to PXE auto install Windows 11. I'm not going to image, patch, upgrade, etc for every single laptop, that would be ridiculous.
Fortunately if you're loading Windows using wimboot there's a pretty quick fix to disable all of those arbitrary checks inside of your PXE boot environment and happily get on with your day.
The process is fairly simple, in summary you just need to modify the registry of the boot.wim file you use to initialize your PXE install with the new LabConfig keys. That will give you a persistent bypass for your PXE server. I assume you've already gone through the process of copying the wim files using the Windows 11 ADK. Microsoft has solid documentation on using the ADK to generate this stuff, you can find that here.
Mount the boot.wim: dism /mount-wim /wimfile:C:\PXE\media\sources\boot.wim /index:1 /mountdir:C:\PXE\mount Load the system registry of the wim file: reg load HKLM\WR c:\PXE\mount\windows\system32\config\system Add the LabConfig Hive: reg add HKLM\WR\Setup\LabConfig Bypass TPM Check: reg add HKLM\WR\Setup\LabConfig /v BypassTPMCheck /t REG_DWORD /d 1 Bypass Secure Boot Check: reg add HKLM\WR\Setup\LabConfig /v BypassSecureBootCheck /t REG_DWORD /d 1 Bypass RAM Check: reg add HKLM\WR\Setup\LabConfig /v BypassRAMCheck /t REG_DWORD /d 1 Bypass CPU Check, and allow upgrades with bypassed checks: reg add HKLM\WR\Setup\MoSetup /v AllowUpgradesWithUnsupportedTPMorCPU /t REG_DWORD /d 1 Unload the wim registry hive: reg unload HKLM\WR Commit changes to the image: dism /unmount-wim /mountdir:C:\PXE\mount /commit
Once you've commited your changes to the boot.wim file copy it over to your PXE server and drop it into the directory you're using to bootstrap Windows 11 from. It's just a drop in replacement for your boot.wim, so I assume if you're using WDS then this would work fine as well. In the end you'll need your directory to look something like this. You should pull the BCD and boot.sdi files from the ISO you're using in your installation. install.bat and winpeshl.ini aren't necessary, they're just an auto install script and launcher of said script.
├── boot │ ├── bcd │ ├── boot.sdi │ └── boot.wim ├── install.bat └── winpeshl.ini 1 directory, 5 files
If there's interest I'll do a longer post on linux PXE servers, they're honestly one of those things that every sysadmin should have notes on somewhere to same themselves time and effort. Even if you're just homelabbing this can save you immense amounts of time getting new hardware into a production ready state.
"Very little indeed is needed to live a happy life." - Aurelius
- Modifying boot.wim
- Alpine Workstations
- The Old Computer Challenge
- Thinking Like a SysAdmin
- Very Little Indeed
- This Distro is Not For You
- Low Spec Computers
- MikroTik Maplite Magic
- Lisp, Make, & Esper
- Building Blocks
- Decentralized Collaboration
- Mobile Workflow: Part 2
- Striving Towards Happiness
- Building an Alpine NAS
- Did I Make Enough Static?
- Macros in Fennel
- Emulating aarch64
- Fennel Confusion
- toAPK -v template
- Mobile Workflow
- Tying up loose ends
- toAPK chez-scheme
- OpenRC & Open Source
- My Docker Workflow
- Over-Engineering a Blog: Part 2
- Over-Engineering a Blog: Part 1
- About Lambda Create