As I stated previously, bypassing the Windows 11 hardware requirements can be done, but that doesn’t mean it’s a good idea. And I stand by that. But based on a couple of Twitter threads, there’s some debate over the effectiveness of the LabConfig settings in bypassing those requirements. So, for clarity, let’s try them out one by one to answer the question once and for all.

First, I’m using the Windows 11 Business Editions ISO from https://my.visualstudio.com, updated with the July Patch Tuesday cumulative update. I am pairing that with a VM that purposely doesn’t meet the Windows 11 requirements:

• 2GB RAM
• 50GB hard drive
• One virtual CPU
• SecureBoot turned off (UEFI VM)
• No TPM

Normally on a machine like that I wouldn’t try to install Windows using SETUP.EXE (well, normally I wouldn’t use SETUP.EXE at all, just apply the WIM directly using DISM or PowerShell), but since that’s what is validating the hardware requirements I’ll do it.

So, for the simplest test, I can attempt to run the install with no tweaks, to see it fail:

And checking the log confirms that it doesn’t like the available RAM:

OK, so we should be able to bypass that check with the creation of a registry key in the Windows PE registry, specifying BypassRAMCheck=1:

Checking the logs again, we can see that the BypassRAMCheck setting was respected, so the insufficient RAM was ignored and we then failed on the number of cores:

So, success #1, setting works fine as long as it’s in the Windows PE registry prior to that point in the process. (Notice the typo in the error message.). Now, let’s see if we can bypass the CPU cores requirement using the BypassCPUCheck setting:

No such luck on that one, as the same error is reported even with the BypassCPUCheck=1 setting in place. I’ll temporarily work around that one by adding another core to the VM to see if we can get to the next problem. Sure enough:

This result is somewhat interesting though: It reports that my machine is capable of SecureBoot, even though SecureBoot is disabled. That makes sense since this is a UEFI system (gen 2 VM), so to check this one I’ll need to use a non-UEFI system (gen 1` VM) — we’ll come back to that one. But we also see that the TPM check failed as my VM doesn’t have a TPM. So let’s try to bypass that check:

And now I get to the EULA page, so all the checks passed:

The logs confirm that the BypassTPMCheck=1 setting worked fine:

But wait, what about the 64GB disk space requirement? Apparently SETUP doesn’t even try to verify that one — as long as the image you’ve chosen will fit (with a bit of a fudge factor in the calculation) it will allow it, so my 50GB volume is just fine.

Alright, back to the SecureBoot check with a gen 1 (BIOS) VM (same RAM, CPU cores, disk space), setting these bypasses:

That reported the same error with the number of CPU cores, so let’s try again with a second core added. And with that, we pass:

So let’s summarize. If you set these HKLM\System\Setup\LabConfig registry values, you can bypass some of the hardware checks:

• BypassRAMCheck = 1. This works fine to enable SETUP.EXE to install Windows 11 on a machine with less than 4GB (well, really 3686MB) of RAM.
• BypassTPMCheck = 1. This works fine to enable SETUP.EXE to install Windows 11 on a machine that doesn’t support TPM 2.0.
• BypassSecureBootCheck = 1. This one is really somewhat misnamed as it doesn’t really do anything on UEFI systems. It does allow SETUP.EXE to install Windows 11 on BIOS-based machines that can’t possibly support SecureBoot (since that’s a UEFI feature).

But the two other settings, BypassCPUCheck and BypassStorageCheck, don’t appear to exist. If we take that premise a bit further and search all of the Setup binaries for the “LabConfig” registry key and “Bypass” values, using strings.exe to parse the binaries looking for that text, you can see that only the previous three settings actually exist:

So, there’s no simple way to bypass the CPU check (and you really do want at least two cores anyway as Windows in general is awful on a single-core device/VM), and as I mentioned previously, no real reason to bypass the storage check as it doesn’t appear to be enforced anyway.

Of course the easy way to bypass all of these checks is to just bypass SETUP.EXE, as I already mentioned. Long live DISM or your deployment tool of choice (MDT, SCCM, Tanium Provision, etc.), none of which use SETUP.EXE to do a bare metal install.