We have recently managed an issue which resolution may help to most of you. For so, we would to share it here. It is about data source connection in Power BI Desktop application and in our case we were using OData Feed connection. If you get the following error "The user was not authorized", the first thing you must do is check if the credentials you are using are correct. However, there are sometimes that you have checked that credentials are correct, that  it had worked for past connections on the same desktop application and you get stuck doing the connection again and again without been able to connect.

On those cases, we detected that Power BI is trying to reuse an old connection stored on the application cache. Try to delete the cache and the old data source connections related. You can do it, going to "File --> Options and Settings" in the following way: 

1. To delete cached files go to "File --> Options and Settings --> Options --> Data Load":

2. To delete the old data source connection related, go to "File --> Options and Settings --> Data Source Settings" select the related connection and click on delete:

You can also edit the connection to check if the information in the data source matches with the one you are trying.

Hope it helps!

In this series of post, I am going to show you the most common (and not so common) problems we can find when creating a new web site and how to troubleshoot them.

The access denied error when deploying a web site in Master Data Services, is one of the most classical issues, and probably the first one you are going to deal with if you are new to MDS.

First of all, let's see how to enable MDS logs. They will help us to identify what's going on:

In the path program_files\Microsoft SQL Server\<version>\Master Data Services\WebApplication edit the web config.

1.- Uncomment the section below by removing the yellow portion:

<!-- <add name="LogFileListener" type="System.Diagnostics.TextWriterTraceListener" initializeData="c:\temp\MdsTrace.log" traceOutputOptions="DateTime" /> -->

2.- In the initializeData parameter, type the path and the name of the log file that will be created.

3.- In the system.diagnostics section. Change the switchValue to "All".

<source name="MDS" switchType="System.Diagnostics.SourceSwitch" switchValue="All">

4.- Save the changes and restart the apppool. If you cannot restart it, the web application will reload configuration settings in a couple of minutes, so let's wait for the log file to appear in the folder.

5.-Reproduce the problem

6.- Stop the application pool and retrieve the log file (may need to wait for writing to finish; there could be a delay after stopping the app pool)

7.- Open the web.config file with a text editor and change the switchValue back to “Off” or the prior value.

Once the logs are enabled let's see the first case.

When accessing the MDS website, we get a blank page containing a message "Access is Denied":

Access is denied can be caused by different reasons, today I want to show you the most typical.

In the logs we see the following error message:

MDS Error: 0 : A Windows identity could not be obtained from the current Windows principal or the user property is null.

DateTime=2015-12-17T11:14:23.2462367Z

MDS Stop: 2 : RequestContext.InitializeCurrentUser

DateTime=2015-12-17T11:14:23.2472524Z

MDS Error: 0 : LogError : The user does not have access to the application.

DateTime=2015-12-17T11:14:23.2482526Z

That happens when anonymous authentication is enabled in the MDS web site.

Disabling Anonymous authentication will solve the issue. Only Windows authentication must be enabled:

Usually the application pool restart is no required, so you can try again after a couple of minutes.

Some users are experimenting authentication issues when using Project Online as a data source. This authentication issue causes an error just when importing data, but the connection is performed properly.

Let’s suppose the scenario below:

In Power BI Desktop click on Get Data > OData feed and type the url to connect to your Project Online tenant

When you click on OK, all the data is showed, that means the connection is performed properly. However when you click on Load the data starts to be loaded into the data model and you finally get an authentication error: “The user was not authorized”:

If you click on Connect and introduce again your Office 365 credentials, the error persists and you get again the same error.

Let me share with you a workaround to solve this issue:

1. Connect to the OData source as you usually do and type your credentials

2. Select the table you want to import and click Edit instead of load

3. The query editor will be opened. Click on Keep Rows > Keep Top Rows

4. Then introduce the number of rows we want to keep. For this workaround, we are going to type a number much bigger than the total of rows that the table has. I would suggest typing for example “5000” and click OK.

5. Then, click Close & Apply and the data will be loaded to the data model.

As a consequence of this problem, if you try to connect to the Project Online content pack service in app.powerbi.com you will also get a error importing data. In this case, we cannot modify the transformations applied to the dataset so we recommend creating the report through Power BI desktop and apply the workaround above.

If you have recently acquired a license for Microsoft Power BI, you have probably experimented the issue below when trying to access Power BI Admin Center:

What does this error mean? Are we missing something?

Power BI Admin center is part of the old version, Power BI for Office 365.

