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 |
The value is wrong. It should be #2 |
The results:
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: