Creating a Demo Power BI Data Gateway using an Azure Virtual Machine


PLEASE READ CAREFULLY

Before getting into the topic of this post, I want to clarify that what I am describing here is an UNSUPPORTED configuration.  There are very specific reasons I am setting up my environment in the manner described below, and anyone repeating these steps should understand that they are accepting all responsibility for deviating from standard guidance.

In addition, I want to clarify that these steps apply to the products released in February 2014.  As these products evolve rapidly – one of the great benefits of the cloud – these steps may become quickly out of date.

 NOTE: Gerhard Brueckl has documented another way to implement a very similar demo environment.  Please check out his post here.


I frequently need to setup trial Power BI environments and as part of my demonstration I need to show the OData feed feature of the Power BI Data Gateway in action.  In a standard deployment, the Data Gateway would be installed on a server that is part of a domain which has been federated with Office 365, but as I am implementing a demonstration environment that is not part of a formal domain (and may be working with multiple deployments simultaneously), I need to take a non-standard approach to my setup.

For my deployment, I am using a client system that is part of my corporate domain, a trail Power BI site with which I have no Active Directory federation, and an Azure Virtual Machine running Windows Server 2012 R2 with SQL Server 2012 SP1 which also has no Active Directory affiliations.  To setup the Power BI Data Gateway, I follow the steps outlined here. I use HTTPS with the default port of 8050 and a self-signed certificate created via makecert per these instructions. When executing makecert, I use the short server name so that if the fully qualified name of my Azure VM was myserver.cloudapp.net, I would use myserver as the server name in that step. I then complete the setup of my data source and OData feeds, again using the standard steps.

At this point, the Data Gateway and the data source are fully configured and should appear to be in good working order from within the Power BI Admin Center.  The challenge is now to get my client system to properly communicate with them.  To do this, I do the following:

  1. Login to the Azure VM and record the public IP address.  This is displayed on the desktop background for easy access. Please note, this address is subject to change so that you may need to revisit this and the next step over time.
  2. In the HOSTS file of my local machine (located at C:WindowsSystem32DriversEtc on most Windows systems), add the following, space-delimited entry:

Public.IP.Address servername

In this last step, the server name is the same short server name as used in earlier steps.

With the HOSTS file modified, I can now locate the server used as my data source.  My next step is to install the certificate used to encrypt the HTTPS channel to my client system. To do this, I do the following:

  1. Open Internet Explorer
  2. Navigate to the HTTPS endpoint associated with the OData feeds.  If my server was named myserver, this endpoint would look like this: https://myserver.cloudapp.net:8050.
  3. On the resulting warning page, click the Continue to This Website (Not Recommended) option.
  4. When prompted with a Windows security prompt, click Cancel.  The address bar will now display a Certificate Error.
  5. Click on the Certificate Error message in the address bar to produce a message regarding a Mismatched Address.  On the bottom of that message, click the View Certificates option.
  6. Clicking View Certificates will open a Certificate dialog.  From the General tab of the dialog, click the Install Certificate button to launch the Certificate Import Wizard.
  7. Within the Certificate Import wizard, select Local Machine as the Store Location and click Next.
  8. On the resulting page of the wizard, select the Place All Certificates in the Following Store option and click the Browse button to select the Trusted Root Certification Authorities location. Click OK and Next until the import process is completed.

Now I can launch Power Query, perform an Online Search to locate data sources I’ve exposed as OData feeds via my Power BI Data Gateway, and pull data through those feeds into my workbook. Be sure to remember to sign-in to the Power Query add-in using the login (Organizational Account) associated with your Power BI site.


Comments (4)

  1. Gerhard Brueckl says:

    Hi Bryan,

    i need to setup a very similar environment also for trainings and demos.

    When I modify the hosts-file i get the following error when launching the DataSourceManager via the [Credentials]-button I get the following error:

    "Failed to verify gateway status. Unable to connect to the remote server – You can click "Cancel" to skip editing credential."

    Once I remove the hosts-file entry again I get the old error:

    "Failed to verify gateway status. The remote name could not be resolved: 'myserver' – You can click "Cancel" to skip editing credential."

    everything else is working fine

    – Gateway is registered (web and gw-client)

    – SSMS works from my client to azure vm using SQL authentication

    – …

    the actual problem is that it tries to resolve 'myserver' opposed to 'myserver.cloudapp.net' but this cannot be changed currently. This is also a problem if you have trusted domains, if my client is in "Dom1" / client.dom1.com and the GW is in "Dom2" gw.dom2.com this will also not work as GW cannot be resolved in "Dom1"

    any help on this is highly appreciated!

    -gerhard

  2. Are you modifying the host file on the gateway server or on your local client system?  The host file modification should take place on the client and not the gateway server.  Also, when you configure your data source, you should use fully qualified name of your server.  

  3. I did the modification on the client and also used the FQDN when configuring the datasource so it should have worked theoretically, for some reason it did not in my scenario

    anyway, in the meantime I found a much cleaner solution which I am going to blog about within the next days – I will post the link here as soon as the post is online

    -gerhard