Some content in this article was written by Marta Barillas, a SDET on the WSUS team.

Did you know that 80% of the content in Microsoft Update (MU) is drivers? Drivers represent a huge amount of content, so if your organization has standard devices, or you know what drivers are needed by your users, you can dramatically reduce the amount of metadata and content in your WSUS server by not syncing the "Drivers" category to WSUS.

Instead, you can selectively import drivers from the catalog by using a feature in the WSUS UI. Please note, this is only available through a WSUS Management Console of same version as the WSUS Service that is connected to in remote scenarios.

1. Launch WSUS console
2. Click on the “Updates” node (left panel)
3. Click on “Import Updates” (right panel)
4. Search and download the update from the opened IE page

Once you have downloaded the update using the Microsoft Update Catalog, the update will appear in "All updates." From there, you can approve the update, assign it to target groups, and set deadlines.

click the screenshot above to enlarge

When you use System Center Configuration Manager (SCCM) to manage updates, SCCM causes clients not to use WSUS servers directly for all operations (such as reporting). In this configuration, it is possible for multiple WSUS instances as part of SCCM to share the same database but not be configured as a NLB cluster. Technet states:

When you install more than one software update point at a primary site, use the same WSUS database for each software update point in the same Active Directory forest. If you share the same database, it significantly mitigates, but does not completely eliminate the client and the network performance impact that you might experience when clients switch to a new software update point. A delta scan still occurs when a client switches to a new software update point that shares a database with the old software update point, but the scan is much smaller than it would be if the WSUS server had its own database.

To set up such a configuration, you would install multiple SCCM SUPs with WSUS on shared database, configure WSUS/SUP to store content on a file share, but stopping short of enabling NLB.

1. Install SQL
2. Install first WSUS server creating database
3. Install other WSUS servers creating database
4. Create share for content (computer accounts must have change permission)
5. On first WSUS server Use WSUSutil movecontent to change location
6. On each WSUS server, in IIS ensure the “Content” virtual directory path is set to the share, and specify an account to use to connect to the path (to cater for anonymous access).
7. Add SUP (Software Update Point) role to first server and synch.
8. Add SUP role to other servers.

Rather than connecting to WSUS directly, clients are choosing a random SUP to connect to (which is their expected behavior, and why the NLB is not needed on the server side). This is a supported configuration of WSUS, but only when WSUS is being used in a SCCM deployment.

Some content in this section was written by Marta Barillas, a SDET on the WSUS engineering team.

This blog post applies to Windows Server 2012 and Windows Server 2012 R2.

• For instructions using WSUS 3.x with NLB, please see this TechNet article: http://technet.microsoft.com/library/dd939896(v=ws.10).aspx
• NLB is not supported on WSUS 2.x or earlier versions. WSUS 2.x is out of support and if you are still using it, you should upgrade to WSUS 3.2 which is available free of charge from Microsoft.

Requirements for NLB in WSUS 6.x

The requirements to run WSUS in a NLB cluster include:

• All nodes in the NLB cluster should be running the same version of WSUS and the same version of Windows, and should have the same Windows Updates installed. Prior to Windows Server 2012, the same WSUS-specific patches must also be installed across all servers in the cluster.
• SQL DB should be shared across all WSUS from the same NLB (WID is not supported for NLB, and the SQL DB need not be clustered -- though it may be clustered) *
• Content directory should be shared across all WSUS in that NLB cluster (see "Configuring Content Sharing") below*

* If you are not running WSUS in a NLB configuration, then the WSUS servers must not share a database or content directory.

Prior to Windows Server 2012, WSUS 3.2 requires a special set up command line as described in the Network Load Balancing topic in WSUS 3.x documentation. Please refer to that documentation (in the in-box HTML help/CHM file) if you are using WSUS 3.2.

Additionally, all requirements for NLB also apply above and beyond the requirements discussed above.

Sample test configuration

