2 of 2 people found this helpful
For the "not getting finished in a given patching window" problem: have you looked at using more Automation Server Roles?
If you aren't familiar with that concept: An Automation Server Role is the 'workhorse' piece of the deployment task. When you target a set of machines with a task like an update deployment task, it is the ASR that is talking to those machines via WMI and telling them what to do. If you just have one ASR, it will methodically go through the whole list of targeted machines, but will only be able to talk to a few at a time.
Check out this thread: July Month patch for 600 systems ran more than 12 hr
for more details. Specifically, the comment from Lawrence Garvin at July 18, 2013 4:09PM sheds a lot of light on how ASRs work and how to get more done in less time with additional ASRs.
When deciding where to place additional ASRs (if you choose to go that route)...if you already have downstream WSUS servers, that is a very natural choice for where to put one of those extra ASRs without having to allocate or find a different box.
That is not something I was familiar with and that might also be the key to getting this working right. So it seems if I want to get more servers patching at the same time, we should deploy additional servers to help with this. So far this is seeming like a lot of additional overhead for SWPM without much benefit above what we are switching from.
If servers have AU settings via GPO to install during a maintenance window and you approve updates days earlier, wont they just download them and then when the maintenance window comes up they will all install at the same time with patch manager not having anything to do with it?
Basically, wouldnt more automation roles just be for if you wanted to approve updates and have them go out and install with no AU settings made?
Yes, if you have your machines with Group Policy setting for Automatic Updates set to schedule installation of updates ("Option 4 - Download and Schedule") and you Approve updates ahead of time, the machines would just install at that time since they will have already downloaded the content.
One of the Patch Manager features, however, is to be able to schedule direct deployment tasks to get updates out to machines - through the Update Management task (for specific updates) or the Update Management Wizard task (for the more 'bulk' deployment method of "go get and install all needed and approved updates" for example.
If you're using one of the Patch Manager tasks mentioned above to do deployments, you would still have AU settings to point your machine(s) to the WSUS servers and "Allow signed content..." for the 3rd party stuff, etc..., but when it comes to scheduling the deployments you could choose to set your Automatic Updates GP to be "Option 3 - Download and Notify" and then use Patch Manager to schedule the deployment task for a specific time - or run it Now, or run it periodically if desired.
Where extra auto servers really help is:
- when you have remote sites and you don't want to open up a bunch of WMI ports through the WAN firewalls. instead of putting Patch Manager agents on all the remote machines to reduce the number of ports to be opened, you could put an Auto Server at that site. Then, when a Task is run that targets the remote site, the "main" Patch Manager server will talk to the remote Auto server over one port to get the task going but the remote Auto server will then (locally) make the WMI connections to the machines there.
- If you have a whole lot of machines (local and/or remote). Even if the machines have already downloaded the binary content, if i'm deploying to 5,000 machines, it will take a while for one Auto server to make connections out to each of those machines. With 3 extra Auto servers, each Auto server could handle 1250 instead of one doing all 5000. If you have a time window that you have to work within (as opposed to just a starting time), that type of distributed-load approach can really help you meet that window.