XenApp, Chrome 58 und ‚Oh nein! Fehler beim Anzeigen dieser Webseite.‘

Aktuell bin ich dabei, eine vorhandene XenApp-6.5-Umgebung auf XenApp 7.13 zu aktualisieren. Dazu wurde auch der Unterbau aus XenServer und Provisioning Services auf die neuen Versionen 7.1 und 7.13 aktualisiert.

Da die Umstellung auf XenApp 7.13 noch einige Zeit und Tests beanspruchen wird, wurden die vorhandenen XenApp 6.5-Systeme für XenServer 7.1 und PVS 7.13 aktualisiert. Dazu wurden im Master-Image die vorhandenen XenTools und die PVS Target Services deinstalliert und die aktuellen Version installiert. Soweit, so gut, das neue Master-Image läuft fast problemlos auf der neuen Umgebung.

Ein kruder Fehler hatte sich jedoch bei der Aktion eingeschlichen, der Start des veröffentlichten Google Chrome lieferte nur noch das folgende Ergebnis:

Wird die gleiche URL mit dem veröffentlichten Internet Explorer aufgerufen, so funktioniert das problemlos. Auch alle anderen Seiten können aufgerufen werden.

Startet man Chrome auf der lokalen Konsole des Servers (also über das XenCenter), so wird die Startseite vollkommen korrekt angezeigt, auch alle anderen Seiten lassen sich ansurfen (nun ja, bis auf die mit dem Zertifikats-Problem).

Wechselt man nun in eine RDP-Sitzung auf dem gleichen Server mit dem gleichen Benutzer und startet Chrome erneut, kommt wieder die Meldung „Oh nein! …“.

Wenn man in der Konsolensitzung Chrome startet (da funktioniert er ja) können verschiedene Webseiten aufgerufen werden. Wechselt man dann in eine RDP-Sitzung und nimmt die Sitzung mit, kann auch dort weiterhin im Internet gesurft werden. Sobald der Browser geschlossen und wieder geöffnet wird, kommt die Meldung erneut und nix geht mehr.

Besonders verwirrend an der ganzen Aktion ist, das die „alten“ XenApp-Server, die in einem anderen Rechenzentrum noch über PVS 6.1 und XenServer 6.2SP1 bereitgestellt werden, das Verhalten nicht zeigen. Dort läuft Chrome problemlos…

Ursache war schließlich, das sich bei der Aktualisierung des Master-Images wohl unbemerkt das Update auch Chrome 58 eingeschlichen hat. Die vorhandene Version 57 (32 Bit) wurde durch die neue Version 58 (64 Bit) aktualisiert. Die automatische Aktualisierung ist zwar durch ein GPO deaktiviert, allerdings ist das Master-Image nicht im Geltungsbereich dieses GPO.

Die im anderen RZ provisionierten XenApps liefen mit Chrome 57.0.2987.11 (32 Bit), daher auch kein Chrome-Problem. Auf der neueren Plattform läuft Chrome 58.0.3029.110 (64-bit), und diese Version hat das Problem.

Auf der Suche nach einer Lösung bin ich nach langer Suche auf diese Seite gestoßen:

Google Chrome 58 Update Throws Aw Snap Errors for Several Enterprise Users after 64-bit Migration

Dort wurde auf einen Citrix-Artikel (CTX107825) hingewiesen und auf die entsprechende Info im Chromium Bugs (717834).

Die Lösung ist, die folgenden Registry-Keys auf den XenApp-Servern zu setzen:

Key: HKLM\SOFTWARE\Citrix\CtxHook
Key: HKLM\SOFTWARE\Wow6432Node\Citrix\CtxHook
Value Name: ExcludedImageNames
Type: REG_SZ
Value: chrome.exe

Daraus lässt sich flugs ein GPO zusammenstecken, mit dem die im Citrix-Artikel genannten Registry-Keys auf die XenApp-Server verteilt werden können:

Sobald das GPO auf den Servern angewendet wird funktioniert auch wieder der Google Chrome.

Ach so: Zusätzlich müssen noch beim Starten von Chrome die folgenden Parameter mit übergeben werden:

--allow-no-sandbox-job

--disable-gpu

damit Chrome dann unter XenApp sauber funktioniert.