Jump to content

SQL 2005 Cluster Login Failed


Guest

Recommended Posts

I have retrospect 7.5 Multi Server with the Value Pack. I am a long time user of Retrospect v5 - v7.5. I am running a 2 node SQL Server 2005 cluster on Windows Server 2003 (SP1). All machines are in a 2003 domain. I cannot authenticate to the SQL Server no matter which method I use (Current Retrospect User, SQL Authentication, domain user), even Enterprise Admin credentials do not work. After licensing the SQL Server I wish to back up, I am prompted for login credentials to the server. I always get back "Sorry authentication failed. Please retry." I have connected successfully to a standalone version of SQL 2005. I also set up a Virtual Cluster just to try it on a clean environment and still no luck. The Retrospect client sees the drives and the DB Server itself just fine.

 

I use to use retrospect 6.5 and 7.0 to back up my SQL 2000 cluster just fine even though it was not an "officailly supported" configuration. Now it is supported and it doesn't seek to work. Any help would be greatly appreciated. Thanks!

Link to comment
Share on other sites

Thanks AmyJ. The client software is on both nodes. But since I have to choose one node (I cannot choose the IP Address where the Virtual SQL server is and have Retrospect follow it) I use node 1 and that is where the SQL Group is by default. I have tried both nodes just to be sure and neither work. Has anyone done this successfully?

Link to comment
Share on other sites

Hi Jim -

 

 

 

I've licensed/logged in SQL Server 2005 in a cluster a fair number of times both in a hardware and a virtual environment and did not have the issues you are seeing. Off the top of my head I don't recall whether I used SQL Authentication or Windows Authentication. When you say you've tried both nodes do you mean that you moved the SQL group to node 2 and then attempted to license it from there?

 

 

 

How are the security preferences set in Retrospect? To run Retrospect as the logged in user, or as a specific user?

 

 

 

Can you try authenticating as a Domain Admin rather then an Enterprise Admin?

 

 

 

Are these machines (Retrospect server and cluster nodes) all in the same domain?

 

 

 

Are there any errors in the SQL management logs after attempting to authenticate? If so, what are they?

 

 

 

Let me know...

Link to comment
Share on other sites

Amy, I moved the SQL Server to node one, applied a free SQL license successfully and then could not authenticate using any of the three methods. I then released the license from node one, moved the SQL group to node 2, then licensed node 2 with the available license. Failed to login there with the same result.

 

I have tried running retrospect as both the logged in User (me Domain Admin) and a specific user me, the user account the cluster runs under and the RBU account that I set up using the directions in the Retrospect Manual on how to connect to a SQL Cluster.

 

All machines are on the same real domain including the VMs I set up and a 2nd cluster to do some testing. I could set up a Virtual Domain with all VM's and try everthing again there, although that would take some time.

 

There is nothing in the Retrospect logs even at the max logging level (7). The log from the Node 1 is interesting. There are 3 entires for the attempt. It appears that it registers a successful logon and logoff of the RBU user.

 

Successful Logon:

User Name: RBU

Domain: (domain name removed for post)

Logon ID: (0x0,0xD5BCE)

Logon Type: 5

Logon Process: Advapi

Authentication Package: Negotiate

Workstation Name: DEV-CLUSTER1

Logon GUID: {6f91fb32-932c-4dda-3be3-36785acc2d01}

 

Special privileges assigned to new logon:

User Name: RBU

Domain: (domain name removed for post)

Logon ID: (0x0,0xD5BCE)

Privileges: SeSecurityPrivilege

SeBackupPrivilege

SeRestorePrivilege

SeTakeOwnershipPrivilege

SeDebugPrivilege

SeSystemEnvironmentPrivilege

SeLoadDriverPrivilege

SeImpersonatePrivilege

 

User Logoff:

User Name: RBU

Domain: (domain name removed for post)

Logon ID: (0x0,0xD5BCE)

Logon Type: 5

 

For more information, see Help and Support Center at

 

But Retrospect says the login failed. I have installed Retrospect on another server to be sure the problem was not with the Backup Server, but I get the same results.

 

Thanks again, Jim.

Link to comment
Share on other sites

Hi Jim -

 

 

 

Which value are you setting for max logging in Retrospect? The only one that would probably show you anything is Trees and Volumes. Does the Windows Event Log show any errors?

 

 

 

Can you connect to the SQL instance running in the cluster via the Server Management Studio with both Windows Authentication and SQL Authentication?

 

 

 

Are you changing permissions (users) for SQL through the Server Management Studio or through the SQL Service?

 

 

 

Do you have MSDTC installed as a cluster service? I don't know if you can install SQL 2005 in the cluster without it, but it is a requirement. Just checking...

 

 

 

Thanks,

 

Amy

Link to comment
Share on other sites

Amy,

 

I have already given you what the Event log on the Cluster machines shows in my previous post. The Windows event log on the Retrospect Server does not show anything.Here's a few lines from the Operations Log:

