On January 14, 2020, support for Windows Server 2008 and 2008 R2 will end. That means the end of regular security updates. Don't let your infrastructure and applications go unprotected. We're here to help you migrate to current versions for greater security, performance and innovation.
The reality is in many organisations, just because a vendor declares a piece of hardware EOL (End of Life) or EOSL (End of Support Life) doesn’t mean you can just turn it off. The business is still using it and for what ever reason (and they are numerous) the IT Department is going to have to support that service, and software/hardware until it can be migrated, upgraded or shutdown.
You have Windows Server 2008r2 (and in some cases that might also be Win XP, NT, 2003) installed on your network, its running an application you can’t do without and it can’t be closed down, so let’s focus instead on what’s next.
The issue is often the risk is seen only as the EOL item, the apparent danger to the business is not in the service its self, its in the delivery of that service, However the risks are greater than this.
In short, we actually have 3 main risks.
- The Service/Application that is being run on the machine will be compromised in some way, that means the service won’t be available which means the system is down and nobody who you can normally turn to is there to support the environment.
- The ecosystem that needs to support the Application & Operating System Environment (OSE) won’t do in the future (Hardware, Hypervisor, Backup, etc.)
- The machine out of support becomes an infection risk, an infected zombie in a crowded healthy room allowed to infect anything it can come in contact with being used as a host to carry infections (payloads) that may not even affect it.
The bigger risk by far, your network, not the service. The illustration of this is WannaCry and the NHS. It was the application set and installed hardware that kept the environment on WinXP not the desire to run on an old unsupported operating system. It highlights the longer-term management of risk if we don’t look at mitigation strategies from day one as part of the lifecycle of any service(s).
In terms of choices, lets be specific in this case to Win2008r2, but this is generic in terms of all of the other options (Win7, SQL and a myriad of other environments).
a) Upgrade on-premise servers to current version (available via Monthly Billing or Volume Licencing) – Have you tested the application on Win2012r2, it may be safer to run it with limited application support than no operating system security updates, especially if you need to run it for more than 3-6months more.
b) Migrate to a SAAS version (if available) or a different vendor.
- 2. Pay to extend support with the vendor:
- a) Migrate your current 2008 workloads to Azure and benefit from 3 years of Extended Security Updates at no additional charge. If you have active Software Assurance, then save on Azure costs with Azure Hybrid-Use Rights.
- b) Remain on Windows Server 2008R2 and purchase Extended Security Updates for 3 years. This option requires active Software Assurance or subscriptions licences under an Enterprise Agreement only.
- 3. Run the application in a controlled environment:
- a) Lock the legacy down completely, technologies like VMWare NSX and Nutanix Flow as well as traditional firewall solutions can reduce the risk significantly by reducing the exposure to single ports and communication to only the machines or services that need access.
- b) Virtualise the app further, running the app in a VDI or cloud container can similarly limit exposure from the front end significantly and can often allow for hardware, software and infrastructure deployment to be abstracted from delivery.
You still have time but use it wisely and formulate a strategy and then a plan. The longer you leave it, the more the risk increases. Take an audit (or ask us to give you access to a low cost or free one), or speak to one of our licensing or cloud specialists to help you start to action a plan.
Our infrastructure audit, will show:
- Current VM and storage sizing
- Costs to run existing workloads in AWS/Azure
- Identify EOL operating systems
- Identify EOL hypervisors
- Identifies EOSL HW
- Identify HW which doesn’t support a supported version of the current OS/hypervisor
