Site Collection Admin in Modern Team Sites

David Feldman

About a week ago I noticed that Modern Team Sites no longer had the abilty to add SharePoint or Azure Active Directory Groups to be a part of the members, visitors, and owners SharePoint groups.  In fact SharePoint groups had disapeared. 


I just noticed tonight that there is no longer a way on a site to set the site collection admins for that site.  Is there any documentation about what's happening with Modern Team Sites in terms of permissions and authentication.  This seems to be an area that will impact how people think about governance and site structure but i haven't seen a real explanation of whats happening or how the team is thinking about this working.


Any guidance would be really appreciated as this is the biggest non-cosmetic change from modern team sites that i've seen so far.


34 Replies

IMHO this is one of the missing / not well explained points of modern team sites...I'm not aware of that documentation because I think is not ready yet. By the way, those options are there (hidden, but you can manage to get to them :-)). @Sean Squires I would also be interested in your advice about how to govern security in moder team sites

You can set site collection admins for a modern team site (a.k.a. Group team site) at


or by powershell.

You're right that they are currently these, but i hate to rely on things that have been intentionally hidden from the UX.  Even stranger, when i look at who the site collection admins are, it's the group associated with the team site.  This seems really strange having all members of the group by site collection admins seems weird if site collection admins are still a thing.


@Jeremy Mazner have any idea what's happening with Modern team site permissions?  We really would love to be ready as a community before these GA so governance, adoption, and information architecture guidance can be adjust as a part of our readyness strategy.

My client noticed the same thing last week when I was demonstrating this to them. Unfortunately, I did not have an answer, and like you was not able to find one. Microsoft's unwillingness to delay code releases until documentation is ready continues to be a major frustration to me and many others.

If SharePoint team sites aren't going to support using azure active directory groups or site collection administrators that feels like something that should be communicated very clearly with some context around what the strategy is moving forward.  Really hoping this doesn't GA in its current state as I don't know how one could roll these out as is.

Agree with all comments here.   If you are going to give us a sharepoint site, then GIVE us a sharepoint site, not a neutered excuse for a sharepoint site.  


I think the pendulum has swung too far on trying to protect end users from themselves.

@Salvatore Biscari wrote:

You can set site collection admins for a modern team site (a.k.a. Group team site) at


or by powershell.

Note that only the Group Owner can do this. Even an Office 365 Global Admin gets access denied on this!

Understand the current state that this is possible in this one narrow window of a group owner going to an undocumented url and it still happens to work.  I'd really like to understand from MS what the plan is here and where this is going.  Feels like we're trying to reverse engineer current state instead of understand the intent.

@Chris McNulty can you get someone to provide us some insight?

@Kevin Crossman

I have not tried it, but I think that a GA can use the powershell method... Have you tried it?


@David Feldman

The powershell method is documented, however...

@David Feldman

On the same vein, modern team site permissions can be accessed at


You can access almost every administrative page that is part of "classic" sites in modern sites just typing the adminitrative page url :-)

Hi all, sorry for the confusion.  let me try to tackle everything here:

1) documentation -- happy to help fill in gaps where docs are flat out missing, or edit for clarity where we have docs that are insufficient.  If you think docs are missing: post what you searched for and failed to find docs that matched your expectations.  If you think docs need updating, post the URL and leave a comment on the page about what you'd like to see.


2) to Dave's original observations: "About a week ago I noticed that Modern Team Sites no longer had the abilty to add SharePoint or Azure Active Directory Groups to be a part of the members, visitors, and owners SharePoint groups.  In fact SharePoint groups had disapeared" and "I just noticed tonight that there is no longer a way on a site to set the site collection admins for that site": I'm not aware of anything that would have changed in the past week, and in my test tenant I am not seeing any issues -- I went to user.aspx, saw all the default SP groups there, and added a non-mail-enabled SG from AAD to the Members group.  There's discussion further in the thread where people are posting the specific URLs to admin pages and it sounds like they are working for you on the particular comment of "something changed", let me know what specifically worked last week that isn't working now -- URL of the page you're going to, what you're trying to do, what error you get.


