A while back I decided to disable all of SharePoint’s mobile support. Mobile devices today are good enough today that they can handle the full pages, and the mobile views make changes that I’m not a huge fan of. So off it went.
I talked to my favorite branding expert, Randy Drisgill, to see what the best way to handle this was. He pointed me to this SPTechWeb article he wrote on the subject. It covered all the things you need to tweak. Specifically it covers some changes you need to make to each web application’s compat.browser file to disable mobile support at the IIS level. The compat.browser file lists all the types of browsers IIS knows about and what that browser can or can’t do. One of the settings is “IsMobileDevice.” If that’s set to “true,” IIS knows the browser is on a mobile device and it acts accordingly, including telling SharePoint. This is how SharePoint knows whether to send the full page to the browser, or send the sad, neutered page. To keep that from happening you can set all the “IsMobileDevice” settings to “false” so that IIS thinks every browser is a grownup browser. It works like a champ.
I was happy how it worked. I told everyone about it. I talked about it in my SharePoint Netcast. I told customers about it. I was very proud.
Until a customer decided to check my facts.
I was telling a customer about this, as he was asking me about iOS device support for SharePoint 2010. I gave him the whole song and dance about how you didn’t need the mobile view anymore, and how I felt so strongly about it that I disabled the whole shebang on my web site. “Go ahead,” I said, “Check out my blog on your iPad see how well it renders.”
It rendered the mobile view. Imagine my shame.
There was an uncomfortable silence. I explained to my customer that I must have been mistaken on which site I’d done it on. I knew that I’d done it on my blog, but I didn’t have any explanation for why it had changed. I was talking to Randy about it later. He said the same thing had happened to him. Coincidentally also in front of a customer. It’s a wonder we have any business at all. We chatted about it a bit and he thought maybe a patch or service pack might be overwriting it. I decided to find out for sure.
I had a VM that was sitting at the RTM, so I went into the compat.browser file and set all the “IsMobileDevice” settings to “False.” I also made a backup copy of the file, so I’d have something to compare it to. I hit the web app once to make sure everything before I put the Service Pack on. Everything was not okay. The page wouldn’t load, so I changed the “CustomErrors” setting in the web.config to “Off” and reloaded the page. It was complaining that there were multiple definitions for a browser. This was confusing to me, as I hadn’t added anything. I shot the error over to Randy, and he said he’d seen problems when he’d made backups of the file. Sure enough, if I rename the extension of the backups to anything but “.browser” everything worked fine. It looks like IIS looks in the App_Browsers directory and looks at the settings in all the “.browser” files it finds. I had the usual compat.browser, but I also had a “compat – false.browser” file. Once I renamed it to “compat.browser.false” everything was fine. Tip from Todd: make backups of those files, and change the extensions when you do.
After everything was working I put Service Pack 1 on. Installing the Service Pack itself did not change the compat.browser file. However, when I ran the Configuration Wizard, my custom crafted compat.browser file was overwritten, and all the “IsMobileDevice” values were set back to “true.” I was vindicated. I had put Service Pack 1 on my production server since I had changed that file.
You always hear to make backups of any files you edit because a service pack might overwrite them. This is an example of one that does get overwritten.