Failed to inject guest runtime components

[perjonsson1960]

Folks,

In some of our Application Aware jobs we are getting these warnings:

Failed to inject guest runtime components via GIP, failing over to guest agent connection via GIP
Failed to connect to guest agent via GIP, failing over to guest runtime components through VIX via GIP

I was under the impression that this could only happen when using Persistent Agent Components, but we are using Non-Persistent Runtime Components, and it still happens. We have a backup job that backs up our 21 MS-SQL servers, and this occures in six of them. And we have another job backing up our nine various Domain Controllers, and there it happens in all but one.

I have no idea why this happens, and what differs between the VMs for which this happens, and for the ones where it does not.

However, it doesn't seem to be any cause for panic, because it seems to work fine to restore Application Items from backups where this happens.

We are using the latest version of B&R.

Kind regards,
PJ

[haslund]

Please do open a support case so our team can review the logs. A quick check would be to edit the backup job and use the 'Test' button under Application-aware processing to see if this test fails or not.

For direct: Double check network connectivity from the GIP, can you browse to MS SQL server admin$ share on one of the six that fails for example?
For VIX: It could be something as simple as restarting VMware Tools on the services, or perhaps updating them to the latest version.

[perjonsson1960]

Case #07051455

[aagrapart]

Hello perjonsson1960,

Did you have an answer to this ? We are in the same case.

Thanks.

[perjonsson1960]

The problem is due to that the Guest Interaction Proxy cannot connect to the admin share (Admin$) in the VM being backed up.
Our network people are looking into the firewall rules on the various VLANs that we have. It works with some VLANs, but not with others.

[BKoretz]

Are the servers where you cannot access the Admin$ share domain joined? If they are not members of a domain, ONLY the Built-in admin account can access this share. This is a Microsoft hardcoded permission that cannot be changed.

[JGM2023]

Few others have commented but this Issue Is almost 90% of the time due to port Issues. I find the easiest way to confirm what ports It's using Is running a trace on one of the existing servers that are working. Then you have your port list to open on the others.

[perjonsson1960]

Are the servers where you cannot access the Admin$ share domain joined? If they are not members of a domain, ONLY the Built-in admin account can access this share. This is a Microsoft hardcoded permission that cannot be changed.

All servers being backup up with Application Aware are domain joined.

PJ