Systems administrators have quite a few options when it comes to applying Windows updates to the computers that they’re responsible for. In smaller environments with looser requirements it might be totally sufficient to just manually install updates each month by logging on to each computer with Remote Desktop or some type of KVM solution, and then initiating the download, install, reboot process, and finally making sure computers come back online properly. It’s not necessarily an efficient process, but it can be sufficient in many cases. Of course this process becomes unwieldy quite quickly when the total number of computers being managed increases over a certain threshold. If requirements continue to stay loose, it might be that the administrator can shift to using Group Policy to gain a modicum of control over the updating process, thereby alleviating some of the pain of a completely manual process. This may or may not involve installing a WSUS server to help with controlling which updates are made available to target computers. But what happens when more control is needed? Administrators of environments that have stringent uptime requirements or brief maintenance windows or a large number of servers know that relying on just Group Policy to manage the update process simply won’t cut it. It’s hard to even call it “managing” the process because there isn’t much managing going on.
Why WSUS + Group Policy Objects Might Not Be Enough In Your Environment
If you’re trying to manage Windows updates in your environment with just GPOs and WSUS, there are some very important things to consider:
- Machines get stuck during reboot: Sometimes computers hang while shutting down or starting up. This is an inevitable fact. The more computers you’re dealing with, the more likely you are to see one or more get stuck during the reboot. If you’re relying solely on WSUS + GPO scheduled installations/reboots, it can be hard to determine that a machine got stuck if you aren’t monitoring it in real-time. If you have a different tool that alerts you of down/offline servers, that’s great, but you probably have it disabled during your maintenance window since you know computers will be going offline at that time. The result is that at the end of the maintenance window when you turn back on your alerting tool, you all of a sudden discover which servers are stuck offline, but now it’s too late to resolve the issues *before* the end of the maintenance window. In an environment with uptime guarantees you’re probably already getting calls from customers at this point asking why they can’t access X, Y, or Z.
But what about the case where the server gets stuck during the shutdown process? You could end up in a situation where the server completed installing updates, but it gets stuck somehow such that the reboot does not occur. The server might still be online and responding to requests, so it doesn’t trigger your alert system, but the update process has not officially completed because the reboot never took place. When your maintenance window is over, you won’t discover this very easily or at all, and the machine will be in a questionable state and might still be vulnerable to whatever issues were supposed to be fixed by the updates that were installed since the installation never actually got to complete since the reboot never occurred. - Unexpected slow update processing causes reboots to be initiated at unexpected times: We all wish Windows updates always installed rapidly, but sometimes there are issues, and things just don’t go as quickly as we expect or need. If a scheduled update process is taking longer than expected, the reboot can occur at an unexpected time. If you aren’t monitoring the installation process in real-time then you might end up with a surprise reboot that occurs when you didn’t want it to. However, if you have a tool that provides you with real-time monitoring capability you’ll know the process is going slower than expected, and so you can make the necessary arrangements to deal with that before an unexpected reboot occurs.
- Critical services not starting after reboot: Sometimes services fail to start after a reboot. It’s just one of those things that can happen sometimes. The more servers you’re dealing with, the greater the likelihood is that something like this could happen. The sooner you are able to discover which servers have critical services in a stopped state, the better. However, you need to be able to confirm that the reboot occurred before checking the state of services, which again is very difficult when you don’t have a real-time monitoring solution in place for the update and reboot process. It also helps significantly to have a tool that can quickly tell you which computers have automatic services in a stopped state.
- Server dependencies create challenges for update and reboot timing: It is not uncommon for there to be dependencies in groups of servers such that one server cannot be taken offline at the same time as another, or one server can/should only be rebooted when another server is online etc. The more dependencies that exist, the more an administrator can benefit from having a tool that allows precise scheduling and/or on-demand execution as well as real-time monitoring. A tool like BatchPatch is even capable of orchestrating complex sequences to update and reboot servers in specific orders with lots of control and flexibility over exactly what happens and when, allowing you to configure one-click actions that handle the updating and rebooting of numerous computers in particular orders and with particular dependencies.
- Virtual machines: In environments with many virtual machines it becomes important to coordinate the update and reboot timing of the guests and hosts so that host operating systems don’t reboot during or before guest update processes complete, for example.
A Better Option
If you’re at the point where manual updating or GPOs and WSUS alone aren’t cutting it anymore, BatchPatch might be the tool for you.
