Four Different Ways to Find Your Power BI Desktop Local Port Number

Power BI Desktop Local Port

About two years ago I wrote a blog post on how to connect to a Power BI Desktop model from different tools like SSMS, Excel, and SQL Server Profiler. A big chunk of that blog post was about different ways of finding Power BI Desktop local port. Having the port number is crucial if you want to connect to a Power BI Desktop model from any sort of tool for different purposes like monitoring in SQL Server Profiler or analysing the model in Excel. I’ve been asked several times here and there about different reasons people need to find the Power BI Desktop local port number, so I decided to dedicate a post to the Power BI Desktop local port number.

When you run Power BI Desktop, it runs a local instance of SSAS Tabular model in the background and it assigns a random port number to that local instance. Therefore, if you want to connect to the model to analyse it in Excel you need to know that port number. There are several ways to achieve the port number and this post will cover most of them.

As you may know, Power BI Desktop is now available as a Windows App that can be installed from Windows Store. In general, the main difference between the App and the downloaded edition from the Microsoft website is that you will get a notification whenever a newer version is available to download. Then you have to manually download and install the newer version on your machine, but, the App will be updated automatically. However, some other differences are out of the scope of this article. There is just one difference that is relevant to this article which is that Power BI Desktop creates its temporary folders in a different location than the Power BI Desktop App does.

The methods described in this post work for both the downloaded edition and the Store edition.

Different Methods to Find Power BI Desktop Local Port

· Using DAX Studio

· Tabular Editor

· Power BI Desktop Temporary Location

· Command Line (CMD)

The reason that I explain different methods is that not all methods are doable in all environments. You may work at a customer site that doesn’t allow you to install new software like DAX Studio on their machines. But you always have access on Power BI Desktop temporary files.

Continue reading “Four Different Ways to Find Your Power BI Desktop Local Port Number”

Demystifying “DirectQuery” and “Connect Live”

The terms “DirectQuery” and “Connect Live” are somehow confusing. I saw lots of people are using both terminologies as alternatives. But, the context of “DirectQuery” and “Connect Live” are very different indeed. Therefore, if use a a terminology when we’re talking about a different context then the whole situation might get quite confusing. in this post I try to explain the differences and make it more clear to prevent using a wrong terminology and make sure everyone is on the same page when we’re referring to “DirectQuery” or “Connect Live”.

When we use the “DirectQuery” terminology we are actually talking about connecting from Power BI Desktop instance to an RDBMS type of data source like SQL Server DB or Oracle DB.

There are two types of data connections when we’re connecting to RDBMS like SQL Server or Oracle DB from Power BI Desktop:

  • Import Data: which literally loads data into the underlying model to make it available in memory
  • DirectQuery: which doesn’t load data into model. Instead, it runs multiple concurrent queries on the RDBMS side (data source side) and gets the results. This is good to support real-time data processing.

Note: The same principal applies to SSAS Tabular.

DirectQuery/Data Import Mode in Power BI Desktop

On the other hand, when talk about “Connect Live”, we are referring to the data connection type from a reporting tool like Power BI Desktop OR Excel to an instance of SSAS, either SSAS Multidimensional or SSAS Tabular.

Continue reading “Demystifying “DirectQuery” and “Connect Live””

On-premises Data Gateway for Azure Analysis Services

On-prem Data Gateway for Azure AS, How it works DemoFrom April 2017 onward we can use On-premises Data Gateway for Azure Analysis Services. This means  you can connect your Tabular Models hosted in Azure Analysis Services to your on-premises data sources through On-premises Data Gateway. In this post you learn how to setup and configure the On-premises Data Gateway as well as how to configure Azure Analysis Services to connect to the on-premises database(s) via the gateway.

Requirements/Assumptions

  • You have an Azure subscription
  • You already have an up and running instance of Azure Analysis Services (AAS)
  • You already installed and configured the latest version of On-premises Data Gateway
  • Your instance of Azure Analysis Services, your instance of Power BI Service and your On-premises Data Gateway are all in the same “Region” (Check Prerequisites section below for more details)
  • This post covers the most common scenario which doesn’t involve Kerberos, Proxy Server, OKTA etc…

Reading: If you are not that familiar with On-premises Data Gateway then I encourage you to read this and for more in-depth read this article. You may also watch this video from Adam Saxton discussing On-premises Data Gateway.

Prerequisites

As stated in the “Requirements” section, it is important to check if your instances of Azure Analysis Services, Power BI Service and On-premises Data Gateway located in the same “Region”.

The reasons behind that are:

  • Your On-premises Data Gateway MUST be installed in the same Region as your Power BI Service sits in. Otherwise your Power BI cannot see the gateway, therefore, you’re unable to schedule automatic data refresh in Power BI Service
  • To get the best performance and more reliability, you have to create On-premises Data Gateway Resource in Azure side in the same region as your Azure Analysis Services lives in

But, in some cases people created their Power BI account a long time ago and perhaps they didn’t set the right region for their Power BI Service to sit in. Now, they need to create an instance of Azure Analysis Services, but, due to their organisation privacy and security, they don’t want to (or perhaps not allowed to) create the instance of Azure Analysis Services in the region that their Power BI tenant sits in. So they would prefer to create the Azure Analysis Services in another region. In that case, it is recommended to install a new instance of On-premises Data Gateway in a separate server and change the “Gateway Region” during the installation.

To check the “Region” of your instances follow the steps below:

Power BI Service Region:

  • Login to your Power BI Service
  • Click the question mark on top right side of the page
  • Click “About Power BI”

Continue reading “On-premises Data Gateway for Azure Analysis Services”

Azure Data Lake, Azure Analysis Services, Power BI and How They Relate

Loading Data From On-prem SQL Server to Azure Data Lake Store and Data Visualisation in Power BI

I recently spoke in Tampa Dev Azure Meeting in a webinar form on 31st Jan 2018. We received interesting questions during the presentation. My aim was to introduce basic concepts of Big Data, Azure Data Lake, Azure Data Lake Store (ADLS), Azure Data Factory (ADF)  and Power BI.

I would like to thank Tampa Dev organisers and all attendees for giving the opportunity to speak in this session.

In this session you learn basic concepts of:

  • Big Data
  • Azure Data Lake
  • Azure Data Lake Store (ADLS)
  • Azure Data Factory (ADF)
  • Azure Analysis Services (AAS)
  • Power BI
  • And how they relate

Session recording:

Continue reading “Azure Data Lake, Azure Analysis Services, Power BI and How They Relate”