Streamlining Your Application Analysis and Testing Project

What’s our next project? Test our applications to get readyfor Windows 7? No problem, boss. We just have about 950 that we need to lookat…

How thoroughly you’ve conducted the application compatibilityportion of the migration project will determine if your OS roll-out isreasonably smooth, or if you’re about to throw your IT team into a firestorm ofhelp-desk calls, finger-pointing and numerous late nights.

When companies began evaluating Windows Vista a few yearsback, application compatibility was the issue that stopped some dead in theirtracks. In many of these cases, criticalapplications an organization relied upon for key business functions simply werenot available for Windows Vista. Inother cases, organizations did not have the budget, nor desire, to license thenew version that was designed for Windows Vista. Finally, in some instances, key applicationswere custom or in-house development efforts where the original developers wereeither no longer around or otherwise not available to re-engineer the codebase.

If you are looking to migrate to Windows 7, you’ll find thesituation isn’t as challenging as it was a few years back—most applicationsdesigned to work with Windows Vista will work fine with Windows 7, and mostISVs have updated their applications to work with this new generation ofWindows operating system. So whetheryou’re migrating from Windows XP or Windows Vista, the situation isn’t quite astough as it was in the past.

That said, getting your application portfolio ready for anOS migration can be a major undertaking, but taking the right sequence of stepsand making some tough choices to reduce the scope of testing can make the chorea little less daunting.

Why do applications break in Windows Vista and Windows 7?

So what changes were made in Windows 7 (and Windows Vista)that caused applications designed for Windows XP to ‘break?’ To be sure, the engineering teams responsiblefor Windows Vista and Windows 7 didn’t take the issue lightly. 

The changes to Windows were made to improve security,reliability, performance, and usability, and in some cases to remove legacycomponents that have simply reached the end of their useful life. We won’t take the time to catalog all of thechanges in this article, but those most significant to applicationcompatibility include:

User Account Control (UAC)/Standard User accounts. In the development of Windows Vista, theengineering team set out to enable most organizations to deploy their users asstandard users, and reserve administrator privileges for those who need them—ITprofessionals. Adopting the principle ofwhat we used to call ‘least-privileged user account’ for client PCs helpsprevent intrusive malware, reduces end user configuration errors, and preventsunauthorized applications from being loaded on the machine. In the past, an application had the abilityto write to the registry settings, modify the kernel, and other similarlyinvasive actions. Unfortunately thislevel of freedom came with a price—namely security. Windows now restricts the parameters of theOS an application is able to change—limiting the impact any malware canhave—but applications that were written with this behavior will need to bemodified or shimmed to function in Windows 7.

Applications performing hard version checks for the WindowsXP operating system version are also affected. While it makes some sense for adeveloper to lock support and functionality for the application with the versionof the operating system the developer originally used in testing, it alsoassumes that users will never attempt to install that application on a newerOS, or install a newer Service Pack to the same OS. While this is a relativelyeasy issue to mitigate with compatibility modes or fixes, you will see thissurface frequently when coming from Windows XP to Windows 7.

The five steps to managing application readiness for Windows 7

Like most big undertakings, the challenge isn’tinsurmountable if you take the time to deconstruct the problem into logical,manageable tasks. 

An application readiness project falls into three majorsections: Collecting, Analyzing and Mitigating. However, there are a couple of additional steps we would like to callout: consider virtualizationtechnologies before you commence the testing regimen, to help reduce thetesting process and potentially help improve your desktop infrastructure tomake future migrations more manageable; and sequence the testing phase to alignto your roll-out strategy.

If you’re ready to dive in, let’s get started.

Step 1: Collect an application inventory

The first step is to take an application inventory tounderstand exactly where you stand—and believe us; at this point you’veprobably just realized the problem is bigger than you thought. But more importantly, you’ve just turned an‘unknown’ into a ‘known’ and are in a better position to scope the testing andreadiness program and understand the challenges ahead. 

Fortunately there are a number of tools available that canhelp automate the process. Your clientmanagement software might have this capability built-in, or you can also usethe ApplicationCompatibility Toolkit, available for free download. If you already haveanother inventory mechanism like System Center Configuration Manager, AssetInventory Service or other, you can use that as a starting point. 

