Skip to main content
To homepage To homepage

Hi,

We are setting up a new Azure environment for a client and we are having some issues with the Azure SQL DB.

The app server VM is based on the one available in the Azure marketplace:
https://azuremarketplace.microsoft.com/en-us/marketplace/apps/timextender.timextender-app-server?tab=Overview

The issue occurs when we try to test the storage connection for the MDW instance. 

When we try to use Azure AD integrated or password authentication we get the error that adalsql.dll is not able to load when we test the connection in the desktop app.

Azure AD integrated authentication
Azure AD password authentication

The URL leads to a 404 not found: http://go.microsoft.com/fwlink/?LinkID=513072

I found these two posts about AAD integrated auth, but it is not clear to me if it is possible or not to get it to work:

I didn’t find any discussions about the Azure AD password authentication.

Are these not supposed to work as authentication methods for a DW instance deployed in an Azure SQL DB? If they are, is there something we need to install on the VM to get it to work?

Cheers.

//Pontus Berglund

Hi,

if adalsql.dll is not there you might need SSMS 19 and / or SQL client libraries. If you are using Qlik you need to be mindful of the specific version of the client libraries but 18.2.3, 18.6.5, 19.3.2 should be fine. 

Azure AD Integrated required ADFS iirc. The password option should work. Note that the marketplace VMs may not be “cutting edge” with respect to drivers. I tend to roll my own most of the time.

Hi @rory.smith,

Alright, I’ll install SSMS and will look into the SQL libraries. We are using Power BI so perhaps the versions will not matter as much then? 

Interesting that the marketplace VM might not have all the drivers, I thought it would be “optimized” for TX in a sense. Are there any specific things you consider when setting up VMs?

Thanks for the advice. 

Hi @pontus.berglund ,

usually the templates lag a bit behind the most recent version of TX in my experience.They are simply set up to have all the software dependencies installed that you need for a vanilla TX setup. If you have any other moving parts, you may end up having slightly different requirements. I occasionally use the VM template (or let the customer use the image) to only set up the VM as that may be the best way in some more restrictive environments. As soon as there is more custom stuff going on, I tend to insist on setting it up by hand.

The main issue is that Microsoft performs rolling updates on PaaS services like Azure Analysis Services and Azure SQL DB which may require updates on client libraries. Other tools are sometimes also lagging behind a bit, which means you end up needing to customize which versions of what to have available. 

When setting up a VM I tend to take other tooling into consideration in my choices of software to install: that may require older .NET and C++ runtimes or tooling simply not working with the most recent versions of SQL Server or Microsoft drivers. There are usually also all kinds of monitoring tools that need to be applied to make a VM work for a customer's Azure governance. In the end, setting up a VM from scratch is not that time-consuming compared to chasing a weird interaction between drivers.

Reply


Terms and ConditionsCookie settings