Tag Archives: Power BI

Get Power BI Desktop from the Microsoft Store

If you’re a Power BI Desktop user, you are likely familiar with the monthly update cadence. Once per month, a new Power BI Desktop is released, and normally it contains at least one new feature that you WILL want to use. In case you miss it, a little indicator will light up in the bottom right hand corner that will prompt you to update. Of course, you normally don’t notice this until you’re in the middle of designing something, and it’s never a good time.

Then you do click on the prompt, you’re take to a web page from which to download PBI Desktop. Doing so can take a few minutes (it’s relatively large), and when it starts, more often than not, you’ve forgotten to exit the current PBI Desktop. Once you do, you can run the installer and then you’re up to date. For 30 days. While I think that most of us welcome the new features, this update process itself is cumbersome. Thankfully, the availability of Power BI Desktop in the Microsoft store removes this pain.

Power BI Desktop – Microsoft Store Edition

Getting Power BI Desktop from the Windows store allows you to have it automatically updated in the background whenever new versions are available, just like any other app in the store. To be sure, it is not a separate “Microsoft Store Edition” of the product, but precisely the same product in a Windows Centennial (presumably) wrapper.

Installing Power BI Desktop from the Store

Before installing the store version of Power BI Desktop, it’s a good idea to uninstall the older version. This is not required, and the two can operate side by side, but this will most likely be confusing. The non-store version is uninstalled by opening “Programs and Features” in Control Panel and uninstalling from there. As an aside, the store version will not appear in this list – like other apps, it will only appear in the start menu, and if necessary can be uninstalled by right-clicking on the tile.

To install PBI Desktop, open the store and search for Power BI. At the moment, PBI Desktop does not appear in the search dropdown, but the Power BI app does. The app is not what you’re looking for here. Execute the search and you should see two results, Microsoft Power BI Desktop, and Microsoft Power BI. The icons for the two are very similar (but not identical!). Be sure that you select he one with “Desktop”.

Installing Power BI Desktop from the Microsoft Store

The power BI app is the Windows 10 app for Power BI and is designed for a mobile experience. It is like the versions found on iOS and Android. Selecting the Desktop tile should download and install Power BI Desktop.

Copy Your Saved Settings

One of the downsides of this new isolated model is that all the stored credentials, cached data and saved settings from your prior versions of Power BI desktop do not come forward into the store version. However, the good news is that you can bring them forward manually. To do so, navigate to your AppData folder for Power BI, likely at:

C:\Users\[YourUserName]\AppData\Local\Microsoft\Power BI Desktop

Copy everything in this folder (including subfolders) and copy it into:

C:\Users\[YourUserName]\AppData\Local\Packages\Microsoft.MicrosoftPowerBIDesktop_8wekyb3d8bbwe\LocalCache\Local\Microsoft\Power BI Desktop Store App\

The latter is simply the isolated store app version of the former. This content can be relatively large, so it’s a good idea to delete it from the source once finished. Uninstalling the original application does not clean up this content – in fact in my case, as advised above, I uninstalled it prior to the installation of the store app itself.

Once you’re up and running with the store version, you should never need to worry about manually updating Power BI Desktop again.

Understanding the Power BI Capacity Based SKUs

Power BI licensing has changed again. 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

Anonymous*

Anonymous*

PBIX on PBIRS

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**

SSRS WP

XLSX (stored in SharePoint)

N/A

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.

SQL Server Reporting Services vs Power BI Report Server – What’s the Difference?

Power BI Report Server (PBIRS) was first introduced in May 2017. Based on SQL Server Reporting Services (SSRS), it brings the ability to work with Power BI reports completely on premises in addition to all the other capabilities of SSRS. Given this, it would be reasonable to conclude that PBIRS was the next version of, or a replacement for SSRS, but that is not the case. I have heard people state that SSRS is “going away”, but this is simply not the case. SSRS is still a core part of the Microsoft BI stack. So, what are the differences between the two platforms? The differences boil down to features, licensing, and update cadence.

Features

Early builds of SSRS 2017 (V.Next at the time) contained the ability to render Power BI (Interactive) reports in addition to the “classic” RDL (Paginated) reports that SSRS is well known for and the recently added RSMOBILE (Mobile) report types. However, when PBIRS was introduced, SSRS lost that capability, and from a feature standpoint, it really was the only difference between the two. The recent introduction of the Excel report type (Analytical) to PBIRS has further differentiated the two products.

From a features standpoint, the differences between the two products are straightforward. PBIRS is a superset of SSRS. It contains everything that SSRS has, and it ads the ability to render both Interactive (PBIX) and Analytical (XLSX) reports.

Licensing

Licensing is where things get a little more involved. SSRS was always included on the SQL Server installation media, but with SQL Server 2017, this is no longer the case, it’s a separate download (the RC version of SSRS 2017 is currently available for download here). However, the license for SSRS is still tied to your version of SQL Server. Therefore, if you have a license for Standard mode SQL Server, you will be able to use the Standard mode features of SSRS, Enterprise unlocks the Enterprise features, etc. As of the 2017 version, there is also no longer an Integrated mode of SSRS, it’s Native Mode only.

Power BI Report Server is licensed in one of two ways. Purchasing Power BI Premium capacity gives you a license to run the same number of cores as you have in the capacity. This ONLY applies to Premium P SKUs, not any others such as EM. The other way that it can be licensed is by purchasing SQL Server Enterprise Edition + Software Assurance.

Release cadence

Just as with licensing, the timing of releases of SSRS is also tied to that of SQL Server. Whenever a new version of SQL Server is released, a new version of SSRS will be as well. This is not the case for PBIRS. Since PBIRS is considered a standalone product this makes sense, and the constant pace of change in the Power BI service itself necessitates a more frequent update cadence.

As an example, PBIRS first came into General Availability (GA) in June 2017, and as of this writing (Sept 2017) is already in preview for its next release, whereas SSRS 2017 hasn’t yet gone to GA.

How to choose

The choice between which platform to use will likely be straightforward and likely driven by requirements. If your organization only uses paginated reports on premises, you may find that SSRS is a more cost-effective option. If, on the other hand you have the need to render interactive or analytical reports on premises, or you already have SQL Server Enterprise Edition with Software Assurance, then PBIRS will likely be your best choice. There are no circumstances that I can think of where both products will be advisable, if you have PBIRS, you have everything that SSRS offers and more.

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.