[What (else) is new in v11 - VII] Persistent guest agent


Userlevel 7
Badge +13

Default behavior in VBR (incl. v11!): When a VM gets application-aware backed up, runtime components gets installed at start of job and are removed at the end. With v11 we have the option to install them persistent!

 

 

This increases security! No Admin-Share and VIX-access is necessary any more. But it is required to deploy the Veeam Installer Service on the VMs you want to use persistent components.

 

 

This can be done by manual installation, Group policy roll-out, or by adding the VM to managed Servers.

 

When everything works fine, components are installed persistently:

 

 

If you enable this feature and something does not work (as installer is not deployed, ..), VBR tries to run non-persistent components.


43 comments

Userlevel 1

I have seen that the service runs as a local system. Does this eliminate the need to enter guest OS credentials into the backup job? Because it’s a pain to store a domain admin on a backup server to backup the domain controllers. It would be great if Veeam uses the service user for this and no longer needs the guest credentials.

You still need guest credentials to use for Application Aware processing.  This just helps with the backup process and having to spin up the agent each job run, now it uses the persistent agent.

Do you know why? Application Aware processing aka VSS Writer can be started by the system account as well. For example, Quest's backup solution use this way. It would make the IT environment so much more secure.

You do NOT need an administrator account in each situation! See required permission page for more information:
https://helpcenter.veeam.com/docs/backup/vsphere/required_permissions.html?ver=110#performing-guest-processing

 

To back up Microsoft Active Directory data, the account must be a member of the built-in Administrators group.

I have seen that the service runs as a local system. Does this eliminate the need to enter guest OS credentials into the backup job? Because it’s a pain to store a domain admin on a backup server to backup the domain controllers. It would be great if Veeam uses the service user for this and no longer needs the guest credentials.

You still need guest credentials to use for Application Aware processing.  This just helps with the backup process and having to spin up the agent each job run, now it uses the persistent agent.

Do you know why? Application Aware processing aka VSS Writer can be started by the system account as well. For example, Quest's backup solution use this way. It would make the IT environment so much more secure.

You do NOT need an administrator account in each situation! See required permission page for more information:
https://helpcenter.veeam.com/docs/backup/vsphere/required_permissions.html?ver=110#performing-guest-processing

 

To back up Microsoft Active Directory data, the account must be a member of the built-in Administrators group.

Just wondering, isn’t this required with Quest? And do you have the same granular restore options with Quest?

Sorry for my late response, with Quest it isn’t required and you have the same granular restore. But during the restore you have to enter domain admin credentials, but not for the backup.

Userlevel 7
Badge +12

I think the primary reason why we need administrative permissions is, that Veeam needs to (temporarily) install its helper services or runtime processes. The persistent guest agent only changes the way how those are deployed, but it's not a full agent component. I'm sure this will change in future releases as many organizations request limited permissions, but for now we'll have to work with it that way.

Veeam Agent for Windows would probably be more comparable with other solutions, like Quest. It's a full-blown agent and does all the processing without special permissions.

Userlevel 7
Badge +13

I have seen that the service runs as a local system. Does this eliminate the need to enter guest OS credentials into the backup job? Because it’s a pain to store a domain admin on a backup server to backup the domain controllers. It would be great if Veeam uses the service user for this and no longer needs the guest credentials.

You still need guest credentials to use for Application Aware processing.  This just helps with the backup process and having to spin up the agent each job run, now it uses the persistent agent.

Do you know why? Application Aware processing aka VSS Writer can be started by the system account as well. For example, Quest's backup solution use this way. It would make the IT environment so much more secure.

You do NOT need an administrator account in each situation! See required permission page for more information:
https://helpcenter.veeam.com/docs/backup/vsphere/required_permissions.html?ver=110#performing-guest-processing

 

To back up Microsoft Active Directory data, the account must be a member of the built-in Administrators group.

Just wondering, isn’t this required with Quest? And do you have the same granular restore options with Quest?

Userlevel 1

I have seen that the service runs as a local system. Does this eliminate the need to enter guest OS credentials into the backup job? Because it’s a pain to store a domain admin on a backup server to backup the domain controllers. It would be great if Veeam uses the service user for this and no longer needs the guest credentials.

You still need guest credentials to use for Application Aware processing.  This just helps with the backup process and having to spin up the agent each job run, now it uses the persistent agent.

Do you know why? Application Aware processing aka VSS Writer can be started by the system account as well. For example, Quest's backup solution use this way. It would make the IT environment so much more secure.

You do NOT need an administrator account in each situation! See required permission page for more information:
https://helpcenter.veeam.com/docs/backup/vsphere/required_permissions.html?ver=110#performing-guest-processing

 

