What You Should Know About WSUS 3.0

Disclaimer: I wrote this document to be used as a training manual and/or “standard” when I was doing small-biz consulting, so rather than explain all the options available to you, sometimes I just say “do it this way”. Chances are (for most WSUS installations which are not integrating with something more complex, like SCCM), these settings are the best-practice anyway. Nevertheless, YMMV.

Furthermore, I have not updated the document for WSUS 3.0 SP2 since I haven’t been working with it lately. But—as with all my posts here—please feel free to drop me a note to let me know of any errors, suggestions, or otherwise. Thanks, and enjoy!

Installing & Configuring WSUS 3.0

Microsoft Windows Server Update Services can be used to help keep control of your Windows network patching. It is free and relatively easy to use, but a bit of attention should be paid to a few points of the setup to avoid problems.

  1. Decide which server has the memory and disk space to spare for WSUS. Note also that there may be memory bugs with WSUS 3.0 for 64-bit systems, so maybe that should be avoided for now.
  2. Download the latest version (v3.0 SP1 at the time of this writing) for your architecture (32- or 64-bit) from http://www.microsoft.com/wsus
  3. Note the following system requirements—if you do not have them installed yet, you should install them before continuing:
    1. Windows Server 2003 or higher
    2. IIS (can be installed from Add/Remove Programs—Windows Components on Server 2003 or as a Role in Server Manager on Server 2008+)
    3. .NET Framework 2.0 (and all the latest patches—get them now or you will have to reboot the server afterwards!)
    4. Microsoft Report Viewer 2005 (http://www.microsoft.com/Downloads/details.aspx?familyid=8A166CAC-758D-45C8-B637-DD7726E61367&displaylang=en)
  4. Run the installer file you downloaded and choose the following options:
    1. “Full server installation including Administration Console” , “Next >”
    2. “I accept…”, “Next >”
    3. Check “Store updates locally” and choose the data drive will lots of free space, for example “D:\WSUS” (never on the C:-drive!).
    4. Tip: If you have a dedicated/separate SQL Server, it is recommended to host the WSUS database there (it will require about 1-2GB of space). The application/web front-end does not have to be on the same server as the database. If you want to create the database on a separate server, choose the option “Using an existing database server on a remote computer” now; otherwise, choose “Install Windows Internal Database on this computer” and enter the same directory name as above (“D:\WSUS”).

    5. Caution: If you already have important web services such as Outlook Web Access (OWA) or SharePoint on the IIS Default Web Site port 80/443, do not install WSUS onto this same port—choose the option “Create a Windows Server Update Services 3.0 Web site” and it will use port 8530. Otherwise, if you are sure there’s nothing on port 80 that WSUS will clobber or have trouble with, than go ahead and select “Use the existing IIS Default Web site (recommended)”. Remember the URL that it gives you here (e.g. “http://SERVER:8530”, because you’re going to need it for configuring Group Policy!
    6. You should now be at the summary screen; click “Next >” to install and “Finish” when it is done.
  5. Next the “Windows Server Update Services Configuration Wizard” window appears. Follow these steps:
    1. “Next >” to begin.
    2. Check “Yes” only if you want WSUS sending info to Microsoft.
    3. “Synchronize from Microsoft Update” if this is the only WSUS server; if you are setting up a hierarchical tree of server, you may prefer to specify a parent server here instead; “Next >”.
    4. Specify a web proxy server only if needed (rarely), “Next >”.
    5. Click “Start Connecting”, wait until it is ready, then click “Next >” to continue.
    6. Download only updates in “English”.
    7. Check products appropriate to the company you’re configuring. Here are a couple that you probably want to include in any case:
      • Microsoft Core XML Services
      • CAPICOM
    8. Check at least the following classifications (depending on the client sensitivity and needs, more may be appropriate):
      • Critical Updates
      • Definition Updates
      • Security Updates
      • Update Rollups
      • Updates
    9. Select “Synchronize automatically” and pick a time each night (off business hours) when the server will synchronize).
    10. Uncheck “Begin initial synchronization”! Don’t do it yet, or you’ll have a mess of updates you don’t need!
    11. Click “Finish” and the “Update Services” Console should open.
  6. Now you should have the WSUS “Update Services” Console open for the first time. Before synchronizing or connecting any clients we need to make some configuration changes:
    1. First, we will want Group Policy to manage to systems are organized into groups. Go to Options | Computers and select “Use Group Policy or registry settings on computers”.
    2. Next, we need to create the group names we are going to be using. Expand the “Computers” section, then right-click on “All Computers” and choose “Add new group…”. Typically you will want to at least create separate groups for ‘Servers’ and ‘Desktops’.

    3. Last, this is where some of the magic comes in: WSUS can automagically approve and apply the updates without any intervention. Go to Options | Automatic Approvals, check the box by the “Default Automatic Approval Rule” (otherwise it won’t do anything!), then click the words “Critical Updates, Security Updates” to open the “Choose Update Classifications” box. Here I would recommend you select the following (more or less depending on client sensitivity—keep in mind that these will be automatically applied as soon as Microsoft releases them):
      • Critical Updates
      • Definition Updates
      • Security Updates
      • Update Rollups
      • Updates

    4. Now if you wish you can click over to “Synchronizations” and choose “Synchronize Now”—but realize that this will use a lot of bandwidth and take a good amount of time before it’s done, especially the first time it runs.
  7. Next, it is recommended that you limit the amount of RAM that the WSUS database process will use (by default it will use everything it can, but it certainly doesn’t need that). Follow the steps outlined at http://msmvps.com/blogs/bradley/archive/2005/05/22/allocated-memory-alert-one-more-time.aspx;
    you should be able to limit the process to 128mb or 256mb at the most, and performance will not be affected.
  8. The last configuration step is Group Policy, which is what makes it happen…
    1. If you don’t already have the Group Policy Management Console (GPMC) installed, now would be a good time to install it (http://www.microsoft.com/windowsserver2003/gpmc/default.mspx).
    2. You should understand how the Group Policy hierarchy works for best practices and performance. Simply put, you should apply settings for all systems at the domain level, and then use more specific policies applied to OUs to override the settings just for those machines (or users). For example, a standard WSUS
      configuration would include two policies:

      1. Create a policy called “Domain WSUS Policy” that is linked at the top of the domain tree, applying to everything below it. In here you would set the WSUS server location and have the settings you want for
        all domain desktops.
      2. Create a second policy called “WSUS Server Policy” and link it to the “Domain Controllers” and “Member Servers” OUs. This policy only needs a few settings to override the domain-level ones, such as having the servers only “Download & Notify” when there are new updates and not install and reboot themselves.
    3. Follow the recommended settings below. I have annotated these carefully, because the values aren’t clear and you can do something stupid if you don’t know what you’re setting. Too many times I have seen bad settings causing middle-of-the-day reboots, etc.

Group Policy Settings

Under Computer Configuration\Administrative Templates\Windows Components\Windows Update:

  • Configure Automatic Updates → Pick a time, then typically “Download & Notify” (for your servers policy, or for fussy people) or “Download & Install” (for for domain/desktop policy).
  • Specify intranet Microsoft update service location → http://<servername>:<portnumber>
  • Enable client-side targeting → Set to the group name you want to use for each policy; e.g. “Servers” and “Desktops”. Make sure you create the group in the WSUS Console before you do this, or it won’t show up right!
  • Do not change the “Automatic Updates Detection Frequency”. Really! It won’t do anything useful (except perhaps slow down the target systems) if you change it.
  • Enable recommended updates → Enabled (since we approve them with WSUS).
  • No auto-restart for schedule automatic updates installations → On your server policy, enable this to prevent restarts.
  • Allow automatic updates immediate installation → As these little non-rebootable updates still may cause problems, I recommend disabling this on your server policy.
  • Re-prompt for restart with schedule installations → You can increase this value (the time period between the “you need to reboot your computer” warnings) if you want to.

Test your new settings

  • Run gpupdate /force on the server you’re on, then check the Resultant Set of Policy to see if the Group Policy applied as you expected.
  • Run wuauclt.exe /detectnow on the server you’re on, then check the WSUS console to see if the server appears in the group you specified.
  • Run rsop.msc to see resultant policy. (Note that the Resultant Set of Policy wizard is deprecated, so it may be better to use the “Group Policy Results” section of the GPMC.)

Helpful Resources

Troubleshooting WSUS