Forum Discussion
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.
dave
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.
34 Replies
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 $all.Count 368 $ListOwner = $all | Where {$_.Owner.Length -ge 1} $ListOwner.Count 37Okay, 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).$all[100] Url Owner Storage Quota --- ----- ------------- https://[tenant].sharepoint.com/sites/[sitename] 1048576
So...no 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].sharepoint.com/sites/[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 $members 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.
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.
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.
- 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.
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
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.
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 too...so 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 https://channel9.msdn.com/Events/Ignite/2016/BRK2038. 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: https://contoso2016g.sharepoint.com/sites/ProjectTahoe/_api/site/owner. 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 https://contoso2016g.sharepoint.com/sites/ProjectTahoe | 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, https://contoso2016g.sharepoint.com/sites/ProjectTahoe/_api/web/AssociatedMemberGroup/Users.
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.
You can set site collection admins for a modern team site (a.k.a. Group team site) at
https://<tenant.sharepoint.com>/sites/<sitename>/_layouts/15/mngsiteadmin.aspx
or by powershell.
Salvatore Biscari wrote:You can set site collection admins for a modern team site (a.k.a. Group team site) at
https://<tenant.sharepoint.com>/sites/<sitename>/_layouts/15/mngsiteadmin.aspx
or by powershell.
Note that only the Group Owner can do this. Even an Office 365 Global Admin gets access denied on this!
I have not tried it, but I think that a GA can use the powershell method... Have you tried it?
The powershell method is documented, however...
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 :-)). ssquires I would also be interested in your advice about how to govern security in moder team sites
- 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
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.
On the same vein, modern team site permissions can be accessed at
https://<tenant>.sharepoint.com/sites/<sitename>/_layouts/15/user.aspx
