Single, well-connected site
WSUS Updates from Microsoft Update
Clients update from WSUS
Single server can handle 25,000 clients
Largest use case in production today
Driving forces to move to Machine Groups:
Differing patching requirements or schedules
Servers vs. Workstations
Not necessarily used for load distribution
Downstream servers are replicas of primary server
Little downstream control over servers
Downstream admins drop machines into predefined groups
All update approvals and schedule done at primary server
Chaining involves downstream servers getting updates (and sometimes Group data) from upstream servers
Options for chaining
Distributed vs. Centralized model
“Autonomous Mode” vs. “Replica Mode”
Chaining solves the problem of “MESH” or “Fully Independent” architectures
Wastes resources and bandwidth
◦ Not that some situations don’t mandate “MESH” or “Fully Independent”
Downstream servers obtain updates from primary server, except:
Update approvals do not flow down. Assigned at each site individually.
Downstream admins have greater control. Can create groups and assign approvals.
Used for distribution rather than control of updates
Many environments don’t have Internet connectivity.
Test/dev, government, classified, air gap environments
Data must be imported from “the outside”
Any the previous architectures will work
Manual import process required
Gives CM/QA/Security the option to review updates prior to bringing “inside”.
WSUS 3.0 includes native support for high availability
NLB Clusters connect multiple WSUS web servers via a single cluster IP
SQL Cluster manages the database
No single point of failure
Fixes of problems specific to solutions.
Updates of virus definitions.
Software components designed to support new types of hardware.
Feature packs (Features)
New product launches gathered under a future product.
Fixes of specific solutions to security issues.
Service Packs (service packs)
Cumulative packages that contain critical fixes and security updates, and a limited number of updates at the request of clients.
features that come
Cumulative packages fixes, critical updates Security and implemented together.
Fixes to specific problems and solutions addressed to non-critical and non-security.
Updating the registry keys on the WSUS server after IIS configuration was changed.
Configures health monitoring values in the database. If new values are not specified, the current values are displayed.
Part of the export/import process used to synchronize a downstream WSUS without using a network connection.
Exports update metadata to an export package file. You cannot use this parameter to export update files, update approvals, or server settings.
The second part of the export/import process.
Imports update metadata to a server from an export package file created on another WSUS server. This synchronizes the destination WSUS server without using a network connection.
Changes the file system location where the WSUS server stores update files, and optionally copies any update files from the old location to the new location
Lists the front-end servers related to this WSUS server.
Deletes the specified front-end server from the WSUS database.
Checks the health of the WSUS server. Results will appear in the Application Event log.
Checks that every update metadata row in the database has corresponding update files stored in the file system. If update files are missing or have been corrupted, downloads the update files again.
Returns a list of update titles with approvals that are in a permanently inactive state because of a change in server language settings.
Removes approvals for updates that are in a permanently inactive state because of a change in WSUS server language settings.
Changes the port number used by the WSUS Web services from 80 to 8530 or vice versa.