Category Archives: SharePoint

Understanding the Power BI Capacity Based SKUs

This week at Microsoft Ignite, Microsoft introduced a new capacity based SKU for Power BI Embedded, intended for ISVs and developers: The A SKU. This brings the number of capacity based SKUs to 3, with each category having numerous sub categories. This means that there are a number of ways to embed content by using Power BI Pro, Power BI Embedded, or Power BI Premium. The trick is to know what will be needed for what circumstances. This post will attempt to help with the distinctions.

The SKUs are additive in nature, with A (Power BI Embedded) providing a set of APIs for developers, EM (Power BI Premium) additional ad-hoc embedding features for organizations, and P (Power BI Premium)providing a SaaS application that contains everything that the Power BI service offers. For some background, the EM SKU was initially introduced to serve the needs of both Independent Software Vendors (ISVs) and of organizations that needed to do some simple sharing within the organization, and give them access to the latest Power BI features. However, ISVs have a different business model than enterprises, which is why the A series was introduced.

Power BI Embedded A SKUs

The A SKU (A is for Azure) is a Platform-as-a-Service and set of APIs for those ISVs who are developing an application to take to market. These ISVs choose to use Power BI as the data visualization layer of that application to add value to their own application. As such, Power BI assets contained in Power BI Embedded capacities cannot be accessed by a licensed Power BI user, but are only accessed by customers of the ISV’s application.

Power BI Embedded capacity is billed hourly, can be purchased hourly, and can be paused – meaning no long-term commitments to a specific capacity. This pausing capability is critical for small ISVs that don’t yet have the revenue stream to support monthly commitments, and it addressed one of my largest concerns over moving Power BI Embedded over to the Premium model. Power BI Embedded is purchased through Microsoft Azure. Additionally, Power BI Embedded can scale up and down as needed to accommodate the requirements of the ISV business model as the vendor’s application grows.

Running the entry level A1 capacity for a full month equates to approximately $750/month, so while the capacity of the Power BI Embedded A1 SKU is equivalent to the Power BI Premium EM SKU, ISVs pay a slightly higher effective monthly price for the flexibility mentioned above.

There are 6 sizes of Power BI Embedded available, each capacity mapping to an existing Power BI Premium capacity so ISVs can grow their business as needed. Pricing starts at about $1/hour:

Name Virtual cores Memory (GB) Peak renders/hour Cost/hour
A1 1 3 300 ~$1
A2 2 5 600 ~$2
A3 4 10 1,200 ~$4
A4 8 25 2,400 ~$8
A5 16 50 4,800 ~$16
A6 32 100 9,600 ~$32

Power BI Premium EM SKUs

The EM SKU (EM is for embedding – NOT Embedded) covers off everything contained in the Power BI Embedded A SKU, but also offers the ability to share Power BI reports within an organization through content embedding. Currently, this can be accomplished through the use of the SharePoint Power BI web part for modern pages, or the through tabs using Microsoft Teams.

There are three EM SKUs, and while the largest, EM3, can be purchased through Office 365 monthly, the smaller 2 (EM1 and EM2) must be purchased through Volume Licensing. Volume licensing represents an annual commitment, and may be an incentive for ISVs to remain on the A SKU even if they are not pausing their service. EM SKUs cannot be paused – a month is the smallest available billing unit. Additionally, scaling on EM SKUs requires that you retain your monthly or annual commitment to the initial SKU purchased until the end of the contract term.

Details on the EM SKUs are below:

Name Virtual cores Memory (GB) Peak renders/hr Cost
EM1 1 3 1-300 $625/mo
EM2 2 5 301-600 $1,245/mo
EM3 4 10 601-1,200 $2,495/mo

Power BI Premium P SKUs

The P SKU (P is for Premium, but it helps to think of it as “Power BI Service”) is the “all in” version of Power BI licensed through capacity. It offers everything that is available with Power BI, which includes everything available in the A and EM SKUs. It also offers the ability to share Power BI assets in the Power BI service through apps, or if personal workspaces are in a Premium capacity, through dashboard sharing.

The entry point of the P SKU is significantly higher than EM as well, but you’re getting a business application vs a set of APIs. It also comes with significantly more resources attached to it. For example, P1 comes with 8 virtual cores and 25 GB of RAM, whereas the largest EM offering is EM3, with 4 cores and 10 GB RAM.

All the P SKUs can be purchased through the Office 365 administration center, and can be billed monthly. Details are below:

Name Virtual cores Memory (GB) Peak renders/hr Cost
P1 8 25 1-300 $4,995/mo
P2 16 50 301-600 $9,995/mo
P3 32 100 601-1,200 $19,995/mo

What to use when

Sharing capabilities:

PBI Embedded A PBI Premium EM PBI Premium P
Embed PBI Reports in your own application Embed PBI Reports in your own application Embed PBI Reports in your own application
  Embed PBI Reports in SaaS applications (SharePoint, Teams) Embed PBI Reports in SaaS applications (SharePoint, Teams)
  Share Power Reports, dashboards and datasets through Power BI Apps (workspaces)
 Ad hoc dashboard sharing from personal workspaces