necoOpen: connection established with "dev-cluster1"

necoIncoming: cmd 300 [ 231 bytes]: 5f 67 6c 5f 05 06 00 00 54 57 44 42 53 71 6c 53

T-2: TWDBSqlServerappl.gifInit: Connect() failed [0x80040000]:[Microsoft][ODBC SQL Server Driver][shared Memory]SQL Server does not exist or access denied.[Microsoft][ODBC SQL Server Driver][shared Memory]ConnectionOpen (Connect()).

necoIncoming: cmd 300 [ 56 bytes]: 5f 67 6c 5f 07 06 00 00 44 62 4d 61 70 45 72 72

T-2: DbMapError: mapped SQL error -2,147,221,504 to

necoIncoming: cmd 300 [ 89 bytes]: 5f 67 6c 5f 06 06 00 00 54 57 44 42 53 71 6c 53

T-2: TWDBSqlServerappl.gifInitDMO: connection failed to instance: '(local)', username: 'sa'

 

Question: I see that it is trying to connect to instance '(local)' which is not the name of the Virtual Server SQL Cluster - that name is 'DEV-SQLCluster'. Could this be the problem? I have tried to connect to the Retrospect Client using the IP and Name of the SQL Cluster (which is does, but shows me the cluster host name - dev-cluster1 instead of the cluster name). Is there a way to force the client to bind itself to the Cluster IP address?

 

I CAN connect to the SQL server with the Management Studio with both Windows Authentication and SQL Authentication (using 'sa' account).

 

Just to make sure there was not a problem with the service accounts, I just changed them all to log in as the Domain Admin. I also just changed to the Retrospect Client Services account to login in as the Domain Admin. No luck there either.

 

MSDTC is now installed as a cluster service, although it was not originally in my test VM environment that I am using now. No effect there.

 

Not exactly sure which permissions you are talking about, but I created the Users I am trying to connect with in the SQL Management Studio. I know they are supposed to be Backup Operators, but I have give them FULL premissions in SQL Server for testing purposes.

 

Once again, I appreciate your continued help.

-Jim

Link to comment
Share on other sites

Hi Jim-

 

 

 

>>Question: I see that it is trying to connect to instance '(local)' which is not the name of the Virtual Server SQL Cluster - that name is 'DEV-SQLCluster'. Could this be the problem? I have tried to connect to the Retrospect Client using the IP and Name of the SQL Cluster (which is does, but shows me the cluster host name - dev-cluster1 instead of the cluster name). Is there a way to force the client to bind itself to the Cluster IP address?

 

 

 

If there is a "local" instance of SQL on the cluster machine as well as the clustered SQL Retrospect should see 2 SQL servers in Configure > Volumes. Each instance will appear separate from one another. Do you have a local and a cluster instance?

 

 

 

The client has to bind to the node public IP address.

 

 

 

>>Not exactly sure which permissions you are talking about, but I created the Users I am trying to connect with in the SQL Management Studio. I know they are supposed to be Backup Operators, but I have give them FULL premissions in SQL Server for testing purposes.

 

 

 

I was referring to changing the users for the service accounts - sorry for the confusion, which you correctly did.

 

 

 

At this point I would suggest calling EMC Insignia technical support and opening an incident. If the problem is a bug in the software your support costs will be refunded.

 

 

 

Sorry I couldn't be of more help.

Link to comment
Share on other sites

Hi Amy,

 

Thanks for all the replies. There is no local instance of SQL Server running on the machines, but it appears Retrospect is trying to connect to a local instance. Any way to get it to connect to the right instance?

 

How do I force the client to bind to a specific IP? Does it matter if you install the Retrospect client before or after you install SQL Server?

 

I guess I'll set up the whole thing in a virtual environment (domain controller, backup server, 2 cluster nodes) to see if it works there (sigh). Then I call tech support. smile.gif

 

Jim

Link to comment
Share on other sites

Hi Jim -

 

To bind the client to a specific IP go to Run and type "retroclient /ipsave <ipaddress>". The client will broadcast on any available IP but should default to binding to what Windows thinks is the default IP. It may help to go into Network Connections on the client machine and then Advanced > Advanced Settings and make sure the public IP address is listed first in the list, before the private address.

 

I'm mostly out of ideas right now, but feel free to ask if you have any more questions.

 

Thanks,

Amy

Link to comment
Share on other sites

Amy,

 

Just as a follow up -

 

I've built a virtual domain of 3 VM's (domain Controller, Node1, Node2) to test the setup from scratch. I've followed the instructions in the Retrospect User Guide just in case I was doing something wrong. Still the same behavior. I guess I'll have to call tech support.

 

Thanks for all the assistance.

 

Jim

Link to comment
Share on other sites

  • 2 months later...

To All,

 

Dantz has confirmed this is a problem and they are working on a fix. No timeframe given as to when one will be available.

 

-Jim

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...