Hi all, I'm trying to identify if there is some limitations with the Analysis Services Connector?, something like size of data, size of query, number of dimensions, things like that.
There are two things that I would consider:
EffectiveUserName is passed with the requests. I just verified off of the AS Connector that is available on the Microsoft Download Page.
I've never seen it not pass EffectiveUserName. I'm not sure what you were referring to.
Try to log in as different users and see whose credential are being passed while looking at the same report . I guess I misspoke when I said that no EffectiveUserName is passed, but credentials of the user viewing reports are not being passed.
please see this blog post for more details
To describe the behavior, if UserA creates a new Dataset and choosing an Analysis Services connection that exists, that dataset will pass UserA via EffectiveUserName. If UserB creates a new dataset and choose the same AS Connector, UserB will be passed via EffectiveUserName.
Here is what I think you are encountering.
UserA creates a Dashboard, report and dataset based on an Analysis Services connection using the AS Connector. When UserA uses the items, UserA will be passed via EffectiveUserName. When UserA shares the dashboard with UserB, and UserB goes to use the Dashboard/Report, UserA will still be passed via EffectiveUserName. This is because UserA owns the asset and is letting UserB use it.
Ideally UserB would be passed via EffectiveUserName in that scenario, but that isn't the current behavior.
That said, if UserB creates his own items based on the same AS Connector item, UserB will be passed via EffectiveUserName.
That's correct. Therefore, I would advise using caution when AS Connector-based content is shared, because this behavior is counterintuitive and could have very serious security repercussions until it's fixed for GA.
As of right now it is definitely a limitation.
I think about size of data, size of query, number of dimensions - does not affect , it will treat this as general.
Addition details -
Currently, other on-premises sources are not refreshable yet within the Public Preview, Got this from Adam's Blog (http://blogs.technet.com/b/powerbisupport/archive/2015/02/17/a-look-at-the-analysis-services-connect...
Updated on Enable connectivity to on-prem (or IaaS) SSAS Cubes / multidimensional!, here is idea supporting this with high votes https://support.powerbi.com/forums/265200-power-bi/suggestions/6606693-sql-server-analysis-services-...
Two important points to note down from power bi support website (https://support.powerbi.com/knowledgebase/articles/471577-configure-a-power-bi-analysis-services-con...
You can read additional FAQ here related to this topic
Also take one look here on ideas associated with SSAS (https://support.powerbi.com/forums/265200-power-bi?query=SSAS)
All Power BI support links for SSAS realted topics are here
Hope this helps
BI Solution Architect
Internet latency is also something to consider. You can use Fiddler to identify where the requests are going do, and then evaluate what kind of altency you have with regards to performance. You may not be able to do a whole lot about it, but it may give you some idea if things seem sluggish as it can contribute to that.
A gap in the functionality of the SSAS connector is also that it cannot connect to an HTTP pump end point. This makes is hard to support ISV's who host customer tabular and dimensional data sources on their cloud for u;sers. The way it works now and the way it seems to have been envisioned is to serve IT departments who synch to AD Azure and not for an ISV who supports hundreds of different customers and also use a different type of authentication. Also, it assumes that the security on the cubes are role based, rather than dynamic security based on DAX or MDX filtering. Microsoft needs to allow connections to HTTP SSAS Pump endpoints as Excel or other tools always have - With this approach ISV's or anyone not able to synch with Azure AD to manage the connection as well as mapping to internal identity through an httphandler proxy. Allowing this, rather than thinking that EffectiveUserName will work in lieu of Azure AD synching. We have thousands of users that use Excel to get to tabular models this way now. We would love to able to offer the same capabilities thru Power BI. I have discussed this with some MSFT folks already. I really hope this is being considered as it's a main showstopper for us. A large problem is also that some of these are European customers and they do not want to move their data to 'yet another cloud provider'. MSFT please consider resolving this issue soon. It will open up the capabilities for your ISV's and also get more Power BI subscribers.