We recently announced on the Microsoft Update Product Team Blog a set of changes made to the Windows Update Agent. In an effort to provide additional protection for our WSUS customers, we are releasing an update that enhances the security of Windows Update, the Microsoft Update (WU/MU) Client, and Windows Server Update Services. The update applies to WSUS 3.0 SP2, as well as the WSUS role running on Windows Server 2012 and Windows Server 2012 R2.

Improvements include further hardening of the infrastructure used by WU/MU client and the communication channel between WU/MU Client and Service. Additionally, the communication channel between WSUS and WU/MU service has been hardened. This update to WSUS also rolls up all prior updates.

Details on the changes to the WU/MU client can be found at KB 2887535.

Details and additional considerations for the update to WSUS can be found at KB 2938066.

Downloads

The following files are available for download from the Microsoft Download Center:

Marta Barillas also wrote a significant portion of this blog posting.

Some customers have indicated that some update files are not being downloaded by WSUS after approval, which results in those updates being unavailable to clients.

For an update to be offered to clients, the following needs to happen:

1. Update must be approved to a target group in WSUS.

2. Update files must be available; so if WSUS is configured to store content locally, the update files must be successfully downloaded by WSUS.

Check if WSUS is configured to store content locally

The setting is controlled by a checkbox in the WSUS console.

When this is selected, if the update files fail to download to WSUS, the update will not be offered to Clients even though it has been approved.

Troubleshooting when WSUS is configured to store content locally

First, check if WSUS is syncing from another (upstream) WSUS server. (We’ll refer to the upstream WSUS server as USS and the downstream WSUS server as DSS henceforth).

If WSUS is syncing from another WSUS server, verify that the USS has the update files available by looking in the content directory on the USS. If the update files do exist on the USS, make sure that the DSS has access to:

1. the WsusContent folder on the USS
2. the root folder of the DSS WsusContent folder

If files are missing because they were never downloaded; ensure that files are downloaded by the Upstream WSUS (USS) and retry the download of the files on the Downstream WSUS (DSS).

If files are missing because the update has been declined and Cleanup Wizard has deleted the files from USS; proceed to decline the update from the DSS as well.

Note that in a WSUS hierarchy the Cleanup Wizard is recommended to be run from the bottom to the top in order to avoid DSS requesting updates that are no longer available on the USS.

Instructions for using the Server Cleanup Wizard are available on TechNet.

If files are missing because somehow they got deleted (not through WSUS Clean Up wizard); run Reset on USS and after files are available, retry the download of the files from the DSS. Please note that resetting a WSUS server can be a time consuming operation, as the reset happens for all the updates.

In order to run Reset, run the following command as an administrator:
%SystemDrive%\Program Files\Update Services\Tools\WsusUtil.exe reset

For help information run:
%SystemDrive%\Program Files\Update Services\Tools\WsusUtil.exe help reset

If WSUS is syncing from MU (there is no USS), verify that the update has not been Expired; otherwise it means that the update is no longer available. To verify that the update exists, search for it in the Microsoft Update Catalog.

•  If the update is no longer available from MU, Decline the update from the WSUS.

•  If the update exists, verify that WSUS has access to the root folder of the WsusContent folder.

The WSUS Team

A fix is now available from Microsoft that resolves the issue where some computers that have the KB 2919355 update for Windows 8.1 and Windows Server 2012 R2 installed stop scanning against Windows Server Update Services 3.0 Service Pack 2 (WSUS 3.0 SP2 or WSUS 3.2)-based servers that are configured to use HTTPS and do not have TLS 1.2 enabled. Direct download links, installation instructions, and more information you can use to check if you’re impacted by this issue, are provided on the KB 2959977 page.

• If you manually imported KB 2919355 prior to the issue of KB 2959977, you should decline the old revision on your WSUS server. Once you decline the revision in WSUS, it will no longer be distributed to clients.

• For all users (even if your environment was not impacted), we recommend that administrators approve the latest revision of KB 2919355 for distribution to enable deployment of Windows 8.1 Update in your environment.

Update Monday 4/14/2014 - Please see http://support.microsoft.com/kb/2959977 for additional information.

There is a known issue which causes some PCs updated with the Windows 8.1 Update (KB 2919355) to stop scanning against Windows Server Update Services 3.0 Service Pack 2 (WSUS 3.0 SP2 or WSUS 3.2) servers which are configured to use SSL and have not enabled TLS 1.2.

Issue Description

The problem is specific to the following scenario when all of the following are true

