Photo by Fancycrave on Unsplash

Introduction

There are a few good articles about modernizing a classic site by using the “Connect to new Office 365 Group” action.

Two great ones are on Microsoft’s sites:

• Connect a classic experience SharePoint team site to a new Office 365 Group
• Connect to an Office 365 group

If you read those articles very carefully, I’m sure they cover most of the “gotchas” that I have documented here, but they are, in no way, obvious.

Setup

For this experiment I had the following setup for the site collection:

Site Collection Template	Classic Team Site
Site Name	Classic Team Site

Groups:

Name of Group	Members
Site Collection Admins	Mike Hatheway Admin
Classic Team Site Owners	ADGroup1 John Doe Maggie Knowsall
Classic Team Site Members	ADGroup2 Bill Smith Jane Doe

Subsite

I also added a subsite. This subsite did not inherit permissions from the root site.

Details:

Site Template	Classic Team Site
Site Name	Classic Subsite

Groups: 

Name of Group	Members
Classic Subsite Members	Peter Price
Classic Subsite Owners	Bonnie Enclyde

The Experiment

I went through the steps without modifying any of the prompts to see what came out the other side. I have shown the basic steps in the gallery below.

The Results

The Results are as follows. Since the O365 Groups and the SharePoint groups have the same names, I have distinguished them with an (O365) or a (SP) tag after the name.  

Groups:

Name of Group	Pre-conversion Members	Converted Members
Site Collection Admins	Mike Hatheway Admin	Classic Team Site Owners(O365) Admin
Classic Team Site Owners(SP)	ADGroup1 John Doe Maggie Knowsall	ADGroup1 John Doe Maggie Knowsall
Classic Team Site Members(SP)	ADGroup2 Bill Smith Jane Doe	ADGroup2 Bill Smith Jane Doe Classic Team Site Members(O365)
Classic Team Site Owners(O365)	N/A	John Doe Maggie Knowsall Mike Hatheway Admin
Classic Team Site Members(O365)	N/A	Bill Smith Jane Doe

The subsite and the security groups remained unchanged.

The Gotchas

#1 Users are not removed from SharePoint groups

When the system goes through the default groups (and it will only go through the default Members and Owners groups), it adds all Site Owners to the Owners of the new O365 Group. It then adds all Site Members to the Members of the new O365 Group. Then it simply adds those the O365 Owners to the Site Collection Administrators Group and the O365 Members to the Site Members SharePoint Group.

The issue is that it doesn’t remove the original users when it adds them to the group. So now you have Bill Smith as a Member of the O365 Group and as a member of the SharePoint Site Members Group.

Question: “But what’s the big deal? Isn’t it close enough?”

Answer: No it’s not. Let’s say as the owner of this new shiny site, you decide to go clean up the permissions. You go into the site permissions panel and remove Bill Smith. Then you post a document that Bill shouldn’t see, but that’s OK because you removed Bill, right? No. Bill is still a member of the O365 Members group (which s hidden under a button you might not have clicked) and still has member access to the site.       

#2 Users are “randomly” removed from Site Collection Administrators Group

This one is the closest thing I can find to a bug.

In my testing, I noted that, although all users are retained in Members and Owners Groups, that one user (and I could not determine what user and why) would be removed from the Site Collection Administrators Group.

In the experiment above I ran the conversion as the Admin user but that user was left in the Site Collection Admin Group. In other tests, it would remove the account I was running the conversion under.   

This isn’t a major issue because it does add all the Site Collection Admins to the O365 Owners Group, and it adds the O365 Owners Group back to the Site Collection Admins Group (another duplication).

#3 Owners of the root site are now Site Collection Administrators

This was the reason I added the subsite for this experiment. Much like the “The Problem with Maggie” section of my article on Site Types and Permissions, you may lose track of who should (and who does) have Site Collection Administrative rights after converting to a group.

You should note, in the above example, 2 users (Admin and Mike Hatheway) had access to everything on the site collection including the “Classic Team Site” and it’s subsite “Classic Subsite”.

You should also note that even though the users/groups: ADGroup1, John Doe, and Maggie Knowsall had Site Owner access at the root site, that they still didn’t have access to the subsite (it has unique permissions).

But after the conversion, all O365 Site Owners on the root site are added to the Site Collection Administrators group. This contains any users (not groups) in the SharePoint Site Owners group. So, after the conversion, the two new users will have Site Collection Admin privileges (John Doe, and Maggie Knowsall).

If you don’t have any subsites or list/libraries with special permissions this is probably not a big deal.  

Bonus Gotcha: Groups are not added to the O365 Group

No groups (O365, Security, Mail-enabled Security) are added to the newly created O365 group.

This may not be a gotcha to anyone familiar to O365 groups as MS has published many articles stating that O365 group cannot contain groups.

Note: SharePoint groups cannot be added to SharePoint groups, so you wouldn’t need to worry about this.

Conclusion

As a “SharePoint Person”, I get it. SharePoint is complicated and full of legacy code, so there are probably reasons for the implementation of “Connect to new Office 365 Group”.

I do wish that the users were removed from the SharePoint Groups when they were added to the O365 Groups, or that they would provide that as an option in the wizard (something like a checkbox saying, “Remove users from SharePoint when adding to O365 Group?”).

My $0.02 is that if you are looking at this “Connect to new Office 365 Group” functionality, that you are probably modernizing your site. And if you are modernizing your site, you may want to think about re-architecting it at the same time. Avoid trying to reuse your old sites as-is. This may be the perfect time to do some spring cleaning in SharePoint, create some new modern sites (maybe even some hub sites), and move some content off of these classic sites so that you can retire them.