3) on how group-connected team site permissions work by default: I tried to cover this at my Ignite talk, around 46:00 mark at  The recap is: Site Collection Ownership is linked to ownership of the associated O365 Group. In pseudo-code, SPSite.Owner == Group.Owner.  When you go to mngsiteadmin.aspx we have a display bug that renders the group name but doesn't make it clear it's the group owners. I will log that for engineering to fix. You can see under the covers by looking at the REST endpoint for your site, eg:  You should see a claim like "<d:LoginName>c:0o.c|federateddirectoryclaimprovider|09d2ba12-c4ad-4428-82d2-eb5f4efe9ebb_o</d:LoginName>".  You'll see the same via PowerShell, eg: "Get-SPOSite | ft Owner" returns "09d2ba12-c4ad-4428-82d2-eb5f4efe9ebb_o" . The GUID is the identity of the group, the "_o" postfix indicates this is the claim given to Owners of that group.  Of course this is not something we ever want any user or admin to have to look at it, but just wanted you to be able to see under the covers that we are actually setting this correctly.  The members of the site default to the members of the group, again in pseudo-code SPWeb.AssociatedMembersGroup.Users == Group.Members.  If it's a public group, we put the "Everyone except external users" claim in there as well.  You can see that in REST as well,


4) on Brent's comment "GIVE us a sharepoint site, not a neutered excuse for a sharepoint site."  That is absolutely the goal.  I described above the defaults for group-connected sites.  We have only one limitation on that site right now, which is that you cannot delete the group owner claim from the site collection admin list -- the whole point of a group-connected site is that the group provides the governance for the site, so removing group owners doesn't make sense.  Beyond that, we do hide the user.aspx page from site settings to encourage users to manage access via O365 group membership, rather than mucking with SharePoint groups, again for better governance, and we will be adding some new modern UI to make it easier for end users to view and manage O365 group membership directly from the site...but user.aspx is still there and still works.  We may over time add additional limitations to avoid getting into cases where group members don't have access to the site...but generally, yes, we are giving you a full site and trying very hard to avoid a case where you say "oh this site isn't good enough, I have to go create a _real_ site to use with this group"


5) to Kevin's comment "Even an Office 365 Global Admin gets access denied" to mngsiteadmin.aspx: this is how SharePoint Online has always worked.  O365 Global Admins are not granted any rights to any SharePoint content or management by default.  If an admin needs access to a site, they must use powershell (Set-SPOSite -Owner) to explicitly add themselves to the Site Collection Administrators for that site.  Without taking this audited/traceable action, even global admins don't have special powers or access.


okay, hope that helps, thanks for the feedback, and let's get documentation gaps patched up for sure.

Thank you very much, Jeremy.

Among other considerations, my takeover is that using hidden pages, directly accessing them by their URL, is definitely a legitimate and supported operation. Am I correct?

@Juan Carlos González Martín

BTW, in his awesome post, Jeremy has answered also to an old question that, if you remember it, we have discussed in the good old days of the Yammer network: why in the SCAs page have we listed the Group name itself?

Jeremy answer is: it is a display bug, and the Group name actually stands for the Group Owners!

Ey Salvatore, what a good times did we have in the wonderfull Office 365 Network :-) always, you are right!

Thanks Juan! I always remember with a little nostalgia those wonderful times!

If you use the hidden UX to delete the AssociatedMemberGroup, our sharing dialog will stop showing the simple "edit" permission, all O365 Group Members will loose access, and other group experiences like modern attachments from mail won't work -- the product is not designed to support operating correctly without AssociatedMemberGroup. And there are other things you can do in user.aspx that will end up changing site behavior in a way that isn't obvious to users -- for example you can share the site to an additional security group for broader access, but when your users look at the doc library or list UX, they will still see it say "Private Group" and will still see a count of members in the associated O365 Group, and they will have no idea that the site is actually available to this whole other SG.  That's no different than how we've always approached SharePoint team sites, the difference with our modern UX and O365 groups is that we are doing more and more work to hide the paths that are most likely to cause pain like this.  People who are taking the time to read this thread will, I believe, understand this implications and make the right tradeoffs for their particular circumstances, but that is different from saying that everything you can do on the page is "supported" as in "will work really well with the default experiences the SharePoint team designed".  Make sense?

