For some organizations, just catching their breath from a Windows XP end of life that took them by surprise and more time and effort than they anticipated, I have some bad news: There is no rest for the weary. The next big end of support horizon that you need to be concerned about is Windows Server 2003/R2 on July 14th of next year. That’s 322 days as of this writing.
What does End of Support Mean?
Under Extended Support last calendar year (2013), Microsoft released 37 critical updates for Windows Server 2003/R2. No new updates will be developed or released after July 14th, 2015.
Lack of compliance with various regulatory and industry standards and regulations can have a huge impact on an organization For example, lack of compliance with the Payment Card Industry (PCI) Data Security Standards might mean that your organization can no longer accept major credit cards without using a third party (which might prove costly if not inconvenient).
No safe haven
Both virtual and physical instances of Windows Server 2003/R2 and Microsoft Small business Server (SBS) 2003 are vulnerable and would probably not pass a compliance audit.
How big a job is this?
Microsoft estimates that at the enterprise level, the average server migration take approximately 200 days of elapsed time and the average application migration takes close to 300 days. Of course these numbers are not based on level of effort but from project start to finish (consider project planning, needs analysis, procurement, testing, etc.).
So how do we make best use of the time we have left? I would hope that as we are fresh from out Windows XP migrations, we have learned some lessons that we can apply to accelerate our Windows Server 2003/R2 migrations. Two key learnings that I’d like to explore in this post are concern application compatibility and application deployment.
The biggest issues that most organizations will face will be around application compatibility. What we have found in our Windows XP migrations is that there is a class of applications that no matter what you do cannot be made compatible without some recompiling at a minimum. The applications I am referring to are 16-bit applications. The reason for this is based on the implementations of Windows-on-Windows (WoW):
- Wow can be used to run 16-bit applications on a 32-bit Windows OS
- Wow can be used to run 32-bit applications on a 64-bit Windows OS
- Wow can NOT be used to run 16-bit applications on a 64-bit Windows OS
These same issues will present themselves with Server 2003/R2 migrations. However; if you are moving to Windows Server 2012/R2 (and why wouldn’t you?) – there is no 32-bit version available. Applications that are susceptible to these compatibility issues need o be dealt with in a different manner. Perhaps a small pool of 32-bit Windows Server 2008 servers. You will have until 2020 until extended support for Server 2008 runs out.
As part of migrating and existing application or deploying a new application, best practices would recommend having at a minimum of three segregated environments:
Virtualization has made this much more economical and accessible to smaller organizations. One of the issues I see is moving applications between the environments. I can be time consuming and error prone. One way to minimize the level of effort and increase the accuracy is to use Server App-V. Server App-V (part of System Center Virtual Machine Manager) is a technology that enables virtualization of server applications. With Server App-V, you can create a package that contains all of the required elements of an application (including configuration information) and deploy it simply by “copying” the package to the target server. No changes (registry, service, COM, DCOM, COM+, WMI, etc.) are required on the target server. Server App-V addresses the full lifecycle of an application including deployment, updating, and retiring.
Server App-V is can be used with or without SCVMM but the greatest advantage to the technology comes from integrating packages into VMM Service Templates.
Now go out and upgrade those servers.