I’ve been working on an issue with Power States in Xendesktop that’s been driving me nuts for over a month now. However I finally resolved the issue yesterday.

Background: I’m working on a corporate network, with tightly controlled firewalls and ACLS between VLANs. I’ve built a Xendesktop Infrastructure which consists of 2x DDC, 1x SCVMM and 2x Hyper-V Hosts. Initially the servers had open ACL access during the build, the installation and configuration went really smoothly.  However when the ACL rules were applied that’s when I started seeing issues.  Having studied the known ports used by Citrix Guide I submitted the change requests, the only this is the guide isn’t really clear on the direction of traffic. I guess they assume people will just open it both ways, our Network teams don’t like this idea unless its really necessary.

 

Issues discovered: 

  • Unable to detect power status
  • Unable to power on VDI from the Web Interface or DDC
  • Provisioning new Machines failed
  • Updating machines resulted in (Action Pending) – (Nightmare!)

However users were able to access their existing VDIs if they were powered on.

 

Resolution:

This may not be a complete solution from your environment, but I highly recommend checking the following items:

VDA – Ensure your VDA agent can see the DDC on the default port 80 in BOTH directions, this can be one of the results for not detecting the power status or failure in updates. Ensure you can resolve the DDC (Xendesktop controller) in DNS, telnet the DDC and telnet the VDA from the DDC. There’s a really useful tool for checking connectivity to your DDC and other required serviced called XDPING which you can download from the Citrix Website http://support.citrix.com/article/CTX123278

 

NETWORKING

Sign > = direction of traffic < > = both ways

Adding a Hyper-V Server
Allow ACL Access from [SCVMM SERVER] > Tcp 80,443,3389,5900,135,24158,2179 > [HYPER-V SERVER]
Allow ACL Access from [SCVMM SERVER] > Tcp 80,443,3389,5900,135,24158,2179 > [HYPER-V SERVER]
Allow ACL Access from [XENDESKTOP SERVER] >Tcp 80,135,24158 > [HYPER-V SERVER]

Adding a XenServer
Allow ACL Access from [XENDESKTOP SERVER] > Tcp 80,443 > [XENSERVER]

VDI Access
Allow ACL access from [XENDESKTOP SERVER] < Tcp 80, 443 > 3389, 5985, 135, > [CLIENT VDI VLAN]

Adding a XenDesktop Server
Allow ACL Access from [XenDesktop] > 8100 > OPSCVMM02D or SCVMM Server
Allow ACL Access from [XenDesktop] >Tcp 80,135,24158 > [HYPER-V SERVER]
Allow ACL Access from [XenDesktop] udp > 137, 138 > Tcp > 27000, 7279, 135, 445, 139> <49152-49652> TO [Citrix & TS Licensing SERVER]
Allow ACL Access from [XenDesktop] tcp > 1433> TO [SQL SERVER]

Ensure that your all servers, VDIs have access to Active Directory / and local DNS servers, information you can find on the Microsoft website. http://technet.microsoft.com/en-us/library/cc959828.aspx 

Finally! 

On your HYPER-V host and SCVMM  servers set the WMI service as a static port and then ensure that port tcp 24158 is open.

Follow the Microsoft article http://msdn.microsoft.com/en-us/library/bb219447(v=vs.85).aspx

This is really only required if your network is port restricted, like ours is.

This actually resolved the issue with users unable to power on their own VDIs.

You can test if you communicate correctly to the HYPER-V server by running the following PowerShell command:

Get-WmiObject -ComputerName YOURHYPERVSERVER -NameSpace root\Virtualization -Query “Select * from MSVM_ComputerSystem”