crminthefield: RESOLVED: Unexplained Internet Explorer 302 Redirects to CRM 2011 Mobile Site

[Blog bot]

Источник: http://blogs.msdn.com/b/crminthefiel...bile-site.aspx
==============

I recently worked with a customer who had end-users encountering a strange behavior where all attempts to access the main CRM 2011 web site were being being redirected to the CRM mobile site (../m/default.aspx).  While this is normal behavior when accessing CRM via currently unsupported browsers (Firefox, Safari, Chrome, etc.), what made this strange was that the users experienced this behavior in Internet Explorer. The behavior was consistent for all affected users, however not all users were affected.  Also, launching an In-Private browsing session in IE (ctrl+shift+P) and navigating to CRM did not produce the behavior. 

We decided to run a fiddler trace for an affected user where the behavior was reproduced as well as for the same user in an In-Private browser session.  After capturing both scenarios we filtered down to the /default.aspx GET request and subsequent redirect/request.  The reproduced scenario showed a 302 redirect response to /m/default.aspx, the CRM mobile site, and the working scenario (In-Private session) showed the expected, subsequent GET request for /main.aspx. 

Having successfully reproduced the behavior and captured a working, control scenario we started to compare the two GET requests for /default.aspx.  What became immediately apparent was that the User-Agent header value differed between the two requests.  The control scenario showed a typical profile for Internet Explorer, but most intriguing was that the reproduced scenario specified a non-IE user agent in the header.  The particular element of the user agent that caught our attention was ‘Chrome/22.0.1229.94’.  Why did the request appear to be coming from a Chrome browser when using IE?

This discovery prompted a discussion about IE browser plug-ins and it turned out that the affected user had installed an IE plug-in from Google called Chrome Frame which is a supplementary install alongside a Chrome browser installation.  This plug-in provides a Chrome-based browsing experience, for purposes of HTML5 and Chrome-optimized site support, inside of Internet Explorer.  We disabled the Chrome Frame IE plug-in and the user was then able to navigate to the main CRM site successfully.  This cause also explains why the In-Private session did not exhibit the behavior since browser plug-ins are disabled in that mode. 

For this reason, we strongly recommend that such third-party add-ins/plug-ins be avoided both for Internet Explorer and for Outlook since they can introduce undesired and often unexpected behavior affecting CRM.  Such behavior can be difficult to troubleshoot.   In our case, we were lucky that the cause was fairly visible in a client-side trace.  As a general rule, disabling plug-ins is a good client-side triage/troubleshooting technique to minimize variability.

In regards to the Chrome Frame plug-in, its primary purpose of HTML5 support for Internet Explorer is unnecessary.  Opt instead for IE9 which begins to support the HTML5 spec and ultimately upgrade to IE10 with Windows 8 (or Windows 7 when available) for more extensive native support.

Below is the Fiddler trace output from both the reproduced and working scenarios:

Reproduced Behavior in Internet Explorer





User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; chromeframe/22.0.1229.94) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.94 Safari/537.4

Working Scenario in Internet Explorer (In-Private browsing session)





User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET CLR 1.1.4322; .NET4.0C; .NET4.0E; InfoPath.3; MS-RTC EA 2)

Austin Jones

Microsoft Premier Field Engineer





Источник: http://blogs.msdn.com/b/crminthefiel...bile-site.aspx