Tag Archives: SharePoint

Use Power BI to Help Manage Your SharePoint Sites

Note – This article first appeared on April 12, 2017 on the Microsoft Partner Network

When it comes to Business Intelligence, SharePoint is most often used as a platform to access dashboards and reports. With the recent availability of the Power BI web part, Power BI joins SQL Server Reporting Services and Excel as a go-to reporting tool within SharePoint.

Occasionally, list data is used as a data source for these reports. This doesn’t work for large amounts of data, but for smaller lists, this is perfectly adequate. Given that Power BI has native connectors for both SharePoint lists and libraries, it is perfectly suited for this sort of task. Combining these two results in some interesting possibilities, as the following article demonstrates.

We work extensively with modern Groups in Office 365. Each group gets its own SharePoint site, and within that, its own OneDrive, or “Shared Documents” library. Depending on the usage of the group, the storage in that library can grow quickly, and it’s not always easy to spot where all the content is being stored. By building a Power BI report that uses the OneDrive as a data source, we can create a report of storage allocation by file and folder, and then show that report on the home page of the SharePoint site.

There are several steps to building this report. It all starts with Power BI Desktop.

Get the Data

To start with, we Launch Power BI Desktop, and Select “Get Data”. Then we select the “SharePoint Folder” file source, and enter the URL of the SharePoint site. Even though we are prompted for the URL of the folder, we must enter the URL of the site itself. The query editor can be used later to filter out any unwanted folders. Only user created document libraries and folders will be returned.

The query will return a number of columns that are irrelevant to this report, and they can be removed. We need to create a column for the URL to the files themselves. The attributes column can be expanded to get the size of any files in bytes. We also use the split function to split the folder path by the “\” delimiter which will allow us to create a folder hierarchy. Finally, we set the appropriate data types on columns, and give them user friendly names.

The scope of this article does not allow for a complete step by step walkthrough of the query editor, but the code below can be pasted into the advanced editor (after replacing the URLs appropriately).

let
  Source = SharePoint.Files("https://yoursharepointsiteurl", [ApiVersion = 15]),
  #"Removed Columns" = Table.RemoveColumns(Source,{"Content"}),
  #"Added Custom" = Table.AddColumn(#"Removed Columns", "Folder", each [Folder Path]),
  #"Added Custom1" = Table.AddColumn(#"Added Custom", "URL", each [Folder Path] & [Name]),
  #"Removed Columns1" = Table.RemoveColumns(#"Added Custom1",{"Folder Path"}),
  #"Replaced Value" = Table.ReplaceValue(#"Removed Columns1","https://unlimitedviz.sharepoint.com/sites/Presentations/Shared Documents/","",Replacer.ReplaceText,{"Folder"}),
  #"Renamed Columns" = Table.RenameColumns(#"Replaced Value",{{"Folder", "FolderBase"}}),
  #"Added Custom2" = Table.AddColumn(#"Renamed Columns", "Custom", each Text.Trim([FolderBase],"/")),
  #"Renamed Columns1" = Table.RenameColumns(#"Added Custom2",{{"Custom", "Folder"}}),
  #"Removed Columns2" = Table.RemoveColumns(#"Renamed Columns1",{"FolderBase", "Date accessed"}),
  #"Expanded Attributes" = Table.ExpandRecordColumn(#"Removed Columns2", "Attributes", {"Size"}, {"Size"}),
  #"Changed Type" = Table.TransformColumnTypes(#"Expanded Attributes",{{"Size", Int64.Type}}),
  #"Renamed Columns2" = Table.RenameColumns(#"Changed Type",{{"Size", "Size (bytes)"}}),
  #"Added Custom3" = Table.AddColumn(#"Renamed Columns2", "Size (KB)", each [#"Size (bytes)"] /1024),
  #"Changed Type1" = Table.TransformColumnTypes(#"Added Custom3",{{"Size (KB)", type number}}),
  #"Added Custom4" = Table.AddColumn(#"Changed Type1", "Size (MB)", each [#"Size (KB)"] /1024),
  #"Changed Type2" = Table.TransformColumnTypes(#"Added Custom4",{{"Size (MB)", type number}, {"Date created", type datetime}, {"Date modified", type datetime}}),
  #"Split Column by Delimiter" = Table.SplitColumn(#"Changed Type2","Folder",Splitter.SplitTextByDelimiter("/", QuoteStyle.Csv),{"Folder.1", "Folder.2", "Folder.3"}),
  #"Changed Type3" = Table.TransformColumnTypes(#"Split Column by Delimiter",{{"Folder.1", type text}, {"Folder.2", type text}}),
  #"Renamed Columns3" = Table.RenameColumns(#"Changed Type3",{{"Folder.1", "Folder"}, {"Folder.2", "Subfolder 1"}, {"Folder.3", "Subfolder 2"}})
 in
  #"Renamed Columns3"

Build the Report

When the Query is complete, we click on the load the data into the model. We don’t need to do a lot of model editing for this report, it’s relatively straightforward. There is only one table, and the Date Created field gives us enough time intelligence that we don’t need to create a date table. There are two edits to the model that I used that bear mention.

One thing that I wanted to show was the accumulation of storage over time. With the size of the file and the create date, I could show the total size that was added for a given day, month or year, but that doesn’t show the accumulation. To do that we need to create a calculated measure, “Cumulative Size”. The formula below calculates a running total of file size based on date:

Cumulative Size (MB) =
 CALCULATE (
  SUM ( Files[Size (MB)] ),
  FILTER (
  ALL ( Files[Date modified] ),
  Files[Date modified] <= MAX ( Files[Date modified] )
  )
 )

It’s not strictly necessary, but it’s convenient to create a folder hierarchy by dragging subfolder1 onto Folder, and then dragging in subfolder2 to the bottom of it. That allows all levels of the folder hierarchyto be managed as one.

Finally, we add our visual elements to the report. The report itself can be seen above. In this case, the Size by Folder chart uses the folder hierarchy as the x axis so that clicking on a data bar (while in drill down mode) will open a lower level folder. Marking the data category of the URL field will cause the report to display a clickable URL in any tabular visuals, and setting the “URL icon” property (in the Values section) of the table will display a link icon instead of the long URL. Doing this will allow the user to open any of these files directly from the report. The Growth Rate chart used the Cumulative Size calculated measure created above.

Embed the Report

Once completed, we publish the report into Power BI. It is important to select the correct workspace for this. Since we will be embedding the report into a SharePoint page, it is important to ensure that all viewers will have access to the report. By publishing the report to the same Power BI Workspace that is used by the SharePoint site in question, this will be automatic. In this case, we are reporting against the “Presentations” team site that is associated with the “Presentations” group, so we publish this report to the “Presentations Power BI workspace.

Once published, we need to get the embed URL for SharePoint. This can be determined by opening the report in Power BI, selecting File- Embed in SharePoint Online.

Once we have the URL, we navigate to the SharePoint site and edit the home page (note – the home page needs to be a modern SharePoint page). Once in edit mode we add a new web part, and select the Power BI web part. When prompted, we enter the embed code retrieved above. Once the page is published, all is complete.

Finally, the data source in Power BI will need to be set up to refresh on the frequency required.

With a few simple steps, we have not only gained insights into the storage patterns of our team sites, but we have made those insights available to all members of the site in a highly interactive fashion, without making them open another application.

Enabling the new OneDrive Sync Client for SharePoint

I recently wrote about the fact that the new OneDrive sync client now supports the synchronization of SharePoint libraries, and the benefits that it brings. Since the release however, I have heard from several people that even though they have the new client, their libraries continue to sync with the older OneDrive for Business client. Microsoft has documented all of the procedures for getting it to work in this article, but I wanted to call out a few common issues here. If you’ve been using the old OneDrive for Business Sync client, and you want to move to the Next Generation Sync Client (NGSC), you’ll want to check the items below.

Make sure you have the correct version

The Next Generation Sync Client has been available for over a year, but the ability to synchronize SharePoint libraries was only added in January 2017. If you use Windows 10, the client is updated automatically, but you may not have it yet. To check your version, right click on one of the OneDrive clouds in the system tray (not any OneDrive for Business icons) and select “Settings”

Next, click on the “About” tab and check the version.

If you have version 17.3.6743.1212 or above, you’re good to go. If not, or you’re not running Windows 10, you can download the latest version here.

Ensure That Your Tenant is Configured for the New Client

Administrators can configure their tenant to use either the new OneDrive Sync client or the old OneDrive for Business Sync Client. This configuration setting is in the SharePoint administration of Office 365. To change this setting, log into the Office 365 Admin portal (or have your tenant admin do this if you don’t have rights). The URL for the portal is https://portal.office.com/adminportal/. Once there, launch the SharePoint admin center by clicking SharePoint in the Admin Centers section.