Thanks Jeremy


>If an admin needs access to a site, they must use powershell (Set-SPOSite -Owner) to explicitly add

>themselves to the Site Collection Administrators for that site


This right now is at least the same as the fact that the same O365 Global Admin can't see the Group's Site Collection in the SP Admin panel (where, if he could see the site collection he could add additional SCAs).


But, per my above use case, if the site collection is visible to a Global Admin then that Global Admin can edit the Site Collection Admins. I would expect this to continue to be the case...   PowerShell is better than nothing, that's for sure, but isn't really a solution for many of us Service Owners.


Hopefully updating the SP Admin UI ito include Group sites is coming soon.

Thank Jeremy. It makes sense.

Of course it is always possible to shoot yourself in the foot! I didn't mean that everything you can do in the page is okay, but rather than using the page is a supported way to do what is okay...



Thanks for the great reply.  So the summary would be that users can continue to utilize /_layouts/15/user.aspx to add sharepoint or active directory groups and those will continue to live in the product, just won't be linked from the user interface anymore.  A few of us saw those links but didn't know if they would continue to function or if their removal from the ui meant they were being depricated and taken away.


Thanks again


Given that there is a group upon which many other features depend, we should not be allowed to Delete or otherwise modify the functionality of that group. By allowing us to accidentally break the site, you are setting the stage for expensive support tickets. I have already experienced this once (with the special groups in the Root site collection that are used to control the Editing of Links on the Quick Launch bar). MS should not be Hiding things like this, they should be Locking them so that can't break the services.


Providing customers the ability to change/delete features with dependencies has been an issue for over 10 years in SP and it long past time that the problems be avoided by better software engineering practices


I agree with the sentiment, which is why all of our modern UX guides users down safe paths.  But as you can see from this thread, we also have a community of people who depend on being able to do some advanced, custom configuration, and don't want to leave them in the lurch.  We believe that we've struck a good balance here, where unlike the past 10 years we avoid users accidentally stumbling into trouble, but empowering the experts who to get their job done.  I hear your feedback that you think we need to go further, but I know if we completely block it we'll have a lot of feedback saying we went too far.

While I did not explicity state it in my earlier post, one of my key concerns is the fact that MS is allowing things to be done that cannot be undone without a call to Tech Support. Save the company some tech support money, and us a big headache with our clients (which are your customers and when they ask what happened, I have to tell them that MS gave them bullets and gun and they just shot themselves in the foot) and seal/block/lock etc all of the objects upon which you have taken dependencies. Allowing people to accidentally or intentionally change something without providing the ability to undo the change is not a good design decision.  Hiding something does not prevent someone from making a mistake with SP Designer, PowerShell or CSOM. The fact that many of the dependencies are undocumented only exacerbates the problems.

Longer term I hope to not need to remember a collection of urls for assigning scadmins or adding an ad group with thousands of members to a site. I get this model for private team site but I would bet it will need refinement as you get into the publishing use cases in the future where broad sharing goes beyond what O365 groups support today. Many of us have investments in fim and mim that manage enterprise level ad groups so that will hopefully have a place in the story even if the answer is they can be added to an O365 group. That would be better than doing it on the sharepoint site but recognize that's maybe another team.

This thread is perfect for now because it tells us we can use them, it's not going away, we are just making it harder. Hope this gets shared more broadly because it's super important for people to understand it's not a broken sharepoint site, just a site with some guard rails to help simplify

@Jeremy Mazner

As an IT professional, I obviously want to have a complete freedom to do EVERY advanced configuration that I feel necessary for my customers (at my risk, naturally...).

Hence, IMO, you have ALREADY gone too far with blocking/hiding advanced configuration interfaces.

Nevertheless, I understand your effort to guide inexperienced users users down safe paths.

I only hope that this strategy will not impair us, experienced professionals, in our work.

In short: go ahead with hiding, if you have to, but please document thoroughly all advanced configuration interfaces and all dependencies that are in place.

Perhaps a global admin or sharepoint admin setting is in order.

Something like Simple vs Advanced mode. Simple gives you all the locked down/protect the user options, and Advanced gives experienced professional full access to go in and do what we need to do.

