03-06-2015 07:35 AM
I'm receiving these errors from virtual machines after a backup job
V-79-57344-38730 - Backup Exec was unable to authenticate with virtual machine '************' and was unable to collect the necessary metadata to restore individual application items. You cannot perform GRT-enabled restores of application data from this backup. You must edit the credentials for the host computer's backup job and then select the proper credentials for the virtual machine.
Restoring single files and folders seems to be still working from these machines.
I have single Hyper-V host (Windows Server 2012 R2) and these VM's are running on this host. Backup Exec 2014 is installed directly to host. Hyper-V host is a member of a workgroup and VM's are member of AD domain.
What credentials should I use when backing up these virtual machines? Credentials from local Hyper-V host or credentials from AD that these virtual machines belong?
03-06-2015 10:43 AM
This error refers to the Application GRT feature i.e. granular restore from Exchange, SQL, AD, Sharepoint.
The credentials which you specify for the backup job job must have appropriate permissions to access these applications.
04-27-2015 04:01 AM
This problem has unfortunately come back for us! We last resolved this problem by carrying out a reinstall of Backupexec 2014 v14.1 rev 1786 (64 bit) which is used to backup our VMs running on vmware 5.1, that are running Windows 2012 standard server. The actual login credentials were found to be correct, hence we reinstalled Backupexec. This only affects some of our VMs. There have been no changes to either Backupexec or the actual jobs. Any ideas?
V-79-57344-38730 - Backup Exec was unable to authenticate with virtual machine '\<path to VM>' and was unable to collect the necessary metadata to restore individual application items. You cannot perform GRT-enabled restores of application data from this backup. You must edit the credentials for the host computer's backup job and then select the proper credentials for the virtual machine.
04-27-2015 04:25 AM
When performing VMware backups (with APP GRT enabled) the ability to specify a different login account for the the host environment vs the guest environment exists.
If you edit the job definition, then at the bottom of the left pane (where the selections are shown) as well as an Edit button, there should another button relating to Credentials. Click this button
By default the resulting screen will show you the VCenter or ESX host and the datacenter objects with one set to a specified account and the other probably indicating same as it's parent.
However you can expand the datacenter object to see the individual VMs and each VM can then have a different account specified. Make sure these accounts are correct for whatever is inside each VM and if you change anything and then use the test option, make sure you click Apply before you click Test.
Note1: On top of the credentials needing to be correct, Application GRT also needs:
- the remote agent to be running inside of Each VM
- the trust to have been setup between each remote agent and the Backup Exec Server
- each VM be able to name resolve from the media server
- each VM being accessible via port 10000 from the media server
- agent publishing to have been configured back to the media server
It is possible that some of these not being set correctly would also result in the same job log message.
Note2: File System GRT does not need the same security due to how the mount vmdk operation works and therefore you can see a working file system GRT backup when the application part fails. ( Just because you have the wrong credentials or no communication with the remote agent inside the VM). A file system restroe back to original server hwiever would probably still fail if the credentials are wrong.
Note3: Similar settings exist for Hyper-V agent backups.
05-06-2015 02:39 AM
We have 2 seperate VMware 5.1 Hypervisors, each running Windows VMs.
Hypervisor 1 - VMs all backup with the ability to restore GRTs
Hypervisor 2 - VMs all backup without the ability to restore GRTs
If I run a scheduled job to back a single VM on Hypervisor 2 during the day, the VM is backed up with the ability to restore via GRT. The problem arises when the nightly backup job backs up all of the VMs on Hypervisor 2.
Therefore with the above said, the issue cannot possibly be:-
* Login credentials are correct, otherwise I would not be able to successfully backup with GRT through a seperate test job.
* The remote agent - as each VM is running the correct version.
* Name resolution from the VM of the media server. I have made sure that the "Enable the agent for windows to publish information to the backup exec servers in the list" has both the hostname, ip address and FQDN of the media server. This is the only difference I saw with VMs running on Hypervisor 1 and 2. Will the order of these entries make any difference though?
* Each VM is accessible via port 1000 as there are not internal firewalls running.
Is there anything that I can do to check further as to what may be causing this problem, which only just came back 2 weeks ago?