To back up Microsoft Active Directory data, the account must be a member of the built-in Administrators group.

Userlevel 7
Badge +13

I have seen that the service runs as a local system. Does this eliminate the need to enter guest OS credentials into the backup job? Because it’s a pain to store a domain admin on a backup server to backup the domain controllers. It would be great if Veeam uses the service user for this and no longer needs the guest credentials.

You still need guest credentials to use for Application Aware processing.  This just helps with the backup process and having to spin up the agent each job run, now it uses the persistent agent.

Do you know why? Application Aware processing aka VSS Writer can be started by the system account as well. For example, Quest's backup solution use this way. It would make the IT environment so much more secure.

You do NOT need an administrator account in each situation! See required permission page for more information:
https://helpcenter.veeam.com/docs/backup/vsphere/required_permissions.html?ver=110#performing-guest-processing

 

Userlevel 7
Badge +20

I have seen that the service runs as a local system. Does this eliminate the need to enter guest OS credentials into the backup job? Because it’s a pain to store a domain admin on a backup server to backup the domain controllers. It would be great if Veeam uses the service user for this and no longer needs the guest credentials.

You still need guest credentials to use for Application Aware processing.  This just helps with the backup process and having to spin up the agent each job run, now it uses the persistent agent.

Do you know why? Application Aware processing aka VSS Writer can be started by the system account as well. For example, Quest's backup solution use this way. It would make the IT environment so much more secure.

That is just the way Veeam does things and requires an account for this.

Userlevel 1

I have seen that the service runs as a local system. Does this eliminate the need to enter guest OS credentials into the backup job? Because it’s a pain to store a domain admin on a backup server to backup the domain controllers. It would be great if Veeam uses the service user for this and no longer needs the guest credentials.

You still need guest credentials to use for Application Aware processing.  This just helps with the backup process and having to spin up the agent each job run, now it uses the persistent agent.

Do you know why? Application Aware processing aka VSS Writer can be started by the system account as well. For example, Quest's backup solution use this way. It would make the IT environment so much more secure.

Userlevel 7
Badge +20

I have seen that the service runs as a local system. Does this eliminate the need to enter guest OS credentials into the backup job? Because it’s a pain to store a domain admin on a backup server to backup the domain controllers. It would be great if Veeam uses the service user for this and no longer needs the guest credentials.

You still need guest credentials to use for Application Aware processing.  This just helps with the backup process and having to spin up the agent each job run, now it uses the persistent agent.

Userlevel 1

I have seen that the service runs as a local system. Does this eliminate the need to enter guest OS credentials into the backup job? Because it’s a pain to store a domain admin on a backup server to backup the domain controllers. It would be great if Veeam uses the service user for this and no longer needs the guest credentials.

Userlevel 7
Badge +13

In https://helpcenter.veeam.com/docs/backup/vsphere/runtime_process.html?ver=110 it says, 

“You can let the Installer Service install the components automatically during the first run of the backup job with enabled guest processing of this VM by persistent agents”

How would I install it using this method? With a job script? I currently have enabled guest processing and the “Use persistent quest agent (optional)” is checked. I might be missing a step.

First you need to install the Installer Service in the VM. This service handles the agent installation and update.

Userlevel 7
Badge +12

In https://helpcenter.veeam.com/docs/backup/vsphere/runtime_process.html?ver=110 it says, 

“You can let the Installer Service install the components automatically during the first run of the backup job with enabled guest processing of this VM by persistent agents”

How would I install it using this method? With a job script? I currently have enabled guest processing and the “Use persistent quest agent (optional)” is checked. I might be missing a step.


Installing the service via the backup job will only work if you initially open all necessary ports. In your case, if you want to limit the open ports, then I would recommend to pre-install the service manually.

Userlevel 7
Badge +17

In https://helpcenter.veeam.com/docs/backup/vsphere/runtime_process.html?ver=110 it says, 

“You can let the Installer Service install the components automatically during the first run of the backup job with enabled guest processing of this VM by persistent agents”

How would I install it using this method? With a job script? I currently have enabled guest processing and the “Use persistent quest agent (optional)” is checked. I might be missing a step.


No, the agent is installed automatically during the run of the backup job.
Without “Use persistent quest agent (optional)” checked the agent is installed at each runtime. And with this checked it is installed at the first runtime and remains on the system.

Please read this thread as there are some difficulties to get this running.

In https://helpcenter.veeam.com/docs/backup/vsphere/runtime_process.html?ver=110 it says, 

“You can let the Installer Service install the components automatically during the first run of the backup job with enabled guest processing of this VM by persistent agents”

How would I install it using this method? With a job script? I currently have enabled guest processing and the “Use persistent quest agent (optional)” is checked. I might be missing a step.

