Mystery Access Denied Troubleshooting in SharePoint


In a MOSS 2007 installation we have a site with a wiki library. The wiki library has been customized a bit with event handlers to do some fancy automatic permission assignments to individual wiki pages and prevent some users from approving wiki pages that they are not allowed to. This was done so that every user is able to add, read, edit wiki pages but let individual identified users handle the approval of the pages in a large wiki library. These details are probably inconsequential.

The real problem is there is a single user who can can read, add, and edit wiki pages. He is also assigned to approve some wiki pages. However, when he attempts to view the history of a wiki page for approval he gets an access denied error. The history page for a wiki page in a wiki library is an application page (in _layouts directory) with the following path: http://<path to sharepoint site>/_layouts/VersionDiff.aspx?ListID=<my wiki library id>&ID=<id for the wiki page>&Source=<return path>

The user also experiences this error when clicking the link to view incoming links. The path for this page is: http://<path to sharepoint site>/_layouts/BackLinks.aspx?ListID=<my wiki library id>&ID=<id for the wiki page>

This user has the following permissions being applied:

  • Site Permissions – Limited Access
  • List Permissions – Limited Access
  • Item Permissions – Design

This user is also part of a domain group which has the following permissions being applied:

  • Site Permissions – Limited Access
  • List Permissions – Contribute
  • Item Permissions – Contribute


I started a thread in the TechNet SharePoint forum in hopes of finding someone who has run into this problem before. Thanks to the folks in the forums, there were a few suggestions on how to resolve the problem. Unfortunately, I didn’t have the opportunity to try most of these. But here are the suggestions:

  • Delete the user from the SharePoint site and re-add the user and re-apply permissions.
  • Recreate the AD account
  • Assign a higher level privillege to a parent object (This is the band aid that I applied which resolved the problem)

List of SharePoint 2007 Web Templates

I came across this reference in the past and I needed it again today. Took me a few minutes to find it, so I decided to save a copy of the table here on my blog:

Template Name Description
GLOBAL#0  Global template (1033)
STS#0  Team Site (1033)
STS#1  Blank Site (1033)
STS#2  Document Workspace (1033)
MPS#0  Basic Meeting Workspace (1033)
MPS#1  Blank Meeting Workspace (1033)
MPS#2  Decision Meeting Workspace (1033)
MPS#3  Social Meeting Workspace (1033)
MPS#4  Multipage Meeting Workspace (1033)
CENTRALADMIN#0  Central Admin Site (1033)
WIKI#0  Wiki Site (1033)
BLOG#0  Blog (1033)
BDR#0  Document Center (1033)
OFFILE#0  Records Center (1033)
OFFILE#1  Records Center (1033)
OSRV#0  Shared Services Administration Site (1033)
SPS#0  SharePoint Portal Server Site (1033)
SPSPERS#0  SharePoint Portal Server Personal Space (1033)
SPSMSITE#0  Personalization Site (1033)
SPSTOC#0  Contents area Template (1033)
SPSTOPIC#0  Topic area template (1033)
SPSNEWS#0  News Site (1033)
CMSPUBLISHING#0  Publishing Site (1033)
BLANKINTERNET#0  Publishing Site (1033)
BLANKINTERNET#1  Press Releases Site (1033)
BLANKINTERNET#2  Publishing Site with Workflow (1033)
SPSNHOME#0  News Site (1033)
SPSSITES#0  Site Directory (1033)
SPSCOMMU#0  Community area template (1033)
SPSREPORTCENTER#0  Report Center (1033)
SPSPORTAL#0  Collaboration Portal (1033)
SRCHCEN#0  Search Center with Tabs (1033)
PROFILES#0  Profiles (1033)
BLANKINTERNETCONTAINER#0  Publishing Portal (1033)
SPSMSITEHOST#0  My Site Host (1033)
SRCHCENTERLITE#0  Search Center (1033)
SRCHCENTERLITE#1  Search Center (1033)
SPSBWEB#0  SharePoint Portal Server BucketWeb Template (1033)

How To: Remove or hide the “Site Actions” menu

I came across the request for this from a client I was working with. The client pointed me to some research he found on web (one link from MSDN and another from another blog). After some reading and further research, I found a great post that walks you through doing this.

