Forum Discussion

Bhargava_B's avatar
Bhargava_B
Frequent Visitor
8 months ago
Solved

Gateway issue with StrongDM suffix

 
I’m facing a persistent issue with Power BI Desktop → Power BI Service → On-Premises Data Gateway when using StrongDM (SDM) as a secure access layer to SQL Server.

 

Environment

  • Power BI Desktop (Import mode)

  • Power BI Service

  • On-Premises Data Gateway (Enterprise mode)

  • SQL Server (on-prem)

  • StrongDM client used for database access

  • Authentication via service account on Gateway VM


StrongDM Context

For developers, StrongDM exposes SQL Server using a local alias with role + port, for example:

Dev-Mhgh01.dev.local.all_rwd_sql,10700

However, for Power BI Service + Gateway, the dataset must use the real hostname only, without the StrongDM suffix:

Dev-Mhg01.dev.local

StrongDM client runs on the Gateway VM and brokers access transparently.


What I’m Trying to Achieve

  • Develop the semantic model locally using the StrongDM alias

  • Publish the same model to Power BI Service

  • Bind it to the On-Premises Data Gateway using only the real SQL hostname

  • Avoid embedding the StrongDM suffix in the published dataset


What I Have Done

  1. Built a semantic model in Import mode

  2. Created Power Query parameters:

    • serverWithSDM = Dev-Mheg01.dev.local.all_rwd_sql,10700

    • serverWithoutSDM = Dev-Mheg01.dev.local

    • Server (active selector)

    • DB

  3. All queries use:

     
    Sql.Database(Server, DB, [Encrypt=true, TrustServerCertificate=true])
  4. Verified no hardcoded SDM suffix exists in any query

  5. Deleted the existing semantic model from Power BI Service

  6. Closed and reopened the PBIX

  7. Switched parameter to serverWithoutSDM

  8. Clicked Close & Apply

  9. Published again


Problem 1 – Desktop

When I switch the parameter to serverWithoutSDM in Power BI Desktop and click Close & Apply, I get:

 

 
OLE DB or ODBC error: A connection was successfully established with the server, but then an error occurred during the pre-login handshake.

(This is expected locally because my machine can only connect via StrongDM alias.)


Problem 2 – Power BI Service / Gateway (Main Issue)

Even after:

  • Deleting the dataset from Service

  • Republishing with serverWithoutSDM

  • Ensuring no SDM suffix exists in M code

 

 In Power BI Service → Gateway → Cloud connections,
the dataset still shows the old server value with the StrongDM suffix, e.g.:

 

 
Dev-Mheg01.dev.local.all_rwd_sql,10700

As a result:

  • Gateway binding fails

  • Dataset refresh fails

  • Error: Gateway is not configured


Key Observation

In Power BI Desktop → Model / Power Query, I still see parameters listed under Expressions, e.g.:

  • serverWithSDM

  • serverWithoutSDM

  • db

Even though the active parameter is set to serverWithoutSDM, Power BI Service appears to retain the original data source identity that was created when the model was first evaluated using the SDM suffix.


My Questions

  1. Is Power BI Service persisting the initial data source identity permanently, even after dataset deletion and republish?

  2. Is there any supported way to force Power BI Service to:

    • Recreate the data source identity

    • Bind the dataset to the Gateway using a different server name?

  3. Is it architecturally impossible to use a single PBIX when:

    • Desktop can only connect via one hostname

    • Gateway can only connect via another?

  4. Is the only supported approach to maintain:

    • One PBIX for development (StrongDM alias)

    • One PBIX for publishing (real hostname, prepared on a gateway/jump VM)?


Expected Outcome

I want Power BI Service to see and bind only:

Dev-Mheg01.dev.local

 

and never retain:

Dev-MHeg01.dev.local.all_rwd_sql,10700
 

Clear guidance on data source identity behavior, gateway binding, and supported deployment patterns would be extremely helpful.

4 Replies

  • Hi Bhargava_B - Power BI Service cannot be forced to recreate the data source identity.single pbix cannot be used when Desktop and Gateway must connect using different hostnames.this behavior is by design, not a bug.

    Recommendation should be maintain two pbix files: for development you can Uses StrongDM alias (for local modeling). Once you move to production maintain another pbix ses the real SQL Server hostname (opened and published from a Gateway-accessible VM or jump box).This is the only fully supported and reliable pattern.

    ref:

    https://learn.microsoft.com/en-us/power-bi/connect-data/service-gateway-onprem-tshoot

    https://powerbi.microsoft.com/fi-fi/blog/using-xmla-endpoints-to-change-data-sources-in-a-power-bi-dataset/

     

    Hope this helps.

     

     

  • sarahlns's avatar
    sarahlns
    Frequent Visitor

    Hello  Bhargava_B


    Power BI Service persists the SQL data source identity based on the server name used during the initial evaluation.

    Parameters do not redefine this identity, and the Gateway binding relies exclusively on the persisted data source metadata.

    As a result, using different hostnames for Power BI Desktop and the On-Premises Data Gateway is not supported for Import mode models.

    The only supported approaches are developing on a gateway-accessible machine or maintaining separate PBIX files for development and publishing.

  • Hi Bhargava_B,

    Checking in to see if your issue has been resolved. let us know if you still need any assistance.

     

    Thank you.