A quick blog regarding my Citrix lab upgrade from Citrix Virtual Apps and Dekstops (CVAD) 1912CU4 to 2203 and the little StoreFront snag I hit.
Summary of my setup:
Two Delivery controllers
Two StoreFront servers cohabitating with Director as well
Two FAS servers
Two WEM servers
One unmanaged VDA worker
And a Citrix ADC HA setup load-balancing the entire solution with keep in mind only TLS1.2 enabled for the services.
All components went flawless through the upgrade only after the maintenance window I could not see any desktops when logging in through StoreFront and got the dreaded “cannot complete your request” when logging in via the Citrix Gateway. At first no error entries that would stand out not even the errors shown in the support article which I’m mentioning in a bit.
The I remembered that there was a hotfix released quite fast after the original 2203 release of StoreFront regarding TLS hardening of the original CVAD setup. The following articles mention it in detail:
Gateway Callback and / or XML Communication fails after upgrade to Storefront 2203
Hotfix – Receiver StoreFront 3.23.1- For Citrix Virtual Apps and Desktops 2203 – English
After doing some checks regarding the XML, StoreFront and all the VIP’s this was definitely the case. The event logs would make clear that the XML could not be reached and when logging in through the gateway the callback URL would not be reachable. Updating the StoreFront servers with the above hotfix resolved everything.
Hope it helps!
Recently I got involved at a customer location which was going to use Remote PC catalogs in combination with their XenDesktop / XenApp 7.15 environment. This was no problem whatsoever to configure but on closer testing I encountered a bug that when you create for example a delivery group called “Windows 10 Remote PC” and adding more than one desktop the second, third and so on would get the published name of the local computer name e.g. WSDELL34951 which doesn’t comply with a standard name. The following can be observed for the delivery group name:Normally you would see at “PublishedName” an empty value, to correct this take a note of the “Uid” number and put in the following command:In this case my id was 4, and voila this will correct the name in StoreFront like in the following screenshot:
For the Multi Licensing part this needs to be done at the same level in powershell, see the following article:Multi-type licensing
In the previous screenshot you will see:
“LicenseModel” & “ProductCode” these need to be compliant with their respective edition of XenApp or XenDesktop license model, management is then per delivery group and not applicable for the entire site anymore. This would be a default for every new delivery group that will be created unless like in above screenshot you will add the “LicenseModel” & “ProductCode”
Hope this helps!
I came across an issue in my lab environment where the screen will go black while launching a session on Windows Server 2016. This is with XenApp/XenDesktop 7.15 LTSR
The following registry entry: DisableLogonUISuppression (D WORD Value 0) did not resolve the issue as stated in the following articles:
https://support.microsoft.com/en-us/help/4034661/windows-10-update-kb4034661 and https://support.citrix.com/article/CTX225819
Ultimatly after some trial and error the deletion of all subkeys from below registry entries resolved it:
Came across two bugs on a XenServer 7 deployment in combination with XenDesktop/XenApp 7.12 worth sharing:
The first is a mouse alignment issue which results in VNC mouse pointer slowness or disalignment of the pointer on a console session in XenServer, the following can check the status of the usb and usb_tablet parameters on the vm’s:
## xe vm-list uuid=[of the provisioned machine] params=platform
which will give the output of the VM and the following command will set the value’s:
## xe vm-param-set uuid=[of the provisioned machine] platform:usb=true
## xe vm-param-set uuid=[of the provisioned machine] platform:usb_tablet=true
confirm the settings with the xe vm-list command and afterwards reboot the machine and the issue is resolved.
The second bug is in a newly provisioned MCS catalog the XenTools of all provisioned machines won’t get installed, there is a private fix for this with Citrix Support under LC6769, the definitive solution shall be updated in 7.13 according to support.