– Jan's Cloud – online Gedankenstütze ;)

25. Oktober 2018

Remotedesktop Blackscreens mit Server 2016

Filed under: Citrix,Remotedesktopdienste,Windows Server,XenApp — Schlagwörter: , , , , , , , , — Jan Mischo @ 09:31

Verschiedene Situationen die mit Terminalservern / VDAs unter Windows Server 2016 zu Blackscreens führen können

In unterschiedlichen Kundenumgebungen mit und ohne Citrix gab es in den letzten Monaten immer wieder Blackscreens bei der Anmeldung von Usern. Bei fast jedem Blackscreen half es nur den entsprechenden Session-Host bzw. die VDA durchzubooten. Hier einmal eine kleine Auflistung, welche Fehler in welchen Konstellationen aufgetreten sind und wie sie sich ggfs. beheben lassen:

  1. Citrix Virtual Apps and Desktops (XenApp / XenDesktop) verursacht in den Versionen 7.15 LTSR bis 7.17 bei Einsatz des User Profile Managers einen schwarzen Bildschirm
  2. Die Abmeldung eines Users mit durchgereichter Smart Card verursacht für sämtliche Neuanmeldungen am betroffenen Host Blackscreens
  3. Mozilla Firefox bringt den Audio-Dienst und AudioDG.exe zum Absturz und Neuanmeldungen landen für längere Zeit (ca. 10 – 20 Minuten) im Blackscreen

zu 1) Hier hilft, im 7.15 LTSR Fall, das Update auf 7.15 LTSR CU2 sowie anschließend die Installation des Hotfixes für den UPM: https://support.citrix.com/article/CTX235399. Sollte man im Blackscreen „gefangen“ sein, dann hilft CTX235100. Für den Fall, dass das Current Release (CR) eingesetzt wird, würde ich auf 7.18 bzw. 7 1808 updaten. So eben (29.10.2018) hat Citrix das CU3 für den Long Term Servie Release 7.15 veröffentlicht und den „Black Screen“ als Fixed Issue angegeben (https://docs.citrix.com/en-us/xenapp-and-xendesktop/7-15-ltsr/whats-new/cumulative-update-3/fixed-issues.html):

  • 7.15 LTSR CU2 sessions might launch as a black screen. The issue occurs with sessions running on XenApp and XenDesktop 7.15 LTSR CU2 and 7.17 VDAs when Profile Management is enabled. For more information and a workaround, see Knowledge Center article CTX235100. [LC9648]

zu 2) Dieser Bug wurde mit dem Kummulativen Update KB4103720 und folgenden behoben. In mehreren Fällen musste neben dem Update die Registry noch angepasst werden. Dazu unter

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Cryptography\Calais
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Calais

jeweils den 32-Bit DWORD „ForceWinStationUnregisterCall“ mit dem Wert 1 anlegen sowie die Sessions-Hosts durchbooten.

zu 3) Nach einem kurzen Case bei Microsoft hat sich ergeben, dass hier eine Deinstallation von Firefox auf den RDSHs / VDAs oder ein Deaktivieren des Audio-Dienstes hilft. Im Technet gibt es dazu einen etwas längeren Thread, mit einem kleinen Script, welches bei einem Kunden stündlich läuft und so „Abhilfe“ schafft. Zusätzlich empfiehlt es sich, die Windows Sounds zu deaktivieren. Dadurch kommt es nicht zum zehn- bis zwanzigminütigem Blackscreen-Loop. Deaktivieren lassen sich die Sounds z.B. per Gruppenrichtlinien-Einstellung Registry:

HKCU\AppEvents\Schemes (Default) REG_SZ .None

Quelle für den Registry Key: https://social.technet.microsoft.com/Forums/en-US/4e3ff4ea-ad23-4dda-b1e9-022f8d76c8e6/remote-desktop-rds-2016-gives-back-screen-on-logon-and-prevents-progression-to-desktop-audiodgexe?forum=winserverTS

