Doc fault? - guest agent deployment process

[AlexHeylin]

Looking at https://helpcenter.veeam.com/docs/backu ... ml?ver=110



Surely "Is job-required persistent component installed?" = Yes, should link to "Use persistent agent component for guest processing", not "Job fails"?

[Mildur]

Hi Alex

On first thought, you should be right.
I will run a test tomorrow in my lab to confirm the behavior.

Thanks,
Fabian

[AlexHeylin]

Thanks Mildur.

I've got an issue in production now where the persistent agent being installed isn't enough - and it refuses to work. It seems to require access to admin$ - even though the agent is already there for it to talk to. Access to admin$ is being problematic "username / password wrong", even though they're correct. That's why I've gone with the persistent agent. As the VM being backed up is a workgroup server - the remote access VBR needs to install the agent is known to be quirky - but I thought part of the reason for persistent agent was to avoid this by allowing the agent to be preinstalled so VBR can just talk to the agent (which because it's local should avoid the remote access quirks). I've not had a chance to lab this, or open a support case on it yet.

While researching that issue, I came across this - and I hope the image is wrong because that's easier to change than the code. Obviously the backup failing because the persistent agent IS installed is not sensible logic.

[Regnor]

You're right, the image looks confusing or maybe it's wrong.
With the Persistent Guest Agent access to the admin shares is no longer required. Only if it fails, Veeam will try to go this way as a fallback.
Have you installed the Veeam Installer Service on the VM? And if you're not using the built-in Administrator, you'll have to set the LocalAccountTokenFilterPolicy registry key.

[Mildur]

Hi Alex

I'll ask our tech writers to have a look at this page in the user guide.
If install service doesn't answer, but the persistent guest agent does, it should work. Also talked to one of my colleagues this morning and it should work.

I've got an issue in production now where the persistent agent being installed isn't enough - and it refuses to work. It seems to require access to admin$ - even though the agent is already there for it to talk to.

That sound strange. Maybe you can open a case and have our support team check the logs.

Best,
Fabian

[AlexHeylin]

Have you installed the Veeam Installer Service on the VM? And if you're not using the built-in Administrator, you'll have to set the LocalAccountTokenFilterPolicy registry key.

I did install the installer service as per

you only need to pre-install VeeamInstallerSvc.msi

and I'm using the .\Administrator account (magic SID) - but that account always gets access denied (wrong password) in VBR but works fine in net use etc I've reentered the password into VBR multiple times, this is not the the issue. I've not set, and should not need, LocalAccountTokenFilterPolicy.

Because VBR gets access denied the installer service could not install (weird as I expected this to work as that account works fine in EVERYTHING except VBR, locally and remotely), I then grabbed the MSI for the persistent agent and installed that - however I now realise it needs a config file which I did not create.

[AlexHeylin]

I'll ask our tech writers to have a look at this page in the user guide.

Thanks

If install service doesn't answer, but the persistent guest agent does, it should work. Also talked to one of my colleagues this morning and it should work.

So the image is wrong, and I'm not going mad
Even though this currently doesn't work for me because >>>

That sound strange. Maybe you can open a case and have our support team check the logs.

When I've finished my VMCE training (thanks Veeam!), I'll open a case with support to investigate. I know I messed up the persistent agent install manually as I didn't copy / create the config file. I don't think there's any / supported way to get this config and manually install the agent (not rely on installer service, which didn't work).

[Mildur]

Hi Alex

Unfortunately the user guide is correct. Technical writers confirmed it with our QA. I also run a short test in my lab.
If you remove the installer service, the job will fail.

But I'm still confused by the screenshot in the user guide. I'll continue to work with our technical writers. Fallback to admin share at the second last line in my session details is not documented in our user guide.

I know I messed up the persistent agent install manually as I didn't copy / create the config file. I don't think there's any / supported way to get this config and manually install the agent (not rely on installer service, which didn't work).

You only have to install only the installer service by one of the mentioned methods in our user guide.
The persistent guest agent components will be deployed over port 6160 to the installer service the first time the backup job runs. Admin$ is not required to deploy the persistent components.

hen I've finished my VMCE training (thanks Veeam!), I'll open a case with support to investigate.

Enjoy

Best,
Fabian

[Regnor]

and I'm using the .\Administrator account (magic SID) - but that account always gets access denied (wrong password) in VBR but works fine in net use etc I've reentered the password into VBR multiple times, this is not the the issue. I've not set, and should not need, LocalAccountTokenFilterPolicy.

Have you also tried to use HOSTNAME\Administrator?

