Application Compatibility - Who?, What?, Why?, How? - Part 1

In the last few weeks I have been involved in many meetings around Windows 7. I am currently a part of my 7th Windows 7 migration and was also on a team assisting with a Windows Vista migration. During my time with my previous employer I was also a member of an exclusive team of Techs who travelled around to other countries to perform Windows 7 Application Compatibility and MDOP launchpad workshops. I feel at this stage of my career I have had a significant exposure to the Migration process. Even in the early Beta versions of Windows 7, I was working on investigating changes to Windows Installer, NTFS Permissions, ACT, AppLocker and a whole host of changes to Windows Operating System landscape.

Across all of the projects I have worked on, one thing is all too common. Teams, People, Customers were all intimidated by the application compatibility aspect of the OS migration and that is understandable. It is my opinion and quite frankly, I believe a fact that your applications are the most important part of your IT tool belt. Creating a Windows 7 image is relatively simple, more info which is helpful for that can be found HERE and HERE The OS Deployment is also relatively simple, more info for an example of how to do that can be found HERE with more useful info in Part 6 of this series. Data Migration is pretty challenging but once you’ve got it set up and going it can be a case of set it and forget it. The applications are the most important component. You can give your users a nice flashy Windows 7 desktop with your company branding on it and all of their files and user settings carried over from their previous system, but if they don’t have the applications to open these files or the applications to actually perform their daily work then your Windows 7 desktop isn’t worth a damn. Applications drive productivity and are critical to your business.

With all that stated, application compatibility does not have to intimidate you. With the correct planning and the correct tools it can actually be a very logical step by step process with less pain points than you might think. I will cover the common process adapted for migrations in the coming parts of this series of blogs and add my own insight from the variations I have seen adopted on projects over the course of my career. Before moving onto the process though, let’s get an understanding of Application Compatibility and what you need to know.

Microsoft state that it is not their intention to break applications when releasing a new operating system. To their credit they do provide vast amounts of documentation in advance of a new OS coming to the market. In my experience in-house developers do not seem to adhere to this documentation and so that introduces challenges. If you are just migrating OS, right now. You are unfortunate because you are likely under great pressure to complete the migration within a very tight deadline but you are also fortunate in a way. The bulk of applications in an environment tend to be purchased from third party vendors, as they are in the job or providing applications they tend to revise applications for newer OS’s to keep them in line with changes in the IT landscape. For early adopters of an Operating System this is often not quick enough as they find themselves being unable to get a compatible version of their software to use. But this being 2013 and Windows 7 coming out in 2009, it means vendors have had a lot of time to bring their applications up to par and so it’s likely that the majority of your third party applications in your environment will likely already work out of the box for Windows 7. Not so fast though, Don’t forget about those applications developed in-house, you still need to analyze these and remediate accordingly. Also another consideration, with hardware advancing, many companies are not just moving to Windows 7 or Windows 8, they are also moving to a 64-bit architecture. In my opinion this impacts on your application compatibility more now in 2013 than moving to Windows 7 itself. Your applications over the years have become Windows 7 certified simply by proxy, through your maintenance plans and progression of moving to the latest and greatest. Hell, even if you aren’t bleeding edge, it’s quite likely a lot of your applications have been upgraded since 2009. Unfortunately if you did not have 64-bit systems out in your environment all of your apps are currently 32-bit.

