ConfigMgr 2012 Windows Update Client Process
Hi Gang!
So I provided this information to one of my customers recently, and Georgy said it would be quite helpful for you dedicated ConfigMgrDogs readers too, so here it is.
This is a high-level view of the Windows Update process from a ConfigMgr clients view utilizing a SUP (Software Update Point).
The Software Update process from the ConfigMgr client
Following the flow
After refreshing machine policy, kick off the Software Update Scan. We can then see the Software Update Scan Cycle has started via the WUAHandler.log (C:\Windows\CCM\Logs\WUAHandler.log)
The Windows Update Handler initiates the Windows Update service against the ConfigMgr SUP. (C:\Windows\WindowsUpdate.log)
After the scan is completed, we then run the Software Update Deployment Evaluation Cycle. Use the UpdatesDeployment.log to view this process (C:\Windows\CCM\Logs\UpdatesDeployment.log)
The Content Access Service finds the content on the CMPRI-MATTSLABS Distribution Point and downloads it
Update Deployment attempts to install updates, Service Window Manager blocks the installation (C:\Windows\CCM\Logs\UpdatesDeployment.log)
Service Window Manager blocking the installation (C:\Windows\CCM\Logs\ServiceWindowManager.log)
And when the window opens, the updates should install. Check the UpdatesDeployment.log
Also, the WindowsUpdate.log success
And reboot if required (and scheduled)
Update: An ex-colleague reached out to me to add some extra info around the process for the SCEP update trigger. As my SCEP knowledge isn't the greatest, it's something I'll be sure to remember and very helpful for the community.
The key difference that I can see is that the SCEP definition update initiates from the AntiMalware Policy configuration, not from the EndPoint client settings where I expected to see it, or the from Software Updates Schedule client setting. As opposed of course to Software Update scanning and installation as per your post. Also triggering a manual SCEP definition update is only done from the SCEP client and not the SCCM client actions from what I've seen so far.
Thanks David!
Comments
- Anonymous
January 01, 2003
@Moataz
That's correct - Anonymous
January 01, 2003
@Joel
All executions and reboots are suppressed when the service window closes, so no more updates will install until the next open window. This makes it particularly important to ensure you have your windows open for long enough to install all updates. - Anonymous
January 01, 2003
@Justin
You' are correct. However, as the ConfigMgr SUP role takes 'ownership' of the WSUS instance, we generally say the clients use the SUP, not WSUS. - Anonymous
January 01, 2003
@Joel
Yep! - Anonymous
January 01, 2003
@Joel The maintence window must be that long that all updates maximum run time together fits the maintence window. otherwise the updates will not get installed. It will not install some of the updates! - Anonymous
June 30, 2014
This means if the machine policy is 60 min and scan is every day but the depolyment evaluation cycle evey week . Tne updates will be deolyed after 1 week after the evaluation happened . So I have to evaluate everyday to get the endpoint updates ? - Anonymous
June 30, 2014
"The Windows Update Handler initiates the Windows Update service against the ConfigMgr SUP". We actually scan against the WSUS instance here not "SUP". the SUP simply controls the configuration and sync between WSUS and ConfigMgr. - Anonymous
June 30, 2014
Great article thanks! Just wondering what happens if the service window available is only sufficient to apply half the updates? Will half install in the current window and half in the next available window, and, will a reboot occur in each window or will it be postponed until all updates have been applied? - Anonymous
July 03, 2014
Is this process essentially the same for downloading SCEP definition updates if ADR has been used to update the deployed package daily? - Anonymous
July 21, 2014
Hi!
Thanks for nice post.
What about datatransfer.log and contenttransfer.log. They will not play any role?
Also if you have distriubtion point group then how you locate from where its downloading the content?
Thanks,
Capricorn - Anonymous
November 14, 2014
I have found that I can only initiate the action 'Software Updates Deployment Evaluation Cycle' from the Configuration Manager Actions tab. When I try to trigger this action from the CM12 Console, Collection Commander, WMIC, or Powershell nothing happens. - Anonymous
April 13, 2015
After a software update synchronization process completes and there is at least one new update, a site wide policy is generated which tells the client to perform a scan and then an evaluation so really only a machine policy retrieval action is required...or you can just wait for the client to automatically pull down the policy which usually happens pretty quickly.
Many environments sync every 8 hours to keep the SCEP definitions up-to-date so in this scenario, your clients run a scan and evaluation 3 times a day. - Anonymous
April 14, 2015
Can anyone expand on that last paragraph? I need someone to (hopefully) clarify how SCEP updates function. I have a SCEP ADR configured to run immediately after a successful wsync, with a wsync that is configured to run every 6 hours beginning at 12 PM. The SCEP ADR sets a deadline of 'As soon as possible'. We have a single server OU-based collection with an antimalware policy deployed that checks for definition updates every 8 hours. In our client policy, we have the Software Update Scan scheduled for every 3 hours.
Which value are endpoint protection definitions installed on? Is it found every 3 hours per the client policy, or will it only install at the deadline after discovering the update on the 8 hour malware policy interval? - Anonymous
July 02, 2015
@John, Here is how I trigger the 'Software Updates Deployment Evaluation Cycle' in PowerShell. To check:
If (Select-String -Path "$serverC$WindowsCCMLogsUpdatesDeployment.log" -Pattern 'Message received')
To Scan, thanks to http://www.configmgr.no/2012/01/17/trigger-sccm-client-action-from-powershell/
$trigger = "{00000000-0000-0000-0000-000000000108}"
$scan = Invoke-WmiMethod -ComputerName $server -Namespace rootccm -Class sms_client -Name TriggerSchedule $trigger - Anonymous
July 13, 2015
We currently have our update scan and deployment re-evaluation set for 4 days. This is fine for most machines in our estate, but certain model types which can quite often be powered on for only a few hours at a time (and sometimes may be powered off for over a week at a time) are never actually running the software updates scan, so never think they require any new updates.
So my query is : if a scan is set to take place every 4 days, but the machine is off for over a week - will it force a scan the moment that device is then connected?
if so, then I would always expect all devices to run the scan and specify that they need the updates (even if they are not connected for long enough to download and install them)
Would lowering our scan cycle (to say 1 day) help us in this case - or do we simply need to force a scan through means of a scheduled task when machines logon to ensure they run the scan and report back to config mgr that they are required? - Anonymous
September 01, 2015
Very helpful walk-through - thank you! - Anonymous
October 12, 2015
This is such an awesome break down. Thank you so much for this wonderful post. I now have a better understanding of the entire update process.