XenDesktop

Fix Your Citrix License Issues

You can add as much HA and DR infrastructure as you like to your farm but ultimately the license server or RDS license server can bring down your entire estate. Citrix offer a 720 hour grace period which allows you time to fix your license server or bring a new one online. Microsoft RDS license offer 120 days grace period if you havent already used it. This blog post is to address the process of troubleshooting Citrix licensing, monitoring them and the networking ports required to for the service to work.

 

The issue:  A DDC dropped off the site/farm as was unable to connect to a valid license from the license server.

Even with port 27000 open and confirmed by telnet it was still unable to connect.

The additional port 7279 (check in/check out) was opened by networks and I could see in the event logs that Citrix Broker service connected to the license server. However in studio we still could view the license server.

After further investigation I found an error code: XDDS:9509EEA3. This suggested that ports tcp 8082 and 8083 were needed opening as per article: https://support.citrix.com/article/CTX200937

Resolution: The Citrix Web Services for Licensing service listens on port 8083/8082 and is required if you want to view licenses in Studio on a DDC, ports 27000 and 7279 are essential for acquiring licenses.

Networking: DDC to license server is requires ports: TCP 27000, 7279, 8083, 8082 to properly function. Our enviroment is completely locked down so we have to request every port that needs to be opened between hosts.

Monitoring:  Event logs will help you identify license issues look for the following:

  • Error: Source: Citrix Broker Service,   Event 1151, The Citrix Broker cannot contact the license server
  • Error: Source: Citrix Broker Service,   Event 1155, The Citrix Broker will not stop providing desktop and application sessions, this controller is no longer in grace period…. (This is critical and you need to fix the issue ASAP or face losing the DDC/Site)
  • Info: Source: Citrix Broker Service,   Event 1198, The Citrix Broker is successfully consuming licenses from the license server..  (Your back in business)
  • Info: Source: Citrix Broker Service,   Event 1150, The Citrix Broker Service successfully contacted the license server (Your license server is back online, Happy Days)

RDS licensing: Citrix requires your have RDS (Remote Desktop) licenses on an RDS License server, you dont need to configure your VDA for all RDS services and the VDA will install these automatically.

You need to create a GPO to point your Citrix Servers (VDA) to the RDS license server. This came in Windows 2012 as before you could just add the RDS license servers in the control panel.

 

Networking Ports: This can be a pain because you need so many and also a dynamic range, but you can customize the port range: https://support.microsoft.com/en-us/help/154596/how-to-configure-rpc-dynamic-port-allocation-to-work-with-firewalls

Application protocol Protocol Ports
RPC TCP 135
Randomly allocated high TCP ports¹ TCP <var>random port number between 1024 – 65535</var>
<var>random port number between 49152 – 65535²</var>
NetBIOS Datagram Service UDP 138
NetBIOS Name Resolution UDP 137
NetBIOS Session Service TCP 139
SMB TCP 445

RDS Events: This is better explained in the Microsoft article as there are many examples: https://technet.microsoft.com/en-us/library/ee890876(v=ws.10).aspx

You can choose which event IDs are best to monitor, but generally unable to connect, issue or a certifcate related to this service needs to be monitored.

 

 

Citrix – MCS fails to create machines

Summary: We have an existing machine catalog with VMs created on a XenServer cluster. The existing machines work fine and are power managed. In Citrix studio you can turn on and off machines but not create new ones. There is sufficient resources on the XenServer. The frustrated client wants more machines for new starters.

The Issue: We are unable to deploy new VM to the existing machine catalog.

Errors: This operation cannot be performed because a VDI is in use by some other operation. This operation cannot be performed because a VDI is in use by some other operation.

 

Troubleshooting Steps: The initial steps would be to verify the DDC can authentication against hyper-visor. This is located Studio > Configuration > Hosting. Right click the properties of the host and pop in the credentials again.

If that doesn’t work, click Test Resources on the right hand side and check for any warnings.. All results should be successful. Read the warning for more information.

Depending on the version of Xendesktop, in this case it was 7.8, you may want to try creating another machine catalog. We have seen some instances where we are unable to add to an existing machine catalog but can use the same image/snapshot to deploy VMs on a new machine catalog.

The Resolution: In this instance the processor and cores didn’t match that of the master image. Its fine if the you add more cores but the number of CPU must be the same. 2×2

Example: In Xenserver, the master image was 2 CPU x 6 Cores and we tried changing it to 1 CPU x 4 core.

This worked when I changed the configuration to 2 CPU and 2 Core = 4 cores.

 

 

 

XenDesktop 5.6 Power Issue

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”

 

Go to Top