Site Collection Administrators permissions missing

Question

I've run into a situation where my main administration account is missing the site collection administrator rights.

The account in question did:

1. Create the site collections.
2. Stands as primary site collection administrator.
3. Got owner rights.

But still the extra settings are missing from some of the collections site settings. From some of the site collections i got full access to the extra settings. I am at the root site for every site.

I've tried to re-set the primary administrator but it does not change anything. Logging in as my secondary admin account, i got full rights on all the sites.

Trying to access a URL like _layouts/15/mngsiteadmin.aspx give's me access denied.

Update

Running a PowerShell script which returns all the site collections and the administrator in my faulting web application, it only returns the one where i got administrator privileges. What could be wrong?

Update 2

Logging into with my secondary admin account, accessing the site collection administrators, my primary is missing, even after resetting it from central admin. Are the site broken or is this a bug? Anyone familiar with this problem?

Update 3

A couple of months later. It has happened again. My primary site collection administrator account has lost all the permissions in a random bunch of site collections in a specific web application.

So i cant even access the sites anymore using this account, meaning that the account must have been removed from the owners group as well. This account created the site collections.

Running the PowerShell cmdlt:

get-spsite -WebApplication $w | select url, owner, secondaryContact

returns all the site collections and it shows blank on primary owner and secondary owner in some of the site collections. If i go to Central Admin and go to "Change site collection administrators", the account who lost permissions stands clearly as primary owner of the site, but still has no privileges left.

Entering the account name again does not give me any administrators rights, and in PowerShell it still says blank for primary owner, and i still can't enter the site.

Trying to do it in Powershell using:

Set-SpSite $spSite -owneralias "domain\user" -SecondaryOwnerAlias "<domain\user>"

does not work either.

Any suggestions where i could look? If i can't even do it with PowerShell, then it feels like i can't do it at all.

According to this thread, it's a catch 22 situation.

"It's permissions related. The account I was using to run PowerShell did not have permissions to read content in the problem sites and apparently Owner and SecondaryContact as considered to be content!"

PowerShell SP bug? SPSite.Owner and SPSite.SecondaryContact are Null?

Trying to set all the site collections administrators using PowerShell removes the permissions instead.

Get-SPWebApplication $w | Get-SPSite -Limit All | ForEach-Object { Set-SPSite $_ -OwnerAlias "Domain\Username" -SecondaryOwnerAlias "Domain\Username" }

Answer 1

Did you try adding your primary, secondary and the account with which you run PowerShell, to the User Policy at the Web Application level of the Site collections in question?

from central admin > Manage web applications > select the web application for your site collections > from the ribbon select 'User Policy' > add your primary, secondary and the account with which you run PowerShell and give full rights.

This gives full control (SC admin rights) to the accounts to all the site collections under the web application, even if you are not a primary or secondary SC admin to any of the SCs.

Once you do this, you should be all set. You can also run your PowerShell without any permission issue and you should be able to return ideal content.

Answer 2

I had the same problem and resolved it as follows:

1. Run PowerShell with SharePoint modules

2. Execute following command:

   Set-SPSite <URL> -owneralias "i:0#.w|< domain\user >"
   

It looks like this is a bug which occures when the user profile import was not run correctly, the last thing I don't know yet, but it's my best guess

Answer 3

Were you by chance performing site backups or restores with that account? Like spsite-restore? I know that stsadm had a nice little habbit of putting sites into read-only and sometimes they remained locked. You could check CA > application management > configure quotas and locks to see if the site was locked. I know you said your other account worked though.

Answer 4

If you are not a primary site administrator / secondary contact for the site collection, you should run your PowerShell code in an elevated block as shown below to be able change the site owner via the Owner property of the SPSite:

$url = "https://yoursite"
$siteOwnerLogin = "domain\user"

# elevated privilages
[Microsoft.SharePoint.SPSecurity]::RunWithElevatedPrivileges(
     {
         $web = Get-SPWeb $url
         $user = $web.EnsureUser($siteOwnerLogin)
         $web.Site.Owner = $user
     }
)

It is not because RunWithElevatedPrivileges would change the identity your PowerShell script runs with. For the SPWeb instances created within an elevated code block the IsSiteAdmin property of the CurrentUser property will be true, even if the user executed the code has no administrative permissions on the site, and it is the very same property the security checks in the Owner property verify.

You find further details on this behavior in this post.

If you are a farm administrator and a local admin on the SharePoint server you run your admins scripts on, you can use the stsadm -o siteowner command as well to change the site owner:

stsadm -o siteowner -url http://yourserver/yoursite -ownerlogin "domain\user1"

If you are a farm administrator, you can change the owner of the site without the elevated privilages as well:

$url = "http://mysiteroot/users/user1" 
$siteAdmin = New-Object Microsoft.SharePoint.Administration.SPSiteAdministration($url) 
$siteAdmin.OwnerLoginName = "domain\user1" 

You find further details on these approaches here.