1. Client PC has installed Windows 8.1 Update KB 2919355
2. Windows 8.1 with Windows 8.1 Update KB 2919355 attempts to scan against WSUS 3.2 running on any affected platform:
   • Windows Server 2003 SP2, or
   • Windows Server 2003 R2 SP2, or
   • Windows Server 2008 SP2, or
   • Windows Server 2008 R2 SP1
3. HTTPS and Secure Sockets Layer (SSL) are enabled on the WSUS server
4. TLS 1.2 is not enabled on the server

Only users who have enabled HTTPS and have not enabled TLS 1.2 on their WSUS 3.2 servers and who are also using these WSUS 3.2 servers to manage PCs running the Windows 8.1 Update KB 2919355 are affected by this issue. Please note, while we do recommend the use of HTTPS on WSUS servers, HTTPS and TLS 1.2 are not enabled by default.

Workarounds

If you are using WSUS 3.2 on Windows Server 2008 R2, you may perform either of the following steps to restore the scan functionality if you have deployed the Windows 8.1 Update KB2919355.

• Enable TLS 1.2 (follow the instructions under More Information > SCHANNEL\Protocols subkey), or
• Disable HTTPS on WSUS

If you are using WSUS 3.2 on an operating system other than Windows Server 2008 R2, you may perform the following step to restore the scan functionality.

• Disable HTTPS on WSUS

When Microsoft releases an update that resolves the issue, you may re-enable HTTPS on WSUS.

Microsoft plans to issue an update as soon as possible that will correct the issue and restore the proper behavior for Windows 8.1 Update KB 2919355 scanning against all supported WSUS configurations. Until that time, we are delaying the distribution of the Windows 8.1 Update KB 2919355 to WSUS servers.

You may still obtain the Windows 8.1 Update (KB 2919355) from the Windows Update Catalog or MSDN. However, we recommend that you suspend deployment of this update in your organization until we release the update that resolves this issue. You may also find the workarounds discussed in this article to be useful for testing this Windows 8.1 Update for your organization. Thank you for your patience during this time.

The WSUS and Windows Update Teams

Symptoms

• When installing WSUS through the Add Roles and Features Wizard (ARW), the Post-Installation task fails and the generated log folder (*.tmp) is empty, AND
• The Tools folder is missing after WSUS was installed. Note: By default, the Tools folder is installed to the following location: %SystemDrive%\Program Files\Update Services\Tools

This behavior has been seen when:

• Uninstalling WSUS
• Manually deleting WSUS folder: %SystemDrive%\Program Files\Update Services
• Manually deleting WSUS registry keys: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update Services
• Re-installing WSUS

Root Cause

When uninstalling WSUS Role via ARW the “API and PowerShell cmdlets” feature is not uninstalled by default (unless explicitly selected by the user). Deleting the remaining WSUS folders and registry keys leaves the server in a bad state and the re-installation fails because it is expecting this feature to be already installed.

Workaround

Uninstall all the WSUS roles and features and re-install WSUS.

Workaround 1: To uninstall WSUS roles and features using Windows PowerShell

1. In PowerShell, review features installed by calling: Get-WindowsFeature UpdateServices*
2. To remove features, call: Uninstall-WindowsFeature <featureName>

Workaround 2: To uninstall WSUS roles and features using the Server Manager Console

In Server Manager, launch Remove Roles and Features Wizard (RRW), unselect items to be uninstalled, and complete the Wizard:

1. In Server Roles tab unselect ‘Windows Server Update Services’ option
2. In Features tab unselect ‘Remote Server Administration Tools -> Role Administration Tools -> Windows Server Update Services Tools’ option

We recommend restarting the server to ensure that all WSUS components are removed. After uninstalling WSUS roles and features, you may reinstall the WSUS roles and features.

To reinstall WSUS, launch the Add Roles and Features Wizard and then select the “Windows Server Update Services” option. You may optionally reinstall the Windows Server Update Services Tools. After the ARW completes successfully, you may run the WSUS post-installation tasks.

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.

We've had some questions recently about why WSUS in Windows Server 2012 R2 no longer supports generating self-signed certificates for signing update packages. We disabled this feature because it was causing a significant management burden for those using the feature, and it duplicated functionality that already exists in Windows Server Certificate Services (and other products).

