VM has 2 IPs, vWorkspace uses the wrong one

Hi Nicholas,

I suspect this is more a DNS issue than a vWorkspace issue but let's see what we can find out.

 When you import VMs into the console, the connection broker(s) will use the DNS-resolved IP address of the VMs and will attempt to initialise (copy data collector service binary to VM, run a remote command to start the data collector service and brand the VM with the correct registry values). The data collector service then reads the registry values and starts sending heartbeat packets to the connection broker.

So if initialisation was successful, the LLMServerList value should have your connection broker names.

For x64 VMs, check the LLMServerList value under HKLM\SOftware\Wow6432Node\Provision Networks\Common. For x86 VMs, check the LLMServerList value under HKLM\Software\Provision Networks\Common.

If the name(s) are there, the next step is that the data collector service on the VM needs to be able to resolve the IP address of one of the connection brokers. I would guess the connection broker is on the 10.202.4. network.

Vms on the 172.21.202 network (DHCP?) would need to be able to do a DNS lookup on the connection broker name, and depending on the IP address, would then use the appropriate network interface to talk to that network. If the data collector service can't resolve the connection broker IP address, then the VM will appear to be offline (not sending heartbeats to connection broker).

If you log on to the console of one of the offline VMs, use nslookup to look up the connection broker name. If it doesn't resolve, you've found your problem.

However I  am curious as to why one of the VMs worked. If they've got 2 NICs, is it possible you've got DHCP enabled on both networks? If they have different DNS servers and default gateways, then I could speculate a degree of randomization in the end result.

If the IP address of the connection broker is resolved, then the VM would be sending heartbeats with a 10.202.4 IP address and the connection broker would update accordingly. If not, the VM would be offline.

regards,

Rick

Hi Rick,

There is no Provision Networks entry in the registry at all, so it doesn't even get to this stage.

We can see a bunch of entries in our firewall logs where the CB is trying to access the VM on the 172.x IP address, but it gets blocked (which is expected behaviour).

Both IPs are static, no DHCP is at play here.

In the VMWare console, I can see both IPs listed, so VMWare knows about both IPs. I guess when I import the VM from VMWare, VMWare either tells vWorkspace about both IPs, then vWorkspace picks tho 172.x address and it fails, or VMWare only tells vWorkspace about the 172.x address, and it fails.

If I NSLookup the CB from the VM, it works and gets the correct IP.  the CB is not on the 10.202.x network, it's on the 10.1.x network.

Thanks!

Nick.

Hi Nick,

You didn't mention static IP addresses so I (wrongly) assumed that DHCP could be at fault.

If there is no Provision Networks entry, then the vWorkspace "agent", PNtools hasn't been installed. So no latency reduction, no universal printing, flash redirection, user profile management etc.

However even without PNTools installed on the VMs, the connection broker HAS to be able to initialize the VMs when you import them. That involves copying a file, pndcsvc.exe to c:\windows system32 (x64 or syswow64 for x86), and running a remote command which installs pndcsvc.exe as a service and creates the registry settings under HKLM...\Provision Networks\Common that the data collector service needs to send a heartbeat packet to the connection broker.

No heartbeat packet=OFFLINE.

You are going to have to create a firewall exclusion for the connection broker, because if it can't communicate with the virtual machines, they won't be available.

This is analogous to what you have if you forget to install VMware tools on to a VM, it'll be crippled.

regards,

Rick

Hi Andrew,

Great, thanks for letting me know.

Is the only way to configure this registry entry by manually entering it?  Or is there a GUI in the vWorkspace console.

If the IP range is on the VM, how does the CB find out about it?  It can't connect to the VM in the first place...

Nick.

Hi Nick.

You have to set this on the VM manually. Normally the registry entries would be put into your master template (Hence being a range instead of a specific ip)

Then when you deployed from that template, during provisioning we'd inject the rest of the registry keys needed for the VM to talk to the Connection Broker. The DataCollector service would then send the correct IP to use to the Broker as part of it's heartbeats.

As you've manually imported these VMs, rather than provisioning them through vWorkspace, you do have a unique issue as you say in your last sentence.

To get around this, either

1. Temporarily disable the other nic, so that your Hypervisor will report the correct IP address to our Broker and we'll then be able to do the initialize and get the VM setup.. As long as you have the registry key in place for which IP to use, you'll then be able to re-enable the other network card.

2. You may be able to fix this by changing the binding order of your NICs. I think if you make the NIC with the correct IP the first network card in the binding order, it will be this IP address that gets reported to the Hypervisor. We asked the Hypervisor for the IP so this should also fix the issue.

Let me know how you get on,

Andrew.

I'll give it a go, thanks Andrew.

We already tried the binding order trick, didn't help unfortunately.

Will let you know!

This worked.

1. install updated PNTools

2. add the registry entries, ours were "10.0.0.0", and "255.0.0.0"

3. remove the 172.x NIC

4. Wait a bit, maybe 10 mins.  vWS console starts using 10.x NIC

5. Add the 172.x NIC back in, vWS appears to keep using the 10.x NIC.

I can't confirm whether steps 1 and 2 were actually necesarry, or step 3 and 4 were all that we required, but it seems to have worked.

That's great news - thanks for letting us know :emotion-1:

Hi Andrew,

Is this only for VDI or does it work for RDSH as well? I have a 2012R2 RDSH server running vWorkspace 8.01 which worked fine until I added a second NIC. As soon as this was added, clients failed to connect via the web interface or AppPortal. Direct connections using PNTSC worked fine.

Looking at resource monitor on the secure gateway server I can see that connections are trying to connect to the wrong IP address. If I disable the 2nd NIC, things start working again.

I installed the hotfix and added the IPRange value as the servers IP address and IPMask value as 255.255.255.255. It made no difference. I also confirmed that the NIC I want to use is first in the binding list.

We have Server 2008R2 RDSH servers with similar configurations which don't have this issue.

Scott

Hi Scott,

Sorry I didn't see your reply before.

When dealing with RDSH, The IP address used for your RDSH is based on what DNS tells the Connection broker it is. I imagine your DNS is confused as you have more than one IP registered for that hostname (or simply the wrong one registered)

A quick way to control this is to edit the C:\Windows\System32\drivers\etc\hosts file on each broker.

For example, when I add

10.10.122.12  Sessionhost2008

My Broker gives out the .12 IP address.

Thanks, Andrew.

Hi Andrew,

Thanks for your reply. The second NIC is set to not register itself in DNS. I have confirmed that it definitely isn't there. I also tried adding the IP address to the hosts file as you suggested, but it still did not work. As soon as I enable the second NIC, users can no longer log on. As soon as I disable the NIC, users can log on again. When I use resource monitor on the secure gateway, I can see it is trying to proxy the RDP connection to the wrong IP address when the 2nd NIC is enabled.

I have deployed numerous 2008R2 RDSH hosts with this dual NIC configuration with no problems but both 2012R2 deployments I have setup don't work with 2 NICs.