Showing results for 
Search instead for 
Did you mean: 

Patch Manager Architecture – Deploying Application & Management Role Servers

Level 17

Patch Manager Architecture – Deploying Application & Management Role Servers

This is part two of a two part article discussing scenarios for implementing additional Patch Manager servers. In part one of this article I described some of the common scenarios for using additional Patch Manager Automation Role servers that may be beneficial to your environment. In this part I will discuss scenarios for using additional Application Role and Management Role servers.

Again, I would like to emphasize the fact that because Patch Manager is licensed by the number of managed nodes in your organization, there are no additional Patch Manager licensing costs associated with implementing additional Patch Manager servers.

As previously discussed, 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 one of the following: a workgroup, an Active Directory domain, a WSUS server.

Why implement additional Application Role servers?

Implementing additional Application Role servers is done to provide redundancy or additional load capacity for console connections, or to create isolated sandboxes in which a console user manages an environment. An Application Role server has its own credentials, user profiles, and security roles.

Why implement additional Management Role servers?

Implementing additional Management Role servers is done to physically segregate the Patch Manager data into multiple data stores. Multiple data stores might be appropriate where segments of an organization have data sensitivity or confidentiality concerns about their managed systems, or where reporting is typically done at a more granular level, perhaps by department or site.

Scenario 1: Using an Application Role server to manage console connections

A scenario where multiple application servers would be appropriate is when managing a large number of Patch Manager console users, or where high-availability requirements exist. In a High Availability (HA) scenario, there would be three Application Role servers implemented:

  • The primary server (PAS) is not used for console connections, but only as a control system for the Patch Manager environment. It should be backed up regularly.
  • At least two Secondary Application Role servers (SAS) would be implemented. These servers primarily handle console connections and task management. Consoles can be split across the servers for rudimentary load balancing and individual console users would connect to the alternate server if their home server was offline, or the servers can be designated as an active/standby pair, and the consoles would only connect to the standby server if the active server is offline and immediate access is required.


This HA scenario can scale to as many Application Role servers as are required. Theoretically, each console user could have their own dedicated Application Role server installed on their personal systems.

Scenario 2: Using a Management Role server to segregate patch and asset data

One use for an additional Management Role server is to physically segregate the patch data collected from the WSUS server from the asset inventory data collected from the Managed Computer Inventory (WMI) task. This might be done for performance reasons, providing better report generation from smaller databases, or because an organization has a large dataset and does not want to invest in a licensed instance of SQL Server.

For some environments, the 10GB database size limitation of SQL Server 2008 R2 Express Edition may not be sufficient for both WSUS (patch) data and WMI (inventory) data. The primary Patch Manager server can be used to hold the data for the WSUS inventory, and a second Management Role server can be configured with a management group just for managing domain and asset inventory data collected via WMI. This implementation would look something like this:


Because the data is physically segregated, this significantly reduces the size of the database that must be accessed for generating reports. Patch management reports come from the database server containing patch data, and asset management reports come from the database server containing asset inventory data. The smaller datasets will result in faster rendering of reports.

Finally, security controls can also be applied in this scenario, so users who should only have access to patch data, can be physically and logically isolated from the asset inventory data, or vice versa, and users who need access to both can still have full access.

Scenario 3: Using an Application and Management Role server in a testing lab

One scenario in which an additional Application and Management Role server might be implemented is for an installation of Patch Manager in a testing lab. Many organizations test patches before deployment in a lab setting. Configuring an additional Patch Manager server in the lab allows that environment to be completely isolated from the production environment.

In this particular lab scenario, we are able to implement a second Management Role server, as our lab environment operates in a subdomain of the primary domain. We will define a separate Management Group for this subdomain and the WSUS server in our lab, so that we can physically isolate any inventory data we might choose to collect, as well as manage all task execution completely within the lab environment.

This scenario might also apply to a special business unit that has confidentiality considerations, or even to a perimeter network (DMZ), where communication into the primary network is not possible and all management resources must also be on the DMZ.

Deploying additional Application Role servers or Management Role servers can provide enhancements to your Patch Manager infrastructure in the areas of redundancy, load-balancing, data distribution, and improved report performance.

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.

Level 8


Thanks for this article.  I got some questions on deployment.

We have networks all over the world.  Lets say we have 200 networks interlink together with 1Mbps links.  Each site around 150 nodes. We currently are in one of the networks.  We want:-

1.  Centrallize manage patches. (Both windows and 3rd party).  The individual IT personnel on each network can have only the rights to put the computers in the correct computer groups.  I would like to approve the patch at one server and it automates the patching process to other 199 sites.

2.  Downloading of patches to come from the individual networks.  Even though the 200 networks are interlinked together, each has its own internet link.  I would like to be the person approving the patches but I would like the servers in each 200 networks to utilize their internet links to download the patches and push down based on the computer groups which I have defined and not through the interlinks.

3.  Report generation (global view and site view) .  I would like to be able to generate reports for each individual site (how many computers are patch/and how many are not).  Also I would like to generate report in a global sense to know how many percent is being patched.    If I can group the individual sites to its own group and generate patching status reports based on that, the better.

