Windows Server 2003 Reaches End of Life In July

Several readers sent word that we're now less than six months away from the end of support for Windows Server 2003. Though the operating system's usage peaked in 2009, it still runs on millions of machines, and many IT departments are just now starting to look at replacements. Although Microsoft publishes support deadlines long in advance -- and has been beating the drum to dump Server 2003 for months -- it's not unusual for customers to hang on too long. Last year, as Windows XP neared its final days of support, there were still huge numbers of systems running the aged OS. Companies lined up to pay Microsoft for extended support contracts and PC sales stabilized in part because enterprises bought new replacement machines. Problems replacing Windows Server 2003 may appear similar at first glance, but they're not: Servers are critical to a business because of the applications that run on them, which may have to be rewritten or replaced.

[In many cases, legacy applications are the sole reason for the continued use of Server 2003.] Those applications may themselves be unsupported at this point, the company that built them may be out of business or the in-house development team may have been disbanded. Any of those scenarios would make it difficult or even impossible to update the applications' code to run on a newer version of Windows Server. Complicating any move is the fact that many of those applications are 32-bit -- and have been kept on Windows Server 2003 for that reason -- and while Windows Server 2012 R2 offers a compatibility mode to run such applications, it's not foolproof.

Comments

It's not simple to just go and upgrade

[Neo-Rio-101]

The reason why a lot of these businesses haven't upgraded is because it usually takes years to make this happen.
If you're a business who IT department or enterprise support vendor is running in full ITIL mode with a few ISO business standards thrown in for good measure, it really does take that long.

The amount of paperwork and busywork that needs to go into something as relatively simple as an OS upgrade is something to be marvelled at when you actually have to work in that environment. There are whole massive bureaucracies and months of meetings, followed by change review boards, and more change review boards and testing and more testing and backout plans, and risk registers, and more meetings, and then you have to wait for the next meeting to come along before going onto the next stage.... and and and......

So to all these people saying "just run open source" have never run a multimillion dollar business and relied on Windows to bring home the bacon. Much less have they ever considered being a large collossal IT support vendor that has to maintain SLAs and can get hit for penalities of millions of dollars if those SLAs are breached. These are not nimble organisations. They are not cowboys. They cover all possible failure scenarios and document everything from multiple support networks before they lay a single mouse click on the box.

Re:End of support, not "end of life".

[dissy]

My understanding is that fixing newly discovered vulnerabilities in Windows XP or Windows Server 2003 would be fairly inexpensive.

One more downside to being closed source - if Microsoft won't fix vulnerabilities, no one else can for any sane price.

At work I'm still migrating our last two 2003 servers, one migration nearing completion the end of this month, and the next not even started yet but expecting to take 9-12 months.

Exchange server was our primary risk because by its nature it has to handle SMTP, and while you can't poke that server directly from the Internet (a postfix relay server is the only one with direct internet exposed ports) but those emails still flow through it, and it sends outgoing mail directly so has to connect to other MTAs and everything involved with that like DNS queries... A pretty big risk footprint on that one, so no argument from me that it needs upgraded.

The last 2003 server however doesn't technically require being replaced, the risk is very small and mostly controlled for even then. It would likely run fine until enough hardware failures make keeping the server up cost prohibitive, which is really the biggest reason (though a fairly justified one) to upgrade.

The vulnerability risk footprint is limited to the LAN, and then only really to windows file sharing (that and SQL server are the only exposed services)
Not zero for sure, but taken alone not enough of a reason to justify the cost of an upgrade. Only everything taken together combined with a string of purchase approvals to upgrade everything else that demands it, is why it ultimately will be.

If only another big player could release continued security updates, or ideally more than one to help both competition on price and a choice of whom to trust for such a thing.
There is definitely a market for very long term support, which you have to look no further than IBM to see.

In fact many would trust IBM to fill such a role if they were to do so. Others may trust Google. I'm sure there are plenty of other examples as well.
But I don't see "long term windows support" being in many of those companies interests, nor see microsoft going along with such a plan even if they were.
Microsoft wants you to buy their latest shiney instead, Google would prefer you didn't use Windows at all, and IBM doesn't seem to be as big on the support thing these days even for their own products let alone microsofts.

All of those facts factor in to the cost of providing security updates, and does raise the bar quite a bit higher than it would appear at first glance.

Re:A reason to go with Open Source

[Chrisq]

So, which Linux distro that I installed in 2003 still has active security updates today? Which one even had more than four years of support?

RHEL 4.0 which was available in 2003 and will be given extended support to the end of this month.

Re:A reason to go with Open Source

[DarkOx]

Fair enough, but there are some really key differences between the Linux world and that of Windows and even Unix.

You distribution tends to package like 90+ % of the software on the system. The left over 10% is whatever in house app the server is running or 3rd party app you bought. All the libraries it uses, and support software that it uses database engines, etc typically are in the distribution. So the integration details library versions supported version issues are all taken care of for you.

On Windows this absolutely not the case. Things like databases, libraries for document rendering, and just about anything else you can think of is maintained outside the OS distribution. So Windows is where you upgrade and discover UAC totally breaks the version of ${SOFTWARE PACKGE} you have installed or changes to winHTTP cause all the web service calls to fail etc. Even if they mostly are other first party applications like SQL Server or Office. Its also true that its harder to isolate things. If you install something to /opt or /usr/local on a Linux box and those are separate partitions you can have reasonable confidence that blowing away / won't and reloading it from distribution media will leave you with a working app where you left it. Good luck with that on Windows unless you designed the package yourself and avoided the registry and tens of other possible pitfalls.

So again speaking in the general case its easier to go from RHEL 6.x to RHEL 7.x with an in place upgrade, as is true for most other Linux distros; however you do it, let package manager figurout distupdage or re-install a fresh /.

In most of my travels I have not seen 10+ year old Linux versions in production unless its at the same kind of shop that also does not care to patch or be on a supported version of Windows. Even in shops that are good about patch management get their WSUS updates applied etc ( I want to be fair to MS here these rarely if ever break anything) there is still lots of legitimate fear around upgrading an application server between major Windows versions. So in lots of cases Windows boxes tend to stay on whatever release for either the life of the hardware or the life of the app whichever is shorter. Linux boxes tend to be upgraded more frequently.