Last January I talked in another article about the scenario involving using a new WSUS v6 server (which runs on Windows Server 2012) in combination with Patch Manager.

 

But I overlooked one scenario in that article, and since then another one has arisen.

 

The fundamental challenge with mixed scenarios involving different operating systems has to do with the WSUS API version. In order to support local publishing activities (basically anything involving putting a third-party update into the WSUS database), both the WSUS Console version of the Patch Manager server and the version of WSUS installed on the WSUS server must be identical. If they are not identical, the Patch Manager Publishing Wizard will return the error message

     Message: Failed to publish packageName. Publishing operation failed because the console and remote server versions do not match.

 

You can get more information about this particular message, and other known causes, in Solarwinds KB4328.

 

Today, there are three supported production versions of WSUS that can contribute to this situation.

  • WSUS v3.2 - runs on Windows Server 2003, 2008, and 2008R2.
  • WSUS v6.2 - runs on Windows Server 2012 (RTM)
  • WSUS v6.3 - runs on Windows Server 2012 R2
  • WSUS v10  - runs on Windows Server 2016

 

So the original article dealt with the scenario where WSUS v6.2 was being deployed on Windows Server 2012, but presumed that Patch Manager already existed, or was being deployed, on a non-WS2012 system. It talked about how to get the WSUS v3 console of the Patch Manager server to talk to the WSUS v6.2 server. Essentially we did that by forcing the connection through a WSUS v6.2 console installed underneath a second Automation Role server.

 

Here's a chart showing the various combinations of Patch Manager and WSUS, and which ones will connect natively and those that will require an additional Automation Role server (typically installed on the WSUS server, but can be a third system).

For the sake of the symmetry of the chart (and future capabilities), I've included the scenario involving Patch Manager on Windows Server 2012 R2 -- but please note that Patch Manager v1.85 is not officially supported on Windows Server 2012 R2 at this time. Implementing a Patch Manager Automation Role server on Windows Server 2012 R2 or Windows 8.1 will require Patch Manager v2.0 (coming soon!).

 

Patch Manager on WS2003/2008/2008R2 (WSUS v3 console)Patch Manager on WS2012 (WSUS v6.2 console)Patch Manager on WS2012 R2 (WSUS v6.3 console)Patch Manager on WS2016 (WSUS v10.0 console)
WSUS v3 (on WS2003/2008/2008R2)Direct Connection from PAS works

Requires AutoServer on WSUS v3 server

or other system running WS2003/2008/2008R2 or Windows Vista/Windows 7

Requires AutoServer on WSUS v3 server

or other system running WS2003/2008/2008R2 or Windows Vista/Windows 7

Requires AutoServer on WSUS v3 server

or other system running WS2003/2008/2008R2 or Windows Vista/Windows 7

WSUS v6.2 (on WS2012)

Requires AutoServer on WSUS v6.2 server

or other system running WS2012 or Windows 8

Direct Connection from PAS works

Requires AutoServer on WSUS v6.2 server

or other system running WS2012 or Windows 8

Requires AutoServer on WSUS v6.2 server

or other system running WS2012 or Windows 8

WSUS v6.3 (on WS2012R2)

Requires AutoServer on WSUS v6.3 server

or other system running WS2012R2 or Windows 8.1

Requires AutoServer on WSUS v6.3 server

or other system running WS2012R2 or Windows 8.1

Direct Connection from PAS works

Requires AutoServer on WSUS v6.3 server

or other system running WS2012R2 or Windows 8.1

WSUS v10.0 (on WS2016)

Requires AutoServer on WSUS v10.0 server or other system running WS2016

Requires AutoServer on WSUS v10.0 server or other system running WS2016

Requires AutoServer on WSUS v10.0 server or other system running WS2016

Direct Connection from PAS works

 

Note particularly that it is the version of the WSUS SERVER that determines where the additional Automation Role server must be installed, not the operating system that the Patch Manager server is installed on.

 

UPDATE [1/6/2014]: In this version of this article, I failed to also mention the requirement to create an Automation Server Routing Rule (ASRR). It is the ASRR that tells the Patch Manager server to route all requests for the WSUS server through the appropriate Automation Role server. To create an ASRR:

  1. From the Managed Enterprise node, select the Automation Server Routing Rules tab.
  2. In the Actions Pane on the right, under "Routing Rules" select "Add WSUS Server Rule".
  3. Select the WSUS Server from the dropdown menu and click on "Save".
  4. Check the correct Automation Server from the list.
  5. IMPORTANT: Check the "Absolute Rule" checkbox at the bottom of the dialog.
  6. Click on OK.

 

For more information about the architecture and implementation of Patch Manager Automation Role servers, please the Administrator Guide and these blog articles.

Patch Manager Architecture - Deploying Automation Role Servers

How-To: Install and Configure a Patch Manager Automation Role Server