Jaa

Managing changes from a WSUS Server

  • Artikkeli

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 https://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 https://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”.

 

-Marc Shepard, WSUS Lead Program Manager

Comments

  • Anonymous
    January 01, 2003
    thank you

  • Anonymous
    January 01, 2003
    The WSUS Team Blog releases a well-thought out compendium of the various ways in which updates can be approved through a WSUS infrastructure. Some of these may not be overtly obvious through the interface. The team reports that seven different mechanisms

  • Anonymous
    January 01, 2003
    In regards to the question on if updates can be approved and unapproved from our API, the answer is yes. Anything you can do from the UI you can do from the API, since the UI is built on the public API. On our main technet site, http://technet.microsoft.com/en-us/wsus/default.aspx, check out the links for "SDK", "Script Center", and "API Samples and Tools" for more information on how to use the APIs.

  • Anonymous
    January 01, 2003
    thank you

  • Anonymous
    January 01, 2003
    thank you

  • Anonymous
    January 01, 2003
    Thank you http://www.pireilaclama.gen.tr

  • Anonymous
    January 01, 2003
    thank you

  • Anonymous
    January 01, 2003
    Thank you for this info... and the script.

  • Anonymous
    January 01, 2003
    I upgraded our Small Business Server 2003 R2 to WSUS 3.0 the other day and the new UI (MMC snap-in) is great. Much more responsive and easy to use. I was, however, a little disappointed that it did not integrate into my Server Management console and daily SBS performance report. Any chance that will be available in the future? Thanks for the good work.

  • Anonymous
    January 01, 2003
    thank you

  • Anonymous
    January 01, 2003
    I am needing some assiatance in getting WSUS 3.0 running on my server. I installed WSUS 3.0 on a server running Server 2003 STANDARD SP1, I made sure all the prereqs were installed  - in fact I installed them 1 week ago and made sure there were no conflicts before I installed WSUS 3.0. After the installation (which gave no errors). the configuration screen failed to come up. When I try to connect to the server to configure the updates, I receive the following errors: Initially I get (where Servername is the name of my server I installed WSUS on): "Cannot connect to "Servername". The server may be using another port or different Secure Sockets Layer Setting." I changed to SSL and try to connect, get this error: "Cannot connect to "servername". The remote server could not be contacted. Please verify that IIS on the server is correctly configured and running. Contact your network administrator if the problem persists." IIS is running, I am trying on the server that WSUS is installed on, and got no errors during the install. I am unable to connect to the server. Any suggestions?

  • Anonymous
    January 01, 2003
    thank you

  • Anonymous
    January 01, 2003
    super thank you http://www.parcakontorbayiniz.com

  • Anonymous
    January 01, 2003
    On February 12, 2008 we will release the Windows Internet Explorer 7 Installation and Availability Update

  • Anonymous
    January 01, 2003
    thank you

  • Anonymous
    January 01, 2003
    PingBack from http://windows-update.blogyblog.info/?p=8841

  • Anonymous
    January 01, 2003
    Managing changes from a WSUS Server
    thank you

  • Anonymous
    January 09, 2008
    When is WSUS team planning to release Windows Live Messenger to WSUS? It's up a category. Is this not going to be used?

  • Anonymous
    January 10, 2008
    The comment has been removed

  • Anonymous
    January 15, 2008
    When approving an update only for a specific group of computers it is still categorized as "needed" for the group it wasn't approved for. Is there any chance this will be corrected soon?

  • Anonymous
    January 17, 2008
    Is there a way to remotely force application of any pending updates on client computers on demand?   I can remotely force detection and download via the /detectnow switch.  Is there a different switch to force installation/application of pending updates? Danke, Mark

  • Anonymous
    January 17, 2008
    I wish that WSUS supported a "big red switch" deployment for updates.  I am afraid to have automatic deployment of updates because of reboots and potentially incompatibility with existing things on the servers that might "break" something.  So I wish there was a big red switch to say "deploy all approved bits to these set of servers." I currently do my deployments such that all my servers are set to download the updates automatically (but not deploy).  Then I deploy in the following order (if each previous deployment is successful):

  1.  To internal servers that do not affect anything and can afford to have downtime.
  2.  Deploy to half of the rest of the servers (all of these servers are redundant so if they are down, services are still running because each server is in a farm).
  3.  Deploy to other half (rest of servers). I know I can setup groups and deploy them if it's approved but the problem is that some automatically approved updates require reboots and I cannot afford having an entire farm being down at the same time as all services come to a halt).  I tried it using different group policies for different sets of servers and it was too complicated and didn't work in this fashion that I wanted. BTW - I provide internet facing services so all of our updates are to servers that are constantly being pounded and used and we have no clients in the infrastructure.