To make the inventory most useful downstream, capture morethan just a list of applications—you’ll want to understand more detail on whois using an application, what their role is, and how important that applicationis to the user. With this information,you can prioritize those mission-critical applications and eliminate unused orredundant applications (more on that in the next step).

Also, there’s a side benefit—identifying widely-usedapplications that you don’t currently manage. You’ll want to get these into your orbit so you can ensure they areproperly managed, on the approved version and have the required softwareupdates.

Step 2: Analyze yourapplications

How many applications do you currently support that havebeen replaced or have otherwise fallen out of favor with business users? If you’re like most organizations, a sizablenumber of them—in some cases most of them.  So once you done your assessment and have a good ‘lay of the land,’ thenext step is to scrub your supported application list and filter them down,before you undertake the time consuming—and costly— process of regressiontesting.

Set appropriate goals for your application portfolio. How many total apps do you want tosupport? At what point does an appelevate to “managed” status? 

After you set your goals, it’s now time to find the lowhanging fruit and narrow down the applications that need testing.

• Eliminate redundant and unusedapplications.You’ll undoubtedly findthat you have several applications that perform the same function. Now is agood time to standardize on a single application per function, and eliminatethose that have been made obsolete. One tip here is to try and map applicationdependencies, as you may need to support a legacy version of one application tokeep another one supported by the ISV.And of course drop those that are rarely or never used.Not only will you make testing easier, youmight save on licensing expense as well.
• Remove multiple versions of the same applicationand standardize on the most current.Inalmost all cases, the newest version performs best and is the most secure andreliable. Again, watch for application-to-application dependencies.

Collect information from business users to help prioritizethose apps that are mission critical, and determine which departments are usingwhich apps. This will be useful when yousequence your testing process; you’ll want to align the timing of your testingto your staged roll-out of the new desktop image.

Step 3: Assess incompatibilities and mitigationoptions

No doubt you will find some applications that need some workto get them ready for Windows 7. At thispoint you have several options:

1. You can replace the non-compatible applicationwith a new version.Certainly the mostreliable method, but unfortunately, the most expensive as well.If the application is mission-critical orotherwise strategic to operations, this is the way you’ll want to go.
2. Create shims for your existingapplications.Shims are small pieces ofcode inserted between the application and Windows to modify calls to theunderlying OS—for instance, to trick your application into thinking the user isrunning as an administrator, while still maintaining standard user mode.You will have some management overhead, sinceyou’ll need to maintain a shim database, but this approach will remedy manyapplication problems.This is the morecost effective route, and might be the only option if the application vendor isno longer around.One caveat—manyvendors will not support shimmed applications.
3. You can use Group Policy to change the offendingbehavior of the application.Likeshimming, this will usually take care of the compatibility problem but carriessome downsides as well.Essentially thisapproach uses policy to disable a particular feature or function that iscausing the application to falter.Unfortunately, in many cases these functions involve the security of theunderlying system, so the trade-off is significant.Likewise, the application must have GroupPolicy settings to enable this manageability.

For custom or in-house developed applications, you can ofcourse modify the code. This isn’talways an option, but if it is, there are great resources to help—the ApplicationCompatibility Cookbook for changes made from Windows XP to Windows Vista,and the ApplicationQuality Cookbook for changes made from Windows Vista to Windows 7. Both arefree guides that help developers recode an application for nativecompatibility.

Step 4: Prepare forthe OS deployment and new application delivery options

The start of an OS migration project is a great time torethink how you package and deliver applications to your end users. Virtualization technologies have opened upoptions that simply weren’t available for the last major OS migration; youshould consider different models for desktop image and application deliverybefore beginning the testing process. Youmight find that the savings in application testing and readiness more thanoffsets the cost of implementing a virtualized environment—while providing amore flexible and easier-to-manage environment for future efforts.

