Practical App

Best Practices for Migrating to IE 9 & Keeping Your Legacy Apps Alive

Migrating from Internet Explorer 6 to a modern browser can be faster, cheaper and easier than you think -- if you know the right tricks.

• By Chris Jackson
• 09/28/2011

Nobody is happy to still be on an old browser like Internet Explorer 6. People shake their heads and complain about the new features they don't have, the applications that no longer work, and about the insufficient performance. Yet, there they are, still running Internet Explorer 6. Why? It's simple: they're afraid that their stuff will break.

You don't want to be the one who brought down the enterprise for a day because of a broken mission-critical app. So, there you remain, paralyzed by fear and ambiguity. The process of migrating to Internet Explorer 9 may not be problem-free, but if you leverage a few tricks, you honestly can make it faster, cheaper and easier.

Overcome Ambiguity
Before you start your application-compatibility project, you may not feel as if you have the data you need to accurately measure the risks involved. After all, can you really list all the Web sites that everyone in your organization has ever visited? What are the true risks?

In the most recent release of the Microsoft Assessment and Planning (MAP) Toolkit, there is some Internet Explorer inventory capability. It inventories browsers installed on a computer (and which browser is set as the default), as well as which add-ons are installed for Internet Explorer (such as ActiveX controls or Browser Helper Objects). This can help you understand the code running within your users' browsers.

You may not get a comprehensive listing of all Web sites visited because of technical, legal and privacy reasons. Absent that, you could do things like querying proxy servers to determine which Web sites are accessed through them. However, even though you can make a big list of URLs if you try hard enough, it's almost never a good idea.

Think about it. How many times in a typical day do you visit Web sites that have no impact on your work? How many Web sites do you use where, if they went away tomorrow, you'd just go find other ones? If you took an inventory of the Web sites I personally visited and then exhaustively tested them all, at least 95 percent of that effort would end up being wasted time. It's the fear of not locating that 5 percent of sites that users would miss that drives people to want an exhaustive census of Web sites.

Identify the Apps
Here's another approach: Figure out which applications absolutely, positively have to work on day one. These are the applications you need to proactively test before you deploy a single seat of Internet Explorer 9. Once you've cleared the mission-critical apps, you can begin to deploy.

Start deploying a few seats. Have enough help desk support knowledgeable about Web application compatibility to manage additional incoming volume because of the new browser. Have a plan for addressing issues, and a backstop for emergencies.

The beauty of this plan is that you don't have to test everything. Typically, your users will only report a problem if it's a blocking issue for them. Otherwise, they'll just go about their business. You end up spending less time testing apps that users don't actually care about. You spend less time doing proactive testing. The users can determine if an application actually works or not.

So your proactive application-compatibility testing doesn't actually determine compatibility? It's an unusual concept. Consider what it means to be compatible. It means you have no bugs on a given platform that stop you from working. Now, we all know you can't get to the point where a product has zero bugs. You just need to prove that none of them stop you from getting work done. As long as your user community is productive, you're in good shape.

This combination of proactive and reactive testing -- an approach that combines sensible risk management, user empowerment and platform agility -- is pure app-compatibility gold. This approach can overcome inertia based on ambiguity, and saves you money and time.

Tune the Environment
Once the migration project is started, it's time to get your browser environment tuned up to ensure that more applications work right from the start. When talking about modern versions of Internet Explorer, which support the latest Web standards, many think they have to update all their applications as part of the migration. While that's certainly a noble goal, it's also slower and way more expensive.

Internet Explorer 9 provides a sophisticated and manageable compatibility infrastructure that lets you choose to keep things working as the default, and then opt in to the new Web standards on an application-by-application basis. So how do you tune for maximum compatibility? It all starts with proper zoning.

Some internal applications land in the Internet zone, either because they're using fully qualified domain names or because they're using IP addresses for some applications. The Internet zone is more restrictive, and as a result is much less compatible. For example, SharePoint isn't nearly as good when improperly zoned. All kinds of features just don't work.

The other zoning issue is putting internal applications into the Trusted Sites zone. Back in Internet Explorer 6, Trusted Sites was actually the most trusted zone. It genuinely gave you more power. In Internet Explorer 9, the most trusted zone is not Trusted Sites; it's Local Intranet. So, you're actually giving up power. Plus, by using the default policies you're also giving up integrated authentication.

Why is Local Intranet now more trusted? Previously, you had two different buckets for internal apps: trusted and really trusted. How often do you need to make such a distinction? Not that often, once there's a sensible default policy for the Local Intranet zone.

Once you have applications zoned correctly, you also land in the default policy where the Local Intranet zone enables Compatibility View by default. This makes your existing Web applications more compatible, just by virtue of landing in the zone with the more permissive security template.

