Configuration Manager Update source content being deleted

Posted: October 11, 2014 in Configuration Manager, System Center, Windows Update
Tags: , , , ,

[Place holder post – FULL POST write up coming shortly]

https://social.technet.microsoft.com/Forums/en-US/3ac88d59-d1b5-4826-a44d-bb94bfd80f66/configmgr-2012-update-source-content-deleted?forum=configmanagergeneral#39c42c3c-d3af-4362-b097-09c022adc86b

An issue where some source folder content of Windows Update deployment packages is deleted for no apparent reason.

Currently waiting for a response from the Microsoft ConfigMgr Product team on if they feel this is an issue worthy of a product update or just a TechNet article warning of the impact

Summary: issues relating to Update deployment packages that are migrated between ConfigMgr hierarchies that share the same source folder location. Automated “orphan cleanup” process will delete content from the folder if one of the hierarchies doesn’t need it, even it the other one still does.

Advertisements
Comments
  1. Hi , I have the same issue .. Do you have any update on this ?

    • Scott says:

      Hmm, I thought I had updated this post. The link to the technet forums has a post describing the problem so check that out. Essentially it happens if there are two different systems referencing the same content source location. When one system performs an automated “cleanup” it will cause the other to break because content it was still expecting to see has been deleted.
      Essentially, it is “by design” and Microsoft have no plans to change this behaviour. So if you are migrating content or running multiple ConfigMgr systems, make sure they are using their own copies for the source content and not sharing.

  2. Kyle says:

    So still the best solution is to have different content source for each site? We are facing the same issue.

    • Scott says:

      Yes, if you have multiple stand alone primaries doing their own sync then they need their own content source. Once I understood the mechanism it makes sense how it works, but that is by design and not going to change. What sort of setup are you using that you have this issue? Prod and Dev trying to share content?

  3. Kyle says:

    I have two standalone sites sharing the contents from same location. The source files and folder getting deleted every day. As a test, I tried changing couple of application packages with different source location yesterday. I just noticed today they got removed anyway. I have no maintenance task enabled to delete any old aged content. Still can’t stop this. Thanks

    • Scott says:

      This issue is specific to software updates, application content should not be seeing this issue.
      Maintenance takes are just for the data in the database related to machine inventory etc, none of them will be deleting source file content

      Maybe something else to check for is do you have data deduplication enabled on the content source folders or some other non-configmgr related processes running?

  4. Kyle says:

    It is happening to the application contents though i already removed the migration tasks in new site. Thanks Scott. I checked but no dedub enabled either.

    • Scott says:

      You seem to have some other odd issue happening. The Migration tasks don’t move or change source content at all. If you are seeing application and package source content changing then there must be some other process happening. I can’t think of any ConfigMgr related activities that would change the source content in the way you are describing.

  5. Kyle says:

    I will check around. Thanks Scott.

  6. Sean Bradley says:

    Scott just to clear something up here…we are having this issue with one of our parent sites. I have a CAS and 11 Parent sites (I do not have enough words to explain why…lol) But this issue is happening to one of our parent sites and that is it. The parent site is the only site using that update content folder. We are working through some other issues about servers not receiving updates since April of 2015…but I think that has to do with pre-reqs not being there…but again another story…lol.

    So this parent site if we download the updates and create the packages and push em out…a couple days later the folder is cleaned up as an orphan…but to my knowledge nothing was migrated for this site…everything is brand new and they are just dabbling in security updates now.

    So is there something I can check?? or test to see why it is happening with only that parent site and none of the other 10??

    • Scott says:

      Are you creating the Update packages at the CAS, or at each Primary? I would suggest you create all your update packages at the CAS and distribute from there.
      Is the whole folder is cleaned, or just some content from it? You will need to identify what process is doing that. Is it ConfigMgr, is the content expired updates, do you have Data Deduplication and some overly zealous anti-virus running?
      I don’t know what you mean in reference to things being “migrated for this site”.

      ConfigMgrs “auto-cleanup” process will show in the wsyncmgr.log with entries saying “Deleting old expired updates…”, “Deleted xx expired updates” and “Deleted xx orphaned content folders in package” so you could check there as a first step.

  7. Sean Bradley says:

    Are you creating the Update packages at the CAS, or at each Primary?
    –Each Primary site has it’s own admins…so they handle creating their own update groups and deploying updates.

    Is the whole folder is cleaned, or just some content from it?
    –In this case right now the whole folder has been cleaned twice.
    \\\UpdateServicesPackages\Server2012_August_2016
    Was there….and then the Server2012 folder was gone….anything underneath UpdatesServicesPackages is empty.

    Is it ConfigMgr, is the content expired updates, do you have Data Deduplication and some overly zealous anti-virus running?
    –not sure what is deleting…the log file that normally shows orphaned folders being cleaned up (wsyncmgr.log) shows orphaned folders being deleted…but does not always match what the folder name was according to the Parent Site’s admin. No AV currently installed on the box.

    I don’t know what you mean in reference to things being “migrated for this site”.
    –Sorry…previous posts have mentioned that if you migrated from 2007 to 2012 in this post…

    https://social.technet.microsoft.com/Forums/en-US/3ac88d59-d1b5-4826-a44d-bb94bfd80f66/configmgr-2012-update-source-content-deleted?forum=configmanagergeneral

    A comment from that site…
    “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.”

    ConfigMgrs “auto-cleanup” process will show in the wsyncmgr.log with entries saying “Deleting old expired updates…”, “Deleted xx expired updates” and “Deleted xx orphaned content folders in package” so you could check there as a first step.
    –As noted above, it is where I thought to start and it mentioned orphaned folders deleted…but these are updates from August, so none of them will be that expired or superceded. We even tried with September updates last month…and same thing.

    • Scott says:

      Hmm. While I am curious about why having so many primaries was a requirement rather than using RBAC permissions, that is probably a discussion for another day

      Under the “root” folder, the subfolders themselves are being deleted, not just the GUID named folders in the package source directory? To the best of my knowledge there is no reason Configmgr would be doing this itself.

      My first thoughts:
      1. Someone is deleting the folders or update packages (entirely by mistake of course)
      2. Check if there are any update packages or anything other packages that reference that root folder (Updateservicespackages) by mistake instead of the subfolder beneath it
      3. Check there is no admin from another site using the share on that server by mistake

      To identify who/what is deleting the folders, grab the sysinternal procmon tool and filter it to the folder you store the package source files. That should help narrow down the culprit. If you can’t figure out how to get that working let me know and I’ll give you specific steps to try.

      Other than some very odd misconfiguration possibilities, I can’t think of any specific process that would have this behaviour.

  8. Sean Bradley says:

    Yea you can definitely be curious…the idea was to have everything separate for each region…instead of all in the same server but with certain permissions. I inherited it…so what can I say, lol.

    The only line I can find in the wsyncmgr.log that mentions deleting things…is the following
    Deleted 1 orphaned content folders in package SHR00036 (SHR – Windows Servers All Previous Update). This is for site SHR but the package ID is what I believe to be an old one not being used for any new software update groups (I am following up with the techs in the region for sure)

    So when that happens…when the folder is deleted it goes from
    \\\UpdateServicesPackages\Aug_2012\ (with many GUIDS below it for the updates downloaded)
    to this
    \\\UpdateServicesPackages\
    No more subfolder…so it is not just deleting an individual GUID…but the whole Aug_2012 folder

    I thought the same thing about someone deleting them…but there are only two and I am starting to trust they did not…lol.

    No other admins have access to their site’s share…so we are good there.

    I have them checking into the package ID that does match the orphaned content folder being deleted from the logs to see if we can delete it and re-download one of the other software update groups and create a new one and see what happens.

    I will hold off on the procmon route for a bit.

    • Scott says:

      Procmon is really the easiest way to work out the culprit. It doesn’t install anything on the machine or do anything to it. You just run as admin and away you go.

  9. Sean Bradley says:

    So far it has been 5 days after recreating all the software update packages….and we are still showing all the updates in the folder…

    No culprit yet. lol.

    Much appreciate the replies and I look forward making this a regular pit stop during my day. ( I have already added another comment with some trickery…)

  10. Marcus Robinson says:

    Any resolution on this?

    • Scott says:

      I really do need to get around to writing something more for this post, but look through the comments where I have discussed some more details.
      Essentially, the resolution (in my situation) is to not use the same folder location as the source for packages on different ConfigMgr servers.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s