There are two major forms of virtualization that can addressapplication compatibility issues—application virtualization and OSvirtualization. Applicationvirtualization separates the application layer from the OS, including theapplications files and registry settings, and packages the application forstreaming. OS virtualization come in afew different forms, but essentially creates an OS image independent of thenative image on the machine.

Virtualizing your application portfolio provides a number ofbenefits for manageability and flexibility, but one key advantage is that youminimize application-to-application conflicts. This type of conflict arises, for instance, when you need to run twoversions of the same application simultaneously—common in training situationswhere you want to compare the process of conducting a specific task in an oldversus new application, or when the finance department is migrating to a newerversion of their accounting software but needs access to the old one to closethe fiscal year.

A more general use of virtualization to overcome applicationcompatibility is to create a virtual image that contains a critical applicationand the operating system it is designed to run on. There are several tools to enable OS virtualization,from Virtual PC and Windows XP Mode in Windows 7 Professional and higher SKUs(an unmanaged virtual image that will run applications intended for Windows XPbut not compatible with Windows 7) to Microsoft Enterprise DesktopVirtualization (MED-V), in the Microsoft Desktop Optimization Pack (MDOP),which enables a virtual machine to be easily provisioned, configured andmanaged using policies to determine how the physical and virtual environmentsinteract with one another.

Of course, adopting an alternative computing model for yourclient PCs is an undertaking in its own right, but this would be the time toassess whether the benefits to your organization—greater flexibility andmanageability—outweigh the additional effort to adopt this model for PCprovisioning.

Step 5: Sequence yourtesting, piloting and deployment efforts

Use your prioritization from step 2 to sequence your testingefforts, so you can begin the staged roll-out with and conduct subsequenttesting in parallel.

As you begin the testing process, you can use two approaches—staticand dynamic analysis; while static analysis is relatively new, a thoroughtesting regimen will use both. 

• Static analysis looks at the structure of theapplication and identifies issues that will undoubtedly arise, either ininstallation or runtime.There are anumber of tools and services that can help automate this process, and willquickly highlight the obvious problems.
• Dynamic analysis looks at the behavior of theapplication at runtime, and is what is traditionally done in regression testing.Here, you are “smoke testing” the applicationin your specific environment—replicating the experience a variety of users willhave with their hardware and the other key applications and drivers.
• Finally, you will want to get a handful of realusers running the applications and looking for any strange behavior that hasn’tsurfaced in the structured testing.Thepromise of keeping the new PC for participation can be a great motivator here!

Once you are ready to start rolling out into production, identifythe people for whom a migration makes sense first—based on specificcapabilities they need, or to minimize business disruption. Migrating a group of expert users will beeasier than dealing with the help desk calls from task workers who now are lookingat an unfamiliar screen and don’t know what to do with it. Next, identify whichapplications these groups will need to perform their work. Start with groupsthat are minimally or unaffected by application compatibility based on theapplications they use, this will enable you to validate the deployment processand the operating system. As you work through your application portfolio andmore groups become unblocked from incompatible applications, then target thosegroups.

One final word of caution—avoid taking the process toofar. If you let the scope creep fromapplication compatibility to a full-blown application quality project, youmight never finish. Accept the goal offixing bugs that prevent work from being done, and avoid trying to eliminate everybug that exists—you undoubtedly have better use for your time!

More resources

Readying your application portfolio for a migration toWindows 7 is a major undertaking, but fortunately there are a number of toolsand an abundance of guidance to make the process more streamlined andmanageable. We have just scratched thesurface in this article; if you’re ready to dive deeper and get the processrolling, a great next step is to visit the ApplicationCompatibility zone on the SpringboardSeries on TechNet, download the Application Compatibility Toolkit, andstart building your project plan!

You can also find helpful information and guidance on Chris Jackson’s Blog, and in theWindows 7 Application Compatibility white paper, which covers UnderstandingApplication Compatibility and UnderstandingApplication Compatibility in Your Environment. You can learn more on the virtualizationtechnologies mentioned above at www.microsoft.com/mdopand on theMDOP TechNet page.

To learn more about Windows 7 or any of the Windows Clienttechnologies, please visit www.microsoft.com/springboardfor the latest in information, guidance, and community connections.