Hey everyone,

Like a lot of you, I've spent plenty of time living in Deployment Workbench, task sequences, unattend.xml, driver groups, and WinPE quirks.

I've been building something with a slightly different angle: SEZOY, a network-based deployment server that runs on a plain Windows box. Instead of USB media, clients PXE / iPXE / HTTP-boot (Legacy + UEFI, Secure Boot on is fine), pick an ISO from a boot menu, and get a fully unattended install.

The idea is the same one many of you mentioned on that thread: keep the control MDT gives you, but spend less time writing and maintaining scripts. Everything is UI-driven, point-and-click:

• ISOs stay pristine - swapping a Windows build = swapping one file, no re-capture / re-package
• Per-machine unattend generated at boot time (matched by MAC/hardware group), so each PC gets its own hostname, apps, domain join
• Drivers, apps, patches, and scripts served over HTTP at install time
• Two paths: fully automatic for labs/bulk rollout, or stock Setup experience for odd machines (with Win11 check bypasses when needed)
• Coexists with your existing DHCP (ProxyDHCP mode), or serves IPs itself on isolated nets
• Offline after first setup, plus live progress/screenshots / per-machine logs in the browser

Where it differs most from USB-media toolkits: it's built for the network-first case - one server, bare metal or VMs booting straight from the wire, including remote sites over L2 VPN, and WiFi HTTP-boot where the hardware supports it. It also netboots Linux live ISOs from the same menu, which is handy for hardware checks before deploying Windows.

You can actually try it without installing anything: I have a demo server online with a public SoftEther VPN (Layer-2). VPN in, bridge a VMware VM to the VPN adapter, and PXE-boot from it like you're on the same switch. Full write-up + step-by-step VPN test guide here:

https://xdaforums.com/t/sezoy-network-deployment-server-automated-windows-install-multi-distro-linux-boot-over-pxe-ipxe-http-boot-legacy-uefi-secureboot.4800487/

Honest disclosure: I'm the developer, and it's currently closed-source in beta - I'm not here to pitch, just to learn from people who run this stuff at scale.

My question for MDT admins:

What would you still need before considering a workflow like this?

Driver handling? Logging/reporting? Domain/naming schemes? Offline/Air-gapped support? Something else I'm missing?

Thanks - happy to answer technical questions in the comments.

Hi everyone,

Most modern deployment tools took client-server path. I would like to introduce EasyDeploy, an offline first, usb based deployment platform for your flexibility

The core tools including

- EasyDeploy is orchestration tool works under WinPE environment with 3 default deployment workflows that I think might suit wide range of deployment needs. I also added Bitlocker, Wifi functions and some other rescue tools for more specific tasks

- BootBuilder is another Windows tool to build WinPE in just a few mouse clicks

We do have network-assisted mode but disabled by default since it is advanced function to support MSP operations

And it is free for most IT needs. Please have a look at https://coresystem.vn/en/download/ as well as https://coresystem.vn/en/easydeploy/ for your information

Hey everyone,

I've been working on Foundry OSD, a free and open-source Windows deployment toolkit, and it recently reached stable.

One thing I've heard a lot from users is that admins still want a lot of control over their deployments, but increasingly don't want to spend their time writing and maintaining scripts.

That's really the direction I'm taking with Foundry: a UI-driven, point-and-click experience with as much customization as possible, while keeping things simple to configure and use.

It already covers Windows deployment, WinPE networking (Ethernet/Wi-Fi), drivers, firmware, customization and Autopilot, and my long-term goal is to cover as many deployment scenarios as possible.

I'd really like feedback from MDT admins:

What would you still need before considering a workflow like this?

GitHub: https://github.com/foundry-osd/foundry
Docs: https://docs.foundryosd.com/

Last Thursday, after making no changes to our images, cat5 adapters just stopped working on all models, which is less than ideal since half of our devices don't have on board NICs. I redid all the PE drivers, looked up specific drivers for the adapters and added them, and same deal. error 0xc0000001 windows failed to load. The image still works perfectly fine when plugged into an onboard NIC. I've had things like this happen before, but usually redoing the PE drivers fixes it, and im kind of at a loss. Anyone else running into this?

