Over the months and years leading up to the end of Windows XP in April 2014, I suggested an alternative that could help people wrap up their projects under the deadline: Migrate troublesome applications that require Windows XP to Windows Server 2003.
It made sense because Windows Server 2003 is the “server version” of Windows XP. Applications are likely to be compatible with it, and support for Windows Server 2003 wasn't slated to end for another fifteen months after XP.
Time flies! Now we’re nearing the end-of-life date for Windows Server 2003, which is July 14, 2015. It’s not going to be the industry-wide kerfuffle that migrating from Windows XP turned out to be, but for some organizations there will be challenges.
There are two groups of companies that are still using Server 2003 for their desktop virtualization: Those that are stuck in the past because they chose to be, and those that are stuck in the past because of a particular application.
Companies that chose to be stuck in the past are the ones that decided Server 2003 -- alone or with help from Citrix XenApp -- was enough for them. Faced with forklift upgrades at every turn, they just chose to continue business as usual. If you’re one of these companies, I hope you enjoyed your few years off, because you’re about to undertake a rather large upgrade.
Other companies didn’t choose to remain on a twelve-year old platform so much as they’re handcuffed to it. There are many instances where companies have to support an old application -- like the reason I suggested migrating XP apps to Server 2003 in the first place. Sometimes they’re 16-bit applications that require a 32-bit operating system. Other times it has to do with browser applications that require Internet Explorer 6 or 7. Sometimes there are just apps that are flat-out incompatible with later OSes.
Companies with applications that simply require Windows XP/Server 2003 might be in trouble, but there are some things you can to do ease the transition.
What to do if you're still on Server 2003
For browser-based applications, you could look into a browser virtualization platform such as Browsium. It enables modern browsers to use legacy Web apps, treating each application as standalone. That means if you have an app that requires IE6 with a certain version of Java as well as another app that requires IE7 with a different version of Java, you can run them simultaneously on the same system.
On the other hand, if you have an application that requires 16-bit support, you have a few choices to make. If you have to have a Remote Desktop Session Host platform deliver your application, you’re limited to Windows Server 2008 (not R2).
If you’re a Citrix shop, the only version of XenApp that runs on what amounts to Vista Server is XenApp 5, which has been in the retirement home since January. Support doesn’t officially end until Microsoft ends support for Server 2008 in January 2020 (the same day as Windows 7), but you can only count on paid support and emergency patches. Besides, if you use XenApp 5, you’re nearly three releases and an entire backend away from being modern. You’re just trading one antique platform for another.
The better option for 16-bit applications (or anything that needs a 32-bit OS) is to use desktop OSes. Windows 7, 8, and even Windows 10 have 32-bit versions that might work for you. You can deliver these desktops to physical machines, via a VDI platform or even via DaaS.
Of course, the best thing to do would be to get rid of the offending applications altogether and modernize your entire desktop and application delivery platform, but it’s good to know there are a few tricks left in the hat. They may be more involved than simply swapping out Windows Server 2003 for Windows XP, but they set you up for an easier transition in the future.