Mitigation Strategies and Solutions

Applies To: Windows 7

Now that organizations have completed inventory, prioritization, and rationalization of web applications, and also performed some application compatibility testing, it’s time to look at some migration strategies. Tools like IECTT may have indicated a list of known issues, the next step is to get started on actual remediation or mitigation techniques. This section will take you through some basic mitigation steps, as well as provide information on how to plan for future application compatibility while addressing key issues at hand.

Organizations can take a simple remediation approach that can be handled by IT pros to tackle minor non-code fixes, or opt for the more formal remediation approach that involves code changes to implement Internet Explorer 8 standards, which requires web developer involvement. There is also another option for IT pros: operating system or presentation virtualization, which is discussed in conjunction with the other remediation options.

Simple Remediation Approach

In some cases, design change causes compatibility issues that can quite often be fixed by simple remediation approach. There are several tools from Microsoft and third party vendors that help IT pros and developers in the remediation process.

For more information about design change, see Browser Changes from Internet Explorer 6 to Internet Explorer 8.

For a list of Microsoft tools, see Appendix 2: Tools for Debugging Web Applications and Add-ons.

Ensuring documents remain compatible with future browser releases is an important concern for web developers. Internet Explorer 8 provides the ability to control document compatibility modes, which enable developers to instruct the browser to render web pages in the same way as older versions of the browser. This feature also allows the developer to choose when to update the web page while it continues to be usable and function correctly.

Attempt a Fix Using Compatibility View

Compatibility View is a feature of Internet Explorer 8 that allows the browser to render the web page nearly identically to the way that Internet Explorer 7 would render it.

For specific details about Compatibility View, see the Internet Explorer Team Blog on the Microsoft Developer Network.

What is Compatibility View?

In Internet Explorer 8, Compatibility View changes the way the browser interprets code written in CSS, HTML, and the Document Object Model (DOM) to try to match that of Internet Explorer 7. This means viewing a site in Internet Explorer 8 Compatibility View will be almost identical to viewing a site in Internet Explorer 7. However, compatibility view does not change the way all code is interpreted by the browser. For example, the changes made to Internet Explorer 8 in relation to how the browser handles ActiveX, the parser, AJAX, JavaScript, networking, and security may still cause website or web application incompatibilities. These behaviors are largely unchanged by the Compatibility View feature.

For more information, see Differences between IE8 Compatibility View and IE7.

For further reading on the differences between Internet Explorer 8 Compatibility View and Internet Explorer 7, see the Site Compatibility and Internet Explorer 8 blog.

For a list of what we recommend for developers to check when upgrading to Internet Explorer 8, see the Internet Explorer 8 Readiness Toolkit.

In an enterprise environment, some areas have lower risk for compatibility issues. For example, Intranet Zone websites use Compatibility View by default. Client web applications that render using the Web Browser Control, or the WebOC, (Internet Explorer rendering engine) are also low risk for compatibility issues because Internet Explorer 8 defaults to a compatibility mode for the WebOC. However, the default configuration settings for Compatibility View may not be enough to ensure complete compatibility. The best way to know if a website or web application is compatible with Internet Explorer 8 is for the website or web application owner to test the web application.

Why do you need Compatibility View?

When Microsoft looked at compatibility issues in legacy web applications, it was clear that customers could benefit from the ability to have their browser ‘switch behavior’ to render as it had in previous versions. One of the challenges with delivering this feature to users is to make it as seamless and invisible as possible – it should just work. The Compatibility View feature follows a set of rules in attempt to display content correctly, without any user (or IT administrator) action needed whenever possible. The feature provides mechanisms for developers to instruct the browser which rendering engine to use, as well as the ability for users to override the browser’s choice and enable them to switch modes. When neither the developer nor the IT pro specifies which rendering mode to use, the user will see the ‘broken page’ icon at the right end of the Address Bar:

Clicking the icon instructs Internet Explorer 8 to switch rendering modes, and the user will see the page reload instantly. It is important to note that users will not always see this icon – its goal is to provide users with a fallback solution rather than serve as the primary application compatibility mechanism. Internet Explorer only displays this button when toggling into Compatibility View makes sense, such as when viewing Standards mode pages. In all other cases, such as when viewing Quirks mode pages or viewing intranet zone sites, the button is not displayed.

For more information about the goals of the Compatibility View feature and when the icon will display, see Introducing Compatibility View.

