Skip to content

Master Page gone bad! The base type is not allowed for this page.

Recently, I had a user check out a master page, make a change, then upload it to the master page gallery. He did not publish the new master page, so I  thought that even if he had messed it up, nothing could break. I was wrong. What I didn’t realize was that this master page was maintained through a wsp. Any changes to it had to be rolled into a wsp update and deployed that way. I was unaware that this particular site collection was managed that way.

So now, when going to any page on that site, we got a big fat “Sorry, something went wrong” error message. This was followed by a message like this:

The base type ‘MySiteName.MasterPage.MySiteName_Master’ is not allowed for this page. The type MySiteName.MasterPage.MySiteName_Master, MySiteName, Version=, Culture=neutral, PublicKeyToken=c9257e7fd2740965 could not be found or it is not registered as safe.

There was a correlation ID along with the message. Taking the correlation ID into the ULS logs, I found a couple relevant messages, but they didn’t say much more than the page did.

Application error when access /Pages/home.aspx, Error=The base type ‘MySiteName.MasterPage.MySiteName_Master’ is not allowed for this page. The type MySiteName.MasterPage.MySiteName_Master, MySiteName, Version=, Culture=neutral, PublicKeyToken=c9257e7fd2740965 could not be found or it is not registered as safe.
at Microsoft.SharePoint.ApplicationRuntime.SPPageParserFilter.AllowBaseType(Type baseType)
at System.Web.UI.TemplateParser.ProcessInheritsAttribute(String baseTypeName, String codeFileBaseTypeName, String src, Assembly assembly)
at System.Web.UI.TemplateParser.PostProcessMainDirectiveAttributes(IDictionary parseData)
Microsoft.SharePoint.ApplicationRuntime.SafeControls+UnsafeControlException: The base type ‘MySiteName.MasterPage.MySiteName_Master’ is not allowed for this page. The type MySiteName.MasterPage.MySiteName_Master, MySiteName, Version=, Culture=neutral, PublicKeyToken=c9257e7fd2740965 could not be found or it is not registered as safe.
at Microsoft.SharePoint.ApplicationRuntime.SPPageParserFilter.AllowBaseType(Type baseType)
at System.Web.UI.TemplateParser.ProcessInheritsAttribute(String baseTypeName, String codeFileBaseTypeName, String src, Assembly assembly)
at System.Web.UI.TemplateParser.PostProcessMainDirectiveAttributes(IDictionary parseData)

I googled around and found a couple blog and forum posts and that helped me zero in on the issue.

This problem can occur when your master page is part of a wsp. When you deploy the wsp, then activate the master page on various SharePoint sites, the master page is “ghosted.” This means that when the wsp is updated, any instances of the master page from the wsp that has been deployed will be updated automatically as well. That’s a great feature if you want to exclusively control the master page through controlled code updates.

But if someone goes in and manually edits the master page in the master page gallery – either through SharePoint Designer or by checking it out, changing it, and uploading it back to the gallery – it breaks this kind of inheritance. It “unghosts” it. And now, anywhere that edited master page is used is now broken. That’s not such a great feature.

But there is a fix. A way to “re-ghost,” or, more officially, reset page to site definition version. Even with your site giving you the big error with correlation ID, other pages that don’t use the master page should still work, including site settings. You can get to it by going to . That’s for SharePoint 2013. For 2010 it’s, for 2016 it’s .

So go to the site settings.

Under Site Actions, go to Reset to site definition.

By default, the “Reset specific page to site definition version” radio button is checked.


In the box for “Local URL for the page,” enter the URL of the master page.

That URL should be something like:

If you are not sure of the URL, you can find it in the Master Page gallery. You should be able to navigate to the gallery by appending this to the URL: /_layouts/15/ChangeSiteMasterPage.aspx (or removing the /15 or replacing it with /16 depending on the version of SharePoint you are working with).

Find the Master Page you need to re-ghost, and from that list item’s drop-down menu, select “View Properties.”

In the Properties, there is a hyperlinked name field. Right click on the link and select “Copy Shortcut”. That will give you the URL of the Master Page.

Re-ghosting the master page will eliminate any changes you’ve made since the manual changes to the master page. You will have to re-implement anything you’ve done since then. But if you normally only update the master page through a wsp deployment, and the accidental manual edit of the master page immediately caused this problem, there should be no changes to roll back.

I found these two links to be supremely helpful in my troubleshooting:


Permissions for email enabled lists and libraries

I was recently tasked with enabling lists and libraries on the SharePoint farm to receive incoming emails. I’ve set this up before, and there are lots of guides on how to do this. But before I could proceed, I was asked a lot of questions about what users would have the ability to turn on incoming email for a specific list. Could anyone do it? How could we limit it? And I couldn’t find a good summary of that information. After some digging, here is what I found.

The ability to enable incoming email on a list requires the “Manage Lists” permission. This permission is, by default, in the following permission levels: Edit, Design, Full Control, Manage Hierarchy. So any group with those permission levels will have the ability to turn on incoming email.

Of the default groups, site Owners, Members, and Visitors, only Owners has a permission level that includes the Manage Lists permission. So in a farm with default permissions and groups, only Site Owners could turn on incoming email.

It is pretty much impossible to limit the ability to activate incoming email. The Manage Lists permission is required to create and delete lists, add or remove columns in a list, and add or remove public views of a list. You can’t take away the ability to activate incoming email without taking away the ability to create a list.

So if you turn on e-mail enabled lists, know that there is no easy technical way to limit site owners from enabling incoming email on all their lists.

Embedded Spreadsheets not displaying

I recently had an issue with Excel spreadsheets that were embedded in a page not displaying. Instead of the spreadsheet, users saw an error box with the message “Unable to load the requested workbook.” Users could open spreadsheets in the app, but not in the browser (we have Office Web Applications configured).

There are a lot of reasons why this is happening. Usually Excel Calculations Services is not running. Recycling the application pools in IIS can often fix this issue. But not this time, not for me.

Digging deeper, I went to the ULS logs. I found an interesting error: “#960013: Antivirus scanner timed out.” associated with the page the spreadsheet was hosted on.

We run Forefront Protection for SharePoint on our farm, so I opened up the console. I found the following error: “The SharePoint service is running but the Forefront VSAPI Library is not registered.” Forefront runs on each server on the farm, and this error was only showing up one of the farm servers. Of course it was on the application server, where Excel Calculations Services were running.

Some Googling led me to this: , but the steps listed there to restart the service did not fix the issue. Finally, a reboot of the server got Forefront into a good state, and spreadsheets started working again. Why didn’t I try that first?


SharePoint 2010 Administration Service won’t start

This one had me banging my head against the wall for a while. On our two web front-ends, the SharePoint 2010 Administration Service would not start. The only difference between the WFE’s and the App servers where the service was working, was some firewall rules.

I could not find useful information in the Windows Event logs. A couple errors, the most prominent bein “Error 1053: The service did not respond to the start or control request in a timely fashion” is not very helpful. I also found some Event ID 4656 audit failure errors in the security log that coincide with when I try to start the service. Lots of advice on turning off logging for this particular event, but nothing I found that told me what kind of problem would cause that error.

Finally, I found this blog which was short on details: , but it turned out to be the cause of my pain.

Microsoft patch kb2677070 is an automatic updater of revoked security certificates. It will let Windows Server go out to the internet, get an updated list of revoked certificates, and make security decisions based on that. But if your server is firewalled away in a DMZ and does not have unfettered internet access, this call to the find the updated revocation list will fail. When it does, the SharePoint 2010 Administration service will not start.

To fix this problem, you can uninstall the patch, or disable the network check in group policy. Some have reported that uninstalling the patch does not fix the problem. I couldn’t find the patch in add/remove programs, and I wonder if there isn’t a newer patch that might include this “functionality”. Anyway, disabling the network check fixed the issue for me. Here’s how to do it:

  • Open Group Policy Editor. From start->search box, type in gpedit.msc and hit return.
  • Navigate to Computer Configuration->Windows Settings->Public Key Policies-> Certificate Path Validation Settings.
  • Click on the “Network Retrieval” tab.
  • Check the “Define these policy settings” and uncheck the “Automatically update certificates in the Microsoft Root Certificate Program”
  • Click OK

