It’s the email we all dread: Your organization’s specific Windows Server OS is nearing end of life. Now it’s time to handle the situation.
End-of-life messages from Microsoft — or any other vendor — are not a surprise, as they are announced several months in advance, if not earlier. For many IT admins, it’s a simple click-and-delete action to delay addressing the problem — it’s always down the road. But at some point, you run out of road.
Oddly enough, server end of life isn’t something that happens a lot in IT. This is because application updates and upgrades are more normal, which often result in new VMs built alongside existing environments. Therefore, an application upgrade often results in an OS update. But these update patterns don’t always work in legacy applications still necessary for business operations.
Update the OS manually
For one-off situations, perform a manual OS update. This often works, but it’s time-consuming; it also requires some level of skill to address issues with hardware or software compatibility.
If the server in question is virtual, clone it to test the upgrade to ensure there are no issues, and move forward if cleared. Physical servers require proper backups — and an outage window long enough to handle the entire drawn-out upgrade and patching processes, which can take hours for some applications.
Consider security risks
A big question is how the existing application will work with the new OS. New OSes often change security settings and frameworks that can cause older applications to fail, as they were never designed for the newer security settings. They accept more relaxed security settings that new OSes removed. Relaxed security can be difficult or even impossible to implement in modern Windows Server versions.
Depending on how many versions back a Windows Server OS is, it might require multiple upgrades from Server 2008 to Server 2019. You need a stop at Server 2012 and possibly at Server 2016 based on the presence of R2. These stops increase the chances of issues either during or after the installation, and prolong the outage window.
An alternative option is to retire the server and its application. This might sound radical, but it’s not an idea to ignore. Applications often run simply because they are present and people are comfortable with them. It is often human nature to resist wholesale changes in workflows, which can prove inhibitive. Difficulties aside, a rip-and-replace strategy can be worth the effort over attempts to migrate the server to a new OS. It often becomes a political process that requires some social maneuvering, but be honest with application users and owners about the risks and challenges presented by using deprecated applications and OS platforms.
Inaction is another option, but it’s not a good option. Data center security is not defined by the technology in place, but rather by its weakest link — such as a server OS that can no longer be patched.
That crack in your data center security exists regardless of how closely you monitor it. There are third-party patching systems that act as armored wrappers for older OSes that can no longer be patched. However, this is significant effort to put into an old OS. And you become reliant on third-party software for security, which can be expensive and a gamble on its life span — as third-party software ages, it becomes more expensive.
Communicate concerns with users
Server end of life is never a pleasant conversation with application owners or users. It requires honesty about the risks and concerns, as it is never just a single-server conversation. A single security risk server can become the gateway to a much larger breach; their server could be the cause regardless of how small they think it is.
The conversation will not be enjoyable for IT operations staff. Stick to the facts, and explain the costs and risks to everyone involved — including management. This situation will be messy, and IT operations teams must track everything and the state it is in.
Because you cannot approach this like a normal project, document where things are in the process. Identify the risks at every stage in the process so that everyone involved knows the overall risk facts at any given time. A dashboard helps provide that transparency, which is the key to move ahead with mitigation — and to address and prepare for the risks that come with a lengthy and drawn-out process while teams work on server end-of-life tasks.
