Internet Explorer 7: Common Deployment Issues “Tips and Tricks”
Draft 1.1
April 22, 2008
For the latest information, please see http://www.microsoft.com/ie
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property. ? 2008 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows XP, Windows Vista, Internet Explorer, IE7, the Windows logo, and the Internet Explorer logo are trademarks of the Microsoft group of companies. All other trademarks are property of their respective owners.
The purpose of this document is to provide IT Professionals and Administrators with a quick solutions guide for commonly experienced problems when deploying Internet Explorer 7. This is not an exhaustive review of any and all potential issues. This document will focus on several of the most commonly observed technical issues and provide guidance for workarounds or problem resolutions.
Contents
I can’t seem to get pages to come up or certain things aren’t working quite right .................................... 5 I’m seeing messages and prompts about installing ActiveX controls ........................................................ 8 I’m having design and layout issues with Internet Explorer 7 ................................................................. 13 I’m getting new certificate warnings and other security messages that I’ve never seen before .............. 16 I’m having issue with our application trying to write to the local file system in Vista .............................. 18 I’m not even sure where to start figuring out what works and what doesn’t .......................................... 19 I’m having installation/deployment issues ............................................................................................. 21
User-Agent String Detection Errors
Many Web designers use browser-detection techniques to customize the experience for specific browser versions. It is important to ensure that the techniques chosen take into account future browser releases. Several typical browser detection techniques fail when they encounter Windows Internet Explorer 7. For example, some sites that look great when viewed in Internet Explorer 6 might display errors when viewed in Internet Explorer 7. This is not caused by any problems with Internet Explorer 7; it happens because the browser detection code (either on purpose or by accident) is not designed for newer versions of the browser.
In addition to the solutions addressed here, Microsoft recommends using feature detection, where the website logic detects if a browser is capable of supporting a specific feature. By using feature detection, website owners can ensure the experience they want their users to have, regardless of browser version and client upgrades. In the enterprise environment this can be especially helpful as well, where the need to support legacy applications makes it critical to ensure application compatibility. Feature detection logic could help enterprise applications age gracefully while they remain current in a parallel application development cycle.
Question:
I am trying to reach my website, but instead of loading the normal page I keep getting a message telling
me to upgrade my browser version. I am using IE 7, so why do I see this error?
Answer: This is generally an issue with application logic on the server or code within a webpage that does not recognize the new ‘MSIE 7.0’ version number used in Internet Explorer 7. Prior to the release
of IE 7 most web development practices accounted for versions up to, and including, 6.0. The logical operators they used did not account for future versions, and an unexpected result higher than 6 is causing the application to show an error.
Solution: Depending on where the application logic is being performed (in the server or within a webpage), that code would need to be modified to recognize the ‘MSIE 7.0’ string and accept it as a valid version number. Regardless of where the fix resides, it’s a trivial bit of code to update and won’t cause regression problems. If the application logic is contained within a webpage, it can be seen by right clicking in the browser window and selecting ‘View Source’. If you do not see some kind of JavaScript
browser version checking code in the page, the logic is most likely contained in a server side application. One common example of web page based browser checking logic is:
if ( ver = 6.0 )
msg = "You're using a recent copy of Internet Explorer."
else
msg = "You should upgrade your copy of Internet Explorer.";
The problem with this version checking logic is that it specifically matches a version number, rather than looking for a minimum value. While this code is not incorrect, it causes unnecessary issues (and unintended errors) with newer browser versions. Simply changing the code to:
if ( ver >= 6.0 )
msg = "You're using a recent copy of Internet Explorer."
else
msg = "You should upgrade your copy of Internet Explorer.";
fixes the issue and accommodates for any value greater than 6.0. By adding the > operator, the code will now be able to handle any future version values for IE.
Identifying application logic issues for server side applications requires looking for similarly written conditional statements. Given the vast number of possible server side application platforms and languages it is impractical to provide every server side example in this document. Microsoft has
published a best practices document for effectively detecting Internet Explorer (covering both webpage and server side application logic), which is located at http://msdn2.microsoft.com/en-
us/library/ms537509.aspx.
Question:
My webpage loads and the content renders, but some of the functionality (e.g. menus, buttons,
rollovers, etc.) is not working. Is there something wrong with using IE7?
Answer: This issue is generally tied to browser identification logic errors within a webpage where the
JavaScript code is not designed to properly handle the version of Internet Explorer you are using. There
is nothing wrong with using IE7, nor is anything specifically wrong with the web application.
Solution: Since the webpage renders in the browser window, it appears the browser detection logic is
likely happening in some JavaScript within the HTML content. In order to view the HTML source for the webpage (including the JavaScript programming code) simply right click in the browser window and
select ‘View Source’. In looking at the source code you should focus on content contained within <script></script> tags, especially looking for JavaScript variables that reference the navigator object.
For example, you might see JavaScript code like:
this.ver=navigator.appVersion;
this.agent=navigator.userAgent;
These lines are working with elements of the Document Object Model (DOM) that allow web developers to read information about the user and take actions based on the results. If you do not see any
navigator object references in the webpage source code, you will need to find where the source code is being referenced. Some web developers prefer to use externally sourced JavaScript files rather than
include all their code in one HTML page. For those situations you may need to load the URL indicated
and open that .js file in a text editor. To find those files you would need to search for HTML tags that look like:
<script language="JavaScript1.2" src="inc/mycode.js">
Once you have found the JavaScript code relating to the browser logic activity, you need to look for instances where the code references versions of Internet Explorer. Specifically, you need to find any
items where the web developer may have limited the conditional operator to exclude new versions (or at least those beyond Internet Explorer 6). For example, you may see code which looks like this:
this.ie5=(this.ver.indexOf("MSIE 5")>-1 && this.dom)?1:0;
this.ie6=(this.ver.indexOf("MSIE 6")>-1 && this.dom)?1:0;
this.ie4=(document.all && !this.dom)?1:0;
this.ie=this.ie4||this.ie5||this.ie6
You can see that this JavaScript code has conditions to deal with versions up to 6, but in the case of IE 7
the code will simply exit without returning a result. Often this type of exit condition will cause a webpage to render properly – there is nothing wrong with the HTML or JavaScript code – but the
functionality will be broken and you will not be able to use the application. The fix for this situation is to
modify the JavaScript to include conditions which properly handle the IE 7 (and IE 8) version string. By
modifying the code to look like:
this.ie5=(this.ver.indexOf("MSIE 5")>-1 && this.dom)?1:0;
this.ie6=(this.ver.indexOf("MSIE 6")>-1 && this.dom)?1:0;
this.ie7=(this.ver.indexOf("MSIE 7")>-1 && this.dom)?1:0;
this.ie7=(this.ver.indexOf("MSIE 8")>-1 && this.dom)?1:0;
this.ie4=(document.all && !this.dom)?1:0;
this.ie=this.ie4||this.ie5||this.ie6||this.ie7||this.ie8
You should immediately see the proper functionality with IE 7 that you experienced with IE 6.
Question:
I have too many applications to test in my organization, is there a quick way I can test the User-Agent
string issue without digging through any code?
Answer: Yes, Microsoft recognized the need to have a simple solution for broad based web application testing.
Solution: Microsoft offers the User-Agent String Utility for system administrators, web developers, application owners and any other users to quickly and easily modify their browser settings to send the
Internet Explorer 6 User-Agent string values. This tool, available at
http://www.microsoft.com/downloads/details.aspx?familyid=9517db9c-3c0d-47fe-bd04-
fad82a9aac9f&displaylang=en, enables you to launch an instance of Internet Explorer 7 that will send
the modified User-Agent string (it will send the IE 6 UA String). You do not need to modify the system
registry or make any other system modifications to use this tool. It is meant as a diagnostic tool to help
you in evaluating deployment preparedness, and therefore does not permanently change any system values. If you find the testing is successful when using this tool, but your web applications fail to work properly when sending the Internet Explorer 7 User-Agent string, Microsoft recommends that you
modify any applications to properly accommodate for the Internet Explorer 7 User-Agent string value.
In the case of Commercial Off The Shelf (COTS), Enterprise Resource Planning, or Customer Relationship Management (CRM) software applications you should contact those vendors for availability of any upgrades or patches to their applications.
Microsoft does not recommend using this tool as an enterprise deployment solution, it is meant for
testing and diagnostic purposes only. See the registry based solution for a suitable enterprise
deployment and distribution solution.
Question:
I’ve checked out my applications and they work if I set the User-Agent string to version 6, but I need to
deploy this to my entire organization (and the software vendor/developer does not offer a patch or
upgrade to their application). How do I change it on every machine? And will it break anything else?
Answer: Making changes to the web application code is the recommended solution, but there can be
logistical reasons that make it difficult or impossible. Sometimes the source code is not available (in the
case of server side applications) or exists in too many places (in the case of embedded code in HTML pages) to be a viable solution in your environment. There are also many older (legacy) applications used
in an organization and some applications vendors have chosen to only support the newest versions of their web based applications, and upgrades are either impractical or impossible. To facilitate migrations
to Internet Explorer 7, you can modify system settings in the registry to force Internet Explorer 7 to send
the Internet Explorer 6 User-Agent string. Fortunately, making this change will only skew the web
statistic usage reports gathered by website administrators – it will not break any functionality of
Internet Explorer 7, nor will it reduce any of the feature and security enhancements available to Internet Explorer 7 users.
Solution: The registry key is located at:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent]
Under that key you will need to make the following entry:
"Version"="MSIE 6.0"
These changes can be made using Active Directory configuration changes or you can use login scripts to run a registry file file update for installations that do not have AD infrastructures. The registry file needs
to contain both of the lines above and have a .reg extension for it to properly import to the system registry. This registry file is supported on both Windows XP and Windows Vista. Administrator rights are required to install registry files, or they can be deployed via login scripting.
Microsoft recommends using this registry fix as a temporary solution while working to make your web applications compatible with a standard installation of Internet Explorer 7. When your web applications
and software vendors provide compatible versions of their software, you can safely remove this registry modification and not lose any functionality.
ActiveX Controls
Internet Explorer 7 introduced a new feature designed to help prevent users from being potentially and unknowingly exposed to malicious attacks. Internet Explorer has long offered web developers the ability to build custom components and extensibility solutions using the ActiveX platform. As with any extensibility model, the more you allow people to do and the more you expose the users system, the more potential for abuse. To counter that potential issue, IE7 introduced the ActiveX opt-in
feature, which disables all previously unused controls by default. This helps in both case of upgrades and new installs, since ActiveX opt-in protects the user against controls that are installed along with non-web enabled applications. Prior to IE 7, those controls would be exposed to the Internet by default. Now the user is protected, and must give their approval before the control can be invoked. Any ActiveX control installed on the system must be on the approved list before it can be instantiated in the browser. A control which has never been used before (or previously called but not approved) will trigger IE7 to display the information bar to prompt the user to approve the control.
Question:
I am testing with Internet Explorer 7 and I keep getting prompted by the information bar to run an ActiveX control, why am I getting this warning?
Answer: One of the security improvements made in Internet Explorer 7 is the addition of a feature called ‘ActiveX Opt-In’. The purpose of this feature was to restrict the use of ActiveX controls within Internet Explorer to those specifically intended by the user (or administrator). Unlike previous versions
of Internet Explorer, users will now be prompted to run an ActiveX control if they have never used it before. Once approved, the user will never be prompted again for that specific control.
Solution: To best address this issue and provide for system stability and security in your enterprise, Microsoft recommends you create an internal list of approved ActiveX controls (both public and private
in the case of internally created ActiveX controls). Centrally managing this list of approved controls will
help ensure users are not blocked from certain actions and need helpdesk support to install/approve ActiveX controls for locked down systems. The Group Policy setting is found at:
Computer Configuration -> Administrative Templates -> Windows Components -> Internet Explorer -> Security
Features -> Add-on Management -> Add-on List
Enter all approved ActiveX controls (listed by CLSID) in this object container. You need to enter two items, Name and Value. The Name is the CLSID and the Value needs to be one of:
0 – Deny this add-on
1 – Enable this add-on
2 – Permit user to use Manage Add-ons
To quickly and easily find your complete list of CLSIDs, once you have added all approved controls to a machine, open the Manage Add-ons dialog and add the ‘Class ID’ column.
Once this list is complete, you can use Group Policy to create and propagate the approved list to systems in your AD domain. If you want to lock down this list of controls to only those you have approved for
your organization, ‘enable’ the Group Policy Setting at:
Computer Configuration -> Administrative Templates -> Windows Components -> Internet Explorer -> Security
Features -> Add-on Management -> Deny all add-ons unless specifically allowed in the Add-on list
To provide additional control over the user experience, and remove the information bar notifications entirely, you can ‘disable’ the Group Policy Object found at:
Computer Configuration -> Administrative Templates -> Windows Components -> Internet Explorer -> Security
Features -> Information Bar -> Internet Explorer Processes
Question:
Internet Explorer 7 is blocking users from running critical ActiveX controls so they can’t use our web applications. How can I unblock those controls?