Live connection to SSAS

[XeniaLi]

I wonder if anyone can point me into a direction we have re-occuring issue with live connection to SSAS model.

Our current config is

• Power Bi Repport Server on Server A
• Our SSAS model on Server B with RLS intergrated
• We also create an alias name for web browsers of reprot server (as server had a very techincal name, report users were struggling to remember it)
  
  

Occasionall users on a random basis have an error 
When looking for dev tool it is Conceptual Schema


This issue do not affect reports in import mode, and it also resolve on it's own after some time and then re-appear and resolve, for different users in different time. So some user might have access while other do not.

Many many thanks for any ideas.

[XeniaLi]

Thank you much appreciated.
We've checked configuration Kerberos configs and other and they are looking correct. However I've noticed that some request to SSAS are requested in anonymous logon whihc is not allowed. How can I change it from PBRIS to stop anonymous connections when it is direct/live query of SSAS?

TA

Xenia

[Nasif_Azam]

Hey @XeniaLi ,

You're experiencing a recurring issue where Power BI Report Server fails to connect to a live SSAS (SQL Server Analysis Services) model. This issue:

• Happens randomly to different users

• Only affects live-connected reports

• Fixes itself without intervention, then reoccurs

• Does not affect reports using import mode

From the screenshots:

• Error mentions ConceptualSchemaProxy.execute in the console

• Error popup shows: "We couldn't connect to the Analysis Services server"

Resolve Tecnique

1. Kerberos Delegation Issues

Live connections to SSAS require Kerberos authentication to impersonate users. If this setup is incomplete or misconfigured, users will see connection failures.

What to do:

• Ensure Service Principal Names (SPNs) are correctly registered:

  • For Report Server: HTTP/yourReportServerName

  • For SSAS: MSOLAPSvc.3/yourSSASServerName

• Check that Constrained Delegation is configured: In Active Directory, allow the Report Server’s service account to delegate to the SSAS service

• Confirm that your live connection uses EffectiveUserName to pass user identity for RLS

2. Alias and DNS Resolution

If your friendly alias doesn’t consistently resolve or isn’t trusted by all users’ browsers, it can trigger connection issues or CORS (cross-origin) problems.

What to do:

• Confirm that the alias works for every user via ping or nslookup

• Add the alias (like http://reports.yourcompany.com) to the Trusted Sites list or Intranet Zone via Group Policy

• Ensure the DNS alias (CNAME) doesn’t conflict with Kerberos SPNs

3. Performance Bottlenecks on SSAS Server

Temporary resource shortages (CPU, memory, etc.) on the SSAS server can block or delay connections, especially under heavy load.

What to do:

• Monitor SSAS performance using:

  • Performance Monitor

  • SQL Profiler

  • Resource Monitor

• Check whether memory constraints or process restarts are causing downtime

• Look for query execution delays or processing backlogs

4. RLS-Related Identity Problems

Row-Level Security depends on the correct user identity being passed to SSAS. If this fails (e.g., due to delegation issues), users may be denied access randomly.

What to do:

• Confirm that user identity flows properly from the report to SSAS

• Test user access by connecting to the SSAS model in SSMS (SQL Server Management Studio) using their credentials

• Review RLS filters to make sure they’re not too restrictive or misconfigured

5. Clock Synchronization Issues

If the system time differs significantly between user machines, the report server, or SSAS, authentication tokens may become invalid due to clock skew.

What to do:

• Ensure all servers and user devices are syncing time with a reliable NTP source

• Double-check domain time policies

• Reboot servers if needed to apply new time settings

For detailed information:

Configure Kerberos Constrained Delegation for Analysis Service

Troubleshoot Analysis Services Connection Issues in Power BI Report Server

Set SPNs for Power BI Report Server

Kerberos Configuration Manager for SQL Server

If you found this solution helpful, please consider accepting it and giving it a kudos (Like) it’s greatly appreciated and helps others find the solution more easily.

Best Regards,
Nasif Azam

[Poojara_D12]

Hi @XeniaLi 

The recurring error you're encountering when using a live connection to an SSAS (SQL Server Analysis Services) model through Power BI Report Server, as shown in your screenshots, is typically caused by transient network or authentication-related issues between the Report Server and the SSAS server. The error message We couldn't connect to the Analysis Services server along with Access token expired or ConceptualSchemaProxy.execute failures indicates that, at the time of accessing the report, the user's identity or token used for RLS (Row Level Security) validation could not be successfully passed to SSAS.

Since the issue is intermittent and resolves on its own, it’s likely not a misconfiguration but rather an environment-related inconsistency. This can stem from several common factors:

Kerberos Delegation: Live connections with RLS require Kerberos to correctly delegate the user identity from the report server to the SSAS server. If Kerberos is not set up consistently across all access routes (especially when using an alias or DNS CNAME for Report Server), users might fail to authenticate intermittently.

Token Expiry and Session Caching: If the user’s authentication token expires or is not refreshed in time (especially in distributed setups or long sessions), the server can return token-related errors, which would match the “access token expired” part of your log.

DNS Alias and SPNs: If you're using an alias (friendly URL), ensure that the alias is properly configured with a registered SPN (Service Principal Name) for Kerberos, and the delegation is set up from the Power BI Report Server service account to the SSAS service account.

Recommendations:

Ensure Kerberos is configured correctly with proper SPNs and constrained delegation set up between Report Server and SSAS.

Validate that the Report Server and SSAS are on the same domain and that user delegation is allowed.

Review SPNs using setspn -L <ServiceAccount> for both SSAS and Power BI Report Server accounts.

If you're using a custom alias, ensure it resolves correctly on all client machines and is covered under the SPNs.

Consider using Network Monitor or Fiddler to trace the traffic when the error occurs to confirm if it’s Kerberos failure.

Ensure users are accessing the report server using the fully qualified domain name (FQDN), not just the alias or short name.

This kind of setup is sensitive to network environment and domain configuration, so even if the setup is correct in principle, any minor inconsistency (like a missing SPN for the alias) can cause the exact intermittent behavior you're seeing.