Now try to start your SharePoint 2010 Administration service.

What web front end am I seeing?

So we have two web front-ends with our SharePoint 2010 farm. Load balancing is not done through Windows NLB, but rather through an F5 BigIP, which is managed by a different group in our IT department. This presents some challenges for me as a SharePoint administrator. When I see issues with a SharePoint site, how can I quickly tell if it is isolated on a specific WFE? Normally, I’d have to contact the group that manages the load-balancer, have them remove one WFE from the pool, then wait for my session to expire, then test the site.

This is such a hassle that I came up with a quick and dirty way of telling which web front end I’m on. And it is so simple, any end user can tell at a glance and let me know over the phone.

I take a graphic that is on the front page of a site. You can use any image that is on your site. For 2010, I use the default site icon. A lot of companies will customize this image, but we use the default.

I save the image to my computer, then I open it up in a graphics editing program. I use GIMP, available for free at . You can use PhotoShop or even Paint, whatever works for you. Then I add a mark – one dot for WFE 1, and two dots for WFE2.


And then I copy the appropriate version of the graphic onto the corresponding WFE. The default location for this graphic is <14 Hive>\TEMPLATE\IMAGES\SITEICON.PNG . I replace the default file with the image with the dot. No IISReset is needed. When you go to your site, you can now quickly see if you are on WFE1 or WFE2.

Some of our site owners customize their sites and don’t display the SiteIcon image. But our root sites all display it. For SharePoint to work properly, the BigIP has to be session-aware. That means, when you initially connect to the SharePoint site, the load-balancer picks a WFE and starts your session with it. All subsequent traffic from your session is routed to the same WFE. Our load-balancer is configured with a 60 minute time-out for sessions. That means, once you start a session, all traffic will be routed to the same WFE, until 60 minutes of inactivity has occurred.

So once you view the main page and see the icon, you know what WFE you are on. You can then navigate to a site, and even if it doesn’t have an icon, you know you are on the same WFE.

Hey look, I’m on WFE2!

The next step, forcing traffic onto one WFE or the other, is more complicated, depending on your network and load-balance setup. That is a subject for another post sometime. But this trick can help you quickly identify which WFE you are seeing, and it has been immensely helpful to us in our troubleshooting.


Another SSL issue

But different SSL than the last post. Our problem was intermittent slow-loading pages. Pages would take 15 seconds to load, seemingly randomly. We narrowed it down to a single web front-end. The slow load would usually happen after you visited a page, didn’t touch it for a while, and then navigated away or refreshed it. Using Developer Dashboard, we could see that the delay was consistently occurring when a 3rd party application was loading a web part. The step was always the same, GetServiceSecurityToken. We worked with the 3rd party company, and they swore up and down that the problem wasn’t their software. The GetServiceSecurityToken is a default SharePoint call that their software used, and the problem was with SharePoint.
We had another web application hosting sites that did not run this third party application, and it too would have the issue. In this case, it was with SearchBoxEx.OnLoad, so it did look like this was an issue with SharePoint, not with the third party app.
We finally found the solution here: SharePoint 2010 uses SSL to encrypt intra-farm communication. It should work invisibly, but under the right conditions, it can cause problems, resulting in these 15 second timeouts. SharePoint has its own internal SSL root certificate and its own certificate stores, so you never see this intra-farm encryption unless you go looking for it. But if SharePoint can’t authenticate the SSL certificate it’s using, it will have these 15 second timeouts before loading the page. Under some circumstances, the page won’t load at all.
The fix is to export SharePoint’s SSL cert through PowerShell, then add it to the server’s Trusted Root Authentication Provider store through the MMC’s Certificate snap-in.
To do that, on any server in the farm, open up SharePoint 2010 Management Shell. Enter the following commands:
$rootCert = (Get-SPCertificateAuthority).RootCertificate
$rootCert.Export(“Cert”) | Set-Content C:\SharePointRootAuthority.cer -Encoding byte

