Ability to connect existing SharePoint team sites to Office 365 Groups is coming later this year

[cfiessinger]

Important sets of announcements today from the SharePoint team, including this specific one coming later this year:

• The ability to connect existing SharePoint team sites to Office 365 Groups, so you can augment existing sites with shared conversations, calendar and Planner.

https://blogs.office.com/2017/05/16/new-sharepoint-and-onedrive-capabilities-accelerate-your-digital...

[#2]

@Tejas Mehta

Thank you for such a quick response.

That is a real problem for us. I appreciate some of the challenges that you have flagged.

In our specific case, the permission inheritance aspects are not such a big deal. We've architected our sites and sub-sites this way more so for the IA aspects rather than the permission inheritance, i.e. we make more use of Site Collection Content Types, Site Columns etc, so that each set of sub-sites pull from their specific set of common js and css etc.

I guess, what we want to know is that. In the Groups interface can change the link behind the Files and Notebook links?

and future in Teams - change the Files link or remove it so we can add our own Files link.

To answer your question. Right now, do to Self-Services site creation process we have over 2,000 sites collection. However, we are planning to link our solution to automate the creation of these sub-sites based on business rules in our Enterprise Data Warehouse, so when a Job or Lead reaches a particular business state the tools like, the SharePoint site, Group calendar/email etc.. and permissions to them are provisioned, so that they are available at the time of when they needed.  We will be testing this with one part of our business this year which will result in a run rate of around 1,000 sites a month, and if successful we will look to expand this for more of the business. So the numbers will grow faster early next year.

[#3]

Hi Christophe,

Any update re. timing of SC link to groups?

Thanks,
JC

[#4]

Hello,
It's super challenging for us to create groups/teams w default email assignments. We had a name change, but aren't changing the domain. In creating users, we can simply add the alias. Without this option in groups/teams, it's defaulting to an @ address that isn't our common use. Is there a way to add an alias group email address?

[#5]

Brent - do you mind giving the name of the migration tool that you bought?

[#6]

You might try mapping Channels from Teams to the sub-webs of your Site (site collection).

Team, Group, and Site are all a one-to-one relationship.  Probably best we keep it that way or we might all go mad.  So for example, if "Products" is the subject matter, then there's one Team / Group / Site called Products.

However, there is a one-to-many relationship between a Team and its sub-Channels.

And there's a one-to-many between a Site (site collection) and its sub-Webs.

So you can create a Channel (sub-Team, so to speak) for each sub-Web (sub-Site).  Then add a tab in the Channel that connects to the corresponding sub-web, and put a link back to the corresponding Channel from the left nav (Quick Launch) of the sub-web.  The Channels then map the augmented functionality for conversations etc. to the sub-webs on one-to-one basis.

So for each actual product sub-Web (Grommet, Rivet, Bracket, etc.) you might have below the Products Site, there's a corresponding Channel (Grommet, Rivet, Bracket, etc.) below the Products Team.

I'm just waiting for the programmatical interface to Teams to become available before setting up some automation provisioning whereby the associated Channels are created automatically from the sub-Webs.  This will work for Customers, Suppliers, Employees, as well as Products, where the one-to-many-ness abounds.

[#7]

We're also not going to benefit much from the ability to convert site collections, we definitely need the ability to convert subsites, else we're going to have to do a heck of a lot of migration.

[#8]

Hi Tejas,

You say "One is a migration effort from subsite to root site collection, and then connecting the collection to a new group with the feature described in this thread." would it be just as easy to create a group and then migrate the data from old team site to the new group? Are there any disadvantages to this over your suggested method? I understand that site collections created using my suggested method won't appear in the site collection list for administrators, but I believe this is on the way anyway.

Thanks.

[#9]

This wouldn't work for us. We have a handful of site collections all of which have hundreds of subsites under them. Because there's no way to set permissions per channel, everyone would be able to see everyone's conversations etc.

[#10]

There's a user voice for that one, and MS are apparently working on it: -

https://answers.microsoft.com/en-us/msoffice/forum/msoffice_o365admin-mso_teams-mso_o365b/microsoft-..., that's  01d6edb182e6 

https://microsoftteams.uservoice.com/forums/555103-public/suggestions/16911079-support-for-private-c...

Hopefully whatever users / groups / permissions functionality MS put into Teams for Channels it will have an API too.  Then we can code something to sync permissions between the SP sub-Webs to the corresponding Channel.  For example, the SP sub-Web Members group syncs its membership to the corresponding Channel's "group" (or whatever they call groups in the users / groups / permissions functionality for Teams and Channels) thereby granting permissions to the conversation for the Channel only to the members of the SP sub-Web's members group.

[#11]

I really don't think the "purpose" of the channel-level permissions is set up to align to sub-sites. And that level of mapping would be a nightmare.

In reality, I believe based on the way Groups and Teams has been "architected", doing mini-migrations into a logical NEW setup is the right way to do this. Everything else may end up being more painful in the long run.

Channel level permissions will help with what Andrew was mentioning, but again, I still think there is lots of rework in your future.

[#12]

Has this feature landed yet - I cannot see any way to connect our SharePoint Team sites to Office 365 Groups?

[#13]

It hasn't yet.

[#14]

Hi,

If there is a need to add existing O365 groups to Sharepoint subsites, there is always the possiblity to grant access to the AD Seurity group equivalent of the O365 group via the site's SharePoint group.

[#15]

Sorry, but I'm not following you here: can you elaborate what you mean? You can add Office 365 Groups to your SPO Subsites security configuration with no problems

[#16]

how?

[#17]

For migration scenarios with nested sites and where the Teams functionality is also required: it could be an option to grant access separately to the SP sites, and "Teamify" the O365 groups where Teams make sense and the group is to interact across the collaboration and communication apps. Links can be added to the above mentioned Sharepoint sub webs to the Teams' tabs.

[#18]

That's a handy integration during a migration: using Teams as a portal to tab-aggregate the old "classic" SP site with the new "group" site, and drop the new Teamified Office 365 group security principal into the required SP group of the old "classic" SP site, but ...

Don't let Redmond off the hook!  Those so-and-so's will do anything to get you off the line!  If you don't want to migrate, and do want to Groupify-Teamify an existing "classic" site to save unnecessary hours of extra migration work with users, make MS work for it.

[#19]

thanks Lawrence, I'm maybe being a little thick here, but I see the words you're saying about migration and teams and classic and groups etc. - but if you don't mind could you clarify how I would go about going from our current SharePoint Online "classic" sites to somehow them being linked to or as groups. Do I need to contact Microsoft or something I am not clear on how you do it....

[#20]

Hi Baronne,

Let's say your old "classic" site is called Old-Contoso, and it has the usual 3x SP Groups: Old-Contoso Owners, Old-Contoso Members, Old-Contoso Visitors.  You manage members of the SPG's in the usual manner, by selecting security principals from the people picker.

And you've got a new Office Group called New-Contoso.  So this comes with its own membership management, surfaced in the Office 365 Admin Centre -> Groups, and also in the Outlook Groups presentation of the OG functionality.

If you go to the Old-Contoso SP site -> Site Settings -> People and Groups, and select one of the SPG's, say Old-Contoso Members, then add a new user, the people picker will let you select the OG's like they were users.  If you add an OG to an SPG, the members of the OG membership gets the access that the SPG has to sites, libraries, folders, and docs in the Old-Contoso site.

Likewise, if you go to a site, library, folder, or document in the Old-Contoso site, and disinherit its permissions from its parent, and add permissions, the people picker will allow you to add an OG and grant it permissions.

So you can use OG's, for example the New-Contoso OG, to puppet master the permission across your old "classic" SP sites, for example Old-Contoso, by adding the OG's as members of the old "classic" SP sites' SPG's, or by directly granting the OG's access permissions on the old "classic" SP sites' containers (sites, libraries, folders) and documents.

So in a migration or hybrid you can manually configure the OG's to duplicate the old permissions by creating OG's with memberships, adding them to the old sites SPG's, containers, and documents permissions.  Then delete the old memberships of old SPG's.

The old sites and SPG's are then security "zombies" from a group membership point of view.  All granting of collective permissions is made by member management of the new OG's, and by granting permissions of those OG's onto the resources of the old sites.

[#21]

Excellent! thanks Lawrence - for some reason in my mind I had thought that the "connecting" of classic site to OG was somehow where the sites/URLs would become connected/merged somehow - eg.
OG group : TEAMA (https://ourtenant.sharepoint.com/sites/TEAMA)
SP Site : TEAMA (https://ourtenant.sharepoint.com/sites/BU/TEAMA)

...somehow the two could link so they didn't have "separate" SharePoint sites...
So from what you're saying the connecting of these is en essence to do with assoication by security group permissions rather than some fancy magical merge...