PXE Boot Failure: “Access Denied or Aborted” with Secure Boot on [Part 4]

In this article, we discuss “PXE Boot Failure: “Access Denied or Aborted” with Secure Boot on”. This guide will help you eventually when Microsoft releases a newer version of ADK. Please see Fix Operating System Loader failed signature verification” on Dell Safe BIOS Systems via PXE [Part 3], and how to protect Microsoft 365 beyond native limits with VDC [Part 1]. This issue occurs when you attempt to PXE boot a Generation 2 VM with secure boot enabled on XCP-ng or similar TianoCore-based hypervisors.

Note: This process is only a temporary workaround and does not resolve the underlying issue, because MDT and WDS always regenerate WinPE from the ADK baseline; as a result, even after updating the ADK with the latest November 2025 servicing updates. MDT/WDS continue reapplying the older WinPE boot binaries during LiteTouch image generation and deployment, overwriting any manually updated Secure‑Boot‑compatible files in both the WinPE media path and the WDS RemoteInstall directory. This behavior is by design and means that changes to WDS or WinPE binaries are never persistent, so the only real fix must come from Microsoft through an updated ADK servicing release that includes corrected WinPE binaries.

The error below appears where the boot process fails immediately after the Network Bootstrap Program (NBP) has been successfully downloaded. The firmware displays the error as shown below. For other errors not discussed here, please see the “Advanced troubleshooting for PXE boot issues in Configuration Manager“.

Note: This occurs is present if the PXE infrastructure (WDS/MDT) is correctly serving files with Secure Boot enabled. And currently does not affect physical device or VM using the same network path as shown below that do not have the SAFE BIOS update (Secure Boot On) applied/enabled. Here is a similar error as it relates to Proxmox VE.

As you can see, the Windows Boot Manager is successfully loading the WinPE deployment image. That is (.wim file) into the virtual machine’s memory when Secure Boot is disabled. This is not the desired result as we do not want secure boot disabled.

Please see An error has occurred in the script on this page: HTA applications report a Script error after upgrading to ADK for Windows 11, version 22H2. Here is how to bypass unsupported CPU and Processor by upgrading to Windows 11 via Windows Update.

What is PXE Boot?

Before attempting to fix this issue, I will like to discuss how Preboot execution Environment (PXE) works. PXE Boot is a network boot technology that allows a devices to start an operating system from a network server instead of a local hard drive or removable media.

Note: PXE Boot simplifies large-scale operating system deployments by eliminating the need for physical installation media while enabling centralized and automated provisioning across enterprise networks.

As System/Network Administrators, we utilize PXE Boot to deploy operating systems, automate imaging tasks, and provision devices remotely. PXE Boot relies on several network services working together, including DHCP, TFTP, and a Network Boot Program (NBP).

When a client device powers on with network boot enabled in UEFI or BIOS. It broadcasts a DHCP request to locate a PXE-enabled deployment server. The DHCP server responds with an IP address and additional boot parameters, including:

• Option 66 – Specifies the TFTP server address
• Option 67 – Specifies the boot file name

Please see WDS and DHCP Deployment Scenarios: Configure DHCP Options 60, 66, and 67. Here is how to migrate WDS and MDT to a new Windows Server, and Comprehensive Guide to Install DHCP Server on Windows Server.

Using this information, the client connects to the TFTP server and downloads the required boot loader or NBP into memory. The system then executes the downloaded boot file, which initiates or launches a Windows PE environment (OS deployment). PXE deployments utilizes these terminologies below as it applies to my usecase:

• Windows Deployment Services (WDS)
• Microsoft Deployment Toolkit (MDT)
• WinPE
• UEFI Secure Boot
• Network Boot Programs like wdsmgfw.efi and bootmgfw.efi

How PXE Boot Works?

To recap, the PXE boot process follows a structured sequence between the client device, DHCP server, and deployment server.

• Step 1. PXE Initialization: The client system powers on and starts the PXE code stored in its BIOS or UEFI firmware.

• Step 2. DHCP Discovery: The client broadcasts a DHCPDISCOVER request to locate a DHCP or PXE deployment server on the network.

