Now no longer supported, Mark Newton explores the issues facing businesses that need to upgrade from Windows Server 2003
Microsoft's official retirement of Windows XP last year was mainstream news. The end of support for Windows Server 2003 in July has been much quieter, but it's just as important to think how this might affect your organisation. Like XP, Server 2003 was a successful and well-liked operating system, and many businesses are still using it, having seen little reason to upgrade to later versions. There are probably many setups where this OS is still running on the original hardware, now 12 years old or more! In scenarios such as that, even if the OS weren't coming to the end of its life, it would make sense to consider upgrading just to refresh the hardware before it starts to fail.
If your business is reliant on Windows Server 2003, you may be tempted to stick with it. After all, just because the manufacturer decides that the operating system has reached the end of its supported life, this doesn't mean it will suddenly stop working. But running a production server without security patches is asking for trouble, and now that the OS itself is officially unsupported, you may hit problems when trying to update the applications and services running on it.
Who's still using Server 2003?
Businesses are gradually moving away from Server 2003 – but the old OS is far from extinct. According to a recent survey by Vanson Bourne on behalf of the Cloud Industry Forum, Server 2003 usage among organisations of fewer than 20 employees has fallen from last year's 58%, but remains at a worrying 44%.
The picture is worse for larger organisations with up to 200 employees. Here, 51% are still invested in the obsolete server platform. And when it comes to big enterprise, things look grim indeed: thanks to the complexity of large-scale infrastructure upgrades, 72% of organisations with more than 200 staff are still reliant to some extent on the discontinued operating system.
With so many unpatched systems out there – in many cases running high-profile business services – it's almost certain that hackers already have Server 2003 in their sights. The sooner you can move to a more secure operating system, the better.
The best upgrade method
So what's the best way to upgrade the operating system? Don't even consider attempting an in-place upgrade over the top of the existing Server 2003. For a start, you can't migrate directly to the latest release: you'd need to upgrade from 2003 to 2008 before moving up to 2012 R2. Even if this process went smoothly, which is far from guaranteed, the amount of downtime involved would cause a lot of disruption to your organisation.
And what will you do if, after the upgrade, you find that some legacy system won't work with the newer OS? Windows Server has evolved and changed over the years, and several older technologies have been dropped. For example, the multitude of ways in which a program can communicate to a data source has been rationalised: if you have a program that talks to your database via a technology such as RDO, then after the upgrade you'll find that nothing will work and you need to rewrite the program to work with ADO.NET (although, to be fair, it's probably time you did this anyway).
Another area that might give you problems is the XML parser, which has changed significantly. Other problems can stem from the level of security set by default in the OS, and while you can disable many of the newer security features and open things up, you need to ask yourself if you really should: if you were starting afresh, wouldn't there be a better and more secure way of configuring your new server?
Because of problems like these, I'd suggest starting with a clean install of 2012 R2 on a new machine and working from there. At the very least, if your hardware is as old as the OS, upgrade it – although of course by now it may have been virtualised onto a newer box.
Image Leonardo Rizzi - Flickr
Your second decision is which version of Server 2012 to use. There are nine in all, the main four being Datacenter, Standard, Essentials and Foundation. There are also two versions of Storage Server, two versions of MultiPoint Server and a Hyper-V version, but these are unlikely to be used to upgrade an existing box as they are specialised for virtualisation, storage, or multiple- user access. If you're currently using Server 2003 for any of these tasks it might be worth sitting down and rethinking your network structure.
So, going back to the more standard versions of Server 2012 R2, which should you choose? Datacenter is designed for large servers on which you intend to virtualise more than a couple of machines. Not surprisingly, the price reflects this. Standard will allow the virtualisation of a couple of machines and you may well find it's the best version for your needs, partially because it's very flexible in its configuration: unlike Essentials, Standard doesn't have to install as an Active Directory (AD) server. As a consequence of Essentials being an AD server, the installation of a SQL Server database on the same machine is also discouraged, for reasons of security and performance.
Be aware that if you decide to join a 2012 server to your existing domain, then the whole domain will have to be migrated to the new format, as the schema of the 2012 AD is different. This process is relatively painless, but you must give some thought to any issues that may arise when you upgrade all the domain controllers on your network, and allow time for all the synchronisation to take place between the various domain servers.
Foundation is the most limited version, and normally only available when bought with new hardware. It's suited to businesses with fewer than 15 users; think of it like the old Small Business Server.
The painless upgrade process
As you can probably deduce from all the above, for my own upgrade I opted for Windows Server 2012 Standard. The first question was whether to create a new domain or add the new server to my existing domain. I opted for the latter, and found the process almost painless.
In fact, it's fair to say that the whole install process is one of the nicest I have used. While you can run the usual Adprep command lines as before, things have been made much simpler and diving into the command prompt shouldn't be necessary. You may be aware of a bug that has caused issues for many businesses when upgrading: this was caused by the Kerberos security authentication failing between 2003 and 2012 R2 servers, leaving users unable to log in to the domain at times.
Thankfully, there's now a hotfix available for this, so it should no longer be a problem.
In addition, if you're used to 2003 or workstation installs, note that the days are now gone where almost everything was installed by default: you'll need to specify which roles you want your server to provide. Fortunately, the setup procedure holds your hand through this process with excellent descriptions of each task. After you've completed setup, you can go back to this screen to add further functionality if you discover something missing, such as the SMTP service that no longer installs by default alongside the web server.
It makes sense to start by installing the major components that you require, and then go back and add any lesser ones, particularly if they might be dependent on being part of the domain. Take your time and examine each option's dropdown list so you know exactly what you're installing. If you also plan to run an SQL server database on the same box then don't set it up as a domain controller, not even a Read-Only Domain Controller. Indeed, this configuration is specifically discouraged by Microsoft for security and performance reasons – so don't do it!
One component that is enabled by default in Server 2012 is the firewall. It's tempting to switch this off and rely on the firewall box that you have in your rack. While this is a perfectly reasonable thing to do, just stop and think for a while: the internet is riddled with potential threats, and any extra defence could be useful, so unless the firewall gives you a real issue I recommend that you keep it enabled. The only thing to be aware of is that if you have SQL Server running on a firewalled box, then to access SQL Server from another machine you'll need to open port 1433, as well as enabling named pipes within SQL Server itself. Obviously, you'll only allow access to this port from within your own network, and possibly only from certain machines.
The other gotcha for anyone configuring a web server that uses classic ASP rather than ASP.NET is giving the IUSR account read permissions to the root folder of your website. This is different to 2003, which just assumed you wanted to do this. Now, if you want to make things a little more difficult for hackers, you can change the account that the web server uses to one of your choice.
Upgrading from legacy technologies
When you move from Server 2003 to 2012, you're leaping across several years of progress, and as mentioned above, numerous technologies have fallen (or been pushed) by the wayside. There isn't a single list of what's been removed between those two particular releases, but usefully, Microsoft offers lists of technologies deprecated in Server 2008, 2012 and 2012 R2.
Skim these pages and you'll see that plenty of things have gone, including JRO, the Microsoft Jet database engine, MSDASQL, Oracle ODBC, RDS, SQLXML, ESQL/C, DAO, DB-Library, MDAC and .NET Remoting. Remote Storage services have been deprecated too, along with support for the IPX/SPX protocol favoured by Novell servers (remember those?), services for MAC, NTBackup, Remote Installation Services,
Windows Recovery Console, the licence logging service and support for non-ACPI HALs. If, having checked these pages, your company relies on a technology that isn't supported in the modern server operating system, then you have three options.
The first is to virtualise your existing server and keep it running. This exposes you to all the dangers of running an unsupported operating system, and only puts things off until the day when a real solution will need to be found, but it could be the right choice if you know a compatible version of your software is coming soon.
The second option is to add the necessary support files to re-enable an obsolete technology on the new server. This might be a solution for a data transport layer, for example, but it isn't recommended: if this leaves your business reliant on an unsupported solution, it should be avoided if at all possible.
The third option, and the best one if available, is to upgrade your application so that it no longer uses the unsupported technology. In all cases, if there's any doubt at all about whether a third-party component or program will work, it's very important to fully test your proposed new setup on at least a virtual machine, to catch any issues before you go live.