• Distribution. After WSUS generates a certificate suitable for self-signing of packages, significant effort was required to export and install this self-signed certificate into all of the clients that needed to verify packages signed by it.
• Expiration. When the self-signed certificate expires, WSUS offered no functionality to notify you that the signatures were no longer valid. This resulted in failed updates, and other hard to diagnose failures.
• Certificate Updates/Revocation. If you wanted to update or revoke a certificate (i.e. after discovering that it expired), WSUS offered no functionality to enable this. Accomplishing this turned into a manual task that was very hard to either do by hand or automate successfully.

If you still want to distribute signed updates, you have several options:

• Install Windows Server Certificate Services. This is an in-box feature of Windows Server 2003 and beyond, and is designed to address exactly these issues.
• Create and Install your own certificate. Many tools exist to generate a self-signed certificate. After generating one, you can install it in your WSUS server and distribute it as you did before, using the SetSigningCertificate API. You’ll still need to take care of distribution and revocation yourself, but WSUS will monitor your custom certificate and let you know when it’s nearing expiration.

WSUS will still be able to sign packages using any registered signing certificates. If you already are using a self-signed certificate that WSUS generated, you can continue to use that certificate for as long as it meets your needs.

Please continue to read the "What's new in R2" blog series for more updates and discussions of new features in Windows Server 2012 R2!

Thanks,
The WSUS Team

Update: Workaround Details

While WSUS will not generate self-signed certificates by default, it is possible to restore the legacy behavior by setting the following registry key: 

• HKEY_LOCAL_MACHINE\Software\Microsoft\Update Services\Server\Setup\
• Create DWORD value: EnableSelfSignedCertificates = 1

Please note that the CreateSelfSignedCertificate API is still considered deprecated and may be removed in a future version of Windows.

Until Windows 8, Windows Update used to manage its own internal scheduling for checking for, downloading, and installing updates. It required that the Windows Update Agent was always running in the background, consuming memory and other system resources. In an effort to increase battery life on portable devices, Windows 8 introduced a new feature called Automatic Maintenance, which runs nightly and performs various tasks such as lightly defragmenting hard drives (or TRIMming SSDs if necessary), checking, repairing, and optimizing the system component store, running anti-virus scans, installing updates, and more. This consolidation allows for all these components to use far less system resources, work consistently, respect the new Connected Standby state for new device types, and consume less battery on portable devices.

What this also means is that on Windows 8 and Windows Server 2012, the setting for when to download and install updates doesn't work in the same way. While you can still set Windows Update to download updates and install them automatically or not, the day-of-the-week setting is not effective on Windows 8. Indeed, Automatic Maintenance runs once a day by default, and due to the consolidation of maintenance tasks there isn't a way to individually specify which maintenance tasks run on which days.

WSUS provides administrators with a way to control when patches get installed and PCs get rebooted. I'll explain one possible strategy for doing this:

Taking Control of Update Installation

What to do:

• Using Group Policy, set your target machines to check for updates but do not automatically install them.
• When you want to deploy an update at a particular time, set the deadline for when you want the machine to install updates and restart.
• You can use groups in WSUS to set different approvals and different deadlines for different groups of machines.

Here's how it works:

This works because if you have set a deadline, WUA will enforce that deadline even outside of the Automatic Maintenance window, and even if updates are set not to install automatically. The computer will be rebooted (if needed) at the end of the installation process.

Every day, the Windows Update agent contacts WSUS and downloads information about which updates are to be offered to that PC, along with the deadline for each update as specified by the administrator. If an update is overdue, Windows Update will force that update to be installed automatically, even though WUA is configured to NOT generally install every update automatically. Otherwise, the update is offered to the user for manual installation until the deadline is reached. When the deadline is reached or passed, the update is forcibly installed and the machine is rebooted after a 15-minute countdown. If no users are signed in, the machine is rebooted immediately.

If you are running a server and you want to make sure it doesn't reboot until a certain date, then this is the option for you. Your server won't install any updates automatically until one of the updates reaches its deadline, and then the server will be rebooted immediately upon passing of the deadline, assuming that no users are signed in. If there are users signed in, the standard 15 minute timeout applies.

You can limit reboots to "service time" windows if you approve all updates with deadlines during your desired service windows. Machines that are powered off during the service window will be automatically updated when they are powered on once again.

Note: You need to make sure that all the updates you care about have deadlines assigned to them. If you neglect to assign a deadline and you've instructed Automatic Updates to not be automatically installed otherwise, you could be leaving your network in a less secure state if your users don't manually install those updates.

A note about time zones

