Missing Update Folder Within an Update Package

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 package((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.)) Now, however, there is 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:

[su_note note_color=”#ffcb05″]Snapshot processing content with ID 16816292 … SMS_DISTRIBUTION_MANAGER 1/26/2020 8:52:59 PM 5556 (0x15B4)
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 [/su_note]

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 returned 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.)