Introduction

An imaging migration can move Microsoft Deployment Toolkit to the new environment while boot media and deployment workflows still pull task sequences from the old share. Bare-metal deployment works on one subnet but not another, WinPE starts but fails later when the old server is removed, or technicians keep seeing the retired deployment path because boot images, deployment rules, and LiteTouch settings often remain unchanged after the backend move.

Treat this as a deployment-source problem instead of a generic MDT failure. Start by checking which deployment share path and server an affected boot image actually contacts, because migrations often validate the new MDT server itself while old boot media and task sequence settings still reference the previous share.

Symptoms

  • MDT deployment still pulls content from the old server after migration
  • WinPE boots successfully, but deployment fails when accessing task sequences or packages
  • One boot image uses the new share while another still uses the previous deployment path
  • Imaging fails only after the old MDT server is disabled
  • Technicians still see the retired server name during deployment
  • The issue started after moving MDT, deployment shares, or imaging infrastructure

Common Causes

  • Boot images still contain the old deployment share path
  • Bootstrap.ini or CustomSettings.ini still references the previous MDT server
  • LiteTouch media or PXE boot entries were rebuilt in one place but not another
  • Task sequence packages, scripts, or UNC paths still use the retired server
  • One technician workflow or site still uses older boot media
  • Validation confirmed the new MDT server worked but did not verify what server existing boot images actually contacted

Step-by-Step Fix

  1. Capture one affected deployment attempt and record the deployment share path, boot image, and server it actually uses, because the runtime WinPE source determines where task sequences and packages are pulled from.
  2. Compare that active deployment path with the intended post-migration imaging design, because one stale boot image or bootstrap rule can keep many deployments tied to the retired server.
  3. Review Bootstrap.ini, CustomSettings.ini, boot media, PXE publication, task sequence paths, and technician-run launch methods for references to the old MDT server, because imaging workflows often span multiple boot and configuration layers.
  4. Check USB media, PXE boot entries, and regional deployment points separately if behavior differs, because migrations often fix one imaging path while another still serves the previous share.
  5. Update the authoritative deployment-share and boot-image configuration so affected deployments use the intended MDT server, because copying deployment content alone does not retarget existing WinPE workflows.
  6. Run a controlled imaging test and confirm task sequences, packages, and logs come from the intended deployment share, because a successful WinPE boot does not prove the right backend handled the deployment.
  7. Verify the old MDT server no longer receives deployment traffic from migrated workflows, because split imaging paths can remain hidden while both shares stay accessible.
  8. Review driver injection, network initialization, and account permissions if deployment still fails, because the destination can be correct while WinPE networking or credentials still break content access.
  9. Document which team owns boot-image rebuilds, deployment-share publication, and migration validation so future MDT moves verify the actual server contacted by live imaging workflows before retiring the previous environment.