WSUS FOR VARS

OVERVIEW

Windows Update is ubiquitous and Microsoft believes that the application of the latest updates and service packs contain the fix to all IT problems. Those of us in the IT support trenches are far more skeptical of the rapid and un-tested application of patches and service packs in to the environments that we are in charge of. There is a 125 Page document available from Microsoft called “Deploying Microsoft Windows Server Update Services 3.0 SP1” by Susan Norwood which I have digested into these few pages I strongly recommend you consult this document if you need to introduce advanced patch management functionality into your environment. Reading forward I discuss a basic WSUS deployment at a VAR level into a multi-client environment. The intent is to allow the VAR to build a WSUS facility to test and control the deployment of patches to client sites.

Two modes of patch deployment can be envisioned. A simple mode where all clients, even across multiple subnets are configured using a local DNS or Hosts file entry to update from a WSUS server controlled by a VAR. This implementation is less bandwidth friendly, and is suitable for smaller network s with ten or less clients.

Or a more complex mode where there is a VAR WSUS with multiple downstream client WSUS servers (physical or virtual) located at a client site(s). This implementation is more bandwidth friendly, and is suitable for larger network s with ten or more clients.

Both of these deployments allow a VAR to control, monitor and report on patches in multiple environments. An excellent relationship between VAR and client can be created and sustained by offering a complete patch management solution.

WSUS is a service you run inside your network - on one or more servers which you configure to serve software updates to one or more clients or WSUS replica servers. You can configure a WSUS server to download updates either from Microsoft or from another WSUS server within or outside your organization. Once you approve an update for installation, WSUS downloads it from the configured upstream partner, and can then issue these updates to clients that request it. You can approve any update for some, all, or none of your computers. Once an update is approved, the targeted WSUS clients download the update using the Windows Automatic Update client. WSUS also provides reports on which clients have, and have not, had updates. This allows for prudently testing updates on individual client workstations (physical or virtual) before releasing the patch for client wide installation.

