I am able to connect to Azure Databricks from Power BI Desktop and see preview but not able to load data into power bi getting below error need support

Question

I am able to connect to Azure Databricks from Power BI Desktop and see preview but not able to load data into power bi getting below error need support

Bochkar, Sriraj (Contractor) 0

User's image

Hi Team, Need help asap for the issue which i am facing, thanks in advance

SIVASANKAR YEDDULA 170 Reputation points Microsoft External Staff Moderator

2026-09-12T09:09:28.89+00:00
Hi @Bochkar, Sriraj (Contractor) ,

Thank you for sharing the error details.

Analysis

Since Power BI Desktop can successfully connect to Azure Databricks and display preview data, authentication and connectivity to the Databricks SQL Warehouse are working correctly.

The error occurs only when loading the full dataset:

"Couldn't resolve host name"

"A retriable error occurred while attempting to download a result file from the cloud store"

This typically indicates that Power BI is unable to resolve or access the Azure Storage endpoint used by Databricks CloudFetch to download query result files. Microsoft documentation and internal guidance associate this error with DNS, firewall, proxy, or storage connectivity issues rather than credential or permission problems. ODBC Driver error: "Couldn't resolve host name" when connecting to Azure Databricks from Power BI Desktop
Recommended Mitigation

Verify DNS resolution from the Power BI machine.

Check firewall, proxy, or VPN restrictions that may block Azure Storage endpoints.

Ensure the Databricks workspace storage account is reachable on port 443.

If Private Link or VNet injection is used, verify private endpoints and DNS configuration.

Test the same load operation from another network or machine.

Update Power BI Desktop and reconnect to Azure Databricks.

As a temporary troubleshooting step, CloudFetch can be disabled (EnableQueryResultDownload=0) to confirm whether the issue is related to result-file download. ODBC Driver error: "Couldn't resolve host name" when connecting to Azure Databricks from Power BI Desktop.

Conclusion

Based on the error message and the fact that preview works successfully, the issue is most likely related to DNS or network connectivity between the Power BI Desktop machine and the Databricks storage endpoint used for downloading query result files, rather than an authentication or permissions issue. ODBC Driver error: "Couldn't resolve host name" when connecting to Azure Databricks from Power BI Desktop.

Please share whether the environment uses a corporate proxy, VPN, Private Link, or custom DNS configuration so that we can assist further.

Best Regards,

Sivasankar Yeddula,

Microsoft Azure Support.

2 answers

Your answer

Answer 1

Hi @Bochkar, Sriraj (Contractor)

Root cause : connectivity or credentials issues may be.

Solution :

Make sure your PC or gateway can reach the data source host.
If the dataset uses Azure Data Lake, Synapse, or SQL Server, re‑authenticate the connection:

In Power BI Desktop → Data Source Settings → Edit Permissions.
Clear and re‑enter credentials.
Refresh the dataset.

Sometimes the connection string points to an outdated region or alias. Confirm the server name matches your current Azure region (e.g., eastus.azuredatalake.net).
Power BI and Analysis Services cache result files locally. Clear them: %LocalAppData%\Microsoft\Power BI Desktop\AnalysisServicesWorkspaces Then reopen Power BI and refresh.

Thanks.

Answer 2

The error shown is consistent with a network name-resolution problem during result-file download from Azure Databricks, not the initial connection itself. That explains why preview works but the full load fails.

Use this checklist:

Verify outbound network access from the machine running Power BI Desktop.
- The error includes: Couldn't resolve host name.
- This indicates DNS resolution or outbound access is failing when Power BI tries to download result files from cloud storage.
If the connection is going through a proxy, confirm the proxy configuration is supported.
- The Azure Databricks connector supports web proxy.
- Automatic proxy settings defined in .pac files are not supported.
- If the environment relies on .pac, switch to a supported Windows system-wide proxy configuration.
If a firewall or network security policy is in place, allow the required certificate authority endpoints.
- Azure Databricks SSL certificates use DigiCert.
- Add *.digicert.com to the firewall allow list so certificate revocation validation can succeed.
If the environment uses private networking and SSL verification errors are involved, adjust certificate revocation handling.
- Create this file if it does not exist: C:\Program Files\Microsoft Power BI Desktop\bin\ODBC Drivers\Simba Spark ODBC Driver\microsoft.sparkodbc.ini
- Add:
```
     [Driver]
     CheckCertRevocation=0
```
- This is a workaround for CRL-check failures caused by restricted outbound network access.
- Warning: disabling certificate revocation checking reduces certificate-validation security and should be used only when network restrictions are the cause.
Check the Power BI Desktop version.
- Built-in automatic detection of Windows system-wide HTTP proxy configuration requires Power BI Desktop version 2.104.941.0 or later.
- If native SQL queries are being used, that requires version 2.112.603.0 or later.
- Databricks service principal M2M OAuth requires version 2.143.878.0 or later.
Reconnect and test with a small load.
- Open Get Data > Azure Databricks.
- Reauthenticate if needed.
- In Navigator, select a small table first and try Load.
- If preview succeeds but load still fails, that further points to network restrictions during result retrieval rather than authentication.
If using Partner Connect, regenerate the connection and test again.
- In Azure Databricks: Marketplace > Partner Connect integrations > Power BI.
- Choose the compute resource, download the connection file again, open it in Power BI Desktop, then authenticate and test the load.

The most relevant documented causes for this pattern are:

unsupported proxy configuration such as .pac
blocked certificate revocation endpoints
private-network SSL verification issues requiring CheckCertRevocation=0

References: