In einem meiner letzten Citrix XenDesktop Kursen schilderte mir ein Teilnehmer die Problematik, dass bei Ihnen die gepinnten Dokumente (also Dokumente, welche z.B. bei Word in der Taskleiste fixiert wurden) nach einer Neuanmeldung eines Benutzers nicht mehr vorhanden waren:

Aus dieser Schilderung heraus haben wir ein wenig Brainstorming zu den möglichen Ursachen vorgenommen und hier ein wenig die Zusammenhänge:

Die eigentliche Ursache für das Verhalten ist weder bei den Roaming Profiles noch bei Citrix Profile Management zu suchen, sondern bei GPO Einstellungen welche gerne eingestellt werden:

Clear history of recently opened documents on exit

Diese Einstellung bewirkt, dass Dateien während einer Benutzersitzung in der Taskleiste erscheinen und auch angepinnt werden können.
Beim Abmelden werden diese jedoch gelöscht.
Dieses Verhalten kann falls gewünscht mittels Citrix Profile Management angepasst werden.

Do not keep history of recently opened documents

Diese Einstellung bewirkt, dass Dateien selbst während einer Benutzersitzung in der Taskleiste gar nicht erst erscheinen und somit nicht angepinnt werden können.
Dieses Verhalten kann selbst mit Citrix Profile Management nicht angepasst werden.

***

Lösungsansatz mittels Citrix Profile Management (CPM)

Mittels CPM können die einmal geöffneten Dateien in das Profil übernommen werden, so dass diese auch nach einer Neuanmeldung des Benutzers noch verfügbar sind.
Dazu wird folgender Pfad einmal ein den durch CPM verarbeiteten Ordner ausgeschlossen dafür mittels Ordner-Spiegelung während der Sitzung gleich in die Profilfreigabe geschrieben:

!ctx_roamingappdata!\Microsoft\Windows\Recent\AutomaticDestinations

Danach sind die gepinnten Dokumente auch nach einer Neuanmeldung noch vorhanden:

Ich hoffe, ich konnte dem einen oder anderen ein wenig weiterhelfen :-)

Viel Erfolg beim Nachbau…

Hallo zusammen

Wer schon einmal versucht hat eine VHD/VHDX im Hyper-V über den normalen Weg zu verkleinern, wird sicherlich schon hier gestrandet sein:

Standardmässig wird kein „verkleinern“ angeboten. Wenn man im weiten Internet sucht wird auch nur von vergrössern gesprochen, bzw. auf ein altes Tool verwiesen, welches nicht mehr verfügbar ist bzw. welches nur VHD aber keine VHDX Dateien handhaben kann.

Der Trick ist dass man den Weg über das Datenträger-Management gehen muss.
Innerhalb der Datenträgerverwaltung fügt man die gewünschte virtuelle Disk hinzu. Erwähnenswert ist hier, dass die Disk natürlich nicht in Gebrauch sein darf!

Anschliessend kann man wie bei einer normalen Festplatte die Partitionen vergrössern oder in unserem Fall verkleinern:

Jetzt wo wir wieder nicht zugewiesenen Speicherplatz haben, müssen wir uns wieder von der VHD trennen, damit wir im Hyper-V die virtuelle Disk verkleinern können:

Im Hyper-V gehen wir wieder die Schritte wie am Anfang und werden feststellen, dass nun die Option zur Verkleinerung der Disk zur Verfügung steht:

Mir ist bewusst, dass dieser Task weniger in produktiven Umgebungen benötigt wird. Jeder der jedoch selbst eine kleine Test- bzw. Demo-Umgebung betreibt ist da sicherlich schon an die Grenzen der Speicherkapazitäten gestossen und wollte die ursprünglich grosszügig bemessenen Disks wieder verkleinern.

Viel Erfolg dabei :-)

Hallo zusammen

Wir haben neu in unserer Umgebung eine Synology RS2414+ NAS Appliance.
Wie man diese einrichtet ist in der Doku des Herstellers ersichtlich ;-)

Ich möchte hier nur auf Punkte eingehen, wie das NFS auf der Appliance eingerichtet und im XenServer zum VM-Export benutzt wird.

Im ersten Schritt werden die Volumes und freigegebenen Ordner gemäss Doku eingerichtet.
Danach sollte man kontrollieren ob NFS aktiviert ist:

Nun müssen die NFS Berechtigungen auf dem freigegebenen Ordner hinterlegt werden:

Dabei werden die Host-Systeme (in unserem Fall die XenServer) definiert, welche auf den NFS Ordner zugreifen dürfen.
Man beachte auch den „Mount path“ unten links (in dem Fall „/volume1/Backup“). Diesen werden wir in der CLI benötigen

Die NAS ist nun bereit und wir wechseln in die CLI des XenServers.