REM Terminal Server instability seems to be caused by AudioDG.exe hanging and the Windows Audio
REM  service. Restarting these seems to bring it back up. So hopefully, pre-emptively restarting
REM  them at intervals will prevent it.

net stop Audiosrv
taskkill /F /IM AudioDG.exe
net start Audiosrv

Sollten mir noch weitere Blackscreens unter Terminalserver / Remotedesktopserver / XenApp & XenDesktop bzw. virtual Apps and Desktops auf die Füße fallen, so würde ich hier einfach ergänzen. 🙂

Zuletzt bearbeitet am:
  • 29.10.2018: 7.15 LTSR CU3 Informationen ergänzt.

16. Juli 2018

Exchange und Remotedesktopgateway über eine IP veröffentlichen

Filed under: Citrix,Exchange,Netscaler,Remotedesktopdienste — Schlagwörter: , , , , , , , , , — Jan Mischo @ 12:38

Mit dem Netscaler VPX Express (Freemium) Exchange und Remotedekstopgateway bzw. Outlook WebApp, Outlook Anywhere, Exchange ActiveSync, Remotedesktopgateway und die Remotedesktop Web Services über eine öffentliche IP betreiben

Ich komme häufig in Kundenumgebungen, in denen es nur noch eine freie externe IP Adresse gibt, und dennoch die Exchange- sowie Remotedesktopdienste nach außen veröffentlicht werden sollen. Hier kann man jetzt „unschön“ ansetzen und die Ports für Exchange oder RDS auf z.B. 10443 verbiegen und damit in diverse andere Probleme laufen oder man bedient sich dem kostenlosen Netscaler VPX Freemium (formerly known as Netscaler VPX Express) und größtenteils dem Content Switching.

Ich würde an dieser Stelle einfach mal voraussetzen, dass der Exchange Server entsprechend sauber mit Split DNS konfiguriert ist, die Remotedesktopdienste ebenfalls funktionstüchtig sind und der Netscaler grundkonfiguriert ist. Ebenfalls sollte es ein vertrauenswürdiges SAN Zertifikat mit den passenden FQDNs geben. In meinem Beispiel:

  • „app.<domain>.<tld>“
  • „autodiscover.<domain>.<tld>“
  • „outlook.<domain>.<tld>“

Dieses Zertifikat muss im ersten Step auf dem Netscaler installiert werden. Dazu kann man sich zum Beispiel dem Citrix Knowledge Center bedienen: https://support.citrix.com/article/CTX205404

Der Einfachheit halber starte ich direkt mal mit dem Weg über das Command Line Interface bzw. per SSH. Evtl. wird der Beitrag ja später noch um eine GUI Variante erweitert. 🙂 Also legen wir als erstes die Server im Load Balancing an, erstellen die Dienste sowie die Load Balancing Virtual Servers (GUI: Traffic Management -> Server bzw. -> Services bzw. -> Virtual Servers):

add server SRV_EXCHSRV <IP ADRESSE DES EXCHANGES>
add server SRV_CBSRV <IP ADRESSE DES RDGW / RDWEB>

add service SVC_Exchange_SSL SRV_EXCHSRV SSL 443 -gslb NONE -maxClient 0 -maxReq 0 -cip DISABLED -usip NO -useproxyport YES -sp OFF -cltTimeout 180 -svrTimeout 360 -CKA YES -TCPB YES -CMP NO
add service SVC_RDWeb-RDGW_SSL SRV_CBSRV SSL 443 -gslb NONE -maxClient 0 -maxReq 0 -cip DISABLED -usip NO -useproxyport YES -sp OFF -cltTimeout 180 -svrTimeout 360 -CKA YES -TCPB YES -CMP NO
add service SVC_RDWeb-RDGW_UDP-3391 SRV_CBSRV UDP 3391 -gslb NONE -maxClient 0 -maxReq 0 -cip DISABLED -usip NO -useproxyport NO -sp OFF -cltTimeout 120 -svrTimeout 120 -CKA YES -TCPB YES -CMP NO

