Windows Server Update Services Overview

Applies To: Windows Server 2012 R2, Windows Server 2012

The Windows Server Update Service (WSUS) enables information technology administrators to deploy the latest Microsoft product updates. By using WSUS, administrators can fully manage the distribution of updates that are released through Microsoft Update to computers in their network. This topic provides an overview of this server role and more information about how to deploy and maintain WSUS.

Did you mean…

WSUS server role description

The WSUS server provides the features that administrators need to manage and distribute updates through a management console. In addition, a WSUS server can be the update source for other WSUS servers within the organization. The WSUS server that acts as an update source is called an upstream server. In a WSUS implementation, at least one WSUS server in the network must connect to Microsoft Update to get available update information. The administrator can determine, based on network security and configuration, how many other servers connect directly to Microsoft Update.

Practical applications

Update management is the process of controlling the deployment and maintenance of interim software releases into production environments. It helps you maintain operational efficiency, overcome security vulnerabilities, and maintain the stability of your production environment. If your organization cannot determine and maintain a known level of trust within its operating systems and application software, it might have a number of security vulnerabilities that, if exploited, could lead to a loss of revenue and intellectual property. Minimizing this threat requires you to have properly configured systems, use the latest software, and install the recommended software updates.

The core scenarios where WSUS adds value to your business are:

Centralized update management

Update management automation

New and changed functionality

Upgrade from any version of Windows Server that supports WSUS 3.2 to Windows ServerВ® 2012 R2 requires that you first uninstall WSUS 3.2. In Windows Server 2012, upgrading from any version of Windows Server with WSUS 3.2 installed is blocked during the installation process if WSUS 3.2 is detected, and you are prompted to first uninstall Windows Server Update Services prior to upgrading Windows Server 2012. However, because of changes in Windows Server 2012 R2, when upgrading from any version of Windows Server and WSUS 3.2 to Windows Server 2012 R2, the installation is not blocked. Failure to uninstall WSUS 3.2 prior to performing a Windows Server 2012 R2 upgrade will cause the post installation tasks for WSUS in Windows Server 2012 R2 to fail. In this case, the only known corrective measure is to format the hard drive and reinstall Windows Server 2012 R2.

Windows Server Update Services is a built-in server role that includes the following enhancements:

Can be added and removed by using the Server Manager

Includes Windows PowerShell cmdlets to manage the ten most important administrative tasks in WSUS

Adds SHA256 hash capability for additional security

Provides client and server separation: Versions of the Windows Update Agent (WUA) can ship independently of WSUS

Feature and functionality

Windows ServerВ 2008В R2

Windows Server 2012 and Windows Server 2012 R2

Inclusion of Windows PowerShell cmdlets to manage the ten most important administrative tasks in WSUS

Security enhancements with SHA256 hash capability

Client and server separation: Versions of the Windows Update Agent (WUA) can ship independently of WSUS

Using Windows PowerShell to manage WSUS

For system administrators to automate their operations, they need coverage through command-line automation. The main goal is to facilitate WSUS administration by allowing system administrators to automate their day-to-day operations.

What value does this change add?

By exposing core WSUS operations through Windows PowerShell, system administrators can increase productivity, reduce the learning curve for new tools, and reduce errors due to failed expectations resulting from a lack of consistency across similar operations.

What works differently?

In earlier versions of the Windows Server operating system, there were no Windows PowerShell cmdlets, and update management automation was challenging. The Windows PowerShell cmdlets for WSUS operations add flexibility and agility for the system administrator.

Removed or deprecated functionality

In this release of WSUS, the API is updated to the .NET FrameworkВ 4.5.

System requirements

The minimum hardware requirements for WSUS are:

Processor: 1.4В gigahertz (GHz) x64В processor (2В Ghz or faster is recommended)

Memory: WSUS requires an additional 2 GB of RAM more than what is required by the server.

Available disk space: 10В GB (40В GB or greater is recommended)

Network adapter: 100В megabits per second (Mbps) or greater

See also

The following table lists references for more information about WSUS:

Windows Server Update Services (WSUS)

Applies To: Windows Server (Semi-Annual Channel), Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

Windows Server Update Services (WSUS) enables information technology administrators to deploy the latest Microsoft product updates. You can use WSUS to fully manage the distribution of updates that are released through Microsoft Update to computers on your network. This topic provides an overview of this server role and more information about how to deploy and maintain WSUS.

WSUS Server role description

A WSUS server provides features that you can use to manage and distribute updates through a management console. A WSUS server can also be the update source for other WSUS servers within the organization. The WSUS server that acts as an update source is called an upstream server. In a WSUS implementation, at least one WSUS server on your network must be able to connect to Microsoft Update to get available update information. As an administrator, you can determine — based on network security and configuration — how many other WSUS servers connect directly to Microsoft Update.

Practical applications

