Track SCCM Software Update patch deployment through client log flow
In this post I will be discussing on how to track SCCM software update patch deployment through client log flow. Patch management is a complex process which consists of various components such as Windows Update Agent, Software Update Agent, Software Update point and others.
To understand it further, I am here demonstrating you deploying software update to Windows 10 devices. I will be discussing the log files involved in patch management process at client side. Sequence of log flow for Software Update and then Analysing the logs.
Troubleshooting software update issues using logs could be intimidating, this is the purpose of this post to help you out. Tracking SCCM application deployment is much easier as compared to Software Update issues; you can check the link Track SCCM application deployment through client log flow which will eventually give you confidence coming to this post. Or you can check much easier log flow for tracking sccm package deployment.
Log files involved in Software Update using SCCM.
Software Update deployment to workstations / servers creates multiple log files. If we understand each component responsible for these log files and the flow, it will make our life easy for troubleshooting software update issues.
Software update log files on client (workstation or server) is saved at c:\windows\ccm\logs (this is the default location to store SCCM logs). Following are the log files:
PolicyAgent.log
ScanAgent.log
UpdatesStore.log
UpdateDeployment.log
Wuahandler.log
UpdatesHandler.log
LocationServices.log
CAS.log
ContentTransferManager.log
DataTransferServices.log
Though there are more log files involved in whole process, but majorly you will be able to troubleshoot majority of issues using above mentioned log files.
Sequence of log flow for Software Update Deployment
The key for troubleshooting issues related to patches deployed via SCCM relies on understanding the workflow of the logs. Hence, let me demonstrate you deploying multiple patches to Windows 10 devices and then we will monitor the progress of the installation.
I have deployed few patches which are part of following Software Update Group “Software Update Group – 2022-11-21 12:08:00 AM”. Software Update group is collection of multiple patches combined in a single container which is deployed to a specific collection.
Make note of CI Unique ID for the Software Update Group, initial 5-6 characters are enough for troubleshooting to check into the logs (step 2 mentioning FF4F967B..). If you can’t see CI Unique ID, then right click any column and enable “CI Unique ID” column.
In below pane (Step 3) – you can see I have deployed to a specific collection. We need Deployment Unique ID. Once again, if you can’t see this column, enable it by right clicking below pane (column) and selecting it. Here, Deployment Unique ID is starting with {46CE010E..}.
Double click Software Update group to see list of updates targeted. We can see there are 2 updates, for us important thing is to see Title and its Unique Update ID, both are important to look into the logs.
Check the logs at client side now.
Login to windows 10 device where we have targeted the update and launch Configuration Manager through control panel and initiate Machine Policy retrieval & Evaluation Cycle or else policy will be downloaded in next 1 hour..
PolicyAgent.log – This log file will show downloading of Software update deployment policy. While looking into the logs, I can see my CI Unique ID policy got downloaded which starts with FF4F977B.
Compiling policy 'ScopeId_A01E8F68-CD81-4C08-80FA-477C0E10623B/AuthList_FF4F967B-948E-4F99-9412-146EEB15C489/VI' version '3.00' hash 'SHA256:E64D3B29108E923EF1F616279BF60723F9A59713C4A6A2198BF1723A0D19A07C' from 'SMS:MAN' (2022-11-29 10:03:43.740)
[PolicyBodyDownload] Adding 3 policies to the queue.
[PolicyBodyDownload] Downloading some policies directly
Raising event:
instance of CCM_PolicyAgent_PolicyDownloadSucceeded
{
ClientID = "GUID:abab5bc4-48fe-47a1-a44e-4b888858264e";
DateTime = "20221129100652.108000+000";
DownloadMethod = "BITS";
DownloadSource = "http://<mp>/SMS_MP/.sms_pol?ScopeId_A01E8F68-CD81-4C08-80FA-477C0E10623B/AuthList_FF4F967B-948E-4F99-9412-146EEB15C489/VI.SHA256:E64D3B29108E923EF1F616279BF60723F9A59713C4A6A2198BF1723A0D19A07C";
PolicyNamespace = "\\\\.\\ROOT\\ccm\\policy\\Machine\\RequestedConfig";
PolicyPath = "CCM_Policy_Policy5.PolicyID=\"ScopeId_A01E8F68-CD81-4C08-80FA-477C0E10623B/AuthList_FF4F967B-948E-4F99-9412-146EEB15C489/VI\",PolicyVersion=\"3.00\",PolicySource=\"SMS:MAN\"";
ProcessID = 5984;
ThreadID = 12176;
};
ScanAgent.log – As the policy is downloaded, Scanning comes into pictures. Windows Update Agent needs to scan against WSUS regarding what updates are installed vs missing. LocationServices.log will help finding the WSUS server (Software Update point) and once scanned, it will show the info of required updates. I can see it returned scanning completed and 2 major info related to updates CI Unique ID ie.:
- Update:08f5fb90-8bbe-438b-ab6d-bc468cb5f36e
- Update:98022d2e-3e1d-4251-be08-d181834abb7f
Once completed, scanning information can further be found in wuahandler.log,Updateshandler.log and others, more on it later.
*****ScanByUpdates request received with ForceReScan=0, ScanOptions=0x00000008, WSUSLocationTimeout = 604800
Found CategoryID of :b3c75dc1-155f-4be4-b015-3f1a91758e52 for Update:08f5fb90-8bbe-438b-ab6d-bc468cb5f36e
CScanAgent::ScanByUpdates - Found UpdateClassification 0fa1201d-4330-4fa8-8ae9-b877473b6441 for Update:08f5fb90-8bbe-438b-ab6d-bc468cb5f36e
Found CategoryID of :b3c75dc1-155f-4be4-b015-3f1a91758e52 for Update:98022d2e-3e1d-4251-be08-d181834abb7f
CScanAgent::ScanByUpdates - Found UpdateClassification 0fa1201d-4330-4fa8-8ae9-b877473b6441 for Update:98022d2e-3e1d-4251-be08-d181834abb7f
UpdatesStore.log – Scanning results of scanagent component is stored under UpdatesStore Component. Treat it like a database storing the information of all the updates in WMI store. I can see the updates status showing as missing.
Queried Update (08f5fb90-8bbe-438b-ab6d-bc468cb5f36e): Status=Missing, Title=2022-11 Cumulative Update for Windows 10 Version 20H2 for x64-based Systems (KB5019959), BulletinID=, QNumbers=5019959, LocaleID=, ProductID=b3c75dc1-155f-4be4-b015-3f1a91758e52, UpdateClassification = 0fa1201d-4330-4fa8-8ae9-b877473b6441, ExcludeForStateReporting=FALSE
.Queried Update (98022d2e-3e1d-4251-be08-d181834abb7f): Status=Missing, Title=2022-11 Cumulative Update for .NET Framework 3.5, 4.8 and 4.8.1 for Windows 10 Version 20H2 for x64 (KB5020686), BulletinID=, QNumbers=5020686, LocaleID=, ProductID=b3c75dc1-155f-4be4-b015-3f1a91758e52, UpdateClassification = 0fa1201d-4330-4fa8-8ae9-b877473b6441, ExcludeForStateReporting=FALSE.
UpdatesStore component stores this information in WMI and I found this PowerShell command very useful to get the information of update in easy-to-read format. Run this command with elevated rights:
Get-CimInstance -Namespace root\ccm\softwareupdates\updatesstore -ClassName CCM_UpdateStatus | select Title, UniqueID, ProductID, Status
This is such a wonderful command. Kindly make a note of it or save it somewhere. This has helped me so many times while troubleshooting the updates issue to find the patch status on client side whether it is Installed or missing, to check the update status.
UpdateDeployment.log – I would consider it a master log file for monitoring the updates downloading, installing and all other status. Once the deployment executes and scheduled time has passed, it will initiate the installation. If you launch Software Center, you will see the status “Pass due – will be installed” which means you have crossed the deadline time of update, and it will initiate the installation soon.
When Deadline is reached, scanning happens again means scanagent & UpdatesStore component kicks in again. But this time UpdatesStore.log will show more information, It will show CI Unique ID, Patch Title and the location of the update.
As you can see updatesstore.log is showing me the CI Unique ID along with the source location of update. Updates under software update group can belong to different packages also. Each update itself is considered as a self-independent package which could either be part of 1 deployment package or different deployment package. Hence SCCM client needs to find the location of each content and its DP.
Updatesdeployment.log will contain all the information of the deployment group, its updates along with installation status:
Update (Site_A01E8F68-CD81-4C08-80FA-477C0E10623B/SUM_98022d2e-3e1d-4251-be08-d181834abb7f) Name (2022-11 Cumulative Update for .NET Framework 3.5, 4.8 and 4.8.1 for Windows 10
Update (Site_A01E8F68-CD81-4C08-80FA-477C0E10623B/SUM_98022d2e-3e1d-4251-be08-d181834abb7f) Progress: Status = ciStateDownloading, PercentComplete = 0, Result = 0x0
Update (Site_A01E8F68-CD81-4C08-80FA-477C0E10623B/SUM_08f5fb90-8bbe-438b-ab6d-bc468cb5f36e) Progress: Status = ciStateDownloading, PercentComplete = 0, Result = 0x0
Update (Site_A01E8F68-CD81-4C08-80FA-477C0E10623B/SUM_08f5fb90-8bbe-438b-ab6d-bc468cb5f36e) Progress: Status = ciStateInstalling, PercentComplete = 75, DownloadSize = 0, Result = 0x0
IsRebootSetForScheduledUpdate - Scheduled update Site_A01E8F68-CD81-4C08-80FA-477C0E10623B/SUM_08f5fb90-8bbe-438b-ab6d-bc468cb5f36e - Job options = 0 RebootImmediately = False
And finally when the installation is completed you will get notification of “Your computer is about to restart”
UpdatesDeployment component relies on so many other components to get this job done, it just summarises everything in a neat and clean manner, but below log files are also very important.
Another handy PowerShell command which fetch the information of updates installed with its deadline status
Get-CimInstance -Namespace root/ccm/ClientSDK -ClassName CCM_SoftwareUpdate | Select-Object -Property Name,StartTime,RestartDeadline,UpdateID
UpdatesHandler.log– When scanning got completed using ScanAgent component, the information of update (CI Unique ID) gets updated in UpdatesHandler and this component provides the content source location of update, and passes this info to CAS.log (ContentAccess component)
CAS.log– ContentAccess component has 2 responsibilities:
1. To find the content location on DP: It will create ContentLocationRequest forLocationServices and instruct it to find the content location on DP based upon Boundary configuration.
2. To download the content from DP: Once 1st job of CAS is completed to locate the content, it will create CTM job for ContentTransferManager component to download the patch.
Once the download is completed, it will show the status as success and will pass on the information back to updatesdeployment.log. But for more details, you need to check locationservices.log and ContentTransferManager.log
Snippet from CAS.log
Requesting locations synchronously for content d37db1ec-42d4-4d13-9f4b-632029fd8465.1 with priority Medium
The number of discovered DPs(including Branch DP and Multicast) is 1
Calling back with the following distribution points
Distribution Point='http://SCCM01.MANBAN.COM/SMS_DP_SMSPKG$/d37db1ec-42d4-4d13-9f4b-632029fd8465', Locality='SUBNET'
**** Received request for content d37db1ec-42d4-4d13-9f4b-632029fd8465.1, size(KB) 0, under context System with priority Medium, persist duration 0
Submitted CTM job {B63652F0-023F-4582-AE45-4BEB7DAAA335} to download Content d37db1ec-42d4-4d13-9f4b-632029fd8465.1 under context System
Download {B63652F0-023F-4582-AE45-4BEB7DAAA335} started for content d37db1ec-42d4-4d13-9f4b-632029fd8465.1
Matching DP location found 0 - http://sccm01.manban.com/sms_dp_smspkg$/d37db1ec-42d4-4d13-9f4b-632029fd8465 (Locality: SUBNET)
LocationServices.log : This is the component responsible for locating the content on Distribution points. The job created by CAS to locate the content has to be fulfilled by locationservices. This component is also responsible for finding the location of WSUS ie. Software Update Point location which is required for scanagent.log
Created and Sent Location Request '{1475786F-99CB-4658-8A7E-634F9E87B041}' for package d37db1ec-42d4-4d13-9f4b-632029fd8465
Distribution Point='http://SCCM01.MANBAN.COM/SMS_DP_SMSPKG$/d37db1ec-42d4-4d13-9f4b-632029fd8465', Locality='SUBNET', Version='9088', Capabilities='<Capabilities SchemaVersion="1.0"><Property Name="SSLState" Value="0"/></Capabilities>', Signature='http://SCCM01.MANBAN.COM/SMS_DP_SMSSIG$/d37db1ec-42d4-4d13-9f4b-632029fd8465.1.tar', ForestTrust='TRUE', BlockInfo='0'
Called back with 1 locations for location request {1475786F-99CB-4658-8A7E-634F9E87B041}
ContentTransferManager.log : As CTM Job was created by CAS.log component, ContentTransferManager will download the content using location available on DP. This component will further create DTS Job for DataTransferServices Component, and once content is downloaded, it will hand over to CAS, CAS to updatesdeployment.log – like a hierarchy.
CTM_StartJob – Starting CTM job {383B17CA-200F-4638-8343-7E5CDBF3CBCD}
CTMJob({383B17CA-200F-4638-8343-7E5CDBF3CBCD}): CCTMJob::_DownloadContent – Created corresponding DTSJob({39535631-3BA6-4956-B81D-4548686A773A})
CTMJob({B63652F0-023F-4582-AE45-4BEB7DAAA335}): CCTMJob::ProcessProgress – entered phase CCM_DOWNLOADSTATUS_DOWNLOADING_MANIFEST
DataTransferServices.log DataTransferServices will do the actual download using either SMB or BITS.
DTSJob({39535631-3BA6-4956-B81D-4548686A773A}): state changing from ‘RetrievedManifest’ to state ‘PendingDownload’.
DTSJob({39535631-3BA6-4956-B81D-4548686A773A}): state changing from ‘PendingDownload’ to state ‘DownloadingData’.
DTSJob({39535631-3BA6-4956-B81D-4548686A773A}):CDTSJob::JobTransferred – Successfully completed download.
Wuahandler.log : This is a short and precise log file which could be treated as companion to UpdatesDeployment.log but just shows summary of update Wua agent scanning started, completed along with updates installation triggered with 1 liner and got installed. It will also show you if reboot is required for that specific update or not.
Async searching of updates using WUAgent started.
Successfully completed scan.
Going to search using WSUS update source.
Synchronous searching of all updates started...
Successfully completed synchronous searching of updates.
1. Update: 08f5fb90-8bbe-438b-ab6d-bc468cb5f36e, 200 BundledUpdates: 1
Update: d37db1ec-42d4-4d13-9f4b-632029fd8465, 200 BundledUpdates: 0
1. Update (Missing): 2022-11 Cumulative Update for Windows 10 Version 20H2 for x64-based Systems (KB5019959) (08f5fb90-8bbe-438b-ab6d-bc468cb5f36e, 200)
2. Update (Missing): 2022-11 Cumulative Update for .NET Framework 3.5, 4.8 and 4.8.1 for Windows 10 Version 20H2 for x64 (KB5020686) (98022d2e-3e1d-4251-be08-d181834abb7f, 200)
Update 1 (08f5fb90-8bbe-438b-ab6d-bc468cb5f36e) finished installing (0x00000000), Reboot Required? Yes
Update 2 (98022d2e-3e1d-4251-be08-d181834abb7f) finished installing (0x00000000), Reboot Required? Yes
RebootCoordinator.log : This component is responsible to show you the countdown of restart based upon grace period you have specified in Client agent settings for Software Update. We are getting notification because I haven’t suppressed the reboot while deploying the updates. Suppressing the restart will not give this notification.
The client is instructed to enforce reboots. Including grace period 21600 seconds, the system restart turnaround time is 22200 seconds Including grace period 21600 seconds, the system restart turnaround time is 22200 seconds Scheduled reboot from agent UpdatesDeploymentAgent. Deadline local time: 11/29/2022 10:48:26 PM, PreferredRebootWindowType = 4 System reboot request succeeded. Reboot initiated
As you can see the notification is appearing in bottom right corner which can’t be closed. This option is coming on behalf of following setting:
Launch Configuration Manager console and navigate to \Administration\Overview\Client Settings, open existing client settings. Under Computer Restart, I have specified:
“Specify the amount of time that a user is presented a final countdown notification before a device get restarted (minutes)” as 359.
This is close to 6 hours, this can irritate user for 6 hours before restart occurs automatically, I think this is a good option because users will be having ample amount of time to restart their PC before that before complaining the SCCM team that update restarted automatically (15 mins default behaviour).
While this setting controls the Deadline, which means after patch installation it will restart after this much minutes “Specify the amount of time after the deadline before a device gets restarted (minutes)”
Conclusion I hope this blog post solves the purpose of your troubleshooting and understanding the patching related work flow. Let me know if you have any query, or something not clear to you.
