Over the last year or two, it seems as though the term “centralized patch management” has been thrown around a whole lot. In most cases, centralized patch management refers to having a server that is responsible for deploying patches across an entire organization. Centralized patch management sounds good in theory, but there are some organizations in which centralizing patch management just isn’t a good idea. For example, centralized patch management is often a bad idea in large organizations or in organizations that are spread out geographically. In this article, I will discuss some alternative arrangements for these types of organizations.
Why Not Use Centralized Patch Management?
In the last paragraph, I mentioned that centralized patch management could be a bad idea in large organizations or in organizations that are geographically spread out. I want to start out by explaining why this is the case. In large organizations it’s simply a matter of supply and demand. A single patch management server probably isn’t going to be able to keep up with the demands of a large, enterprise class network.
For example, imagine that Microsoft releases a new security patch that is 1 MB in size. If there are 5,000 workstations on the network, then your patch management server is going to have to transmit about 5 GB worth of data just to send out this 1 MB patch to all the clients (actually, it would be a lot more data than that because of overhead in the authentication and patching processes). Even if you don’t mind having a single server sending out 5 GB worth of patches at a time, you have to consider what the impact would be of deploying a 200 MB service pack (a terabyte of data suddenly flooding your network).
Even if you aren’t concerned with the volume of traffic that a single patch management server would have to deal with on a large network (you should be), you have to consider the amount of time that it would take a single server to patch all of those workstations. Even a fast server is going to take a while to patch 5,000 workstations because of bandwidth limitations and because of inefficiencies in the workstations themselves. Being that so many of the patches that Microsoft releases are critical security patches, it’s important to be able to apply patches quickly.
OK, so a centralized patch management server usually isn’t a good idea for large networks, so what’s the alternative? In a large organization, it’s usually a better idea to decentralize patch management. The idea is that you still have a central patch management server, but this server never sends patches directly to the workstations. Instead, it acts as a master patch management server and sends patches to subordinate patch management servers. This allows you to have a separate patch management server for each major department.
To see how this works, let’s go back to my earlier example of the organization that has 5,000 workstations that need to be patched. Rather than having a single server patch all 5,000 workstations, let’s pretend that the organization installed a master patch management server and five subordinate patch management servers that each service about 1,000 users.
When the 1 MB patch that I used in my earlier example needs to be applied, the same approximate volume of traffic is still being placed on the network. After all, there are still the same number of workstations receiving the patch and there is slightly more overhead than before. The difference is in the way that the traffic is being distributed. For starters, you won’t have a single server sending out 5 GB of data. Instead, each of the subordinate servers will be sending out a much more manageable 1 GB of data each. More importantly though, these subordinate servers can be placed in the same subnets as the clients that they service. That way most of the network traffic that’s related to the patch management process will be isolated to a single subnet rather than flowing all over the entire network. The end result is that the traffic will have much less impact on the network as a whole.
Using five subordinate servers to distribute patches rather than using a single central server also allows patches to be distributed more quickly. All five servers can work simultaneously and assuming that all things are equal, the patching process can be completed about five times more quickly than it could if only a single patch management server were in use.
Wide Area Networking
Now that I have discussed some reasons why centralized patch management usually isn’t such a good idea for large networks, I want to discuss some reasons why it is also not a very good fit for geographically dispersed networks. Many of the same principles that I have already discussed in regard to large networks also tend to apply to geographically dispersed networks since they often also tend to be large. However, centralized patch management tends to cause problems for geographically dispersed networks regardless of size. As the networks size increase, the problems do tend to be magnified though.
To see why centralized patch management is problematic even for small geographically dispersed networks, let’s pretend that there is a company that has two offices; one in Miami, Florida and the other in Las Vegas, Nevada (why not use fun places). Since there are a couple thousand miles between the two offices, the company has elected to use a leased line to connect the two facilities. The company is small, with 25 employees in each office. Because of the company’s small size and because of budget constraints, the company is using a T-1 line for WAN connectivity, which has a throughput of 1.544 MBPS.
OK, so what’s the problem with a company like this using centralized patch management? Let’s pretend that the company has a patch management server in the Las Vegas office, but not in the Miami office. Now, let’s pretend that Microsoft releases a 1 MB security patch that needs to be deployed to all workstations. The patch management server downloads the patch, and it deploys the patch to all of the workstations in Las Vegas with no problem. The patch management server then starts deploying the patch to the workstations in Miami. The problem is that there are 25 workstations in Miami. The patch management server has to send the same 1 MB patch over the slow WAN link twenty five times. This means that the slow link is being congested with 25 MB of traffic. Until all of the patches have been sent, other communications between the two offices could seriously be hampered.
If this were a real life network, I would probably place an independent patch management server in each office. That way, patches never have to be sent across the WAN link since the link speed is so slow. If the WAN link was faster, or if centralized administrative control was important, then the server in Miami could be set up as a subordinate to the server in Las Vegas. That way, the server in Las Vegas would download the patches and deploy them to the workstations in Las Vegas. It would also send a copy of each patch to the server in Miami, which would in turn deploy the patches to Miami based workstations.
Conclusion
In this article I have explained that although centralized patch management has gained popularity recently, it is sometimes impractical. I explained some reasons why centralized patch management is often ineffective in large or geographically dispersed networks. I then went on to discuss some alternate arrangements.
