XMLA endpoint stuck on deploy

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:

1. We tested on my local machine version 38 (same as Andrew's client), but we got the error I posted above
2. We tested on my local machine version 40 (same as my client is on where deployment gets stuck), same error as above
3. Rory asked if I had installed the AAS libraries on my local machine, I had not installed them so installed these:
4. 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?

@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.