• Step 3. DHCP Response: The DHCP server assigns an IP address and provides PXE boot parameters such as the TFTP server location and boot file name.

• Step 4. TFTP Communication: The client connects to the TFTP server and requests the specified boot file.

• Step 5. Boot File Download: The deployment server transfers the Network Boot Program (NBP) or EFI boot loader to the client system.

• Step 6: Operating System Deployment: The client executes the downloaded boot loader. This then loads WinPE, an operating system installer, and deployment task sequence environment.

Please see Fix the request to add or remove features failed 0x00400d. Also, see [AZURE] Procedure for creating an MSSQL Always On Cluster on Azure, and how to Create a Windows 10 or 11 bootable USB with UEFI support

Part A: Reason UEFI PXE Boot Stops with Access Denied

While wdsmgfw.efi is the “first responder (PXE Network Bootstrap Loader)” that handles the PXE handshake. Then downloads the BCD, boot.wim and hands off to bootmgfw.efi. It is the Windows Boot Manager (bootmgfw.efi) that does the heavy lifting of actually loading the .wim file.

The PXE loader has the updated binaries copied from the WinPE file path. You cpould also copy this from the RemoteInstall path in System 32 folder as you wish. As such there is no access issue.

Note: But the Boot Manager in this regard is not the old, revoked version (CA 2011). But manually copied from the local EFI partition. This breaks the chain the moment the system tries to transition from “downloading” to “loading files due to permission issues.

Please see A-Z of XCP-ng and Xen Orchestra setup and VM Creation, How to deploy images to computers using PXE Boot, and How to Install and Upgrade Docker Engine From Binaries.

Apply Windows ADK Patch

Note: [I attempted to apply the new update to the version of Windows ADK and WinPE (ADK)]. And injecting the SafeOS patches as documeneted here ” steps to customize Windows PE boot images.” Yet, the ADk and WinPE sources still did not contain the corrected secure boot compatible binaries. This emans, the servicing update did not correctly replace the the underlying WinPE boot chain inside the ADK installation path. As a result, the MDT regenerated LiteTouchPE, and WDS extracted PXE Loaders. Both systems continued to reapply the older binaries from the ADK Baseline. Thereby causing the secure boot chain to fail during the winload/winpe stage. This means, the ADK serving package is outdated. And no amount of manual patching can persist. This is because MDT/WDS always rebuilds WinPE from source ADK source.

Note: Before proceeding with the troubleshooting and binaries update with the latest CA 2023. Ensure you have the latest Windows Assessment and Deployment Kit (ADK) is installed. This includes having the latest Deployment Tools and Windows Preinstallation Environment (WinPE) add-ons. This update can be downloaded from here. Refer to the sign post.

Please see how to download and install the Windows ADK Patches. Also see Windows PE working for Windows 11 and Windows Server 2022, and how to uninstall and upgrade ADK, WinPE, and MDT.

Please see Creating a WinPE USB Drive: Fixing System Boot Issues, and Advanced Tape Troubleshooting: Diagnosing Veeam LTO Drive Issues with ITDT..

Solution to UEFI VM failed to boot: Access Denied

As mentioned above, disabling Secure Boot is an option. Bacause XCP-ng ships with a complete set of Secure Boot variables (PK/KEK/db/dbx) by default. Regardless, we have the right PXE Loader copied form the right location without permission issues.

As discussed here “Fix Operating System Loader failed signature verification” on Dell Safe BIOS Systems via PXE [Part 3] as referrenced in the first paragraph above”. You can replace it with the updated server binaries from the System32 location if you wish. That is “C:\Windows\System32\RemInst\boot_EX\x64\wdsmgfw_EX.efi”.

To resolve this without compromising security by disabling Secure Boot. I will synchronize the WDS boot environment with the modern 2023-signed binaries provided by Microsoft from the System32 location.