Als erstes erstellen wir einen Ordner, welcher den Mount-Pfad für das NFS bildet, z.B.

mkdir /tmp/bkp

Im nächsten Schritt müssen wir den NFS Ordner mounten (192.168.199.210 = IP unserer NAS):

mount -t nfs 192.168.199.210:/volume1/Backup /tmp/bkp

Und zu guter Letzt können wir nun die einzelnen Virtuellen Maschinen exportieren:

xe vm-export vm="Name der VM" filename="Exportpfad" --compress
xe vm-export vm=PITVM01 filename=/tmp/bkp/PITVM01.xva --compress

Der Parameter –compress sorgt dafür dass die exportierte Datei komprimiert wird.

Wenn ihr danach sucht, findet ihr auch entsprechende Skripte um dies automatisieren zu können.

Viel Spass beim Ausprobieren ;-)

Im Artikel „NetScaler Content-Switching für HTTP zu HTTPS Umleitung für mehrere Domains“ habe ich eine Variante der HTTP zu HTTPS Umleitung mittels Content Switching (CS) beschrieben. Mein Kollege Claudio Mascaro hat das Ganze nun ein wenig eleganter mittels einer Responder Policy gelöst :-)

Dafür benötigt man als ersten einen HTTP Loadbalancing (LB) vServer, welcher permanent „ON“ ist und welcher die gleiche IP wie der HTTPS CS vServer aufweist (z.B. 192.168.200.10):

add server PITDUMMY 192.168.199.199
add service svc-HTTPtoHTTPS PITDUMMY HTTP 80 -healthMonitor NO
bind service svc-HTTPtoHTTPS -monitorName tcp -monState DISABLED
add lb vserver lb-vsrv-http.domain.pit HTTP 192.168.200.10 80
bind lb vserver lb-vsrv-http.domain.pit svc-HTTPtoHTTPS

Um den Service permanent „ON“ zu schalten wurde das Monitoring mit den Parametern deaktiviert:
– -healthMonitor NO
– bind service HTTPtoHTTPS -monitorName tcp -monStateDISABLED

Nun benötigt man noch eine Responder Policy welche die Anfrage von HTTP zu HTTPS umleitet:

add responder action rs_act_httptohttps redirect "\"https://\" + HTTP.REQ.HOSTNAME.HTTP_URL_SAFE + HTTP.REQ.URL.PATH_AND_QUERY.HTTP_URL_SAFE" -responseStatusCode 302
add responder policy rs_pol_httptohttps "!CLIENT.SSL.IS_SSL" rs_act_httptohttps

Zu guter Letzt muss diese Policy nun noch dem vorher erstellten LB vServer zugewiesen werden:

bind lb vserver lb-vsrv-http.domain.pit -policyName rs_pol_httptohttps -priority 100 -gotoPriorityExpression END -type REQUEST

Ab jetzt wird jede HTTP Anfrage an die IP 192.168.200.10 nach HTTPS umgeleitet. Somit ist der Weg frei um beim HTTPS CS vServer jederzeit neue Policies hinzuzufügen, ohne sich noch Gedanken über eine Umleitung machen zu müssen.

Ein spezieller Dank geht hier an unseren Master CCI Claudio Mascaro, welcher dies auf unserem System entsprechend eleganter als meine Lösung eingerichtet hat :-)

Skript: NS-HTTP2HTTPS-Responder

Hallo zusammen

In einer neuen Unified Gateway Umgebung hatte ich die Situation, dass über die gleiche IP mehrere Hostnamen angesprochen werden.
Für HTTPS wird beim Wizard automatisch schon ein Content Switching (CS) eingerichtet, welches mit weiteren Policies und Ziel vServer erweitert werden können.

Eine automatische Umleitung von HTTP nach HTTPS wird jedoch nicht eingerichtet. Zu Zeiten als jeder NetScaler Gateway (NSGW) vServer eine eigene IP hatte, richtete man einfach einen Loadbalancing (LB) vServer mit einer Redirection URL ein und fertig. Was nun aber im oben genannten Fall?

Bestehend nach dem Wizard und ein paar Anpassungen:
– CS vServer cs-vsrv-https.domain.pit mit der IP 192.168.200.10 konfiguriert für HTTPS
– NSGW vServer nsgw-vsrv-citrix.domain.pit mit der IP 0.0.0.0
– LB vServer lb-vsrv-data.domain.pit mit der IP 0.0.0.0
– LB vServer lb-vsrv-mail.domain.pit mit der IP 0.0.0.0
– drei DNS Einträge citrix.domain.pit, data.domain.pit und mail.domain.pit auf eine spezifische öffentliche IP

In unserer Umgebung haben wir dies mit einem weiteren Content Switching vServer mit HTTP und den dazu gehörenden LB vServern eingerichtet:

