Mark Gilbert's Blog

Science and technology, served light and fluffy.

We do not follow Sitemaps to buried treasure (Part 2 of 2)

Last week I described how we’re using sitemap files to provide custom navigational menus on our highly branded SharePoint site, and a couple of the pitfalls we encountered.  Now it’s time to discuss the meteor-impact that we fell into.

When we first extended the SP web app, and tried to test the site, the home page blue up with the ever-so-helpful “an unknown error has occurred” SharePoint error.  What made this even more useless was that the server application event log didn’t have any more detail, nor did the SharePoint server log.

With the help of one of our SharePoint infrastructure gurus, Ben, we managed to narrow the problem down through a lot of trial and error.

We changed master pages from our highly branded one to default.master, and the error went away.  We had created our master page from the MSDN-published minimal master page spec, so we were pretty confident that we weren’t missing anything critical (such as one of the required content placeholders).  Additionally, the exact same master page was being used by our internal version of the site.  Still, something about our master page wasn’t playing well with the extended SharePoint web app.

We originally thought that there was something wrong with Forms authentication (we’ve hit other problems and limitations with this on other projects).  However, a bit more testing showed that even if we left the site running with Windows authentication the error appeared.  We later found that if we did NOT enable anonymous access, the error did not appear.  It seems that hitting the site anonymously caused the error to manifest itself.

Next, we tried enabling anonymous access, and hitting the Site Settings page first.  It prompted us to log in, as we expected it would.  Then, using the same browser, we navigated back to the main page of the site.  The result?  No error.

So, the problem clearly seemed to be with enabling anonymous access, but we were still no nearer to figuring out what about the master page was really having problems with anonymous users.

I decided to create a new master page that was a copy of default.master, and piece by piece I copied over the structure from our custom master page.  When I got to the asp:Menu controls and the associated sitemap data sources, my new master page blew up.  I went back to my original master page, removed the menus entirely, and the page worked, even anonymously.  Further tinkering showed that if I left the menu and the data source controls on the page, but simply didn’t set the DataSourceID property of the asp:Menu control, the page worked.  I didn’t have any menus, but I also didn’t have any errors.

Ah, if only I could have stopped there.  Line 94 generating errors?  Well, simply comment it out!  It won’t through any more errors, will it?  Problem solved!

Alas, I had to press on.  I tried pointing my menus to one of the built-in datasource providers, and this worked.  So, the problem was definitely with my sitemap files.

On a hunch, Ben suggested checking the file security for the .sitemap files in the web root.  We did, and found that there wasn’t anything SharePoint-related in the list.  We tried giving “Everyone” full access, and tried the menu again.  This worked!  Now that we demonstrated that it was file-security related, we just needed to figure out which user and what level of security was needed.

Our process for installing SharePoint involves creating a handful of special system accounts on the network for the various SP services and jobs to run under.  We tried all of those, and none of them worked.  On another hunch we tried adding the IUSR account for the server.  Perhaps IIS itself was having problems getting to these files – maybe it wasn’t even a SharePoint thing.  That worked.  Granting the IUSR account “Read” and “Read & Execute” rights on the .sitemap files was enough to make them accessible to IIS and SharePoint, and avoids the “unknown” error.


We haven’t gone back to try setting up Forms authentication again (we’re going to stick with Windows authentication for the content authors for the time being), but now that we’re pretty convinced that the issue was with Anonymous access, and not Forms authentication, it would probably work just fine.

What struck me as odd after all of this was that we have custom resource files in the App_GlobalResources folder, and we’ve never needed to manually tweak the access rights on these files to get them to work.  Even the web.config didn’t have these extra permissions.  I could understand it if everything that SharePoint creates in the virtual folder had this permission, but things that I drop in manually don’t.

Why do the base site files (like web.config) work without this permission?  Why do our custom resource files work without this permission?  Why doesn’t the virtual directory itself specify this permission, so that things below it can inherit that permission, and then work?  I’d love to hear if you have answers to these questions.

May 4, 2007 Posted by | MOSS | 2 Comments