Speeding Up ConfigMgr OSD Task Sequences Without MDT Integration (2026)

Microsoft retired the Microsoft Deployment Toolkit in January 2026. No more fixes, no more security patches, no more compatibility updates for new Windows builds. If your ConfigMgr task sequences still lean on MDT integration, that’s now a dependency on a dead product sitting in your deployment pipeline.

Pulling MDT out doesn’t have to mean slower OSD. Most of the “MDT made it faster” reputation was never really about MDT itself, it was about content design and driver handling. Here’s what actually speeds up native ConfigMgr OSD task sequences once MDT integration is gone.

Why this is urgent, not just tidy housekeeping

MDT integration adds ZTIGather scripts, the Microsoft Deployment Toolkit package itself, and a layer of wrapper logic around steps that ConfigMgr can now do natively: driver injection, USMT-based user state capture, and OS image application. None of that needs MDT any more, and every unsupported component you leave in a build is one more thing that quietly breaks on the next Windows servicing update with nobody fixing it upstream.

Removing the integration is a one-off job: delete the MDT-specific steps (Gather, Install DeploymentAgent, Recover from Domain, and similar), remove the toolkit package reference, and rebuild the task sequence using the native equivalents below. It typically takes an afternoon per task sequence, not a rebuild from scratch.

Pre-cache content instead of pulling it live

The single biggest time cost in most OSD runs is waiting for content to download from the distribution point during the task sequence. Configure pre-cache content on the OS image and driver package, and the client downloads them in the background before deployment even starts, so the task sequence just applies content that’s already sitting in the client cache.

For refresh scenarios this is close to free: the machine has been sat on the network for days beforehand. For bare metal builds, pair it with prestaged media on a USB stick or in the factory image so the OS and driver content never touch the network at all during deployment.

Avoid “Access content directly from the distribution point” as a shortcut for low-disk devices. It skips package hash verification and pulls content over the network step by step, which is slower and less secure than pre-caching.

Trim driver packages down to what’s actually needed

A single “all models, all drivers” package sounds convenient but forces every deployment to download and evaluate drivers it will never use. Split by model instead.

Keep vendor driver catalogues current rather than accumulating every pack ever imported. Old, superseded driver packages left in the console still get evaluated by matching logic and add nothing but overhead. If you’re deploying HP hardware, our guide on finding current HP driver packs for SCCM/Intune covers where to pull clean, up-to-date packs from.

Structure steps with conditions, since parallel execution isn’t really an option

ConfigMgr task sequences run one step at a time, full stop. There’s no native way to fan out steps to run concurrently within a single sequence. The practical substitute is conditioning groups so devices only ever execute the steps relevant to them:

1. Put a Check Readiness step (or a group of WMI/registry condition checks) right at the start, so incompatible hardware fails out in seconds rather than partway through an image apply.
2. Wrap architecture-specific or model-specific steps in their own groups with conditions, rather than one long flat list of conditioned individual steps. Groups short-circuit cleanly and are easier to audit.
3. Use dynamic application variable lists (APP01, APP02…) for the Install Application step rather than a static list, so collection-driven variation doesn’t need separate task sequences.

Tune the boot image

A bloated boot image adds seconds to every single PXE boot and USB boot on the estate, which adds up fast across a large deployment. Keep it lean:

• Only inject the drivers the boot environment actually needs (NIC and storage controllers), not the full driver catalog. Boot image drivers are a different problem from OS drivers.
• Build one x64 boot image rather than maintaining both x86 and x64 unless you genuinely still image 32-bit hardware in 2026.
• Distribute the boot image to every distribution point OSD clients can reach. A boot image that isn’t local means a slow WAN pull before the task sequence has even started.
• Re-distribute after every optional component or driver change. A stale boot image on a DP is a common, invisible cause of “OSD is slow at this site” tickets.

Frequently asked questions

Do I still need MDT for user state migration?

No. Capture and restore user state with USMT run natively through ConfigMgr OSD steps, no MDT wrapper required. See our USMT in ConfigMgr OSD guide for the full step-by-step.

Will removing MDT integration break existing task sequences?

Only if you delete the MDT package reference before replacing the steps that depend on it. Rebuild the affected steps with native equivalents first, test in a pilot collection, then remove the toolkit package. Treat it as a controlled change, not a flag flip.

Should I just move to Windows Autopilot instead?

Depends on your estate. Autopilot suits cloud-managed, internet-connected devices well. On-prem imaging, air-gapped networks and bare metal builds against local infrastructure still belong on ConfigMgr OSD. Plenty of organisations run both side by side. If you haven’t looked at Autopilot yet, our Windows Autopilot zero-touch deployment guide is a good starting point.

Is there a quick win if I only have time for one change?

Content pre-caching. It’s a configuration change, not a rebuild, and it removes the single biggest wait in most task sequences: downloading content live during the deployment instead of beforehand.