It’s the email we all dread: Your organization’s specific Windows Server operating system is nearing its end of life. Now is the time to deal with the situation.
End-of-life messages from Microsoft – or any other vendor – come as no surprise, as they are announced months in advance, if not sooner. For many IT administrators, this is a simple click-and-delete action to delay fixing the problem – it’s still on the road. But at some point, you run out of road.
Oddly enough, server end-of-life isn’t something that happens often in IT. This is because application updates and upgrades are more normal, often resulting in new virtual machines being created alongside existing environments. Therefore, an application upgrade often results in an operating system update. But these update patterns don’t always work in legacy applications that are still needed for business operations.
Update the operating system manually
For one-time situations, perform a manual OS update. This often works, but it takes time; it also requires some level of skill to troubleshoot hardware or software compatibility issues.
If the server in question is virtual, clone it to test the upgrade to make sure there are no issues, and continue if it is wiped. Physical servers require proper backups – and a long enough downtime window to handle all of the 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 operating system. New operating systems often change security settings and frameworks which can cause older applications to fail because they were never designed for the new security settings. They accept looser security settings than the new, removed operating systems. Relaxed security can be difficult, if not impossible, to implement in modern versions of Windows Server.
Depending on the number of versions of a Windows Server OS, it may require multiple upgrades from Server 2008 to Server 2019. You should stop at Server 2012 and possibly Server 2016 depending on the presence of R2. These downtimes increase the risk of problems during or after installation and extend the downtime window.
Another option is to remove the server and its application. This may sound drastic, but it’s not an idea to be ignored. Apps often work simply because they’re there and people are comfortable with them. It is often human nature to resist massive changes in workflows, which can be inhibiting. Difficulties aside, a remove and replace strategy may be worthwhile over attempts to migrate the server to a new operating system. This often becomes a political process that requires social maneuvering, but be honest with users and app owners about the risks and challenges presented by using outdated apps and operating system platforms.
Inaction is another option, but it is 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 operating system that can no longer be patched.
This hole in your data center security exists no matter how you monitor it. There are third-party patch systems that act as armored wrappers for older operating systems that can no longer be patched. However, it is a significant effort to put into an old operating system. And you become dependent on third-party software for security, which can be expensive and a bet on its lifespan – as third-party software gets older, it gets more expensive.
Communicate concerns to users
Server end of life is never a pleasant conversation with application owners or users. This requires honesty about risks and concerns, as it is never just a one-server conversation. A single security risk server can become the gateway to a much larger breach; their server could be the cause, no matter how small.
The conversation will not be pleasant for the 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 need to keep track of everything and the state it is in.
Because you can’t approach this as a normal project, document where things are in the process. Identify risks at every step of the process so everyone involved knows the overall risks at all times. A dashboard helps provide that transparency, which is key to moving forward with mitigation – and to addressing and preparing for the risks that come with a long and tedious process as teams work on end tasks. server life.