WSUS provides a capability that allows the clients to obtain and install updates. However, it does not provide an internal version of the Windows Update site, thus your users can not navigate to your WSUS server and obtain updates (as they can when they navigate to Microsoft's Windows Update site).

TECHNICAL IMPLEMENTATION

The WUS Server requires the below windows programs and services installed and after installation it is a good idea to patch and update the WSUS box directly from Windows Update. The Hardware requirements for WSUS are largely dependent on the number of clients and MS products you are going to support but you can consider that the WSUS server runs IIS and a Database and will be downloading and uploading constantly; you can see why it may require a fairly beefy platform.

Microsoft’s belief that a WSUS server with a 1 GHZ Pentium III processor and 512 MB RAM is adequate (not including OS memory and RAM requirements) to support a small network is fairly reasonable. However, the Microsoft recommendation for a WSUS server with a dual processor 3 GHZ Pentium IV for 10,000 Clients is not realistic. A Windows 2003 Server which is expected to host a 20GB+ size Data Base, run IIS Server in a physical or virtual implementation needs at least 1GB of RAM and 60GB’s of HDD space, and a good duel core processor, especially if running in a virtual environment.

1. Microsoft Internet Information Services (IIS) 6.0. (Just add it when you install the OS & make sure that ASP.NET is selected)

2. Microsoft .NET Framework Version 2.0 Redistributable Package, available on the Microsoft Download Center (It is usually pulled down when you update the box, framework 2.5 is fine)

3. Microsoft Management Console 3.0 for Windows Server 2003 (KB907265), available on the Microsoft Download Center

4. Microsoft Report Viewer Redistributable 2005, available on the Microsoft Download Center

5. Download and Install WSUS (After patching and updating) http://www.microsoft.com/downloads/details.aspx?FamilyID=e4a868d7-a820-46a0-b4db-ed6aa4a336d9&displaylang=en

(If you are using SBS 2003 this is an excellent link http://technet.microsoft.com/en-us/library/cc708091.aspx, However I do not under any circumstances recommend that WSUS be installed on a SBS running MS Exchange)

Incorporating WSUS into your environment requires planning and you need to have a solid Active Directory network foundation and decent bandwidth; I recommend that you establish a WSUS server in each subnet to insure that client PC’s are not pulling down updates across a WAN. WSUS uses the Background Intelligent Transfer Service 2.0 (BITS) protocol for all its file-transfer tasks, including downloads to clients and server synchronizations. BITS is a Microsoft technology that allows programs to download files by using spare bandwidth. BITS maintains file transfers through network disconnections and computer restarts. It is an excellent idea to include the BITS install as part of your corporate “image” or a pre-deployment installation task in order to insure that the clients can update from the WSUS platform. Keep in mind hard working workstations that are running low on resources may not have spare bandwidth. If the above mentioned workstation is turned on in the morning and turned off at the end of the day and a Service Pack is being pushed out by the WSUS server it may take weeks to deploy a Service Pack to this workstation.

Configuring the WSUS Server:

The WSUS 3.0 configuration wizard will be run immediately after installation or at a later time. If you want to change the configuration later, you run WSUS Server Configuration Wizard from the Options page of the WSUS 3.0 Administration console. Before configuring the WSUS server, make sure you know the answers to the following questions:

1. Is the server's firewall configured to allow clients to access the server?

2. Can this machine connect to the upstream server (Microsoft Update or an upstream WSUS server)?

3. If this machine is the root WSUS server (the one that connects to Microsoft Update), will it use a proxy server?

4. If a proxy server will be used, does it support both HTTP and SSL protocols?

5. Do you have the name of the proxy server and the user credentials for the proxy server?

6. Do you know the port number on which this machine will connect to the upstream server? Microsoft Update and WSUS require ports 80 and 443 to be open to outbound traffic.

The Configuration Wizard allows you to configure the following areas:

Choose the Upstream Server

Specify the Proxy Server

Connect to the Upstream Server

Choose Update Languages

Choose Update Products

Choose Update Classifications

Configure the Synchronization Schedule

Configuring the Client PC’s

Configuring client PC’s and Servers is best achieved with Active Directory Group Policy objects; and it is a good idea to engage Sr. Management in a discussion around what the update policy will be. I broach this topic due to the massive inconvenience that may be perceived by forced installation, forced reboots and re-occurring nag screens can cause in an environment. The GPO controls for WSUS do not appear as part of the standard GPO’s and you need to follow these steps to get it to appear in the Microsoft Management Console using the Active Directory snap-in.

1. In the Group Policy Object Editor, click either of the Administrative Templates nodes.

2. On the Action menu, click Add/Remove Templates.

3. Click Add.

4. In the Policy Templates dialog box, select wuau.adm, and then click Open.

5. In the Add/Remove Templates dialog box, click Close.

The GPO’s available in this template allow for greater control of the updating process., keep in mind that GPO changes take time to replicate in an AD environment!

Configure Automatic Updates:

The setting for this policy enable you to configure how Automatic Updates works. You must specify that Automatic Updates download updates from the WSUS server rather than from Windows Update.

Specify intranet Microsoft Update service location:

The settings for this policy enable you to specify a WSUS server that Automatic Updates will contact for updates. You must enable this policy in order for Automatic Updates to download updates from the WSUS server.

Enter the WSUS server HTTP(S) URL twice, so that the server specified for updates is also used for reporting client events. For example, type http(s)://servername in both boxes, where servername is the name of the server. Both URLs are required.

Enable client-side targeting:

This policy enables client computers to add themselves to target computer groups on the WSUS server, when Automatic Updates is redirected to a WSUS server.

If the status is set to Enabled, this computer will identify itself as a member of a particular computer group when it sends information to the WSUS server, which uses it to determine which updates should be deployed to this computer. This setting indicates to the WSUS server which group the client computer should use. You must actually create the group on the WSUS server.

If the status is set to Disabled or Not Configured, no computer group information will be sent to WSUS.

This feature is excellent to clearly identify a virtual or physical test workstation from the production servers or workstations in the environment.

Reschedule Automatic Updates scheduled installations:

This policy specifies the amount of time that Automatic Updates should wait after system start-up before proceeding with a scheduled installation that did not take place earlier.

If the status is set to Enabled, a missed installation will occur the specified number of minutes after the computer is next started.

If the status is set to Disabled, a missed installation will occur with the next scheduled installation.

If the status is set to Not Configured, a missed installation will occur one minute after the next time the computer is started.

This policy applies only when Automatic Updates is configured to perform scheduled installations of updates. If the Configure Automatic Updates policy is disabled, this policy has no effect.

No auto-restart for scheduled Automatic Update installation options:

This policy specifies that, to complete a scheduled installation, Automatic Updates will wait for the computer to be restarted instead of causing the computer to restart automatically.

If the status is set to Enabled, Automatic Updates will not restart a computer automatically during a scheduled installation if a user is logged on to the computer. Instead, Automatic Updates will notify the user to restart the computer in order to complete the installation. Be aware that Automatic Updates will not be able to detect future updates until the restart occurs.

If the status is set to Disabled or Not Configured, Automatic Updates will notify the user that the computer will automatically restart in five minutes to complete the installation. This policy applies only when Automatic Updates is configured to perform scheduled installations of updates. If the Configure Automatic Updates policy is disabled, this policy has no effect.

In most environments you need to enable this as restarting workstations automatically or nagging users who are temporarily away from their workstations may not win the hearts and minds of your customers. This could cause data loss if files are not closed out properly.

Automatic Update detection frequency:

This policy specifies the number of hours that Windows will wait before checking for available updates. The exact wait time is determined by using the number of hours specified minus a random value between 0 and 20 percent of that number. For example, if this policy is used to specify a 20-hour detection frequency, then all computers to which this policy is applied will check for updates anywhere between 16 and 20 hours.

If the status is set to Enabled, Automatic Updates will check for available updates at the specified interval.

If the status is set to Disabled or Not Configured, Automatic Updates will check for available updates at the default interval of 22 hours.

Allow Automatic Update immediate installation:

This policy specifies whether Automatic Updates should automatically install certain updates that neither interrupt Windows services nor restart Windows.

If the status is set to Enabled, Automatic Updates will immediately install these updates after they have been downloaded and are ready to install.

If the status is set to Disabled, such updates will not be installed immediately.

This setting is real life saver and insures that critical and security updates that don’t require a reboot get installed right away on approval. Most users will notice a slow down while the updates install in the background & thankfully most of these types of updates (not requiring a re-boot) are small.

Delay restart for scheduled installations:

This policy specifies the amount of time that Automatic Updates should wait before proceeding with a scheduled restart.

If the status is set to Enabled, a scheduled restart will occur the specified number of minutes after the installation is finished.

If the status is set to Disabled or Not Configured, the default wait time is five minutes.

You need to consult the management around the requirement for nag screens or threatened reboots; users are frequently in and out of the office and may not be able to respond. This could cause data loss if files are not closed out properly.

Re-prompt for restart with scheduled installations:

This policy setting specifies the amount of time that Automatic Updates should wait before prompting the user again for a scheduled restart.

If the status is set to Enabled, a scheduled restart will occur the specified number of minutes after the prompt for restart was dismissed.

If the status is set to Disabled or Not Configured, the default interval is 10 minutes.

Again you need to consult the management around the requirement for nag screens or threatened reboots; users are frequently in and out of the office and may not be able to respond. This could cause data loss if files are not closed out properly.

Allow non-administrators to receive update notifications:

This policy specifies whether logged-on non-administrative users will receive update notifications. If Automatic Updates is configured (by policy or locally) to notify the user either before downloading and installation or only before installation, these notifications will be offered to any user, administrator, or non-administrator who is logged on to the computer.

If the status is set to Enabled, Automatic Updates will include non-administrators when determining which logged-on user should receive notification.

If the status is set to Disabled or Not Configured, Automatic Updates will notify only logged-on administrators.

I believe that letting users know what is happening with their workstations is an important way of educating and communicating with the user community

Allow signed content from the intranet Microsoft update service location:

If this policy setting is enabled, Automatic Updates receives signed third-party updates from the Windows Server Update Services server. If this policy is not enabled, users will be able to get updates only from Microsoft.

Remove links and access to Windows Update:

If this policy setting is enabled, Automatic Updates receives updates from the WSUS server. Users who have this policy setting enabled cannot get updates from a Windows Update Web site that you have not approved. If this policy setting is not enabled, the Windows Update icon remains on the Start menu; local administrators will be able to visit the Windows Update Web site, from which they could install unapproved software. This happens even if you have specified that Automatic Updates must get approved updates from your WSUS server. In Windows Vista, this setting will gray out the Check for updates option in the Windows Update application.

Disable access to Windows Update:

If this policy setting is enabled, all Windows Update features are removed. It blocks access to the Microsoft Update and Windows Update Web sites, and in Windows Vista will gray out the Check for updates option in the Windows Update application. The machine will not get automatic updates directly from Windows Update or Microsoft Update, but it can still get updates from a WSUS server. This setting overrides the user settings Remove links and access to Windows Update and Remove access to use all Windows Update features.

WSUS can be used in a non-domain environment by directly using registry or local policy entries; however keep in mind that windows firewall and permission issues in a non-windows domain may be difficult to work around. WSUS works best in an Active Directory Windows Domain.

MS Virtual PC or Server can provide the opportunity to have a unique or site specific virtual test client side by side with the production WSUS server to allow updates to be tested before they are approved for production release. The virtual test client is also handy for troubleshooting GPO’s which may have conflicting settings.

Special Attention should be paid to the reporting capabilities of the WSUS Server this is where Microsoft’s efforts have been focused since the previous versions of WSUS. The WUS Server provides a great summary over the overall health of the network and client specific reporting capability as well as the ability to email reports!