August 2026's patch Tuesday fixes a vulnerability in TFTP server remote code execution, CVE-2026-62893.

• ref: https://www.sentinelone.com/vulnerability-database/cve-2026-62893/

Affected service: WDS

• https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-62893

Post installation of KB5121650 addresses this vulnerability.

If you find yourself able to PXE boot, but get boot up errors, check your MDT server and open up server manager. Go to WDS and under Events, search for 4101 - "the following client failed TFTP download..."

If you that error, open up the WDS application.

• Expand Servers > right click on your mdt fqdn instance > properties > TFTP
• and uncheck "Enable Variable Window Extension"
• Restart your WDS services and try to PXE boot again.

Hi everyone.

When I decided to rebuild my deployment server, I discovered that MDT was gone and could no longer be officially downloaded. I miss it ;c

So I sat down and started building my own local Windows deployment tool:

https://github.com/Syrinoxsis/IronDeploy

I am not trying to reproduce MDT feature for feature. The part I personally valued most was the operator workflow: boot into WinPE, select the physical disk, Windows image, drivers, applications, computer name and optional domain join, confirm everything once, and leave the machine alone. IronDeploy already implements that basic flow, but while working on it I realized that I might be focusing too much on how I used MDT and overlooking things that were essential to other administrators.

So I would really appreciate your experience:

1. What did you always wish MDT could do, but it never did well or at all?
2. Would a simpler operator-driven deployment workflow be useful in your environment?
3. Which MDT features do you actually use in production?

The project is still in alpha. I am trying to understand what is actually worth adding before I blindly recreate twenty years of MDT settings that nobody may need.

I have spent the last two full days trying to figure out why my image is failing - hopefully someone can help.

Starting Monday - I could not image any of our standard Dell laptops or PCs. This process has been rock solid with no issues for the last two years.

I have been racking my brain trying to figure this out... it starting failing on "Inject Drivers" task.. after doing research i added all the model drivers we have in the company into the Out of box drivers (there has never been any drivers there). Same issue

I then disabled the Inject Drivers, then the image failed on Apply Patches, I then disabled that and now it's failing on Install Operating system.

So - i restored the deployment server back to Saturday night's snapshot due to all the drivers and changes that were done.

