Hotfix for IE browser issues in SharePoint 2010

Question

I have an intranet site in share point 2010.It's working fine in fire fox and chrome.But when I performs the update operation on a list items or setting Alerts on a directory,it's gave me errors.

Though I can temporary resolved it by setting the browser mode to "IE=8.0" or via in my master page through "meta tag specifying IE=8". But I want to know is there any hot-fix available for SharePoint 2010 to resolve these IE issues?

Answer 1

SharePoint 2010 only works properly in IE9, IE10, and IE11 when the compatibility meta tag is set to IE8. It does not support IE9/10/11 in their native rendering modes.

There is no actual work around for this, it is a known issue with SharePoint 2010. The SharePoint 2010 controls only work in IE8 mode.

Answer 2

I ran into this issue today - specifically ActiveX not being recognized as available so Datasheet view didn't work on a list. (Edit 2014-07-10: This works to fix SharePoint 2013 pre-SP1 as well e. g. not being able to work with web parts in edit mode.)

There are two fixes to this on the client side, but they are both very big hammers:

1. You can add the site to the Compatibility List in IE ([gear] -> Compatibility View Settings -> Enter URL, Add). This is a big hammer because it actually applies to the entire DNS domain, which if SharePoint is one of many things in the DNS domain, is really bad. So this was no good for me.

2. You can add the site to the Intranet zone and have the Display Intranet Sites in Compability View checkbox turned on (also in Compatibility View Settings). This impacts all sites in the zone, which will hurt sites in that zone that are not broken on IE11. So this was also no good for me.

I tried the different ASP.NET updates to update ASP.NET browser detection but that was all up to date, so that didn't help.

However, as a hunch, I decided that somewhere SharePoint was doing "User Agent Sniffing" - the timeframe of the code was right for that, and a very, very large number of IE11 compatibility issues come down to user agent sniffing. The user agent was changed on purpose for IE11 (ref: http://blogs.msdn.com/b/ieinternals/archive/2013/09/21/internet-explorer-11-user-agent-string-ua-string-sniffing-compatibility-with-gecko-webkit.aspx).

Since I can't work out where it's happening, and the whole web site on the server is dedicated to SharePoint 2010, I decided I would use a medium-sized hack-shaped hammer to fix this. The hack is to change the user agent being reported to SharePoint to make IE 11+ look like IE 8.0.

Steps you should follow to reproduce:

1. Install the URL Rewrite 2.0 module on the server if it's not already installed. (Current URL: http://www.iis.net/downloads/microsoft/url-rewrite but it's very easy to find).

2. Open the IIS Manager (the current one, not the IIS 6.0 legacy one).

3. Select the web site under Connections.

4. In the Features View IIS section, open URL Rewrite.

5. Under Actions Manage Server Variables select View Server Variables....

6. Under Actions select Add....

7. When prompted with Add Server Variable, enter HTTP_USER_AGENT as the Server variable name: and press OK.

8. Under Actions select Back to Rules.

9. You are now back at the main URL Rewrite context. Under Actions select Add Rule(s)....

10. When prompted for Add Rule(s) select Blank rule under Inbound rules and press OK.

11. Create the rule as follows:

    • Name : whatever makes sense to you

    • Match URL

      • Requested URL: Matches the Pattern

      • Using: Regular Expressions

      • Pattern: .*\.aspx

      • Ignore case checked

    • Conditions

      • Logical grouping: Match All

      • Add... a condition

        • Condition input: {HTTP_USER_AGENT}

        • Check if input string: Matches the Pattern

        • Pattern: .*Trident.* like Gecko

        • Ignore case unchecked

        • 

      • Server Variables

        • Add... a server variable

        • Server variable name: HTTP_USER_AGENT (if not in the dropdown you added it wrong above)

        • Value: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; Media Center PC 6.0; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C) (this is an arbitrary Internet Explorer 8.0 on Windows 7 with a bunch of stuff installed value - I don't care in my case exactly what it says since as far as I know nothing running on the SharePoint site is trying to make decisions based on say the .NET versions installed on the client - but your mileage may vary)

        • Replace the existing value checked

        • 

      • Action

        • Action type: None

      • Under Actions select Apply then Back to Rules. (If Apply is unavailable you have an invalid rule - check your work.)

That's it, done. This worked for me - the datasheet view immediately worked correctly without my browser set for compatibility mode for the page beyond the automatic "act like IE 8" that seemed to happen without me doing anything.

You could conceivably also a rewrite rule to add the IE=8 rendering meta tag into all ASPX responses as well - I haven't done that myself so I'm not documenting details here but it shouldn't be too hard to figure out from what I have here.

(edit 2014-07-10: added small missing step)

Answer 3

MikeBaz has the right answer, mine is based on that and slightly tweaked.

1. Make sure URL Rewrite module is installed in IIS
2. Add HTTP_USER_AGENT to server variables, as per MikeBaz's answer

3. Copy and paste below into the web.config of website, just before </system.webServer>

   <rewrite>
       <rules>
           <rule name="IE gte 11 HTTP_USER_AGENT hack">
               <match url=".*" ignoreCase="false" />
               <conditions>
                   <add input="{HTTP_USER_AGENT}" pattern=".*Trident.* like Gecko" ignoreCase="false" />
               </conditions>
               <serverVariables>
                   <set name="HTTP_USER_AGENT" value="Mozilla/4.0 (compatible; MSIE 8.0; Trident/4.0)" />
               </serverVariables>
               <action type="None" />
           </rule>
       </rules>
   </rewrite>
   

The differences being:

• Matches more than just .aspx e.g. .ashx and .axd (also not sure if MikeBaz's answer works with URLs with query strings)
• Ignore case unchecked on URL, possibly slightly faster
• Simpler, possibly safer, user agent string omitting OS (not sure if valid but works so far)

Enjoy!

Answer 4

Turn on Internet Explorer Enterprise Mode, it overrides the meta tag: https://technet.microsoft.com/en-us/library/dn640699.aspx