Forum Discussion
Site Collection Admin in Modern Team Sites
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.
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.
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 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?
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?
