SSAS cube no longer deploying -- error:The target principal name is incorrect
Hello,
I have an SSAS project set up that processes a small cube. The project was originally written in VS 2005 running against a SQL Server 2005 database. I have since upgraded to VS 2008 Professional and SQL Server 2008 Developer Edition. Now, I cannot get the cube to process. It keeps choking on the data source connection credentials. The error I get is:
OLE DB error: OLE DB or ODBC error: Cannot generate SSPI context; HY000; SQL Server Network Interfaces: The target principal name is incorrect.
; HY000.
The thing is, I'm using MY account specific credentials on the connection's impersonation pane. If I go into the connection itself and test it, it works fine. It's only when I try to deploy and process to the server that I get these issues.
I'm uncertain how to proceed. Do I need a service pack? Am I missing something simple?
Thanks.
I have an SSAS project set up that processes a small cube. The project was originally written in VS 2005 running against a SQL Server 2005 database. I have since upgraded to VS 2008 Professional and SQL Server 2008 Developer Edition. Now, I cannot get the cube to process. It keeps choking on the data source connection credentials. The error I get is:
OLE DB error: OLE DB or ODBC error: Cannot generate SSPI context; HY000; SQL Server Network Interfaces: The target principal name is incorrect.
; HY000.
The thing is, I'm using MY account specific credentials on the connection's impersonation pane. If I go into the connection itself and test it, it works fine. It's only when I try to deploy and process to the server that I get these issues.
I'm uncertain how to proceed. Do I need a service pack? Am I missing something simple?
Thanks.
ASKER
OK, I managed to figure out a workaround, but the problem is as I originally stated. Basically, I can't connect to my local instance of SQL server 2008 remotely. If I go into SSMS on the server, and try to connect using windows authentication, I get the same error. However, my browser service is running and TCP/IP protocols are all enabled. So, I don't see why I can't connect to my dev machine remotely.
Any ideas?
Any ideas?
You added your domain user to the SSAS server?
In SQL Management Studio, connect to SSAS Server
next right click in the server and go to properties
next slect security tab and add your domain user to the SSAS Server,
Resolved?
regards
In SQL Management Studio, connect to SSAS Server
next right click in the server and go to properties
next slect security tab and add your domain user to the SSAS Server,
Resolved?
regards
ASKER
Well, the issue is that I can't connect to a regular database, but I am an admin on both the database server and SSAS level. The SQL Server instance is set to allow remote connections, but even if I just try connecting from any other computer through SSMS I get the error:
"Cannot generate SSPI context"
Which implies that it either won't accept remote connections, or it cannot validate the windows credentials for some reason.
"Cannot generate SSPI context"
Which implies that it either won't accept remote connections, or it cannot validate the windows credentials for some reason.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks, I saw that first article already and it didn't help, but this paragraph from the second article did:
If you run the SQL Server service under the LocalSystem account, the SPN is automatically registered and Kerberos interacts successfully with the computer that is running SQL Server. However, if you run the SQL Server service under a domain account or under a local account, the attempt to create the SPN will fail in most cases because the domain account and the local account do not have the right to set their own SPNs. When the SPN creation is not successful, this means that no SPN is set up for the computer that is running SQL Server. If you test using a domain administrator account as the SQL Server service account, the SPN is successfully created because the domain administrator-level credentials that you must have to create an SPN are present.
I changed it to the LocalSystem account and was able to connect successfully.
Thanks!!
If you run the SQL Server service under the LocalSystem account, the SPN is automatically registered and Kerberos interacts successfully with the computer that is running SQL Server. However, if you run the SQL Server service under a domain account or under a local account, the attempt to create the SPN will fail in most cases because the domain account and the local account do not have the right to set their own SPNs. When the SPN creation is not successful, this means that no SPN is set up for the computer that is running SQL Server. If you test using a domain administrator account as the SQL Server service account, the SPN is successfully created because the domain administrator-level credentials that you must have to create an SPN are present.
I changed it to the LocalSystem account and was able to connect successfully.
Thanks!!
ASKER
Thanks, that was driving me nuts.
ASKER
This is the same server I used to deploy this cube too and I never had this problem before. So, it must have something to do with VS 2008 passing the credential differently.