Situation:
Working with a public anonymous site hosted on SharePoint 2010 there was an issue with the mobile view on certain devices. Anybody who has worked with SharePoint knows that by default it will do browser detection for mobile browsers and render a mobile version of the site OOTB. Although this can be helpful with some browsers, most mobile touch screen devices make the need for a specific mobile version unneeded.
The specific issues we were facing are listed below:
Issues:
- The files required for the mobile view are located in a directory which was not accessible anonymously causing a 401.
- Files that were in the Style Library were not accessible for certain browsers, but worked just fine on other browsers.
- Changing the compat.browser file located in inetpubwwwrootwssVirtualDirectories{WebAppFolder}App_Browsers allowed all browsers to see the full site, but the changes caused problems for Safari and Chrome on the desktop as well on mobile devices.
Solution:
For issue #1, we did not want to display the mobile version of the site so the solution was to make sure browser detection stopped rendering the alternative version. This lead to first testing the site by appending ?mobile=0 (http://www.site.com/Pages/default.aspx?mobile=0) to the end of the URL so that SharePoint would skip the browser detection. This revealed issue #2.
Although the mobile view was no longer rendered, the styling on the page was severely off. Users of Windows Phone 7 and desktop browsers were rendering the site just fine, but Android and iPhone devices rendered without proper styling. By looking at IIS logs, I noticed that Android and iPhone devices were getting 401’s when trying to connect to the Style Library. This is where a number of key .js and .css files were stored so it made sense that the site did not render properly. This next part is purely conjecture on my part, but I believe the discrepancy between devices came down to NTLM support. Although the site had anonymous access turned on, the Style Library on a Publishing site does not inherit permissions therefore when anonymous access gets turned on it does receive the anonymous permissions unless directly specified. This can go unnoticed for browsers/OS’s that support NTLM as the Style Library has the group Style Resource Readers on it which contains NT AUTHORITYauthenticated users. My assumption is that browsers that support NTLM use the special user NT AUTHORITYiusr to connect and it is considered authenticated and therefore the site rendered properly for most OS’s and browsers. IIS logs seem to support this as NT AUTHORITYiusr shows up when accessing the Style Library. The solution here was simply to add anonymous access to the Style Library. With this done, appending ?mobile=0 now rendered the site as expected. This left the final issue.
The next step was to turn off browser detection so that no devices were being sent to the mobile experience. From reading various sources, the compat.browser file needed to be edited to set isMobileDevice to false. I wrote a PowerShell script to quickly replace all instances. Find and replace probably would have worked as well, but I like trying new things in PowerShell. With my modified compat.browser file ready, I took and replaced it in our test environment and everything worked as expected. I then moved it to our Production environment and this is where issues started. In Production, the menu system was not being rendered properly on Chrome and Safari. Thinking the issue was related to my change, I reverted to the original file thinking this would fix the problem. It did not. A number of other solutions such as file permissions, editing other compat files, and adding .browser files were attempted but they were unsuccessful at resolving the problem. It wasn’t until we were able to successfully break another system that we stumbled on the answer. Deleting the compat.browser file and then browsing to the site successfully replicated the issue on a dev server. Restoring the file would no longer fix the issue. Server reboots also failed. The final solution turned out to relate to the second file in the App_Browsers directory which is the compat.moss.browser file. When this file was deleted from the directory and the site was visited, the problem went away. The compat.moss.browser file could then be restored without ill effect. My recommendation DON”T DELETE compat.browser when editing. It seems like the “stickiness” of this issue would be considered a bug as one would assume restoring an original file would fix the issue, but it did not. Hope this saves someone else the same headache.
Beavel's blog 
Recent Comments