Introduction

An update migration can move the primary WSUS infrastructure to the new environment while offline scan workflows still download CAB files or update metadata from the old source. Patch compliance checks fail in disconnected networks, task sequences still call the retired catalog location, or one maintenance workflow uses the new source while another still depends on the previous server because offline scan packages, scripts, and task automation often escape the main WSUS cutover.

Treat this as an update-content source problem instead of a generic patching failure. Start by checking which CAB URL, share path, or package source an affected offline workflow actually uses, because migrations often validate the new WSUS server for online clients while disconnected or scripted scans continue following older maintenance logic.

Symptoms

  • Offline scan workflows still download update CAB files from the old source after migration
  • Patch scans fail only after the old WSUS or catalog server is removed
  • One task sequence or maintenance script uses the new source while another still uses the previous one
  • Connected clients work, but disconnected or staged devices do not
  • Update automation still references the retired CAB location despite a successful WSUS migration
  • The issue started after moving WSUS, update catalogs, or endpoint maintenance infrastructure

Common Causes

  • Task sequences or scripts still reference the old CAB URL or UNC path
  • Offline scan packages were copied, but automation still points to the retired source
  • Golden images, maintenance shares, or USB media still carry older update-source references
  • One workflow was updated while another still uses the previous catalog location
  • Proxy or certificate settings make newer sources fail, causing fallback to the old server
  • Validation confirmed the new WSUS environment worked for online clients but did not verify what source offline scans actually used

Step-by-Step Fix

  1. Capture one affected offline scan workflow and record the exact CAB URL, file share, or package source it actually downloads from, because the runtime content path determines where disconnected update checks depend.
  2. Compare that active source with the intended post-migration update design, because one stale script variable or package path can keep maintenance workflows tied to the retired server.
  3. Review task sequences, maintenance scripts, offline scan packages, USB media, and scheduled jobs for references to the old source, because disconnected update workflows often bypass the main WSUS client settings entirely.
  4. Check each disconnected network, build pipeline, and technician workflow separately if behavior differs, because migrations often fix one offline path while another still distributes the previous catalog source.
  5. Update the authoritative scan-package and workflow configuration so affected maintenance tasks use the intended source, because moving the main WSUS server alone does not retarget offline scan logic.
  6. Run a controlled offline scan and confirm it downloads or reads the intended CAB source successfully, because online update health does not prove disconnected workflows are using the right backend.
  7. Verify the old source no longer receives requests from migrated offline maintenance tasks, because split update paths can remain hidden while both locations stay reachable.
  8. Review certificates, proxy access, and package freshness if scans still fail, because the destination can be correct while trust or stale media still breaks content retrieval.
  9. Document which team owns offline update packages, task sequences, and migration validation so future WSUS moves verify the real content source used by disconnected workflows before retiring the previous server.