Patch Manager integrates into the SCCM console which will be connected to the Patch Manager server.
Patch Manager always publishes the third party content to a WSUS server, often just referred to as a Software Distribution Point for SCCM customers.
As long as the network is open (at least port 4092 for Patch Manager) I don't foresee too many issues connecting to multiple environments. Knowing more about the specific architecture you plan on supporting would help.
Patch Manager definitely works with Primary and Secondary WSUS servers including replicas so it all depends on what your options are with connecting to the machines. If you have a restrictive firewall or are managing geographically isolated environments you will want to look into Automation Servers to help:
You can click Next on the bottom of the page for the next two pages are useful here for exploring different scenarios.
That was my understanding of how Patch should work - I was just reaching out to see if anyone had tried it before. An important note is that we are primarily planning on using Patch just for third party patching, and I think most management of the environments will be facilitated through the separate SCCM consoles.
The current plan is to install Patch on its own server, separate from any of the SCCM servers, and then connect Patch to each of the Software Update Points (the SCCM role of the WSUS server). I am working on setting up a test for proof of concept before we move forward.
Can you go into more detail about the need for an Automation Server?
I think that the Automation server's main benefits are that it can help facilitate more WMI connections (I believe our Patch server will only be using WMI connections with each of the SCCM SUPs) and that it can help control the flow of information between the SUPs and the Patch server, but from my understanding each update will only have to publish to the SCCM SUPs (WSUS instances) once, which I don't expect will over stress our WAN.
The two main pieces where Automation Servers (AS) are going to help is facilitating network connectivity:
- Talking on a specific port.
- Can be used to distribute the load over WAN.
- Can be used to distribute the load of management tasks.
It would probably be a waste of SCCM to use Patch Manager to manage your tasks, so I wouldn't typically recommend an AS in your case and if you're not worried about the bandwidth then don't sweat it.
The other component would be to bridge the API gap between versions of WSUS (3, 6 and 10) as different versions of WSUS don't communicate well enough for our purposes so if you were running a 2012 Patch Manager server and 2008 WSUS servers (just for illustration purposes, any major OS mismatch is going to cause the same thing) then you will need an AS server to help communicate with the mismatched servers.
Thanks for the info Jrouviere! I will make sure to check out versions of WSUS.