Userlevel 7
Badge +13

This looks promising, I will try it on my VMs. We normally have to open a lot of ports on our VMs to get our backups to work properly. 

Let us know, how it works for you @ITSysTech !

This looks promising, I will try it on my VMs. We normally have to open a lot of ports on our VMs to get our backups to work properly. 

Userlevel 7
Badge +13

So, our problem has been solved. It looks like it wasn't the bug within the guest interaction proxy but rather the user account which is used for the connection. Although installing the guest interaction proxy worked and Veeam was also able to use the VM as a hot-add proxy, it failed to connect to the persistent agent via the guest interaction proxy. At the end is was the format of the user which caused the problem. I had entered only the username which did work on the first place, but as it's a local account, it should have been added like this: Hostname\Username

Neither I nor support did suspect a problem with the account as everything else worked; even test credentials succeeded. Initially I had added it with the hostname but wasn't able to connect, so I've tried different formats and ended up with just the username.

Thank @regnor for this update!

Userlevel 7
Badge +20

So, our problem has been solved. It looks like it wasn't the bug within the guest interaction proxy but rather the user account which is used for the connection. Although installing the guest interaction proxy worked and Veeam was also able to use the VM as a hot-add proxy, it failed to connect to the persistent agent via the guest interaction proxy. At the end is was the format of the user which caused the problem. I had entered only the username which did work on the first place, but as it's a local account, it should have been added like this: Hostname\Username

Neither I nor support did suspect a problem with the account as everything else worked; even test credentials succeeded. Initially I had added it with the hostname but wasn't able to connect, so I've tried different formats and ended up with just the username.

Nice to see it solved.

Userlevel 7
Badge +12

So, our problem has been solved. It looks like it wasn't the bug within the guest interaction proxy but rather the user account which is used for the connection. Although installing the guest interaction proxy worked and Veeam was also able to use the VM as a hot-add proxy, it failed to connect to the persistent agent via the guest interaction proxy. At the end is was the format of the user which caused the problem. I had entered only the username which did work on the first place, but as it's a local account, it should have been added like this: Hostname\Username

Neither I nor support did suspect a problem with the account as everything else worked; even test credentials succeeded. Initially I had added it with the hostname but wasn't able to connect, so I've tried different formats and ended up with just the username.

Userlevel 7
Badge +13

So, today support came to the conclusion that it's a bug withing the guest interaction proxy and not directly with the persistent guest agent. We're waiting for the hotfix/patch now.

Thanks for the update!

Userlevel 7
Badge +12

So, today support came to the conclusion that it's a bug withing the guest interaction proxy and not directly with the persistent guest agent. We're waiting for the hotfix/patch now.

Userlevel 7
Badge +12

None, except for Windows Defender 😉

I've also posted it in the forums: https://forums.veeam.com/post424005.html?sid=d92af730896c5f80f565449959eb3704#p424005

Userlevel 7
Badge +20

What antivirus is being used? 🙂

Userlevel 7
Badge +12

@MicoolPaul I've created a Wireshark capture for Veeam Support from both the proxy and the guest. It doesn't look like they've found the cause in those captures as we have a new remote session on Monday. 

The necessary ports are reachable which we have verify via powershell. And you can also see in the logs that the proxy is able to connect to the guest, it starts uploading all other Helper files and then it just fails.

Userlevel 7
Badge +20

I think you'll see in the GUI that the persistent agent isn't reachable. At least the logs show which way is used.

In our case we see the following:

Failed to inject guest runtime using guest interaction proxy, failing over to backup server
Failed to inventory guest system: Veeam Guest Agent is not started

The non-persistent way is also not working as the Admin Shares aren't available.

Ah, I see. The first Failed-message I know. It is green-marked. I guess the second is red?

Yes it is. The backup server itself can't connect to the guest VM, so finally guest processing is falling.

I hope to receive a solution on Monday or else I'll setup an alternative.

Hey guys, have either of you done a packet capture on this yet? I’d expect this to be a firewall issue. Be good to validate the port we see Veeam connect to is as expected and the endpoint’s firewall is permitting it and we see the traffic on that device.

Userlevel 7
Badge +12

I think you'll see in the GUI that the persistent agent isn't reachable. At least the logs show which way is used.

In our case we see the following:

Failed to inject guest runtime using guest interaction proxy, failing over to backup server
Failed to inventory guest system: Veeam Guest Agent is not started

The non-persistent way is also not working as the Admin Shares aren't available.

Ah, I see. The first Failed-message I know. It is green-marked. I guess the second is red?

Yes it is. The backup server itself can't connect to the guest VM, so finally guest processing is falling.

I hope to receive a solution on Monday or else I'll setup an alternative.

Comment