I did some quick cleanup of the update packages in my lab the other day before running the Automatic Deployment Rules. Unfortunately, this appears to have deleted a source folder and distribution manager was all too happy to let me know that the update package1Update Packages are referred to as Deployment Packages in most places in the admin console, however, I refuse to refer to them as such as they have no direct connection to deployments in any way. Most of the built-in reports properly refer to them as Update Packages though. now had a missing update folder within its source location.
Here’s an excerpt of the relevant portion of the distmgr.log on the primary site server:
The source directory \\cm301.lab300.memftw.com\ConfigMgr\Content\Updates\AllWorkstationUpdates\88bb4359-0d2a-4a21-a055-4c7290ab1bf1 doesn’t exist or the SMS service cannot access it, Win32 last error = 2
Failed to take snapshot of one or more contents in package 30000021
So where to start with only a single, seemingly random ID of 88bb4359-0d2a-4a21-a055-4c7290ab1bf1 (the missing folder) which does not match the format of any IDs associated with updates as shown in the admin console? SQL Management Studio and a little bit of SQL of course.
Step 1: Find the Content ID
After a little bit of hunting around, I found a view associated with content that contained IDs that matched the format of 88bb4359-0d2a-4a21-a055-4c7290ab1bf1. A quick query confirmed this ID was in that view and was even associated with the package in question (30000021):
SELECT *
FROM vCI_ContentPackages
WHERE Content_UniqueID like '88bb%'
Step 2: Find the Update’s CI
The next step is to find the CI of the update associated with this content ID (16816292).
SELECT *
FROM v_UpdateContents
WHERE Content_ID = '16816292'
Step 3: Find the Update from the CI
Next, I found the actual update based on the two CIs returned.
SELECT *
FROM v_UpdateCIs
WHERE CI_ID = '16821322'
OR CI_ID = '16865076'
Step 4: Review the Update’s Details
The final part of the discovery process here was to click on the SDMPackageDigest for each row to show the XML that defines the CI. The second CI shown above is for the update group (which was easily deduced when I reviewed the XML). The XML for the first CI listed the update that I needed to re-download. Here’s an excerpt:
<DesiredConfigurationDigest xmlns="http://schemas.microsoft.com/SystemsCenterConfigurationManager/2009/07/10/DesiredConfiguration">
<SoftwareUpdateBundle AuthoringScopeId="Site_4AD729D7-A567-4F7A-85F6-C811A18D52E9" LogicalName="SUM_1ccbf8d2-e571-44a9-bbfe-b9bef824cd4a" Version="200">
<Annotation xmlns="http://schemas.microsoft.com/SystemsCenterConfigurationManager/2009/06/14/Rules">
<DisplayName Text="Update for Microsoft Silverlight (KB4481252)" />
Step 5: Delete the Update from the Package and Re-download
The final step here was to re-download the content for the update (KB4481252). Initially, I tried simply right-clicking on the update in the admin console, selecting Download, and then completing the download wizard. This doesn’t work because ConfigMgr thinks the update is already downloaded and so the wizard finishes successfully but without actually re-downloading the update. Thus, I opened the update package’s membership, selected the update, and deleted it from the package.
After deleting the update from the update package, I went back to the All Software Updates node, found the update, right-clicked on it, selected Download, and finished the download wizard. Once this finished, I updated the package on the lab distribution points and all was right with my update packages again. Don’t you love a happy ending? (I’m not going to link to a happy ending video here though as I’m afraid to search for that phrase.)
Footnotes
↑1 | Update Packages are referred to as Deployment Packages in most places in the admin console, however, I refuse to refer to them as such as they have no direct connection to deployments in any way. Most of the built-in reports properly refer to them as Update Packages though. |
---|
Thanks! this helped me out! But i didn’t do anything to clean out the updates, sccm must have done this on its own. Perhaps a race condition, whereby i deployed/distributed right around the time it was performing the new-to-current-branch wsus cleanup task… kinda troubles me it did it on its own.
Hard to say without digging in. There certainly are update cleanup tasks though.
Thanks so much for walking through this. It just happened to me and I couldn’t find any other references to anything remotely like a solution. I was able to find and correct the problem in one morning with your article.
You are very welcome.