In WSUS, when you set a deadline, it is interpreted in the time zone of the WSUS server, not the time of the target computer. Be sure to keep this in mind when setting your deadlines to avoid unexpected reboots. Remember, if a reboot is needed, it will occur no more than 15 minutes after the completion of the installation of the update.

Additional reading:

• Client Behavior with Update Deadlines: http://technet.microsoft.com/library/cc708585(v=WS.10).aspx
• Automatic maintenance is described in detail on TechNet at http://msdn.microsoft.com/library/windows/desktop/hh848037(v=vs.85).aspx
• The section titled "Automatic Maintenance and changes to restart behavior after updates are applied by Windows Update" at http://technet.microsoft.com/library/hh994618.aspx#BKMK_WhatsNewEight
• For more information about how automatic installation works in Windows 8, you can read more on this blog post on the Building Windows 8 blog.

There is a really valuable blog post on the Hey Scripting Guy! blog that explains how to install and configure WSUS on Windows Server 2012 using PowerShell. Enjoy!

http://blogs.technet.com/b/heyscriptingguy/archive/2013/04/15/installing-wsus-on-windows-server-2012.aspx

P.S. we're looking at improving our own PowerShell coverage in WSUS in the future as part of our work towards compliance with Microsoft's Common Engineering Criteria. If there are scenarios you find particularly painful or just missing, please let us know in the comments below. We'll consider and respond to every piece of feedback!

I am pleased to announce that, as of today, a fix for this issue is available from Microsoft for WSUS 3.x, in addition to the Windows Server 2012 update that we published last week.

WSUS 3.x ships back to Windows Server 2003 R2, and ships in x86 and 64-bit versions. This requires additional testing above and beyond what we did for Windows Server 2012, which applies only to that OS and is for 64-bit only. Additionally, the packaging format for Windows Server 2012 is different from what we must use for downlevel OS versions.

An article describing how to get this update is available at:

• http://support.microsoft.com/kb/2819484 if you are running Windows Server 2012
• http://support.microsoft.com/kb/2828185 if you are running WSUS 3.0 SP2 (WSUS 3.2) on Windows Server 2003 R2, Windows Server 2008, or Windows Server 2008 R2
• Direct link to download 64-bit http://www.microsoft.com/download/details.aspx?id=38429
• Direct link to download 32-bit http://www.microsoft.com/download/details.aspx?id=38430

Please see my last blog post for more engineering details about why this problem happened in the first place and what decisions we made to try to make this update as bulletproof as possible. This update rolls up and includes all updates to WSUS 3.2, including KB2734608. WSUS 3 SP2 must be installed before you install this update.

Also, I just wanted to take this opportunity to reiterate that all versions of WSUS prior to WSUS 3.0 SP2 are no longer being maintained or supported. WSUS 3.0 SP2 is a free download from the Microsoft Download Center, and any customers using older versions of WSUS should install both WSUS 3.0 SP2 and this hotfix as soon as possible.

Thanks,
The WSUS Team

If you are managing updates for Windows Server 2012, you might have noticed that your WSUS server has been synchronizing a greater than usual number of updates these days. Windows Server 2012 is not only Microsoft’s most powerful, but also Microsoft’s most secure operating system to date. Since RTM, we’ve published dozens of updates that improve the security, reliability, and  functionality of Windows. Most notably, the Defender team has been publishing virus and malware definition updates 4 times a day, to ensure that your PC is never left unprotected from even the latest threats.

We’ve also added many new products to WSUS, including updates to Adobe Flash Player, Skype, Lync Server, and Office 2013. There are more WSUS updates than ever before.

All these updates certainly can take a toll on a WSUS server, especially on servers that have auto-approval rules. Many administrators were recently surprised to see that exporting updates from WSUS servers was failing, resulting in zero-size output files. It became clear to us rather quickly that the issue was due to a limitation in the CAB file format, which is an uncompressed file size limit of 2 GB.

I am pleased to announce that, as of today, a fix for this issue is available from Microsoft. An article describing how to get this update is available at:

• http://support.microsoft.com/kb/2819484 if you are running Windows Server 2012
• http://support.microsoft.com/kb/2828185 if you are running WSUS 3.0 SP2 (WSUS 3.2) on Windows Server 2003 R2, Windows Server 2008, or Windows Server 2008 R2

Many people have been asking on the forums and even through this blog for this fix for some time, and were wondering why it took more than 4 months to complete. To that end, I thought it would be interesting to share some of the engineering story as well.

