~ Fuyu Jin
I 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
CAUSE
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.
RESOLUTION
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 onFacebookandTwitter:
System Center All Up: http://blogs.technet.com/b/systemcenter/
System Center – Configuration Manager Support Team blog: http://blogs.technet.com/configurationmgr/
System Center – Data Protection Manager Team blog: http://blogs.technet.com/dpm/
System Center – Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
System Center – Operations Manager Team blog: http://blogs.technet.com/momteam/
System Center – Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center – Virtual Machine Manager Team blog: http://blogs.technet.com/scvmm
Windows Intune: http://blogs.technet.com/b/windowsintune/
WSUS Support Team blog: http://blogs.technet.com/sus/
The RMS blog: http://blogs.technet.com/b/rms/
App-V Team blog: http://blogs.technet.com/appv/
MED-V Team blog: http://blogs.technet.com/medv/
Server App-V Team blog: http://blogs.technet.com/b/serverappv
The Forefront Endpoint Protection blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/