XenDesktop 7.6
Citrix Receiver richtig deinstallieren
27/09/16 21:54
Bei dem Versuch, die neueste Version des Citrix Receiver zu installieren, erhalten Administratoren manchmal die folgende Fehlermeldung: "Setup cannot continue because this version of Receiver is incompatible with a previously-installed version". Dies liegt meist daran, dass die Registry nicht vollständig von alten Versionseinträgen befreit wurde. Mit einem Blick auf die Support-Seiten von Citrix und die Nutzung eines speziellen Registry-Reinigers lässt sich dieses Problem jedoch leicht aus der Welt schaffen.
Filtern Sie zunächst mit dem Windows-Tool Process Monitor nach der Datei trolleyexpress.exe. Sie werden feststellen, dass die ursprüngliche Version des Citrix Receiver zwar entfernt ist, aber in der Registry noch einige fehlerhafte Einträge vorhanden sind. Diese sorgen dafür, dass der Installationsprozess wie beschrieben abgebrochen wird. Im Web bietet Citrix zu diesem Zweck ein spezielles Receiver Clean-Up Utility-Programm an, mit dem sich vorherige Installationen vollständig entfernen lassen.
Anbei der Link: http://support.citrix.com/article/CTX137494
Filtern Sie zunächst mit dem Windows-Tool Process Monitor nach der Datei trolleyexpress.exe. Sie werden feststellen, dass die ursprüngliche Version des Citrix Receiver zwar entfernt ist, aber in der Registry noch einige fehlerhafte Einträge vorhanden sind. Diese sorgen dafür, dass der Installationsprozess wie beschrieben abgebrochen wird. Im Web bietet Citrix zu diesem Zweck ein spezielles Receiver Clean-Up Utility-Programm an, mit dem sich vorherige Installationen vollständig entfernen lassen.
Anbei der Link: http://support.citrix.com/article/CTX137494
vmxnet3 Benennt die NIC in # 2
26/08/16 21:18
XenDesktop-Umgebung auf WMware vSphere virtualisieren, gibt es zum Teil Probleme, dass es im Geräte-Manager mehrere Netzwerkadapter generiert, wie auf dem Bild unten zu sehen ist. Meistens ergänzt mit dem Namen „# 2“
Um dieses Problem zu beheben muss der Microsoft Patch
„Windows6.1-KB2550978-x64.msu“ installiert werden.
Danach tippen Sie in einer cmd Konsole die folgenden Befehle ein:
set devmgr_show_details=1
set devmgr_show_nonpresent_devices=1
start devmgmt.msc
Der Geräte-Manager wird gestartet. Dann klicken Sie im Menü auf Ansicht und wählen „Ausgeblendete Geräte anzeigen“
Löschen Sie alle Netzwerkadapter und starten Sie das Client-Image neu.
Beim Klonen der VMs sollte danach nur noch ein Netzwerkadapter ohne „# 2“ im Geräte-Manager zu sehen sein.
Um dieses Problem zu beheben muss der Microsoft Patch
„Windows6.1-KB2550978-x64.msu“ installiert werden.
Danach tippen Sie in einer cmd Konsole die folgenden Befehle ein:
set devmgr_show_details=1
set devmgr_show_nonpresent_devices=1
start devmgmt.msc
Der Geräte-Manager wird gestartet. Dann klicken Sie im Menü auf Ansicht und wählen „Ausgeblendete Geräte anzeigen“
Löschen Sie alle Netzwerkadapter und starten Sie das Client-Image neu.
Beim Klonen der VMs sollte danach nur noch ein Netzwerkadapter ohne „# 2“ im Geräte-Manager zu sehen sein.
Explorer.exe als Publish Application schliesst sich nach dem Starten
01/03/16 21:40
Windows Explorer als Publish Application schliesst sich sofort nach dem Starten. Um dieses Problem zu beheben, muss folgender Registry-Key erstellt werden.
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Citrix\wfshell\TWI]
„LogoffCheckerStartupDelayInSeconds”=dword:00000010
Citrix hat einen Artikel darüber veröffentlicht „CTX138069“
http://support.citrix.com/article/CTX138069
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Citrix\wfshell\TWI]
„LogoffCheckerStartupDelayInSeconds”=dword:00000010
Citrix hat einen Artikel darüber veröffentlicht „CTX138069“
http://support.citrix.com/article/CTX138069
Zugriff auf Citrix Policies nicht mehr möglich
09/12/15 20:10
Vor kurzem hatte ich im XenDesktop plötzlich kein Zugriff mehr auf die Policies.
Der Fehler war:
Das Problem kam, als unserer XenDesktop Datenbank-Server neu gestartet worden ist. Als Workaround half mir dieser Citrix Artikel: http://support.citrix.com/article/CTX138509
Ich habe in der Citrix Studio Konsole die folgenden PowerShell Befehle ausgeführt:
Add-PSSnapin Citrix.Common.GroupPolicy
New-PSDrive Site –PSProvider CitrixGroupPolicy –Root \ -Controller localhost
cd Site:\User
ren "User Profile Desktop" User-Profile-Desktop
Anscheinend hat alles mit dem Zusammenführen des Clients und Computer Settings zu tun. Im Artikel wird eigentlich beschrieben, dass man nur die Policy, die Probleme macht per PowerShell umbenennen muss, was ich auch tat. Nur bei mir war die Policy nicht unbenannt, sondern es waren zwei Policies vorhanden, die alte und eine neue. Die neue Policy hatte aber nicht alle Einstellungen. Das Ganze war eigentlich verwirrend. Schlussendlich schaute ich, dass alle Einstellungen, die ich benötigte, auf einer der Policies wieder vorhanden waren und löschte die andere Policy.
Ich habe danach noch einen Case bei der Citrix eröffnet. Sie fanden aber keine Ursache dafür und fragten, ob ich es reproduzieren könnte. Auf dem Test-System war es nicht reproduzierbar und da ich nicht unbedingt auf dem Produktiv System basteln wollte, sagte ich nein.
Vielleicht war es Zufall, vielleicht auch etwas Anderes, das ich nicht gerade weiss. Aber für den Fall, dass es nochmal passiert, habe ich einen Workaround, der funktioniert hat.
Der Fehler war:
Das Problem kam, als unserer XenDesktop Datenbank-Server neu gestartet worden ist. Als Workaround half mir dieser Citrix Artikel: http://support.citrix.com/article/CTX138509
Ich habe in der Citrix Studio Konsole die folgenden PowerShell Befehle ausgeführt:
Add-PSSnapin Citrix.Common.GroupPolicy
New-PSDrive Site –PSProvider CitrixGroupPolicy –Root \ -Controller localhost
cd Site:\User
ren "User Profile Desktop" User-Profile-Desktop
Anscheinend hat alles mit dem Zusammenführen des Clients und Computer Settings zu tun. Im Artikel wird eigentlich beschrieben, dass man nur die Policy, die Probleme macht per PowerShell umbenennen muss, was ich auch tat. Nur bei mir war die Policy nicht unbenannt, sondern es waren zwei Policies vorhanden, die alte und eine neue. Die neue Policy hatte aber nicht alle Einstellungen. Das Ganze war eigentlich verwirrend. Schlussendlich schaute ich, dass alle Einstellungen, die ich benötigte, auf einer der Policies wieder vorhanden waren und löschte die andere Policy.
Ich habe danach noch einen Case bei der Citrix eröffnet. Sie fanden aber keine Ursache dafür und fragten, ob ich es reproduzieren könnte. Auf dem Test-System war es nicht reproduzierbar und da ich nicht unbedingt auf dem Produktiv System basteln wollte, sagte ich nein.
Vielleicht war es Zufall, vielleicht auch etwas Anderes, das ich nicht gerade weiss. Aber für den Fall, dass es nochmal passiert, habe ich einen Workaround, der funktioniert hat.
Videos können im Internet Explorer nicht abgespielt werden
16/09/15 23:30
Vor kurzem hatte ich mal wieder das Bedürfnis, mich mit dem Abspielen von Videos im Internet Explorer zu beschäftigen. Als wir ein E-Learning Awareness Training für die Benutzer auf einem Web-Server aufschalteten, hatten wir das Problem, dass die Videos nicht abgespielt werden konnten. Der Fehler hiess: „Das Video konnte nicht decodiert werden“
Zuerst installierte ich diverse Codecs, aber ohne Erfolg. Dann, um zu erfahren, ob das Problem vom Citrix kam, deinstallierte ich den VDA-Agent und plötzlich konnte ich die Videos im Internet Explorer abspielen. Für mich war klar, dass es nicht an meiner Windows 7 Installation lag, sondern etwas mit Citrix zu tun hatte.
Da fing ich mit den Citrix-Richtlinien an zu spielen, wie. z.B. „Flash Redirection“ etc. Aber es war auch damit kein Erfolg zu sehen. Was mich eigentlich noch stresste, war, dass die Videos mit dem Firefox und Google Chrom abgespielt werden konnten.
Ich fing dann an, mich mit dem Internet Explorer tiefergehend zu beschäftigen und setze den Tool Process-Monitor für die Analyse ein. Nach einer sehr langen Analyse stiess ich auf den Registry-Key: [HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main]
UseSWRender"=dword:00000000
Dieser Key steuert das „Softwarerendering anstelle von GPU-Rendering verwenden“ im Internet Explorer. Als ich diesen Key aktivierte, war das Problem gelöst.
Damit auch die Benutzer nichts unternehmen müssen, einfach alles per Policy implementieren und schon hat jeder Benutzer nach einer neuen Anmeldung die richtige Einstellung.
Eigentlich etwas Einfaches, aber die Analyse dorthin hat mich knapp 3 Tagen gekostet.
Zuerst installierte ich diverse Codecs, aber ohne Erfolg. Dann, um zu erfahren, ob das Problem vom Citrix kam, deinstallierte ich den VDA-Agent und plötzlich konnte ich die Videos im Internet Explorer abspielen. Für mich war klar, dass es nicht an meiner Windows 7 Installation lag, sondern etwas mit Citrix zu tun hatte.
Da fing ich mit den Citrix-Richtlinien an zu spielen, wie. z.B. „Flash Redirection“ etc. Aber es war auch damit kein Erfolg zu sehen. Was mich eigentlich noch stresste, war, dass die Videos mit dem Firefox und Google Chrom abgespielt werden konnten.
Ich fing dann an, mich mit dem Internet Explorer tiefergehend zu beschäftigen und setze den Tool Process-Monitor für die Analyse ein. Nach einer sehr langen Analyse stiess ich auf den Registry-Key: [HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main]
UseSWRender"=dword:00000000
Dieser Key steuert das „Softwarerendering anstelle von GPU-Rendering verwenden“ im Internet Explorer. Als ich diesen Key aktivierte, war das Problem gelöst.
Damit auch die Benutzer nichts unternehmen müssen, einfach alles per Policy implementieren und schon hat jeder Benutzer nach einer neuen Anmeldung die richtige Einstellung.
Eigentlich etwas Einfaches, aber die Analyse dorthin hat mich knapp 3 Tagen gekostet.
Zusätzliches VLAN zu einer bestehenden Host-Ressource in einer XenDesktop-Umgebung
26/08/15 20:25
Um ein zusätzliches VLAN in einer XenDesktop 7.6 Umgebung zu konfigurieren, kommt man ohne PowerShell nicht weiter. Denn diese Konfiguration kann nicht über eine grafische Oberfläche gemacht werden. Ein zusätzliches Storage dagegen schon, was ich nicht verstehen kann.
Das Ganze hat aber einen Kniff. Als ich die Umgebung aufgebaut habe, hatte ich schon drei VLANs konfiguriert. Der Bedarf, ein zusätzliches VLAN zu konfigurieren, kam später.
Im Internet fand ich sehr schnell die PowerShell-Befehle dazu, aber nachdem ich die Befehle wie beschrieben angewendet hatte, waren plötzlich meine drei bestehenden VLANs weg und ich hatte nur noch das neue VLAN, das ich zusätzlich wollte. Zum Glück war ich auf dem Test-System
Man muss im PowerShell-Befehl die bestehenden und die zusätzlichen VLANs angeben, ansonsten fliegen die bestehenden raus und es bleiben nur die neuen VLANs.
Hier ein Beispiel, Schritt für Schritt:
1. PowerShell als Administrator starten
2. Um die Citrix-Module zu starten tippen Sie „ asnp Citrix*“
3. Damit die Konfiguration angezeigt wird, tippen Sie „dir XDHy:\HostingUnits“
4. Dann tippen Sie den Befehl für das zusätzliches VLAN. Mit einem Komma können Sie mehrere VLANs ergänzen.
Set-Item -Path xdhyp:\hostingunits\VMware -NetworkPath 'XDHyp:\Connections\VMware\SHNET.datacenter\SHNET_XEN.cluster\shnet-vlan806.network', 'XDHyp:\Connections\VMware\SHNET.datacenter\SHNET_XEN.cluster\shnet-vlan807.network', 'XDHyp:\Connections\VMware\SHNET.datacenter\SHNET_XEN.cluster\shnet-vlan810.network', 'XDHyp:\Connections\VMware\SHNET.datacenter\SHNET_XEN.cluster\shnet-vlan870.network'
Und so hatte ich alle VLANs konfiguriert und war glücklich.
Das Ganze hat aber einen Kniff. Als ich die Umgebung aufgebaut habe, hatte ich schon drei VLANs konfiguriert. Der Bedarf, ein zusätzliches VLAN zu konfigurieren, kam später.
Im Internet fand ich sehr schnell die PowerShell-Befehle dazu, aber nachdem ich die Befehle wie beschrieben angewendet hatte, waren plötzlich meine drei bestehenden VLANs weg und ich hatte nur noch das neue VLAN, das ich zusätzlich wollte. Zum Glück war ich auf dem Test-System
Man muss im PowerShell-Befehl die bestehenden und die zusätzlichen VLANs angeben, ansonsten fliegen die bestehenden raus und es bleiben nur die neuen VLANs.
Hier ein Beispiel, Schritt für Schritt:
1. PowerShell als Administrator starten
2. Um die Citrix-Module zu starten tippen Sie „ asnp Citrix*“
3. Damit die Konfiguration angezeigt wird, tippen Sie „dir XDHy:\HostingUnits“
4. Dann tippen Sie den Befehl für das zusätzliches VLAN. Mit einem Komma können Sie mehrere VLANs ergänzen.
Set-Item -Path xdhyp:\hostingunits\VMware -NetworkPath 'XDHyp:\Connections\VMware\SHNET.datacenter\SHNET_XEN.cluster\shnet-vlan806.network', 'XDHyp:\Connections\VMware\SHNET.datacenter\SHNET_XEN.cluster\shnet-vlan807.network', 'XDHyp:\Connections\VMware\SHNET.datacenter\SHNET_XEN.cluster\shnet-vlan810.network', 'XDHyp:\Connections\VMware\SHNET.datacenter\SHNET_XEN.cluster\shnet-vlan870.network'
Und so hatte ich alle VLANs konfiguriert und war glücklich.
XenDekstop 7.6 Schwarzer Bildschirm beim Starten mit zwei Monitoren
23/06/15 22:28
In der letzten Woche war ich mit einem seltsamen schwarzen Bildschirmproblem in einer XenDesktop 7.6-Umgebung beschäftigt. Ein Rollout für eine Abteilung war gerade am Laufen und ich konnte nicht verstehen, wieso das Problem während der Testphase nicht aufgetreten war.
Bei der ersten Untersuchung stellte ich fest, dass das Problem erst auftritt, wenn die Umgebung unter Belastung ist.
Als zweites suchte ich die Problematik an unseren ThinClients „IGEL“. Aber als ich feststellte, dass, egal aus welchem Gerät ich startete, es reproduzierbar war, musste ich die ThinClients ausschliessen.
Als drittes fing ich die Problematik am Receiver zu suchen und testete die Versionen 4.0, 4.1 und 4.2, leider ohne Erfolg.
Jetzt konnte es für mich nur noch an dem XenDesktop-Image liegen. Ouu, ich habe unsere Umgebung noch gar nicht vorgestellt
Unsere XenDesktop 7.6-Umgebung läuft auf VMware 5.5
Jetzt war Zeit für eine intensive Fehlersuche.
Zuerst aktivierte ich den „Legacy-Grafikmodus“ in der Test-Umgebung
Und deaktivierte „Desktop Composition Redirection“
Ich änderte die folgenden Registrierungseinträge, um sicherzustellen, dass es kein Problem mit dem MFAPHOOK war.
Path: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows
Name: AppInit_DLLs New Value: MFAPHOOK64.DLL
Path: HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Windows Name: AppInit_DLLs New Value: MFAPHOOK.DLL
Wie Sie in den folgenden Screenshots sehen, enthält der Wert immer den vollständigen Pfad:
Vorher:
Nachher:
Vorher:
Nachher:
Der nächste Schritt war, einige Grafiktreiber Registry-Einstellungen zu ändern. Ich benannte die folgenden Schlüssel in .old um und machte einen Neustart an der VM.
HKLM\SYSTEM\CurrentControlSet\GraphicsDrivers\Configuration
HKLM\SYSTEM\CurrentControlSet\GraphicsDrivers\Connectivity
Nach dem Neustart waren die Schlüssel zwar neu erstellt, aber unterschieden sich von den ursprünglichen.
Für mich war das ganz klar ein Indiz für den Grafiktreiber. Aber für welchen? Da der VMware SVGA-Treiber für XenDesktop nicht benötigt wird, deinstallierte ich diesen.
Für den Citrix-VM Zugriff ist ein Citrix-Treiber vorhanden, der mit dem VDA-Agent installiert wird.
Nach intensiven Tests bekam ich den schwarzen Bildschirm nicht mehr. Ich setzte die Lösung in der Produktiv-Umgebung und wartete auf die Rückmeldung der Benutzer.
Nach zwei Tagen war ganz klar, der schwarze Bildschirm kommt nicht mehr.
Zum Schluss deaktivierte ich den „Legacy-Grafikmodus“ und aktivierte „Desktop Composition Redirection“ wieder
Bei der ersten Untersuchung stellte ich fest, dass das Problem erst auftritt, wenn die Umgebung unter Belastung ist.
Als zweites suchte ich die Problematik an unseren ThinClients „IGEL“. Aber als ich feststellte, dass, egal aus welchem Gerät ich startete, es reproduzierbar war, musste ich die ThinClients ausschliessen.
Als drittes fing ich die Problematik am Receiver zu suchen und testete die Versionen 4.0, 4.1 und 4.2, leider ohne Erfolg.
Jetzt konnte es für mich nur noch an dem XenDesktop-Image liegen. Ouu, ich habe unsere Umgebung noch gar nicht vorgestellt
Unsere XenDesktop 7.6-Umgebung läuft auf VMware 5.5
Jetzt war Zeit für eine intensive Fehlersuche.
Zuerst aktivierte ich den „Legacy-Grafikmodus“ in der Test-Umgebung
Und deaktivierte „Desktop Composition Redirection“
Ich änderte die folgenden Registrierungseinträge, um sicherzustellen, dass es kein Problem mit dem MFAPHOOK war.
Path: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows
Name: AppInit_DLLs New Value: MFAPHOOK64.DLL
Path: HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Windows Name: AppInit_DLLs New Value: MFAPHOOK.DLL
Wie Sie in den folgenden Screenshots sehen, enthält der Wert immer den vollständigen Pfad:
Vorher:
Nachher:
Vorher:
Nachher:
Der nächste Schritt war, einige Grafiktreiber Registry-Einstellungen zu ändern. Ich benannte die folgenden Schlüssel in .old um und machte einen Neustart an der VM.
HKLM\SYSTEM\CurrentControlSet\GraphicsDrivers\Configuration
HKLM\SYSTEM\CurrentControlSet\GraphicsDrivers\Connectivity
Nach dem Neustart waren die Schlüssel zwar neu erstellt, aber unterschieden sich von den ursprünglichen.
Für mich war das ganz klar ein Indiz für den Grafiktreiber. Aber für welchen? Da der VMware SVGA-Treiber für XenDesktop nicht benötigt wird, deinstallierte ich diesen.
Für den Citrix-VM Zugriff ist ein Citrix-Treiber vorhanden, der mit dem VDA-Agent installiert wird.
Nach intensiven Tests bekam ich den schwarzen Bildschirm nicht mehr. Ich setzte die Lösung in der Produktiv-Umgebung und wartete auf die Rückmeldung der Benutzer.
Nach zwei Tagen war ganz klar, der schwarze Bildschirm kommt nicht mehr.
Zum Schluss deaktivierte ich den „Legacy-Grafikmodus“ und aktivierte „Desktop Composition Redirection“ wieder
Fehler beim deinstallieren von Citrix Hotfixes
16/06/15 19:36
Vor zwei Wochen hatte ich ein phänomenales Problem:
Als ich den Hotfix „ICAWS760WX64014“ aus einem VM deinstallieren wollte, bekam ich die Fehlermeldung " Es wurde keine gültige Reihenfolge für die Patches gefunden" Das grösste Problem war, dass ich keine weitere Citrix Hotfixes mehr installieren konnte.
Nach ein paar Versuchungen und da ich ziemlich im Stress war, machte ich einen Case bei der Citrix auf.
Einen Tag später rief schon ein Citrix Technical Supporter an. Eigentlich ein sehr guter Service. Er kam dann Remote auf meinen PC drauf und wir versuchten, wieder ein paar Workarounds, aber ohne Erfolg. Da er keine Idee mehr hatte, verblieben wir so, dass er sich wieder bei mir melden würde.
Zwischendurch machte ich mich wieder auf die Suche nach dem Problem und plötzlich fand ich eine mögliche Lösung. Damit ihr auch versteht, wie ich auf diese gekommen bin, werde ich es Schritt für Schritt angeben.
1. Aktivieren der Windows Installer-Protokollierung, damit ich in der Ereignisanzeige mehr Informationen sehen kann.
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer
Reg_SZ: Logging
Wert: voicewarmupx
2. In der Ereignisanzeige auf Fehler suchen.
3. Der Log Datei „MSI531aa.LOG“ analysieren. Dort fand ich den folgenden Eintrag, der eigentlich nicht viel sagte, aber ich wusste, diese Datei hat etwas mit der Patch Installation zu tun.
4. Nun löschte ich die Datei „20d858.msi“ und schon war das Problem gelöst. Die Deinstallation konnte erfolgreich durchgeführt werden. Auch die neuen Hotfixes konnten problemlos installiert werden.
5. Danach teilte ich Citrix mit, dass ich das Problem gelöst habe und sie den Case schliessen konnten. Sie baten mich, die Lösung, die ich verfolgt habe, zu schicken, was ich auch tat. Ich hoffe, sie werden es publizieren.
Als ich den Hotfix „ICAWS760WX64014“ aus einem VM deinstallieren wollte, bekam ich die Fehlermeldung " Es wurde keine gültige Reihenfolge für die Patches gefunden" Das grösste Problem war, dass ich keine weitere Citrix Hotfixes mehr installieren konnte.
Nach ein paar Versuchungen und da ich ziemlich im Stress war, machte ich einen Case bei der Citrix auf.
Einen Tag später rief schon ein Citrix Technical Supporter an. Eigentlich ein sehr guter Service. Er kam dann Remote auf meinen PC drauf und wir versuchten, wieder ein paar Workarounds, aber ohne Erfolg. Da er keine Idee mehr hatte, verblieben wir so, dass er sich wieder bei mir melden würde.
Zwischendurch machte ich mich wieder auf die Suche nach dem Problem und plötzlich fand ich eine mögliche Lösung. Damit ihr auch versteht, wie ich auf diese gekommen bin, werde ich es Schritt für Schritt angeben.
1. Aktivieren der Windows Installer-Protokollierung, damit ich in der Ereignisanzeige mehr Informationen sehen kann.
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer
Reg_SZ: Logging
Wert: voicewarmupx
2. In der Ereignisanzeige auf Fehler suchen.
3. Der Log Datei „MSI531aa.LOG“ analysieren. Dort fand ich den folgenden Eintrag, der eigentlich nicht viel sagte, aber ich wusste, diese Datei hat etwas mit der Patch Installation zu tun.
4. Nun löschte ich die Datei „20d858.msi“ und schon war das Problem gelöst. Die Deinstallation konnte erfolgreich durchgeführt werden. Auch die neuen Hotfixes konnten problemlos installiert werden.
5. Danach teilte ich Citrix mit, dass ich das Problem gelöst habe und sie den Case schliessen konnten. Sie baten mich, die Lösung, die ich verfolgt habe, zu schicken, was ich auch tat. Ich hoffe, sie werden es publizieren.
Der Bildschirmschoner wird im XenDesktop 7.6 nicht aktiviert
17/04/15 18:00
Der Bildschirmschoner wird im XenDesktop 7x nicht aktiviert
Die Policy, um Bildschirmschoner zu aktivieren hat bei der XenDesktop-Umgebung einfach keine Wirkung gezeigt.
Im Internet fand ich einen Artikel mit einem Bug in der Version XenDesktop 7.1. Da ich mit der Version 7.6 unterwegs bin, dachte ich es betrifft mich nicht. Aber nach langem Suchen stellte ich fest, dass der Bug in der Version 7.6 noch nicht behoben ist.
Lösung: Einfach auf dem Basis Image den folgenden Registry Key setzen:
[HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\Graphics]
"SetDisplayRequiredMode"=dword:00000000
So wie ich es getestet habe, benötigt die Maschine einen Reboot damit es wirksam wird, was zu Konklusion führt, dass den Key auf dem Basis Image gesetzt werden muss, und nicht per Policy gesetzt werden kann.
Die Policy, um Bildschirmschoner zu aktivieren hat bei der XenDesktop-Umgebung einfach keine Wirkung gezeigt.
Im Internet fand ich einen Artikel mit einem Bug in der Version XenDesktop 7.1. Da ich mit der Version 7.6 unterwegs bin, dachte ich es betrifft mich nicht. Aber nach langem Suchen stellte ich fest, dass der Bug in der Version 7.6 noch nicht behoben ist.
Lösung: Einfach auf dem Basis Image den folgenden Registry Key setzen:
[HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\Graphics]
"SetDisplayRequiredMode"=dword:00000000
So wie ich es getestet habe, benötigt die Maschine einen Reboot damit es wirksam wird, was zu Konklusion führt, dass den Key auf dem Basis Image gesetzt werden muss, und nicht per Policy gesetzt werden kann.
Pass-Through unter XenDesktop 7(.1) in Verbindung mit Storefront 2(.1)
14/03/15 19:08
Citrix Receivers 4.1 in Verbindung mit einem Storefront-Store
Wichtigster Punkt vorab: Ein Pass-Through bei Verwendung der Storefront-Website ist stand heute nicht mehr möglich. Citrix stellt zwar in Aussicht, dass dieses Feature in einem kommenden Release wieder zur Verfügung steht, mit den aktuellen Versionen fehlt diese Funktion jedoch.
Vorbereitung:
In diesem Szenario muss der Client die Passthrough-Authentifizierung ermöglichen. Dies geschieht (im Windows-Umfeld) mit der bei der Receiver-Installation mitgelieferten icaclient.adm (zu finden unter C:\Program Files (x86)\Citrix\ICA Client\Configuration)
Folgende Einstellung ist hier zu setzen und dem entsprechenden Client (entweder lokal oder als Domänen-Richtlinie) zuzuweisen:
Citrix Components > Citrix Receiver > User authentication > Local user name and Password
Enable pass-through authentication
Des Weiteren muss die Pass-Through Authentifizierung in Storefront aktiviert werden:
Installation
Download des aktuellen Citrix Receivers über https://receiver.citrix.com
Beispielhafte Installationsparameter der CitrixReceiver.exe – für die Authentifizierung wichtige Komponenten wurden fett markiert:
CitrixReceiver.exe /includeSSON ADDLOCAL="ReceiverInside,ICA_Client,SSON,AM,SELFSERVICE,USB,
DesktopViewer,Flash,Vd3d" ALLOWSAVEPWD="A" ENABLE_SSON=YES STORE0="Storename;http://ddc.fqdn/Citrix/[Storename]/discovery;on;Store Description"
Diese und weitere Befehlszeilenargumente werden in den Citrix eDocs ausführlich erläutert:
http://support.citrix.com/proddocs/topic/receiver-windows-40/receiver-windows-cfg-command-line-40.html
Konfiguration
Damit der Delivery-Controller den durchgeschleiften Anmeldeinformationen des Clients vertraut, muss per Powershell auf dem Controller der Command
Set-BrokerSite -TrustRequestsSentToTheXmlServicePort $True
ausgeführt werden. Weitere Informationen über diese Anpassung:
http://support.citrix.com/article/CTX132461
Besonderheit “http”
Falls die Kommunikation zwischen Client und Delivery-Controller nicht über https erfolgt ist folgender RegKey (am Client) zu setzen:
HKLM\Software\Wow6432Node\Citrix\AuthManager: "ConnectionSecurityMode"="Any"
Ergebnis
COM & LPT Port Mapping XenDesktop 7x
14/03/15 19:03
COM & LPT Port Mapping unter XenDesktop 7x funktioniert nicht, in dem man die passenden Policies konfiguriert hat.
Man muss zusätzlich die Registry bearbeiten
http://support.citrix.com/proddocs/topic/xendesktop-7/cds-policies-rules-deprecated.html
Man muss zusätzlich die Registry bearbeiten
http://support.citrix.com/proddocs/topic/xendesktop-7/cds-policies-rules-deprecated.html
Using the default VMware vCenter server certificate in XenDesktop POCs
14/03/15 19:01
Lange Anmeldezeit und schwarzer Bildschirm
12/03/15 23:26
seit längerer Zeit mal wieder ein Artikel. Erst letzte Woche ist mir mal wieder etwas untergekommen und wer hat nicht auch schon mal damit zu tun gehabt:
Verdammt lange Anmeldezeiten an einer XenApp 6.5 oder XenDesktop 7.x Umgebung.
Dabei ist es egal ob published Desktop oder published Application. Richtig verwirrend wird es dann noch dazu, wenn die Profile der Benutzer unter 15 MB sind und man ja eigentlich davon ausgehen sollte, dass die Anmeldung rucki zucki gehen sollte.
Einen Strich durch die Rechnung machen uns dann meistens irgendwelche Richtlinien, deren Verarbeitung durchaus ein wenig Zeit fressen kann.
Froh kann dann derjenige sein, der noch XenApp 6.5 im Einsatz hat. Der sieht bei der Anmeldung nämlich direkt, an welcher Richtlinie es hapert.
XenDesktop Benutzer allerdings sehen nur schier endlos einen schwarzen Bildschirm. Das gilt übrigens für Server VDAs und genauso für Desktop VDAs.
Um jetzt schauen zu können, welche Richtlinie es ist, muss man zunächst einen kleinen Registry Wert setzen:
Registry Key: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\Logon
Name: DisableStatus
Type: REG_DWORD
Value: 00000001
Dazu gibt es auch einen entsprechenden Artikel von Citrix.
Hat man diesen Wert gesetzt, hat dies zur Folge, dass man den normalen Windows Anmeldebildschirm sehen kann und hier sieht man dann auch sehr schön, welche Richtlinie ärger macht. Dieser Logon Screen kommt dann übrigen auch beim Starten von published Apps. Also nach dem Troubleshooting wieder weg mit dem Regkey.
nun aber weiter:
In meinem Fall war der Übeltäter die Richtlinie "Internet Explorer Branding"
Das Problem ist nur: Man findet darüber ziemlich wenig und wenn dann ist es uralt.
Uralt heißt aber nicht zwingend schlecht und so ergab sich dann die Lösung:
Und das war wieder ein Registry Wert, der auf dem VDA gesetzt werden musste:
Registry Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\\FeatureControl\FEATURE_PARSING_BRANDING_CMDLINE_FLAGS_KB941158
Name: *
Type: REG_DWORD
Value: 00000001
Ich habe diesen Wert via Computerpolicy gesetzt, damit ich das Master Image nicht anpassen musste. (zuviel Aufwand)
Und nach dem Setzen verringerte sich meine Anmeldedauer von 50 Sekunden auf 15.
Damit kann man leben.
Verdammt lange Anmeldezeiten an einer XenApp 6.5 oder XenDesktop 7.x Umgebung.
Dabei ist es egal ob published Desktop oder published Application. Richtig verwirrend wird es dann noch dazu, wenn die Profile der Benutzer unter 15 MB sind und man ja eigentlich davon ausgehen sollte, dass die Anmeldung rucki zucki gehen sollte.
Einen Strich durch die Rechnung machen uns dann meistens irgendwelche Richtlinien, deren Verarbeitung durchaus ein wenig Zeit fressen kann.
Froh kann dann derjenige sein, der noch XenApp 6.5 im Einsatz hat. Der sieht bei der Anmeldung nämlich direkt, an welcher Richtlinie es hapert.
XenDesktop Benutzer allerdings sehen nur schier endlos einen schwarzen Bildschirm. Das gilt übrigens für Server VDAs und genauso für Desktop VDAs.
Um jetzt schauen zu können, welche Richtlinie es ist, muss man zunächst einen kleinen Registry Wert setzen:
Registry Key: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\Logon
Name: DisableStatus
Type: REG_DWORD
Value: 00000001
Dazu gibt es auch einen entsprechenden Artikel von Citrix.
Hat man diesen Wert gesetzt, hat dies zur Folge, dass man den normalen Windows Anmeldebildschirm sehen kann und hier sieht man dann auch sehr schön, welche Richtlinie ärger macht. Dieser Logon Screen kommt dann übrigen auch beim Starten von published Apps. Also nach dem Troubleshooting wieder weg mit dem Regkey.
nun aber weiter:
In meinem Fall war der Übeltäter die Richtlinie "Internet Explorer Branding"
Das Problem ist nur: Man findet darüber ziemlich wenig und wenn dann ist es uralt.
Uralt heißt aber nicht zwingend schlecht und so ergab sich dann die Lösung:
Und das war wieder ein Registry Wert, der auf dem VDA gesetzt werden musste:
Registry Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\\FeatureControl\FEATURE_PARSING_BRANDING_CMDLINE_FLAGS_KB941158
Name: *
Type: REG_DWORD
Value: 00000001
Ich habe diesen Wert via Computerpolicy gesetzt, damit ich das Master Image nicht anpassen musste. (zuviel Aufwand)
Und nach dem Setzen verringerte sich meine Anmeldedauer von 50 Sekunden auf 15.
Damit kann man leben.
Letzter oder einziger XenDesktop Controller defekt! Was nun?
08/03/15 23:38
Aus aktuellem Anlass möchte ich hier nochmal kurz auf einen Blog Artikel hinweisen, der in den Citrix Blogs veröffentlicht worden ist.
Stellt euch vor ihr habt eine XenDesktop Site und der einzige oder letzte Controller geht kaputt. Was nun, wo man doch via GUI und Powershell einen aktiven Controller braucht, um einen neuen Controller hinzuzufügen?
Neuinstallation? Denkbar schlecht aber generell ein Ausweg.
Hier aber der noch bessere weg:
http://blogs.citrix.com/2013/08/20/xd-tipster-manually-joining-a-new-controller-to-an-existing-db-3-simple-steps/
Stellt euch vor ihr habt eine XenDesktop Site und der einzige oder letzte Controller geht kaputt. Was nun, wo man doch via GUI und Powershell einen aktiven Controller braucht, um einen neuen Controller hinzuzufügen?
Neuinstallation? Denkbar schlecht aber generell ein Ausweg.
Hier aber der noch bessere weg:
http://blogs.citrix.com/2013/08/20/xd-tipster-manually-joining-a-new-controller-to-an-existing-db-3-simple-steps/