Troubleshooting permissions errors 1

[packdragon]

The server that is running our backups is also a domain controller. It went down for a couple weeks while I worked with Microsoft to get it back up. When we finally did get it back up I ran backups of everything. All but 2 servers were backed up fine. Those two failed due to access denied, though I'm not sure why because they were working before.

In the Backup Selections when I try to navigate to those two servers a login dialog pops up. The last time this happened I added the backup user account to the local Administrators group and it was fixed. When I went to check it this time, that user is still a member of the local admin group, so the problem must be something else.

In checking the Event Log I did notice a few failed logins to my account at times like 2am when a backup would be running. I made sure all backup services were using the designated backup user account and they were. What else do I need to check? What could be using my account for login attempts?

 

[Qdog]

At the Backup Exec server, login as the Backup Exec services account.
1. Start|Run|\\remoteservername\c$ ...does it popup an Explorer window showing you contents of the remote server's C: drive? Or does it give you an access denied?

2. Open regedt32 and try to connect then browse the remote server's registry. See if you can add a value to a key in HKEY_LocalMachine. If you get access denied, there is a problem. This is a good test to see if a backup of system?state would work.

Each of these tests when conducted at the Backup Exec server while logged on as the BE services account will prove whether that account can get there from here.

What do you get access denied on the remote server, is it to the drives? System state? All?

You mentioned that the domain controller was down. Now that it is back up, you have problems. After all the above things, try the following:
-On the Backup Exec server running Windows 2000:
1. Close Backup Exec(BE) and stop all BE services.
2. Rename the bewinui.uni file in \Program Files\Veritas\Backup Exec\NT\Data folder to bewinui.old.
3. Open registry, HKLM/Software/Veritas/Backup Exec/Engine/NTFS, doubleclick Restrict Anonymous Support and change the value from 0-->1.
4 Create a new DWORD in the NTFS key called useAdSSCheck with value of 0.
5. Close registry editor and start BE services.
-On the remote server running:
1. Stop the Backup Exec Remote Agent for NT/2000 service.
2. Follow steps 1-3 above.
3. Start the Backup Exec Remote Agent for NT/2000 service.

 

[packdragon]

Thanks for these great tips! One of the two denied servers is a domain controller, and that one is denying me the System State. The other server is a member server and denying me everything.

When I checked the registry there was no item called RestrictAnonymousSupport. I did create useAdSSCheck as you mentioned however. On the remote servers there was no bewinui file, and no RestrictAnonymousSupport item in the registry either.

I seem to be able to browse the member server now through Backup Exec's Backup Selections interface. But when I click on the DC it still asks for a login. Should I create the RestrictAnonymousSupport value on the backup and client servers?

 

[packdragon]

After running a backup job, the member server is now being backed up just fine. However it is still not able to attach to the DC's system state. It says "The item was not found." That sounds odd to me. How do I make it find it?

 

[Qdog]

My previous comments assume that Backup Exec version 8.6 is installed. The bewinui.uni file is on the Backup Exec server only. Finally, in 8.6 the RestrictAnonymousSupport dword is created for you on the media server and also should be present on the remote server once a backup has used the remote agent.

If you are not running 8.6, you will not be able to utilize my post. Sorry.

Take care.

 

[packdragon]

How is it that I try to include as many details as possible about what I tried and I manage to leave out what version I'm running? Unbelievable. Anyway, I'm using 8.5, which is probably why that registry key isn't there. But thanks for all your help Qdog!

I did manage find a Veritas article that might help. It refers to a registry key in a different place. I think I'll try it out...

http://seer.support.veritas.com/docs/239059.htm