SharePoint 2010 Anonymous Sites Issues

There are a few…well, let’s just call them “challenges” with anonymous sites in SharePoint 2010. Here’s the list of issues I’ve discovered so far that exist when with default settings in place:

  1. Anonymous sites can’t be accessed from mobile devices.
  2. The content query web part doesn’t work.
  3. Grouped views in sharepoint lists / libraries don’t work.
  4. Word docs cannot be opened without a login prompt (other formats work fine (pdf and excel for example))
  5. Document Sets are not functional
  6.  Consuming ATOM feeds provided by an SSRS report from PowerPivot (more here)

I don’t yet have solutions to all of these, but I will write up a few posts for each of the above, starting with mobile devices.

Mobile Devices

SharePoint automatically detects that a user is connected with a mobile browser, and redirects them to a mobile view of the page. However, by default anonymous users don’t have access to this page. However, if you have a publishing site, then most likely you will find that the default mobile view is poor and not worth enabling for anonymous access anyway. In this situation, the likely goal is to not redirect the users to the mobile page. (If you’re trying to prevent the user from being redirected, see the next section below)

By the way, you can test the mobile experience by adding ?mobile=1 to a page in a normal browser.

More details:

When a mobile user connects to the site, they are automatically redirected to /_layouts/mblwp.aspx. This mobile page requires a user to have the ViewFormPages permission. And, an anonymous user does not have this permission by default. More specifically, permissions for anonymous users are driven by the “limited access” permission level. To see what this permissions this permission level has, go to:


Pay special attention to the “view application pages” permission for the “limited access” role:

On a non-publishing site, that value is checked, and on a publishing site it is not. SharePoint turns this permission off on publishing sites using a feature called “viewformpageslockdown”. To repeat, if viewformpageslockdown is enabled, anonymous users won’t have access to application pages, since anonymous users get their permissions from the limited access permission level. So, one solution to this problem is relatively simple:

  1. Disable the viewformpageslockdown feature
  2. Disable anonymous access
  3. Enable anonymous access

The last two steps are required to re-set the permissions for anonymous users. If you skip it, it won’t work.

The down-side to this of course, is that anonymous users now have access to all application pages. This means anonymous users would be able to browse to:


More info on all of this:

Prevent mobile users from being redirected

The other solution for mobile pages is to not redirect them at all. In reality, this is the better answer for anonymous sites as the mobile experience is really designed for collaboration sites, not publishing sites. There are a couple strategies out there to disable the redirect. One is to modify the compat.browse file and specify that each device listed is not actually a mobile device. More info on this is here:

Another strategy is to modify the browserCaps section of web.config:

<result type=”System.Web.Mobile.MobileCapabilities, System.Web.Mobile, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a”/>

The above is from:


4 thoughts on “SharePoint 2010 Anonymous Sites Issues

  1. Laurent Schoenaers


    I tried all solutions, but I’m still getting redirect to the mobile page.

    I’m really pulling my hair out on this one.

    Any ideas what might cause this? I’m running SharePoint Server Enterprise.

    Kind regards,
    Laurent Schoenaers

      1. Laurent Schoenaers

        Indeed, I also tried adding the browsecaps in the web.config, still no change.

        I even disabled the MobileRedirect feature, with no luck.

      2. Laurent Schoenaers

        Okay… The mysteries from SharePoint are back again.

        I was so sick of it that I copied the compat.browse file into all of our web applications (except for the central admin) and suddenly it works like a charm.

        I imagine that the compat.browse under port 80 should also have isMobileDevice set to false if you want it under different ports as well. I’m not sure, just a wild guess.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s