Skip to main content
  • EN

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.

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.

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.

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!

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. 

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 !

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.

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.


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.

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.

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.

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.

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.

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.

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

 

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?

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.

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.

Comment


Terms & Conditions