Many sysadmins love to write scripts to solve the problems that exist in their environments. This is something we understand very well. 🙂 If you’re reading this right now then one major problem that you probably face is having to regularly ensure that your computers are completely up to date. However, some problems either aren’t so easily solved by a simple script, or are a huge time-drain to get up an running in a way that is useful enough to deploy in a production environment. When it comes to Windows Updates, in particular, frequently it’s not sufficient to simply deploy a script to remotely initiate Windows Update. As an IT administrator you often need more control. After all, if something doesn’t work right or if you can’t efficiently monitor the process, things can quickly become unwieldy, particularly when you’re working with a limited time window with critical servers that absolutely have to be online outside of maintenance periods. BatchPatch was created with the goal of helping to ease the patch management burden on systems administrators. After all, they don’t call it ‘patch installations’ for a reason. It’s a process… it’s something that, unfortunately, really has to be managed! Hence the term ‘patch management.’
In the most basic configuration for the simplest environments the goal might just be to download and install Windows Updates on all networked computers and then trigger them to reboot. Even in this seemingly straightforward process there’s actually a lot that can go wrong, especially when you are dealing with a lot of computers, and especially when there is a time crunch. And as you surely already know, there is virtually *always* a time crunch. How does the saying go? “Too much to do, too little time!” For example, what happens if a couple of computers don’t come back online after they are rebooted? If you don’t have a system that monitors uptime, how do you discover that these computers never came back online? If you do have a system that monitors uptime, usually it’s going to be disabled during the maintenance window so that it doesn’t buzz away with false alarms for every single rebooted computer. The problem here is that you won’t find out which computers haven’t come back online until *after* you’ve re-enabled your monitoring service *after* the maintenance has ended, which is too little too late!
In many environments there is a much higher degree of complexity, so the goal can’t always be as simple as downloading and installing Windows Updates on all networked computers and then triggering them to reboot. Sometimes, for example, there are dependencies across multiple computers. Maybe one computer can’t be offline unless another computer is online, and vice versa. Or maybe there are services on certain machines that have to be stopped before applying updates, and then those same services have to be re-started after the updates have been applied, with verification that the services are running properly. You might realistically want or need to execute a series of actions, in sequence, across numerous computers. And with all of this you still have the most basic requirement of needing to be able to monitor the process in real-time to make sure that when the maintenance window ends you have actually completed the entire process with all servers and services verified as being back online and performing their normal duties. Without a tool dedicated to help you with this process you’d be looking at spending practically all your working hours on patch management, which simply isn’t realistic in the IT industry. You are always going to have too much to do with too little time to do it, so choose wisely to help save yourself time and energy!
