Citrix, DNS, PVS, XenApp

XenApp, PVS, Hyper-V and NIC issues – 1494 not listening

While spinning up about 100 xenapp servers on hyper-v, I utilized a PVS isolated stream network.  This network, on Hyper-V, needs to use the legacy NIC.  It is a different subnet than the backoffice network, which utilizes the 10GE NIC.

For some reason, several of my XenApp servers seem just fine except they won’t connect (RDP works fine).  I let Citrix support take a shot at this but here is what I found.

netstat -a shows the 1494 port listening on the wrong NIC.  This often occurs if the NIC needs to be recreated (I have no idea why some VMs have a #2 or #3 NIC, I plan to take care of that later).

I tried to use many CTX articles to figure this out, but nothing I tried seemed to work (this included editing the httpd.conf, setting DNS lookups, NIC binding, ICA listener configs).  Nothing would seem to change the IP of the 1494 listener.

http://support.citrix.com/article/CTX126871
http://support.citrix.com/article/CTX128254
http://support.citrix.com/article/CTX131554
http://support.citrix.com/article/CTX105793
http://support.citrix.com/article/CTX131831
http://support.citrix.com/article/CTX128115

Getting a bit frustrated, I stepped back and figured something must be locking that port.

netstat -a -b

Shows me TermService is using 1494.  I restart TermService and all troubles just disappeared.

Thinking this through, what happens is if the VM needs to create the 10GE NIC (for whatever reason) it doesn’t wait to start TermService, which means TermService locks 1494 and doesn’t let IMA/XTE use it, no matter what you say in the ICA configuration settings.  In fact, ICA Configuration isn’t correct when it reports what Network Interface it listens on, it seems it doesn’t know (even all NICs isn’t correct).

In any case, I paused and stepped back.  Looking further into the issue, XenApp could not get the right IP for some of the VMs and this led me to look at DNS.  The customer had a master domain (where the infrastructure servers resided) and a child domain, where the XenApp servers resided.  Due to stale records on the DNS of the primary domain (3rd party DNS/DHCP provider) I had to force DNS lookups on the infrastructure servers to use the child domain first (eliminating a bad DNS entry in the root domain).  Magically everything worked.

I actually noticed this post in draft mode today and just added the part at the end realizing the issue had been resolved.  If the DNS/domain setup is strange, ensure lookups are working before going too much further.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s