The setting that we’re after is in the “settings” section of the SharePoint admin center. Select it, then scroll to the “Sync Client for SharePoint” section. The options are straightforward – Start the new client, or start the old one. Once selected, click on Save (scroll down for the button). This setting controls what happens when the “Sync” button is selected in a SharePoint library.

Initiate the Takeover Process

Even with this setting turned on, the old OneDrive for Business sync client may be active. You’ll need to take action to have the new client take over. This can be done one of several ways. Firstly, running the setup process for the new sync client will do it (download is above). You can also run “OneDrive.exe /takeover” to accomplish this, but the easiest approach is to simply sync a new library by clicking on its Sync button. Doing so will not only sync the new library, but will take over syncing anything that the older client is doing.

Once the takeover process is complete, the old client will be removed on the next system restart. That’s the last you’ll see of GROOVE.EXE.

OneDrive and SharePoint – Together Again

A little over a year ago I wrote a post entitled “OneDrive, TwoDrive, ThreeDrive” in which I took a slightly cheeky look of what has become known as the “Next Generation Sync Client” (NGSC) for OneDrive, and its many idiosyncrasies. I then turned that post into a speaking session (Changing the title slightly to OneDrive, TwoDrive, White Drive, BlueDrive), and that session has been presented at many events over the past year. In that post and session, it is pointed out that the NGSC still had some work to do, and that it would get done.