add cs vserver cs-vsrv-http.domain.pit HTTP 192.168.200.10 80
add cs policy cs-pol-http-citrix -rule "HTTP.REQ.HOSTNAME.STARTSWITH(\"citrix\")"
add cs policy cs-pol-http-data -rule "HTTP.REQ.HOSTNAME.STARTSWITH(\"data\")"
add cs policy cs-pol-http-mail -rule "HTTP.REQ.HOSTNAME.STARTSWITH(\"mail\")"
add lb vserver http_redirect-citrix.domain.pit HTTP 0.0.0.0 0 -redirectURL "https://citrix.domain.pit"
add lb vserver http_redirect-data.domain.pit HTTP 0.0.0.0 0 -redirectURL "https://data.domain.pit"
add lb vserver http_redirect-mail.domain.pit HTTP 0.0.0.0 0 -redirectURL "https://mail.domain.pit"
bind cs vserver cs-vsrv-http.domain.pit -policyName cs-pol-http-data -targetLBVserver http_redirect-data.domain.pit -priority 100
bind cs vserver cs-vsrv-http.domain.pit -policyName cs-pol-http-mail -targetLBVserver http_redirect-mail.domain.pit -priority 200
bind cs vserver cs-vsrv-http.domain.pit -policyName cs-pol-http-citrix -targetLBVserver http_redirect-citrix.domain.pit -priority 300

Nun prüft zuerst die Policy vom CS nach der Subdomain und leitet an den entsprechenden HTTP vServer weiter. Dieser wiederum hat eine Umleitung auf die korrekte HTTPS Adresse hinterlegt.

Am Rande bemerkt: so sieht im Grundsatz auch die CS Konfiguration des Unified Gateways aus. Dieser basiert auf HTTPS, benötigt zusätzlich noch ein SSL Zertifikat und der NSGW vServer muss eingerichtet werden. Darauf verzichte ich jedoch in diesem Blogeintrag. ;-)

Skript: NS-HTTP2HTTPS-CS

Hallo NetScaler Freunde

Im letzten Artikel „XML Dienste & Citrix Director gemeinsam hinter NetScaler“ berichtete ich über die Möglichkeit XML und Director über den gleichen Loadbalancing (LB) vServer zu konfigurieren. Was nun aber, wenn auch noch Storefront auf dem gleichen Server installiert ist?

Vom Prinzip her verwenden wir wieder den LB vServer wie im letzten Artikel beschrieben.

Im DNS Server fügt man nun einen weiteren Host Eintrag hinzu:
storefront.domain.pit = 192.168.100.30

Nun benötigen wir eine weitere Responder Policy, welche
– den Hostname überprüft (startet der Hostename mit storefront…?)
– prüft, ob die URL den Wert „StoreWeb“ noch nicht enthält – unabhängig der GROSSklein Schreibung
– nach /Citrix/StoreWeb umleitet, sofern oben genannte Bedingungen zutreffen:

add responder action Resp_Act_to_SF-StoreWeb redirect "\"/Citrix/StoreWeb\"" -responseStatusCode 302

add responder policy Resp_Pol_to_SF-StoreWeb "HTTP.REQ.HOSTNAME.STARTSWITH(\"storefront\") && HTTP.REQ.URL.SET_TEXT_MODE(IGNORECASE).CONTAINS(\"StoreWeb\").NOT" Resp_Act_to_SF-StoreWeb

bind lb vserver lb-vsrv-PIT-XD-HTTPS -policyName Resp_Pol_to_SF-StoreWeb -priority 100 -gotoPriorityExpression END -type REQUEST

Mit dieser weiteren Responder Policy ist nun auch dieses Ziel erreicht.

Skript: NS-RespStorefront

Hey NetScaler Fans

Ich habe in meiner Umgebung folgendes Szenario:
– zwei XenDesktop Controller auf welchen auch Director installiert ist
– einen Loadbalancing (LB) vServer auf dem NetScaler, welcher beide Server ansteuert

Ziel war es:
– den SSL LB vServer für XML-Anfragen zwischen Storefront und Controller zu verwenden mit Hostname = xmlxd7.domain.pit
– den gleichen SSL LB vServer für den Zugriff auf die Director Site zu verwenden mit Hostname = director.domain.pit
… bis hierher noch kein Problem, aber
– beim Zugriff auf den Hostname director.domain.pit soll der NetScaler im Bedarfsfall auf die URL /Director umleiten, aber KEINESFALLS wenn eine XML Anfrage den LB vServer erreicht

Soweit so gut, das Loadbalancing einrichten ist soweit ja mal keine Hexerei:

add server pit-xd01 192.168.100.31
add server pit-xd02 192.168.100.32

add service svc-https-pit-xd-01 pit-xd01 SSL 443
add service svc-https-pit-xd-02 pit-xd01 SSL 443

