ConfigMgr 2012 Update Source content deleted

Question

Greetings,
I am experiencing a problem that is appears to be the same as the old thread here:
http://social.technet.microsoft.com/Forums/en-US/bee18ffb-f779-4aa4-900d-046e7711424c/sccm-2012-source-content-gets-deleted?forum=configmanagergeneral
Rather than revive an old post, I thought it best to start my own.
We have a rather large environment (CAS +5 Primaries + Many DP's) and we are currently adding several new remote DP's each week. Each time a new DP is added it is placed in a Distribution Group and the "core" package content is sent
to it.
I have a problem where my Windows Update Packages keep failing due to content disappearing from the source folder location. This started some time ago, and is now becoming a regular event to correct. Not every day, but once a week or so.
The Update group has the updates all showing as "downloaded"
I have a report query that matches the updates to the "GUID" subfolder so I know all the content is there
I distribute the content from the CAS. Distrmgr.log shows all is good. Packagemgr.log on the Primaries show all is good
Client have been installing the updates as expected so the deployment does work
Days/weeks later, ALL the DP's will show as "failed" for that update package. Checking the distmgr.log shows that it is failing to distribute due to a missing source folder. I use my query to work out which update that subfolder GUID belongs to,
but it is already flagged as downloaded, and when trying to download it again CM just "skips" it thinking it already has the content in that package.
The "fix" is to download the same update to a new package instead. CM then does a proper check, realises it doesn't have the content and will download the update to the new package source location. I can then copy the missing GUID subfolder
from the new package into the original package and try the distribution again.
The problem now is that there are usually many folders missing, so distmgr.log will fail again on the next missing folder. Because it stops at the first error, repeating the above process is incredibly tedious when there are a lot of missing folders.
My current "solution" is to select ALL the updates that should be in the current package and download them all to a "Temp package" that isn't deployed or distributed anywhere. Then in future when the main deployment package fails, I just
"select all, copy" the contents of the temp folder into the original folder (skip duplicates) and it puts back all the missing content and distribution will work again.
We are not using ADR's for this content, although I do have an ADR for the Endpoint updates which go into a completely different distribution package.
*Something* is cleaning up or purging these folders from the source location, but I have no idea what process or mechanism this might be.
Any thoughts or suggestions most welcome.
Scott.

Answer 1

I've found the cause, blog post write here:
http://kickthatcomputer.wordpress.com/2014/10/11/configuration-manager-update-source-content-being-deleted/
Microsoft was working with me trying to identify what was deleting the folders, however nothing was appearing as the cause.
I just realised this morning that I had used the built-in CM12 Migration function some time back to migrate update packages and groups over to our second hierarchy but hadn't updated any of the migrated content since then. The migrated packages on the second
hierarchy still point to the same source location and so whenever my original hierarchy added content to the update packages, the second hierarchy would delete it because it though it was "orphaned" content.
This is something people will have to watch out for when using the migration wizard as the same type of issues will impact things like WIM boot image packages as well where the source content can be manipulated directly by the CM12 system on one hierarchy
without the other one being aware of that change.
At the moment the options are to either
Make sure you run a "migrate changes" job whenever you make changes to updates on your source hierarchy to keep them in sync
Manually make a copy of the source content to a different folder or location, then update the package source location on the migrated packages to point to that new content (undesirable for massively large content)
Create a scripted method to schedule regular migration jobs between the hierarchies (looking into this option now)