How do I Enable Compatibility View?

There are several ways to enable the Compatibility View feature, and this list is provided to help understand using it for a testing process only. If testing shows that Compatibility View resolves the issue, Microsoft recommends organizations use Group Policy (GP) to control the Compatibility View feature in an enterprise wide deployment. By default, Compatibility View is enabled for the Intranet Zone, helping to ensure that Line of Business applications work without needing additional modifications. Also, extranet applications, often managed by outsourcing partners are typically not seen as intranet sites and may need to be included in GP settings. Information about using GP with Compatibility View is included later in this document.

Additional Methods for Enabling Compatibility View:

  1. In the Tools menu, select Compatibility View.

    This places a checkmark next to the Compatibility View item on the menu list, indicating the browser is currently using Compatibility View.

  2. Compatibility View can also be enabled through the Developer Tools, which is launched by pressing the F12 key or selecting Developer Tools from the Tools menu. Using the Developer Tools for testing provides an additional benefit by offering the ability to manipulate the Browser Mode as well as the Document Mode. The Browser Mode setting modifies the UA String reported (changing it from MSIE 8.0 to MSIE 7.0) and adjusts the version vector which is used by CSS and JavaScript within the documents. The Document Mode setting modifies page rendering, allowing you to force the page to render in one of the three modes (Quirks Mode, Internet Explorer 7 Standards, or Internet Explorer 8 Standards) without modifying the UA String reported to the web application.

    For more information about the differences between Browser Mode and Document Mode, see Testing in Different Browser and Document Modes.

  3. Enable the EmulateIE7Meta tag. Unlike the previous methods to enable Compatibility View, this method is done using HTML code inserted directly into the page(s) themselves. This method requires making changes either to the server settings (using a HTTP header tag) or on a page level header (using the EmulateIE7 Meta tag). For more information about using the Meta tag, refer next section.

    For more information about using a HTTP header tag, see Implementing the META Switch on IIS.

    For more information about using the EmulateIE7 Meta tag, see META Tags and Locking in Future Compatibility and the information that follows in this section.

  4. Use the Compatibility View list. This option works if your site is either on the Compatibility View list maintained by Microsoft, or if you manually add a URL to the Compatibility View list. You can check if your web domain is already on the compatibility view list. The current version of the Compatibility View list maintained by Microsoft can be seen at any time by typing res://iecompat.dll/iecompatdata.xml into the Address bar.

    For more information, see the following resources:

In addition to this application compatibility guidance document, Microsoft has created the Internet Explorer Readiness Toolkit as a resource to aid in migration planning and issue mitigation. If your testing identifies areas needing mitigation or other issues to address before your organization is ready to deploy Internet Explorer, review the Windows Internet Explorer 8 Readiness Toolkit.

If Compatibility View Resolves the Issue

If you enable Compatibility View in Internet Explorer 8 and this successfully resolves the issues you were experiencing with the website or web application, the best course of action is to enable Compatibility View, and plan to update any code using the latest set of adopted web standards for the next release of your web application or website. While Microsoft is committed to supporting the Internet Explorer 8 product throughout its lifecycle, Microsoft recommends organizations not rely only on legacy rendering modes, but also opt in all new applications to standards mode using the Meta tag or header. To ensure forward compatibility in the future, web applications should be coded for currently adopted Web standards.

Web standards are constantly evolving and changing. As such, compatibility is an issue that will need to be addressed as your organization moves forward. Browsers are continually being improved to become more compliant, not less compliant, with the newest web standards; consequently, your web-based applications and websites should be updated to match the newest browser standards as well.

Use the Meta Tag or HTTP Header to Ensure Future Compatibility

By using the Meta tag’s content attribute, developers can specify the mode content is rendered in for the web page. To ensure the content is displayed using the Internet Explorer 8 standards rendering mode, specify the value of IE=EmulateIE8 or IE=8. To ensure the content is displayed by Internet Explorer 8 using the Internet Explorer 7 rendering behavior, specify the value of IE=EmulateIE7 or IE=7. To ensure the content is displayed using the Internet Explorer 5.5, or Quirks, rendering behavior, specify the value of IE=5.

For further information on compatibility and the X-UA-Compatible header, see Defining Document Compatibility.

The following code demonstrates how to force the web page to be rendered in Internet Explorer 8 mode.

