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.