Hi, in TX v20 we are trying to configure XMLA endpoints. We were having issues with using the Service Principle so now using Windows authentication. When we test the connection, this works OK. But when trying to deploy the endpoint, it runs for an infinite amount of time without any error message. We have put the settings on XMLA Endpoint to ‘Read Write’ but still no change.
Also, the workspace is Premium Capacity so I guess the relevant XMLA Endpoint setting in Power BI is like this, correct?
So the ‘Read Write’ setting for Premium Per User is irrelevant?
Page 1 / 1
Hi Kaj,
XMLA endpoint is only supported in the latest version of TimeXtender. Have you tested it there ? Here is a guide.
Hi Syed,
We are not working with the latest version of TX. For v20 there are workarounds when it comes to pushing data to XMLA endpoints, my colleague Andrew described that here.
Would love to hear what you guys think of the issue I described above.
What issues are you having with the Service Principle?
Hi Christian,
At first, a colleague mentioned that we had to install some AAS client libraries. After we did that, we tried connecting with several ‘deployment targets’ and ‘compatibility levels’. But the error remained like this:
The app registration has the right API permissions and in Power BI the following settings are changed:
Service Principles are in a group that is allowed to use the PBI api
XMLA endpoint settings have been set to 'Read Write’.
OK, if I understand correctly then @andrew.gebhard has a workaround which is working for one client and now you are trying to implement the same for another customer and are running into errors, which are believed to be related to the service principle. Perhaps the best approach would be to compare the working solution to the ones you are having issues with (settings, permissions, etc), and document any differences between the two, and try to rectify the issue with the Service principle as opposed to trying to use Windows Authentication
@Christian Hauggaard, I tried connecting to the Power BI workspace with the same Service Principle from TimeXtender that I installed on my local machine (with SQL db on my machine as DWH). In that case, the deploy actually did give me an error:
“Failed to save modifications to the server. Error returned: 'The '3072' locale is not supported. Either the database with the ID of 'ICM' does not exist in the server with the ID of 'autopremiumhostwesteuropexxx-xxx', or the user does not have permissions to access the object.”
This error seems to be related to the endpoint trying to connect to the SQL db on my local laptop, which is not accessible.
What I want to report as bug here is that the deployment in our Azure environment just stalls at 50% for an infinite time. Why don't we get an error there? Shouldn't TX be running into some sort of timeout and report that?
@Christian Hauggaard, I have been doing some extensive tests together with @rory.smith but no result this far. Let me sum up our most important findings:
We tested on my local machine version 38 (same as Andrew's client), but we got the error I posted above
We tested on my local machine version 40 (same as my client is on where deployment gets stuck), same error as above
Rory asked if I had installed the AAS libraries on my local machine, I had not installed them so installed these:
After installing these on my local machine, the deployment stalls just like it does at my customer. So without any error messages at all
Could you investigate this issue as well?
@Christian Hauggaard, we found something interesting. In order for TX 20.10.xx to work with XMLA endpoints for Power BI premium, you need to install very specific versions of the AAS libraries that I previously mentioned.
At first, I just downloaded them from Microsoft and got the most recent versions. However, we noticed that at another customer for which we use XMLA endpoints older versions of these libraries were installed:
We installed these versions in our implementation and all of a sudden, the deployment of the endpoint worked. Do you have an explanation for this? Most of the times these kind of libraries are backwards compatible.
Good to document this somewhere by the way.
Best regards,
Kaj
@KajEmergo , e.a. I’d like to add the following to the use of the v15 version of the drivers. At a client I was not able to de-install an existing driver for which the version was unknown. When trying to install v15 it aborted with the message that a version already existed and that it needed to be de-installed first. Via add/remove programs or the program list in control panel the driver was however nowhere to be found. There were some files in the program files folder, but I couldn’t make up the version of it.
To solve this I installed v16 which prompted me that it would upgrade the current driver. Luckily v16 came with a de-installer. After de-installing v16 I was able to install v15 using the files from the post above of Kaj.