Microsoft recognizes that web sites may contain thousands (or tens of thousands) of individual pages so setting this value on each document is impractical. If your site works by setting the meta tag for all pages or a collection of pages selected by folder, the recommendation is to adjust your server configuration and add the X-UA-Compatible metadata in the HTTP header.

For sites that require different Meta tag values for pages on the same server, there are several tools available today that automatically generate and insert the appropriate Meta tag for you. One such tool is the ArtinSoft Web Tools utility from Aggiorno that inserts and removes the Internet Explorer 8 compatibility tag feature, and is designed to help webmasters bring their site up to specific compatibility standards.

For more information about using a HTTP header tag, see Implementing the META Switch on IIS.

For more information about using the ArtinSoft Web Tools, see The Insert/Remove the Internet Explorer 8 Compatibility Tag feature.

The following table describes document compatibility in Internet Explorer 8:

Content Value Meaning


“Quirks” Mode


Always use Internet Explorer 7 mode


Display in Internet Explorer 7 mode unless site has “Quirks” DOCTYPE


Always use Internet Explorer 8 mode


Use this tag to override compatibility view on client computers and force Internet Explorer 8 mode


Display in latest mode; in the Internet Explorer 8 release, this is equivalent to IE=8

Managing Compatibility View with Group Policy

Internet Explorer 8 has over 1300 Group Policy entries that can be configured for keeping your environment managed and safe. Configuring these for the first time may seem like a daunting task. This section provides recommendations for the following important areas: security, performance, and compatibility with Internet Explorer 7 and Internet Explorer 6.

To enable Compatibility View for all sites using Group Policy, regardless of Zone determination, set the following policy object to Enabled:

Policy object Location

Turn on Internet Explorer 7 Standards Mode

Windows Components\Internet Explorer\Compatibility View

To enable Compatibility View for all Intranet Zone sites using Group Policy, set the following policy object to Disabled:

Policy object Location

Turn on Internet Explorer Standards Mode for Local Intranet

Windows Components\Internet Explorer\Compatibility View

To ensure your users are using the compatibility list maintained by Microsoft, set the following policy object to Enabled:

Policy object Location

Include updated Web site lists from Microsoft

Windows Components\Internet Explorer\Compatibility View

To specifically enable Compatibility View web sites using Group Policy, set the following policy object to Enabled, and add your list of sites:

Policy object Location

Use Policy List of Internet Explorer 7 sites

Windows Components\Internet Explorer\Compatibility View

Users will be able to add or remove sites manually to their local Compatibility View list, but they will not be able to remove the sites you specifically added.

By configuring the Site-to-Zone assignment list, you can control which security zone settings are applied to specified sites.

Policy object Location

Site to Zone Assignment List

Windows Components\Internet Explorer\Internet Control Panel\Security Page

By configuring security policy, you can restrict users from making configuration changes.

Policy object Location

Disable the Security Page

Windows Components\Internet Explorer\Internet Control Panel

Turn off Data Execution Prevention (DEP) configuration

Policy object Location

Turn off Data Execution Prevention

Windows Components\Internet Explorer\Security Features

SmartScreen® Filter configuration

Policy object Location

Use SmartScreen Filter

Windows Components\Internet Explorer\Internet Control Panel\Security Page

For a comprehensive list of all group policy settings included in the administrative template files delivered with Internet Explorer 8, see the Group Policy Settings Reference for Internet Explorer 8 spreadsheet.

For more information about Group Policy and Internet Explorer 8, see article 985351 in the Microsoft Knowledge Base.

Remediating ActiveX Installation for Standard Users

Installing ActiveX controls becomes a compatibility issue when your migration to Windows 7 includes a transition to standard users. This type of transition is a common best practice wherein IT Pros move their environment to a standard user account and is not a requirement for deploying Internet Explorer 8.

For more information, see Why use a standard user account instead of an administrator account?.

One common hurdle in the development of a secure desktop environment is how to mitigate the threats surrounding malicious ActiveX controls while still providing an appropriate level of application compatibility in your environment. An ActiveX control is a piece of executable code (typically an OCX file packaged within a Cabinet file) that is installed and invoked by the user through Internet Explorer. Web developers create ActiveX controls to add functionality to their web applications that they cannot easily achieve with standard HTML or a simple script.

