On Thursday (May 9) Microsoft announced the forthcoming content for Patch Tuesday – May 14, 2013.
You can have Microsoft's security bulletins sent directly to you:
To receive automatic notifications whenever Microsoft Security Bulletins are issued, subscribe to Microsoft Technical Security Notifications.
Microsoft also hosts a webcast where they discuss the releases, typically the Wednesday after Patch Tuesday:
Microsoft will host a webcast to address customer questions on the security bulletins on May 15, 2013, at 11:00 AM Pacific Time (US & Canada).
Register now for the May Security Bulletin Webcast. After this date, the webcast is available on-demand.
You can also follow the MSRC team at @MSFTSecResponse.
Number of Releases: 10
Critical Security Updates: 2 addressing vulnerabilities in Windows and Internet Explorer.
Important Security Updates: 8 addressing vulnerabilities in Windows, Windows RT, Lync Server 2013, Lync 2010, Communicator 2007 R2, Word 2003, Publisher 2003/2007/2010, Visio 2003/2007/2010, Windows Essentials 2011/2012
Updates are typically released by Microsoft at 10am PT (6pm UTC).
Configuring WSUS servers to synchronize relative to that time can be helpful in expediting availability of these security updates.
Over the previous weeks, I‘ve posted a series of articles about the configuration options available for the Windows Update Agent, but knowing what those options are is only half the battle. One of the most significant challenges new WSUS Administrators face while implementing WSUS is getting the clients configured to communicate with the WSUS server. In this article, we’re going to walk through the steps necessary to make this happen.
Before you dive down into Active Directory, OrgUnits, and Group Policy, always start with the simplest option – configuring the WSUS Server itself as a client. This provides two notable opportunities:
In all of the configuration settings described in previous posts, only one of them is required to configure a system as a client of a WSUS server.
Log onto the WSUS Server as the local administrator and run GPEDIT.MSC.
Navigate to Computer Configuration -> Administrative Templates -> Windows Components -> Windows Update
Enable this policy and provide the URL of your WSUS server in both fields of the dialog. The URL should be in the form http://servername. You also need to know whether WSUS was installed to port 80 or port 8530. If it was installed to port 8530, there is a virtual directory named “WSUS Administration” in IIS. In this case, the URL should be http://servername:8530. This information is also presented during WSUS installation on a dialog.
Since we’re configuring a server, there is a second setting for which we should specify a non-default setting.
Enable this policy and set the dropdown to Option #3 – Auto download and notify for install. This will allow the WSUS server to transfer the installation files for approved updates from the “server” to the “client”, so they’re ready for installation when you choose to actually update the server.
Close the policy editor.
Open a Command Prompt and run the command gpupdate /force /target:computer
This will apply the two settings you just configured to the system. Also, because the Windows Update Agent is aware of policy change events, this will automatically trigger an immediate detection event with the WSUS server configured in the URL.
One of the most common errors I see in configuring a client is assuming that the policy was applied. There are three ways you can verify policy settings have been applied.
Open the Registry Editor, and navigate to HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU
If the policy applied correctly, these five registry values will be present. (There may be others, but they don’t matter at this point.)
At the time you ran the GPUPDATE command earlier, or anytime the Windows Update service is started, these entries of immediate interest will be made to the WindowsUpdate.log:
This tool will inspect your registry, display all of the significant values found, and identify if any are inconsistent.
Finally, after confirming the system has been properly configured, you should review the WSUS console to verify that the WSUS server is listed in the All Computers group.
Okay, so we’re done with the hard part. The easy part is just reproducing the above using Group Policy. The first step in using Group Policy is to understand your Active Directory Organizational Unit structure. The second step is to create a Group Policy Object (GPO). While the WSUS GPO can be linked at the domain level, it’s much more realistic that you will have more than one GPO (desktops, servers) and they will be linked by Organizational Unit. Survey your OrgUnits so that you know where the various machine types are contained. Also consider additional behavioral configurations of the Windows Update Agent that may drive your need for additional GPOs.
Configuring a GPO is identical to the process you used for configuring the WSUS server via Local Policy, except now instead of using the local policy editor you’ll use the Group Policy Management Console (GPMC) with a domain administrator account. The GPO is hosted on the domain controllers and acquired by a client system when the machine logs onto the domain.
After configuring the GPO you’ll need to link it to one or more Organizational Units, where those OrgUnits hold the machines that are appropriate for the settings in the GPO.
And, like you did for the local policy on the WSUS server, you’ll also need to confirm that the policy is successfully applied by inspecting the registry and/or the WindowsUpdate.log.
A full discussion on troubleshooting Group Policy issues is beyond the scope of this article, so if you’ve not explored this concept, I would encourage you to do so. If your GPO does not get applied to a client system, this typically happens for one of the following reasons:
You can also use GPResult or RSOP (Resultant Set of Policy) to verify the policy has been applied. RSOP is useful when you need to troubleshoot why a policy is not being applied, or when conflicting policy settings are being applied. For simply confirming that the right settings have been applied, however, reading the registry or the WindowsUpdate.log is much simpler and faster.