Compatibility Modes
This, of course, brings us to our next important topic: compatibility modes and when to leverage them. This is an often-misunderstood aspect of Internet Explorer 9. A lot of that complexity is hidden behind a seemingly simple button with a picture of a broken page.

Keep in mind as you go through the process that Internet Explorer 9 actually contains four separate rendering engines. That's four sets of rules for HTML layout, scripts and so on. In Internet Explorer 9, those rendering modes are:

• Quirks/Internet Explorer 5.5
• Internet Explorer 7 Standards
• Internet Explorer 8 Standards
• Internet Explorer 9 Standards

This is not new. Even Internet Explorer 6 had two different modes: Quirks and Internet Explorer 6 Standards. You would get Quirks until the developer specifically opted into Standards using a DOCTYPE element in his markup. Internet Explorer 7 continued the dichotomy, evolving and improving Standards, while leaving Quirks in. Internet Explorer 8 kept both Quirks and Internet Explorer 7, and added Internet Explorer 8. Internet Explorer 9 is following that trend.

So, you have four rendering engines behind a single button. How do you go back and forth between them? Compatibility View will render a Web page that contains a DOCTYPE in Internet Explorer 7 Standards mode. It will render a page without one in Quirks mode.

If you're not using Compatibility View, then a Web page that contains a DOCTYPE will be rendered in Internet Explorer 9 Standards mode. A page without one will be rendered in Quirks mode. So, a Web page running in Quirks mode won't change if you push the Compatibility View button. This also changes the version of the browser reported to the Web server.

It's not a terribly user-friendly solution to instruct users to push a button to make a Web page work. There's now Group Policy support for Compatibility View, specifically to make it the default for the Local Intranet: Administrative Templates | Windows Components | Internet Explorer | Compatibility View | Turn on Internet Explorer Standards Mode for Local Intranet.

This is one of those double-negative policies. You have to disable "Standards Mode" for the Local Intranet in order to enable Compatibility View. The default is disabled, and you should keep it that way. That doesn't mean you want to keep writing to a 5-year-old standard. It means that stuff you've already written to an older standard will continue to work. You can, of course, opt in a particular Web application using a more modern standard, but you can't use the latest standards for anything until you get a modern browser deployed.

Naturally, there's also a Group Policy for keeping external partners' Web applications running: Administrative Templates | Windows Components | Internet Explorer | Compatibility View | Use Policy List of Internet Explorer 7 sites.

If you add specific sites to this policy (it uses top-level domain names, or TLDNs), they'll be opted into Compatibility View, and might work better. Compatibility View doesn't fix everything. Coming from Internet Explorer 6, there's a specific reason why it doesn't always work. Internet Explorer 6 doesn't read the DOCTYPE unless it happens to be the very first line of markup on your page.

So, what if you have a page that starts like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">

That's a common prolog to an XHTML page: an HTML dialect that was popular for a few years. Internet Explorer 6 is going to render any XHTML that starts like this in Quirks mode, because DOCTYPE isn't the first line. Internet Explorer 7 fixed that bug, so Internet Explorer 7 or later will render it in Standards mode. Because the rules for layout changed between Quirks and even Internet Explorer 6 Standards, this can be a pretty big deal.

For many, it's the promotion of Web sites from Quirks to Standards that causes them to break in droves. More than 80 percent of apps have been broken by this one change. It's precisely because of this situation and its alarming frequency that we added a new Group Policy for Internet Explorer 9 (also available for Internet Explorer 8 if you apply the hotfix, which can be found here): Administrative Templates | Windows Components | Internet Explorer | Compatibility View | Use Policy List of Quirks Mode sites.

This lets you opt in to Quirks for a given site that may be affected by Microsoft fixing this bug. This doesn't give you complete control, but it gives you a straightforward, policy-based way to get started.

To get complete control, you have to leverage X-UA-Compatible, where you can explicitly choose precisely which rendering mode you want. You can get the full details from the MSDN Library page, "Defining Document Compatibility", but in short, you must include either a header: X-UA-Compatible: IE=5 or, you include a meta tag, as shown in Figure 1.

<meta http-equiv="X-UA-Compatible" content="IE=5">
<!-- Quirks Mode -->

<meta http-equiv="X-UA-Compatible" content="IE=7">
<!-- IE7 Standards -->

<meta http-equiv="X-UA-Compatible" content="IE=8">
<!-- IE8 Standards -->

<meta http-equiv="X-UA-Compatible" content="IE=9"> 
<!-- IE9 Standards -->

<meta http-equiv=»X-UA-Compatible» content=»IE=edge»>
<!-- The latest standards - never use in production! -->

You're going to want to understand the compatibility infrastructure and all the ways you can have it configured. For example, if you leave the default configuration for Local Intranet, it's to use Compatibility View. Then, let's say you implement an HTML5 application. If you do nothing, it's going to default to Compatibility View -- the Internet Explorer 7 engine.