This will export SharePoint’s internal root certificate into the C:\ root directory. You can copy this file to all servers in the farm for importing. To import this certificate, open up MMC.
Start-> Run-> MMC-> Enter.
File-> Add/Remove Snap-in
Highlight the Certificates snap-in and click the add button. You will be prompted for which account to run this snap-in under – your user account, a service account, or the computer account. Select Computer Account, as you need this in the server’s store. That way, all accounts and services will use it.
Expand Certificates-> Trusted Root Certification Authorities.
Right-click “certificates-> All tasks-> Import.
Click the browse button and navigate to C:\SharePointRootAuthority.cer
Open-> Next-> Next-> Finish-> OK.
Refresh the view and you should see the SharePoint Root Authority certificate in the store.

Repeat this import for all servers in your farm. Do an IIS reset on all servers.
This fixed the problem for us (though initially, I ran the Certificates snap-in under the farm administrator account rather than the computer account, which resulted in a couple more days of troubleshooting). Pages stopped having the 15 second delay and everyone was happy.

SSL Certificates, Trusts, and SharePoint 2010

We were having a 3rd party migration tool fail at bringing over some web parts from our 2007 farm to our 2010 farm. Looking through the Windows Event Logs on the 2010 server, I found a number of these errors:

Source: SharePoint Foundation

Event ID: 8311

An operation failed because the following certificate has validation errors:\n\nSubject Name:, OU=IT, O=”Contoso”, L=Redmond, S=WA, C=US\nIssuer Name: CN=InternalCertAuthority, DC=Contoso, DC=com\nThumbprint: <biglongGUID>\n\nErrors:\n\n The root of the certificate chain is not a trusted root authority..

The InternalCertAuthority certificate our company’s own self-signed certificate. I checked, and it is in the Trusted Root Certification Authorities store on all servers in our farm. You can verify that your cert is in the proper store by one of two methods.

In IE, click on Tools->Internet Options. Click on the Content tab and click the Certificates button. Click on the Trusted Root Certification Authorities tab and find your cert.

Alternately, you can use MMC. From the start button, enter mmc in the “Search programs and files” text box. In the MMC window, select File->Add/Remove Snap-in. Highlight Certificates in the left pane, click the Add > button in the middle and click OK. Select My user account and click Finish. Expand the navigation pane “Certificates – current user”->”Trusted Root Certification Authorities”->”Certificates” and find your cert.

If it is not there, you can import it. Get a copy of the certificate from your internal certificate server. It should be in the *.cer format.

Save that file somewhere and open up Central Administration. Go to Security->General Security->Manage Trust. You should see “local” in there, that is SharePoint’s own self-signed certificate. SharePoint uses this to encrypt traffic between servers in the farm. But now, you need to add your company’s self-signed root certificate here. Click the “New” button in the upper left. Give a friendly name to the certificate – “Contoso self-signed” or whatever. Click the Browse button and go to the location where you saved your copy of the certificate. Then click OK.

At this point, everything should be great. You should see your certificate listed on the “Trust Relationships” page.

But you may have gotten an error. Maybe after you clicked OK, you got a message that says “The Root Certificate that was just selected is invalid. This may be because the selected certificate requires a password and we do not support certificates that require a password. Please select another certificate.” How can that be? The cert doesn’t require a password! What is going on?

I’m not sure what is going on, but I know how to get around this error. You can create Trust Relationships through PowerShell, and it is pretty simple. Microsoft’s documentation is here: . For this, you need to save the certificate from your company’s certificate authority somewhere on a server in your farm. On that server, open SharePoint 2010 Management Shell. Type “New–SPTrustedRootAuthority -Name “FriendlyNameForTrust” -Certificate C:\<location of certificate>”

Now, if you go to the Trust Relationships page in CA, you should see the new trust. This fixed our issue with our migration tool and cleared up the errors in the event log.