With 64-bit systems the majority of your 32-bit applications could actually work without issue. This is due the Operating System having WOW (Windows on Windows) emulation. Which in essence is a 32-bit file system structure alongside your 64-bit structure. If you install an application with 32-bit components on a 64-bit OS, the files and folders should go to C:\Program Files (x86) while your 64-bit components will install files to C:\Program Files. Any 32-bit components that put down HKLM registry during the installation will go to HKLM\Software\Wow6432Node while 64-bit components will go to HKLM\Software. Any 32-bit components installing anything to the system files will now go to a folder SYSWOW64 While 64-bit goes to System32. At first it can be confusing, you may look to verify ODBC settings and not see them but it’s most likely because they got installed to other directory. It’s not really a challenge to learn but rather just a habit you need to adapt. Along with the fact the registry now gets redirected this can cause some compatibility issues when 32-bit apps install certain shell extensions. Also with 64-bit, Microsoft pulled support for 16-bit Installers and any 16-bit code (This is not a huge concern as this is incredibly outdated by now, most companies do not have 16-bit components in their environment) Drivers are really the main concern as drivers for 32-bit applications will not work and also no unsigned drivers will not install. For the most part the vendors of these types of applications will have a 64-bit version of the application which you should be entitled to with your current licensing. Hard-coded paths is another big concern. If paths have been hard-coded to locations such as C:\Program Files and the files are instead installed to C:\Program Files (x86) then obviously you will have problems. It’s possible if you are using old applications with 64-bit compatibility issues and it’s a real legacy application then the vendor might be out of business, if that’s the case you will need to look at different solutions such as virtualization or a new product.

Windows 7, Windows Vista, Windows 8, Windows Server 2008 (R2) and Windows Server 2012 all have changes to the OS from the XP days which should be noted. For example C:\Documents and Settings is no more. That has been replaced with C:\Users. Your applications which install or created run time files for your user profile should now go to C:\Users\Username. You may also notice folders for Roaming, Local Low and Local. Local is where your standard user files should go. Local Low is more a secure user writable location which can be leveraged by processes such as applications, to write user files to stop these processes from seeing your user data. Roaming is for Roaming profiles on domain computers if you plan to leverage the Roaming profiles option which I will discuss in another part of this series. You may also notice there’s a folder for C:\Users\Public which is the equivelant for All Users now but for compatibility purposes Microsoft have a ‘virtualization’ layer which can re-direct files and folders. If Windows Installer detects files which are set to install to C:\Documents and Settings\All Users these will instead be installed to a hidden folder C:\ProgramData.

Compatibility issues for Windows 7 and later include: Gina Dll, The Gina Dll has been removed from the OS, this was an API which may have been leveraged by internally developed applications which required user logon. Session 0, The OS, although not visible to the user has been split into layers\contexts. XP ran all process and functions visible to all contexts and layers, whilst Windows 7 can execute certain processes and tasks in the background and also ensure for security purposes that a greater level of integrity is upheld on the user layer so they cannot perform certain tasks, unfortunately some applications may execute processes which will actually execute in Session 0 rather that the User session so if the process has a prompt for user input that dialog will never appear to the user as they do not see that layer. This is not all that common. Deprecated components can cause problems, Microsoft update or strip certain API’s and so if an application leverages any of these to function they will not work on the new OS, however as stated previously, Microsoft are not setting out to break applications so in many cases the new API’s provide backwards compatibility to allow applications to use an updated API.

If you are moving from XP to Windows 8 you will hit against all of these issues plus a few others with some different deprecated components as well as possible issues with applications that integrate with Explorer. Also you should beware that obviously with the tile interface you may not be too happy with how your shortcuts appear and may want to dicky things up a bit. Customizations you may have set in your own application packages might also have an impact on compatibility which is in a later part.

The biggest challenge with application compatibility with Windows Vista and later is the introduction of UAC (User Access Control) which annoyed users to no end. It was a very intrusive security tool which would black your screen and prompt you: “Are you Sure!?” “No, No, Are you really Sure!?” Luckily for everybody partly down to Microsoft making the UAC less intrusive and partly down to vendors falling in line with security best practices with their applications. UAC is not such a big issue anymore. However it is by far the single largest cause for application remediation on Windows 7 in my experience. I will address how to fix and remediate these issues later in this series.

That’s the large and skinny of Application Compatibility really. Most issues with Application Compatibility are actually very easily fixed. The most important aspect to a successful migration is not the remediation itself and that amount of effort, rather, it’s the planning and process followed to ensure a timely move.

I will be covering the following topics as part of this series.