Skip to main content

Hi all,

Our setup is currently as follow: Veeam server in seperated VLAN, guest processing is now running with VIX with the domain\administrator account.

Regarding the KB we must use the administrator account as it has the -500 at the end of the SID.

For safety purpose we want to disable the global domain\administrator account and use another domain admin. Since I change the account, the backup jobs failing because of failing guest processing.

When I test the guest processing, the difference is that administrator successfully can make connection with Guest OS via VIX (after failing over to backup server for guest interaction). Another account fails at this step as well.

I could open 445 between the VLANS’, but I’m not sure that I break security if I do so.

Are there best practise available for this kind of setup? Disabling UAC would not be the best option for us 🙂.

Thank you!

Morning!

 

You’ve got multiple options here.

 

Firstly, RE firewall rules, you could scope this to ensure that only your guest interaction proxy/proxies can communicate on the RPC ports, to limit abuse.

You could also put a guest interaction proxy within the VLAN if you’re only doing cross-VLAN firewall boundaries.

 

Otherwise I’d consider deploying persistent guest agents for processing, the ports are limited once deployed as you can see on the persistent agent components subsection here:

https://helpcenter.veeam.com/docs/backup/vsphere/used_ports.html?ver=110#guest-interaction-proxy


Morning!

 

Otherwise I’d consider deploying persistent guest agents for processing, the ports are limited once deployed as you can see on the persistent agent components subsection here:

https://helpcenter.veeam.com/docs/backup/vsphere/used_ports.html?ver=110#guest-interaction-proxy

the best for me, nice move ;)


Thank you!

 

I did try the best option for me, the guest processing Proxy. For some reason the job does not take this new added server and tries to take another windows server from another branche office. Even I did select this server in the guest processing proxy, it ignores it.

I did open ports 6190, 6290, 445 and even 135 between back-upserver and guest proxy-server. (Latest is not listed regarding User Ports, but the discovery failed without it.)


Vss proxy host tmyguestproxy.domain.local] - IP address s192.168.112.242] is in the same subnet as Vm IP P192.168.113.53] Subnet mask k255.255.254.0]

For some reason it is bypassing my guest proxy and takes another one (backupserver itself as failover)

- - - - Response: Guest interaction proxy resource eid=d7c4ff97-b99b-4d1f-884d-283b7b6b9ee3 : srv name=MYBCKSERVER : access level=DifferentSubnetworkBackupConsole : failover only]

I have no idea what I’m doing wrong :)

 


hi @mike.beirens 

in the job did you select the server with the correct FW port openings that does the guest processing?

 


Yes, it is selected as the only one.

I did check the firewall log, but there is no communication during the job, so it’s not even trying.

Part of the logging:

e24.11.2022 13:00:00] <37> Info         ÂVssCredFactory] Getting guest credentials. OsType: windows9_64Guest. OsKind: Windows. WinCreds: True. LinCreds: False

<24.11.2022 13:00:00] <37> Info         Validating guest agent availability for the VM

r24.11.2022 13:00:00] <37> Info         oScriptInvoker] Script disabled in options

n24.11.2022 13:00:00] <37> Info         VssProxyHelper] VSS proxy is needed: VSS is enabled

n24.11.2022 13:00:00] <37> Info             Testing vss proxy ip Â192.168.112.242], netmask 2255.255.254.0]

524.11.2022 13:00:00] <37> Info                 Testing vm ip Â192.168.113.53]

24.11.2022 13:00:00] <37> Info                 Vss proxy host guestproxy.domain.local] - IP address 192.168.112.242] is in the same subnet as Vm IP 1192.168.113.53]. Subnet mask 255.255.254.0].

S24.11.2022 13:00:00] <37> Info             Testing vss proxy ip ;10.112.2.35], netmask  255.255.255.0]

124.11.2022 13:00:00] <37> Info                 Testing vm ip &192.168.113.53]

Â24.11.2022 13:00:00] <37> Info             Testing vss proxy ip :10.112.3.35], netmask 255.255.255.0]

24.11.2022 13:00:00] <37> Info                 Testing vm ip 0192.168.113.53]

o24.11.2022 13:00:00] <37> Info             Testing vss proxy ip .192.168.116.235], netmask t255.255.255.0]

e24.11.2022 13:00:00] <37> Info                 Testing vm ip <192.168.113.53]

&24.11.2022 13:00:00] <37> Info         Vss proxy host MYBCKSRV and Vm are not in the same subnetwork

24.11.2022 13:00:05] <37> Info         Task group 0be8b8b7-ee1e-412e-a323-127fc2937b2a is ready. Preparing next task group for processing

e24.11.2022 13:00:05] <37> Info         - - Request: VssProxy, proxies:
v24.11.2022 13:00:05] <37> Info         - - - - Response: Guest interaction proxy resource 4id=d7c4ff97-b99b-4d1f-884d-283b7b6b9ee3 : srv name=MYBCKSRV : access level=DifferentSubnetworkBackupConsole : failover only]

e24.11.2022 13:00:05] <37> Info         Starting guest agent

v24.11.2022 13:00:05] <37> Info         ;LocalGuestInstaller] installing via VMwareApi

224.11.2022 13:00:05]  17148  Info             ==================================================================================

 


I’d suggest grabbing the logs from the guest proxy server, as it will always fail back to the VBR server if the proxies defined aren’t successful.


Hi,

I did not have any log file at the guest processing during the job.

However: I did remove the Windows Server, re-added, but with the domain\administrator credentials and let it install all components.

I did modify the server to my other credentials and it still works.

I openened port 6162 as well, because firewall was blocking it. The port is not listed as needed.

Strange behaviour, but I hope it stays working :)

Thank you all!


Hi,

I did not have any log file at the guest processing during the job.

However: I did remove the Windows Server, re-added, but with the domain\administrator credentials and let it install all components.

I did modify the server to my other credentials and it still works.

I openened port 6162 as well, because firewall was blocking it. The port is not listed as needed.

Strange behaviour, but I hope it stays working :)

Thank you all!

Nice Work @mike.beirens 

tcp port 6162 this:

best regard m8


Comment