First of all, let me say I'm a bit of a newbie when it comes to Sharepoint but I inherited an intranet portal which was recently restored after HDD trouble. The system was reinstalled but, after reinstallation, wiki pages do not work.

I've tried logging using IIS Failed Requests as well as Sharepoint's internal logging and monitoring using procmon. Procmon doesn't show any ACCESS DENIED messages and IIS Failed Requests just points to ASP.NET returning 403 FORBIDDEN (substatus 0 - SUCCESS).

The system's SPS 2010, SP2 applied, running under Windows 2008 R2 and ASP.NET 3.5. What I've noticed is that the forms in the wiki library work (such as AllPages.aspx), only the pages themselves are troublesome. I edited a copy of one article using Sharepoint Designer, removing parts of the page until the error disappeared. Apparently, if I change the Inherits="Microsoft.SharePoint.WebPartPages.WikiEditPage" to Inherits="Microsoft.SharePoint.WebPartPages.WebPartPage" the article appears (although in a different layout) - contact intact, permissions OK.

So, basically, I'm wondering if anyone has an idea as to why using that class would cause the 403 message. I forgot to mention I tried setting the trust level to WSS_Minimum and Full since I've noticed some permissions in the C# declarations for the class (although these dlls are already registered in GAC from what I can tell). I also tried setting permissions for the "bin" directory as some posts show - although I don't use any non-GAC DLLs, I was just desperate to try something.

Thanks to anyone who's read this post through. Any help is appreciated :)

  • Finally sorted it out... it was a permission issue, the Object Cache Superuser and reader accounts did not have User Policy permissions for the web application; this post helped me solve it: blogs.msdn.com/b/sambetts/archive/2013/04/26/…
    – AdrianH
    Mar 10, 2014 at 11:15
  • In case the link doesn't work, you basically go to the Central Administration Console, manage the Web Application and select User Policy; there you grant the two accounts Full Control (Superuser) and Full Read (Superreader). You can find the accounts configured as the obj cache accounts from the Sharepoint Powershell by using: $wa = Get-SPWebApplication -Identity "<WebApplication>" $wa.Properties["portalsuperuseraccount"] $wa.Properties["portalsuperreaderaccount"]
    – AdrianH
    Mar 10, 2014 at 11:16
  • Apparently this problem didn't only affect wiki pages but multiple types of editable content - pages, editable data and others - all except for uploaded documents.
    – AdrianH
    Mar 10, 2014 at 14:54

1 Answer 1


looks like you have the right access due to accessing the aspx pages. What I'm thinking is, is your master page correct and your wiki page?

does your wiki page look like this:

<%@ Page Language=”C#” Inherits=”Microsoft.SharePoint.WebPartPages.WikiEditPage” MasterPageFile=”~masterurl/default.master” meta:webpartpageexpansion=”full” meta:progid=”SharePoint.WebPartPage.Document” %>

make sure your web.config contains the Microsoft.SharePoint.WebPartPages.WikiEditPage dll reference. You should be able to copy Microsoft.SharePoint.WebPartPages.WebPartPage and change the key from assembly!

also found this if above is all ok!:


  • I found the hint about the TaxonomyHiddenList and it didn't help (sorry for missing it, I've tried so many things in the past two days I don't remember all of them - rolled them all back, though). As for the DLL, I thought the class was defined in the Microsoft.Sharepoint DLL which is already referenced; I'll have to check if a different lib exists for the WikiEditPage. And yes, the page tag looks just like that. Just a custom MasterPageFile but switching to the default didn't help.
    – AdrianH
    Mar 8, 2014 at 2:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.