add lb vserver LB_VS_Exchange SSL 0.0.0.0 0 -persistenceType NONE -cltTimeout 180
add lb vserver LB_VS_RDWeb-RDGW SSL 0.0.0.0 0 -persistenceType SOURCEIP -cltTimeout 180
add lb vserver LB_VS_RDWeb-RDGW-UDP UDP 0.0.0.0 0 -persistenceType SOURCEIP -cltTimeout 120
bind lb vserver LB_VS_Exchange SVC_Exchange_SSL
bind lb vserver LB_VS_RDWeb-RDGW SVC_RDWeb-RDGW_SSL
bind lb vserver LB_VS_RDWeb-RDGW-UDP SVC_RDWeb-RDGW_UDP-3391

set ssl vserver LB_VS_Exchange -ssl3 DISABLED
set ssl vserver LB_VS_RDWeb-RDGW -ssl3 DISABLED
bind ssl vserver LB_VS_Exchange -certkeyName <NAME DES IMPORTIERTEN ZERTIFIKATES>
bind ssl vserver LB_VS_RDWeb-RDGW -certkeyName <NAME DES IMPORTIERTEN ZERTIFIKATES>

Damit die Server nicht „blank“ per http(s) erreichbar sind, schränke ich den Zugriff auf die gewollten Verzeichnisse des WebServer (IIS) ein (GUI: AppExpert -> Pattern Sets bzw. -> Rewrite -> Actions / Policies):

add policy patset patt_set_rdweb_path
add policy patset patt_set_exchange_path

bind policy patset patt_set_rdweb_path "/" -index 4
bind policy patset patt_set_rdweb_path "/rpcwithcert" -index 1
bind policy patset patt_set_rdweb_path "/rpc" -index 2
bind policy patset patt_set_rdweb_path "/rdweb" -index 3
bind policy patset patt_set_exchange_path "/mapi" -index 1
bind policy patset patt_set_exchange_path "/ecp" -index 2
bind policy patset patt_set_exchange_path "/owa" -index 3
bind policy patset patt_set_exchange_path "/oab" -index 4
bind policy patset patt_set_exchange_path "/ews" -index 5
bind policy patset patt_set_exchange_path "/autodiscover" -index 6
bind policy patset patt_set_exchange_path "/rpcwithcert" -index 7
bind policy patset patt_set_exchange_path "/rpc" -index 8
bind policy patset patt_set_exchange_path "/microsoft-server-activesync" -index 9

add rewrite action rew_act_exchange_invalid_path replace http.REQ.URL.PATH "\"/owa\""
add rewrite action rew_act_rdweb_invalid_path replace http.REQ.URL.PATH "\"/rdweb\""

add rewrite policy rew_pol_exchange_invalid_path "!http.REQ.URL.PATH.TO_LOWER.CONTAINS_ANY(\"patt_set_exchange_path\")" rew_act_exchange_invalid_path
add rewrite policy rew_pol_rdweb_invalid_path "!http.REQ.URL.PATH.TO_LOWER.CONTAINS_ANY(\"patt_set_rdweb_path\")" rew_act_rdweb_invalid_path

bind lb vserver LB_VS_Exchange -policyName rew_pol_exchange_invalid_path -priority 100 -gotoPriorityExpression END -type REQUEST
bind lb vserver LB_VS_RDWeb-RDGW -policyName rew_pol_rdweb_invalid_path -priority 100 -gotoPriorityExpression END -type REQUEST

In der GUI müssen die letzten beiden Schritte natürlich unter Traffic Management -> Load Balancing -> Virtual Servers und dann den entsprechenden LB VServern vorgenommen werden. Damit wären die Vorbereitungen der Load Balancing Objekte (Server, Dienste, virtuelle Server) fertig und es geht nahtlos über zum Conten Switching (Traffic Management -> Content Switching -> Policies bzw. Virtual Servers).

