December 28, 2010 at 12:03 pm
I must be missing something. I'm developing a cube in BIDS and the cube won't process using ANY impersonation mode. Data Source is pointing to Server A while cube database & SSAS exist on Server B.
Server B uses a domain account for the SSAS Service. I've made sure that this account is in the Server Security properties for Analysis Services and assigned to the Full Control / Admin role under the cube database Roles folder. I've added my own domain account for good measure.
On Server A, the service account exists as just a regular login with db_databasereader and Public perms to the source database. I am a member of an AD group which is a member of Sysadmin on both servers.
Attached is a list of the errors I'm getting when trying to do a Full Process of the cube. I've separated out each by Impersonation Mode on the data source in BIDs. What's strange is that three of them almost have the same exact errors while the one saying "Use Current User's Credentials" comes up with a different set of errors. I've scrubbed certain names in the error file, so if something doesn't make sense, let me know. I might have accidentally overwrote something.
I only got one response off of #sqlhelp, so I figure this issue is too huge for Twitter. Any assistance would be appreciated. I have no idea what it is I've missed and my Google-Fu comes up with nothing that helps me.
December 28, 2010 at 7:44 pm
Strange... sounds like you should be good from what you've listed here. If you open the ODS connection and hit Test Connection your able to connect?
I usually go with Default, which when processing uses the AS services account. As long as that services account has access to the ODS connection you will be in good shape but sounds like that is already done.
December 28, 2010 at 8:00 pm
Hey Brandy,
Did you check this KB article? If you get bored with it (it's a little dry to begin with) at least skip down to the 'Simplified Explanation' for a easier to digest explanation of what *might* be happening for you.
HTH,
Steve.
January 4, 2011 at 7:10 am
Okay, I'm back. Sorry about not responding. Was pulled on another project.
I'm looking at the KB article now. Thanks for the link.
Interesting note. I changed the Impersonation Info and had to rebuild the project, which had to overwrite the DB, which removed my Role that had my users set up with Admin perms. That was annoying. It also errored out again.
Per SQLJoe, I've logged into SSAS using the Service account and verified that it can connect to SSAS just fine. So now I'm on to other things.
January 4, 2011 at 7:12 am
Devin Knight (12/28/2010)
Strange... sounds like you should be good from what you've listed here. If you open the ODS connection and hit Test Connection your able to connect?
Yes, I am. That's what's driving me nuts. EDIT: I should note the ODS server doesn't have SQL logins at all, so I'm using Windows Auth. Could this be what's causing the issue?
I usually go with Default, which when processing uses the AS services account. As long as that services account has access to the ODS connection you will be in good shape but sounds like that is already done.
Yep. Much frustration here. I can only think this has something to do with the original source having once been a cluster that was broken (but the instance still has the same name). If nothing else works, I may have to point my source to a production server, which I really don't want to do unless I'm desperate.
January 4, 2011 at 11:08 am
(headthunk)
(headthunk),(headthunk)
Two weeks I've been fighting this (well, I had to take time out to do another project, but still. Two weeks!) and the solution turns out to be so easy that a fifth grader could have fixed this problem.
I created a SQL Server only account and changed the ODS authentication information from Windows Auth to the SQL Server only account. Tested the connection in the DS. Rebuilt the project, and the cube is in the middle of processing.
As in it's actually proccessing and not immediately erroring out.
Impersonation mode is set to Service Account. Nothing else has been changed. No rights added to the Service Account, nothing. Thanks for the KB link, SteveFromOz. That did help me understand the nature of the SPN problem.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply