Multi-homed server, lock ICA and RDP to a specific NIC

We implement a multi-homed setup with Citrix Provisioning Services.  We have all of our production traffic on one NIC and all PVS traffic on a second nic.  This helps us in troubleshooting when doing packet captures but does introduce other sets of challenges.  One of these challenges is when I uninstalled and then installed updated VMWare tools on one of our vDisks it caused the NIC's to renumber and reorder themselves.  You've probably read some articles saying to 'show hidden devices' and uninstall any 'ghost' devices; with a multi-homed setup this may not resolve your issue.  My specific issue is my NIC's now went from "0x1 and 0x2" to "0x3 and 0x4" in the LANATABLE.  We apply a GPO to the ICA-TCP and RDP-TCP to force them to only utilize our 'Production' NIC which we decided was going to be the second NIC.

Provision = 1st Nic, Production = 2nd Nic

I uninstalled the ghost devices but because this change is all 'in the registry' it wasn't immediately noticeable by myself that the LANATABLE and NIC ordering had changed.  I promoted my vDisk and then tried to RDP into it:

Well...  I knew this wasn't right.  So I logged onto the server and checked the LANATABLE values:

Provision NIC

Production NIC

Provision NIC LanaID = 0x3 after the VMWare Tools upgrade

Production NIC LanaID = 0x4 after the VMWare Tools upgrade

RDP targets LanAdapter 0x1 (!?)

ICA targets LanAdapter 0x2

A couple issues popped out.   The first was that the LanaID's were wrong.  I *thought* Provision should be #1 and Production should be #2, but we apply our LanAdapter ID's via GPP so these values are correct for our other systems.  I know both RDP and ICA need to be locked to the Production NIC and the order is *correct* but I'm a bit confused to why the numbers are different between RDP-TCP and ICA-TCP.

So I started on getting the issues resolved.  First, I was going to resolve RDP.  If it is targeting 0x1 that means that I need the Production NIC (VMWare Network Adapter #2) needs to be set as 0x1.  So I edit the LanaId of the Production NIC to 0x1 and the Provision NIC to 0x2.  I rebooted the box and I could RDP into it without issue.  I then checked the Remote Desktop Session Host Configuration:

This is the correct value.

OK, so RDP is set correctly and works.  I then tried to launch a Citrix application.

It failed.

It generated an event on the server:

Unable to connect to the CGP tunnel destination

Looking at the ICA Listener configuration showed me the following:

The value is wrong.  It should be #2

So the ICA-TCP listener was set to the 'Provision' NIC.  So our production traffic was not getting to it. This is the wrong value.  My first thought was the LANATABLE would make sense here...  We have the LANADAPTER key is set to 0x2 which would equal the 'Provision' NIC under this configuraiton...   So I changed the LANATABLE to be the reverse.  0x1 = Provision NIC and 0x2 = Production NIC.

The results:

Now both are wrong!

Jeez.

I reverted the LANATABLE to 0x1 = Production and 0x2 = Provision.  Again, only the RDP-TCP connection changed.  At this point the ICA Listener *must* be looking at another place...  I used Procmon to trace the registry when I opened the ICA Listener Configuration and noticed it did NOT query LANATABLE but did go through and look and query this key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Linkage

The BIND order is set as Production (#2 NIC) first and Provision second in this order...  To change this order you need to go to Advanced Settings and modify the connection order:

Provision *should* be the top NIC here...

So I used the arrows on the side and moved Production to be second in this order:

Rebooted and I checked the ICA Listener:

Hurray!

I then tried both RDP and ICA traffic and both now worked correctly.

So, the lesson learned here is that this registry key:

Targets the BINDING order of the NIC's.

And this registry key:

Targets the LANATABLE and the values specified within.