This week was a very busy and exciting one with the first edition of ITPROCeed taking place. All the effort put into the event by many paid off and the event was really a success – stay tuned for a short debrief somewhere next week.
In-between project work and the event preparations there were a few items that I did flag for further reading. Here they are outlined in this week’s review:
- Interesting article on the ConfigMgr blog on how the Configuration Manager Content Library manages disk space.
- Be aware that Configuration Manager 2007 will be out of mainstream support in a few weeks. More details in this article by Rod Trent on WindowsITPro.com.
- Peter Daalmans published two interesting articles: one on how to set user preferences in Mac OS X 10.x with ConfigMgr 2012 R2 and another one on how to set background of Mac OS X with ConfigMgr 2012 R2
- Pay attention when deploying the newly released Security Update KB2965788. It requires multiple reboots so it will fail when deployed in a Task Sequence. See KB2894518 for details about this issue with Task Sequences (and note that HB2965788 is not listed – yet).
See you next week!
Troubleshooting – How to pinpoint a problematic software update based on entries in UpdatesDeployment.log
Recently a customer of mine bumped into an issue when applying software updates during a Task Sequence. The first symptom that was noticed was that the task sequence was taking forever to complete. Looking further into this it turned out the task sequence step during which the updates were applied was running for a very long time.
Further investigation of the log files was required and an entry in the UpdatesDeployment log is pointing us into the right direction.
The status ciStateError indicates there is a problem with this specific update. After looking up the error code 87d00669 it indicated there might a problem with the content. The real challenge now is to find which update it actually is that is causing this problem. All we have on it right now is the ModelName (Site_ / SUM_) without any further information.
We figured that using the Get-CMSoftwareUpdate cmdlet would be the quickest and easiest way to gather some more information and tried the following command:
Unfortunately this is not the case. The command itself seems to take forever to run and on top of that we ended up with a warning indicating the result exceeded the maximum size. Using Set-CMQueryResultMaximum we could probably overcome this … but as we don’t have an hour or more to wait for results we need another solution.
In comes WMI. Using PowerShell to query WMI is really easy, but alternatively you could also use WBEMTest or a 3rd party utility. We’ll go for the Powershell approach and need the following information:
- The namespace in WMI (using site_ABC where ABC is the site code)
- The hostname of the SMS Provider
- The actual WMI Query
The actual command is shown in the screenshot below. The result is returned in a second and we immediately have the required information of our problematic Software Update. Based on the articleID, BulletinID and Display Name we can now troubleshoot further and ensure the update content becomes available.
Hope this saves you some troubleshooting time in the future!