The ImpersonationInfo for datasource 'ASDBName' contains an ImpersonationMode that can only be used by a server administrator
The solutions (there are two or three) aren't terribly painful but they both require some form of administrator intervention.
All the solutions require two things:
- The data sources should be configured in the SSAS project to impersonate the service account. Yes, I know, that's what caused the error I mentioned earlier.
- A role in the AS database project that grants the developers full control over it.
The first solution is probably easier for the developers. In this one the BI Admin gets a copy of the SSAS project (from source control, right?) and deploys it to the server. Once it's deployed once by the administrator the developers can deploy over the top of it as long as they don't add any new data sources or change the impersonation setting for the existing ones. If the data sources change, the admin has to perform the deployment again.
The second solution requires a little back-and-forth between the developers and the admin. In this scenario the administrator creates the blank database as before. After that, the developers change the data sources to impersonate the current user. They will also want to set the project not to process upon successful deployment; otherwise, it will cause the whole thing to fail. A developer then deploys the database to the server and hands the baton off to the BI Admin. Once the database is in place, the administrator can change the data sources in the database to impersonate the service account and the developers do the same in the AS project. The developers should now be able to deploy to the server all they want (with the same caveats as option "one").
The third option -- I wouldn't call it a solution -- is to give you developers admin access to the server. I don't like this method but sometimes the hassle of the other choices just aren't worth it. You have to be careful that there are no databases with sensitive data on the server. If necessary, create separate instances of SSAS to hold sensitive data and only grant admin access to the developers working on those particular projects.
All that said, none of these are options for your Production environment. None. Of. Them. Only the BI administrator should be deploying to Production unless, of course, your builds are automated and go through a strict vetting process.
Got a better solution? I would love to hear it. I am stuck in option number three in the moment but bouncing some ideas around my head on how I might automate #1 or #2.
No comments:
Post a Comment