Forum Discussion
Change group permission on connected group site
- Bob German’s blog is unavailable so I cannot judge his advice.
All I can say is that I favor simplicity above complexity, especially in cloud systems where you do not control all the pieces. It is up to you to decide whether to take the risk that you might break something. If you are experienced at dealing with SharePoint permissions, you might be able to work everything out and all will go smoothly. However, generally speaking, I do not recommend that people go outside the boundaries of the default permissions. It’s your tenant... so it’s up to you. And if you work everything out and make it all work as you want, perhaps you can document what you did so we all learn from your tenant experience.
We have discussed this subject in several other threads in the past. You could do a search for such threads.
The takeover is that it is not recommended to manipulate permissions in modern team sites.
The reason is that Groups are composed of many resources allocated in several workloads, with much things happening behind the scenes, and therefore manipulating permissions often breaks something in an unpredictable way.
If you need to manipulate permission, do yourself a favor and use a classic team site instead.
Maybe TonyRedmond could add something more authoritatively than me...
I agree. Don't mess with the permissions for a group-connected site. If you want to do something funky with permissions, create a traditional team site and use that. There are just too many potential ways you can break the connection between Office 365 Groups and SharePoint (with potential consequences for other apps) if you change the permissions on a group-connected site.
Thanks for the replies. I've done a search and found some guidance, but not on this PowerShell option.
Could you elaborate on what might break? The permission change is only for SharePoint. I can imagine some consequences for Teams, as it uses SharePoint for the wiki and file storage.
Am I missing something else? And there's always an option to revert is back unless Microsoft closes this option.
And another point, I (try to) read and inform myself. There are a lot of users out there that will use the advance permissions options to change the permissions on the SharePoint site. According to your guidance you shouldn't do this. I'm confused as what the consequences of these changes might be. My powershell options is edgy as it overrules the ui that blocks this option, but adding a group and changing the permissions seems fully facilitated by Microsoft.
I don't like the alternative to use classic team sites. Microsoft is pushing hard on the new team sites, with site designs, site scripts and hub sites. If I read correctly I need to miss out on all these options when I don't want to give 'normal' users the ability to customize sites and libraries.
SharePoint has its own permissions scheme, which comes from the on-premises product. You use that scheme with the old-style sites. Group-enabled sites essentially give responsibility for handling permissions over to Groups, where the idea is that all members have the same level of access to all content within group resources, including documents. There are changes made behind the scene to ensure that group membership updates are synchronized to SharePoint to make everything work.
You can come along and introduce your own permissions to a group-enabled site, and those changes might work - today. No guarantee exists that the changes will work in the future if Microsoft changes part of the mechanism that ties SharePoint and Groups together. For example, if you use the Get-SPOUser or Get-SPOExternalUser to examine the (apparent) membership of a group-enabled site, you might find that members long since removed from the group are still present according to SharePoint. This "debris" doesn't matter because Groups controls access and SharePoint refers to AAD for membership information. But if you now introduce your own permissions, you might break something.
Yes, there's a lot of mights and maybes here - but do yourself a favor and avoid the potential for future problems by keeping groups-enabled sites as clean as possible in terms of permissions. My view, Be my guest to go ahead and play with fire...