Problem Getting backup to run after password change

[techwtr]

I have talked to the ARcserve folks and they have yet to help me on this. I hope someone else has run across this. The user id I back the server up with has a chg password every 60 days. When the password changes, I immediately change the password in the existing backup job. I do a modify job, then pick security and chg password everywhere that I can change it ( source server and destination server). By the way I also go on that screen ( home page I believe) and go to the chg default server and change my password there as well. Some times I can get the password to take, other times not.

If I go to the server itself and setup the backup job on the Arcserve screens on the server I can get it to back up and except the new password. If I do it in the Manager on my workstation, it is up for grabs if the password takes or not. I couldn't keep playing with getting the server to backup, so with the holidays I just setup backup from the server screen, and put my backup job that I originally created on hold till I get back to work to further tweek with it. Anyone have a absolute 1-2-3 way to get the new password to be excepted when it changes? It has to be an issue with the Manager. I believe I have all the latest patches for the manager. Any ideas would be appreicated.

 

[GSC]

Hi,
I think that you need to take a look at your procedures before you try to solve this issue.
First of all why don't you set the password not to expire on your backup account?
By doing so you are saving you self a lot of headache and problems.
My feeling is that you get the password change right sometimes, since you say that it is working sometimes. Then when it is not working you are most likely not getting the password change right.

Hope it helps,
Let me know if you have any questions.

GSC

 

[speshalyst]

Hi Techwtr....
If you havent done it already...
Did you change the password for the ARCserve system account on the ARCserve Server Admin..

Assuming that you are using ARCserve2000, Open the ARCserve server admin, click on the "Admin" menu.
Select the system account option..

Delete and readd the user account info.

This should fix the issue..

Let us know

Cheers
Speshalyst

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

 

[techwtr]

I am using Arcserve 9 on a Novell server. I will check that tomorrow to see if that might help. I haven't look at server admin. Maybe that is were it is.

Thanks..

 

[techwtr]

I will probably go to using an id that doesn't change in the future. In the meantime, the best way around it appears to be to delete the backup job and recreate it. Once I did that the backup started running as it should.

 

[dholbrook]

Just a thought,

If deleting the job and re-creating the job solved the problem, then the password issue is with the user account which was set to own and run the job, not the services, etc. You must have set a password account when you established the job, and it is buried in the job. Each job can have a password set for the user who created the job or for the arcserve account, or some other valid user account, or for none (you find these when the job will not run except when the right user is logged on, like you . You also need to be careful that the accounts the services log on with do not have expiring passwords AND have the right level of access, like Backup operator or Admin level, so the backups can connect to the remote system, etc., otherwise they may not even run. Changing these passwords frequently will drive you nuts, as you will always miss one here or there, and may not even remember where they all are!

HTH,

David H.

 

[techwtr]

As admin, I have been running the backup jobs using my own id which does expire. I plan on setting up a new arcserve id with a password that doesn't change. A lot less hassles, and eliminates problems with backups. Thanks.

 

[davidmichel]

Here is a thought on using an account that does not change.

If you are good with security perhaps you can confirm this.
Isn't there a way to put a restriction on an account so it can only login from a specific system?

Thinking about the account does not really need to do a regular login. If some free time comes up I'll test it, but if any of you know please update us.

 

[dholbrook]

Some serious things to consider with an account that does not expire AND which has high level of access (like Backup or Admin level):

1. Make the password long and difficult, and at least 8 or more characters in length (14 is even better),
2. Make sure the password is very strong (NO words, mix in numbers, upper/lower case letters, and a sprinkle of non-letters or numbers,
3. Make sure you also have a second account with full access to change the original account's password if you forget it, change admin people, etc., (to cover the administrator was hit-by-the-bus syndrome), and this account should be changed frequently.
4. Store the password in a sealed envelope in a safe off site, just in case.
5. Be very restrictive at setting ANY services to run under a user account, unless it is absolutely necessary, and make a record of which services are set this way on each system. If services do need an account to run, DO NOT USES ANY REGULAR USER ACCOUNT, instead create a special account just for this situation and decide if this account will be exempt from the regular password changes (use the above rules!).

I find this also a good idea for all the local admin passwords for all non-DC systems too (which do not usually change anyway, and no one uses them), just in case you need to access the system later and no one can remember the local admin account information. In addition, you can restrict the special accounts you set up to ONLY be able to log on to specific systems as a further protection, especially if these accounts have to have something like a Domain admin level access. Lock them down as much as possible to protect against abuse.

One other safety step, split the backup and restore functions apart so the Backup operator can not restore, etc., just to provide additional safety if you are using non-expiring passwords.

HTH,

David Holbrook

PS: ARCServer should always have its own user account, do not use your ADMIN account for this purpose. Otherwise, if the ARCServe account gets cracked, YOU will be the party who has to answer as to why You were logging on to everywhere at odd hours!