• WSUS 6.3 --- Windows Server 2012 R2 (2 units)
• SQL Server --- SQL Server 2012 SP1 (1 unit)
• WSUS Client ---- Windows 7 SP1 (1 unit)

Step 1. Install WSUS

The steps to install WSUS are the same for NLB and non-NLB scenarios. You can install WSUS using PowerShell or Server Manager.

Note: When you use PowerShell to install WSUS 6.x, you must run post-installation tasks from the command line.

Option1: Install WSUS for NLB using PowerShell (recommended)

1. Run this PowerShell command to install WSUS and the RSAT management tools:

Install-WindowsFeature updateservices-services,updateservices-db,updateservices-rsat

Note: updateservices-rsat is Optional; it will install the WSUS MMC console and cannot be installed when installing WSUS on a Server Core installation.

1. Once you have installed WSUS from the command line you need to run postinstall from the command line.

& 'C:\Program Files\Update Services\Tools\WsusUtil.exe' postinstall SQL_INSTANCE_NAME=<Name> CONTENT_DIR=<Path>

Note:

• SQL_INSTANCE_NAME is the name of the SQL Server & CONTENT_DIR is the path to the directory where downloaded update files will be stored. CONTENT_DIR should be a UNC path, as mapped network drives are NOT supported. For example, for example \\server1\share1\contentdir would be valid. Z:\contentdir would NOT be valid.
• For simplicity in testing, you can use an account that has administrator privileges on the SQL server, and you can also use the default instance. You don't need to specify a named instance.
• This step should be run in serial (not in parallel) across all WSUSs in the NLB.
• All WSUS servers in the NLB group must use the same content directory and the same SQL database.

Option 2: Install WSUS for NLB using Server Manager

Alternatively, you can install WSUS using the Server Manager GUI.

1. Launch Server Manager
2. Select “Add roles and features”
3. Click Next until reaching “Server Selection” tab, and select the server name to perform installation.

Note: local server is selected by default.

1. Click Next to “Server Roles” tab, and select “Windows Server Update Services”

1. A dialog will be displayed asking to include Features required for WSUS installation.
2. If WSUS Console should not be installed, uncheck “Include management tools” option on the dialog box.
3. Click “Add Features” on the dialog box.

• Click Next until reaching “ Role Services” tab, and:

1. Unselect “WID Database” option
2. Select “WSUS Services” & “Database” options

• Click Next to “Content” tab, and type the shared ContentDir path. This should be a UNC path, as mapped network drives are NOT supported.
• Click Next to “DB Instance” tab, and type the SQL Server machine name.

1. Click the “Check connection” button.

• Click Next to “Confirmation” tab
• Click “Install” and wait for installation to complete.
• Click on “Launch Post-Installation tasks” link displayed after installation is completed.

Note: This step must be run in serial (not in parallel) across all WSUSs in the NLB.

Step 2. Configure Content Sharing

WSUS Content Sharing is required when using a Shared Database. Documentation for creating a shared file location can be found at: http://technet.microsoft.com/library/dd939896(v=ws.10).aspx. Relevant portions of that article are included here:

Create a shared file location

You should create a single shared file location that is available to all of the front-end WSUS servers. You can use a standard network file share and provide redundancy by storing updates on a RAID controller, or you can use a Distributed File System (DFS) share. The domain machine account of each front-end WSUS server must have Change permissions on the root folder of the file share. That is, if there is a WSUS server installed locally on the computer that has the DFS share, the Network Service account should have change permissions on the root folder. In addition, the user account of the administrator who will run WsusUtil.exe movecontent should have Change permissions.

After you install a WSUS update, check the NTFS file system permissions for the WSUSContent folder. The NTFS file system permissions for the WSUSContent folder may be reset to the default values by the installer.

It is not necessary to use a DFS share with an NLB cluster. You can use a standard network share, and you can ensure redundancy by storing updates on a RAID controller.

