One of the biggest challenges when upgrading to Windows 7 is in testing and preparing applications. This blog puts together a few conclusions that might assist you in planning the work.
The extended lifespan of Windows XP and Server 2003 has been a sort of "peace dividend" or "pension holiday". When you do come to upgrade it is important not to underestimate the cost and uncertainty involved in application compatibility. But at the same time you don’t need to accept that the migration will take forever.
The problem is that applications can be incompatible with Windows 7 in many different ways. Some of these are trivial and easily solved. Some are harder to solve. Some are hard to find and impossible to solve. You don’t know until you test. The same applies to running the applications in Citrix on Server 2008 R2, with the added complication of 64-bit. Here are a few examples to illustrate:
Standard third party application: Lotus Notes
- The current version 8.5.1 is not certified on Windows 7. Does it work OK or not? Do you wait until later this year for 8.5.2, or go ahead with 8.5.1? There is a patch, Fix Pack 1, that is certified but it adds complexity to the installation.
- You would think it would be quite simple to find out: ask the vendor. But most vendors do not certify previous versions. That does not mean they don’t run perfectly well. In this case, although 8.5.1 is not certified, the release notes for Fix Pack 1 contain only trivial changes and 8.5.1 appears to work fine, so there is no reason to delay.
Specialised third party application: legal software
- The installation fails on Vista/Windows 7. Examination of the logs and the Windows Installer file shows there is a custom action to copy templates into the user profile path. The path is hard coded and fails.
- The solution is to customise the installer to remove the custom action and replicate it in a custom script. Inform the vendor so they can modify the installer.
Custom system: membership database
- This is an old system with a SystemBuilder 4GL graphical interface to a Unidata database. The version of SystemBuilder being used is not certified or even tested on Vista/Windows 7. The SBClient application contains an OEM Pervasive SQL client that is also obsolete. The client does mail merge to Word 2003, so it would need to be tested if used with Word 2007 or 2010.
- There is a new version of SystemBuilder that, amazingly for such an old product, is certified both on Windows 7 and on Server 2008 R2 Terminal Services. The new version seems to work perfectly with the old system. However you need to change the client side and the server side of the graphical interface at the same time, so it would be a big bang change to a critical system.
- But, after packaging the old version using Wise Package Studio, it seems to work fine on both Windows 7 and on Server 2008 Terminal Services, so there is no need to upgrade.
Other Gotcha’s
- Applications with OEM versions of Crystal Report 11 or earlier do not install on Windows 7. Crystal Reports 11 is not supported on Windows 7, and you can’t upgrade an OEM edition, but it can be modified to install successfully.
- Applications using the common VB6 SendKeys function raise an error on Windows 7. Sendkeys does not work with UAC. UAC can only be turned off per computer, not per application so there is no workaround except to turn UAC off entirely.
- In XP you can use the Printer button on the PageSetupDialog to set different printer properties for an application. In the Vista/Windows 7 API it’s gone. There’s no error, it’s just not there. But in .NET Framework it’s still there! This might seem rather obscure, but the point is: you would have to do a lot of testing to discover this and then find out whether it matters to your users of that application.
Obviously you could wait till your applications are fully tested or upgraded to the latest certified versions, but this could take impossibly long. If you have just one core application that is not ready, you can’t upgrade the desktop.
A lot of people seem to be combining application virtualization with a Windows 7 rollout. Perhaps surprisingly, application virtualization is largely irrelevant to compatibility across OS’s. With a virtualized app, the same dll’s run within the OS with exactly the same results. If the application faults natively, it will fault when virtualized. Virtualization can be used to implement a compatibility fix, but you still need the fix.
The best way to approach this is with a structured testing environment and a full set of delivery options. Then, for the difficult applications, you can set a time limit.
Structured Testing Environment
- Wise Package Studio or similar, to examine the internal structure of the application and check for conflicts between applications.
- A full VMWare testing environment with VMWare Workstation and ESXi, so you can create all the packaging and testing environments you need and, most importantly, leave them running so that users can log on remotely to test.
- Scripted or automated tests and test accounts for each application.
- Microsoft Application Compatibility Toolkit for testing and distributing fixes
- Thorough documentation and audit trail of the testing.
Delivery options
- Native installation for compatible and well behaved applications
- Citrix XenApp published applications, or perhaps virtual desktop, for incompatible applications
- Virtualization for conflicting applications (e.g. applications that require different versions of common components) or badly behaved applications (e.g. applications that change the default behaviour of the OS)
Most larger organisations already use several delivery options. What is new is to work out the interdependencies of different applications and which platforms they need to sit on. For example, if the incompatible app does a mail merge to Word or a report export to Excel, then the back end platform needs to have Office. It won’t be able to merge and export to the front end. This means that you also have to consider the user profile settings across different delivery platforms. If the user changes a default printer on the Windows 7 front end, should the same change be made to the back end or not?
With this approach, structured testing and multiple delivery options, you can set a time limit for preparing applications for Windows 7 migration. You can migrate the core desktop to Windows 7, while migrating older applications when they are ready.