With the addition of the Power BI Embedded capacity based SKUs, many of the concerns around Premium pricing have been addressed. I would still like to see all EM SKUs available monthly, and to see a “P0” premium SKU, but it’s fairly clear as to which scenarios call out for which licenses.

An ISV that is embarking on the use of Power BI embedded will at the very least need a Power BI Pro license. When development gets to the point where sharing with a team is necessary, a Power BI Embedded A SKU can be purchased from Azure. Once 24/7 availability is required, the ISV may wish to switch to an Premium EM capacity. An ISV should never require a P SKU unless capacity demands it, or they have additional requirements.

An organization that has a few data analysts or Power Users that need to share reports with a broader audience would likely be well served with one of the EM SKUs. This scenario assumes that the organization is also using SharePoint Online, Microsoft Teams, or both. This approach will allow the power users (who will require a Pro license as well) to embed Power BI content within a SharePoint page or a Microsoft Teams tab where it can be accessed by users without a Pro license. This organization would need to include more than 63 users accessing the reports to be financially viable.

Finally, larger organizations with a significant investment in Power BI, or organizations that don’t currently utilize SharePoint Online or Microsoft Teams would benefit from a Premium P capacity. With this, the Power BI interface could be utilized by end users to access shared content without a Pro license. Given it’s monthly cost, compared to the monthly cost of Pro, the organization would need to have at least 500 active report consumers for this approach to practically considered.

SharePoint and the New SSRS/PBIRS Native Mode Report Viewer Web Part

When SQL Server 2016 was released, I wrote a post that covered how to integrate SharePoint 2016 with SQL Server Reporting Services (SSRS) in native mode. I wrote that post because although SSRS was still available in SharePoint Integrated Mode, many of the new features were only in Native mode. It also wasn’t difficult to surmise that Integrated mode had a limited lifespan at that point, a fact that was confirmed in November 2016.

As my integration article pointed out, one of the glaring problems integrating Native mode with SharePoint was that the Native Mode web part had significantly less capability than the one that was available with Integrated mode, not to mention the fact that it was deprecated. Parameter support was first and foremost among those missing features. Organizations that had incorporated SSRS reports into their SharePoint based dashboards couldn’t just move to Native Mode, and those dashboards relied heavily on the ability to pass parameter values to the SSRS reports through the web part. SSRS did make it easier to embed reports into pages without a web part through the rs:Embed URL directive, but there was no real way to make that dynamic.

The introduction of Power BI Report Server (PBIRS), and its ability to render Power BI reports also left the SharePoint dashboard folks without a solution. Although PBIRS is a superset of SSRS, it is only available in Native Mode, in fact, there’s no longer any need to mention modes. SharePoint dashboards that used SSRS report components were stuck at the 2016 version.

Until now.

Today, Microsoft unveiled the new, fully capable SSRS/PBIRS Report Viewer web part for SharePoint.

Integrated Mode Native Mode

“Meet the new boss, same as the old boss” – Pete Townshend

The web part allows paginated reports from either SSRS in Native mode, or Power BI Report Server to be embedded into a SharePoint page. Essentially, it brings all the capabilities of the integrated mode web part to the native mode web part. Organizations that have bet on SSRS running in Integrated mode can now seamlessly move their reports to SSRS Native mode, or to Power BI Report Server. Let’s have a quick look at some of the details.

Parameter and view support

All the options that we’ve come to expect from the integrated mode web part are here in the new web part. Toolbar options can be controlled at a fine level and web parts can be connected to pass in parameter values. In fact, as seen above, the only difference between the two modes now is the report location option.

C2WTS and Kerberos required… unless

With Integrated mode, Kerberos constrained delegation (KCD) was only required if you needed the user’s identity passed back to the data source. This was because Integrated mode and SharePoint itself shared the same access mechanism. Native mode and PBIRS have their own membership providers, and this new (server side) web part needs to connect to the report server itself to authenticate the user. This is an additional “hop” and therefore requires Kerberos constrained delegation. This only gets the user as far as the report server itself. To get the user’s identity further downstream, KCD will also need to be set up between the report server and data source(s).

SharePoint 2016 in most cases uses claims authentication, and SSRS/PBIRS does not. This also means that the Claims to Windows Token Service (C2WTS) must also be running in your SharePoint environment. This allows the user’s NTLM identity to be extracted and sent via KCD to the SSRS/PBIRS server.

There is one case where KCD is not required, and that is when SSRS is running on a machine in the SharePoint farm along with C2WTS. In a small environment, this may be suitable, but if scaling is a factor, you may need to crack open your Kerberos books.

Paginated reports only

Even though SSRS supports the new RSMobile report format, and PBIRS also now supports both Interactive (Power BI) and analytical (Excel) reports, this web part is only built to render paginated reports. Up until 2016, paginated was the only report type supported by SSRS, so this will not be a problem for those looking to move forward. However, for those people that are looking to embed these other formats in SharePoint on premises, there are other options.