This will replace the WDS PXE boot binaries with the latest Microsoft-signed (2023 certificate). WinPE/WDS “Extended” UEFI boot files from a fully updated Windows Server 2022/2025 will help restore Secure Boot compatibility without disabling it. To do this, you can run the commands below. This will ensure the files are replaced with the updated CA 2023.

# Update the (.efi)
copy “C:\Windows\System32\RemInst\boot_EX\x64\wdsmgfw_EX.efi” “F:\RemoteInstall\Boot\x64\wdsmgfw.efi” /Y
copy “C:\Windows\System32\RemInst\boot_EX\x64\bootmgfw_EX.efi” “F:\RemoteInstall\Boot\x64\bootmgfw.efi” /Y

Next, refresh the service to apply changes to clear the WDS “NBP” Cache. This is much easier than running the following command: wdsutil /Uninitialize-Server followed by wdsutil /Initialize-Server /RemInst:”C:\RemoteInstall” (replace with your path). I will also show you this later on how to run this command for completeness of this guide.

net stop WDSServer && net start WDSServer

Note: Do not forget to update your deployment share and regenerate the Lifetouch image. Then proceed to replace the image on WDS.

Please see What are the Differences between UEFI and BIOS, and “MDT deployment failed and Stuck at Command Prompt: Windows installation does not proceed via PXE boot“.

Boot Manager waiting User Confirmation

As you can see below, we have successfully fixed the “Access Denied” issue. The WDS Boot Manager is waiting for user confirmation before it continues the PXE boot chain. It displays the WDS Boot Manager version 0800.

By pressing Enter. It instructs the deployment to proceed to the next stage, usually the loading of the boot image or task sequence environment.

At this point, the network boot has already succeeded enough to reach WDS’s UEFI boot manager. But the process is paused for the “Press ENTER for network boot service” prompt.

Note: After you press Enter, the system should continue to the next phase, such as loading the WinPE image etc. But this is where it fails at the Winload.efi before the WinPE runtime kicks in.

wdsmgfw.efi → bootmgfw.efi → winload.efi → WinPE runtime

Please see Fix failed to connect to the backup server: Make sure it is online,. Also see how to fix Domain Join Error during Windows Deployment, and SCVMM setup Error 10421: Fix VMM Service Account conflict.

Part B: UEFI PXE Boot Failure: 0xc0000022 (Status_Abroted)

But then, a new error message is prompted “0xc0000022” as shown below which translates to STATUS_ACCESS_DENIED.

While the previous “Access Denied” was a firmware-level rejection (Secure Boot blocking the file execution). This one is an OS-level/WDS-level rejection which means, the NBP (wdsmgfw.efi, and bootx64.efi) are accepted. This proves the first statge of secure boot validation succeeded. Meaning the PXE Boot downloads the BCD and the WIM. And then hands off to the Boot Manager (bootmgfw.efi).

But the Boot Manager is running has hit a wall while trying to read the next set of required files at the OS/WDS stage during the transition to Winload/WinPE.

Winload Error

Since the subsequent files could not be read the Boot Configuration Data (BCD), it gets aborted.

The image below means, the UEFI Interactive Shell. It means the PXE/WDS boot chain has failed. And the firmware has fallen back to the shell instead of continuing into Winload/WinPE

Note: Buttom line, the Boot Manager is now trusted. But it is now trying to load the Boot Configuration Data (BCD). If the BCD contains paths to other boot binaries that are still signed with the revoked 2011 certificate. The Boot Manager itself will block them from loading.

UEFI PXE Boot Failures Caused by Improper EFI Boot File Sourcing

A common issue in PXE and WDS troubleshooting occurs when EFI boot files are manually copied from a mounted EFI System Partition. That is, when mounted (mapped as S: but in my case Z:) into Windows Deployment Services (WDS) or ADK WinPE media. Note that even when you copy from “C:\Windows\System32\RemInst\boot_EX\x64\wdsmgfw_EX.efi”. You will not be faced with permission issue but the biinaries will be overwritten which is another problem.

While this may appear harmless, it introduces subtle but critical inconsistencies in the boot environment that can result in PXE or WinPE boot failures due to NTFS/Permissions issues. Files sitting on an active EFI System Partition are under intense protection by the OS.

