First, let me start by saying that we have many customers who run BatchPatch on the same computer where they have the WSUS role installed (Windows Server Update Services). There is nothing inherently wrong about doing this. In many situations, it really isn’t a big deal if BatchPatch and WSUS are running on the same server. That said, it’s not what we prefer or recommend, especially as your number of target computers increases, and especially in cases where it’s important for you to be targeting many computers simultaneously. Here’s the deal…
Neither BatchPatch nor WSUS require a lot of computing/processing power to run. However, both applications can end up with many simultaneous remote connections processing at a given time, and BatchPatch can require a lot of processes and threads to be executed simultaneously. Considering that many administrators use BatchPatch in such a way that requires it to execute actions on a very large number of target computers at the same time, and considering that many of those actions might require the target computers to query and/or retrieve updates from a WSUS, we think it’s a good idea to separate BatchPatch and WSUS to produce the least potential for bottlenecks, especially considering that during a critical maintenance window administrators need everything to go as smoothly as possible.
Imagine for a moment that you have 100 target computers in your BatchPatch grid, and you initiate ‘Download and install updates’ on all 100 computers at the same time. BatchPatch now has to spin up 100+ new processes and 100+ threads, as well as at least one connection (sometimes more) to each target computer. If each target computer now begins to download updates from the WSUS, each target computer will then establish its own separate connection to the WSUS server. If the WSUS server is the same computer as the BatchPatch server, all of a sudden we have a quite lot of outbound and inbound communication taking place to many different target computers because BatchPatch is creating and maintaining many processes and threads that establish remote connections to target computers while those target computers then establish their own remote connections to the WSUS, and then WSUS then has to handle processing those requests and maintaining the connections. In many cases this won’t create any type of bottleneck or lag/delay, but in environments where you know you are going to be targeting a lot of computers at one time in BatchPatch and where you want your maintenance operation to complete as quickly as possible with as few hiccups as possible, then we think it’s a good idea to run BatchPatch on a computer that isn’t performing any other roles at the time that BatchPatch is being utilized. The goal here would be to simply minimize the amount of simultaneous connections/downloads/processes/threads on the BatchPatch computer in order to decrease the likelihood of any hiccups or bottlenecks during a critical maintenance window. You pretty much instantly halve the number of simultaneous connections required to be kept open simply by running BatchPatch on a computer that is NOT the WSUS server. And by the way, BatchPatch doesn’t even necessarily have to run on a server class machine. It can operate effectively from a standard workstation too, so that’s a consideration to keep in mind.
To reiterate once again, there is nothing inherently wrong with running BatchPatch on the WSUS server. In many cases this won’t be an issue or create any problems, and we definitely have plenty of customers who do this. However, for environments where you need or want to minimize the likelihood for any difficulties during a critical patching maintenance, and in environments where there will be a lot of target computers operated on simultaneously by BatchPatch, we would suggest that you put BatchPatch on a computer that isn’t performing any other tasks/roles at the time of the patching maintenance. At the very least we recommend doing some test runs to get an idea of how well things are running in your particular environment. If you discover that all is running smoothly, then you probably don’t need to make any changes.