Internet Explorer 7 doesn't support HTML5, so your application won't work. All is not lost, though. You can add a header to the Web site and configure it to run in Internet Explorer 9 mode, or you can add meta tags to the pages that require HTML5. You just overruled the defaults, and got a more modern rendering mode.

It's advisable to add X-UA-Compatible headers or meta tags to any Web application you touch. You should also require it for new Web applications.

The rules of precedence also support this notion. You can overrule the Group Policy defaults with the X-UA-Compatible header, and overrule the header with an X-UA-Compatible meta tag. At whichever level of granularity you choose, you're in complete control of your rendering mode. You do have to step up and seize that control if you want to keep moving forward. So, make sure you're tagging your sites and setting standards for new applications.

Configure Security Settings
The next step in tuning your environment is considering whether security features are breaking your applications. Some settings that commonly cause issues include:

• Mixed content: Sites that mix and match SSL content with unencrypted content. Some organizations find that this causes excessive warnings and user disruptions with a large number of sites.
• Certificate warnings: Many organizations don't have a public key infrastructure (PKI) implementation, but prefer the safety of SSL. They just borrow keys from one server and use them on another.
• Data execution protection: This can be one of the most effective threat-mitigation technologies available. However, there are still some ActiveX controls that are incompatible with this powerful security feature.

This is by no means an exhaustive list. You can't really tune your environment for these factors up front. This will be an iterative process. If you find a feature that breaks an application, make note of it. It might make sense to disable it for now and build out a plan for fixing it later.

You must also be mindful of the tradeoff. If you remain with Internet Explorer 6, then you get zero percent of the security features added since then. Naturally, you'd rather have 100 percent of the new security features. If critical applications don't work with everything enabled, though, that's not a choice you get to make.

You get to choose either 99 percent of the security features in Internet Explorer 9 (with a feature or two turned off for now) or zero percent of the security features in Internet Explorer 9 by refusing to lower the security posture. That also blocks the deployment. You need to balance these considerations.

Mind Your Middleware
Another important aspect of migrating to Internet Explorer 9 is ensuring that you understand the impact of middleware. It's particularly important to have the latest version of Java installed. Older versions of Java are incompatible with Internet Explorer 9.

Many organizations choose to standardize on a particular version and update level for Java. This basically locks in place a particular patch level for Java and refuses all new security patches. The Microsoft Malware Protection Center has warned about the rising number of Java exploits, so this is an unwise approach.

Look for Root Causes
Once your environment is tuned and you're rolling out seats and starting to get feedback, you're bound to have a few escalations. Here comes the hard part: figuring out what to do about the Web applications that are breaking.

A Web application is generally composed of three different parts that run on the browser: HTML (typically generated by a tool), CSS (typically generated by a designer) and script (typically generated by a developer). No one person often thoroughly knows each of these technologies. It's hard to know even one of them thoroughly.

When troubleshooting Web application compatibility, follow an iterative approach. Come up with a reason why it might be broken and then find a tool that can help you determine whether or not you're right as quickly as possible. If you focus your thinking, you can drive your way to a root cause much more quickly.

Sometimes you'll need to rewrite. Most problems are easily fixable issues, such as version checks. For example, one application might be doing an explicit version check for the script engine, like so (represented in pseudo-code):

if (majorVersion < 5 or minorVersion < 5) then fail

Run this logic through your head. Version 5.5 works fine. So would 5.6, but 6.0 will fail, because 0 (the minor version) is not less than five? You can fix that by changing that one line of code. Often the fix is easier that you think, so make sure you drive to a conclusion on why something is breaking, rather than assuming everything needs to be redone.

Have a Backup Plan
Last but not least, you'll want to have a backup plan. When you have an application that requires support but you don't yet support Internet Explorer 9, you can't run it. Is the backup plan to keep all of those users on Internet Explorer 6, or will you leverage virtualization to move those users over earlier? Review the white paper, "Solutions for Virtualizing Internet Explorer", and build out a plan that gives you an escape hatch if things go wrong.

On average, the typical organization moving from Internet Explorer 6 to Internet Explorer 9 finds 25 percent of its applications don't work out of the box on Internet Explorer 9. After careful tuning, that number drops to an average of less than 5 percent.

Customers moving from Internet Explorer 7 to Internet Explorer 9 typically have 4 percent to 5 percent of their applications not working out of the box, with the number after tuning dropping to less than 2 percent. For companies already using Internet Explorer 8, nearly everything works out of the box.

Hopefully these tips, collected from half a decade of helping organizations move forward from Internet Explorer 6, will help you enjoy the benefits of a modern browser. Put together a risk-based project plan that incorporates user involvement, leverages the compatibility and manageability features of the existing browser, seeks the least-expensive code-based fixes possible, and has an escape hatch for when things go wrong.

Hundreds of companies have removed the shackles that bind them to legacy browsers. You can do the same.