Power BI Desktop Versions Demystified: Part 2, Store vs. Download Version – Key Differences and Use Cases

Power BI Desktop Versions Demystified: Part 2, Store vs. Download Version – Key Differences and Use Cases

In a previous blog post, I explored the differences between Power BI Desktop and Power BI Desktop RS (Report Server). These two versions cater to distinct user needs, cloud-based reporting versus on-premises reporting.

But the story doesn’t end there. Within the regular Power BI Desktop, there are also two flavours:

  1. Power BI Desktop (Store Version)
  2. Power BI Desktop (Download Version)

These flavours, though similar in functionality, offer different features and experiences. In this blog, we’ll examine why these two versions exist, how they differ, and which version might suit your needs and why you might want both.

Why Are There Two Versions?

Microsoft introduced the Microsoft Store Version and the Downloaded Version to provide flexibility for different user scenarios. Each version addresses specific challenges related to updates, deployment, and compatibility.

  • Microsoft Store Version: Simplifies the installation and update process by leveraging the Microsoft Store’s automatic update mechanism.
  • Downloaded Version: Offers manual control over updates and compatibility, allowing users to install and retain specific versions.

Key Differences Between the Two Versions

FeatureMicrosoft Store VersionDownloaded Version
UpdatesAutomatically updated via the Microsoft Store.Manual updates; users must download and install new versions.
InstallationSimplified; just one click from the Microsoft Store.Requires downloading an installer from the Power BI website.
Version ControlAlways the latest version available.Older versions can be retained for compatibility.
IT ManagementIdeal for managed environments (e.g., enterprise devices).Provides flexibility for organisations needing control over updates.
System RequirementsRequires Windows 10 or higher.Compatible with older versions of Windows.
Account DependenciesTied to the Microsoft Store account.Independent of any store account.
Continue reading “Power BI Desktop Versions Demystified: Part 2, Store vs. Download Version – Key Differences and Use Cases”

Power BI Desktop Versions Demystified: Part 1, Power BI Desktop and Power BI Desktop RS

If you are a Power BI power user, you may have wondered: how many versions of Power BI Desktop are there? The quick answer is: it depends!

Depending on your organisation’s preferences, data governance requirements, and the platforms you intend to use for report deployment you may use either Power BI Desktop, the “standard version”, or Power BI Desktop RS (Report Server). Power BI Desktop has variations tailored to meet specific needs, such as cloud-based analytics or on-premises reporting. While many users might only encounter the standard version, there’s another important variant for specialised scenarios.

Power BI Desktop comes in two primary versions:

  1. Power BI Desktop:
    This is the standard version most users rely on. It’s the go-to tool for transforming data, creating semantic models, and building interactive reports. This version is designed to seamlessly integrate with the Power BI Service hosted on Microsoft Fabric, enabling cloud-based sharing, collaboration, and advanced features like Direct LakeAI-driven insights, and more. Regular updates ensure that this version includes the latest features and innovations, such as new Power Query and DAX functions, enhanced visuals, and cutting-edge integrations.
  1. Power BI Desktop RS (Report Server):
    This is a specialised version of Power BI Desktop designed to work exclusively with Power BI Report Server, a locally hosted reporting platform. It is tailored for organisations that prefer to keep their data and reports on-premises due to regulatory, security, or strategic reasons, avoiding reliance on cloud services like the Power BI Service on Microsoft Fabric. Although the two versions look nearly identical in functionality, they serve distinct purposes. Power BI Desktop RS is specifically aligned with the capabilities of Power BI Report Server, supporting features available up to the latest release cycle of the server. For instance, Power BI Desktop RS updates are less frequent; typically released every few months, in line with Power BI Report Server’s update schedule; making it slightly behind the standard version in terms of cutting-edge features. However, it ensures stability and compatibility for on-premises deployments.
Continue reading “Power BI Desktop Versions Demystified: Part 1, Power BI Desktop and Power BI Desktop RS”

Microsoft Fabric: Resolving Capacity Admin Permission Issues in Automate Capacity Scaling with Azure LogicApps

Resolving Capacity Admin Permission Issues in Automate Capacity Scaling with Azure LogicApps