Update management is the process of controlling the deployment and maintenance of interim software releases into production environments. It helps you maintain operational efficiency, overcome security vulnerabilities, and maintain the stability of your production environment. If your organization cannot determine and maintain a known level of trust within its operating systems and application software, it might have a number of security vulnerabilities that, if exploited, could lead to a loss of revenue and intellectual property. Minimizing this threat requires you to have properly configured systems, use the latest software, and install the recommended software updates.

The core scenarios where WSUS adds value to your business are:

Centralized update management

Update management automation

New and changed functionality

Upgrade from any version of Windows Server that supports WSUS 3.2 to Windows Server 2012 R2 requires that you first uninstall WSUS 3.2.

In Windows Server 2012, upgrading from any version of Windows Server with WSUS 3.2 installed is blocked during the installation process if WSUS 3.2 is detected. In that case, you will be prompted to first uninstall Windows Server Update Services prior to upgrading your server.

However, because of changes in this release of Windows Server and Windows Server 2012 R2, when upgrading from any version of Windows Server and WSUS 3.2, the installation is not blocked. Failure to uninstall WSUS 3.2 prior to performing a Windows Server 2012 R2 upgrade will cause the post installation tasks for WSUS in Windows Server 2012 R2 to fail. In this case, the only known corrective measure is to format the hard drive and reinstall Windows Server.

Windows Server Update Services is a built-in server role that includes the following enhancements:

Can be added and removed by using the Server Manager

Includes Windows PowerShell cmdlets to manage the most important administrative tasks in WSUS

Adds SHA256 hash capability for additional security

Provides client and server separation: versions of the Windows Update Agent (WUA) can ship independently of WSUS

Using Windows PowerShell to manage WSUS

For system administrators to automate their operations, they need coverage through command-line automation. The main goal is to facilitate WSUS administration by allowing system administrators to automate their day-to-day operations.

What value does this change add?

By exposing core WSUS operations through Windows PowerShell, system administrators can increase productivity, reduce the learning curve for new tools, and reduce errors due to failed expectations resulting from a lack of consistency across similar operations.

What works differently?

In earlier versions of the Windows Server operating system, there were no Windows PowerShell cmdlets, and update management automation was challenging. The Windows PowerShell cmdlets for WSUS operations add flexibility and agility for the system administrator.

In this collection

The following guides for planning, deploying, and managing WSUS are in this collection:

Windows Server Update Services best practices

This article provides tips for avoiding configurations that experience poor performance because of design or configuration limitations in WSUS.

Original product version: В Configuration Manager (current branch), Windows Server Update Services
Original KB number: В 4490414

Capacity limits

Although WSUS can support 100,000 clients per server (150,000 clients when you use Configuration Manager), we don’t recommend approaching this limit.

Instead, consider using a configuration of 2-4 servers sharing the same SQL Server database. This way you have safety in numbers. If one server goes down, it won’t immediately spoil your weekend because no client can update while you must be updated against the latest zero-day exploit.

The shared database scenario also prevents a scan storm.

A scan storm can occur when many clients change WSUS servers and the servers don’t share a database. WSUS tracks activity in the database, so that both know what has changed since a client last scanned and will only send metadata that’s updated since then.

If clients change to a different WSUS server that uses a different database, they must do a full scan. A full scan can cause large metadata transfers. Transfers of greater than 1 GB per client may occur in these scenarios, especially if the WSUS server isn’t maintained correctly. It can generate enough load to cause errors when clients communicate with a WSUS instance. And clients retry repeatedly in this case.

Sharing a database means when a client switches to another WSUS instance that uses the same DB, the scan penalty isn’t incurred. The load increases aren’t the large penalty you pay for switching databases.

Configuration Manager client scans put more demand on WSUS than the stand-alone Automatic Updates. Configuration Manager, because it includes compliance checking, requests scans with criteria that will return all updates that are in any status except declined.

When the Automatic Updates Agent scans, or you select Check for Updates in Control Panel, the agent sends criteria to retrieve only those updates Approved for Install. The metadata returned will usually be less than when the scan is initiated by Configuration Manager. The Update Agent does cache the data, and the next scan requests will return the data from the client cache.

Disable recycling and configure memory limits

WSUS implements an internal cache that retrieves the update metadata from the database. This operation is expensive and very memory intensive. It can cause the IIS application pool that hosts WSUS (known as WSUSPool) to recycle when WSUSPool overruns the default private and virtual memory limits.

When the pool recycles, the cache is removed and must be rebuilt. It isn’t a large problem when clients are undergoing delta scans. But if you end up in a scan storm scenario, the pool will recycle constantly. And clients will receive errors when you make scan requests, such as HTTP 503 errors.

We recommend that you increase the default Queue Length, and disable both the Virtual and Private Memory Limit by setting them to 0. IIS implements an automatic recycling of the application pool every 29 hours, Ping, and Idle Time-outs, all which should be disabled. These settings are found in IIS Manager > Application Pools > choose WsusPool and then click the Advanced Settings link in the right side pane of IIS manager.

