- The ability to connect existing SharePoint team sites to Office 365 Groups, so you can augment existing sites with shared conversations, calendar and Planner.
05-16-2017 11:45 AM
Important sets of announcements today from the SharePoint team, including this specific one coming later this year:
05-16-2017 11:52 AM
05-16-2017 01:11 PM
05-17-2017 11:55 AM
Wait...site collections. That would be no good. Our site collections are per regional office and our subsites are departments. We NEED to be able to connect an 0365 group to a sub-site. Please clarify Microsoft.
05-17-2017 05:01 PM - edited 05-17-2017 05:32 PM
SolutionHi all - yes our plan is to provide the ability to connect only root site collections to new Office 365 Groups. We've considered enabling subsite-to-group connections, but there are enough gotchas both architecturally as well as from a design standpoint in delivering an experience that is comprehensible to most humans. One example is that when we start rolling out classification-based policy (e.g. Confidential classification equates to group guests being disabled, SharePoint external sharing turned off, etc. - this is just an example for discussion), those policies apply at the site collection container level. If we enabled subsite connection to groups, we would have to deal with site parent-child policy conflicts, inheritance-based permissions, etc. Not saying it's impossible but cleary stands in the way of shipping an experience sooner.
Having looked at all site collections in the service, the vast majority are flat (i.e. no subwebs), for which this experience should work seamlessly. That said, we acknowledge that there are some very active site collections with subsite hierarchies. For these subwebs, there are a couple of paths to get to 'modern'. 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. The other, is a 'modernize this site' type of experience that brings the classic subsite to the modern experiences without a group connection. This is also a body of work we are investing in and will share additional details in the future.
Hope this helps to clarify. We'll definitely be talking more about this in the coming months as we make progress on the feature.
Thanks
05-17-2017 05:33 PM
@Christine Stack we've started doing what @Tejas Mehta mentioned and bought a migration tool to just move existing content into newly created Group sites (root site collections).
im super suprised to hear the stats on the subsites, weve done quite a lot and even more since the expansion of site collection sizes. we typically had one SC for projects, one for workgroups, one for each operating company, etc. in any case it is painfully clear information architecture is dead, might as well embrace it :grinning_face:
for us the migrations arent too painful, though we dont have a lot of complexity in the sites we are migrating (eg no workflows etc)
05-17-2017 05:51 PM
This is dissapointing. This still means there is a large migration process in the future for us if we ever want to start using groups or teams in our org.
05-18-2017 05:20 AM
Tejas Mehta,
I really apreciate the quick answer. Not exactly what I was hoping since we have many subsites but at least we know where we are moving to. I am that we will leave the current structure "as is" create new 0365 modern sites and just put a hyperlink to the old subsites sites.
It is very easy to convert a DL to an 0365 group but all our permissioning and mailing lists are mail-enabled security groups. Is it easy to convert those to 0365 groups?
Christine
05-18-2017 06:15 AM
Are there any plans to connect pre-team site SharePoint Online sites to O365 Groups?
05-18-2017 07:20 AM
05-18-2017 10:39 AM
Nick, curious to hear more about your scenario? Our plans are to enable group connection for classic team site templates only.
05-18-2017 11:53 AM - edited 05-18-2017 11:54 AM
Can you convert security groups to 0365 groups with powershell?
05-18-2017 11:55 AM
Christine, is this a question for me regarding the group connection to existing site collections? If so, yes we are planning to provide PowerShell cmdlet to achieve the site-to-group connection.
05-18-2017 11:57 AM
05-18-2017 12:16 PM
We create site collections per customers and sub sites per projects. Real collaboration occurs on project so I was expecting a Group at the project level.
As we have a lot of sites (150k customers / 180k projects) we didn't want to create all the sites as site collection.
I was really hoping for sub sites Groups.
05-19-2017 05:39 AM
06-20-2017 02:22 AM
Sitecollection 'Projects' and underlying project sites (or 'Teams' and team sites) is a common use case in tons of SharePoint real world implementations. So we would easily accept any further restrictions if we could tie sub-sites to teams or groups.
If not, the implementation will not really help.
08-22-2017 09:43 AM - edited 08-22-2017 10:15 AM
@Christophe Fiessinger - I'm surprised more tenancies aren't making use of sub-sites. We followed our same onPrem architecture of creating a few top level site collections and then creating multiple site collections under them. The ability to connect a Group to a Sub-Site is going to be critical to our business given the subsites in the structure of PPPM ( Portfolio, Programme, Project management) processes we follow.
Is this something Microsoft are considering, on their roadmap?
We also did it this way to work within the 2,000 subsite per site collection limit, while also maximising our protection from the 500,000 limit of site collections per tenancy.
Any advice / guidance - greatly appreciated
08-22-2017 12:15 PM
Hi Graham, thanks for your feedback. At present we don't have plans to enable connection of subsites to Office 365 Groups. There are numerous hurdles and technical complexities we'd need to overcome, e.g. how do you treat group privacy or external guest access to parent (or child) sites that have been connected to groups themselves or how would users of other group workloads (e.g. mailbox) expect to interact with parent/child resources outside of SharePoint? Implementing the corresponding constraints and representing them in a way that site owners can interpret meaningfully in our interface is a challenging task.
Out of curiosity - are you anywhere near 500k site collections in your tenant, or foresee breaking through that number?
Thanks,
Tejas
08-25-2017 04:52 AM
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.
09-26-2017 06:38 PM
09-28-2017 11:53 AM
10-18-2017 07:28 AM
Brent - do you mind giving the name of the migration tool that you bought?
10-25-2017 04:32 AM
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.
10-25-2017 07:34 PM
10-25-2017 08:25 PM
10-25-2017 08:32 PM
10-26-2017 12:55 AM
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
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.
10-26-2017 06:11 AM
12-20-2017 01:11 AM
01-02-2018 08:17 AM
01-03-2018 06:01 AM
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.
01-03-2018 08:15 AM
01-03-2018 08:59 AM
01-03-2018 09:03 AM
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.
01-03-2018 10:21 AM
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.
01-04-2018 03:01 AM
01-04-2018 06:32 AM
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.
01-04-2018 07:10 AM
01-04-2018 08:29 AM
So, here, as an example is what I see when I go and setup a SharePoint Site... if this is the classic experience what is the 'new' experience where a site is connected to an Office 365 group?
01-04-2018 08:37 AM
The "connecting" piece, i.e. in addition to permissions, can only be achieved thus far by some form of linky type navigation integration. Intertwining the menus on one site and the other, giving the appearance of merging the two, sort of thing.
The one suggested above was to use Teams. A Team has its intrinsic new OG site. And this is the site that the link on the Team tab called "Files" goes to. But you can add another tab to the Team called Old Files and link that to the old classic SP site.
Then on the left nav / quick launch of both old and new sites put all the same menu items / links on both old and new sites. You could indent the old and new libraries on the menu one above the other. So the Contoso scenario might look like this: -
V Documents
Old Documents
V Finance Docs Library
Old Finance Docs Library
If the user clicks on "Old Documents" they're taken to the "Old Documents" library on the old site. But because the left nav / quick launch menu looks identical on both old and new sites, they don't perceive the click through as a site-to-site navigation. Rather the old library looks like a sub-folder of the new library, and the click through appears as merely navigating to the sub-folder in the same site. (That visual trick / technique is quite useful for when you hit the 5000 limit on libraries too, splitting out the biggest root level folders into their own libraries and indenting them below the original library on the left nav / quick launch from whence they came).
And if the permissions setup is done as above and doesn't hinder them, they might, as one user said to me, wonder if the migration has already been done: "Why did you bring the old folders over into a sub-folder of the new library? Couldn't you have copied them to the root?"
No, of course, the users, or me, or someone has still got to lift those folders across. This is not a "magic merge" or groupification / teamification upgrade of an old "classic" SP site. That's what we're waiting for from Redmond. But at least Teams, the menu interleaving, and permissions tricks gives the perception of progress, integration, and old-new hybrid-ity quite early on in the project.
On the subject of the so-and-so's getting the actual job done, looks like they've missed the "this year" deadline. I suspect it might be quite a bit trickier than they thought. The new OG site and old "classic" site are two totally different SP site templates. The project to deliver the new OG sites was probably all done in an Agile/ Scrum-ish sort of way, with no-one lifting their head above the tactical parapet of the new OG world user story backlog to ascertain what strategic chaos it might cause for migrating / upgrading from the old world.
Go on Redmond, prove me wrong. Tell me you can "magic merge" or groupify / teamify / upgrade an old "classic" SP site on patch Tuesday next week! ...
01-04-2018 08:38 AM
01-04-2018 08:54 AM
New OG groups are either created in the Office Admin Centre, or in the Outlook Groups part of Outlook's menus, or when you create a Team, or when you launch "SharePoint" from the Office 365 app launcher (waffle menu).
Old SP sites are created as you've described above.
The classic sites probably reside in a different corner of MS's Office 365 datacentre from the OG sites, both with respect to where the data is and the admin functionality that manages them. Notice the OG sites don't appear in the list of SP sites in the Office 365 SharePoint Admin Centre.
This is another reason - over and above the differing SP site templates - why MS will have to work quite hard to produce an upgrade or "magic merge" solution: The two systems and data areas are separate, and therefore data will have to be copied between the two. The process will likely not be able to happen in place.
01-04-2018 09:14 AM
That's what we're waiting for.
Note that it will only work for sites, not webs / sub-sites ...
https://blogs.ibs.com/2017/10/17/connecting-existing-sites-to-office-365-groups-kind-of/
01-05-2018 09:17 AM
Hi all! We are absolutely working on a feature that will connect an existing classic team site to a new Office 365 Group. We had a session at Ignite that covers the mechanics in more detail - you can have a look at this session: https://channel9.msdn.com/Events/Ignite/Microsoft-Ignite-Orlando-2017/BRK2434 and the 'groupify' portion starts at around the 19:13 mark of the video.
01-06-2018 01:57 AM
01-07-2018 07:31 PM
01-08-2018 11:40 AM
Hi,
When exactly is this being rolled out? It was announced during Ignite in September. It's been 3.5 months with still no estimate date when to be rolled out?
I have been planning my rollouts based on this announcement to avoid migrating sites.
I'd really appreciate a more SMART goal, with specifics as to when we can expect this to be usable.