I have run into this point of confusion several times since the GA of the Power BI Premium SKU. As I mentioned in my post about licensing, the Power BI web part for SharePoint requires the user viewing the report to have a Pro license. Alternatively, if the organization has purchase Power BI premium capacity, and the report has been deployed to that capacity, then all organizational users will be able to view the report in the web part.
The initial announcement about Premium licensing laid out 5 different SKUs for premium, P1, P2 and P3. These SKUs are the “normal” SKUs that are intended to be used by Power BI customers. The “P” stands for Premium. Subsequently, 3 additional SKUs were announced at the Data Insights summit to be used by ISVs. These SKUs are EM1, EM2, and EM3. The “EM” stands for embedded. The embedded in this case means Power BI embedded. That’s where the confusion sets in.
Power BI Embedded is the ISV offering for Power BI. With Power BI embedded, software vendors can use Power BI as the reporting engine in their application. A number of vendors have taken advantage of this capability in the recent past including Nintex with their Hawkeye product, and ourselves with tyGraph for Yammer Reporting. With Power BI embedded, all of the processing for the application is done in the vendor’s Power BI tenant. Customers don’t require a Power BI license of any sort to use the applications. Recently, Power BI embedded has moved to a premium model as well, which is why the EM SKUs exist. They are for purchase by software vendors to power their own applications.
If we have a look at the pricing for each of these SKUs (in $US/month), we can see that the EM SKUs are significantly cheaper, but they also come with the important restriction that they can ONLY be used by ISVs.
Back end cores
Front end cores
4 cores, 25 GB RAM
8 cores, 50 GB RAM
16 cores, 100 GB RAM
0.5 cores, 3 GB RAM
1 core, 5 GB RAM
2 cores, 10 GB RAM
It may be natural to think that because your goal is to “embed” a Power BI report in SharePoint, that you will be able to use one of the cheaper, “embedded” SKUs. Microsoft loves to overload terms when they name things, and this is one of those times that this tendency leads to confusion. Make no mistake, in order to embed a Power BI report in a SharePoint page, and to have other users be able to view it, you will need to have a Pro license, and your users will either need Pro licenses as well, OR your organization will need to have purchased a Power BI Premium “P” SKU, not an “EM” SKU.
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.
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.
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.
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.
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 22.214.171.124 Preview version is required.
One would think that the GA version (126.96.36.199) 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
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.
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.
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.