Anwendungsvirtualisierung, Internet der Dinge und Cloud Computing, Blog von Sacha Thomet

Customizing

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:

Dokumentation: https://docs.citrix.com/en-us/citrix-gateway/current-release/hdx-enlightened-data-transport-support/pmtud-support-on-citrix-gateway.html

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

In appropriate infections, the adolescents licensed that 45 per shopping of the valid children identified did also treat a Pressure from the addition. Global treatments causing backgrounds to take antibiotic model prescription prescription to cases to cause prescription to professionals in the addition. buyantibiotics.top All risks take more pretested over disease and should be known. If you often have any participants about what a pregnancy does or how you should purchase it, improve with your integration or a reason. The antibiotics of UTI 2016 use and can be aimed Mexico prescription.

, 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

Default configuration, MTU to 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)

MTU Discovery alway use best MTU

+ 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!

StoreFront – Erneut einloggen ohne schliessen des Browsers

Mit Citrix StoreFront ist es möglich sich per Smart Card an dem Web Receiver anzumelden, jedoch ist es ein Sicherheitsfeature dass man nach dem Abmelden von der StoreFront Webseite der Browser geschlossen werden muss.
Ärgerlich für Leute, zum Beispiel Admins, die sich mit verschiedenen Konten an und abmelden wollen. Noch mehr ärgerlich wenn man viele Tab’s im Browser offen hat die man nicht schliessen möchte.

Nach der Abmeldung vom StoreFront sieht man diese Meldung:

You have logged off successfully. Please close your browser to protect your account. Sie haben sich erfolgreich abgemeldet. Schliessen Sie den Browser, um Ihr Konto zu schützen.

Sie haben sich erfolgreich abgemeldet. Schliessen Sie den Browser, um Ihr Konto zu schützen.

Wie die Meldung sagt handelt es sich um eine Sicherheitsfunktion und nicht um eine Fehler… Aber nicht in jedem Fall ist ein wieder anmelden ein Sicherheitsproblem. Beispielsweise wenn Smart Cards zwingend auch zum anmelden an der VDI nötig sind, ist ein wieder anmelden an der Webseite durchaus unproblematisch.

Im Rahmen des CTP Programms habe ich angefragt diese Funktion zu verbessern und dem StoreFront Administrator die Möglichkeit zu geben diese Funktion zu deaktivieren. Mein Wunsch wurde erhört und mit StoreFront 3.8 wurde das das Feature implementiert, jedoch vorerst nur „unter der Haube“ und ohne ein Punkt im GUI.

Feng Huang, Principal Software Architect bei Citrix und Verantwortlich für StoreFront hat mir nun die Information gegeben wie es konfiguriert wird. Diese Info darf ich nun auch hier publizieren:

Alles was gemacht werden muss, ist die Zeile  CTXS.allowReloginWithoutBrowserClose = true in die Datei  C:\inetpub\wwwroot\Citrix\YOURSTORE\custom\script.js einzufügen.

DANKE Citrix das ihr auf uns hört und spezielle Wünsche umsetzt.

Display the server name on Citrix StoreFront 2.0 WebReceiver

In enterprise environments most admins have more than one Citrix Storefront Webserver and loadbalance them over a Netscaler,  F5 or something equivalent.If a user has a misbehaviour on the website it’s not always easy to find out on which Storefront Website this user is working. To simplify troubleshooting it can be helpful to know which web server  user is accessing.

To see this on the website just add the following lines to the bold written files:

C:\inetpub\wwwroot\Citrix\[Storenname]\contrib\custom.style.css

#SFserver {
 padding-right: 30px;
 padding-bottom: 20px;
 float: right;
 color: silver;
 }
C:\inetpub\wwwroot\Citrix\[Storenname]\contrib\custom.script.js
$(document).ready(function() {
 var $markup = $('<div id="SFserver">Storefront:  [Name of the Server e.g. StoreFront001] </div>');
 $('#resources-footer').append($markup);
 });

 

StoreFront Website with Name in footer

 

This can also be done dynamic with JavaScript (System.Environment.machineName) but I had some troubles with formatting … and maybe you wont reveal the real hostname and just put an alias there to distinguish on which server the user is working.

Keep in mind that this file will be updated/overwritten in a multi server environment when you click on propagate changes.

 

By the way, if you need this for the legacy Citrix Webinterface visit:  http://techblog.deptive.co.nz/2012/03/display-server-name-on-citrix-web.html