Veeam Restore Failed To Install Guest Agent Control

Veeam File Restore Failed To Install Guest Agent Control
Veeam Restore Failed To Install Guest Agent Control

0 Flares Twitter 0 Facebook 0 Google+ 0 LinkedIn 0 Email - 0 Flares Since Microsoft introduced VSS libraries, it’s a smart way of doing backup using them, in order to guarantee a consistent backup of applications supporting them. Veeam can do backups without the help of permanent agents inside the virtual machines, anyway if you want to do a VSS-based backup, Veeam deployes (and removes when the backup is completed) a small agent in the Windows VM in order to cohordinate VSS tasks. Usually, this is done by connecting to the target VM via network. But, what happens when for any reason Veeam is in another network of the one used by the virtual machine, or they cannot communicate to each other? For example an IIS webserver in a DMZ network that cannot be reached from the network where Veeam server is connected to? In these situations we can really appreciate VMware VIX libraries, and the way Veeam decided to use them. I found this, dated 2008, they noentheless explains in an awesome way what those libraries can do.

Basically, they allow for direct interaction between the guest operating system inside a VM using the hypervisor running it, without any need for network connectivity. Among the several activities you can do, you can copy files, start and stop services, and run programs inside the guest VM. Veeam has taken advantage of these libraries to allow VSS-based backups, even when the VM cannot be reached via network. To show you this, I created a small test in my lab, by deploying a Windows 2008 R2 VM with no network connection at all: I then configured a quick backup job in Veeam, without any custom parameter other than the use of VSS libraries, just to see what was going to happen: The backup was “simply” complteted successfully. To be honest, Veeam first tries to connect as usual via RPC, but right because the VM does not have any IP address, it fails and it then tries to use VIX libraries. You can appreciate the intimate procedure by looking at the relevant log parts: 14:00:20 Info VssGAConn('vix-test') Initializing VSS guest agent connection.

14:00:20 Error Failed to connect to guest agent: unable to obtain guest IP address. At Veeam.Backup.VssProvider.CVssGAConnection.ConnectViaRpc 14:00:20 Error at Veeam.Backup.VssProvider.CVssGAConnection.CreateEx 14:00:20 Info VssGAConn Connecting to guest via vix, hostIp '10.2.50.111', postPort '443', hostUser 'SKUNKWORKSadministrator', vmVmx 'qnap259 vix-test/vix-test.vmx', vmUser 'vix-testadministrator' 14:00:20 Info Connecting to host 10.2.50.111 over VIX library. Login: SKUNKWORKSadministrator. 14:00:26 Info Temporary file C:UsersADMINI1AppDataLocalTempvmware161 created. 14:00:26 Info Copying files form host C:Program FilesVeeamBackup and ReplicationVSSVeeamGuestAgentsVeeamVixProxy.exe to guest C:UsersADMINI1AppDataLocalTempvmware161.

Veeam File Restore Failed To Install Guest Agent Control

14:00:27 Info Connecting to host 10.2.50.111 over VIX library. Login: SKUNKWORKSadministrator. 14:00:27 Info Enter CVeeamVssGAInstaller::GetGateState 14:00:28 Info Temporary file C:UsersADMINI1AppDataLocalTempvmware185 created. 14:00:28 Info Running program C:UsersADMINI1AppDataLocalTempvmware161 -func GetServiceState -out 'C:UsersADMINI1AppDataLocalTempvmware185' -svcname 'VeeamVssSupport'. 14:00:30 Info Copying files form guest C:UsersADMINI1AppDataLocalTempvmware185 to host C:WindowsTEMPifd4720.tmp. 14:00:31 Info Deleting file C:UsersADMINI1AppDataLocalTempvmware185 in guest.

14:00:32 Info Leave CVeeamVssGAInstaller::GetGateState 14:00:32 Info VssGAConn('vix-test') Agent state: 'EVeeamVssNotInstalled'. 14:00:32 Info VssGAConn('vix-test') Installing agent.

14:00:32 Info Enter CVeeamVssGAInstaller::Install 14:00:32 Info Installing agent. As you can see, since the RPC connection has failed, Veeam connects to vCenter (10.2.50.111) and from here to the VM via VIX, using the same credentials I specified in the job (vix-testadministrator), since the VM is not joined to my lab domain “SKUNKWORKS”. VIX connection is successful, and Veeam is able to install the temporary agent into the VM.

How cool is that? If you also want to remove the initial error, and save some seconds in the job execution, since Veeam Backup & Replication v6.1 patch 1 (build 6.1.0.205) you can switch the VSS connection order, telling Veeam to try VIX connection first. You can see how to do it in the of that build: Added new registry value that reverses the sequence of application-aware processing, making jobs try network-less processing mode before network one. HKEYLOCALMACHINESOFTWAREVeeaMVeeam Backup and Replication DWORD: InverseVssProtocolOrder Value = 1 To disable (default behavior), value is 0 (false) So, after I configured the new registry key as described, I run again the same backup job: First thing you can see, “Preparing guest for hot backup” now lasted 15 seconds instead of 21, meaning something has really changed.

Veeam Restore Failed To Install Guest Agent Control

But, as before, the detailed log is where you can appreciate the configuration change: 14:39:16 Info VssGAConn('vix-test') Initializing VSS guest agent connection. 14:39:17 Info VssGAConn Connecting to guest via vix, hostIp '10.2.50.111', postPort '443', hostUser 'SKUNKWORKSadministrator', vmVmx 'qnap259 vix-test/vix-test.vmx', vmUser 'vix-testadministrator' 14:39:17 Info Connecting to host 10.2.50.111 over VIX library. Login: SKUNKWORKSadministrator. 14:39:24 Info Temporary file C:UsersADMINI1AppDataLocalTempvmware175 created. 14:39:24 Info Copying files form host C:Program FilesVeeamBackup and ReplicationVSSVeeamGuestAgentsVeeamVixProxy.exe to guest C:UsersADMINI1AppDataLocalTempvmware175. 14:39:25 Info Connecting to host 10.2.50.111 over VIX library.

14:39:26 Info Running program C:UsersADMINI1AppDataLocalTempvmware175 -func GetServiceState -out 'C:UsersADMINI1AppDataLocalTempvmware215' -svcname 'VeeamVssSupport'. 14:39:28 Info Copying files form guest C:UsersADMINI1AppDataLocalTempvmware215 to host C:WindowsTEMPifd6AC3.tmp. 14:39:29 Info Deleting file C:UsersADMINI1AppDataLocalTempvmware215 in guest. 14:39:30 Info Leave CVeeamVssGAInstaller::GetGateState 14:39:30 Info VssGAConn('vix-test') Agent state: 'EVeeamVssNotInstalled'.

14:39:30 Info VssGAConn('vix-test') Installing agent. You can see as now Veeam has started first to connect via VIX libraries, without trying first a connection via network.

So, if you have several virtual machines you cannot reach via network, maybe you can configure Veeam to use VIX libraries as its primary backup mode for VSS. Great article, Luca!

Just a small addition, but important, IMO: using VIX APIs are of course a good way of backing up / replicating Windows VMs in a consistent way with Veeam, without having network access to them. But this mode has a limitation that “classic” mode (network-based) doesn’t have: you either need to disable UAC or use exactly the “well-known” administrator accounts (. ADMINISTRATOR or DOMAIN ADMINISTRATOR). Other administrative credentials that are not exactly “ADMINISTRATOR” will fail. A full description of this issue can be found at: Danilo.