Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials

Remote Application/Automation/Managment Servers and what is needed

I am to attempt a multi-site install of Patch Manager and I've got a few questions.

1)Does the Automation Server control the inventory polling of the clients and will this data be sent to any specified Management server I choose?

2)Do I need to install a secondary Application server for the remote location or can I just use one Automation server?

3)Do I necessarily need a Management server at each remote location or can I just use the one on the Primary Application Server which is connected to a separate SQL box?

4)Does the remote Management server send its data to the Primary Application server Management server for integration into the database or does the remote Management server send it directly to the SQL server?

5)Does each Application/Automation/Management server need its own database for any reason?

6)What hardware specs are necessary for secondary Application/Automation/Management servers? Do they need to be as powerful as the Primary Application server?

I'd rather not have the WMI/RPC traffic going over the WAN if I can help it as firewall and server setup would be an unneeded pain.

Find more posts tagged with

Accepted answers

LGarvin

Greetings Doug.

1. Every connection to a managed system originates from the Automation Role server. The inventory data collected from a client is sent to the Management Server that hosts the Management Group that the client is assigned to. One Management Server per Management Group.

2. You do not need to install a secondary Application Role server for remote sites just for managing clients. If a remote site will have console users, there may be benefits in having a local AppServer to keep the console traffic off of the WAN, but they could just as easily use the primary AppServer.

3. You generally will not implement additional Management Servers. In fact, in most organizations additional Management Servers are not an option. Currently a Management Group is defined by Domain, Workgroup, or a WSUS Server. In a single domain environment, for inventory purposes only one Management Group has any value. ergo only one Management Server. If you were managing a multi-domain environment, or multiple independent WSUS environments, there might be value in physically segregating that data by implementing additional Management Groups (which requires additional Management Servers).

4. If you were using additional Management Servers, then the inventory data is physically held in the database associated with the Management Server. It is not stored anywhere else.

5. Each Patch Manager server must have its own private instance of SQL Server. Each Patch Manager server installation will install an instance of SQL Server Express Edition on the local box. For remote Automation Role servers, SQL Express is more than adequate to the task.

6. A remote Automation Role server does not require significant resources, but the actual resources you choose to implement should be reflected by the number of client connections originating from that Automation Role server, and how much concurrency you want/need with those connections. In its default configuration, an Automation Role server has two worker processes, and each worker process has a thread pool of sixteen, which means an Automation Role server, theoretically, could establish as many as 32 simultaneous WMI connections. The max values are 8 processes and 128 threads per process -- so if you wanted to throw a quad-socket/quad-core box with 16GB RAM at the task and inventory a thousand clients simultaneously -- you could do that. :-)

As a practical matter, many customers find it functional to install the remote Automation Role server on the same system that hosts their WSUS replica server. Both are fairly light-duty tasks for a system, and they co-exist quite nicely -- the one exception, perhaps, would be if you tasked multiple machines to download updates from the WSUS server simultaneously via a Patch Manager Update Management task. That you might see a bit of load with.

All comments

LGarvin

Greetings Doug.

4. If you were using additional Management Servers, then the inventory data is physically held in the database associated with the Management Server. It is not stored anywhere else.

dkeyser

Excellent information sir!

I will be doing my multi-site install with multiple WSUS servers. I'm assuming these are downstream and not separate WSUS servers as well. None of these sites have a VPN either so I'm trying to keep things down to a minimum.

Since you can have 32 simultaneous WMI connections by default then does that mean I can inventory 32 client machines at the same time? I thought I remember reading that inventory does one computer at a time.

So what I really need is the PAS on a larger SQL server and all the automation servers can run off of the sql2008r2 express instances that they install onto themselves? Are the local instances for storing the data it recieves from the client computers before it sends it to the PAS and management server?

Thank you for all the information you have and continue to provide.

LGarvin

To be more clear, the 32 simultaneous connections is really a theoretical maximum. Depending on the number of simultaneous tasks that are executing there is some thread overhead associated with each task, and in some cases there is some thread overhead associated with setting up the RPC/WMI connections.

You can inventory one computer at a time -- by targeting the task to a single computer. But typically an inventory task is targeted to an OU, Domain, Workgroup, or some other grouping of computers. In those cases, think of the resulting list of computers as a pipeline, and as threads are available on an Automation Role server, an inventory connection will be established with the next computer on the list. At some point, possibly, the thread pool will max out, and the next computer on the list will have to wait for some other in-process computer connection to terminate. This same behavior, btw, also applies to update deployments.

Whether you need the PAS on a larger SQL Server is really dependent upon how many clients you are managing, what type of tasks and how often they run, how much inventory data you plan to collect, and how many console users will be active simultaneously. It never hurts to use an instance of SQL Server Standard Edition on a back-end database server, but if you don't already have a server with available resources, that is an additional licensing cost. The built-in SQL Express instance historically outlived its usefulness because of the 4GB database limit -- which we've historically seen at around 2500 clients (although I did once see a customer blow out 4GB of data with only 1000 clients). With the 10GB limits in SQL Server 2008 R2 Express Edition, I suspect we'll see more limits hit due to performance rather than data storage. Trying to manage a >4GB database with a single core and 1GB buffer will not be optimal.

dkeyser

Thank you for your reply. It's good to know we can change those settings to better facilitate our needs. As for SQL 2008 R2 express it's also good to see we could potentially utilize this for our customers that don't have a dedicated SQL server and yet they have a separate WSUS server.