Essentially, the solution is to wrap the SiteActions control with a SPSecurityTrimmedControl in the master page. The only trick to this is identifying the appropriate permission string to use for the control so you do not remove the menu from users who will actually need to use it. The string can easly be composed after reviewing the set of users (or a group of users) who will need access and checking the rights associated permission levels granted those users (or group).

jQuery and jCarousel in SharePoint

I recently had to integrate jCarousel into a SharePoint web part. Since jCarousel is a plugin for jQuery, it means I also had to get jQuery integrated with SharePoint. In order to accomplish this, I followed some good feature packaging instructions found from a few different blog posts:

After figuring out how to package jCarousel and jQuery using SharePoint delegate controls, I was ready for business with the implementation of the web part.

The web part itself was nothing fancy. I used a Repeater control to generate the list item (LI) elements with the content I needed in the carousel. I wrapped the Repeater in an unordered list (UL) which was wrapped in a DIV tag that had the runat attribute set to server. So basically, I just followed the mark up instructions provided in the jCarousel documentation.

The wrapping DIV tag was used in my webpart code to initialize jCarousel. The code snippet below shows how I implemented it:

protected override void OnLoad(EventArgs e)
  if (!Page.ClientScript.IsStartupScriptRegistered(this.GetType(), this.ClientID))
    Page.ClientScript.RegisterStartupScript(this.GetType(), this.ClientID, @"
      <script type=""text/javascript"">
        jQuery(document).ready(function() {
          jQuery('#" + carouselDiv.ClientID + @"').jcarousel({
            // Configuration goes here
            vertical: true,
            scroll: 2,
            visible: 4

Come and Get It! SP2 for MOSS 2007 and WSS 3.0 Is Here

Service Pack 2 for Microsoft Office SharePoint Server 2007 and Windows SharePoint Services 3.0 have been officially annouced and are available for download from the Microsoft Download Center. I ran across the annoucement on the Microsoft SharePoint Team Blog where you can find links to the knowledgebase articles, downloads, and other resources including installation instructions. Below are quick links for the downloads:

SP2 for WSS 3.0:

SP2 for MOSS 2007:

SharePoint Test Driven Development

[Via Joel Oleson]

I love finding a good and useful blog post and this morning I did just that. The post from Joel Oleson regading SharePoint test driven development is great. It has a quick exerpt from his twitter conversation with other SharePoint pros regarding this topic, a summary of what he learned, and list of useful resources with descriptions. If you follow or practice test driven development (TDD) and are involved with SharePoint development, then this post will be a good resource for you too.

Microsoft Office SharePoint Designer 2007 or Not

SharePoint Designer (SPD) is a nifty tool to use to customize SharePoint sites. It is very powerful and allows us to quickly make style, organizational, functional, and content changes quickly and easily. Today, I ran across a post from Joel Oleseon where he shared his professional opinion in response to another post about the tool from Mark Rackley which was motivated in response to Microsoft’s announcement to make the tool available for free. There really is nothing new about the debate as it deals with the advantages and disadvantages of empowering an end user with all of the power the tool has to offer. It has just resurfaced since the tool will be freely available.

So… if the debate is not new, what’s all the fuss about?

Regardless of the stance that you take about allowing SPD to be used in a production SharePoint deployment or not, the real cause of concern is how SPD can impact production environment when used by untrained/uninformed users with appropriate rights. This reminds me of the quote – with great power comes great responsibility… or something like that. I don’t see the need for huge concern. That is assuming people with those rights have already been trained and informed. For the most part, people with contributor or higher permission role assignments can already do plenty of damage to a production environment with only the web browser at hand. Hence, the need and argument for appropriate training, content approval (and publishing) planning and enforcement, and governance plans (especially in Extranet/Internet facing deployments).

Okay… so what should we do?

There shouldn’t be too much to do (assuming training, content approval, governance, etc. has already been addressed). Professionally, I will be making sure to emphasize the role of SPD in SharePoint projects. I will also make sure to encourage the inclusion or addition of SPD training for existing and new SharePoint users (especially “power” users), administrators, and developers.