For Windows Server 2012 (WSUS 6.2), The Scripting Guy wrote about the command line and GUI steps to be used to install a Front-End WSUS Server: http://blogs.technet.com/b/heyscriptingguy/archive/2013/04/15/installing-wsus-on-windows-server-2012.aspx

Step 3. Install/Configure NLB

The actual configuration of NLB is detailed on TechNet here: http://technet.microsoft.com/en-us/library/cc754833(v=WS.10).aspx

In our own NLB test environment, we have the following settings set to ON:

• Single affinity
• Unicast
• “Enable spoofing MAC Address” ON (for the NIC in Hyper-V, if you are using a VM)

Step 4. Check that things are working

4.1. Test that the master server can switchover in the event of downtime

Run the following command to ensure that multiple servers are listed:

• Wsusutil listfrontendservers

Shut down the master server. Then run the command again (on a different WSUS machine) and verify that the master server has been switched.

4.2. Test the WSUS client connection

On the WSUS server, assuming that you are using the default port (8530), run the following command

• netstat -nao | find "8530"

Verify that clients are able to connect. On a client machine which is configured to use the WSUS NLB cluster, run the following command:

• wuauclt /resetauthorization /detectnow

Upgrade/Patch Considerations

Because of sharing same DB, patching can be tricky because only WSUS machines with the same version must be sharing DBs, as the DB schema could be changing as part of the patching.

If you are running WSUS in a NLB configuration, then you must upgrade all WSUS servers together. To do this, disconnect each server from the database & upgrade, then once all servers are disconnected from the database & content directory, you can start re-connecting WS2012 servers to the database & content directory. For one NLB cluster sharing a single database, you could follow these steps:

1. Backup the database.
2. Remove all WSUS machines from the NLB.
3. Stop the IIS services in all machines: ‘Net stop w3svc’
4. Stop the wsus services in all machines: ‘Net stop wsusservices’
5. Perform patching on all WSUS
6. From 1 of the WSUS machine, run postinstall. This will update the database, so it is not needed to be rerun from other servers.
7. Start the wsus services in all machines (if needed): ‘Net start wsusservices’
8. Start the IIS services in all machines (if needed): ‘Net start w3svc’
9. Enable WSUS machines on NLB.

This post was authored by Vivek Mishra on behalf of the .NET Framework team.

Hi WSUS Admins,

The Microsoft .NET Framework 4.5.1 will be made available via Windows Server Update Services on 26 Nov 2013 and this blog highlights some of the key aspects.

The .NET Framework is a development platform for building apps for Windows, Windows Phone, Windows Server, and Windows Azure. The .NET Framework 4.5.1 is a highly compatible, in-place update to the .NET Framework 4 and 4.5. The .NET Framework 4.5.1 can be installed fresh on any supported platform or can be used to upgrade your previous .NET 4 or 4.5 installation. The .NET Framework 4.5.1 also works side by side with older Framework versions lower than .NET 4.0. Applications that are based on earlier versions of the Framework will continue to run on the version targeted by default, after .NET Framework 4.5.1 is installed.

You can learn more about .NET Framework 4.5.1 here.

Useful information about this release:

1. The .NET Framework 4.5.1 and its corresponding language packs are being released for following supported platforms:

   Windows Vista SP2, Windows 7 SP1, Windows Server 2008 SP2, Windows Server 2008 R2 SP1, and Windows Server 2012.

2. The .NET Framework 4.5.1 Language Packs will also be available via WSUS, both to support the upgrade of previous language packs for .NET Framework 4 or 4.5 and for computers, that either have the localized version of the base operating system or have one or more Multilingual User Interface (MUI) packs installed.

3. On Windows 8.1, Windows RT 8.1 and Windows Server 2012 R2, .NET Framework 4.5.1 is available in-box, so you do not need to deploy or install the product separately.