Therefore, when you copy them directly from a mounted volume to the ADK path. Due to permission stripping, these files often lose their “Read & Execute” inheritance. Or carry over restrictive ACLs that the WDS service cannot overcome.

The previous method used to resolve the “Access Denied” issue will be used here as well. The files in C:\Windows\System32\RemInst\boot_EX\ are specifically designed for Deployment Services. They are intended to be distributed over a network. And are explicitly built to handle the transition from PXE to WinPE.

Also see Failure 5456: Unable to determine destination disk, partition, and/or drive, see BDD Log. Also, see how to deploy MBAM Client as part of a Windows Deployment, and How to configure Windows Deployment Services on Windows Server.

The Fix “Update all Deployment Paths

As you can see in Part A. The WinPE boot image is still signed with the old Secure Boot certificate, so even though PXE loader + Boot Manager pass the new Windows UEFI CA 2023 validation. The Winload/WinPE do not, and Secure Boot blocks it. We will see why shortly despite already explained numerous times above. This is simply due to where we source these updated binaries are paramount. Also, ensure all binaries were updated. Despite this, these files will continue to be overwritten whenever the deployment is updated until Microsoft releases a newer version of the ADK containing the updated binaries.

Instead of pulling the updated CA 2023 files from the EFI partition. Use the Server’s system directory to update your ADK Media a shown below. Until Mirosft release newer ADK versions to reflect the updated binaries, the below will not work. They will be reverted during LiteTouchPE regeneration as it builds it with outdated binaries.

#Update the primary UEFI boot entry (Renaming to bootx64.efi for the standard)
copy “C:\Windows\System32\RemInst\boot_EX\x64\bootmgfw_EX.efi” “C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\Media\EFI\Boot\bootx64.efi” /Y

#Update the actual Boot Manager
copy “C:\Windows\System32\RemInst\boot_EX\x64\bootmgfw_EX.efi” “C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\Media\EFI\Microsoft\Boot\bootmgfw.efi” /Y

#Update the secondary loader (Optional but recommended for consistency). Always use the the bootmgr.efi from the boot_EX folder if available
copy “C:\Windows\System32\RemInst\boot_EX\x64\bootmgr_EX.efi” “C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\Media\bootmgr.efi” /Y

This ensures the signatures are 2023-compliant and the files are compatible with network loading.

Path Deployment Root (Drive:\Deployment\Boot\x64)

This is just a practive step only. I found that the bootmgr.efi still had the 2011 signature and this is also a blocker. Even if internal folders are patched, and this root-level loader is called, the firmware will revoke access. To fix this, run the command below.

The bootmgr.efi located in the root of the MDT Boot folder (Deployment\Boot\x64) is still signed with the revoked 2011 Microsoft CA, which means that even if all internal WinPE folders are patched, this root‑level loader will still be rejected by Secure Boot the moment firmware attempts to execute it. Updating the internal WinPE binaries alone is not enough, because the firmware always evaluates the first Boot Manager it encounters in the boot chain. Replacing this file manually with a newer version temporarily aligns the signature, but it still breaks the trust chain later because MDT/WDS regenerate the downstream WinPE components (winload.efi, WinPE kernel, etc.) from the outdated ADK baseline.

#Replace the legacy root loader with the 2023 version
copy “C:\Windows\System32\RemInst\boot_EX\x64\bootmgfw_EX.efi” “F:\Deployment\Boot\x64\bootmgr.efi” /Y

Another binary that needed to be updated was “drive:\Deployment\Boot\x64\bootmgr.efi which had 2011 CA as shown below. You can use the command shown in the image below. Or copy from the system32 folder to the deployment share path over File Explorer.

Please see Fix Users must have at least permission on these subscriptions, and how to fix Error 401 Permission denied for invalid PVE ticket.

Patch the WDS Master Repository

The reason these files keep “reverting” is that you are patching the destination folders while the Master Templates in the Windows System32 and ADK directories remain “poisoned” with the 2011 signatures. We await Microsoft to release a newer version of the ADK containing the updated binaries.

