Support Tip: Some update files missing after migrating a ConfigMgr 2012 Software Update package

~ Fuyu Jin

ToolsI ran into an interesting issue the other day and thought I would share it here just in case anyone else happened to see it. The issue was that after migrating a Software Update package from one System Center 2012 Configuration Manager (ConfigMgr 2012) site to another, you find that some clients are no longer able to download certain updates from the original site. You will also notice that the software update package source folder is missing the same update files. Examining the Distribution Manager log (distmgr.log) will reveal a failure message similar to the one below.

The source directory \\server1\source$\PackageSource\MicrosoftUpdates\037b4d1e-d3ca-418a-9967-21ed57a3e2d7 doesn't exist or the SMS service cannot access it, Win32 last error = 2

In wsyncmgr.log on the destination site you will also see an entry similar to the following.

Deleted 181 orphaned content folders in package pkg1


This can occur if the Software Update package in each site shares the same software update package source folder and the WSUS synchronization manager cleanup task runs before migration is complete.


To resolve this issue, create a new, different software update package folder for the destination site server.

More Information

The typical scenario where you will see this issue is as follows:

1. Before the migration is complete, new updates are downloaded to the software update package on Site A. Because of these new updates, the ci_contentpackagestable on site A is updated with information about the new packages.

2. WSUS sync manager in Site B launches the scheduled cleanup task to remove orphaned content folders. It does this by comparing the ci_contentpackage table and the software update package source folder. Since the new updates do not exist in ci_contentpackagesfolder on Site B, but the updates exist in the shared software update package source folder, wsync manager will delete those folders as orphaned content folders.

3. Clients in Site A are notified that new updates are available but they will be unable to find the packages because they were deleted by the SUP in Site B.

Note that the cleanup task will run every hour, so even though you migrate the software update package data immediately to the destination hierarchy, the cleanup task may delete the orphaned content folders if the migration job does not complete within that one hour time period, causing the migration job to fail.

Fuyu Jin | Support Engineer | Microsoft GBS Management and Security Division

Get the latest System Center news on Facebook and Twitter:

clip_image001 clip_image002

System Center All Up:
System Center – Configuration Manager Support Team blog:
System Center – Data Protection Manager Team blog:
System Center – Orchestrator Support Team blog:
System Center – Operations Manager Team blog:
System Center – Service Manager Team blog:
System Center – Virtual Machine Manager Team blog:

Windows Intune:
WSUS Support Team blog:
The RMS blog:

App-V Team blog:
MED-V Team blog:
Server App-V Team blog:

The Forefront Endpoint Protection blog :
The Forefront Identity Manager blog :
The Forefront TMG blog:
The Forefront UAG blog:

Comments (3)
  1. Sean Bruck says:


    Unfortunately this solution above means no 2012 clients can use their shared 2007 distribution point(s), which can put a big strain on bandwidth. For example if you have hundreds of 2012 clients at a slow remote site using their local 2007 distribution point
    for all content, all those clients would have to download all their updates from a remote 2012 fallback DP over the WAN.

    It would be very helpful if there was a way to disable the orphaned content deletion in 2012. When my company ran into this issue package distribution came to a worldwide halt for days, because when the 2007 DPs were updated with some new content all the old
    content had been unknowingly deleted from source folder (but still there in the console), and thus had to be resent to hundreds of slow links around the world.

    One un-pretty workaround we have used is to explicitly deny rights for the 2012 service account to create/write/delete on the 2007 source folders. That, and try to finish migration asap 🙂


  2. gareth.douce says:

    Is the same thing for a migration from SCCM 2007 ?

  3. sunny says:


Comments are closed.

Skip to main content