One of the unique challenges of working on the WSUS team, compared to other server role teams in Windows Server, is that our role actually ships, “out-of box,” all the way back to Windows Server 2003 R2. We had to be very careful to design a solution that would work on all versions of Windows Server since then. To keep everything as simple as possible, we constrained ourselves on using compression algorithms that are already publicly available in the .NET framework or public Win32 API. Here is what we considered:

We decided it wouldn't be a great customer experience to require people to install .NET 4.5 on their servers. Plus, we wanted to preserve compatibility with Windows Server 2003 R2 if at all possible. .NET 4.5 is not available on Windows Server 2003 R2. We could have also adapted the CAB format to produce multiple output files, but we preferred to produce only a single output file, especially since the resulting files are comparatively small.  On systems running the latest version of .NET 4.0, the maximum file size is limited only by NTFS file size. While Gzip does store the length of the compressed content using 32 bits, the structure stores only the lowest 32-bits thereby allowing for larger file sizes, limited only by NTFS file size (prior to .NET 4.0, the length of the compressed content couldn’t exceed 32 bits, or about 4 GB). This does mean that there’s a limit of 4 GB on systems using .NET 3.5 (i.e., WSUS 3.0 SP2 (3.2) ). Windows Server 2012 is on .NET 4.5 and therefore not affected by the limit. Similar to CAB, GzipStream also includes built-in CRC error detection, which makes the export and import processes highly reliable. Best of all, the compressed output is generated on-the-fly, without the need for temporary uncompressed output files. This greatly decreases disk I/O and we found it reduces the time needed for import and export significantly.

Using our current export algorithm, the export process results in 2 files, a metadata.txt file and an update.cab file, which must be kept together. The CAB format archives these two files together. However, since Gzip is not an archive format, the end user would have needed to keep these files together manually. We would have preferred to produce only a single export file to ease distribution. Therefore, we changed the WSUS exported data XML schema to allow for both metadata and update data in a single compressed file.

In parallel, we also worked with our test engineers to formulate a test plan for the hotfix. Our test matrix is large, as we need to ensure that every supported version of Windows Server will be able to install this update. For Windows Server 2003 R2, that matrix is made even bigger by our support for both x86 and x64 architectures. We also worked with Customer Support Services (CSS) to gather validation data with regard to cases that were currently opened about this issue. And of course, nothing works perfectly the first time, and we’ve gone through several revisions to make sure that the latest WSUS update is more robust than ever!

At this point, we have a hotfix that we feel really good about releasing: well-informed by customer needs, developed by our esteemed software engineers, and thoroughly tested and validated. I hope that it will improve the experience of the many WSUS admins around the world, and I look forward to hearing your feedback about this update.

Thanks for being a valued Windows Server and WSUS customer!

The WSUS Team

On March 26, 2013, we will be adding a new product to your WSUS server – Microsoft Lync Server 2013. This product will be under the “Microsoft Lync Server and Microsoft Lync” product family. It will include updates for Microsoft Lync Server 2013. It will allow for a variety of update types, e.g. service packs, optional updates, critical updates, and security updates. Microsoft Lync Server 2013 updates will also be available in the Microsoft Update Catalog at http://catalog.update.microsoft.com. You should synchronize the Microsoft Lync Server 2013 product if you have this product in your managed environment. For additional information about Lync Server 2013, see http://www.microsoft.com/uc/default.mspx. Servicing of the Microsoft Lync 2013 client product can be found under the Office product family, more specifically, under the Office 2013 product.

Updates under Windows 8 Dynamic Update Category are used by Windows 8 and Windows Server 2012 to obtain critical driver, component and setup improvements during initial setup. These updates are automatically obtained by PCs during setup.  In environments managed by WSUS, SCCM or Intune, it’s important to approve this category to ensure your devices have access to the same critical updates to ensure successful initial setup of your PC.  For additional information about Dynamic Updates, see TechNet link http://technet.microsoft.com/en-us/library/jj618316.aspx.”

We will be adding a new product family to your WSUS server – Microsoft BitLocker Administration and Monitoring (MBAM). This product family will include updates for the MBAM product. It will allow a variety of
update types, e.g. service packs, optional updates, critical updates, and security updates. MBAM updates will also be available in the Microsoft Update Catalog at http://catalog.update.microsoft.com.

You should synchronize the MBAM family if you have this product in your managed environment. For additional information about MBAM, see http://www.microsoft.com/en-us/windows/enterprise/products-and-technologies/mdop/mbam.aspx.

Hello, 