Since issue persisted, the presence of 2011-signed binaries in these paths. This is a critical issue that directly causes the 0xc0000022 (Status Aborted) error on your VM. And also the SupportAssist diagnostic loop on your physical Dell devices.

Modern UEFI firmware, including the TianoCore firmware in your VM and Dell’s SafeBIOS, has revoked the 2011 CA to mitigate the BlackLotus vulnerability. When the boot process encounters a file like wdsmgfw.efi or bootmgr.efi signed with the 2011 certificate. It blocks execution as a security risk.

WDS pulls its PXE loaders from C:\Windows\System32\RemInst. You must overwrite the 2011 versions at the source. As mention previously, these files will be over written due to ADK outdated baselines.

:: Stop WDS to release file locks
net stop WDSServer

:: Take ownership if “Access is Denied” occurs
takeown /f “C:\Windows\System32\RemInst\boot\x64\wdsmgfw.efi”
icacls “C:\Windows\System32\RemInst\boot\x64\wdsmgfw.efi” /grant administrators:F

:: Replace with the 2023 version
copy “C:\Windows\System32\RemInst\boot_EX\x64\wdsmgfw_EX.efi” “C:\Windows\System32\RemInst\boot\x64\wdsmgfw.efi” /Y
copy “C:\Windows\System32\RemInst\boot_EX\x64\bootmgr_EX.efi” “C:\Windows\System32\RemInst\boot\x64\bootmgr.efi” /Y

Please see Enable SSH and Remote Desktop Connection in Windows Server, and how to Create an NFS Storage on Synology NAS and Present it to XCP-ng.

The Operating System Source (Drive:\Deployment\Operating System)

While I also observed that the following OS still had 2011 signed files in the following path “Drive:\Deployment\Operating Systems\W11 for bootmgfw.efi and bootmgr.efi. They do not affect the PXE/WinPE stage.

They only matter during the “Apply Operating System task” much later in the deployment. However, for a clean “BlackLotus-proof” environment. I will also update these binaries with signed 2023 files. This ensures every new device imaged is natively patched against the BlackLotus vulnerability and Secure Boot revocation.

#Update the OS Boot Manager
copy “C:\Windows\System32\RemInst\boot_EX\x64\bootmgr_EX.efi” “F:\Deployment-03\Operating Systems\Windows 11\bootmgr.efi” /Y

#Update the OS Boot Loader
copy “C:\Windows\System32\RemInst\boot_EX\x64\bootmgfw_EX.efi” “F:\Deployment-03\Operating Systems\Windows 11\bootmgfw.efi” /Y

#Optional but recommended: Update the MUI resource for the OS loader
copy “C:\Windows\System32\RemInst\boot_EX\x64\en-US\bootmgfw_EX.efi.mui” “F:\Deployment-03\Operating Systems\Windows 11\en-US\bootmgfw.efi.mui” /Y

Please see Run Mendeley Reference Manager and Cite for Word on Windows, and Resolving VSS Errors: Veeam AD Backups failing with SentinelOne.

WinPE Internal Bootloader

Since we are have not reached the loading file screen where the WinPE is being downloaded. This means the Winload stage is failing as already mentioned. The Boot Manager is starting, but the “Trust” to download the WinPE (.wim) is failing. Therefore, ensure the following path in the Windows Preinstallation Enviornment has the updated CA 2023 binaries as discussed below. But, they will be overwritten:

C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\Media

• …\Media\EFI\Boot\bootx64.efi
• …\Media\EFI\Microsoft\Boot\bootmgfw.efi

Delete Cached and Generated Folders

I proceed and deleted these locations as recommended by some blogs. From my tests, MDT/WDS will repopulate them. Unfortunately with 2021 CA. Therefore, I will recommend not to delete the following folder “F:\RemoteInstall\Boot\x64\” if you have manually updated the binaries already as it does not get overwritten. You could also use these commands if you would like to reproduce my experience.

del /s /q “C:\Windows\System32\RemInst\boot\x64\*”
del /s /q “F:\RemoteInstall\Boot\x64\*”