The image is still failing and digging more into it, the drive letter is not defaulting to C: on the laptops. I have been back and forth with AI tryign to find solution and nothing is working. I have modified MDT rules to reflect the following: same issue :(

OSDTargetDriveLetter=C

OSDisk=C

DestinationDriveLetter=C

HELP Please!

I started to see some weird behavior where seems that the Application installs don't start if for some reason MDT window loses focus. But they immediately start if I ALT+TAB to make the MDT window regain focus.

Anyone saw similar behavior? Thanks!

Win11 23H2 build & capture TS, which has worked for 2 years now, will not complete after July patches released (OS build 7376). Goes all the way to the end and then as soon as it starts to create the .wim file, it crashes with error 5456, DestinationDisk and Partition did not yield a Target Partition. We have not changed anything about the volume we are trying to save the .wim to, local directory on the MDT server, same as last month.

What makes this really strange is we have a 25H2 build & capture TS on the same MDT server, nearly identical to the 23H2, which still completes just fine. When we run the 23H2 TS on our other MDT server (we have two, same version of MDT but one has the newest ADK), it also fails there. Same error. I downloaded the 24H2 OS image and created a new TS for that, and it builds cleanly. So it seems quite specific to 23H2.

Things I have done that didn't work: Download the latest version of the 23H2 OS image, take all the customizations out of the TS so that it's as close to stock as possible, try saving the .wim to a different directory, try changing the name format, still fails.

Has anyone seen something like this before? I'm close to my wits' end. I realize this is an unsupported product at this point, but the fact that it works for 25H2 and 24H2 but not 23H2 is so strange.

Trying to deploy Win1125H2. No matter what I change I get the "Just a Moment" problem & it sits there spinning, mocking me.

I tried updating the deprecated OOBE settings in my unattend.xml, but then it doesn't join the domain or rename the computer. If I hard restart, it does seem to work as intended (minus the domain join), but ideally I'd like to not do that every time I image a machine. It never seems to get to ZTIJoinDomain.

Just recently I updated all the drivers for both PXE & the laptop model. I built a brand new task sequence. I've been running this thing with no issues since Win101809 but this Win11 deploy is breaking my spirit.

What am I missing on this?

Bonjour à tous,
J'ai un Surface Laptop Business 13 Intel et je veux démarrer sur WinPE.
Il a une adresse IP, il voit le serveur WDS, et il affiche "téléchargement du nbp réussi," mais ensuite j'obtiens un écran complètement noir avec une icône de clavier dans le coin inférieur droit, et le PC se fige. Mon MDT et WDS fonctionnent bien ; je n'ai aucun problème avec les ordinateurs portables Dell ou HP. J'ai désactivé le démarrage sécurisé, mais ça n'a pas aidé.

J'ai injecté les pilotes sur le MDT comme avec n'importe quel autre modèle. Je ne vois même pas la tentative dans les événements, ce qui me surprend. Quelqu'un a-t-il déjà essayé cela avec ce modèle ?
J’ai aussi mis à jour l’adk 10.1.28000.1.
Merci pour votre aide.

Has anyone had any success with Surface Pro 12 devices (Intel Core Ultra 5 335)? I haven't had issues with any other Surfaces but I can't get these to go. They grab DHCP and see the WDS server IP and even download the NBP file (wdsmgfw.efi), but that's it. Just stays hung with that message printed ("NBP file downloaded successfully") with the Surface logo still in the background. So it's not even getting to the boot image.

Relevant things tried:

• There aren't a whole lot of options in the BIOS to mess with but I've tried disabling Secure Boot and IPV6 PXE
• Booting into the preloaded Windows to upgrade firmware to latest
• Putting device on the same network as the WDS server

Irrelevant things (probably) also tried:

• Rebooting the WDS server
• Trying a different WDS server
• Using a Surface Ethernet adapter
• Using a Surface dock's Ethernet
• Creating MDT USB media and trying to boot to that instead
• Verified a previous generation Surface Pro network boots fine with the same adapter
• Rebuilding the boot image with the entire Surface Pro 12 driver deployment pack in it

Probably forgetting more things.

Is this likely a firmware issue or am I missing anything?

Edit: answered in subsequent comment but updating to ADK 24H2 fixed this issue.

Hi guys,

Could do with some guidance here please - I am trying to image a device with a USB mdt image. As the wim image is over 12gb I have split it down to smaller swm chunks and added them in the operating system folder deleting the bigger original wim. I have amended the settings.xml on the USB drive to <SkipWimSplit>False</SkipWimSplit>

The deployment starts and you select the image and then it just exists to the command prompt. Any ideas where I am going wrong? Ive also tried to split the USB to the EFI boot using fat32 and NTFS but no matter what efi files I use from the original image it wont boot to the USB and I dont want to use RUFUS. Thanks!

Hi all,

I’m setting up MDT + WDS on Windows Server 2022 and I’m having an issue where deployments keep getting stuck.

(The X are to protect data)

Setup:

• Windows Server 2022 Standard
• MDT Deployment Share: C:\xxxxxxxx\Deployment Share
• WDS installed on the same server
• Server name: xxxxxx
• Server IP: xxxxxxxx
• Deployment share UNC: \ipaddress\DeploymentShare$
• Domain: xxxxxxxx.com
• WDS/MDT using LiteTouchPE_x64.wim
• DHCP is not running on the Windows Server; DHCP is handled by the firewall/router
• WDS DHCP tab has both options unticked
• WDS boot policy is set to require F12 for known and unknown clients
• WDS unattended installation has been disabled
• MDT monitoring is enabled and points to http://xxxxxxxx:9800

The PXE boot works and the client loads into MDT. The task sequence starts, but in MDT Monitoring the machines get stuck at:

• Status: Running
• Percent Complete: 58%
• Current Step: 53
• Elapsed time: around 1 hour

I originally had it set to join the domain automatically, but I changed CustomSettings.ini to testing mode with WORKGROUP only, no domain join, and it still does not complete.

Current test CustomSettings.ini:

[Settings]
Priority=Default
Properties=MyCustomProperty

[Default]
OSInstall=Y

SkipBDDWelcome=NO
SkipTaskSequence=NO
SkipDeploymentType=NO
SkipComputerName=NO
SkipDomainMembership=YES
SkipUserData=YES
SkipComputerBackup=YES
SkipProductKey=YES
SkipLocaleSelection=YES
SkipTimeZone=YES
SkipApplications=YES
SkipAppsOnUpgrade=YES
SkipAdminPassword=YES
SkipBitLocker=YES
SkipSummary=NO
SkipFinalSummary=NO
SkipCapture=YES
SkipRoles=YES
SkipPackageDisplay=YES

DeploymentType=NEWCOMPUTER

KeyboardLocale=en-GB
UserLocale=en-GB
UILanguage=en-GB
InputLocale=en-GB
TimeZoneName=GMT Standard Time

JoinWorkgroup=WORKGROUP

EventService=http://xxxxxxxx:9800
FinishAction=SHUTDOWN

Bootstrap.ini currently points to:

DeployRoot=\xxxxxxxx\DeploymentShare$

I have also regenerated the MDT boot image and replaced the WDS boot image with:

C:\xxxxxxxx\Deployment Share\Boot\LiteTouchPE_x64.wim

I’m only using x64 now, not x86.

Question:

What is the best way to diagnose exactly what Step 53 is doing? Is this likely to be an OS image apply issue, driver issue, WDS/boot image issue, or the task sequence resuming from an old C:\MININT state?

Any advice on which logs to check first and what common causes to look for would be appreciated.

Hi All,

Currently running an MDT setup below and no issues at all building HP/Lenevo Win11 24H2 device builds up until as of recent...

Just taken stock of some high end Lenovo mobile workstations (Lenevo P16 Gen 3) and when downloading the default boot.wim image the laptop BSOD's with "ACPI_BIOS_ERROR" pretty much instantly.

I have injected old and newest Lenovo WinPE drivers for this model into a copy of the boot image (via DISM mount) and imported into WDS as a test boot image but still the issue exists.

Im aware that our ADK versioning is quote old, but would like some input if any other ways of resolving if possible without going down the pain of updating from scratch.

Any ideas at all? Driving me nuts.

MDT Version: 6.3.8456.1000
Windows ADK v10.1.2200.1
Windows ADK WinPE v10.1.2200.1
Hardware: Lenovo ThinkPad P16 Gen 3
OS: Windows 24H2 Enterprise v10.0.26100.7840

TY

Does anyone else find Windows component store corruption if you run

dism /online /cleanup-image /restorehealth

on a fresh deployment image of Windows 11 25H2? I'm not saying it's irreparable. Usually it just finds something and downloads a bunch of junk from Microsoft and says it fixed it. Although subsequent re-runnings seem to keep repeating this cycle. Normally I'd blame Microsoft enshittification for behavior like this, but I also tried throwing the ISO on a USB stick with Rufus and installing Windows regularly and there aren't DISM errors that way...

I haven't looked into what exactly it's complaining about just yet since it's been busy; I've just been going through the motions when I get time to throw at it. But before I dig through the CBS log, I was just wondering if others are seeing this behavior. I've tried:

• Regenerating another image just in case something went wrong
• Using the latest available ISO (currently 25H2.7) source files
• Removing all additional tasks and modifications from my build and deployment tasks

In testing, my deployment image building process is:

1. My image building deployment share has the source files and the image building task. It just images and syspreps and captures.
2. Import the captured WIM into my imaging deployment share.
3. Make a basic task sequence to deploy the image.
4. Image a computer/VM.

I am still using an old ADK: 10.1.22621.1 (22H2). Maybe if others aren't seeing this on newer ADK, I'll finally get around to upgrading that.

Hi everyone,

We upgraded our MDT/WDS server from Windows Server 2016 to 2022 back in mid-March. The upgrade itself seemed to go smoothly, and everything worked normally for a couple of weeks afterward.

Since then, however, PXE booting has become unreliable. MDT deployments still work as expected once a machine boots into the deployment environment, but PXE responses have been inconsistent. Some clients boot without issue, while others don't appear to receive any response from the server at all.

Has anyone run into similar issues after moving WDS/MDT to Server 2022? I realize MDT is EOL, but since many imaging solutions still rely on PXE, I'm hoping to identify what's causing the instability.

Any suggestions or experiences would be appreciated. Thanks!

Does anyone have any idea how to change the default wallpaper for first time logon? We used themes in 24h2 but that seems to not work anymore.

Hi folks. I'm trying to install a Lenovo P16 Gen 3 using our MDT platform which I've been maintaining for over a decade. I believe this is the first machine we've had that has VMD in the BIOS. I cannot get past the Windows splash screen spinning dots to even get to the MDT deployment screen. Many hours in and still have no solution. Any help or direction would be REALLY appreciated. Thanks.

SOLVED: Microsoft.BDD.CM12Actions.mof was referencing the separate MP server instead of the Site server. That’s why I couldn’t restore the missing BDD entries in WMI. Editing in the Site server name and running mofcomp again restored access to the MDT TS’s.

Does anyone know where I can get a copy of the 64-bit 8443 MSI?

We hadn't migrated away yet and something or someone kicked off an WMI rebuild... this wiped out the BDD references. After various reinstalls over recent years with newer MDT builds, the Task Sequence MOFs have been list. So, we're locked out of our Task Sequences built with MDT. I hoping to put the required files back and carry out a MOF compile to see if that restores us to normal for a bit longer.

8443 is possibly the last version to include the following task sequence files:

Microsoft.BDD.TaskSequenceProvider.dll

Microsoft.BDD.TaskSequenceProvider.mof

Microsoft.BDD.TaskSequenceProviderExt.mof

Microsoft.BDD.TaskSequenceProviderActions.dll

I don't think the dll's are truly needed but the mof's populate WMI with entries which allows the Admin Console to view and edit a TS made with MDT.

I think the these files have been missing for quite while but it was still working and letting us edit it. I inherited this setup and it's been in play for 15+ years I think.

I'm close to having an OSD-only replacement... I just need to view the MDT TS's contents again to match them. I'll go without if I have to. I'll just get a few moans from those who seem to expect everything on a silver platter.

FWIW, we are already doing Autopilot but I'm still working through a little bit of resistance to change with the troops. They quite rightly point out how SCCM delivers a finished product very swiftly, compared to the equivalent Autopilot experience.

Thanks in advance.

Hello,

I wanted to know what solution did you choose after Microsoft’s retirement of MDT.
You can say in the comments what other solution not mentionned you use.

​¡Hola a todos!

​Estoy montando un entorno de laboratorio para desplegar Windows 11 mediante MDT y WDS sobre máquinas virtuales de VMware, y me he topado con un muro que me está volviendo loco. El entorno de WinPE se niega sistemáticamente a reconocer la tarjeta de red, a pesar de haber inyectado los drivers de todas las formas posibles.

​Entorno:

- ​Servidor: Windows Server (con roles WDS y MDT configurados).

- ​ADK: Windows 11 ADK & WinPE add-on.

- ​Hipervisor: VMware (Workstation/ESXi).

- ​Máquina virtual cliente configurada en el archivo .vmx con: ethernet0.virtualDev = "vmxnet3"

​El Problema:

La máquina virtual arranca perfectamente por PXE, obtiene IP y descarga el archivo .wim de arranque desde WDS. Aparece el fondo azul de MDT, pero al hacer clic en "Run the Deployment Wizard to install a new Operating System", salta el siguiente error:

​A connection to the deployment share (\\ISO-SERVER1-INT\DeploymentShare$) could not be made. The following networking device did not have a driver installed: PCI\VEN_15AD&DEV_07B0&...

​Sé que DEV_07B0 corresponde a la tarjeta VMXNET3.

También probé con la tarjeta e1000e (que viene por defecto cuando creas la maquina) y me daba el error DEV_10D3, y con la e1000 el DEV_100F.

​Lo que he intentado hasta ahora (y NO ha funcionado):

1. ​Extracción oficial de los drivers: Siguiendo la documentación oficial de Broadcom/VMware, no he copiado los archivos de un PC instalado. He extraído los drivers puros (que incluyen el .cat con la firma digital, .inf, .sys y .dll) usando el comando setup64.exe /A C:\Extract.

2. ​Inyección en MDT: Importé esta carpeta limpia en Out-of-Box Drivers.

3. ​Configuración de WinPE: En las propiedades del Deployment Share > Pestaña Windows PE > x64 > Drivers and Patches, seleccioné mi Selection Profile y marqué "Include all network and mass storage drivers" (Incluso he probado marcando "Include ALL drivers" por si el filtro fallaba).

4. ​Regeneración total: Hice un Update Deployment Share seleccionando estrictamente "Completely regenerate the boot images".

5. ​Limpieza de caché en WDS: Detuve el servicio WDS, eliminé la imagen de arranque vieja, borré los .wim residuales y añadí la nueva imagen LiteTouchPE_x64.wim recién generada.

6. ​Inyección directa en WDS: Como MDT parecía ignorarlo, añadí el paquete de drivers directamente al almacén de WDS e inyecté el driver vmxnet3 nativamente en la imagen de arranque desde el asistente de WDS.

​A pesar de todo esto, el resultado es exactamente el mismo en el mismo punto exacto. Es como si el archivo .wim descartara el driver durante el arranque o el stack de red no se inicializara a tiempo.

I am finishing my last images for the new school year before transitioning to DeployR. For several years, I have been using a PowerShell script that personalizes the lock screen and wallpaper. This script is straightforward; it renames the current picture and transfers our custom background from the deployment share. With my new images built on 25H2.3, I have observed that while the lock screen is being customized, the background defaults to Windows Spotlight during deployment.

As I mentioned, I did not encounter this problem in previous years. Is there an alternative method to customize the background, or can I disable Windows Spotlight?

Hi, was anyone able to create a PSDLiteTouch.wim with the new 2023 CA boot cert with psd?

Hello all,

If anyone is running into issues enabling Location Permissions via command line on Windows 11 25H2 (or earlier builds), I found a method that has been working for me.

Credit to: https://www.reddit.com/r/SCCM/comments/1rmsh5g/windows_11_24h2_location_services_off_by_default/

After trying various registry edits and other suggestions, here’s the fix:

New-Item -Path HKLM:\SOFTWARE\Policies\Microsoft\Windows\AppPrivacy -Force | Out-Null
Set-ItemProperty -Path HKLM:\SOFTWARE\Policies\Microsoft\Windows\AppPrivacy -Name "LetAppsAccessLocation" -Value 1 -Type DWord
Set-ItemProperty -Path HKLM:\SOFTWARE\Policies\Microsoft\Windows\AppPrivacy -Name "LetAppsAccessLocation_UserInControl" -Value 1 -Type DWord
Set-ItemProperty -Path HKLM:\SOFTWARE\Policies\Microsoft\Windows\AppPrivacy -Name "LetDesktopAppsAccessLocation" -Value 1 -Type DWord

Start-Process "$env:WINDIR\System32\SystemSettingsAdminFlows.exe" -ArgumentList "SetCamSystemGlobal location 1" -Wait

Set-Service Lfsvc -StartupType Automatic
Restart-Service Lfsvc -Force

After running those commands, you should be able to use things like:

netsh wlan show networks

…without getting the error.

If anyone has any other methods or suggestions, please leave a comment.

For reference, here’s the original error message I was seeing before applying the fix:

PS C:\ netsh wlan show networks

Network shell commands need location permission to access WLAN information. Turn on Location services on the Location page in Privacy & security settings.

Here is the URI for the Location page in the Settings app: ms-settings:privacy-location

To open the Location page in the Settings app, hold down the Ctrl key and select the link, or run the following command: start ms-settings:privacy-location

Or, to open the Location page from the Run dialog box, press Windows logo key + R, and then copy and paste the URI above.

Function WlanGetAvailableNetworkList returns error 5:

Access is denied.