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
|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|
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.
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.
Its taken Citrix a while but finally Receiver 4.8 supports auto update as a new feature.
Hello readers, I back to writing my technical blog, mostly on Citrix issues I’ll cover other topics of interest as well. over the past 2 years I’ve embarked on a Global Citirx deployment of Netscalers, XenDesktop 7.x and XenServer VDI solutions. To be honest I haven’t had the time or energy to write, but now most of the work is done I can enlighten my readers to some interesting ways to troubleshoot and use Citrix products. There is a lot of useful information and guides already out there so I’ll highlight useful reads and news from Citrix as well as share my own experiences.
Im working in an environment where there is no direct access to the StoreFront servers. All users connect to the Netscaler VIP wherever internal or external. This is the save the headache of applying ACLs to multiple VLANs across multiple global sites. It’s simple TCP 443 and your have access to your Citrix Apps./Desktops.
I’ve come across an issue where the Receiver kept prompting users for the password after about 30 minutes and they were getting frustrated.
The Netscaler’s Default Session timeout is 30 minutes and you can change this something else. In my case we changed this to 600 minutes for internal users and 60 minutes for external users. This is defined in your session policies.
So heres the issue:
After 2 Hours the timeout stops working and users are no longer prompted for the password, this means we can’t offer say a 4 hour timeout.
Netscaler VPX Firmware: 10.5.57.7
The next stop will be test on another firmware level.