Showing results for 
Search instead for 
Did you mean: 
Create Post

Patch Manager Architecture - Deploying Automation Role Servers

Level 17

Patch Manager has some very rich capabilities for scalability that are quite often not utilized. In part one of this article I’m going to describe some of the common scenarios for using additional Patch Manager Automation Role servers that may be beneficial to your environment. In part two I will discuss scenarios for using additional Application Role and Management Role servers.

As a starting point I would like to emphasize the fact that because Patch Manager is licensed by managed nodes, there are no additional Patch Manager licensing costs associated with implementing additional Patch Manager servers.

Let’s do a quick overview of the three roles that exist in a Patch Manager environment. The Automation Role is the component of Patch Manager that initiates communications sessions and manages the task execution on a specific target system. The Application Role is the component of Patch Manager that interfaces with the console user. The Management Role is the component of Patch Manager that stores inventory data and oversees the delegation of task execution events to the Automation Role servers. A Management Role server hosts a Management Group, which is defined by one or more of the following: a workgroup, an Active Directory domain, a WSUS server.

When the initial Patch Manager server is installed, all three roles are installed automatically and they share an instance of SQL Server. A simple block diagram of the relationship between the various components of a Patch Manager server looks like this:


Let’s start with the most common additional server scenario – adding an extra Automation Role server. Automation Role servers are used to initiate the RPC/WMI connections to a managed system, so more Automation Role servers means more clients can be targeted in a task simultaneously, and Automation Role servers closer to the client means RPC/WMI does not have to be transported across WAN connections. Also note that each additional instance of a Patch Manager server (regardless of the roles selected for installation) requires its own instance of SQL Server.

Scenario 1: Using an Automation Role server to manage a dedicated target

We’re going to look at two scenarios involving additional Automation Role servers. The first scenario is deploying an Automation Role server to manage a specific device. One typical scenario is managing the primary Patch Manager server. There are certain types of actions that a Patch Manager server cannot perform on itself – most notably, being able to do a pre-installation reboot in an Update Management task. A second Automation Role server can be used to manage all tasks performed TO the server hosting Patch Manager.


Generally speaking, an Automation Role server would be a dedicated system, but in this particular scenario because this Automation Role server has a very light-duty, special purpose intent (managing only one system), it’s also possible to install this Automation Role on a desktop machine – perhaps the desktop where you’ve installed your Patch Manager console – or even on the WSUS server.

Automation Server Routing Rules

Patch Manager uses a feature called Automation Server Routing Rules to help manage the distribution of tasks to the appropriate Automation Role server. In the absence of any rules, each Automation Role server is a member of a single pool, and tasks are assigned to an Automation Role server based on resource availability on those servers. Generally, however, an Automation Role server is deployed for one or more specific reasons, and an Automation Server Routing Rule allows for the enforcement of that reason.

Creating Automation Server Routing Rules for Scenario 1

In our first scenario, we would create a rule that says “For any task targeted to the Patch Manager server, execute it on the secondary Automation Role server, but if that server is offline, then execute it on the primary server.

Automation Server Routing Rules are created from the tab of that name, on the management group node of the console where the rules should be applied. In most implementations this will be the Managed Enterprise node of the console.


The Automation Server Routing Rule for our first scenario, where we are managing a single machine, would be configured like this:


In this example, our secondary Automation Role server, named TR-AUTO, is configured to handle all tasks for, and only tasks for, the primary Patch Manager server, named TR-EP. If TR-AUTO is unable to handle the task, TR-EP will attempt to run the task itself.


To create this rule we perform three steps:

  1. Define an Automation Server Routing Rule – Computer Rule for TR-EP.
  2. Assign TR-AUTO as the Automation Server to handle those tasks.
  3. Uncheck the Absolute Rule to allow any other Automation Role server to execute the task; since the primary server is the only other Patch Manager server, it will get the task.

Scenario 2: Using additional Automation Role servers for load-sharing

A second scenario for additional Automation Role servers is to offload work from the primary server. You would do this if the primary server is unable to complete tasks in the desired time interval because number of managed systems in the local network is exceeding the capacity of the primary server. This diagram shows a second Automation Role server configured in a pool with the primary server to provide additional capacity.


You would also do this if you have geographically distributed systems, and do not want to maintain RPC/WMI sessions across your Wide Area Network (WAN), or the capacity of the primary server is not sufficient to manage local systems and remote systems.


You can also build pools of Automation Role servers for very large networks, or to have redundancy.

Creating Automation Server Routing Rules for Scenario 2

In our second scenario, we might typically manage that distribution by IP subnet with a rule that says, “For any task targeted to IP Subnet, execute it on the Automation Role server that is located in the subnet, but if that server is offline, don’t perform the task.”

If we deploy multiple Automation Role servers in a subnet, we can explicitly list those individual Automation Role servers and build a sub-pool to handle those tasks by building a rule that says “For any task targeted to IP Subnet, execute it on any of these Automation Role servers that are located in the subnet, but if all of those servers are offline, don’t perform the task.” This allows us to guarantee that tasks are only initiated from local servers, and not across the WAN.

The Automation Server Routing Rule for our second example, and assuming the subnet has multiple Automation Role servers, would be configured like this:


In this example, our additional Automation Role servers, named TR-AUTO and TR-APP, are configured to handle any tasks for any system in the subnet, and if both servers are unavailable, then the task will fail to execute.


To create this rule we perform four steps:

  1. Define an Automation Server Routing Rule – Subnet Rule for
  2. Assign TR-AUTO as an Automation Role server to handle those tasks.
  3. Add TR-APP as an additional Automation Role server to handle those tasks.
  4. Check the Absolute Rule to prevent any other Automation Role server from executing that task.

Automation Role servers can be deployed in a myriad of ways to manage where data communications are initiated from, to provide scalable resources to manage more clients or reduce the time it takes to complete a task. Automation Server Routing Rules can be defined to manage tasks for individual computers or IP subnets, as we’ve seen here, but can also be defined for Active Directory domains, organizational units, or workgroups, as well as an individual WSUS server (for only WSUS Administration tasks) or a Configuration Manager Site Server (for retrieval of Configuration Manager client data).

For more information about Patch Manager Automation Role servers, and advanced deployment scenarios, please see the Patch Manager Deployment Guide. For general product information, please visit the Patch Manager page on the SolarWinds website.

About the Author
I'm a Head Geek and technical product marketing manager at SolarWinds. I wrote my first computer program in RPG-II in 1974 to calculate quadratic equations and tested it on some spare weekend cycles on an IBM System/3 that I ‘borrowed’ from my father’s employer. After that I dabbled, studied, and actually programmed in just about every language known for the past 40 years; worked on a half-dozen different variants of Unix on 3B2s, RS6000s, HP9000s, Sparc workstations, and Intel systems; connected to CompuServe on a 300 baud modem; ran a FidoNet BBS on OS/2 on a 9600 bps modem; and started working with Windows when Windows NT4 was still the latest operating system. Along the way, I did a few years in database programming and database administration. I installed some of the first ADSL and SDSL Internet circuits in Texas, and then migrated into full-time Windows systems management, which had a lot to do with my interest in SUS and WSUS 10 years ago. This ultimately led me to EminentWare in 2009, and SolarWinds three years later.