Here’s a summary of recommended changes, and a related screenshot. For more information, see Plan for software updates in Configuration Manager.

Setting name	Value
Queue Length	2000 (up from default of 1000)
Idle Time-out (minutes)	0 (down from the default of 20)
Ping Enabled	False (from default of True)
Private Memory Limit (KB)	0 (unlimited, up from the default of 1,843,200 KB)
Regular Time Interval (minutes)	0 (to prevent a recycle, and modified from the default of 1740)

In an environment that has around 17,000 updates cached, more than 24 GB of memory may be needed as the cache is built until it stabilizes (at around 14 GB).

Check whether compression is enabled (if you want to conserve bandwidth)

WSUS uses a compression type calls Xpress encoding. It implements compression on update metadata, and can result in significant bandwidth savings.

Xpress encoding is enabled in IIS ApplicationHost.config with this line under the element and a registry setting:

ApplicationHost.Config

Registry key

If both aren’t present, it can be enabled by running this command and then restarting the WsusPool application pool in IIS.

Xpress encoding will add some CPU overhead, and can be disabled if bandwidth isn’t a concern, but CPU usage is. The following command will turn it off.

Configure products and categories

When you configure WSUS, choose only the products and categories that you plan to deploy. You can always synchronize categories and products that you must have later. Adding them when you don’t plan to deploy them increases metadata size and overhead on the WSUS servers.

Disable Itanium updates and other unnecessary updates

It shouldn’t be an issue for much longer, because Windows Server 2008 R2 was the last version to support Itanium. But it bears mentioning.

Customize and use this script in your environment to decline Itanium architecture updates. The script can also decline updates that contain Preview or Beta in the update title.

It leads to the WSUS console being more responsive, but doesn’t affect the client scan.

Decline superseded updates and run maintenance

One of the most important things that you can do to help WSUS run better. Keeping updates around that are superseded longer than needed (for example, after you’re no longer deploying them) is the leading cause of WSUS performance problems. It’s ok to keep them around if you’re still deploying them. Remove them after you’re done with them.

For information about declining superseded updates and other WSUS maintenance items, see the Complete guide to Microsoft WSUS and Configuration Manager SUP maintenance article.

WSUS with SSL setup

By default, WSUS isn’t configured to use SSL for client communication. The first post-install step should be to configured SSL on WSUS to make sure security between server-client communications.

You must take one the following actions:

• Create a self-signed certificate. It isn’t ideal because every client would have to trust this certificate.
• Obtain one from a third-party certificate provider.
• Obtain one from your internal certificate infrastructure.

Your certificate must have the short server name, FQDN, and SAN names (aliases) that it goes by.

After you have the certificate installed, upgrade the Group Policy (or Client Configuration settings for software updates in Configuration Manager) to use the address and SSL port of the WSUS server. The port is typically 8531 or 443.

For example, configure GPO Specify intranet Microsoft update service location to https://wsus.contoso.com:8531 >.

Configure Antivirus Exclusions

About Cumulative Updates and Monthly Rollups

You may see the terms Monthly Rollups and Cumulative Update used for Windows OS updates. They may be used interchangeably. Rollups refer to the updates published for Windows 7, Windows 8.1, Windows Server 2008 R2, and Windows Server 2012 R2 that are only partly cumulative.

For more information, see the following blog posts:

With Windows 10 and Windows Server 2016, the updates were cumulative from the beginning:

Cumulative means that: you install the release version of the OS, and only have to apply the latest Cumulative Update to be fully patched. For the older operating systems, we don’t have such updates yet, although it’s the direction we’re heading in.

For Windows 7 and Windows 8.1, it means that after you install the latest monthly rollup, more updates will still be needed. Here’s an example for Windows 7 and Windows Server 2008 R2 on what it takes to have an almost fully patched system.

The following table contains the list of Windows Monthly Rollups and Cumulative Updates. You can also find them by searching for Windows update History.

Windows version	Update
Windows 7 SP1 and Windows Server 2008 R2 SP1	Windows 7 SP1 and Windows Server 2008 R2 SP1 update history
Windows 8.1 and Windows Server 2012 R2	Windows 8.1 and Windows Server 2012 R2 update history
Windows 10 and Windows Server 2016	Windows 10 and Windows Server update history
Windows Server 2019	Windows 10 and Windows Server 2019 update history

Another point to consider is that not all updates are published so that they sync automatically to WSUS. For example, C and D week Cumulative Updates are preview updates and won’t synchronize to WSUS, but must be manually imported instead. See the Monthly quality updates section of Windows 10 update servicing cadence.

Using PowerShell to connect to a WSUS server

Here’s just a code example to get you started with PowerShell and the WSUS API. It can be executed where the WSUS Administration Console is installed.