I know there's a plethora of open-source and vibe-coded OS deployment solutions out there, all of which I am sure are fine in their own ways. But if you're looking for a complete MDT (or SCCM OSD) replacement, try out the free DeployR Community release, https://2pintsoftware.com/products/deployr-community. A new release came out today with a variety of enhancements and fixes, and we are preparing for an even bigger release next month.

The community version is supported through r/DeployR, with the DeployR Enterprise version supported directly by our top-notch engineering team (who also pop up on Reddit frequently).

I spent several years at Microsoft architecting MDT (and writing most of the code and documentation too), and we want to make sure that DeployR operates the same way: Listening to community feedback and making the requested improvements and fixes quickly. We frequently release new builds (for both Community and Enterprise) in that vein.

With MDT officially done, a lot of us are rebuilding our deployment chains anyway. For me the weakest link was never the task sequence, it was the handful of vendor installers that pop a dialog, wait forever, and stall the whole thing.

So I built a tool that turns those into proper MSIs. Snapshot before, run the installer by hand (reboot in between is fine), snapshot after, review the file/registry diff, build. You get an MSI that does msiexec /qn like it should, plus ICE results and a package report. There's a silent test install built in so you can check it before it goes into the deployment share.

Free, runs locally on Win10/11, no account. Closed source, but nothing leaves your machine.

https://repackager.bath-electronics.de

If you've got an installer that's been breaking your task sequences for years, I'd honestly like to try it against that.

With MDT officially done, a lot of us are rebuilding our deployment chains anyway. For me the weakest link was never the task sequence, it was the handful of vendor installers that pop a dialog, wait forever, and stall the whole thing.

So I built a tool that turns those into proper MSIs. Snapshot before, run the installer by hand (reboot in between is fine), snapshot after, review the file/registry diff, build. You get an MSI that does msiexec /qn like it should, plus ICE results and a package report. There's a silent test install built in so you can check it before it goes into the deployment share.

Free, runs locally on Win10/11, no account. Closed source, but nothing leaves your machine.

https://repackager.bath-electronics.de

If you've got an installer that's been breaking your task sequences for years, I'd honestly like to try it against that.

A few months ago I made a post about a MDT replacement tool that I was working on. Since then, there's been no shortage of others who have also released tools but I think I have a few features that some out there might appreciate.

• Open source, MIT licensed. Use it in your corp/enterprise environment with no restrictions or licensing costs.
  
• HTTP boot. I specifically wanted to be able to deploy over WAN or even the internet, and TFTP/PXE booting was painfully slow over high latency links.
  
• Automated driver management. No more total control, no more pulling new driver packs when a new model is introduced to your fleet, start a deployment and the deployment server will automatically identify the correct driver package and serve it without any manual input (for manufacturers/models that publish driver catalogs such as Dell, HP, and Lenovo).
  
• Chocolatey support. I got tired of updating software packages constant to keep them up to date. Common apps can be installed directly through the Chocolatey package manager so they're always the latest version.
  
• Always up to date OS image. Coming soon, but I want to spend less time doing Windows Update for newly deployed machines. The deployment server keeps the deployment WIM up to date by directly injecting the latest updates before a deployment even happens.
  

I'm not ready to release the source code just yet, there are a handful of things that I want to get fixed and added, but I'm expecting that will occur in the next week.

In the interim, I wanted to share a video of a deployment so people can see what the process looks like: https://youtu.be/iKRBf_MlAjM

And for those of you who would like to try a deployment yourselves, you can point a device's HTTP boot to the following URL: http://deploy.biohazrd.com/boot/x64/boot.efi

This will obviously wipe your drive and install an OS, so don't do it on anything you care about.

I just finished upgrading the task sequences, in 26H2 wscript is still present and there was no issue completing our scripts.

This likely means your MDT is still good for another year.

Hi everyone,

I have a working MDT / WDS environment at our primary site. We recently connected a branch office via a VPN tunnel. The remote site has its own local DHCP server, and routing between both subnets is fully operational.

To save VPN bandwidth, I want to deploy a Linked Deployment Share on a local server at the remote site, managed from our main MDT server.

Does anyone have a solid step-by-step tutorial or documentation link for setting this up? Any tips or common pitfalls to avoid when replicating and deploying across sites would be greatly appreciated!

Thanks!

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!