As part of a (longish) Reddit forum thread, I posted the below facts about the Software Update Point (SUP) role in System Center Configuration Manager (ConfigMgr). This is not a comprehensive list of facts by any means, but there are a lot of misconceptions and incorrect assumptions that the below facts address and so here they are replicated (with a few slight changes and additions) for your reading pleasure.
- There are three parts to updates:
- The update metadata. This is contained in and usually synonymous with the update catalog. The metadata specifies things like description, detection logic, and where to download the update binaries from.
- The update binaries. These are the actual files used to install an update.
- The EULAs (end user license agreements). These are small (usually less than 1KB files). Not all updates have EULAs though.
- The SUP is a thin management layer on top of WSUS. The SUP requires WSUS to be installed locally; i.e., on the same system as the SUP itself. This is because the whole purpose in life of the SUP role is to manage WSUS.
- ConfigMgr uses WSUS to download the update catalog and EULAs (and only those items). Nothing else about WSUS matters or is used by ConfigMgr including approvals or content downloaded by WSUS because of approvals. Thus approving updates directly in WSUS is meaningless and will just waste disk space.
- Updates declined in WSUS become expired in ConfigMgr if they exist in ConfigMgr. Expired updates cannot be deployed. If a previously deployed update becomes expired (either because Microsoft declared it expired or because it was expired in WSUS), it will no longer be installed on clients.
- EULAs are downloaded to and stored in the WSUS content library.
- Update metadata is stored in the WSUS database and replicated to the ConfigMgr database.
- ConfigMgr clients communicate with WSUS to get the update catalog and the EULAs — nothing else. They do not get the update catalog from ConfigMgr or the SUP itself.
- Intranet ConfigMgr clients get update binaries from distribution points or Microsoft update1Configuring Intranet clients to use Microsoft Update is not always easy. The applicable update deployment(s) must be configured to allow this behavior and the corresponding update binaries must not be available to the client on an accessible distribution point. 2Updated to correct an oversight about the client being able to download update binaries from Microsoft Update directly. Thanks Panu!.
- Internet ConfigMgr clients get update binaries from Microsoft update3If an Internet client fails three times to retrieve content from Microsoft Update, it will fall back to using an Internet-enabled distribution point. This behavior is not configurable..
- ConfigMgr itself can acquire the update binaries from one of two locations. Once acquired, they are placed in update packages and then distributed to distribution points so that clients can access them. These two locations are as follows:
- Directly from Microsoft.
- From a UNC path.
- If you specify the UNC path, something else must populate the update binary files in that UNC path.
- During an ADR evaluation, the site server (and only the site server) acquires the content from the specified location (either Microsoft or the specified UNC).
- When manually downloading updates using the console, the system where the console is running acquires the content from the specified location (either Microsoft or the specified UNC).
- The SUP is never used to download update binaries.
- Nobody likes WSUS.
|↑1||Configuring Intranet clients to use Microsoft Update is not always easy. The applicable update deployment(s) must be configured to allow this behavior and the corresponding update binaries must not be available to the client on an accessible distribution point.|
|↑2||Updated to correct an oversight about the client being able to download update binaries from Microsoft Update directly. Thanks Panu!|
|↑3||If an Internet client fails three times to retrieve content from Microsoft Update, it will fall back to using an Internet-enabled distribution point. This behavior is not configurable.|
Great list! One minor clarification: ConfigMgr clients could also get update content from Microsoft update when
a) client is in internet location
b) DP doesn’t have content and you have allowed downloading from MU
Totally agree with your last point.
Thank You, Panu. Oversight on my part as this wasn’t relevant to my original Reddit thread but is certainly accurate and should be included for completeness. It’s now corrected above also.
Thanks for this post. Something to consider when dealing with Proxy servers.
When using the console to manually download updates from the internet, the downloads happen under the account of the user running the console. If there is a proxy server controlling internet access, it may be necessary to configure the proxy settings in the Internet Control Panel for the user. The proxy settings on the Site System roles are only applicable to the System account running those roles when performing actions such as synchronizing the updates catalog and downloading updates as part of the ADR evaluation cycle.
This is an excellent addition to the list above. My preferred answer is to simply rip out the proxy server altogether but that’s rarely within my power to accomplish.
Great facts listed, still reading in 2019!
Great article. Helped save my brain from imploding.
When you say that the replication happens to the configmgr database you mean the sup contacts the primary site database and not a wsus database?
Not exactly sure what you are asking here. The SUP role, during update synchronization, replicates update metadata from the WSUS database to the ConfigMgr DB as stated. This occurs after WSUS downloads the update metadata from Microsoft.