• EN

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

Show first post

43 comments

regnor
Userlevel 7
Badge +14

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.

Max M. | Systems Engineer @Veeam | VMCE/VMCA | former Legend & Vanguard
Chris.Childerhose
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.

Chris Childerhose - VMCA2022 | VMCE2023 | Veeam Vanguard 7* | Veeam Legend 3* | vExpert 5* | VCAP-DCV/VCP-DCV | Object First Ace | Cisco Champion | Twitter: @cchilderhose | Blog Site – https://just-virtualization.tech
vNote42
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!

Wolfgang | vnote42.net | @vNote42
I

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. 

vNote42
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 !

Wolfgang | vnote42.net | @vNote42
I

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.

JMeixner
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.

Jochen (Joe) Meixner | Veeam Vanguard 2024 | Veeam Legend 2021 - 2023 | Veeam Certified Architect (VMCA) 2022 | Twitter: @JoMeix | BlueSky: @jmeixner.bsky.social
regnor
Userlevel 7
Badge +14

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.

Max M. | Systems Engineer @Veeam | VMCE/VMCA | former Legend & Vanguard
vNote42
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.

Wolfgang | vnote42.net | @vNote42
X
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.

Chris.Childerhose
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.

Chris Childerhose - VMCA2022 | VMCE2023 | Veeam Vanguard 7* | Veeam Legend 3* | vExpert 5* | VCAP-DCV/VCP-DCV | Object First Ace | Cisco Champion | Twitter: @cchilderhose | Blog Site – https://just-virtualization.tech
X
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.

Chris.Childerhose
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.

Chris Childerhose - VMCA2022 | VMCE2023 | Veeam Vanguard 7* | Veeam Legend 3* | vExpert 5* | VCAP-DCV/VCP-DCV | Object First Ace | Cisco Champion | Twitter: @cchilderhose | Blog Site – https://just-virtualization.tech
vNote42
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

 

Wolfgang | vnote42.net | @vNote42
X
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.

vNote42
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?

Wolfgang | vnote42.net | @vNote42
regnor
Userlevel 7
Badge +14

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.

Max M. | Systems Engineer @Veeam | VMCE/VMCA | former Legend & Vanguard
X
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.

Comment


Terms & Conditions