Both Power BI and mobile reports can be embedded into a SharePoint page using the script editor web part alongside the rs:Embed=true URL directive. Parameters can be passed to mobile reports using this technique, and text filters can be passed to interactive reports as well. Excel reports can be embedded with the Excel Services web part, the way that they always have which itself allows for passing slicer values. However, for this to work, the Excel files need to be stored in SharePoint, not PBIRS.

On-premises only

The new web part deploys to the SharePoint farm as a WSP solution file, which means that this is an on-premises solution only. Given that SSRS/PBIRS are also on-premises products, this shouldn’t pose much of a problem. It IS possible to ebbed on prem reports into SharePoint Online pages with the script editor web part for classic pages, and the embed web part for modern pages. A complete summary of report/SharePoint edition embed options can be seen below.

Report type

SharePoint Online modern page

SharePoint Online classic page

SharePoint on-premises

PBIX on Power BI Service

Power BI WP




Modern embed content WP

Script editor WP

Script editor WP

RDL on PBIRS or SSRS Native

Modern embed content WP

Script editor WP

Report Viewer WP NEW!

RDL on SSRS Integrated mode

Modern embed content WP

Script editor WP**


XLSX (stored in SharePoint)


Excel Services WP

Excel Services WP

RSMobile on SSRS/PBIRS (Native)

Modern embed content WP

Script editor WP**

Script editor WP

*    NOT recommended

**     Requires adding sever to HTML Field Security options in site collection settings

In summary, the new native mode web part will be very welcome for those organizations that have been feeling stranded by the deprecation of SharePoint Integrated mode. The very fact that it is now available also underscores that SharePoint still plays an important role in the Microsoft Business Intelligence ecosystem. It may no longer be a prerequisite, but it still adds value, and those are both very good things.

Which Premium SKU is Needed to embed Power BI Reports in SharePoint and Microsoft Teams

A short time ago, I posted an article explaining the difference between a Power BI Pro license, and Power BI Premium capacity, and the fact that you’ll at least need one or the other in order to share a Power BI report on a SharePoint page via the Power BI web part. Although that article didn’t mention it, the same requirement is also true for embedding a report in a Microsoft Teams tab.

Power BI Report embedded in a Microsoft Teams tab

Power BI Report embedded in a SharePoint Page

Since there are two major SKU types for Power BI premium, and that there was (and is) a fair amount of confusion around this area, I also published another article attempting to clear up the confusion. While this article was based on all the information publicly available at the time, new information has pointed out that it is incorrect.

The two major SKU types are P and EM, with P standing for Premium and EM for Embedded. This matters significantly because the two SKU types have significantly different entry points and therefore costs.

The P SKU was the only one introduced when Premium was originally announced. It gives organizations the ability to place Power BI assets in a premium capacity container (a Power BI “app”), and once this is done, anyone can consume these assets whether or not they have a license.

Subsequent to this, an additional SK (EM) was introduced to address Power BI Embedded. Power BI embedded allows an ISV to use Power BI to add reports to their own applications. In this scenario, the reports run from the ISV’s tenant. Originally the assets were housed in Azure, but with the availability of Premium capacity, the decision was made to shift Power BI Embedded to use this new model. Given that the requirements of an ISV are not the same as a general organization, this new  SKU was introduced. The EM SKU comes with a significantly lower entry point and cost, but also with significant restrictions. This is where the confusion sets in.

The wording around the restrictions on the EM SKU indicated that it could not be used for the SharePoint web part, and that a P SKU, or a Pro license would be required for that use case. This is where my earlier article is incorrect. I have since had conversations with the product team, and have been informed in no uncertain terms that the EM SKU CAN be used for both SharePoint web part, and Teams tab embedding of Power BI reports.

This is a very significant difference. An organization that is using Power BI casually, but has a few reports that they want to share with a broad audience was looking at a cost of almost $5,000 per month to do this. Given that the cost of a Pro license is $10/user/month, this meant that the organization needed to have at least 500 frequent report consumers before Premium was even worth considering. Also given the fact that the embedding features available in both SharePoint and Teams require that Pro or Premium SKU, this could be a real disincentive to its use. However, given that the EM SKU start at approximately $650/month for the entire organization, this becomes much more approachable, and it lowers the bar to entry significantly. This should result in significantly greater adoption of these Power BI embedding features, and consequently, of Power BI as a whole.

To be clear, there are still restrictions around the EM SKU. You cannot share Power BI apps with this SKU, but you CAN use it to embed reports in both SharePoint and Microsoft Teams.

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


P1 8 4 cores, 25 GB RAM 4 cores


P2 16 8 cores, 50 GB RAM 8 cores


P3 32 16 cores, 100 GB RAM 16 cores


EM1 1 0.5 cores, 3 GB RAM 0.5 cores


EM2 2 1 core, 5 GB RAM 1 core


EM3 4 2 cores, 10 GB RAM 2 cores


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.

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.