In the new version of Power BI,  Power BI Admin Center doesn’t exist anymore, so each user can manage their own dashboards, reports and data sources from the Power BI web site (https://app.powerbi.com). This new version has a self-service approach, we don’t have the concept of Administrator we had in the previous version, each user is an administrator of his data.  In that way the permissions are managed at data source level.

How can we check what kind of license we have?

The licenses for the old version were called “Microsoft Power BI for Office 365” as the image below shows:

In the new version the license is Power BI (free) or Power BI Pro:

Power BI for Office 365, licenses and experience will be deprecated beginning December 31, 2015. That experience will be no more available when this change is implemented, so we strongly recommend migrating to the new experience as soon as possible.

To sum up, if you have a license for Microsoft Power BI or Power BI Pro, don’t worry about this message, Power BI Admin Center is no longer required, you just need to access Power BI web app. And if you have an old license we invite you to start using the new version for free https://powerbi.microsoft.com/en-us/

First of all, is your data source within the list of supported data sources? Let's check on this link: https://support.office.com/en-us/article/Supported-Data-Sources-and-Data-Types-cb69a30a-2225-451f-a9d0-59d24419782e

If so, the problem could be in the Power Query transformation.

Following expressions are not yet supported:

• #literals
• Web
• SAP BusinessObjects
• Active Directory
• HDFS
• Facebook
• Exchange
• Current Excel workbook

For literal expressions, we can replace them with a simple variable. For example, if we have the sentence below:

#"My Literal" = Table.RemoveColumns(MyTable,{"PartitionKey", "Timestamp", "AuthKey"})

#"My Literal" must be replaced with a variable as follows:

MyLiteral= Table.RemoveColumns(MyTable,{"PartitionKey", "Timestamp", "AuthKey"})

Regarding the other expressions, they must be removed from the Power Query string in order to have a supported Power Query connection in Power BI.

More Info available here.

In Power BI, when we want to create or modify a scheduled data refresh, we usually find the "Save and refresh report" and "Save Settings" buttons disabled:

To enable these buttons you have to click on test connection in order to check that everything is fine in the data source. If this check is successful, both buttons will be enabled.

On the other hand, if Power BI finds any problem when testing the connection, the buttons will remain disabled and we should put focus on finding the reason why the datasource test is not working as expected.

That's the usual behavior, however, we have seen several times the error below when testing the connection:

A connection could not be made to the data source with the DataSourceID of '檰棼翷', Name of '檰棼翷'. Correlation ID: …

If you are experimenting this error, don't worry and continue, this warning message does not block the process . The save buttons are enabled, so set the preferences for the data refresh and click on save button.

Then, you can check on the history section that the refresh (scheduled or on demand) has been done successfully.

If you have a Web Forms application containing a Report Viewer control, and you want to specify the credentials used to access your report server, you may have noticed that it is not as easy as you thought.

The property NetworkCredentials stores the user and password that we want use to execute the report but unfortunately it is read only and there is not a set method to change that value.

Does that mean we only can execute the report by using the credentials of the current Windows user? Don't panic, there is an alternative way to do it.

For this case, I have created a very simple application called MyReportViewerWebAPP containing a ReportViewer control. Here is the code:

using Microsoft.Reporting.WebForms;

using System;

using System.Collections.Generic;

using System.Configuration;

using System.Linq;

using System.Net;

using System.Security.Principal;

using System.Web;

using System.Web.UI;

using System.Web.UI.WebControls;

namespace MyReportViewerWebAPP{

    publicpartialclass_Default : System.Web.UI.Page

    {

        protectedvoid Page_Init(object sender, EventArgs e)

        {

            ReportViewer1.ServerReport.ReportServerCredentials =

                newMyReportServerCredentials();

        }

    }

    [Serializable]

    publicsealedclassMyReportServerCredentials :

        IReportServerCredentials

    {

        publicWindowsIdentity ImpersonationUser

        {

            get

            {

                // Use the default Windows user.  Credentials will be

                // provided by the NetworkCredentials property.

                returnnull;

            }

        }

        publicICredentials NetworkCredentials

        {

            get

            {

                // User name

                string userName = "MyUser";

                // Password

                string password = "MyPassword";

                // Domain

                string domain = "MyDomain";

                returnnewNetworkCredential(userName, password, domain);

            }

        }

        publicbool GetFormsCredentials(outCookie authCookie,

                    outstring userName, outstring password,

                    outstring authority)

        {

            authCookie = null;

            userName = null;

            password = null;

            authority = null;

            // Not using form credentials

            returnfalse;

        }

    }

}

This is the easiest way, however, we can do a most sofisticated and secured code.

If we read the user information from the Web.config file instead of storing it, the credentials will not be stored in session, reducing the vulnerable surface area to the Web.config file, which can be secured with an ACL:

public ICredentials NetworkCredentials
    {
        get
        {
// User name
            string userName =
                ConfigurationManager.AppSettings
                    ["MyReportViewerUser"];

if (string.IsNullOrEmpty(userName))
                thrownew Exception(
                    "Missing user name from web.config file");

// Password
            string password =
                ConfigurationManager.AppSettings
                    ["MyReportViewerPassword"];

if (string.IsNullOrEmpty(password))
                thrownew Exception(
                    "Missing password from web.config file");

// Domain
            string domain =
                ConfigurationManager.AppSettings
                    ["MyReportViewerDomain"];

if (string.IsNullOrEmpty(domain))
                thrownew Exception(
                    "Missing domain from web.config file");

returnnew NetworkCredential(userName, password, domain);
        }
    }

Source: https://msdn.microsoft.com/es-es/library/microsoft.reporting.webforms.ireportservercredentials(v=vs.90).aspx

When you access to Report Manager using the balancer virtual name (https://<virtualname>/Reports) , you can intermittently get HTTP 401 error message when you do any action that requires connection from one node to the other
RS node (as run a report with a data source located in the other node or simply when the Report Manager tries to connect to the Report Server Web Service hosted on the other node).

This HTTP 401 error is caused when the request handled by one Report Manager node is back to the balancer and then is handled by the other SSRS node. In this case, the user credentials are not passed to the second node if you are using NTLM authentication. To solve this issue follow the instructions below to ensure that the session established on a SSRS node doesn’t back to the balancer but persists on the same node.

To solve this problem and avoid a double balancing issue:

Open the file “hosts” on both SSRS servers and map the local node IPaddress with the virtual name of the balancer on each server. Follow these steps:

1.      On each SSRS server open  C:\Windows\System32\Drivers\etc\hosts.

2.      If the following entries are not in there please add them:

IPaddress(localnode)                     virtualbalancername

IPaddress(localnode)                     virtualbalancername.domain

 NOTE:

Other solution for this problem is to configure Kerberos authentication for SSRS.

Although the main steps to configure Reporting Services are on the msdn article below, sometimes you can find additional errors trying to access Report Manager or Report Server URLs a load balancer deployment. You will find in this blog some additional steps that will help you.

               Configure a Report Server on a Network Load Balancing Cluster

            https://technet.microsoft.com/en-us/library/cc281307.aspx

1. Changes on the rsreportserver.config file (This file is located by default at the local report server path: C:\Program Files\Microsoft SQL Server\MSRSx.InstanceName\Reporting Services\ReportServer).

                                  1.      Find the ReportServerURL tag and add the following configuration:                    

                                                 <ReportServerUrl> https://nodename/ReportServer </ReportServerUrl>

                                           For more information about this step clic here.

                                  2.      Find the URLRoot tag and add the following:

                                                <URLRoot> https://balancername.domain/ReportServer</ReportServerUrl>

                                           *If you have Sharepoint Integration mode in SSRS please add here the URL for the Sharepoint Site.

                                 3.      Add the following tag:

                                                  <Hostname>balancervirtualname.domain</Hostname>

                                          In the following location:                       
                                                   <Service>
                            
                                                   <Hostname>virtual_server.domain</Hostname>                                 
                           
                                                   <IsSchedulingService>True</IsSchedulingService>                                
                           
                                                   <IsNotificationService>True</IsNotificationService>                          
                                                     […]

2. Open the web.config file on each Report Manager (located at: C:\Program Files\Microsoft SQL Server\MSRSx.InstanceName\Reporting Services\ReportManager). You will see a section <system.web> and inside this section a tag called <machineKey>

                            1.      We need to have the same machinekey on both SSRS servers (that means on the web.config files of Report Manager on each server).

                            2.      If you don’t have the same machinekey, please generate one and add it to both files. You can create one using this tool: https://aspnetresources.com/tools/machineKey

3. Open the file “hosts” on both SSRS servers and map the local node IPaddress with the virtual name of the balancer on each server. Follow these steps:

                           1.      On each SSRS server open  C:\Windows\System32\Drivers\etc\hosts.

                           2.      If the following entries are not in there please add them:

                                                 IPaddress(localnode)       virtualbalancername

                                                 IPaddress(localnode)       virtualbalancername.domain

  Find more information about this point here.

4. Check that either LoopbackCheck is disabled on all SSRS servers belonging to the current scale-out or the balancer virtual name is specified as hostname mapped to the local loopack address.:

https://support.microsoft.com/kb/896861 

"The request failed with HTTP Status 401"

However, the Report Server URL works properly.

This is solved by configuring the ReportServerURL setting on the rsreportserver.config file.

            On each node you must specify the local report server URL:

            <ReportServerUrl> https://nodename/ReportServer </ReportServerUrl>

This tag is used when you want your Report Manager connects to a specific Report Server Web Service. You need to set it when you want the Report Manager connects to a Report Server hosted on another instance
or on a remote computer.

This value is empty by default or it is not included on the rsreportserver.config (depends on the version) and you need to add it.

In a load balancing deployment, if this value doesn’t exist or it is not set, the Report Manager will point to the Report Server URL using the virtual balancer name (because you set it on the <Hostname> tag on the configuration file when you configured your SSRS load balancer deployment.) In this case, the request from the Report Manager to the Report Server backs to the balancer and can ends up on the report server hosted on the other node. If Kerberos authentication is not configured, the credentials could not be passed and you will receive the HTTP 401 error.

If we specified the <ReportServerUrl> to point to the local report server URL, the Report Manager that is handling the request from the balancer will send the request to the Report Server hosted on the same node as it is. In this case as the request stays on the same node, no authentication issues are handled.