Most of the below information is cobbled together from a couple of TechNet pages, a blog post or two, presentations I’ve seen over the years, conversations I’ve had with others, forum posts and experience — there’s just no one definitive source with a product as big as ConfigMgr that also relies on another full product in this case. And of course, there are always gaps (and sometimes errors) in the actual public documentation. Here are a few of the sources I could dig up though (note that very little has changed as far as these actual processes go from 2007 to 2012, software updates was mostly a UI change from 2007 to 2012):
- TechNet: About Software Updates Compliance
- About Software Update Deployments
- Understanding Updates Management
- Software Update Points in Configuration Manager Service Pack 1
Based on the (many) sources, here are a handful of key facts, implications, behaviors, and observations I thought I’d put together in one place (for the day my memory or sanity completely goes away — probably tomorrow).
- The software update scan cycle initiates a compliance scan, using the Windows Update Agent (WUA), for all updates in the WSUS catalog on the client. This activity is mostly reflected in WUAHAndler.log.
- As stated in the previous bullet, resulting compliance info from a scan cycle info is stored in WMI and also forwarded to the site using state (not status) messages.
- As implied in the first bullet, the scan cycle is run at more times than just the scheduled time. It is also run at the following times:
-
- When a client receives a new update deployment.
- Right before a deployment is executed (to ensure its local compliance info is still accurate).
- After a deployment is executed and before a reboot.
- After the reboot associated with a deployment is executed.
- There are two scan enforcement levels based upon when the update scan is performed (as listed at the bottom of the About Software Updates Compliance page linked above): Forced and Unforced. Forced equates to the scan always happening and unforced equates to the scan only happening if the most recent scan happened more than 24 hours ago (because the update metadata/catalog is considered only valid for 24 hours — this is the Time To Live [TTL] of the update metadata).
- There are two types of scans also: Online and Offline. Online performs a full scan using the update metadata/catalog on the WSUS server (which is also simultaneously synched to the client) and offline performs a scan using the metadata cached by the client.
- The scan cycle does not perform a full scan every time; instead, this is effectively equivalent to an incremental and only concerned with updates whose compliance info is in scope (because it was run in conjunction with a deployment) or in the case of the normally scheduled scan cycle for updates that have no compliance information already stored in WMI. I’ve never explicitly watched so don’t know if the ConfigMgr agent simply filters the compliance info returned from the WUA or if the agent can somehow tell the WUA to only scan particular updates — based on limited observation, I suspect the later.
- The main (and really only) purpose and function of the scan cycle is to provide update compliance info to the client (so that it can accurately make decisions about what updates to download and install), to the site for reporting purposes, and for the administrative user when crafting the various software update objects.
- The complementary statement to the previous bullet is that the scan cycle does not directly initiate any software update installation or download activity. It is a precursor certainly, but the scheduled scan is just one of many scan cycles that actually happen.
- There is a random, up to two (or maybe one, I don’t remember and can’t find the explicit documentation on this) hour delay after a deployment deadline hits before a client will kick off the pre-deployment software update scan and subsequent update installation. This is in place to prevent the clients from slamming the client facing site roles because there is a lot of activity that happens during the process. This may have slightly changed in 2012 SP1 with the ability to disable random client activity — not sure as I have not checked or confirmed whether that setting applies to this or not. I want to say no, it’s not gone if you disable the random setting (which is default in SP1 and R2) but don’t know for sure. Also note that if a software update installation activity kicks off because of or during a maintenance window, then this random delay does not occur.
- The deployment re-evaluation cycle doesn’t really play into the normal process, it is meant to ensure that updates previously deployed and still within an applicable and required deployment with a deadline in the past are in fact still installed and it will immediately reinstall them if they are found not installed; this “immediate” installation is not subject to maintenance windows.
- For a client to know about any new settings or deployments, a policy update cycle must be run on that client (either manually or scheduled). This, of course, includes software update deployments (machine policy in this case). The software update scan cycles have nothing to do with updates actually “assigned” to a client via deployments.
There are lots of caveats as always like if you are relying on the required attribute to create your software update objects, you obviously have to wait for a scan cycle to have this info. I don’t typically recommend this anyway because it makes you reactive instead of proactive with the only cost being disk space. Also, if a client changes the WSUS server that it reports to (during an upgrade or failover) it immediately invalidates the cached update catalog/metadata and makes the TTL irrelevant because the client recognizes this as a major change.
The main conclusion and final statement here is that when deploying software updates, it’s all about the deadline of the deployment (and applicable maintenance windows) just like all other deployments. Yes, the scan cycle must be performed and is a precursor (how else would the client know what to install or what to download) but this does not have to be the scheduled scan cycle (and in fact usually isn’t because of the other scans kicked off by the deployment process). Thus the scheduled software update scan cycle is really just about reporting and not crucial to the normal update deployment process so there’s generally no need to explicitly schedule it more than the default of every seven days.
This is brain-meltingly good information. It has concisely answered a number of key questions I had in one place. Thanks for writing this up.
Hi Jason, Your blog is really so informative thanks.
Thanks!
Beer for Jason.
Thanks for the very detailed blog. I am assuming, removing any one patch from Software Update Group will cause the CM clients to re-evaluvate and through state messages report back the status. Is that right?
Not to my knowledge. It will only evaluate the compliance on newly deployed updates. Removal is just that, removal and requires no compliance scanning.
Thanks Jason. Another good blog.
Really good information here Jason, as always. I vaguely remember an MVP stating to set the Software Updates Scan time to during a maintenance window that you have dedicated for the Software Updates installation. The result would be that the client could scan for any new updates it needed and download/install during that window as it completed the installation of other updates. Given your above information, however, that does not sound like a necessity, nor even a recommendation. Would you agree? Would the same apply for the Software Deployments Scan time as well? Thanks in advance.
I’m not sure what running the scan during a MW gains you. The scan is just that, a scan. It does not kick off any actions. Only deployments (and the deployment re-evaluation cycle) actually cause anything to happen. On a similar note, update installation due to the deployment reevaluation scan does *not* adhere to MWs.
One thing you don’t mention is the role the Software Update Sync plays in all this. It is my understanding that after every sync and at least one new update is synchronized, the SU metadata changes which causes the site to generate a site wide machine policy that tells the clients to download the new metadata, perform a software update scan and then perform an evaluation which sends the compliance data to the Management Point. I have confirmed this by kicking off a Machine Policy refresh after a SU sync and within a minute or two, a software update scan occurs followed by a deployment evaluation.
Syncs don’t necessarily imply any new updates whatsoever. It all depends upon when the sync runs but if Microsoft hasn’t released a new update since the last sync, then the sync pretty does nothing.
As for clients and metadata, the normal process has nothing to do with the site. The WUA is solely responsible for downloading update metadata directly from the WSUS instance — ConfigMgr truly has no part in this. You can of course force the WUA to sync metadata, but that’s generally not the norm. As for the site wide policy, no, that does not happen to my knowledge, There would be no reason to have a software update scan cycle if that were the case.
You mention you don’t typically recommend the required attribute when configuring Software Update Groups. What other method do you recommend?
Hi Greg!
Using the required attribute is reactive and not proactive. It also not account for systems not managed by ConfigMgr currently but may be at some point in the future (and you never truly know which will or won’t be). Finally, when using OSD, you need *all* updates available and not just those for systems currently being managed. In short and IMO, all applicable updates for a product should be made available just in case a system need it. This comes at the small price of disk space.
So for OSD in particular, should you make all updates available (i.e. deployed and not required) to every machine and make them hidden in Software Center? Can you elaborate on this point? We are trying to use Task Sequences to patch cluster nodes in our environment. I want to make sure the patches are available to those machines only during a TS. Let me know what you think and thanks!
Yes. That’s pretty much what I’d do. You can’t hide them though if they’re not required — how would anyone install them if they were hidden?
Old post but still very helpful. Regarding the two hour deadline delay – It’s set under the Computer Agent client setting labelled as ‘disable deadline randomization’ (yes/no).
https://technet.microsoft.com/en-us/library/gg682067.aspx
When I wrote this post, the setting didn’t exist but thank you for adding the relevant information and link.
Very helpful post! I think MS should rename The SUS schedule since it’s meant for reporting only !
I have a question though, when there is a new update and it shows 0 updates required ,is there a way to speed up the process to show the actual required# ? Will running the scan schedule help? Will the update be pushed to the clients if it shows 0 even if it’s not installed yet ?
Thanks
Hi Ben. If you are looking to speed up the reporting process for new updates that haven’t been deployed yet, then lowering the scan cycle interval is certainly a way to do it. Or, you could run this manually as well for sure.
What’s shown in the console and reporting for that matter may not reflect the latest scan results from the client. Ultimately, it’s the client that decides, based on the local WUA compliance scan, what to install or not to install (only things deployed to it are eligible to be installed though of course).
we have an issue with SCCM where SUP will pull the monthly updates down, we then have an ADR run the following day to deployed “needed” updates to a group of clients.
However even thought the updates are in SCCM they tend to show as “0 required” for 3-4 days before eventually all of a sudden 700 clients need them. This makes is very difficult to time the ADR schedule and deploy things within are required deadlines.
We thought it might be the frequency of the “Updates Scan Cycle” reporting back only every 7 days (as default). However, even when manually running the Scan from a bunch of clients, SCCM will still show the clients don’t need the updates for the next 2 days…
Its highly confusing.
Honestly, don’t rely on the required attribute. Just deploy all of the possibly applicable updates. You aren’t gaining anything using the required attribute except some disk space.
Ultimately though, the Update Scan Cycle is mainly for reporting compliance on updates that haven’t been deployed yet so adjusting it won’t help. What I suspect is happening is you are running into actual WSUS issues the same as everyone else in the world. Have you cleaned up your WSUS (by declining all superseded updates as well as unchecking products you don’t deploy updates for), scheduled a reindex and statistics rebuild, tweaked the IIS App Pool private memory limit, and adjusted the IIS App Pool queue length?