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.

1. The Update group has the updates all showing as "downloaded"
2. I have a report query that matches the updates to the "GUID" subfolder so I know all the content is there
3. I distribute the content from the CAS. Distrmgr.log shows all is good. Packagemgr.log on the Primaries show all is good
4. 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.

This problem sound like you should be contact CSS directly. They can work with you to solve this problem.

yup, already got a call in. Just thought it worthwhile asking the larger community in the hope someone else had any ideas.

yup, already got a call in. Just thought it worthwhile asking the larger community in the hope someone else had any ideas.

As a general recommend it is a bad idea to preform two different tests at the same time. So doing testing with CSS and a second set of tests based on replies here not a good thing. As they may conflict with each other.

never fear, it's not an issue as I haven't got tests from either yet, but once I start dealing with MS I'll work through it with them before trying anything else.

Past experiences though shows it always helps to have a couple of extra suggestions handy to work through with CSS as well. ;)

First impressions after discussing with Microsoft is that there may be an issue with the Update Sync and Distribution Manager.

At some point when the Windows Update sync runs, it performs a "cleanup" of orphaned update content. For example removing old Endpoint Definitions files.

It looks like it is identifying some of the content in my Windows Update package as "orphaned" and deleting it. When Distmgr then runs to deploy that package to a new DP, it fails because of the missing update content.

So it looks like

1. Wsync doesn't recognise that the content is still in use and tries to delete it. (appearing in wsycmgr.log as "Deleted xx orphaned content folders in package ABC000C0 (Microsoft Updates)")

and/or

2. Distmgr isn't aware that the content is no longer valid because it hasn't been cleaned out of the distribution package and tries to distribute it. (Appearing in distmgr.log as "The
source directory
\\[servername]\source$\MicrosoftUpdates\037b4d1e-d3ca-418a-9967-21ed57a3e2d7
doesn't exist or the SMS service cannot access it, Win32 last error = 2")

The update content it is deleting mostly appears to be superseded updates (not expired), but not all are. all updates are still actively deployed and are being installed by clients.

Investigations continue...

• Edited by Scott Williams - IP1 Wednesday, October 01, 2014 5:08 AM

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

1. Make sure you run a "migrate changes" job whenever you make changes to updates on your source hierarchy to keep them in sync
2. 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)
3. Create a scripted method to schedule regular migration jobs between the hierarchies (looking into this option now)

• Marked as answer by Joyce LMicrosoft contingent staff, Moderator Friday, October 10, 2014 8:45 AM
• Edited by Scott Williams - IP1 Saturday, October 11, 2014 6:04 AM

Hi Everyone,

Does anyone created the script for this issue already? Or resolution from MS has been sent already for this issue? I am encountering the same issue on SCCM software updates :(

Thanks in advance,

Khristian

Even with scripts or automation you will still need to create two different source locations for each hierarchy. The cleanup tasks that runs and deleted the content can't be disabled, so the risk that one hierarchy will delete content the other still expects to exist will continue.

My approach is to just do everything twice. It only adds a few extra minutes of effort so not something I've taken the time to automate as yet.