We regularly receive questions from IT administrators who desire to have more control over their patch management processes as well as better automation for their patching systems. One of the phrases that we have begun to hear more and more frequently is “patch fatigue” and how it’s affecting so many organizations all over the world. Not surprisingly, patch fatigue seems to be one of the elements that drives admins to find patching solutions like BatchPatch.
When it comes to patch automation, in particular, there is a kind-of critical threshold that must be carefully assessed. Some automation is a good thing, but too much automation could actually be a bad thing if it comes at the cost of control over the entire process. If you have everything setup to run automatically without the administrator even having to monitor everything, that sounds very nice! But just because you have setup everything to run automatically does not mean that forgoing monitoring of the entire process is necessarily a good idea. And in many cases I would argue that it’s a horrible idea, but this really depends on the particular environment’s needs, service level agreements, etc. When it comes to automation we have some users who are *truly* obsessed with automating everything. Sometimes they even want to automate all the way to the point that they have automated processes setup with the sole purpose of configuring their automation for other processes, like some sort of meta-automation, if you will. 🙂
However, I would argue that there is a point where too far is too far. Ideally, the administrator really should be monitoring his/her patching processes, even if the processes themselves are launched by automated tasks. If you are able to get away without real-time monitoring, that’s all well and good, and I’m happy for you that your environment allows for that level of flexibility. You may very well not even need a third-party patch management tool. People often say things like “There is no need to use third-party patch management tools when you can just use WSUS and group policy.” This is definitely true for some environments, but generally people who make these blanket statements fail to realize that this is simply not an option in many environments, especially in environments where uptime is critical or where maintenance windows are small, or where the number of systems being patched is large. And so when I see someone make a statement like this I immediately know that one of a few things is true about his/her environment. He/she is likely dealing with a more casual environment where patches can be installed in large time window, reboots can be done without concern for exactly when those reboots occur, and perhaps also the number of computers involved is not all that high. In these cases, the administrator can develop processes that rely on automation while sacrificing precision, control, and real-time monitoring, and so WSUS and group policy alone might be sufficient in these cases. But for the rest of us who need to control precisely when our machines download and install updates or precisely when our machines reboot, and we need to monitor to make sure they are back online by a certain time and that various services are up and running after the machines are online, that’s where third party patching applications like BatchPatch come in to play. And for those of us who like to automate while still maintaining a high degree of precision and control over the whole process, BatchPatch has more advanced features like the ‘Job Queue‘ and the ‘Advanced Multi-Row Queue Sequence‘ that can be used in conjunction with the ‘Task Scheduler‘ for all of your automation desires.