A key feature of ActiveX controls is their simple "download and execute" deployment model. ActiveX controls are installed and invoked through the HTML object tag, which has an attribute called CODEBASE that tells Internet Explorer (using a URL) where to get the control if it is not already installed on the user’s computer. In that case, Internet Explorer downloads the associated installation package, performs trust verification on the object, and prompts the user for installation permission in the Internet Explorer Information Bar. During the installation, the control is registered and invoked by the rendering page. Once installed, the control can be invoked by any standard user. This simple mechanism of distribution and execution is meant to provide developers with an easy way to distribute their components to users of their web application. The problem with this distribution method is that standard account users cannot directly install per-computer ActiveX controls and administrator privileges may be required to complete the installation.

The ActiveX Installer Service (AXIS) enables IT professionals to manage the deployment of ActiveX controls by using Group Policy on computers in an organization. The options and sites used by the ActiveX Installer Service are configured by Group Policy settings, which can be modified by using either the Group Policy Management Console (GPMC) or the Local Group Policy editor. There are two policy settings for the ActiveX Installer Service: Approved Installation Sites for ActiveX Controls and ActiveX installation policy for sites in trusted zones. The Approved Installation Sites for ActiveX Controls policy setting consists of a list of approved installation sites, which the ActiveX Installer Service uses to determine whether an ActiveX control can be installed. The ActiveX installation policy for sites in Trusted zones policy setting identifies the methods by which Trusted sites zones can be used to install ActiveX controls. When a Web site attempts to install an ActiveX control, the ActiveX Installer Service will check to see if the URL of the Web site is listed in either the list of approved installation sites or as part of the trusted sites zone. If the site is on either of these, the ActiveX Installer Service will check to make sure that the site meets the requirements defined by the policy. If the site and the ActiveX control meet all of the requirements of the policy settings, the control is installed.

For more information, see Administering the ActiveX Installer Service.

Virtualization Approach

Application compatibility is one of the main reasons why organizations may be reluctant to upgrade to the latest version of the Windows operating system. Organizations may rely on an important line-of-business (LOB) application that must run in the Windows XP operating system, for example, or they may have a critical intranet site that was built to run in Internet Explorer 6. Additionally, they may not have the time or the resources they need to rebuild, refit, or upgrade these applications.

If an organization is considering an upgrade to Windows 7 and has a large number of web applications to be tested and migrated to Internet Explorer 8, IT pros can use virtualization technologies as a temporary fix for running Internet Explorer 6 web applications on Windows 7 right away, while simultaneously working on remediating the web applications to run natively on Internet Explorer 8. The three Microsoft supported virtualization options most appropriate for virtualizing web applications built for Internet Explorer 7 and Internet Explorer 6 are MED-V, Windows XP Mode, and Terminal Services.

For more information about virtualization options, see Solutions for Virtualizing Internet Explorer.

Microsoft has produced the following webcasts that introduce the supported Internet Explorer virtualization options:

Formal Remediation Approach

If enabling Compatibility View and other simple fixes do not resolve the compatibility issues you are experiencing with your web applications, you will need to update the source code. This ensures that the web application or website works natively in Internet Explorer 8 in at least one of the three rendering modes it provides (IE8 standards, IE7 standards, or Quirks). It is now the IT organization’s responsibility to work across other business unit IT’s (BUITs) to identify application owners and the respective development resources to tackle the compatibility issues of critical business application by putting together a formal remediation plan.

For additional information for IT pros and developers who are planning a formal remediation and migration plan to Internet Explorer 8, see Addressing Application Compatibility When Migrating to Internet Explorer 8 - Understanding Application Compatibility for Corporate Developers.


After reading through this document, you should be comfortable with the application compatibility process using some of the tools and techniques used by the Internet Explorer team. In addition, you should have the information needed to create a strategy to successfully plan your deployment.

Many customers migrate to Internet Explorer 8 to benefit from the enhanced security, manageability, and user experience the browser offers. Most web applications will continue to function correctly in Internet Explorer 8. For those that do not, we recommend reviewing the policies and configuration of the browser to ensure that you have tuned for maximum compatibility, and follow the processes described in this document.

Although this document could not cover the entire list of all compatibility issues that you may encounter within that process, the Internet Explorer MSDN® Compatibility Center contains a list of many known compatibility issues and workarounds. In addition to the information on that site, you should now have the knowledge and experience to identify compatibility problems, determine the root cause of the problem and resolve the issue.

For more information, see the Internet Explorer MSDN Compatibility Center.