In Windows Vista Client Build and Deployment Process, I presented the diagram that I use when scoping deployment projects, so in this post I'll continue discussing the process in more detail - previous posts have covered Infrastructure Prerequisites and Client requirements. In part 3 of this series, I will consider Application Compatibility.
Before starting down the application compatibility testing and remediation route, it is worth considering where the application compatibility issues will arise. From experience this usually falls into two distinct areas that Windows Vista introduces - security enhancements and operating system changes and innovations.
The following new security enhancement features in Windows Vista may cause compatibility issues with applications:
The following operating system changes and innovations in Windows Vista may cause compatibility issues with applications:
The Windows Vista Developer Story: Application Compatibility Cookbook on MSDN provides additional information about the security enhancements and operating system changes and innovations in Windows Vista. The cookbook also provides test approaches and possible remedies for many of the compatibility issues that may be encountered.
Now that we have considered the main areas where application compatibility issues arise, we can consider how the application compatibility testing and remediation will fit into our project process.
Applications Compatibility Testing
The ability to create standardised MSI packages, the introduction of packaging procedures, and a central application database, are the building blocks for many of the new features that can be enabled as part of a Windows Vista deployment project. They also serve other initiatives such as active patching and asset management. In most cases companies will adopt an industry standard, centralised packaging system at the very least.
If this is the case, I recommend using the Microsoft Application Compatibility Toolkit (ACT) 5.0 to aid in the application migration onto the Windows Vista platform. ACT provides a platform to carry out discovery and remediation work and tends to be used by application owners and developers. ACT makes it easier to introduction testing and remediation within a current packaging process.
With ACT in use, the remediation effort should be folded in as part of a packaging workflow. The way that this tends to work is that on entering the packaging workflow, applications are evaluated against known issues using ACT. This will give an early view of applications that will need further investigation, or those that have standard fixes already documented. Additional information on ACT 5.0 can be found in Microsoft TechNet
Changes to an operating system, whether it be a minor change such as a service pack update or as major change such as a migration to a new version requires a significant amount of planning in terms of application remediation. The level of application remediation for these changes is often underestimated due to a lack of pertinent or accurate information. I often advise clients to analyse the entire application portfolio to determining the effort required to ensure the applications will operate correctly when run on Windows Vista.
Application remediation can then fall into a number of areas, from simple shims that enable the application to run without change on Windows Vista to complete re-design and re-writing of an application by in-house developers of the software vendor responsible for the application.
There are also additional Microsoft technologies that can be used to address application compatibility issues that might take some time to fully resolve. These technologies are designed to help migrate to Windows Vista, and continue to run business critical applications that are not compatible with Windows Vista. These technologies include the following:
Applications Delivery and Installation
An application delivery and installation mechanism that I tend to favour uses a tiered application delivery process. I tend to recommend four tier levels that can be used to categorise applications.
The first tier (Tier 1) are applications that are included as part of the core image.
I then consider the other applications to be non-core lines of business applications falling into the other three tiers (tier 2, 3 or 4) which will not be included as part of the core build image. These Line of business applications are catagorised into the remaining three tiers as follows:
Tier 4 usually contains legacy line of business applications that cannot be delivered to users via the browser and will not run under Windows Vista. These will need to be managed as exceptions. The management of exceptions should be ongoing and non-compliant software must be considered for redesign, terminal server use, SoftGrid delivery, Virtual PC/Server delivery or retirement.
The diagram below shows the conceptual design for application delivery based on the four tier idea.
2007 Office System
Although rolling out 2007 Office System as part of a Windows Vista deployment project is common in the customers I work with, there are some things to consider. Although not directly tied to application compatibility, there is a link because many companies use Office as the core of their productivity tool set and because of changed in 2007 Office System, there will be compatibility and remediation work to carry out. Some of this compatibility and remediation work will be technical issues (file formats and extensibility of 2007 Office System) while others are based around user education.
For 2007 Office System inclusion in a Windows Vista deployment project, you should consider:
The following are freely available tools that are useful in application compatibility testing processes.
Windows Vista Hardware Assessment
Microsoft Office Migration Planning Manager
The Windows Vista Developer Story: Application Compatibility Cookbook
BDD Application Compatibility Feature Team Guide