As we mentioned previously, Microsoft is releasing an update to further harden the Windows Server Update Services (WSUS) as a defense-in-depth precaution for our customers. This update is now available for download. As an additional measure, we are providing the SHA1 and SHA2 hashes of the WSUS update and the WU client files we released today. This allows administrators to verify that the files they download are from Microsoft. The hashes are listed in the update KB article. We strongly urge WSUS administrators to apply these updates as soon as possible to take advantage of the added security they offer. If you’d like to read more, please review the MSRC blog for more information.

Please follow the following steps to ensure a smooth deployment:

1. Apply Security Advisory Update 2718704, issued on June 3, which moved unauthorized digital certificates derived from a Microsoft Certificate Authority to the Untrusted Store.
2. Apply the WSUS update, issued on June 08, see KB 2720211.

Thank you,

WSUS team

Hello,

As part of the phased mitigation strategy we outlined on the MSRC blog, an update was released with Security Advisory 2718704 that prevents unauthorized certificates from being used to attack Windows systems.  In an effort to provide additional protection for customers, the next action in our mitigation strategy is to further harden Windows Update as a defense-in-depth precaution. Now that we have seen broad adoption of Security Advisory 2718704, our deployment of the security hardening update to Windows Update and Windows Server Update Services (WSUS) infrastructures will begin to roll out over the next few days.

Our hardening introduces two defense-in-depth changes.  First, we have further hardened the Windows Update infrastructure so that the Windows Update client will only trust files signed by a new certificate that is used solely to protect updates to the Windows Update client. Second, we are strengthening the communication channel used by Windows Update in a similar way.  WSUS customers will also receive an update; more details will be found on the Knowledge Base when the update becomes available.

As with past updates, this update will not change your current Windows Update or Automatic Updates settings. Anytime Windows Update (or Automatic Updates) is turned on, either set to automatically install updates or notify to install updates, Windows Update will take care of updating itself.

It’s important to keep your PC up to date with the latest updates to keep your PC running smoothly and safely.

WU/WSUS Team

Two new product categories will be added to your WSUS server under the System Center family, entitled System Center 2012 – App Controller and System Center 2012 – Virtual Machine Manager.  You will see these new categories when new updates are available for these products. We encourage you to sync these new categories if you have these products in your managed environment.

A new product category will be added to your WSUS server under the Forefront family, entitled Forefront Identity Manager 2010.   You will see this new category when new updates are available for this product.  We encourage you to sync this new category if you have these products in your managed environment. For additional information about this product, please visit http://www.microsoft.com/en-us/server-cloud/forefront/identity-manager-overview.aspx

We will add a new product family to your WSUS server today – System Center. The System Center product family will contain updates for versions 2012 and higher of System Center products, which include System Center 2012, a product that combines components such as:

• Operations Manager
• Configuration Manager
• Data Protection Manager
• Service Manager
• Virtual Machine Manager
• Endpoint Protection
• Orchestrator
• App Controller

The System Center product family will allow a variety of update types, e.g. service packs, optional updates, critical updates, and security updates. System Center updates will also be available in the Microsoft Update Catalog at http://catalog.update.microsoft.com.

You will see new product categories appear under the System Center product family as new updates are available for each product or product component. The first product category to be added will be System Center Advisor. For additional information about System Center Advisor, see http://www.SystemCenterAdvisor.com/.

We encourage you to synchronize the System Center product family if you are planning to deploy System Center 2012, either through upgrades or new licenses, or if you already have System Center 2012 products in your managed environment. For additional information about System Center 2012, see http://www.microsoft.com/en-us/server-cloud/system-center/default.aspx.

A new product category will be added to your WSUS server under the Windows Small Business Server family, entitled Windows Server Solutions Best Practices Analyzer 1.0.  You will see this new category when new updates are available for this product.  We encourage you to sync this new category if you have these products in your managed environment.  For additional information about this product, please visit http://www.microsoft.com/download/en/details.aspx?id=15556

Due to the urgency of the MS11-100 release on December 29, 2011, the WSUSSCN2.CAB offline catalog file was not available at the time of the MS11-100 release.

A revised WSUSSCN2.CAB offline catalog file including MS11-100 has been released and is available to support SMS 2003 ITMU, MBSA (in offline mode) and 3^rd party tools that rely on this offline data source.

WSUS (3.x), SCCM, SBS, SCE and MBSA (in online and WSUS modes) were not affected as they use a direct (online) link to Microsoft.com or a local WSUS server as their data source.