4.  DB storage.  The individual 200 networks/sites does not have a large DB and running on SQL Express DB.     I would like to localize the traffic such that the wsus server / local patch manager server (if you proposed to have) be the source of communication to the clients for patching and only send the change/status data to the main DB storage...

5.  Access rights management.  Although i mentioned i only would like the IT personnel at the sites to put the computers in the correct group, there will be events where certain sites require certain patches/updates that other sites does not need.    Also the site personnel should be able to generate reports based on their site only.

6.  Ease of maintenance.  As we are a small team (1 person or 2 at most), i need to know the best setup such that if there is a patch to be done, it can be done on a single central location and not need to visit 200 sites to perform some upgrade.   As far as I can see the deterrent for this is the 1Mbps bandwidth between sites.


1.  For (1) to work, do I need to have application servers in each of the network?  Or I only need the wsus server at the network?   So the IT personnel on the network just need to connect using the WSUS console and put the computers in the correct group and the wsus and 3rd party patches will be able to push down?

2.  For (4), What kind of traffic am i expecting that will traverse the interlinks if I am putting my enterprise DB at my site?  Will there be an event where all the computers on one site need to connect back to the DB server to update the status?  How does the client communication path work?  Under the "Managed Enterprise" I can see some bandwidth trottling, can you advice whether i can use that to my advantage?

3.  For (3), are there examples of reports and step-by-step guide that we can refer to ?  Can the reports be autogenerated and email to different group of people based on a schedule?

4.  For (5), do you have a good recommendation of how I can set this up?

I know this is long but I need advice.  As the people involve in the deployment is small, we need to make sure this setup is properly planned, thought-through and executed.  Hope to hear from you soon.

Level 17

Somehow I overlooked Adrian's inquiry a year ago, and for that I humbly apologize. I'm sure this reponse is long past useful for the purposes that Adrian needed in September, 2012, but the questions are still valid, and likely relevant to many organizations, so let me answer them now for the benefit of others who may visit this post.

First I'll say that all of the objectives defined above are easily met, many of them are available within the native architecture and deployment infrastructure of WSUS, and don't even require Patch Manager to achieve. Objective #5 is one, however, for which Patch Manager will bring unique capabilities to the table.

Q1. Centralization of approvals is a function of a couple of considerations. First, in an environment using WSUS replica servers, updates can only be approved at the Upstream Server, so as long as the remote staff members do not have administrative rights on the upstream server, they will not be able to approve patches. In a single-server environment, or where administrative rights are not so finely controlled, Patch Manager provides a feature known as Approval Delegation that allows for the explicit managing of access rights for approving updates, and can be used to functionally restrict update approvals to a single console user (or a distinct enumeration of console users, or even an AD Security Group).

Q2(1). Assuming that each site has its own WSUS replica server, and those replica servers are configured to synchronize client reporting data as well as updates and approvals, the actual data that will traverse the WAN link includes: [1] update metadata for every update synchronized to the upstream server (one time only), [2] update approvals (as created; one time only), and [3] EVENTS related to the client's changes in status for any synchronized updates (with the exception of the first reporting event which will include state information for every update). This traffic is best managed by controlling when the replica server performs it's synchronization with the upstream server (e.g. after working hours is usually the best option). (Note: WSUS servers should not use a SQL Server Express Edition database, they should use the native Windows Internal Database.) However, as regards WSUS traffic, a client system will never communicate directly with the upstream server, nor with any database instance; all communication goes through the webservices that constitute the WSUS Server.

Q2(2). A second consideration in this scenario involves the use of asset inventory. Asset inventory can be captured via the native WSUS environment, or via a Patch Manager Managed Computer Inventory task. There some critical differences between these two methods of asset inventory collection, and these differences will significantly impact the data flow across the WAN.

- Using the WSUS infrastructure for asset inventory is an all-or-nothing proposition. The WUAgent pushes the inventory data at every detection event to the local (replica) WSUS server, and the replica WSUS server uploads that asset inventory data to the upstream server during the regular server synchronization event. As noted, this event can be scheduled to avoid impacting normal business operations.

- Using the Patch Manager Managed Computer Inventory is highly customizable. Some data can be collected daily; other data weekly or monthly. You can schedule when the data is collected, and from which machines. However, the connection to collect this data is initiated from the Patch Manager server (you can deploy additional Patch Manager "Automation Role" servers on remote sites as described in this article's companion: Patch Manager Architecture - Deploying Automation Role Servers) and the inventory data is transferred across the WAN, to the Management Role server, during the actual inventory task.

Q3. Patch Manager ships with many predefined reports that will meet most reporting needs, and supports an extensive capability for sorting, filtering, and grouping those reports, as well as customizing the report templates to include the sorting, filtering, and grouping as part of a user-defined report template. Reports can be run on-demand, or scheduled, as well as emailed to appropriate recipients.

Q4. Approval Delegation is the methdology by which you would achieve access rights management to permit a site administrator to approve updates for a specific site. This would be implemented by defining a WSUS Target Group containing the clients of that specific site, and then granting the site administrator the rights to approve updates for only that WSUS Target Group.

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.