add cs policy CS_POL_Exchange -rule "http.REQ.HOSTNAME.TO_LOWER.STARTSWITH(\"outlook.<domain>.<tld>\") || http.REQ.HOSTNAME.TO_LOWER.STARTSWITH(\"autodiscover.<domain>.<tld>.de\")"
add cs policy CS_POL_RDWeb-RDGW1 -rule "http.REQ.HOSTNAME.TO_LOWER.STARTSWITH(\"app.<domain>.<tld>\") && http.REQ.HEADER(\"User-Agent\").SET_TEXT_MODE(IGNORECASE).CONTAINS(\"MS-RDGateway/1.0\")"
add cs policy CS_POL_RDWeb-RDGW2 -rule "http.REQ.HOSTNAME.TO_LOWER.STARTSWITH(\"app.<domain>.<tld>\") && http.REQ.HEADER(\"User-Agent\").SET_TEXT_MODE(IGNORECASE).CONTAINS(\"MSRPC\")"
add cs policy CS_POL_RDWeb-RDGW3 -rule "http.REQ.HOSTNAME.TO_LOWER.STARTSWITH(\"app.<domain>.<tld>\") && http.REQ.URL.REGEX_MATCH(re-^/RDWeb/*-)"

add ns httpProfile nshttp_profile_websocket -webSocket ENABLED

add responder action res_act_http_redirect respondwith q{"HTTP/1.1 301 Moved Permanently\r\nLocation: https://" + HTTP.REQ.HOSTNAME.HTTP_URL_SAFE + "/\r\n\r\n"}
add responder policy res_pol_http_redirect true res_act_http_redirect

add cs vserver cs_EXCH_RDS-SSL SSL <IP ADRESSE DES CONTENT SWITCH VSERVERS> 443 -cltTimeout 180 -caseSensitive OFF -httpProfileName nshttp_profile_websocket
add cs vserver cs_EXCH_RDS-SSL_HTTP_redirect HTTP <IP ADRESSE DES CONTENT SWITCH VSERVERS> 80 -cltTimeout 180
add cs vserver cs_RDS-UDP UDP <IP ADRESSE DES CONTENT SWITCH VSERVERS> 3391 -cltTimeout 120

bind cs vserver cs_EXCH_RDS-SSL -policyName CS_POL_Exchange -targetLBVserver LB_VS_Exchange -priority 5
bind cs vserver cs_EXCH_RDS-SSL -policyName CS_POL_RDWeb-RDGW1 -targetLBVserver LB_VS_RDWeb-RDGW -priority 10
bind cs vserver cs_EXCH_RDS-SSL -policyName CS_POL_RDWeb-RDGW2 -targetLBVserver LB_VS_RDWeb-RDGW -priority 11
bind cs vserver cs_EXCH_RDS-SSL -policyName CS_POL_RDWeb-RDGW3 -targetLBVserver LB_VS_RDWeb-RDGW -priority 12
bind cs vserver cs_EXCH_RDS-SSL_HTTP_redirect -policyName res_pol_http_redirect -priority 100 -gotoPriorityExpression END -type REQUEST
bind cs vserver cs_RDS-UDP -lbvserver LB_VS_RDWeb-RDGW-UDP

set ssl vserver cs_EXCH_RDS-SSL -ssl3 DISABLED
bind ssl vserver cs_EXCH_RDS-SSL -certkeyName <NAME DES IMPORTIERTEN ZERTIFIKATES>