[AlexHeylin]

Hi Fabian,
Thanks for testing this.

Unfortunately the user guide is correct. Technical writers confirmed it with our QA. I also run a short test in my lab.
If you remove the installer service, the job will fail.

It may be "correct" - but it seems to also be wrong, because both you and I have demonstrated that what the diagram says (Persistent Agent Installed = Yes -> Immediate Job Fail) is not what happens. At the very least, it attempts to connect to the admin$ share (which is documented as only happening if Persistent Agent Installed = No. Something seems to smell here - I don't know if it's docs, code, or logic - but there's an aroma in the air.

What is the logic in finding that the required agent IS already installed, then failing the job?
"If my prerequisite is met I'm going to refuse to so any work and hard fail - you must REMOVE the software I require to be installed, then I'll install it again THEN I might work" Hmm. Suspect.

But I'm still confused by the screenshot in the user guide. I'll continue to work with our technical writers. Fallback to admin share at the second last line in my session details is not documented in our user guide.

I agree - that's what I'm seeing in production.

You only have to install only the installer service by one of the mentioned methods in our user guide.
The persistent guest agent components will be deployed over port 6160 to the installer service the first time the backup job runs. Admin$ is not required to deploy the persistent components.

I'm going to try removing the agent and installer service, then ensure I install the installer as per guide. However, given the point of this (in this instance) is to avoid dealing with the admin$ refusing valid credentials - I found installing the installer service did not help, and it still complained about credentials. It's like those creds are valid unless Veeam uses them. They work perfectly for everything else including

Code: Select all

net use z: \\vmname\admin$ /user:administrator

from the VBR machine.

It might be that I'm confusing things here by expecting the persistent agent / deployment process to deal with a situation that it won't / can't (currently). However that situation (admin$ issues) seems to be the most compelling reason to use the persistent agent, so if it can't cope then there's an opportunity to improve there.

I'll tidy up, try above, and open a support case.

Thanks

[AlexHeylin]

Have you also tried to use HOSTNAME\Administrator?

I have tried that. Unfortunately VBR still says username and password wrong (error 5 and 1326).

[AlexHeylin]

This gets more weird! After removing the credentials entirely from creds manager then adding them again to the job (same format ".\administrator") now when I run Test Now it fails to connect to Admin$ with

Code: Select all

Cannot connect to the admin share. Host:  [VMNAME]. Account: [.\Administrator].;Unable to establish connection via the admin share [b]because the guest agent is available[/b];

Now the job works - and appears to not mention using the persistent agent...


I know logically the best explanation is that the creds were wrong in the VBR DB - but I've re-entered the username and password at least five times in various formats. Only deleting entirely and recreating got it to work.

Note I did NOT remove or reconfigure the persistent agent. It either didn't need any config, or it silently did it itself. Also note that the test refers to testing the persistent agent - not the installer service.

[Mildur]

It may be "correct" - but it seems to also be wrong, because both you and I have demonstrated that what the diagram says (Persistent Agent Installed = Yes -> Immediate Job Fail) is not what happens. At the very least, it attempts to connect to the admin$ share (which is documented as only happening if Persistent Agent Installed = No. Something seems to smell here - I don't know if it's docs, code, or logic - but there's an aroma in the air.

I have received a reply from QA because I asked them exactly about this behavior.
The scheme in the user guide is a simplified version. The logic is much more complex. But the scheme is correct in terms of "backup job fails if installer service is not detected but persistent guest agent is installed".
It just do much more in the background and unfortunately also shows it to the console. Which makes it really confusing when compared to the scheme. Maybe this is something we can change in our console output or user guide scheme.

Why does the job fail then?
Because when installer service is not detected, the subsequent attempt is to use standard AAIP (non-persistent guest agent) against the admin share. The condition for using the runtime guest helper is, that the persistent guest agent is not installed. They cannot exists simultaneously on the same vm.

Code: Select all

Unable to establish connection via the admin share because the guest agent is available

So for a backup job with the persistent guest agent option enabled, the following conditions apply:
- installer + persistent guest agent installed -- > persistent guest agent is used for guest processing
- only installer service installed -- > persistent guest agent is deployed and used for guest processing
- nothing pre-installed -- > non-persistent runtime component is used for guest processing

If you see another behavior, please open a support case and share the case number with me.
Admin credentials are still required for guest processing with the persistent guest agent. But access to admin share or VIX/PowerShell Direct can be disabled. V12 will allow you to use gMSA instead of admin credentials.

Best,
Fabian

[AlexHeylin]

Fabian - thanks very much for clarifying that!