SharePoint 2013 –

If you are getting these errors or users are reporting this error when trying to get access to a site, this might be your problem. Each site collection can set its own email address for access requests, if you allow them. Here is how to fix it.

  1. Go to the top level site of any site collection. Click on Site permissions on the settings page.



  2. On the page that comes up, click on Access Request Settings.


  1. Change the default value to whatever email you want to receive the requests. is the default. This is why you are getting the errors.



Cannot delete Host header site collections in Central Admin

I was recently trying to create some host header site collections to my new SharePoint 2013 farm. My first 2 attempts failed because I did not have enough rights to the content DB where the site collections would be created.

s—spsite : Cannot open database “lISS_Content_Intranet” requested by the 
gin. The login failed. 
gin failed for user ‘CORP\SPINSTALL’. 
1 line:1. char:1 
iew—spsite ‘” —owneralias 
t orp\spinstal... ____________________ 
+ Categorylnfo : InualidData: (Microsoft.Share. . .SPCndletNewSite: 
SPCndletNewSite) [New—SPSite], SqlException 
+ FullyQualifiedErrorid : tlicrosoft.SharePoint.PowerShell.SPCndletNewSite

Once I added the proper rights, I tried the command again, only to be told that those site collections already existed. When I go to the view all site collections page in Central Admin I see my phantom site collections in the list. Highlighting it however, reveals no metadata on the right as you would expect. compare the below images. the first is my phantom site collection. the second is a proper one.



I tried to delete these rogue entries , only to be told they did not exist. Clearly a bug here, but how to fix it? I stumbled upon 1 simple solution while working on a different issue. Follow these basic steps (Dont try this if you are in the middle of an upgrade. this assumes you dont have any upgradeable databases)

I have a mix of powershell and central admin here. You could do this all with powershell or all with the UI. This is just how I did it.

1. create a test web application. you can delete it when you are done.
2. in central admin, on the content database page remove the content db from the new test web app (or use powershell)
3. now remove the content db from your actual web app where you are having the issue using the same process as step 2
4. attach your content db with the rogue site collection entries from your actual web app to the test web app. here is a powershell command (you can do this in the UI as well)

Mount-SPContentDatabase “MyDatabase” -DatabaseServer “MyServer” -WebApplication http://sitename

5. now you can browse to the list of site collections in central admin under this test web app and you should see that the phantom site collections are gone.

6. once again, remove the content db from the test web app

7. once again, attach the content db back to the original web app and you should be good to go

8. delete the test web app and unused content database created with it.

It may be that just removing and reatttaching the content db from the original web app may be sufficient without the need for the test web app. that may be worth a try first. I was researching another issue and found to my surprise that my phantom site collection issue had been solved.

The operation failed because the server could not access the distributed cache

I ran across this error the other day while configuring the Newsfeed for my sharepoint 2013 site.

I found a solution at this blog post, though the symptoms were slightly different, the fix was the same..

The issue was that the app pool for my user profile application and the web application were using different domain accounts. The domain account for the user Profile Service needs access to the User Profile application for the feed to show properly

I went into Central Admin–> Manage Service Applications.
Highlight user profile service, click Permissions on the ribbon
Add the rights. The only option that seemed to be available was full control.


once that was done, the newsfeed began to work properly