Damit wären wir in der Theorie auch schon fertig. An der Firewall müssten jetzt noch die Ports tcp 80, tcp 443 sowie udp 3391 auf die <IP ADRESSE DES CONTENT SWITCH VSERVERS> genatted werden. Falls es jemanden aufgefallen ist: Ich erstelle ein neues httpProfile und aktiviere dort webSocket. Warum? Ohne aktivierte Web Sockets im http Profil lässt sich von einem „normalen“ Client über die mstsc.exe oder auch über RDWeb problemlos eine Verbindung herstellen. Sollte es Macs oder Clients mit der Microsoft Remotedesktop App geben, so wird man feststellen, dass eine Verbindung über die „modernen“ Clients (Windows 10 mit o.g. App, macOS, iPhone, iPad) nicht zustande kommt, da diese über eine Web Socket Verbindung gehen.

1. Juli 2018

RDS Connection Broker auf dedizierten Server umziehen

Filed under: Remotedesktopdienste,Windows Server — Schlagwörter: , , , — Jan Mischo @ 10:20

Umzug eines Connection Broker Servers auf einen eigenständigen Server

Die DATEV sieht in ihrer technischen Fachschrift „Windows Terminalserver in eine Windows-Domäne integrieren“ glücklicherweise zwei Remotedesktopsessionhosts vor. Leider wird in dieser Installationsanleitung einer der Session Hosts ebenfalls zum Connection Broker sowie zum Web Access für Remote Desktop installiert. Aufgrund dieser unglücklichen Konstellation kommt es immer wieder vor, dass diese beiden Rollen auf einen neuen, dedizierten Server umgezogen werden müssen sollten.

Ein erfreulicheres Szenario, welches die Uminstallation des Conection Broker auf einen eigenen Server mit sich bringt, ist das immer wieder unerwartete Wachstum bei unseren Kunden. 🙂

Folgendes Szenario hat sich als kurz & schmerzlos herausgestellt:

  1. Neuen virtuellen Server installieren (z.B. CBSRV) und Remote Desktop Connection Broker Rolle hinzufügen
  2. Benutzer am zweiten Session Host zur Abmeldung „bewegen“
  3. Den zweiten Session Host, der nur die RDSH Rolle hat, aus der derzeitigen Sammmlung entfernen
  4. Benutzer ggfs. wieder am verbleibenden Server anmelden lassen
  5. Am Connection Broker den entfernten RDSH zum Server Manager hinzufügen
  6. Neue Sammlung (z.B. RDS) am CBSRV erstellen, entsprechend der alten Sammlung konfigurieren, und den freien Remotedesktopsessionhost hinzufügen
  7. Test der neu erstellten RDS-Sammlung
  8. Neue RDP Verbindungsdatei erstellen und per GPO (z.B. in diesem Beitrag ab „Um die guten Schuhe zu schon…“ beschrieben) oder Anmeldescript auf die Desktops der User kopieren
    Computer: FQDN des Connection Broker (z.B. cbsrv.domain.local)
    RDP Datei mit Notepad öffnen
    – Zeile „use redirection server name:i:0″ auf 1 ändner ->“use redirection server name:i:1“
    – Zeile „loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.<Name der Sammlung>“ hinzufügen -> „loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.RDS“

    RDP Datei für Connection Broker

    RDP Datei für Connection Broker

     

  9. User über neue RDP Verknüpfung mit neuer Sammlung verbinden lassen
  10. Denn verbleibenden Terminalserver aus der alten Sammlung entfernen
  11. Alle Rollen außer Remote Desktop Session Host deinstallieren
  12. Server im Server Manager des CBSRVs hinzufügen
  13. RDSH in neue Sammlung „RDS“ am neuen Connection Broker hinzufügen
  14. Fertig. Spätestens am nächsten Tag sollten die Sitzungen der Benutzer entsprechend auf beide Hosts gebrokered werden

 

 

 

6. Dezember 2017

Citrix Optimizer für VDI RDS Umgebungen

Filed under: Citrix,PowerShell,Remotedesktopdienste,Windows Server,XenApp — Schlagwörter: , , , , , — Jan Mischo @ 10:28

