Basics of SCCM - WSUS Relationship

Question

Hi all,
Just had a question about how updates in SCCM 2007 work. At a very basic level, I understand it to work like this:
SCCM Side: WSUS syncs with Microsoft to build metadata list of all available updates > SCCM leverages WSUS metadata to provide a list of available updates visible under "Software Updates" in SCCM console >
SCCM Admins can then created Update Lists and Deployment Packages based on the wsus metadata > Deployment Packages are applied to Collections
Client Side: CCM client runs an update scan > CCM client leverages the machine's WUA to check available updates on the SCCM server > CCM Client makes a list of the updates that it needs but does
net yet have installed > downloads the updates and installs them from the DP
My question is about what source the CCM client/WUA uses to check which updates are available. Does it simply check the update packages which have been applied to all those collections that it happens to be a member of?
Also, is WSUS completely passive in this whole process - i.e. is it merely a conduit for SCCM to source metadata about available updates?
Thanks for any help!

Answer 1

A handful of comments here:
First, don't confuse packages with deployments. They are two different things in both 2012 and 2007. Packages are simply the binary files that ConfigMgr places on DPs. Clients download the binaries from these when they are needed. Deployments determine what
updates are assigned to or required on clients.
As mentioned, update metadata, basically the definition of all possible updates and how to know what systems the updates apply to comes from the WSUS instance corresponding to the SUP.
The scan cycles kick the WUA into action to scan for updates. The Normal scan cycle is like an incremental and the re-eval cycle scans for all deployed updates to make sure that they are still installed and reinstall them if they aren't. The normal scan
cycle is kicked off at various other times also linked with deployments.
Finally, for using the required attribute, which is reflective of how many clients need a particular update, I think this a reactive approach that is anti-security as it reflects the past and not the current state of the environment. Granted the past may
only be a day ago; however, in security terms, that doesn't matter. Being pro-active in this case, i.e., making all potentially applicable and in-scope updates available comes at the cost of disk space, nothing more. Thus, I generally recommend against using
this attribute.
As for WMI, think of ConfigMgr as a WMi automator -- just about everything that ConfigMgr does involves WMI. In simple terms, WMI is just a DB storing info on local systems.
Jason | http://blog.configmgrftw.com | @jasonsandys