Skip to content

Category: SharePoint

Power BI Embedded is not for Embedding Power BI Reports

NOTICE Sept 17 2017 – The central thrust of this post is incorrect. I am leaving it here, because it still contains valid information, but for an update, please go to this article –  Which Premium SKU is Needed to embed Power BI Reports in SharePoint and Microsoft Teams

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.

Capacity Node Cores Back end cores Front end cores

Cost

P1 8 4 cores, 25 GB RAM 4 cores

$4,995

P2 16 8 cores, 50 GB RAM 8 cores

$9,995

P3 32 16 cores, 100 GB RAM 16 cores

$19,995

EM1 1 0.5 cores, 3 GB RAM 0.5 cores

$625

EM2 2 1 core, 5 GB RAM 1 core

$1,245

EM3 4 2 cores, 10 GB RAM 2 cores

$2,495

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.

5 Comments

What License is Needed to Use the Power BI Web Part?

The Power BI web part is now a part of SharePoint online for the majority of Office 365 users. This web part allows Power BI reports to be embedded on SharePoint pages, putting them in greater context. These web parts are rendered on the client, not on the server like old style web parts, which means that they are rendered by the consuming user, not the server. This means that in order for the report to render properly, the user needs to not only have access to the report, but also needs to be licensed for it.

The Power BI web part is a feature that requires a Pro license for both producers and consumers. This actually makes sense given that any sharing features in Power BI require Pro. Also, given that the consuming user must have access to the report, the report will be contained in a Group workspace, and Group workspaces themselves require a Pro license. So, what happens when a non Pro user opens a SharePoint page containing a Power BI web part report?

Quite simply, the content doesn’t show up.

Premium Capacity

However, on June 1, 2017, the premium pricing model for Power BI became available. Premium allows organizations to purchase premium capacity in the service. When reports are deployed to this premium capacity, users can access these reports without a Pro license. The act of publishing the report still requires a Pro license, but viewing it does not. Therefore, the Pro requirement for the web part goes away if the report is deployed to premium capacity.

This is in fact how it works. To date, I have seen no official announcement or post from Microsoft on this topic. The closest thing is a response to a forum post in the Power BI community forums:

“If the if the user that is trying to consume the embedded report does not have a Power BI Pro license but is part of a Power BI Premium instance, same viewer rights apply meaning that the user can view the report but collaboration features such as Analyze from Excel are not available, in line with regular Power BI Premium related features.”

The bottom line is that in most cases, all users, both producers and consumers will need a Power BI Pro license to be able to use the Power BI web part. The only time that this is not the case is when an organization has purchased premium capacity, and the report is deployed to that capacity. In that case, only the producer requires a Pro license. It should also be noted that in this case,  some features (like export data) will still not be available to the free users.

8 Comments

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.

6 Comments

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.

2 Comments

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.

7 Comments