Purpose: How to debug windows updates in SCCM – real-life examples
SCCM includes an integraded WSUS server in it. You can set this Software Update Point (SUP) to manage your environment windows updates. However, there most likely will some problems along the way, which an active admin will find himself struggling against. This post covers the usual problems seen from the client side.
|C:\Windows\WindowsUpdates.log||Windows Update Service -log|
|C:\Windows\CCM\Logs\ContentTransferManager.log||Download or access of SMS packages|
|C:\Windows\CCM\Logs\LocationServices.log||Finds MPs and DPs|
There might be one, two or three problems that could cause this:
|1)||No Content distributed to the DP||Find the software update, and make sure that the deployment package has been deployed to the DP or that there are no errors in the content distribution.|
|2)||There is no DP available for this workstation||Assign a Distribution Point for the Boundary or Boundary Group.|
|3)||There is no Boundary available for this workstation||Create a Boundary, Create or Join the Boundary to a Boundary Group. Make sure there is a Distribution Point assigned for the Boundary Group.|
Workstations that are stuck in a “Downloading 0%” state will resume the download after the content has been made available for them. If you cannot find a way to resolve this, you can delete the DEPLOYMENT and the next Machine Policy Cycle will remove from the Client Software Center the update that is stuck (and the other updates that were part of that deployment).
The possible stuck-percent can vary but if the update is stuck in some other value than zero, then the aswer is simple: a language version of this update is missing! The system has downloaded one of the three update languages (33%) and is waiting for the remaining two (66%) hat has not been enabled or downloaded or distributed to the Distribution Point.
In my scenario the situation was the following:
My update was downloaded in ENGLISH, and SWEDISH, but FINNISH was missing. This caused the update to hang at “Downloaded 66%” because EN and SV was downloaded, but the FI update was not enabled nor distributed at all. You need to enable the language, Synchronize SUP, Download the Updates, Distribute to the DPs (will happen automatically when set to download new content).
Workstations that are stuck in a “Downloading XX%” state will resume the download after the content has been made available for them. If you cannot find a way to resolve this, you can delete the DEPLOYMENT and the next Machine Policy Cycle will remove from the Client Software Center the update that is stuck (and the other updates that were part of that deployment).
Noticed, that the target system has FI-language enabled in it, and Office is using FI-language as default.
Need to enable the Software Update File in Finnish language as well in the site server SUP.
|ConfigMgr\Logs\PatchDownloader.log||Server downloading process|
|%UserProfile%\AppData\Local\Temp\3||Server downloading process|
Problem: When you set patches manually to download from the SCCM, you might end up in the following error message (12002). The error message translates from the log as 0x80072ee2 (The operation timed out [WINHTTP]). There does not seem to be any logical reason at the moment for this message, and could be environment specific. Each and every time the system started downloading SOME of the updates, but timed out before processing the full list.
Solution: Keep trying to download the patches, and finally the system manages to reach the end of the list. This only has occured when downloading a single patch that has a HUGE amount of available languages and MULTIPLE files for each language. Possible bug or WSUS configuration timeout setting?