Windows Explored

While browsing various reports for workstation compliancy, I noticed that several reports and/or updates failed to install on a large number of computers. Although we don’t expect complete 100% compliancy with thousands of workstation in our environment, there was some sort of mystery going on here because many of the updates that failed to install were along the same computers, i.e. they were not just random computers across the various reports. For example, below is a report for various updates that were missing from generally the same number of computers and computer names:

After some research in the CCM logs, I noticed a repetitive theme in the C:\Windows\SysWOW64\CCM\Logs\UpdatesDeployment.log: “Install not allow as another job is still in progress”:

Using the SCCM Client Center utility, we compared the time in the logs to the Advertisement > Execution History in the SCCM Client Center and saw nothing that was actually trying to install at that time. Out of ideas, I decided to delete root\CCM namespace (also accomplished with the SCCM Client Center utility) on a few of the problem workstations in the reports above. After a few minutes, I noticed the CCM Cache in C:\Windows\Syswow64\CCM\Cache was rebuilt, pulling several pending updates. The next step was to wait for the SCCM service windows to pass. The next day when I came in, I remotely checked the workstation Event Setup logs and saw that several (sometimes dozens) of various pending updates had successfully installed.

Knowing that we had a problem with the CCM namespace, I followed up with some more research. My digging around eventually led me to what might have been an update that was advertised to these computers but likely pulled before it could be deployed. Specifically, what I found was that each update gets an unique update ID. To the CCM agent, this property is known as the AssignmentID, which resides in the instance of the CCM_DeploymentTaskEx1 of the root\CCM\SoftwareUpdates\DeploymentAgent namespace. I went around to several workstation in the SCCM reports and ran wbemtest.exe and saw the same assignmentId(s) across all the computers in the reports:

Convinced this was culprit, I put together a script to query a few of the computer OUs in AD to get their assignment IDs. Looking at one of our larger offices, I saw specifically three assignmentIDs reported in the CCM_DeploymentTaskEx1 instance for all of the workstations not installing updates:

I compared the list of computers in the SCCM reports to the list generated by the script and saw practically a 1 for 1 match. On compliant computers, the assignmentID property was empty and I am guessing that this is the ideal state it should be in when no updates are being installed during the SCCM service window. To further verify my findings, I searched SCCM for the assignmentIDs above (You will need to add Unique Update ID to the SCCM console view) and could not locate any matches, confirming that at least 3 updates were pulled from SCCM but not before the CCM client saw the advertisement and (I am assuming) got hung up trying to get an update that was no longer being advertised.

Here is a sample script you can run against your computers in AD. Run it using cscript from the command line and pipe the results to a txt file. i.e. cscript.exe QueryCCMAssignmentID.vbs > C:\Logs\Query.txt

And this will delete the instance of CCM_DeploymentTaskEx1 if the AssignmentId has some value (obviously, this shouldn’t run during the SCCM service window).

Some references:

http://joshuasmueller.wordpress.com/2011/04/28/install-not-allow-as-another-job-is-still-in-progress/

http://blogs.technet.com/b/sudheesn/archive/2010/07/29/script-to-delete-a-wmi-instance-from-wmi-repository.aspx