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.


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" }
  • is it specific to the user account you are using as primary or specific to the primary position?
    – Choggo
    Commented Feb 6, 2015 at 9:29
  • 1) Are you Farm administrator(could be setted in CA)? 2) Did You try to backup and to update farm credentials, could be done like this: stsadm -o updatefarmcredentials -userlogin ** -password **
    – Gennady G
    Commented Feb 6, 2015 at 9:51
  • Second idea - possibly Your machine is in domain, and You by mistake are logging not as, by example - DOMAIN\Administartor, but like PC\Administrator, and have no access
    – Gennady G
    Commented Feb 6, 2015 at 9:55

4 Answers 4


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.

  • No, i did not try that. I did not thought that was needed as a site collection administrator always get owner rights of the site collection.. I shall try it out and see if i can re-run my powershell script to update the administrator fields. Commented Feb 10, 2015 at 6:45
  • While i could enter the site collections in a web application after granting my admin account full control permissions, my powershell script did not set the property correct. Removing the policy permission kicked me out again sadly. Commented Feb 12, 2015 at 14:46
  • Based on your query, you are on all the site collections as a Primary and secondary administrator. Can you add the Primary and secondary admin accounts to the User Policy of the web app in question and see if this issue occurs ever? You can set them at the user policy level, instead of running power shell to set them up. You can do this and see if the permissions ever drop.
    – ssdar
    Commented Feb 12, 2015 at 16:59

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


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.

  • Yes, i have managed some backups with the account, but not in this particular farm/production environment. I did a quick check if any of the sites were locked and they were not. Thanks for the heads up thou. Does the sites running a chance to get locked out using stsadm only or is it the cmdlts for powershell in general taking backups? Commented Feb 9, 2015 at 12:49
  • As I understand, in both 2010 and 2013, you can set the site collections lock status, such as Not Locked or Adding Content Prevented. If you set it to Not Locked, it should still allow users to upload while running the cmdlets.
    – raredesign
    Commented Feb 9, 2015 at 14:13

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
         $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.

  • elevating privileges in poweshell is useless... the RunWithelevatedPrivileges method only takes the context of the current process to the account that is running the process, instead of using the account that ASP.NET uses for the process - That said, it only does something when you're in a process that is impersonating someone with less permissions then the account running the process.
    – Choggo
    Commented Feb 6, 2015 at 12:38
  • 1
    Sorry, I have another experience. For example, if I am neither site owner nor secondary contact of a site I cannot get the Owner and SecondaryContact properties of this site (these seem to be empty), nor can I set these values. With the elevated privilages I can read and set them. If you don't beleave it, please test it to see how it works.
    – pholpar
    Commented Feb 6, 2015 at 12:44
  • I'm skeptical, and from what it does, it really should not make a difference in this case. Still... SharePoint does behave in mysterious ways some times, so I'll defer judgment :p - except I can't until you make an edit to your post.
    – Choggo
    Commented Feb 6, 2015 at 12:50

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.