Been working on my SharePoint Dev machine where I needed to add a calendar to my site. Wrote the code, everything looked good. I then VPN onto the client’s machine to upload the code to their QA environment. Soon as I looked at the calendar, I notice that it was displaying funny and not working as expected. After ensuring I had indeed uploaded the latest code, I decided to go back to basics and create an out of the box site and add a calendar to the site. Again the calendar didn’t look right.
Non Working Calendar
I jumped on the web front end, and used IE11 from there and the same site appeared correctly.
From my machine I checked with Chrome, Safari, Firefox and all appear correctly, but for some reason my IE didn’t work. It was the first time I’ve had a case of “It doesn’t work on my machine” but does everywhere else.
Non-working. (Loads non_ie.js)
Working (Loads ie55up.js and sp.ui.applicationpages.calendar.js files)
A colleague of mine suggested to use fiddler to look at the User Agent being sent in the request. (Thanks Chris) It turned out that two different User-Agent were being sent.
Non-working: (Mozilla/5.0 (Windows NT 6.3;WOW64;Trident/7.0;rv:11.0) like Gecko)
Working: (Mozilla/4.0 (compatible;MSIE 7.0;Windows NT 6.3;WOW64;Trident/7.0;.NET4.0E;.NET4.0C;.NET CLR 3.5.30729; .NET CLR 2.0.50727; .NET CLR 3.0.30729)
I was able to prove that it was the User Agent causing the issue, by using IE developer tools, and changing the User agent string there. Which then made my calendar display correctly. I also tested the original User Agent string, and if I removed the like Gecko from the User Agent string, the calendar did display correctly. It appears it’s the “Like Gecko” that causes the problem.
This gave me enough information to try and find something on the internet that could help me with my problem. I came across Jeremy Sinclair blog, which implies there is an issue with IE11 and SharePoint 2013.
Jeremy explains in his blog that the following doesn’t work correctly in IE11 with SharePoint 2013, even with SharePoint 2013 SP1 the issues are still there.
- Edit Page doesn’t place the page in Edit mode (especially on custom page layouts)
- If you do happen to use a built-in page layout, any webparts added are unable to be customized.
- The calendar view doesn’t look right
- The calendar overlay button on the calendar view is disabled.
Jeremy second blog post above show you how to use a URL Rewrite Module for IIS, and configure IIS to re-write the HTTP_USER_AGENT.
So how comes it worked on the client QA SharePoint box browser, and worked on my browser pointing to my dev environment, but not when I used my browser to point to the client QA SharePoint Site?
I have learnt that in IE Internet Options, on the Security Tab, when a site is a Local Intranet site, it uses the working User Agent. So when I was trying to connect to my farm that was already set up as a Local intranet. When I was on the remote desktop of the web front end, again I was inside the client domain and the site was already configured to Local Intranet. The connection of my browser on my pc through the VPN to the client’s farm sent the request via Internet. As soon as I put the URL of the client’s site in my Local Intranet settings, the calendar then appeared correctly to me.
Hopefully a patch will eventually be released, and this won’t be an issue. Until it is, I hope this blog helps explains the problem to you and gave you the answer quicker than it took me to work out.