Software Update Point Facts

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:
  1. [ms_highlight background_color=”#ffcb05″ color=”#00274c” border_radius=”2″]The update metadata[/ms_highlight]. 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.
  2. [ms_highlight background_color=”#ffcb05″ color=”#00274c” border_radius=”2″]The update binaries[/ms_highlight]. These are the actual files used to install an update.
  3. [ms_highlight background_color=”#ffcb05″ color=”#00274c” border_radius=”2″]The EULAs (end user license agreements)[/ms_highlight]. 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 update((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.)) ((Updated 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 update((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.)).
• 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.