This is the Software Update Point Troubleshooting page in the Configuration Manager 2007 section of the System Center WIKI at System Center Central.
The following information was submitted by Dominik Heinz.
General Concepts
-
WSUS Infrastructure: 4
-
SCCM Update Deployment: 4
-
Update Installation Process: 4
-
In Detail: 5
-
Compliance Scan on Client 6
Possible issues. 7
-
Downloaded updates cannot be stored within the cache. 8
-
Troubleshooting steps: 8
-
General information about the cache: 9
-
Updates fail to install 10
Appendix. 12
-
Links. 12
-
Clear Cache Script: 13
· The WSUS infrastructure is ONLY used for compliance scanningThe WU Agent on the client is only used for compliance Scanning
· The SCCM server manages the WSUS Server service. To accomplish this, SCCM connects to the WSUS dlls using a proprietary API called Software Update Point. In order to provide the needed WSUS dlls, you must install at least the WSUS admin console on the SCCM server and the WSUS server service on the server running the SUP role.
· The WSUS service needs internet access to download the Microsoft update metadata calatogue. The WSUS service will not download any update binaries.
· As soon as the SCCM Server is connected to the WSUS service and the WSUS service has finished synchronizing against Microsoft Update, the SCCM server synchronizes every single update found into his database as “configuration items” CIs
· For update deployment, mainly standard SCCM Software Distribution processes are used.
· Updates are stored within standard SCCM packages. You can use several packages for different updates or store a bunch of them or even all of them within a single package.
When a bunch of updates get advertised onto a target collection, the updates are first scanned for compliance prior to downloading the patch. The compliance scan is done using the configuration items mentioned above.
If the advertised update is detected as being applicable, it will be downloaded to the local cache and installed.
- A new deployment is created in the Administrator console.
- The Site Server requests the software updates binaries from the source location defined in the deployment. This can be from Microsoft Updates or from a local source.
Note: The software update binaries are stored temporarily in a folder on the site server.
- The Site Server copies the software update binaries to the package share on the Distribution Point.
The Site Server also adds the new software update deployment to the machine policy and copies the policy to the Management Point.
- The client pulls the machine policy from the Management Point on the schedule and receives the new deployment information.
The client then scans for each software update to verify that they are still required.
- If the software update is still required, the client requests the binaries from the Distribution Point for each mandatory update and stores them in the local cache.
Note: Optional updates are downloaded at the time of install.
Note: Selective download is used so only the binaries for the required updates are downloaded to the client.
- The client sends a state message to the Management Point reporting that the software update was downloaded and the Management Point forwards the state message to the Site Server, which then enters the message into the database.
- When the software update deadline arrives or the update installation is manually initiated, the client scans for each software update to verify that they are still required.
- The client installs the software update, scans for the software update using local rules to verify that the update is no longer required, and reports to the Management Point a state message that indicates the state of the deployment at completion. For each software update that fails to install, an error status message is sent to the Management Point. The messages are then forwarded to the Site Server, which then inserts them into the database.
- Note: If the software update is no longer in the local cache, it is downloaded again from the Distribution Point.
Compliance Scan on Client
- On the compliance scan schedule or when manually initiated, the client gets the WSUS server location from the Management Point (MP).
- The compliance scan is initiated on the client. The WSUS agent component on the client connects to the WSUS server and initiates the compliance scan.
The client returns a list of the updates that are Installed or Required.
Note: The site server will determine what updates are not required on each client by comparing the list of all defined updates with the scan results.
- WSUS stores the results of the scan in the WSUS database.
- The client stores the compliance scan results in WMI and sends the results as a batch to the Management Point, in the form of state messages.
- The Management Point sends the results to the Site Server and they are entered into the Site Database.
- The compliance scan data is available in the Software Updates – Compliance reports and in the Configuration Manager console.
Advertised updates are not downloaded
1. Make a copy of the folder “system32\CCM\Logs” and store it as a zip file for further investigation of the engineering team.
2. Check, if client is online (ping, heartbeat discovery)
3. Check, if client got the assigned policy. You can use the tool PolicySpy out of SCCM 2007 Toolkit.
4. Check, if download is showed in “download programs monitor”.
5. Check, if the client can access the DP used. The used DP can be found within the logfile “locationservices.log"
6. Look for log file “ContentTransferService.log” within “system32\ccm\logs”. The CTS log triggers the BITS service to download the updates from the distribution point. For more information about BITS refer to: http://technet.microsoft.com/en-us/library/dd759234.aspx
7. If you think, that BITS is not able to download the updates, you should use the tool “bitsadmin.exe” to check the BITS Q. The correct syntax would be “bitsadmin /list /allusers /verbose”. The BITS Q always shows a maximum of 10 items. If you think that the Q is stuck, you should run bitsadmin / reset.
Downloaded updates cannot be stored within the cache
1. Make a copy of the folder “system32\CCM\Logs” and store it as a zip file for further investigation of the engineering team.
2. Review Content Access Service log for errors. (system32\CCM\Logs\CAS.log) The content access service maintains the cache.
3. Check, if any of the update packages have the flag “persist content in client cache” set. If yes, remove the flag.
4. Check, if the client has the default Cache size of 5 GB: (setting is only viewable after activating “configure Settings”)
5. Check, if there is free disk space left.
6. Sweep client cache folder. If you want to delete the cache , please refer to the attached script.
General information about the cache:
If a program or update has been installed on the target machine, the source files are not deleted instantly out of the client cache.
The following properties are stored within the sitectrl file. (Do NEVER change the sitectrl file by hand!)
PROPERTY <Cache Failure Retry Count><REG_DWORD><><18>
PROPERTY <Cache Failure Retry Interval><REG_DWORD><><14400>
PROPERTY <Cache Tombstone Content Min Duration><REG_DWORD><><86400>
PROPERTY <Cache Content Timeout><REG_DWORD><><2592000>
If a package successfully installs, it gets tombstoned for deletion after 24 hours. If not, it gets by timeout tombstoned for deletion after 30 days.
In case your cache gets full within 23 hours the next package will fail.
1. Make a copy of the folder “system32\CCM\Logs” and store it as a zip file for further investigation of the engineering team.
2. Review log file execmgr.log within CCM\logs, to see, WHY the advertisement was not started. If the log shows, that the update package has the wrong version, maybe the package was changed and the advertisement from the last package version is still active. In this situation, the client would state the package to be the wrong version although it contains the needed files.
3. If the execmg and ccmexec are unable to run the files within the client cache the files maybe got corrupted or are missing signature. You could clear the client cache using the script and re-download the fixes.
4. Check for Errors within the important CCM log files:
a. UpdateDeployment.log – main updater process; triggers other components
b. UpdateStore.log – compliance of updates during scan phase
c. UpdateHandler.log – information about update installation process
d. WUAHandler.log – talks to the WUAserv
e. SDMagent.log – shared log with DCM. Shows information about update compliance. (check against CIs)
f. CIagent.log – remediation and compliance
5. Check for Errors within WindowsUpdate.log (from WUAserv)
6. If the patches are not installable at all, you can proceed with OS troubleshooting. On Windows XP/2003 the KBxxxxx.logs could help. On Windows Vista CBS.log should help.
Additional resources for troubleshooting a ConfigMgr 2007 Software Update Point
Links
List of known issues for Background Intelligent Transfer Service (BITS)
http://support.microsoft.com/kb/331716/en-us
List of Log Files in Configuration Manager 2007
http://technet.microsoft.com/en-ca/library/bb892800.aspx
Troubleshooting Software Updates Client Issues
http://technet.microsoft.com/en-us/library/bb932189.aspx
Troubleshooting Group Policy Configuration for Software Updates
http://technet.microsoft.com/en-us/library/bb735866.aspx
Scripts
Scripts that may be helpful in administering a ConfigMgr 2007 Software Update Point
Script: Clear Cache:
This deletes all cache elements and pinned elements (this is from the SDK):
Call EnumAndDelCache
Sub EnumAndDelCache()
On Error Resume Next
Dim oUIResManager
Dim oCache
Dim oCacheElements
Set oUIResManager = createobject("UIResource.UIResourceMgr")
If oUIResManager Is Nothing Then
wscript.echo "Couldn't create Resource Manager - quitting"
Exit Sub
End If
Set oCache=oUIResManager.GetCacheInfo()
If oCache Is Nothing Then Set oUIResManager=Nothing
WScript.Echo "Couldn't get cache info - quitting"
Exit Sub
End If
oCache.Location = path
WScript.Echo "Cache information " & oCache.Location
WScript.Echo "Location: " & oCache.Location
Wscript.Echo "Total size: " & oCache.TotalSize & " MB"
WScript.Echo "Free size: " & oCache.FreeSize & " MB"
WScript.Echo "Reserved: " & oCache.ReservedSize & " MB"
'WScript.Echo "Max Duration: " & oCache.MaxCacheDuration & " minutes"
' Wscript.Echo "TombStone Duration: " & oCache.TombStone.Duration & " minutes"
Set oCacheElements=oCache.GetCacheElements
WScript.Echo "There are " & oCacheElements.Count & " cache elements"
WScript.Echo
For Each oCacheElement In oCacheElements
WScript.Echo "Program Name: " & oCacheElement.CacheElementID
oCache.DeleteCacheElementEx oCacheElement.CacheElementID, true
WScript.Echo "Program Deleted!"
Next
Set oUIResManager=Nothing
Set oCache=Nothing
End Sub
The output looks like this:
C:\Users\Documents\Scripts>EnumAndDelCache.vbs
Microsoft (R) Windows Script Host Version 5.7
Copyright (C) Microsoft Corporation. All rights reserved.
Cache information C:\Windows\SysWOW64\CCM\Cache
Location: C:\Windows\SysWOW64\CCM\Cache
Total size: 5000 MB
Free size: 4999 MB
Reserved: 0 MB
There are 2 cache elements
Program Name: {422B5935-245D-4F5A-A417-6D532F216EDF}
Program Deleted!
Program Name: {C41E5F9C-2143-43EA-A0CE-5683251ECB44}
Program Deleted!
C:\Users\Documents\Scripts>EnumAndDelCache.vbs
Microsoft (R) Windows Script Host Version 5.7
Copyright (C) Microsoft Corporation. All rights reserved.
Cache information C:\Windows\SysWOW64\CCM\Cache
Location: C:\Windows\SysWOW64\CCM\Cache
Total size: 5000 MB
Free size: 5000 MB
Reserved: 0 MB
There are 0 cache elements