• Drive:\Deployment\Boot\. Not that MDT will recreate this from your patched Media templates regardless and it will still not be complaint until Microsoft releases a new patch).
• C:\RemoteInstall\Tmp (WDS uses this for active PXE sessions and cached BCDs). Does not get overwritten.
• C:\Windows\Temp content (specifically any MDT or DISM-related subfolders).

Note: Running the WDS reset sequnce will force WDS to rebuild its entire PXE boot environment from scratch. This clears cached binaries, resets TFTP state, and regenerates all boot entries using whatever boot images WDS currently has registered. It also wipes any manually updated PXE binaries in System32\RemInst, because WDS always extracts fresh copies from the boot WIMs during initialization. A simple WDS restart achieves the same cache‑clearing effect, but the full regeneration ensures that WDS is serving clean, non‑cached files. The key point: any manual edits to PXE binaries are overwritten, because WDS always rebuilds from the WIMs, not from your patched files.

wdsutil /delete-server /force

wdsutil /initialize-server /reminst:"D:\RemoteInstall"

Syncing Updated Boot Manager .MUI Files with ADK Media

It is important because the updated 2023-signed Boot Manager (bootmgfw.efi) expects to load matching language resource files (.mui) that are also signed and version-aligned. If the WinPE or MDT boot image still contains older .mui files from the legacy ADK media, Secure Boot can treat the boot environment as inconsistent or partially outdated.

By manually copying the updated .mui files into the ADK Media path and fully regenerating the MDT boot image, you ensure that the Boot Manager and its associated UI resources originate from the same trusted signing generation.. This troubleshooting step also remains useful even after Microsoft releases a newer version of the ADK. During upgrades, mixed-content environments, stale boot images, or partially regenerated deployment shares can still leave older resource files inside existing WIMs or PXE paths. Verifying and re-syncing the .mui files provides a reliable method to confirm that all boot components are aligned with the currently trusted Secure Boot certificates and binaries.

#Sync the UI resource for the primary boot entry
copy “C:\Windows\System32\RemInst\boot_EX\x64\en-US\bootmgfw_EX.efi.mui” “C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\Media\EFI\Boot\en-US\bootx64.efi.mui” /Y

#Sync the UI resource for the internal Boot Manager path
copy “C:\Windows\System32\RemInst\boot_EX\x64\en-US\bootmgfw_EX.efi.mui” “C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\Media\EFI\Microsoft\Boot\en-US\bootmgfw.efi.mui” /Y

Update Deployment Share

Note: Any time MDT rebuilds LiteTouchPE, it pulls directly from the ADK WinPE baseline,. Which still contains the revoked or outdated boot chain (2011‑CA Boot Manager, mismatched Winload, and unpatched WinPE kernel). This means that even if you manually patch WinPE, SafeOS, Boot Manager, or PXE loaders, MDT will overwrite those fixes the moment it regenerates the boot image. WDS then extracts those same outdated binaries into its PXE store, causing Secure Boot to reject the Winload/WinPE stage. As long as MDT is allowed to rebuild WinPE, the Secure Boot trust chain will remain inconsistent and the system will fail again. We must wait for a new ADK Servicing release!

Note: Ideally, when the above is complete. You will have to update the “Deployment Share” and regenerate the Lite Touch Image. Then replace the old image in WDS as shown in the image below and bake new signatures into the BCD. I have outlined these steps compreensively here “ADK|WinPE|MDT: Deploy Windows with WDS“.

Note: In WDS/MDT environments, regenerated LiteTouch boot images can create duplicate image identities (for example LiteTouchPE_x64.wim) when older boot-image metadata or BCD associations still exist.

As a result, WDS may continue referencing a stale PXE boot chain instead of the newly regenerated WinPE image. On Dell SafeBIOS systems enforcing updated Secure Boot trust requirements. This can cause PXE boot failure if the older boot chain still contains EFI components copied from the EFI partition as it is in my case.

