0xe00084f9 and 0xe000846a errors during restore - failure connecting to agent

[Dt2020]

I'm on 20.6. My files have backed up correctly. I can see them on the tape when I go to the restore wizard. However whenever I try the restore to a different location like my desktop (I'm logged in as the user the services run as) I get

Final error: 0xe00084f9 - A communications failure has occurred between the Backup Exec job engine and the Agent for Windows.
Final error category: Resource Errors

If I try to restore to the original location I get

Final error: 0xe000846a - The resource could not be restored because an error occurred while connecting to the Backup Exec for Windows Servers Remote Agent.
Make sure that the correct version of the Remote Agent is installed and running on the target computer.
Final error category: Resource Errors

Backup exec is running on my file server so I am attempting to restore it on the same server - I'm not going to a remote machine at all. All the services are running. I've checked my permissions and all should be OK. Only thing my account is not a domain admin - it is a member of the local administrators group and has all of these permissions - some explicit and some as a member of the group.

Backup Exec account must have the following rights:
Act as part of the operating system (Windows 2000 only)
Backup files and directories
Create a token object
Logon as a batch job (Windows 2008 and higher) 
Logon as a service
Manage auditing and security log
Restore files and directories
Take ownership of files and other objects

Any suggestions would be greatly appreciated. I'm not in a position to use disk storage - all I have is my tapes.

[PJ_Backup]

A few thoughts:
 - this could well be a hardware error - can you run some drive diagnostics on your tape drive/library?
 - are you sure all the backups are running completely error free?
 - I would recommend checking the event logs (system & application) for error messages, and also the adamm log (in the Program Files\Symantec or Veritas\Backup exec\Logs directory). Scroll to the bottom then work backwards slowly looking for any relevant messages.
 - are you able to run an inventory and/or catalog job on your tapes?

 - although you say you're not in a position to use disk storage could you as just a temporary troubleshooting step create a disk storage and run a small backup to it (just a few GB) and test out a restore, to try and narrow down the problem. The only restriction with disk storage is Veritas don't recommend having dedupe storage & disk storage on the same volume, but it shouldn't effect anything else. You can then delete it after the tests.

 - when did this stop working? Do you know what has changed in the meantime?
 - are the permissions the same now as when it last worked?

[Dt2020]

Thanks for the reply. I'm not seeing any sign of problems with the hardware. I was onsite last week and there were no error lights and the diagnotics seem to be ok. The adamm log has some soft errors but no hard errors. The System log isn't showing any errors - the application log just show the failed restores. I can run an inventory job on the tape no problem

The backups are running error free. The backup job has no problem with the same agent that the restore is failing on  - from the backup log                                                                                                                                                          Backup Exec server is running Backup Exec version 20.0.1188.2718.                                                                              Agent for Windows(my server) is running Backup Exec version 20.0.1188.2718

Unfortunately i just don't have a drive I can use for disk (I had a look at this video https://www.youtube.com/watch?v=wPDPbrJC56Y and it made the drive unavailable in windows - is that correct?) and company policy won't allow me to attach anything external. 

We've done restores in the past but I honestly can't remember if we've done any since upgrading to 20.6 about 6 months ago. The permissions are applied via a group policy and are identical to what they would have been in the past.

[pkh]

Have you tried using a domain admin account?

[Dt2020]

Not yet - getting the account elevated to domain admin will be difficult due to company rules - I am asking. I'm not backing anything domain related up though. I just want to restore a file from the backup exec server to the backup exec server. Also the account is the same one I used in v15 when restores worked.

The account is a member of the local Administrators group on the server

[Dt2020]

Just tried it with a domain admin account and got the exact same error.

[Dt2020]

Working now with help from support - Had to go to Backup Exec Settings - Network and Security - and change Network Interface from "Use any available" to the specific entry and then change Protocol from "Use any available" to IPv4. Then unchecked Allow use of any available net interface, subnet or protocol......

[PJ_Backup]

Thanks for sharing that video - no that is not correct. Backup Exec never "causes the drive to just disappear"

Watching the video again you can see @ 58sec there are two locations to choose from:

C:\ (System drive) or "Available storage" (and not C: or E: ). So in the disk storage properties in the video (@2:37) where it shows a Path of \\?\Volume{790f0d31-0000-0000-0000-100000000000}\BEData\ this only looks like it does because the volume chosen wasn't originally assigned a drive letter.

If that drive is now assigned a drive letter in Windows via Disk Management, then Backup Exec would subsequently reflect this in its Path statement, which would dynamically change to eg F:\BEData\

I can confirm this having tested it extensively in a lab environment to double check that what is in the admin guide https://www.veritas.com/content/support/en_US/doc/59226269-140215363-1 is correct (see pg 317+).

You could even use the systemn drive for a disk storage volume, however this is not recommended for obvious reasons (due to the risk of filling up your system drive with backups).

I hope this video hasn't put anyone else off creating disk storage...