4. On Windows 8 and Windows RT, customers can get the .NET Framework 4.5.1 by upgrading their computer to Windows 8.1 and Windows RT 8.1 respectively. There is currently no .NET Framework 4.5.1 Windows Update offering for these 2 platforms.

5. Enterprises, that have a specific need to block offering .NET Framework 4.5.1, on computers which can directly connect to Microsoft Update servers, can do so by deploying the blocker registry key as described in following Microsoft Knowledge Base:  

   KB2721187:  How to temporarily block the installation of the .NET Framework 4.5.1 and its corresponding language packs

On computers running the RTM release of Windows 8 and Windows Server 2012, Windows Update no longer defined when to install updates. Instead, Automatic Maintenance is used for that purpose, minimizing activity during active computer use. Windows Update on Windows 8 and Windows Server 2012 computers also has new restart logic that defaults to forcing a restart 3 days after the installation of updates instead of 15 minutes. To avoid unintended data loss, forced restarts also no longer occur if a user is not actively using the machine, able to see the restart notice, and save their work.

While these changes have proven to be beneficial to many end users, the lack of discrete control over Windows Update installations and system restarts disrupted some management scenarios. This update returns the ability to discretely control when Windows Update installs updates, and adds the capability to force a restart soon after those installations regardless of whether there might be an active user session.

Microsoft has updated the documentation to more fully explain how you can use these new group policy settings. This documentation is available here: http://support.microsoft.com/kb/2885694

KB2885694, included in update rollup KB2883201, is available today (October 8^th, 2013) on Windows Update and the Microsoft Update Catalog, and will be available soon on WSUS. We believe that this update will result in significantly improved uptime, reliability, and manageability; we hope you’ll agree.

In order for the below changes to take effect, this update must be installed on all client computers receiving the desired configuration. It should also be installed on the computers configuring the policy to expose the new and updated group policies.

Finally, these updates are already included in the final versions of Windows 8.1 and Windows Server 2012 R2, so if you are already planning to upgrade, there aren’t any additional updates you need to install.

Thank you for sharing your feedback with Microsoft!

The Windows Update and WSUS teams

Changes introduced by this update

KB 2885694 introduces two main changes that define how Windows Update on Windows 8 and Windows Server 2012 computers can be configured using group policy. All policies mentioned are located at this path:

Computer Configuration / Administrative Templates / Windows Components / Windows Update

When enabled with a value of 4…

The Configure Automatic Updates group policy works identically to the Windows 7 / Windows Server 2008 R2 and earlier behavior.

On Windows 8 and Windows Server 2012 without KB 2885694 installed, that policy could configure the main automatic updating setting, but configuring the scheduled install day and time had no effect. After installing KB 2885694, the policy will enable you to configure machines to:

• Install updates during automatic maintenance, the default behavior, or
• Install updates at the scheduled day and time defined in the policy

A new group policy called Always automatically restart at the scheduled time enables restarts soon after updates are installed, instead of 3 days later

By default in Windows 8 and Windows Server 2012, if the installation of important updates requires a system restart, one will be forced 3 days after their installation. The restart timer begins counting down only when a user is able to see it, helping prevent unintentional data loss in the middle of the night. More details about this default behavior are discussed in this blog post.

If you would instead like to force restarts following update installation, similar to Windows 7 / Windows Server 2008 R2 and earlier, you can enable the new “Always automatically restart…” policy. When the policy is enabled, a restart timer will always begin immediately after Windows Update installs important updates, instead of multiple days later.

The restart timer cannot be postponed once started, but the policy lets you configure the countdown timer to any value between 15 and 180 minutes. When the timer runs out, the restart will proceed even if the machine has signed-in users.

Note: If the group policy No auto-restart with logged on users for scheduled automatic updates installations is enabled, then the new “Always automatically restart…” policy has no effect.

Note: In Windows 8 and Windows Server 2012, the Delay Restart for scheduled installations continues to have no effect.

Example configurations

This post was written by Jordan Cohen on behalf of the Windows Update team.