Therefore, by deleting the files in Drive:\RemoteInstall\Boot\x64\Images and regenerating them. We forced MDT to create a fresh BCD (Boot Configuration Data)

LiteTouchePEx64 is being uploaded to WDS

LiteTouchPE uploaded (replaced) as the case may be for you successfully

When this is done, you will have to clear the WDS cache by restarting the WDS service. This ensures the physical Dell and the VM aren’t pulling the 2011-signed bootmgr.efi from the server’s RAM.

net stop WDSServer && net start WDSServer

Please see A-Z on Veeam Data Cloud: Workload Enrollment and Onboarding, Veeam Enterprise Manager setup and User Role management, and A real case of Internal Sabotage and Recovery.

Perform Deplozyment Test Once again

PXE clients can successfully load the WDS PXE boot loader because that stage uses bootmgfw.efi from the WDS RemoteInstall store that does not get overwritten. This is now correctly signed and accepted by Secure Boot.

The failure occurs later, when control passes from bootmgfw.efi → winload.efi → the WinPE runtime as discussed above too.

This later‑stage failure indicates that although the initial PXE loader is trusted, the next‑stage WinPE binaries or their trust chain remain inconsistent, causing Secure Boot to reject them and resulting in the observed crash or 0xc0000022 behavior.

Because the failure now happens after the PXE loader succeeds, it confirms that the replacement PXE binaries are correct, but the WinPE runtime chain is still built from older ADK components that MDT/WDS automatically regenerate.

This proves the issue is upstream in the ADK servicing pipeline, not in WDS or MDT. And that the WinPE boot chain will remain inconsistent until Microsoft ships updated, Secure‑Boot‑compatible binaries. Any manual replacement is overwritten by the regeneration process, so the problem cannot be permanently fixed without a corrected ADK release.

Please see Veeam Enterprise Manager setup and User Role management, Building VIHR: Ransomware-Proof Repository with Veeam JeOS, and how to fix Failed to connect to Deployer Service Error.

Summary

This procedure is only a temporary workaround and will serve as a troubleshooting guide in the future as discussed previouly. It does not resolve the underlying issue currently as at the time of writing this guide. The core problem is that Microsoft’s ADK servicing pipeline continues to supply outdated or incompatible WinPE boot binaries, and both MDT and WDS are designed to always regenerate WinPE from the ADK baseline.

As a result, any manual changes made to WinPE, WDS PXE loaders, or MDT boot images are not persistent. When the Deployment Share is updated or LiteTouchPE is rebuilt, MDT automatically re‑applies the older ADK WinPE binaries, and WDS subsequently extracts those same binaries into the RemoteInstall directory.

This regeneration process overwrites all patched files including bootmgfw.efi, bootmgr.efi, winload.efi, boot.sdi, and BCD templates which leads to Secure Boot failures (e.g., 0xc0000022, Dell SupportAssist triggers, or XCP‑ng dropping to shell).

Therefore, the only durable fix must come from Microsoft in the form of an updated ADK servicing release that includes corrected, Secure‑Boot‑compatible WinPE binaries. Until Microsoft provides such an update, any workaround (including manually patching WinPE or building a custom boot image) will be overwritten by the ADK, MDT and WDS regeneration chain and cannot be considered a permanent solution.

Note: A custom WinPE built outside MDT/WDS works because it bypasses the entire ADK → MDT → WDS regeneration pipeline. In this model, you manually patch WinPE, inject MDT scripts, and import the WIM directly into WDS. This means MDT never touches it, and WDS never regenerates it. This produces a stable, Secure‑Boot‑compatible boot chain. However, the moment you rebuild LiteTouchPE in MDT, the custom WinPE becomes irrelevant: MDT regenerates a new LiteTouchPE.wim using the outdated ADK binaries, and WDS extracts those broken binaries again. This instantly breaks the trust chain and causes the same Winload/WinPE Secure Boot failure. In short: custom WinPE works only as long as MDT is not allowed to regenerate LiteTouchPE.

I hope you found this article on “PXE Boot Failure: “Access Denied or Aborted” with Secure Boot on” very useful. Please feel free to leave a comment below.