True to their word, it seemed that every time I presented that session, I had to modify the slides in one way or another, as another feature was added, bug was squished, or idiosyncrasy clarified. In September, at Microsoft’s Ignite event in Atlanta, Reuben Krippner announced the public preview of a new sync client (as I like to call it, the Next Next Generation Sync Client”. This version of the client addresses the principal shortcoming of its predecessor – namely that it didn’t synchronize SharePoint libraries. I’ve been running the preview ever since. With SharePoint libraries forming the backbone of all document storage in Office 365, including Office 365 Groups, this shortcoming was particularly glaring.

The good news is that this new version of the NGSC is now generally available. You can download it from the OneDrive site, or, if you use Windows 10 and are frequently updating, you’ll get it automatically. With the general availability of the new client today, it seemed like a good time to circle back and see how many of my original criticisms have been addressed.

SharePoint Library Sync

Obviously, the biggest disappointment with the original NGSC was the fact that while it added OneDrive for Business repositories in addition to OneDrive personal stores, it was unable to sync SharePoint libraries. Any library contained in an Office 365 Group or a SharePoint site was therefore excluded and resulted in users needing to run a mix of old and new client. We had this odd situation in where you would sync OneDrive for Business with the OneDrive Sync client, and all your SharePoint libraries with the OneDrive for Business sync client. Now add to it the fact that Group libraries were referred to as the Group OneDrive, and it was quite confusing for end users. Apart from the technical limitations of the old sync client (no more than 5,000 items per library, no more than 20,000 items across all libraries), adding SharePoint libraries to the new sync client greatly reduces confusion for end users and complexity for administrators.

System Tray Inconsistencies

After the rollout of the original NGSC, after connecting my personal OneDrive, my OneDrive for Business, and SharePoint libraries, I would wind up with three OneDrive icons in my system tray.

The white cloud represented the sync process for my personal OneDrive, the blue cloud with the bright white border represented my OneDrive for Business, and the blue cloud with the slightly dimmer white outline (really – look at the picture) represented all the SharePoint libraries that I was synchronizing, including Group OneDrives. If I were interacting with two different Office 365 tenants as I do today, I would have five icons for everything, and while I can certainly cope with it, the inconsistencies made it rather confusing for the end user.

Adding SharePoint libraries to the modern client reduces this complexity. Now the same scenario will show two icons – one white, one blue. The white icon represents the personal account, and the blue icon includes the OneDrive for business as well as all SharePoint libraries being synced. If two tenants are being used, as in the image below, there will be two blue icons, one for each tenant. Hovering over the icon will identify the tenant in question.

The icon styles are also now more consistent, and as an added bonus, they always line up at the top of the system tray, which is a nice touch. While we still have more than “One” drive, it’s much more understandable and usable.

File Explorer Inconsistencies

The user interface insistencies extended to the File explorer integration as well. In the same scenario as above, syncing a personal OneDrive, and a OneDrive for Business with SharePoint libraries from a single Office 365 tenant, I previously wound up with three root nodes in the Windows File Explorer.

“OneDrive – Personal” was my consumer, or personal OneDrive, “OneDrive – UnlimitedViz” was my OneDrive for Business storage connected to my UnlimitedViz tenant, and “SharePoint” contained all my SharePoint synced libraries. One inconsistency is the fact that the personal icon is white in the system tray but blue in the File Explorer. In an organization, people also tend to distinguish their content stored in their OneDrive from organization content by referring to it as “personal” so the use of the word “Personal” here can cause confusion here as well. Finally, the OneDrive branding is completely thrown out the door here when it comes to SharePoint libraries. Keep in mind that at the time, the only way to synchronize SharePoint libraries was with the “OneDrive for Business Sync Client”. However, the resulting node is called “SharePoint”

The latest client makes some significant improvement in this area as well.

“OneDrive – Personal” remains my personal (consumer) OneDrive. The two nodes here names “OneDrive – Serendipity” and “OneDrive – UnlimitedViz” are my two OneDrive for Business locations on the two tenants named “UnlimitedViz” and Serendipity”. Finally, the two nodes “Serendipity” and “UnlimitedViz” contain all the synchronized SharePoint libraries in those two tenants. While the personal icon remains stubbornly blue, the nodes here make significantly more sense and in my opinion in least are much more intuitive.

Selective Sync for SharePoint Libraries

It almost goes without saying, but the all-or-nothing approach to the OneDrive for Business sync client (previously Groove), rendered a lot of large libraries un-syncable. By bringing SharePoint libraries into the NGSC, they too get to participate in the selective folder sync that the consumer client has had for quite some time.

Pause

The previous OneDrive for Business sync client wasn’t all bad, and the NGSC wasn’t all good when compared to each other. One very useful feature that the older client had that NGSC didn’t was the ability to pause a sync. Pausing is a relatively frequent need for various reasons, but the only way that the NGSC could be paused originally was by shutting it down. Given the time it required to start back up sometimes, this was a problem. Luckily, at some point over the past year, the NGSC picked up pausing capability, and you can now pause a sync for 2, 8 or 24 hours.

Stability and Performance

Apart from features, stability and performance is probably the most obvious area where the new client outshines its predecessor. There are countless tales of users having their work “eaten” by the older client. While this hasn’t happened to me, I can point to many times that a sync got corrupted, and the only way to fix it would be to resync the entire library. This would necessarily mean a new repository as the older client couldn’t work with pre-existing content. Having used it for several months now, I have yet to experience any issue that required the total resync of a library.

The sync performance of the new client is acceptable as well. To be sure, it could still be better. Startup times are quite long for me (keep in mind that I’m syncing quite a lot of content), and occasionally the sync process gets bogged down and needs to be restarted. However, it was good enough for me to decide to move my almost 1 TB of content back into OneDrive for Business. That very same content made the move in the other direction 2 years ago, due to performance issues.

Overall, I must say that my overall impression of the new OneDrive sync client is that it is finally ready for prime time. Shortly after the preview was announced in September, I was sufficiently impressed to move my relatively large Dropbox file system (where I had a 1 TB limit) over to OneDrive for Business (with its unlimited storage). I then heaped quite a bit more storage on top of it, and it seems to be performing well now. My main OD4B storage account is currently at 3.3 TB, and my personal OneDrive is at 600 GB. I even have several Groups set up in my Office 365 MVP tenant for managing my household and those libraries are synced by myself and my wife.

Stability is fine, and performance is good enough, apart from the occasional “looking for changes” hang-up. Its value and integration have tipped the scales in its favour, certainly with respect to Dropbox in my opinion. The Office team said they were going to fix it, and they did. Good for them.

So, You Can Disable Office 365 Groups After All

After my recent post “You Can’t Disable Office 365 Groups”, I received feedback from a few people, specifically Elaine Van Bergen,
Martina Grom and Joe Stocker that some editing controls have been added in through the tenant that allows Group creation to be disabled in the Office 365 tenant, and that these controls affect all of the user interfaces that can create groups. The procedure is outlined here, and Martina offers her insight on it here . I was a little disappointed that I had missed these newer controls earlier, but quite happy about the discussion that the original article started. It brought to light some of the confusion around this feature. In addition, it also highlights the fact that Office 365 Groups are about far more than just conversations, they are the bedrock of all Office 365 services moving forward.

Having said that, and having tested these new controls, I have a few observations to make about disabling Groups.

Much of the feedback that I received of my original article was “Good, they shouldn’t be disabled anyway, they’re too important”. To be sure the other side of that argument was heard from as well, but I tend to side with the former. For me at least, the group construct represents real value. It is a trade-off between ease of use and control to be sure, but as a container, it’s easy to understand, and relatively easy to work with for end users. The concerns around Groups are focused on governance, and those concerns are valid. If anyone can create a group anytime, and there is not process for organizing or classifying them in place, they can quickly get out of hand, producing islands of information all over.

The new management controls allow for a single security group (not an Office 365 group) to define those that can create Groups. Groups created by these members are available to all, but only these members can create new Groups. Only one security group can be flagged for group creation, so it’s an all or nothing proposition for these group members.

The article above walks through the process of creating these controls through PowerShell with the Microsoft Azure Active Directory Module for Windows. There are a couple of quirks when walking through this process. I found that the article itself contains a typo, the PowerShell command “Get-MsolCompanyInfo” should actually be “Get-MsolCompanyInformation”. In addition, when downloading the module itself, the 1.1.130.0 Preview version is required.

One would think that the GA version (1.1.166.0) would include everything necessary, but one would be wrong. I made the mistake of trying to use that version and I hit a wall. You need the preview version.

The Azure Active Directory management area in the new Azure portal also allows for the management of group creation rights. I was unable to use the interface to initially set these controls, but once set, the controls were reflected in the user interface, and it’s possible to manage them. Azure Active Directory management is still in preview in the new portal, so presumably this will improve at GA. The controls can be found in the Azure Active Directory blade under Users and Groups – Group Settings.

Like their predecessor, these controls don’t remove the option to create a group from the client interfaces. Once the “Create” option is selected, the user is usually notified that this will not be possible. In one case, it simply fails. The following are the different messages that users will receive when they try to create a new Group but are prevented from doing so.

Outlook Web Access

SharePoint

Planner

Power BI

Microsoft Teams

Ideally, the create option would simply be removed from the user interface, but at least these interfaces prevent the user from filling out details before failing with one notable exception. When a new Group Workspace is created in Power BI, the operation simply fails, and the user isn’t notified as to why. It almost seems as if the Power BI team wasn’t notified that these new controls exist.

The remaining workload that is (ok – will be) integrated with Groups is Yammer. With Yammer, when a Yammer Group is created, a corresponding Office 365 group will be created, and kept in sync with the Yammer group construct. This will ultimately be where Yammer notes and files are stored (via OneNote and OneDrive – basically SharePoint) as well as the group calendar (in Exchange). However, according to this Microsoft support article, if Office 365 Group creation is disabled, then the Yammer groups will not be Office 365 connected.

It therefore is now possible to prevent users from creating Office 365 Groups. This will be important to large organizations while they formulate an adoption strategy for Groups, but formulate it they should. Just because Groups can be disabled, it doesn’t mean that they should. Groups are by their very nature a compromise between usability and manageability, and centralizing creation tips the scales on the side of manageability. We’ve had this for a long time with classic SharePoint, and the usability of Groups is what’s so exciting from an adoption standpoint. Almost all innovations in the Office 365 space are now centered on Groups – they are the new foundational unit, and by ignoring them, you miss out on much of the future enhancements.

Caution is certainly advised, but it’s a good idea to move forward with a Groups strategy. Now.

You Can’t Disable Office 365 Groups

Note – Since originally publishing this post, I have been made aware of some new management tools that will allow the ability to disable group creation by default. As opposed to modifying this post, which contains other observations, I have published a new one dealing with these new tools here.

As I’ve discussed before, Office 365 Groups are a very important feature in Office 365, and one that all organizations using Office 365 should fully understand as soon as possible. Groups are either required or they provide important capabilities for every product in the Office 365 stack. However, every organization has a different tolerance for change, and some have no tolerance for it at all. In addition, there are many aspects of Groups that are still a work in progress (navigation for example). A frequently asked question is “how do we turn off Groups?”. There’s nothing in the Office 365 Administration interface in either the Groups, or the Services & Add-ins sections.

Groups Administration

Groups section in Services & Add-ins

I’m far from the first person to hear this question, and a quick Internet search will turn up many articles that walk through the process of “how to disable Groups creation”. There is an article on Technet that walks through the process, and Wictor Wilén has another that is quite straightforward (not to mention insightful). Finally, Albert-Jan Schot walks through the process of doing this for specific users or groups of users in the tenant.

What these approaches do is to adjust the Outlook Web Access policy that controls the creation of Office 365 Groups. At its core, an Office 365 Groups is just a type of Azure Active Directory Group, one with multiple services attached to it. When Groups were first introduced, the only way of creating them was through the Azure Active Directory interface, PowerShell and through Outlook Web Access (OWA). The first two methods require an administrative level of access, so enabling and disabling this feature in OWA effectively disabled it for end users. An end user can still see the Group creation controls, but any attempt to create a new group is met with a dialog informing them that this feature is disabled.

Since Groups were first introduced, there have been several significant changes as more Office 365 services embraced the Groups structure, and others have been introduced that rely on it.

When the “new” Power BI was introduced in mid 2015, its Sharing story relied heavily on Office 365 Groups. Each Group receives a Power BI workspace, and conversely each new Power BI workspace is a Group. Given that end users can create and to some extent manage the workspace directly in the Power BI user interface, it represents an alternate Groups management tool focused on the end user.

Creating a new Group in Power BI

Microsoft Planner, launched in mid-2016 is another product that relies on the availability of Groups. For the most part Planner stands on its own, with minimal ties to the rest of the Office 365 stack. Each Plan contains multiple tasks, but under the covers, each Plan is backed by an Office 365 Group, with all the rest of the available services. Creating a new plan in Planner creates a new Group, and everything that goes with it, even though the interface doesn’t make it very clear. You’re getting far more than just a plan.

Creating an Office 365 Groups (aka Plan) in Planner

With the release of Modern Team Sites in SharePoint, SharePoint is also very tightly bound to Office 365 Groups. Before this release, creating a new team site through the SharePoint interface or through the SharePoint administration interface created a classic SharePoint site collection. Doing so now also creates a group to go along with it (again, with everything that goes along with that) and all the access to the new Team Site (a site collection) is controlled through membership to that Group. The SharePoint interface for this makes it very clear as to what is happening – “Lets create a new team site and group”.

Creating an Office 365 Group from SharePoint

It is still possible to create a SharePoint site collection that is not bound to a group through the SharePoint administration interface. Modern team sites (the site collections created through the SharePoint user interface) don’t appear in the SharePoint administration interface at all.

The Outlook 2016 rich client also has a comprehensive set of group management features. A group can be created by right clicking on the “Groups” node in the Outlook mailbox, and once created can be fully managed by the “Home” tab in the ribbon.

Creating a new group in Outlook 2016

Managing a group in Outlook 2016

There are now 5 different way for end users to create and in some cases, manage their Office 365 groups. The original Outlook Web Access interface, and now Outlook 2016, Planner, SharePoint and Power BI. The processes outlined above for disabling group creation prevent group creation from Outlook Web Access, but what effect do they have on these new interfaces? The answer is, no effect whatsoever. Whether the “GroupCreationEnabled” OWA policy has been set to false or not, these other interfaces will still be able to create and work with Office 365 Groups. This may not be surprising as Power BI, Planner, and now even features of SharePoint are dependent on the Groups infrastructure.

I have not called out Microsoft Teams above. It is true that Teams is also dependent on the Groups infrastructure, and that creating a new team will create a new group. Where Teams differs from the other dependent services is that the creation of a new Group in one of the other interfaces does not automatically create a new Team. In addition, Teams itself must be enabled by an administrator, meaning that for this additional service, Groups creation can be controlled centrally.

In the very near future, Yammer will also become Groups dependent. Creation of a new group in Yammer will spin up a corresponding Office 365 group, which will be used to store the files and notes available in Yammer. These groups will be flagged as “Yammer managed” meaning that they will not appear in the Outlook interfaces, but they will be available to all the other services that utilize groups.

The bottom line of all this is that even if you use Office 365, and you think that you have disabled Groups in your tenant, the chances are that you could be in for a surprise. If any of these dependent services are in use, the chances are that you already have several created.

Groups are the bedrock of all new features in Office 365 moving forward – it is therefore a good idea that your organization understand them as soon as possible. Their inevitability is also another strong argument for paying close attention to them. If you are currently discussing whether or not they should be used, I would strongly encourage you to shifting that discussion to how they should best be used.