Windows Server 2008 and Windows Server 2008 R2 reached end-of-life (EOL) on January 14th, 2020. I don’t know what sort of guidance and pointers that you’ve read or listened to, but it seems to me that most material does a lot of hand-waving and over-simplifying of a complicated topic. I want to offer something with more detail and nuance.
Before we continue, if you run or manage virtual environments that have one or more physical machines or legacy servers that have not been virtualised you can now use Altaro Physical Server Backup to protect these physical machines and keep them safe. Altaro Physical Server Backup is a free server backup freeware solution created to satisfy this need, with the added bonus that it’s free. Download Altaro Physical Server Backup now
What It Means That Windows Server Reached End-of-Life
In its simplest form, end-of-life for Windows Server means:
- The product will receive no further updates, including security fixes
- Microsoft will no longer maintain its list of compatible hardware
- Microsoft will stop testing products for compatibility on EOL operating systems
- Microsoft will no longer maintain components and documentation in software development kits and similar tools. They might remove them entirely.
- You will not have access to support services from Microsoft for the product
You might lose the ability to exercise downgrade rights to the EOL version
If a product has reached end-of-life, that also means that it has passed its end date for mainstream support. In the case of Windows Server, mainstream support ends five years prior to end-of-life. The end of mainstream support means:
- Microsoft will not develop new features
- Microsoft will not certify new hardware
- Microsoft will not accept further warranty claims
Microsoft will not issue hotfixes
A few other differences exist, but few that affect a majority of licensees. You can review Microsoft’s somewhat more detailed explanation. If you have more questions, talk to your Microsoft Technology Account Manager (TAM). If you don’t have a TAM, then the differences probably do not apply to you anyway.
What Does NOT Happen Now Windows Server Reached End-of-Life
The above leaves room for a lot of questions. Three major assurances:
- Windows Server 2008 and 2008 R2 will continue to function indefinitely
- Product-specific licenses will not expire
Third parties can continue to support the products
I will explore further in upcoming sections. If you wondered, “Can I continue to use Windows Server 2008 or Windows Server 2008 R2 after they reach end-of-life?” then I want to assure you that you can.
The Windows Server Support Cycle
Each version of Windows has a clearly defined lifecycle. When Microsoft releases a new product, they publish its milestones: the date of its beginning, the date that its mainstream support ends, and the date that its extended support ends. For some products, they also include an end date for service pack support, although differences in product support practices can make that chart unintuitive. For Windows Server versions through 2008 R2, the product without Service Pack 1 had a different lifecycle than the same product with a Service Pack. As a result, you will see some EOL dates for these two products in 2011 and 2013. As long as you have installed Service Pack 1 on either of these operating systems, the January 14th, 2020 date applies. You can check the table yourself.
Typically, Windows Server has a five-year mainstream support span followed by a five-year extended support phase. Microsoft can change this for new releases if they want, but they adhere to the published plan once a product ships. This gives every customer a clear opportunity to understand exactly what to expect in terms of support for any given product. They will not have surprises.
Microsoft does make occasional exceptions, but almost always as extensions. These extensions usually have special conditions attached. For instance, they might choose to patch an especially nasty security flaw in an EOLed product. They might provide extended support for an EOLed product, but only in strictly-defined conditions. For very large customers in very special circumstances, they may offer full support for a defined length of time. These things happen most frequently for desktop operating systems. Do not expect any special treatment for Windows Server 2008 or 2008 R2 – almost none of us will get it.
Addressing the EOL of Windows Server 2008 and 2008 R2 in Practical Terms
As usual, the looming date has brought out the Internet punditry in full force. The confusion and uncertainty create a ripe environment for all sorts of fear-mongering, wild speculation, and blanket judgment. The situation deserves a more well-rounded response.
The Pundits are Wrong
I’m sure that you have read at least one article that tries to make you feel like the worst administrator in history if you haven’t eliminated all of your Windows Server 2008/R2 systems by the EOL date. We saw the same ones for Windows XP and Windows Server 2003. Probably had some for the 2000 series products as well, although I don’t personally recall any. First of all, if your major sin is running a server operating system instance past its lifetime, then you’re not even in the bottom 50%.
Most of these article writers have never worked in an internal IT department. Very few have ever worked for a general-purpose outsourced IT provider. Of the handful that have done either, most worked strictly with technologies built for technologists, meaning that they had little or no intersect with line-of-business applications. To them, an “IT Generalist” is a person that has to maintain the SharePoint environment and the Exchange environment, and sometimes even the Windows Servers that they run on! They literally have no idea what an authentic generalist deals with, meaning that they have absolutely no clue what you put up with from your vendors.
When You Must Play Along
To get the responsible guidance parts out of the way, those pundits are not entirely wrong. Some systems really need the upgrade and I don’t expect to see many valid excuses to the contrary. A few things come to mind:
- Windows Server installations that use only Windows Server features (file, print, domain, etc.)
- Installations running only Microsoft application servers
- Servers hosting applications by a vendor that provides migration or upgrade guidance
If you can make the upgrade, make the upgrade.
When You Have to Make Do
Let’s turn to the harder situations. If you’ve never had a vendor that required you to stay on a ridiculously out-of-date version of something to continue using their mission-critical product, then count yourself lucky. At this point, the pundits tend to jump in with proclamations of, “Vote with your wallet,” or, “It’s your fault for not choosing another vendor,” or, “You can just wave your magic ‘the customer is always right’ wand and all the vendors will suddenly do your bidding,” and other ignorant platitudes. Those of us in the trenches know that reality does not bend that way. Personally, I have some major vendors that have no alternatives, and if one ever shows up, switching to them would literally require architects, helicopters, and multi-month construction projects.
Pundits often act like the providers that refuse to move on are insignificant outliers. Obstinance among vendors is common. Just look at the struggles that Microsoft is having with convincing the software manufacturers of the world to stop relying on SMB1. Take a look at the company names on that list; I’m certain that you recognize at least a few. I’m equally certain that you understand the importance of those players in their respective markets. Some of the names that you might not recognize have even greater presence in their verticals. If pressure from Microsoft can’t get these organizations to move off of a thirty-year-old protocol with demonstrably superior alternatives that have been available for well over a decade, what chance does a typical small business have for convincing anyone to abandon a ten-year-old operating system that still functions adequately?
Vendors generally stick with old technologies for a simple combination of two reasons: some technological advances require significant changes, and no company makes significant changes without an equally significant incentive. In 2010, two of my vendors required us to use a Windows NT 4.0 system to integrate with their hardware. The changes to the hardware abstraction layer in Windows 2000 Server placed substantial demands on legitimate driver builders. The products that these vendors made were crucial to our daily operations and they had no competition at all, so forcing us to stay on Windows NT was the path of least resistance for them.
I do not personally know of any comparable technology changes that favor remaining on Windows Server 2008 or 2008 R2. Windows Server 2008 was the last release of Windows Server that still allowed for 32-bit only installations. I can imagine that some software makers want to continue with that. I know of a few that require customers to install their application server software on Windows desktop installations specifically because they still have 32-bit architecture offerings. I wonder if they have even tried to work with a 64-bit installation; the AMD64 architecture became king specifically because it runs both 32-bit and 64-bit code natively. 64-bit Windows on an AMD64-compatible chip should easily handle anything that would run on 32-bit Windows. However, the vendors make the rules for their software, and customers rarely have any choice.
It’s not always a matter of technology. Sometimes it’s laziness or greed. A vendor might not support migrations unless they perform them. If they publish migration guidance, customers might not have the necessary expertise on staff. A provider might prioritize new customers over existing customers, refusing to show up to help out. More commonly, a vendor will perform the migration, but only for an exorbitant charge. Cash-strapped businesses (or cheap business owners) might opt to take their chances with old systems.
Anyway, it doesn’t really matter why you must continue using old operating systems. It happens, vendors don’t care about the plight of their customers and their systems administrators, and we must deal with the consequences.
How to Move Forward from Windows Server 2008 and 2008 R2 EOL
To get started, you must perform your due diligence. Research the upgrade and migration paths for all of your systems. Move the ones that you can. If you need to make a business case to convince your employer, then do that. You have the knowledge that you need. Build a persuasive presentation from the facts:
- Leaving security holes unpatched makes you vulnerable to breaches. Or, perhaps more convincingly, a breach earns you a featured, but distasteful, spot in the news. Using unsupported software makes it that much worse.
- The greater the distance between the installed OS version and the current OS version, the more difficult upgrade and migration paths become
- Hardware failures become unrecoverable
- Support structures become unavailable (e.g. backups, external or replacement expertise)
- Maintenance costs increase
Old systems might hold other systems back (e.g. connectivity and compatibility)
If you have no way to move forward, then you must hunker down. Essentially, you must build the most impenetrable wall possible.
If available, use hardware firewalls and VLANs to isolate the system
- Alternatively, enable and tighten Windows Server’s built-in firewall
- Leverage the isolation techniques native to hypervisors
- Reduce membership in the Administrators and other privileged groups to the minimum
- Maintain locally-installed antimalware for as long as possible
- Institute the strongest possible border protections
Implement regular monitoring and auditing practices
Most of these suggestions describe general best practices for all server installations. You can find the primary difference in the first bullet point. Even in higher-security organizations that normally segregate server systems, servers typically reside in a flat network with other servers. That creates opportunities for network-aware attacks to move laterally. We use other defenses to combat that, such as firewalls, anti-malware tools, intrusion detection and prevention systems, etc. We also implement operating system patches as quickly as feasible. Once the operating system reaches end-of-life, we lose patches and the antimalware and IPS vendors lose interest. So, the risks of keeping old systems in the same network continually increases. So, regardless of your organization’s overall security requirements, the effort to maintain those old systems also increases.
I assume that only a handful of systems administrators will keep their 2008 and 2008 R2 systems out of sheer laziness. I doubt they do enough research that they’ll even find this article, so I won’t address anything to them. I expect that if you did arrive here, that you have a legitimate problem that requires you to either forge forward without help or stay on an old system against your will. I understand your plight; I’ve been there. My best advice: be a persistent nag. Every single time that you talk to any representative of the vendors that plague you, ask when you can modernize. Until that day comes, hang in there.
Get a 30-day trial of Altaro VM Backup for MSPs
Manage all your customer VM backups from a single cloud console, on a monthly subscription. Try Altaro VM Backup for MSPs for 30 days - no strings attached!
Not a DOJO Member yet?
Join thousands of other IT pros and receive a weekly roundup email with the latest content & updates!