robrandon
asked on
Cannot remote admin Arcserve 2000
Windows 2000 Advanced Server - clustered - has Arcserve 2000 SP 4 installed.
On my Windows XP I have Arcserver 2000 manager installed with SP4. I cannot connect to the server to remotely manage it. I can connect to it with Server Admin.
I checked the permissions on the Arcserve$ share and they are ok. What am I missing?
The error I get when I try to connect is:
Server XXX failed to authenticate the user admimistrator (EC=14)
and
Server XXX failed to authenticate the user admimistrator (EC=1722)
I've tried the administrator account and my user account. I've also tried mapping the drive manually first but it didn't work.
On my Windows XP I have Arcserver 2000 manager installed with SP4. I cannot connect to the server to remotely manage it. I can connect to it with Server Admin.
I checked the permissions on the Arcserve$ share and they are ok. What am I missing?
The error I get when I try to connect is:
Server XXX failed to authenticate the user admimistrator (EC=14)
and
Server XXX failed to authenticate the user admimistrator (EC=1722)
I've tried the administrator account and my user account. I've also tried mapping the drive manually first but it didn't work.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Can the other non-cluster ARCserve server remotely manage the clustered one?
ASKER
Nope.
So what ever it is, it is only a problem with that system.
Reset the ARCserve System Account over there. It is done from within the ARCserve Server Account. Also make sure the Job Engine service is configured to logon as System.
Reset the ARCserve System Account over there. It is done from within the ARCserve Server Account. Also make sure the Job Engine service is configured to logon as System.
ASKER
Can you explain "Reset the ARCserve System Account over there. It is done from within the ARCserve Server Account." please? Thanks. Already setup to logon as System.
ASKER
btw, I think the error 14 had to do with something else. Just need to focus on the 1722.
1722 = the RPC server is unavailable
ARCserve components communicate via RPC, so it looks like something at the target end is blocking RPC.
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q167260
XCLN: How to Use RPCPing to Test RPC Communication
ARCserve components communicate via RPC, so it looks like something at the target end is blocking RPC.
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q167260
XCLN: How to Use RPCPing to Test RPC Communication
Sorry I missed you request.
To reset the ARCserve System Account.
Open the ARCserve Server Admin
From the menu bar select Admin, ARCserve Backup System Account.
Then re-enter the name and password.
To reset the ARCserve System Account.
Open the ARCserve Server Admin
From the menu bar select Admin, ARCserve Backup System Account.
Then re-enter the name and password.
ASKER
Hmmm, still not working. It was set to our domain admin account. I re-entered the password and attempted to connect but it failed. I tried restaring the services and that didn't help. I then tried the same with the local servers administrator account, but got the same results.
Any other ideas?
Any other ideas?
Was RPC connectivity verified?
Server XXX failed to authenticate the user admimistrator (EC=1722)
The error code is from the OS, 1722 = the RPC server is unavailable
The different parts of ARCserve communicate via RPC so this might be at the root of the problem.
Server XXX failed to authenticate the user admimistrator (EC=1722)
The error code is from the OS, 1722 = the RPC server is unavailable
The different parts of ARCserve communicate via RPC so this might be at the root of the problem.
ASKER
I should have followed your link earlier about the RPC test but I didn't. I have now. On the server I ran:
RPINGS -p TCP/IP
On my workstation I ran:
rpingdos -p tcpip -n 10.0.0.49 -c 4
It returned this back:
Binding failed with return code 0x6,
The Protocol sequence is not supported
RPC Binding returned (0x21)
The RPC Call failed
Could not bind using these parameters:
protocol sequence = ncacn_ip_tcp
network address = 10.0.0.49
endpoint = 2256
UUID = fe993211-13ec-101b-9932-00
Did I use the utility wrong? What now?
RPINGS -p TCP/IP
On my workstation I ran:
rpingdos -p tcpip -n 10.0.0.49 -c 4
It returned this back:
Binding failed with return code 0x6,
The Protocol sequence is not supported
RPC Binding returned (0x21)
The RPC Call failed
Could not bind using these parameters:
protocol sequence = ncacn_ip_tcp
network address = 10.0.0.49
endpoint = 2256
UUID = fe993211-13ec-101b-9932-00
Did I use the utility wrong? What now?
Looks like the usage is correct.
Try testing it by using the network address of the other ARCserve server that you can manage remotely.
Is there any filtering being done at a firewall or switch for RPC?
If there is another system in the same network segment see if the utility will work or give the same failure with that.
Try testing it by using the network address of the other ARCserve server that you can manage remotely.
Is there any filtering being done at a firewall or switch for RPC?
If there is another system in the same network segment see if the utility will work or give the same failure with that.
ASKER
I tried this on a server I can manage and I got the same results. I don't think this is a valid test. I also tried with Named Pipes but got the similar results.
I know that the cluster services uses RPC to communicate. It is configured to do it over a private network. Can that be the problem?
I know that the cluster services uses RPC to communicate. It is configured to do it over a private network. Can that be the problem?
Private network probably does mean that RPC is not going through.
Speak with your network guys about the problem. Perhaps they can open it up for this or maybe they already have some kind of remote control program setup. Something like terminal services or remote desktop that will let you remotely manage the system instead of using a remove ARCserve Manager.
Because it is on a private network that probably means it is a high security system and so what ever method you use should not comprimise that security. So bring up the problem with the Network Admin to first confirm that the private network would be preventing this comunication, and then what he suggests to work around the problem.
Speak with your network guys about the problem. Perhaps they can open it up for this or maybe they already have some kind of remote control program setup. Something like terminal services or remote desktop that will let you remotely manage the system instead of using a remove ARCserve Manager.
Because it is on a private network that probably means it is a high security system and so what ever method you use should not comprimise that security. So bring up the problem with the Network Admin to first confirm that the private network would be preventing this comunication, and then what he suggests to work around the problem.
ASKER
I probably wasn't clear enough when I said private network. The server is setup as a node in a 2 node cluster. Each node has 2 network cards. One is for the regular network traffic. The secondary cards simply plug one server right into the other. The internal Cluster communications use that network card specifically. The cluster communication uses RPC.
I was just brainstorming out loud, more or less. Is it possible that the RPC traffic isn't reaching the public network at all? Or does regular file server activity included RPC traffic, so we know that it is passing that on the public network.
Incidentally, I have an Arcserve r11.1 installed on a separate cluster that I can remote admin fine.
I was just brainstorming out loud, more or less. Is it possible that the RPC traffic isn't reaching the public network at all? Or does regular file server activity included RPC traffic, so we know that it is passing that on the public network.
Incidentally, I have an Arcserve r11.1 installed on a separate cluster that I can remote admin fine.
By default RPC communication is open.
When it fails is it asking for security info?
If so have you tried using an admin user that is local to the cluster system?
When it fails is it asking for security info?
If so have you tried using an admin user that is local to the cluster system?
ASKER
I've tried the local administrator account as well as the domain administrator account. I also tried setting up the arcserve account through arcserve manager as both of them and then trying again. It always comes back with the
Server XXX failed to authenticate the user admimistrator (EC=1722)
error.
Server XXX failed to authenticate the user admimistrator (EC=1722)
error.
I could be wrong about the RPC but all I can think of at this point is to verify RPC connectivity.
If that utility does not work for you perhaps one of the others will.
If that utility does not work for you perhaps one of the others will.
ASKER
I can connect to our other Arcserve server which is installed on a Windows 2000 Server Standard. Same Arcserve SP. An obvious difference is that one is on a cluster. I think this is a server side issue - something with the configuration there. Any other ideas?