4 Replies Latest reply on Aug 16, 2017 7:22 PM by kellytice

    Best Way To Organize Machines


      Hi all,


      We just got Solarwinds Patch Manager at our company and it was given to me to "Figure it out". My goal is to set Patch Manager up in such a way that we can use it to deploy all Windows Updates going forward and I'm wondering how you all use it and if you have any suggestions for the following scenario:


      • We have upwards 15 domains that are in our initial list of domains that we are managing.
      • These domains are spread across 2 datacenters in different parts of the world initially, but this is going to expand to upwards of 15 when this is done.
      • Our initial server list is about 6000 and we are going to be expanding this to over 15000 when all is said and done.
      • We have 2 maintenance windows per month, one dedicated to each datacenter. We are expected to get all the servers in each datacenter patched during that short 4 hour window. To make things more fun, one of the datacenters twice the size of the other one (So roughly 4000 and 2000)
      • At any given time, one or more of our application environments may need to be excluded from patching.
      • We don't know that we have everything in WSUS and past IT people did a terrible job of cleaning up Active Directory, so trying to figure out exactly what needs to be patched is a bit of a nightmare.


      We tried this out with patch groups via AD rules, but it seems like the scheduled patching executes things in a linear fashion, so we didn't even get through all 2000 servers during our patch window. We broke them up into smaller groups of about 100 a piece and that seemed to work better, but it didn't give us the granularity we needed and the lack of being able to create subgroups within SWPM means we end up with a massive list of patch groups.


      Any thoughts?

        • Re: Best Way To Organize Machines

          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.

          2 of 2 people found this helpful
            • Re: Best Way To Organize Machines

              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.

              • Re: Best Way To Organize Machines

                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?

                  • Re: Best Way To Organize Machines

                    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.