Site Collection Admin in Modern Team Sites


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

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

best response confirmed by David Feldman (MVP)

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