Citrix XenApp / XenDesktop bzw. Windows basierte VDI (Desktops) und RDS (Server) Umgebungen mit dem Citrix Optimizer optimal betreiben.

Mit dem Citrix Optimizer stellt Citrix ein kleines Tool bereit, mit dem diverse in VDI / RDS Umgebungen nicht benötigte Dienste, unnötige Komponenten, Aufgaben und „Verschiedenes“ mit wenigen Klicks bzw. per PowerShell abgeschaltet werden können. Herunterladen kann man den Citrix Optimizer unter https://support.citrix.com/article/CTX224676. Dort gibt es ebenfalls eine kleine englischsprachige sowie bebilderte Anleitung.

Generell ist der Citrix Optimizer ziemlich selbsterklärend und einfach mit einer uberschaubaren GUI.

Citrix Optimizer GUI

Citrix Optimizer GUI

 

 

 

 

 

 

 

Citrix Optimizer Server 2012R2

Citrix Optimizer Server 2012R2

 

 

 

 

 

 

 

Citrix Optimizer Ergebnis

Citrix Optimizer Ergebnis

 

 

 

 

 

 

 

Über den kleinen „View results“ Link bekommt man einen netten HTLM Bericht des Citrix Optimizers über den aktuellen Zustand (Beispiel Report: View results). Nach einem Klick auf „Done“ kann man dann auch sofort mit der Optimierung beginnen.

Citrix Optimizer Optimierung

Citrix Optimizer Optimierung

 

 

 

 

 

 

 

Nachdem der Citrix Optimizer alle ausgewählten Optimierungen durchgeführt hat, kann man sich erneut einen entsprechenden Report ansehen (Beispiel Report II: View results). Nach einem Klick auf „Done“ gelangt man zurück ins Template, welches im ersten Schritt ausgewählt wurde. Ebenso könnte man das soeben evtl. angepasste Template als eigenes Template abspeichern.

Möchte man den Citrix Optimizer automatisieren oder im Roll-Out-Prozess einsetzen, muss man auf das von Citrix freundlicherweise mitgelieferte PowerShell Script samt Modulen zurückgreifen. Für einen ersten Überblick helfen folgende Befehle.

Get-Help .\CtxOptimizerEngine.ps1 -Examples
Get-Help .\CtxOptimizerEngine.ps1 -Detailed
Get-Help .\CtxOptimizerEngine.ps1 -Full

Damit ich meinen Testserver erneut optimieren kann, nutze ich das Rollback-Feature, welches es derzeit ausschließlich für die PowerShell gibt. Dazu lässt sich auch praktischerweise das nach der GUI-Nutzung erzeugte XML File nutzen:

.\CtxOptimizerEngine.ps1 -Source .\Logs\2017-12-06_09-53-36\Execute_History.xml -Mode Rollback
Citrix Optimizer Rollback

Citrix Optimizer Rollback

 

 

 

 

 

 

 

 

 

Danach kann komplett frisch durchgestartet werden. Eine Analyse der Umgebung sowie ein späteres Ausführen wird mit den folgenden PowerShell Zeilen realisiert.

.\CtxOptimizerEngine.ps1 -Source .\Templates\Citrix_WindowsServer2012R2.xml -Mode Analyze
.\CtxOptimizerEngine.ps1 -Source .\Templates\Citrix_WindowsServer2012R2.xml -Mode Execute
Citrix Optimizer Analyze PowerShell

Citrix Optimizer Analyze PowerShell

 

 

 

 

 

 

 

 

 

Citrix Optimizer Optimierung PowerShell

Citrix Optimizer Optimierung PowerShell

 

 

 

 

 

 

 

 

 

Die entsprechenden Reports der Analyse sowie der Ausführung werden ebenfalls bei Nutzung der PowerShell automatisch erzeugt. Nach dem Ausführen der Optimierung empfiehlt es sich den Server einmal kurz durchzubooten.

Older Posts »

Powered by WordPress