Forum Discussion
"This report couldn't access the datasource" - SSAS Tabular Connection Issue
- Anonymous7 years ago
Finally figured out a fix ourselves.
The SSAS Service needed to be ran as a domain account (DOMAIN\USER) ours was using a different service account (NT SERVICE\MSOLAP$...).
We also had to add the new SSAS Service domain account to the following AD group: Windows Authorization Access Group
We found that method by reading the following post:
After restarting the SSAS service, everything worked as expected.
Anonymous Go to the server that hosts the gateway. Search for the gateway via windows and open up the log files for the specific error that is occuring. It should be in there.
Thanks Anonymous
Here's the bit of the log I think it could be. Not sure what I can make from it. Where it suggests to replace the effective username, the from and the to were identical.
| 6A7A1A51 [DM.GatewayCore] AdoNetDBFullConnectiongString: Service Msolap progid is different with on-prem. Service:MSOLAP.5. On-Prem:MSOLAP.8. |
| 733C5FDB [DM.GatewayCore] Db pool opening raw database connection to [MSOLAP.8: <pi>MSOLAP.8:provider=MSOLAP.5;data source=<Server>;initial catalog=<Catalog>;cube=<cube>;sspropinitappname=PowerBI;effectiveusername=<username>;connect timeout=60:[Windows] Encrypted Credential information omitted</pi>] |
| 24AC60C7 [DM.Pipeline.Common] Either LookupPropertyName <username> or TargetPropertyName is null or empty. Fall back to original value. |
| DA9D25D4 [DataMovement.PipeLine.GatewayDataAccess] Replace effective user name in adomd connection string from <username> to <username>. |
- Anonymous7 years agoNot applicable
Finally figured out a fix ourselves.
The SSAS Service needed to be ran as a domain account (DOMAIN\USER) ours was using a different service account (NT SERVICE\MSOLAP$...).
We also had to add the new SSAS Service domain account to the following AD group: Windows Authorization Access Group
We found that method by reading the following post:
After restarting the SSAS service, everything worked as expected.
- Anonymous6 years agoNot applicable
This was the golden key to my SSAS on premise connection issue as well. i.e. run the SSAS service using the domain account under Windows serives instead of the default Local account.
Thank you!