The user.aspx page for users in first release now returns a Internal Server Error message.  Hoping that this is just a bug an not a change where that ux is going to be removed.  @Jeremy Mazner is this just a bug?

no changes expected, and https://[tenant][site name]/_layouts/15/user.aspx is working in my usual test tenants.  worth opening a service ticket so we can investigate.

I still don't understand why this is configured like this. As the Admin you should be able to see all site created under the SharePoint Admin console.

Okay, I read through all this and I thought I had a game plan. My goal is to get a list of all my SPO site collections and enumerate their respective owners. Figured that was easy. Not so much...


$all = Get-SPOSite -Limit all
$ListOwner = $all | Where {$_.Owner.Length -ge 1}



Okay, what the flip is that?? That 37 is just about the number of site collections I've created. Based on that, it seems the only the SPO site collections that define an Owner by name are those made by the SPO admin (via the SCA portal or New-SPOSite). But wait....

I picked one of the 'no owner' sites at random to verify the 'Owner' column. It is indeed blank (but interestingly, not $null).



Url                                                          Owner Storage Quota
---                                                          ----- -------------
https://[tenant][sitename]                    1048576 owner then? I better double check. I ran Get-SPOSite against just this one site.


Get-SPOSite -Identity $all[100]

Url                                                          Owner           Storage Quota
---                                                          -----           ---------
https://[tenant][sitename]             [guid]_o        1048576


This time, a GUID appeared as the Owner. It had an '_o' at the end which I think denotes this as an Office 365 group. To confirm this wasn't a user account, I ran Get-MSOLUser


Get-MsolUser : User Not Found.  User: [guid]



So then I ran Get-MSOLGroup and....


Get-MsolGroup -ObjectId [guid]
ObjectId DisplayName  GroupType
--------  ----------- ---------
[guid]    Test Plan   DistributionList


What the what?? Can distribution list be a site collection owner? I guess so. And why didn't this show up as the owner in the first place? I mean it has a display name, an email address and everything. Anyway, I then ran Get-MSOLGroupMember to see who the heck was in this group.


$g = Get-MsolGroup -ObjectId [guid]
$members = Get-MSOLGroupMember $g.ObjectId

GroupMemberType  EmailAddress       DisplayName
---------------  -----------------  ------------
User             j.smith@my.domain  John Smith



Okay, I am getting there. Once armed with this information, I ran Get-MSOLUser again.


Get-MSOLUser -ObjectID $members.ObjectId

UserPrincipalName   DisplayName isLicensed
-----------------   ----------- ----------
j.smith@my.domain   John Smith  True



Ah, there's the Owner! So that only took, what, like 5 steps? To get a single user name from a single site collection. It's okay though because, while it's a cumbersome process, at least I have hundreds of these to do (and more each day!).


Seriously though, this is unquestionably in-freaking-sane. How in all the verse is a person supposed to manage this?? Can this be done the other way? That is, can I take a single user and find out all the sites they own? Because, if not, all it takes is someone needing to know which sites are owned by User X (like after they were fired or something) and I would have to run this process, complete with cross-lookups of guids, against 300+ site collections. This wouldn't include verifying this against local AD. Keep in mind that getting this info about admin-created site collections takes about 10 seconds.


My brain hurts now. I am going to lie down.

What you really mean is that the Microsoft Developers are literally coding and throwing it over the fence from one day to the next,  while you are developing and rolling out to your customers or clients, so... life is "like a box of chocolates", from one day to the next you never know what the h*%# you are going to get. Surprise, surprise. For the moment I think everyone should consider Sharepoint is a moving target! Don't waste your time. RSR

Please remember that answers are supposed to provide additional information.
Ey Pablo,
Thank you for that...remember also that any message in a thread is also supposed to provide additional information about the discussion
Related Conversations
Change Sharepoint modern site name, and URL
주현 김 in SharePoint on
3 Replies
RSS Feeds within a site.
Allan Clarke in SharePoint on
1 Replies
What is the domain ""??
Tobey Davies in SharePoint on
36 Replies
Cannot drag web parts
Laurie Willis in SharePoint on
17 Replies