A while back, I published a blogpost explaining how to use Azure LogicApps to automate scaling Microsoft Fabric F capacities under the PAYG (Pay-As-You-Go) licensing option. Some of my followers reported an issue with their Capacity Admin settings when running the LogicApp solution. The issue was that their capacity admins disappeared after they had run the LogicApps to upscale or downscale the capacity. After some investigation, I found out what the problem was. At the same time, some of my other followers suggested a fix which involved hardcoding the admins into the solution. While this would work in some cases, it is not a practical solution in the long run, as the admin settings may evolve over time. This makes the solution hard to maintain and unreliable. Back then, I suggested using the APIs and an HTTP action in a new LogicApps solution. This blog is the continuation of the previous blog and a quick and easy fix that ensures the automation runs smoothly with minimal to no manual work or maintenance afterwards. I have also published a tutorial video on YouTube explaining the process from the beginning (which was already covered in my previous blog, so I do not explain it here again) which you can watch here:

A Reminder of the Previous Solution

I suggest you read my blog about automating Fabric capacity scaling with Azure LogicApps as it provides a step-by-step guide to implement the solution. But if you have already implemented, or you are just after the fix, jump to the next section. The following image shows how the original solution works:

Automate Scaling Microsoft Fabric F Capacities with Azure LogicApps
Automate Scaling Microsoft Fabric F Capacities with Azure LogicApps

Here is a quick explanation of how it works:

  1. The Trigger runs the workflow automatically every hour.
  2. The Read a Resource, which is an Azure Resource Manager operation, reveals information about a resource that, in our implementation, is a Microsoft Fabric Capacity.
  3. A condition to check the Status of the capacity. If the capacity is Paused (the condition is true), then do nothing. This is needed as this method only works when the capacity is Active.
  4. If the capacity is Active (the condition is false), then check the current time to see if it is between 2pm and 4pm. This is the timeframe for which we want to upscale the capacity.
  5. If the condition is True, then upscale the capacity to F8 using another ARM operation: Create or update a resource.
  6. If the condition is False, then set the capacity SKU to F2.

The solution works fine if you do not have any Capacity Admin settings either on Azure Portal or on Admin Portal on Microsoft Fabric. But in many cases, we indeed have capacity admins. Let’s see what the issue is.

The Problem

The issue arises when we add some capacity administrators; that are wiped after running the above solution in its current implementation. The following image shows the Capacity Admin settings on both portals:

Fabric Capacity Admins on Azure Portal and Fabric Admin Portal
Fabric Capacity Admins on Azure Portal and Fabric Admin Portal

The reason if that the Create or update a resource also updates the properties of the resource with the ones we define in LogicApps. Therefore, if we do not add any capacity admins, we literally empty the existing capacity admins. Let’s run the solution again to understand why this is happening. The following image shows my capacity admins are wiped out after running my LogicApp workflow:

Capacity Admins deleted after running LogicApps
Capacity Admins deleted after running LogicApps

The issue is also demonstrated in the tutorial video on YouTube:

Continue reading “Microsoft Fabric: Resolving Capacity Admin Permission Issues in Automate Capacity Scaling with Azure LogicApps”

Microsoft Fabric: Troubleshooting Query Parameters in Published Semantic Models

Microsoft Fabric: Troubleshooting Query Parameters in Published Semantic Models

Power Query is a powerful tool within the Microsoft Fabric environment, enabling users to manage data sources and transform data efficiently. However, a common issue you may face is that after publishing the Semantic Model, the Power Query parameters either do not appear or are greyed out, making them non-editable. In this post and its accompanying YouTube video, I’ll walk you through the steps to diagnose and fix these problems, ensuring that your parameters work as expected in your published semantic models.

Why Do Power Query Parameters Become Unavailable?

There are a few reasons why your Power Query parameters might not appear or be editable after you’ve published your report to Microsoft Fabric. These issues generally relate to either the way the parameters are set up within Power Query in Power BI Desktop or how they interact with the data sources.

Common Cause and Fix

1. Parameter Data Type in Power Query

One of the most common reasons your parameters might be greyed out or non-editable is due to the parameters’ data types defined in Power Query within Power BI Desktop. If your parameters are of type any, then they won’t show up, or they are read-only (greyed out). The fixation is easy:

Continue reading “Microsoft Fabric: Troubleshooting Query Parameters in Published Semantic Models”