There are multiple ways updates can be deployed through WSUS to client machines (“client machines” mean clients of the WSUS server – the machines may be running either client or server operating systems). This posting describes these mechanisms and the way they can be controlled by the administrator in order to ensure unexpected changes do not occur.
· Explicit approval. An administrator can explicitly approve an update for installation to a group of machines.
· Auto-reapprove revisions. By default, when a new revision of an approved update is synchronized to the WSUS server we move the approval to the new revision. Normally this is what customers want, since new revisions never contain new binaries, just fixes to the metadata that describe how to automate the installation of the update. However we had one incident when a new revision of the Windows Desktop Search update changed the metadata so that the new revision was offered to *all* machines but the old revision was offered only to machines with older versions of Desktop Search installed, which caused it to be deployed more widely than expected for many customers (see http://blogs.technet.com/wsus/archive/2007/10/25/wds-revision-update-expanded-applicability-rules-auto-approve-revisions.aspx for details). Since then, we’ve added processes to ensure this type of change will not happen again. The administrator has direct control over this and can disable the option to auto-reapprove revisions.
o Warning: turning off auto-reapprove revisions can create problems if the administrator has “definition updates” (signatures) in their synchronization options, because definition updates get created and expired fairly quickly and the expired ones won’t get auto-unapproved. As described in KB 938947, this can quickly lead to having too many updates approved which can cause problems for client-server communication. If auto-reapprove revisions is turned off, the administrator will need to manage revisions themselves; looking for older revisions that are approved and either unapproving them (if the new revision is marked “expired”) or move the approval to the new revision. We have provided a PowerShell sample script at http://www.microsoft.com/technet/scriptcenter/scripts/sus/server/susvms09.mspx that can be used to manage revisions.
· Auto-approve WSUS updates. Some updates are marked as “infrastructure” updates, which means they are needed by WSUS or WUA for proper detection and scanning for many updates. These updates include MSI 3.1. WSUS creates approval rules to these by default, since they are necessary for the update system to work properly. The administrator has direct control over this and can disable the option to auto-approve WSUS updates. If disabled, WSUS will notify the admin in the home page (TODO list) that there are unapproved WSUS updates, which can lead to infrastructure problems (e.g., if MSI 3.1 is not installed on client machines, then many updates including Office Updates, can’t be properly detected).
· Auto-approval rules. Administrators can create custom rules to auto-approve updates (e.g., auto-approve all security updates to all computers, or auto-approve all updates to a test target group). The administrator has direct control over this and there are no auto-approval rules enabled by default.
· Initial client self-update. When a WSUS client’s Windows Update Agent (WUA) first synchronizes against a WSUS server, it checks if the server has a newer version of the agent available in the servers “self-update” tree. If a newer version is available, the agent will self-update before completing the synchronization. Although Automatic Updates will check for self-update on every synchronization, the self update will only occur on the first synchronization unless the admin explicitly applies an update to the WSUS servers self-update tree (the next scenario).
o Note: Newer versions of WUA on a particular operating system are backwards-compatible with the older versions of WSUS that support that operating system. So after WUA self-updates to the latest version, the client can later be managed by an older WSUS server if desired. The agent never “self-downgrades” (it will stay on the latest version of WUA when talking to an older server).
· Subsequent client self-updates. The WSUS team may provide an update to the WSUS server itself that modifies the client self-update tree on the server. As of this writing, only two such update have been released; WSUS 2 SP1 (which modified the WSUS 2 self-update tree) and KB 936301 (which modified the WSUS 2 SP1 self-update tree). Such updates flow to the WSUS server as normal updates. If the admin approves such an update for install on the WSUS server, then the WSUS server self-update tree will be updated and subsequently all clients that synchronize against the server will self-update. The administrator has direct control over this since clients will only perform this subsequent self-update if the administrator approves an update to the self-update tree.
· Update from Microsoft Update. End users on client machines can go to Windows Update or Microsoft Update and install updates (and WUA self-updates) directly. The administrator has direct control over this since they can configure the Windows Update Agent to disallow end-user access to Windows Update and Microsoft Update.
WSUS and AU have log files that allow customers to understand when and why a given update was installed on a machine:
· The Windows Update Agent has a log file “%windir%\WindowsUpdate.log” with verbose logging on updates that have been installed.
· WSUS 3.0 has a log file “%Program Files%\Update Services\LogFiles\changes.log” that contains a record of all recent approvals and who made them. If the approval was created automatically (e.g., auto-reapprove revision, auto-approval rule, or auto-approve WSUS updates), the user in the log will be “WSUS Service”.
Loading ...