**UPDATE: Microsoft released KB 2734608 on August 24th, 2012 that describes a patch for WSUS 3.0 SP2 to support Windows 8 and Server 2012 which makes this procedure unnecessary unless you want to take advantage of new features supported in WSUS on Server 2012.

**NOTE: The configuration described here is not supported by SolarWinds.

With Server 2012 RTM around the corner, we’re working diligently to ensure that our infrastructure is configured appropriately to support it. Part of the excellent service OrcsWeb provides is managed Windows patching for all of the systems on our network. We pride ourselves in ensuring the best possible hosting experience, so deploying Microsoft critical and security patches in a timely manner is a must.

In order to patch a Server 2012 system, you must use a Server 2012 system running the WSUS role – WSUS 3.0 SP2 will not work with Server 2012. The reason is an incompatibility between the Windows Update client on Server 2012 and the WSUS server. That being said, a Server 2012 system running the WSUS role, can provide updates to Windows Server 2003, Server 2008, Server 2008 R2, and Server 2012 clients – provided they have the client update of KB 2720211. Using GPO’s, you could then configure your systems to connect to your WSUS server, and patch themselves during an appropriate window. We utilize Solarwinds Patch Manager (formerly EminentWare Extension Pack) to compliment WSUS for our environment. It provides additional functionality like the ability to publish 3rd party updates via WSUS (for Dell firmware & drivers, or Adobe updates for instance) and pushing patches during discrete windows – something our customers have asked for time and again.

Unfotunately, even the current beta version of Patch Manager (version 1.8) cannot be installed on Server 2012 (at the time of this writing), so that leaves us without a fully supported way of patching our Server 2012 systems. That being said, anyone in the IT industry knows *supported* and *it works* are two completely different concepts. Using a decentralized architecture, we are able to leverage a Server 2012 system running the WSUS role and Patch Manager 1.8 beta running on Server 2008 R2 with the WSUS 3.0 SP2 console to successfully patch Server 2012 clients.

I’ve outlined the steps below to accomplish this:

1. Install the WSUS role on a Server 2012 system (we’ll call this WSUS-SERVER).
2. Configure WSUS-SERVER to synchronize updates and arrange computers into groups like you would in previous versions of WSUS.
3. Configure a GPO for domain clients to use WSUS-SERVER to receive updates.
4. Install the WSUS 3.0 SP2 console on a Server 2008 R2 SP1 system (we’ll call this PATCH-SERVER).
5. Connect to WSUS-SERVER from the WSUS 3.0 SP2 console on PATCH-SERVER.
6. Install Patch Manager 1.8 Beta on PATCH-SERVER.
7. During the configuration of Patch Manager, select WSUS-SERVER as your WSUS server and DO NOT configure 3rd party updates (unfortunately, 3rd party update publishing does not work because of the console version mismatch).

The WSUS 3.0 SP2 and Patch Manager consoles will incorrectly report the Operating System version as Windows Server 2003 x64 Edition, even though the systems are running Server 2012 RC (8400).

The WSUS console on Server 2012 will show the correct OS version:

Server 2012 clients can be included in standard Patch Manager jobs like any other client.

Happy Patching!