Multiple Versions if IE Not Supported - What it means for Application Virtualization

Lack of Support for Running Multiple IEs Impact on Application Virtualization

Background
One of the benefits that Application Virtualization provides is enabling customers to migrate legacy applications across operating systems without impacting the end user or incurring significant costs in testing and rewriting the application to be compatible with the new version of the OS. This has become particularly important for those that believe XP Mode (lack of interaction between applications on the new OS) will not be sufficient enough to enable Win 7 Migrations (as many skipped moving to Vista).

Microsoft has stated they will not support multiple versions of Internet Explorer on the Same OS - particularly when used with application virtualization. - http://support.microsoft.com/kb/2020599/

What does that Mean for Application Virtualization?
The actual magnitude of impact really depends on the architecture that the solution uses. There are several different architectural approaches to application virtualization. Depending on the approach - this could be a significant risk for customers beyond the intentional virtualization of Internet Explorer.

There are essentially 4 types of architectures that exist currently in this market.

1) File redirection - The files are redirected to a different portion of the OS but are still technically installed on the machine.

2) Agent Based Virtualization (Agent installed in OS) - agent is installed in the Operating System and redirects calls to isolated applications. The agent needs to be sequenced etc to determine how much memory consumption and other system resources to allocate based on precedence.

3) Agentless Virtualization - The file system and code to run the application is embedded within the virtual application. The Virtual Operating System is contained within the Application to provide everything the application needs to run independant of a full OS (registry keys, specific components) and communicates with underlying OS.

4) Virtual Client/Agent Hybrid - The fourth architecture is based off of a virtual client that leverages some form of file system and manages all the components independently. It combines the approach of having the agent (without installing it in the OS) and the virtual OS.

How does this translate to impacting product support?
For most application virtualization solutions it literally means that only 1 copy (ideally the one that is shipped as part of the OS) is supported. We all know this is not realistic or possible particularly when newer versions of IE may break mission critical applications.

One would either have to uninstall the version of IE that comes with the OS and use only a single version of the virtual IE across platforms. There is still quite a bit of benefit in this approach. The biggest benefit is reducing costs across migrations from one OS to the other but also being able to support multiple OS with the same version of IE without having to do a significant amoutn of regression testing. It would be equivalent to what is done in most IT shops today for physically installed IE - say when IE 7 came out but many still used 6.

Now it does also lend the ability to run a side by side pilot of a beta version. Meaning that for a small group during the pilot phase - although there would not be broad based support chances are the benefits of having existing pilot users have access to the current version while the new version is being tested is more valuable and less risky then trying to not allow them access. However, the key thing here is nothing installed means nothing to back out and less corruption issues with the base OS.

Architectural Risk
Although the architectures that fall in the 3 & 4 category (Agentless and Hybrid) have the biggest benefit to customers in terms of portability and reduced risks from not having anything installed on the endpoint - there are some significant risks and considerations that come into play with this approach given Microsoft's support policy.

For products like ThinApp that have written their own virtual operating system - the risks are far less. The reason being is according to the written statement is 1 version of IE per operating system. Although I am not a lawyer - having done EULAs in Product Management for a little under 15 years - I do know there is some leaway in language. Microsoft specific support policy states only 1 version of IE per OS. Now given a product like ThinApp that has it's own virtual OS one could say that the virtual IE is running on it's own OS (VOS). The likelihood of having significant impact on the underlying OS would not be as great depending on how the package is created to interacted with the base OS. Remember - for critical applications it is in YOUR best interest as the customer to check with your OS vendor on what their policy is - I can not speak for either Microsoft or VMware on this one.

Then what is the big deal? Hidden Risks
Certain Application Virtualization solutions actually use IE as their virtual file system in lieu of writing their own. That means that with each application - one is running an instance of IE on the base OS. The support policy would extend beyond just intentionally virtualizing IE to migrate to a new OS but would apply to all applications that are being virtualized.

What should a customer do?
Ask the vendors you are considering about their architectural approach so you can make an informed decision as to whether or not this is an issue for your organization. ie)Is it a critical application that has key MS components or is manufactured by MS (like Outlook or Office) that you must have support for or is it a home grown solution based off of Java or some other component that does not require any support from Microsoft.

Either way it is better to understand the pros and cons of ALL the architectural approaches prior to deciding which application virtualization solution to use. Although a few are close - there is not one single solution that has actually achieved the Nirvana that many customers asked for in order to obtain the true Universal Client.

Leap with caution as the technology and market matures to understand what should and shouldn't be done versus can/can't. Remember just because you can do something - doen't mean you should. I have seen some questions on applicability of Application Virtualization - I am a firm believer that it is required to unchain applications from the OS and achieve the True Universal Client. But like all technologies just needs time.

Stay Tuned - next week regarding Implementation Considerations and Hurdles when deploying Application Virtualization within the Enterprise.

Regards,
Jeanne

Questions? Need tips or advice on your App Virtualization or VDI deployment with your current architecture - contact me at: jmorain@yahoo.com