Does Everyone Need a 3rd-Party Patch Management Solution?
A very common statement that you’ll find in discussions on the web about updating Windows computers in a network environment goes something like this: “There is no need to employ a 3rd-party Windows Update management solution because Microsoft provides WSUS and Group Policy objects (GPO) for free.” One of the interesting facets of the web and of the internet, in general, is that it allows anyone, regardless of expertise, to publish statements to a massive audience, even if those statements are not actually grounded in reality. The particular statement above is a good example of that, and it’s a good indication that the author of such a statement (or a similar statement) probably has never worked in a significantly sized enterprise environment.
Now, let me start by saying that WSUS and GPO are powerful options that definitely have their places. In some environments the two together might be totally sufficient because not all environments need more than what they offer. For example, smaller environments where there simply aren’t that many servers to deal with might be able to get away with just GPO and WSUS. Or even in some larger environments if servers can be down for long periods of time without creating lots of problems, it’s possible that WSUS plus Group Policy objects might work ok enough to not invest in something more. Ultimately if you are responsible for an environment where uptime isn’t particularly important or where efficiency isn’t needed, or where there just isn’t much complexity, then you might be fine with just WSUS and GPOs.
Why WSUS and Group Policy are Not Enough in Many Environments
- Size: The size of the environment, without taking into account any other factors, is a major aspect to consider. The more computers that you are dealing with on your network, the more likely you will find benefit in utilizing a 3rd-party patching tool. For example in an environment with just 10 servers, a single sysadmin can manually patch and reboot those 10 servers without any automation whatsoever in a very short period of time. However, as the number of servers starts increasing, the manual operation quickly becomes infeasible. Group Policy might then be able to pick up the slack if you’re dealing with a few dozen machines, but what if it’s a 100, 500, 1000, or even more computers? Things can start to get dicey pretty quickly. See below for more.
- Uptime guarantees / Small maintenance windows: If you simply cannot afford to have servers be offline for any longer than absolutely necessary, then you need to make your update and reboot process as efficient as possible. If you are relying on just group policy to control the timing of updates and reboots, it’s very difficult, if not impossible to have visibility and/or precise control over the process, especially when machines do not complete quickly or when they encounter issues either during installation or during reboot. This leads to computers being offline when they need to be online.
- Visibility: With just group policy configured to auto-install and/or auto-reboot servers, you have no way of knowing what the status of any given server is at a given time without manually checking. This scales horribly, as you can imagine.
- One or more updates fail to install successfully on one or multiple computers: Installation failures are inevitable. How do you learn about them when you have zero visibility into the update process? Typically you don’t find out until your maintenance window is over. In some cases you might not know for weeks or even months. In these cases the security and reliability of your computers is at stake.
- Computers get stuck during reboot: You need a way to discover if/when computers hang on shutdown or startup during the update and reboot process. If you are using a separate uptime monitoring tool, is it disabled during your maintenance window? Do you only learn about stuck servers at the end of the window when you re-enable your alerting system? What about in cases where the machine hangs on shutdown such that it doesn’t go offline and trigger your alerting system? Instead it just never reboots, so it hangs in limbo while Windows is trying to shut it down, but it still responds to requests during this time. Not great when you’re trying to maintain a secure and stable environment.
- Critical services fail to start after reboot: With just group policy controlling the timing of updates and reboots, how will you learn about the services that never started on one or more machines after reboots completed?
- Server dependencies and update/reboot timing: In many environments there will be servers which are interdependent such that some cannot be offline unless others are online. Or in some cases a particular shutdown and/or startup sequence must be executed. This can’t be accomplished with just group policy.
If you’ve realized that in your environment you need more than just group policy with WSUS to control the update and reboot process of your servers, have a look at BatchPatch. It could be just what you need.
