This blog is owned and operated by the ANZ ConfigMgr Premier Field Engineer team.
Ian BartlettMatt ShadboltGeorge Smpyrakis
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.
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 ?
"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.
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?
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.
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.
Is this process essentially the same for downloading SCEP definition updates if ADR has been used to update the deployed package daily?
@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!
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?