add lb vserver lb-vsrv-PIT-XD-HTTPS SSL 192.168.100.30 443 -persistenceType SOURCEIP -timeout 1440

bind lb vserver lb-vsrv-PIT-XD-HTTPS svc-https-pit-01
bind lb vserver lb-vsrv-PIT-XD-HTTPS svc-https-pit-02

add ssl certKey lb-server-cert -cert lb-server.cert -key lb-server.key
add ssl certKey PIT-CA -cert PIT-CA.cer
link ssl certKey lb-server-cert PIT-CA 
bind ssl vserver lb-vsrv-PIT-XD-HTTPS -certkeyName lb-server-cert

Im DNS müssen nun zwei Host-Einträge für den neuen vServer erstellt werden:
xmlxd7.domain.pit = 192.168.100.30
director.domain.pit = 192.168.100.30

Jetzt folgt der kniffligere Teil – die Umleitung für die Director URL.
Dies ist mit einer Responder Policy zu lösen, welche
– den Hostname überprüft (startet der Hostename mit director…?)
– prüft, ob die URL den Wert „director“ noch nicht enthält – unabhängig der GROSSklein Schreibung
– nach /director umleitet, sofern oben genannte Bedingungen zutreffen:

add responder action Resp_Act_to_Director redirect "\"/Director\"" -responseStatusCode 302

add responder policy Resp_Pol_to_Director "HTTP.REQ.HOSTNAME.STARTSWITH(\"director\") && HTTP.REQ.URL.SET_TEXT_MODE(IGNORECASE).CONTAINS(\"director\").NOT" Resp_Act_to_Director

bind lb vserver lb-vsrv-PIT-XD-HTTPS -policyName Resp_Pol_to_Director -priority 100 -gotoPriorityExpression END -type REQUEST

Mit dieser Responder Policy ist nun auch dieses Ziel erreicht.

Und als Abschluss noch dies…
Der aufmerksame Leser hat festgestellt, das der LB vServer für XML und Director auf Port 443 (HTTPS) reagiert. Bei der Eingabe geht dies jedoch des öftern mal vergessen. Dafür kann man einen weiteren LB vServer mit einer Umleitung einrichten:

add lb vserver http_redirect-director.domain.pit HTTP 192.168.100.30 80 -redirectURL "https://director.software-online.ch"

Viel Erfolg beim Nachbauen :-)

Skript: NS-XMLandDirector

Hallo Citrix Freunde

Ich hatte gerade einen interessanten Supportfall.

Der Benutzer hat auf seinem lokalen Rechner die DPI Einstellung verändert (im konkreten Fall auf 150 DPI):

Sobald der Benutzer eine ICA Sitzung startet wird diese entsprechend der DPI Werte skaliert und kann nicht verändert werden:

Folgende Einstellungen bei den Prozessen wfcrun32.exe und wfica32.exe sorgen für Abhilfe.

Ob dieser Workaround für ewig funktioniert oder nur temporär entzieht sich meinen Kenntnissen. Diese Informationen habe ich netterweise vom Partner erhalten mit welcher wegen dem Problem an uns gelangte, die „Lösung“ jedoch selbst gefunden hat.

Hallo zusammen

Wer schon mit Citrix Director gearbeitet hat, ist sicher schon über die folgende Meldung gestolpert:

Die von der Installation angelegte Verknüpfung verweist auf eine HTTP URL und nicht HTTPS, was zur Sicherheitsmeldung führt. Falls diese störend sein sollte, so kann diese im IIS deaktiviert werden.

Dazu öffnet man die Director Site im IIS Manager und wählt die Application Settings:

Sobald man den Parameter UI.EnableSSLCheck auf False ändert, verschwindet auch die Meldung.

Weitere Informationen: http://support.citrix.com/article/CTX135749
(Beschreibung ganz unten)

—–

ab Director 7.x

Hallo zusammen

Director ist meines Erachtens wirklich ein brauchbares Tool für den Helpdesk. Eine Problematik kann jedoch das Tab Applications innerhalb der Benutzerdetails darstellen. Der Helpdesk sieht da die komplette Titelleiste der geöffneten Applikationen und sind wir ehrlich, gewisse Dinge (Dateinamen, Homepage-Titel, etc.) gehen den Helpdesk nur bedingt etwas an:

Um dies zu vermeiden kann man die Übermittlung der Daten entweder mittels Registry-Anpassung seitens VDA unterdrücken oder man deaktiviert die Darstellung innerhalb des Director Frontends.

Dazu öffnet man die Director Site im IIS Manager und wählt die Application Settings:

Sobald man den Parameter UI.TaskManager.EnableApplications auf False ändert, verschwinden zwar die Applikationen jedoch die Prozesse bleiben sichtbar und können weiterhin von den berechtigten Helpdesk-Mitarbeitern geschlossen werden.

—–

ab Director 7.x