Troubleshooting
Citrix CVAD und MTU Discovery
Update November 2022:
Martin Latteier schrieb mir, dass Citrix heimlich eine neue Funktion eingeführt hat, die das Problem behebt. Tatsache ist, dass bei bestimmten Kabelverbindungen mit DS-Lite (nur IPv6) die MTU-Ermittlung mit EDT nicht richtig funktionierte, weil das Kabelmodem das „DF-Flag“ nicht verarbeitete, was dazu führte, dass die MTU-Ermittlung eine zu hohe MTU erkannte, die Datagramme fragmentiert werden mussten und die Performance schlecht war. Die Lösung bestand bisher darin, EDT auf der Client-Seite auszuschalten oder die MTU-Erkennung auf eine statische MTU zu ändern (edtMSS=13xx).
Wenn Sie dieses Flag setzen, sollte das Problem für alle Verbidnungen gelöst sein:
Update Januar 2022:
Ich empfehle die default.ica gemäss https://support.citrix.com/article/CTX231821 nur wie unten empfohlen anzupassen wenn auch die WorkspaceApp für Mac 2201 oder höher eingesetzt wird!
In letzter Zeit traf ich öfters mal die Situation an, wo es bei der ICA Verbindungsherstellung auf virtuelle Desktops via Citrix ADC (aka Netscaler) oder virtuelle Apps im Firmennetz ab den Aussenstandorten Probleme gab. Dazu habe ich für den Fall mit den virtuellen Desktops auch einen Blogpost geschrieben: Probleme beim Zugriff auf Citrix virtual Apps und Desktops auf einem reinen IPv6 Internet Anbieter bei eingeschaltetem EDT
Der Workaround war für beide Fälle das Deaktivieren von dem UDP-basierten EDT Protokoll, welches heute bei Citrix virtual Apps und Desktops Standard ist. Das ist aber nicht so toll, weil wir möchten es nicht für alle ausschalten da es gewisse Vorteile hat. Somit mussten wir alle «Problem-Clients» entdecken und mittels Registry-Key (siehe vorangehender Blog Artikel) auf TCP umstellen.
Eine weitere Analyse der Problems ergab, dass die Ursache bei der MTU, also der maximalen Übertragungseinheit oder eben Paketgrösse liegt. In unserem Firmennetz kommt es bei der Anbindung zu Aussenstandorten aufgrund von eines Krypto-Tunnels, welches wir zu allen Aussenstandorten einsetzen, zu einer Verkleinerung der möglichen MTU was wiederum zu einer Paket-Fragmentierung führt. In gewissen Fällen ist die Fragmentierung so stark, dass der Payload nicht mehr ausreicht für die Citrix Verbindung. Es zeigt sich , das hier EDT via UDP viel anfälliger als ICA auf TCP.
Lösung 1: How to configure MSS when using EDT on networks with non-standard MTU
Im vorangehenden Blog-Post habe ich aufgerufen «Citrix fixt das» und das taten sie bereits vor meinem nörgeln… Dieser Artikel beschreibt wie man die MTU für EDT reduziert: https://support.citrix.com/article/CTX231821 z.B. auf 1480 via das default.ica
Diese Methode hat den Nachteil dass die MTU für alle Verbindungen reduziert wird, und man etwas ausknobeln muss welches denn nun die richtige MTU ist. Dafür funktioniert diese Variante für alle Plattformen ausser Android.
Lösung 2: MTU Discovery aktivieren
Eine etwas noch elegantere Variante hat sich Citrix mit dem etwas heimlichen einführen von MTU Discovery überlegt. Mit CVAD 19.12 ist es nun möglich die optimale MTU automatisch herauszufinden und zu setzen. MTU Discovery ist keine Citrix Erfindung, aber hier neu, Details zu MTU Discovery findet man hier: https://de.wikipedia.org/wiki/Path_MTU_Discovery
Ich habe versucht, dies nun bildlich etwas darzustellen:
Standartkonfiguration, MTU ist auf 1500
Standartmässig werden 1500 byte grosse Pakete versendet, ist die mögliche MTU auf dem Pfad irgendwo kleiner, wird fragmentiert, das kann funktionieren, aber es gibt in der Praxis teilweise auch Probleme.
MTU reduziert auf 1380 gemäss oben genannten Citrix Artikel (Anpassung default.ica auf dem StoreFront)
Nun werden immer 1380 byte grosse Pakete versendet.
– Ist die mögliche MTU auf dem Pfad irgendwo kleiner, wird dennoch fragmentiert, hier im Beispiel der Client aus dem Internet.
– Weiter wir unter Umständen die MTU verkleinert wo es nicht nötig ist, hier im Bild unser Client am Hauptstandort.
+ Diese Lösung funktioniert auf allen Plattformen ausser bei Android.
MTU mit MTU Discovery
(Anpassung in der Registry des VDA)
+ Mit MTU Discovery wird die MTU für jede Verbindung individuell ausgehandelt, verbunden wird mit 1024 bytes und dann wird hochgefahren. Eigentlich der beste Weg … aber es ist zu beachten, dass dafür mindestens der Virtual Desktop Agent 19.12 benötigt wird, weiter muss bei der Verbindung über ADC mindestens die Version 13.0.52.24 oder 12.1.56.22 im Einsatz sein. Wenn die ADC Version tiefer ist, klappt die Verbindung trotzdem aber der MTU Wert bleibt auf 1024 und wird nicht dynamisch wieder nach oben angepasst!
– Weiter funktioniert heute MTU Discovery nur mit der Citrix Workspace App für Windows ab der Version 19.11 (Non-Windows Geräte haben ev eine kleiner MTU Size als nötig)
Kontrolliert werden wie hoch die EDT MTU ist kann mit dem Befehl: ctxsession -v
MTU Discovery ist heute nicht per Default aktiv, sondern kann auf dem VDA mit dem setzen eine Registry Keys aktiviert werden. Details wie man da macht hier: https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/technical-overview/hdx/adaptive-transport.html#edt-mtu-discovery
Update 5.6.2020 – Kombination Lösung 1 & 2
In unserem Fall haben wir für die Verbindungen via ADC eine separate Storefront Konfiguration, hier setze ich nun die MTU auf 1480 um auch macOS Computern (BYOD) gerecht zu werden, aber für Windows Computer haben wir auch die MTU Discovery aktiv:
Technische Umsetzung:
auf dem VDA: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\Wds\icawd
Name: MtuDiscovery
Type: DWORD
Data: 00000001
default.ica:
OutBufLength=1300
udtMSS=1300
edtMSS=1300
Wenn MTU Discovery aktiv ist, also eingeschaltet und ab einem Windows Client mit CWA 19.12 oder neuer zugegriffen wird, übersteuert dies auch den gesetzten Werte vom default.ica !
Wie sieht bei euch die MTU Konfiguration für Citrix mit EDT aus? Hinterlasse dazu doch ein Kommentar!
Probleme beim Zugriff auf Citrix virtual Apps und Desktops auf einem reinen IPv6 Internet Anbieter bei eingeschaltetem EDT
Vor einigen Wochen kamen erste Incident Tickets zu meinem Team dass unsere Citrix Anwender Probleme haben beim Zugriff von ausserhalb der Firma via Citrix ADC (ehemals Netscaler) auf die bereit gestellten pooled Windows 10 Desktops.
Ich habe festgestellt, dass alle betroffenen Benutzer eine Gemeinsamkeit hatten, alle waren bei UPC Cablecom. Wenn die gleichen Benutzer zum Beispiel mit dem Mobiltelefon ein Wifi-Hotspot erstellten und darüber eine Verbindung herstellten
Weitere Troubleshooting Schritte haben gezeigt, dass wenn ich einem betroffenen Benutzer eine dedicated Windows 10 VDI bereit stelle und dieser das adaptive Transport Protokoll EDT explizit via Policy/Tag deaktiviere, der Zugriff ebenso klappt. Aber wir wollen weder dedicated Desktops zur Verfügung stellen, noch wollen wir EDT für alle deaktivieren da wir eine kleine Anzahl Mitarbeitende im Ausland mit schlechten Verbindungen haben. Normalerweise macht Citrix eine automatischen Fallback sollte die Verbindung über EDT nicht klappen, aber nur wenn die UDP Ports explizit zu sind.
Der von Julian Jakob in Twitter vorgeschlagene Workaround, EDT auf Client Seite zu deaktivieren ist also wohl der einzige brauchbare Workaround.
Anleitung für die Anpassung auf Clientseite:
(Muss der User bei BYOD selbst machen!)
Auf dem Windows Rechner muss dieser Registry-Key angepasst werden:
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Citrix\ICA Client\Engine\Lockdown Profiles\All Regions\Lockdown\Network\UDT]
"HDXoverUDP"="Off"
Auf Mac Computer muss dieser Befehl im Terminal eingegeben werden:
defaults write com.citrix.receiver.nomas HDXOverUDPAllowed -bool NO
Auf iPad/iPhones kann es in der Workspace App konfiguriert werden:
Einstellungen (Zahnrad oben rechts) => Erweitert => Einstellungen für adaptiven Transport => EDT zulassen auf inaktiv setzen
Bitte Citrix, fixt das! Bitte macht bei puren IPv6 Verbindungen einen sauberen Fallback auf TCP! Wenn EDT nicht geht, nutzt es nicht! Das ist für Benutzer nicht zumutbar.
Update 26.05.2020
- Wenn eine Nicht-Standart-MTU genutzt wird, sollte man dieses Artikel beachten: https://support.citrix.com/article/CTX231821
- Hintergrund wieso dies Auftritt, UPC scheint da ihre Netze über CarrierGradeNAT (https://elektronik-kompendium.de/sites/net/2010221.htm…) zusammen zu «murksen» (IPv4/IPv6 Enkapsulierung) und es bleibt zuwenig payload übrig (MTU Problem). (Danke Markus Löffler für den Hinweis)
- Citrix hat „heimlich“ das FeatureMTU Discovery eingeführt, zwar ist dieses noch nicht offiziell announced, aber seit 1912 ist es offiziell auch in der Doku: https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/technical-overview/hdx/adaptive-transport.html#edt-mtu-discovery auch dies könnte zur Problemlösung beitragen.
Update 4.6.2020
Das aktivieren von MTUDiscovery sieht sehr vielversprechend aus, ist aber momentan nur für Citrix Workpace App für Windows möglich (ab Version 19.12)
Fatal error during installation (1603) beim StoreFront upgrade auf 3.12
Heute habe ich meine Citrix StoreFront Server von 3.9 auf 3.12 aktualisiert
wie immer habe ich zuerst die folgenden Dienste gestoppt:
net stop W3SVC
net stop CitrixConfigurationReplication
net stop CitrixCredentialWallet
net stop CitrixDefaultDomainService
net stop „Citrix Subscriptions Store“
net stop „Citrix Peer Resolution Service“
net stop CitrixServiceMonitor
net stop CitrixTelemetryService
dann käme dann das Ausführen vom CitrixStoreFront-x64.msi, ein reboot des Servers und danach der zweite StoreFront Server. Bisher ging das meistens Problemlos.
Jedoch dieses mal schlug mein Update fehl mit dem Error 1604:
CitrixStoreFront-x64.msi‘ failed with error code 1603. Fatal error during installation“
Ich mag mich erinnern dass ich das schon mal hatte …. und habe dann dies gefunden:
https://discussions.citrix.com/topic/371535-storefront-upgrade-to-301-from-300-fails
Na gut
, ich bin nun auf StoreFront 3.9 und wenn ich in „C:\Program Files\Citrix\Receiver StoreFront\Services\ProtocolTransitionService\Citrix.DeliveryServices.ProtocolTransition.ServiceHost.exe.config“ schaue sehe ich auf einigen Zeilen „Version=3.8.0.0“ – aber ich habe ja aktuell 3.9, also ersetze ich alle „Version=3.8.0.0“ zu „Version=3.9.0.0“
Resultat: Nun klappts auch mit dem StoreFront upgrade auf 3.12 – Ende gut, alles gut.
Der SOAP Serivce kann auf einem PVS Server nicht mehr gestartet werden
Nach den letzten monatlichen Microsoft Security Updates war einer meiner PVS Server nicht mehr in der Lade den SOAP Service zu starten. Ich kriegte einen Event 7000 mit der Meldung:
The Citrix PVS Soap Server service failed to start due to the following error: The service did not respond the the start or control request in a timely fashion.
Ich lebe in Bern , und wir Berner sind dafür bekannt alles etwas ruhig wenn nicht sogar langsam anzugehen und uns nicht stressen zu lassen. Wahrscheinlich liegt dies an unserem Dialekt der einen gewissen ruhigen Klang ausstrahlt.
Jedenfalls war meine Idee aus der Meldung, wenn der Service sich gestresst fühlt, geben wir ihm doch einfach mehr Zeit:
Ich habe ein DWORD names ServicesPipeTimeout mit dem Wert 120000 in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control erstellt, dies bedeutet das nun die Services auf diesem Server 2 minuten Zeit haben um zu starten. Nach einem Reboot war die Einstellung aktiv und mein SOAP war wieder da.
Übrigens, der SOAP ist ein zickiges Ding und ich empfehle den Service so zu konfigurieren dass dieser nach einem Absturz automatisch wieder startet.
Leerzeichen und Punkte in StoreFront 3.5 Farmnamen vermeiden!
In den vergangenen Tagen habe ich meine bestehende StoreFront 3.01 nach StoreFront 3.5 aktualisiert, in einigen Umgebungen hatte ich dann eine böse Überraschung. Es sah eigentlich so aus als wäre alles gut und würde alles laufen, aber dann bekam ich die Meldung dass die Benutzer keine Anwendungen oder Desktops mehr starten könnten.
Auf dem StoreFront Server sah ich einen Warning Event von Citrix Store Service “ Failed to launch the resource “Farm Name.ApplicationName” as it was not found.
Die Ursache für den Fehler war ein Leerzeichen und ein Punkt in meinem Farmnamen, sieht aus als wäre das ein Bug in StoreFront 3.5, man kann etwas konfigurieren dass dann nicht funktioniert!
Nachdem ich den Namen auf xa65farm geändert hatte, lief alles wieder glatt.
Client zu Server Inhaltsumleitung funktioniert nicht mehr aufgrund eines Lizenzproblems
Neulich hatte ich ein ziemlich seltsames Problem mit einer eigenartigen Lösung. Da ich darüber im Netz nicht gefunden habe, poste ich dies mal hier, eventuell hilft das ja noch jemand anderem mit dem gleichen Problem.
Wir hatten das Problem dass Benutzer die Client zu Server Inhaltsumleitung nicht mehr nutzen konnten. Wir haben Visio auf den XenApp Server installiert und somit sollte es beim doppelklick auf einer *.vsd Datei das Serverseitige Visio öffnen, was plötzlich nicht mehr ging.
Nach einiger Zeit Fehlersuche und dem erfolglosen kontrollieren der Logs auf dem Client und Server habe ich dann endlich das Webinterface EventLog angeschaut wo mir folgender Fehler aufgefallen ist:
Event 31007
Site path: C:\inetpub\wwwroot\Citrix\PNAgent. The Citrix servers are not licensed to support workspace control. This message was reported from the XML Service at address http://myserver.ch:8080/scripts/wpnbr.dll [com.citrix.xml.NFuseProtocol.RequestReconnectSessionData]. [Unique Log ID: a5e760c4] For specific information about this message, see the Web Interface documentation at http://support.citrix.com/proddocs/topic/web-interface-impington/wi-log-messages-event-ids-hardwick.html.
Nun kam uns in den Sin das wir neulich die Citrix Lizenzen konsolidiert haben und dabei auch den Lizenzserver geändert haben. Danach habe wir selbstverständlich auch die XenApp Server neu gestartet, jedoch aber nicht die Webinterface Server da hier ja keine Lizenz eingetragne wird. Ein Neustart der Webinterface Server konnte schlussendlich dieses Problem lösen.
„Cannot complete your request‘“ on Netscaler Gateway VPX
In my lab environment I was using a Citrix Webinterface 5.x which was accessible from Internet over a Access Gateway 5 VPX. Since Citrix Store Front is in a fairly usable release (> Version 2.x), I intended to update my lab environment to the current software releases and update my skills to Store Front and Netscaler Gateway VPX.
You can find a step by step Netscaler Gateway intro here http://blogs.citrix.com/2013/07/03/citrix-netscaler-gateway-10-1-118-7-quick-configuration-wizard
Also a very nice guide you can find here, this guide also contains information about how to configure StoreFront for Netscaler Gateway VPX: http://benjamin.eavey.com/2013/07/netscaler-vpx-as-secure-gateway-replacement
Cannot complete your request
After completion of the configuration I was not able to access the my environment from outside. The login to the Netscaler Gateway, the black window, was working fine, but as soon I hit the StoreFront I get this Error:
Because StoreFront is working fine from internal, I assumed that’s not a completely wrong StoreFront configuration. After i had a look into the event viewer on the StoreFront server I can see that something is wrong here:
The crucial indication that’s a problem between the Store Front server and the the Netscaler Gateway in role of Authentication Callback Server I found here:
when I browse to the address https://192.168.x.x/CitrixAuthService/AuthService.asmx you can see a certificate error, so I need to have here a FQDN that match to the installed certificate but I wont communicate outside, so first I’ve defined the internal IP as Callback URL:
Now I’ve changed the Callback URL to the FQDN appropriate to the certificate:
But because the DNS resolve this URL as the external IP which is not accessible over the necessary TCP ports, I was constrained to do a dirty hack … I have edited my host file :
Issue by creating a PVS 7.1 farm
If you try to create a new Farm and the Provisioning Services Configuration Wizard stuck on a „Not responding“ during the Database Server step maybe you have to many databases on the Server:
Workaround: Use the DbScript.exe to get the Database creation script and create the database with this script directly on the DB server:
Citrix DSCHECK doesen’t work … „No resource module ImaMsgsUI.dll found.“
When you try to make a Citrix Datastore validaiton with DSCHECK you receive the error message :
“ No resource module ImaMsgsUI.dll found. „
Cause:
Probably you are on a Citrix server with UAC,
Solution:
Launch the command line with administrative privileges, „run as administrator“ before you make the dscheck.
more details about dscheck.exe here: http://support.citrix.com/article/CTX124406
