Strange authentication failure with BAB R11.5 SP2 3

[trilix]

Very strange authority problem in ArcServe 11.5 SP2

When I check the credentials through "Modify user name and password" (rightclick on a backupjob). One NT machine gives me a failed authentication message. But when I do a complete Preflight check of that backupjob, all is succesfull.

This is the error through "Modify user name..."
Server X failed to authenticate the user GLOBAL\s-bnlbackup (EC=1219). Please verify that the user name & password is correct.

A guy from CA has looked for 2 hours on my server through remote control, but he could not solve it...

 

[vschumpy]

run net helpmsg 1219 in a CMD window and you will see it is essentially a session credential conflict - you are already logged onto the machine you want to backup with another account.

 

[trilix]

I see yes. But I don't understand where he gets this errormessage from. I've already rebooted the specific server and it's not logged on to.

Is there maybe a cache that's causing this problem?

 

[speshalyst]

remove all network maps to that specific remote server..

"Net use * /d" , whtouht the quotes, should do it if it ok to remove ALL network maps..

So it Shall be Written!
So it Shall be Done!!

 

[trilix]

Thanks it worked! Unbelievable how simple it can be

 

[trilix]

OK, my backup from last night has failed again. And again it's an authentication problem to the same NT server.

This is what I get :
E8535 Failed to receive data from the client agent. (ADDRESS=10.64.3.23 (BE-TES10), EC=9, COMMAND=0)

E8533 Request denied by the client agent. User or password is invalid. (ADDRESS=@0.0.0.0 (BE-TES10) (113))

My Preflight check and individual server check are all successfull.

 

[vschumpy]

Patch up - more than likely your client agent is at a higher version or patch level than your host server.

 

[trilix]

My backup server is 11.5 SP2 and my client agents are 11.5 unpatched.

The problem only begun when I changed the backupaccount password. Before that everything went ok.

Last friday I made a backup of only one server as a test, and it went successfully. Today with the normal backup, that same sever gives authentication problems again.

 

[mcwillystyle]

I had the same issue before I went to AD. I had to change the pswd in "modify the job" of every backup. I would get failure to authenticate on 2 servers but not the others. Hope this helps.

 

[trilix]

The problem is solved. When calling to CA Helpdesk I got another guy on the phone and he told me that I also had to change the password in the Disaster Recovery option.

So if you ever plan to change your backupaccount credentials, it has to be changed at 3 places.

1. the backupjobs
2. Server Admin
3. Disaster Recovery

 

[phanbui]

Trilix. Thank you for sharing. I've had a similar problem. The backup didn't run after I changed the "root" and "caroot" password. The backup job was placed on "HOLD." I changed the "caroot" password from the "csetup" command, and the "root" password via Linux and ARCserve GUI. I went to Job Status Manager to update the "root" password and saved the job script from re "submit" as I had been told. I just resubmitted the job to run tonight. If the problam wasn't resolved, it's likely that I will have to change the Disaster Recovery Password. So how do I change it? Your advice and feedback are greatly appreciated.

 

[trilix]

Hello Phanbui,

The credential I'm talking about is the account Brightstor uses to access the filesystems it's going to backup. But fyi you click on "Create Bootkit" under Wizards tab.

The caroot is something else. It's an account internal to Brightstor, but has no rights to the filesystems. Have you also changed the caroot credentials in the Server Admin?

Goto Server Admin and click "Admin" -> "Select Brightstor ARCServe Backupserver..."

 

[trilix]

Phanbui,

Fyi. This is a link to the knowledge base of CA, on what caroot exactly is. Maybe this helps also.

http://supportconnect.ca.com/sc/kb/...&docid=268777&bypass=yes&fromscreen=kbresults

 

[phanbui]

Good morning Trilix. Thanks for your quick response. What I did was that I ran both command "cauth_setup" and "csetup" and set the "root" equivalence to "caroot" as it had motioned in the "CA" page. I reentered the "root" password from the "Server Backup Manager," and from the "Job Status Manager" I resubmit the job. I was a little bit confused from the "Server and Agent Information" dialog window when saving the script. I believed I didn't save it at the first time when modifying the schedule. I clicked on [OK] instead. When it asked me if I want to save the script, I responded 'y' and then clicked [SAVE]. I would probably [SAVE] it when I modified the schedule, not from saving the script. I changed the password on Tuesday and Tuesday night the backup didn't run. So, yesterday I went through the process, and did it a little bit different from the first time. I saved it from the schedule's modification. I was hoping that the backup job ran last night. If not, I tried it one more time as you have suggested. Also, I'm wondering what's happening to the previous backup tapes, which were backed up from a different "caroot" and "root" password. Would it affect the restoration? Shouldn't I change the "caroot" password at all for this reason? Also, should it matter if the "root" and "caroot" passwords are different? From the previous setup, the "root" and "caroot" password somehow were the same. However, when I updated them I gave them a different password to promote the system security. Would there be any suggestion on these? Thank you so much Trilix. You assistance and concerns are greatly appreciated.

 

[phanbui]

Thanks Trilix. The problem has been resolved. I updated the root password from the "Backup Manager," and resubmit the job from the "Job Status Manager." It seemed to work fine now. I value your great advice.