Citrix XenApp: Wie man den Windows Explorer bei installiertem Internet Explorer 7, 8 oder 9 veröffentlicht

Präambel

Wenn ihr in eurer Citrix XenApp Umgebung den Windows Explorer veröffentlicht habt und Euch dabei unter Umständen (historisch) immer noch an den Knowledge Center Eintrag CTX922603 (2003 veröffentlicht) haltet bzw. gehalten habt, so werdet ihr wahrscheinlich auf einen Fehler stoßen, sobald ihr den Internet Explorer 7 oder 8 installiert habt bzw. ihr einen Windows Server 2008 (RS) – u.U. schon mit dem Internet Explorer 9 – verwendet.

Problem bzw. Fehler beim Starten der Anwendung

Sobald ihr nämlich den Windows Explorer (z.B. über das Webinterface) starten wollt, taucht zusätzlich im Hintergrund ein Fenster vom Internet Explorer, sowie die Fehlermeldung “Das System kann das angegebene Gerät nicht finden” angezeigt.

Fehler beim Starten des veröffentlichten Windows Explorers

Dies liegt daran, dass Citrix damals empfahl, den Windows Explorer über einen Parameter der IEXPLORE.EXE (des Internet Explorers) zu starten, der dann wie folgt aussah:

"%ProgramFiles%\Internet Explorer\IEXPLORE.EXE" -e h:\

Dieser Parameter steht ab der Version 7 nicht mehr zur Verfügung.

Lösung bzw. Workaround

Im Forum von brianmadden.com findet man allerdings den Hinweis, dass der “normale” Aufruf der explorer.exe keine Probleme (mehr) bereiten sollte.

Deswegen lässt sich der Pfad dann wie folgt ändern und führte bei mir ohne Probleme zum Erfolg:

%SystemRoot%\EXPLORER.EXE /n,/e,H:\

Dieser Workaround wird von Citrix auch im CTX112195 beschrieben.

Vielleicht kann mir ein Citrix-Fuchs beantworten, ob ihm dieses Vorgehen im Allgemeinen Bauchschmerzen bereiten oder Sicherheitsbedenken nach sich ziehen würde?

Weiterführende Links

Firefox ESR veröffentlicht

Nachdem nun auch Firefox 10 erschienen ist, hat Mozilla wie angekündigt ebenfalls ein Extended Support Release veröffentlicht, um Unternehmen vom “Updatewahnsinn” der letzten Monate zu entlasten.

Firefox ESR Roadmap

Kommentar am Rande: Gar nicht so schlimm, die vielen Updates; “lieber Firefox 27, ….” meint z.B. ein Kommentator bei Golem, andere Kommentare lesen sich ähnlich.
Hier sei allerdings angemerkt, die Leute denken wahrscheinlich nur in ihrer “Einzelumgebung”: PC zu Hause, neuen Feuerfuchs drauf und fertig. In größeren Umgebung es aber deutlich komplexer und die vielen Updates nerven schon ziemlich. Da muss man schon
manch einen Hebel in Bewegung setzen, um bloß keinem Anwender die Updatehinweise anzeigen zu lassen :-) Außerdem müssen die Versionen immer erst einen Testzyklus durchlaufen und können nicht gleich flächendenkend verteilt werden.

Insgesamt ist das “ganz nett”, wie ich schon vor einigen Wochen geschrieben hatte. Allerdings ist das “ESR” für mich fast schon gar nicht erwähnenswert, denn außer dem längerem Support gibt es nichts interessantes für Unternehmen:

  • Keine “Von-Haus-aus” MSI-Installationsdatei
  • keine integrierte Gruppenrichtlinienfunktionalität
  • keine zentrale Addon-Verwaltung
  • und und und…

Hier gäbe es einiges, was ein richtiges Enterprise-Build ausmachen würde.

Wer eine portable Version des ESR-Builds sucht, schaut mal beim Carsten vorbei, der hat eins gebastelt.

MDT 2012: Monitoring-Funktion

Seit der Beta 2 des Microsoft Deployment Toolkit 2012 lässt sich auch eine Monitoring-Funktion aktivieren, mit welcher ihr Eure derzeit laufenden und abgeschlossenen Installationen im Überblick behalten könnt.

Um die Funktion zu aktivieren müsst ihr in den Eigenschaften Eures DeploymentShares die Option “Enable monitoring for this deployment share” anhaken. Anschließend befindet sich der Eintrag Monitoring in der linken Navigationsleiste.

Aktivieren der Monitoring-Funktion

So bekommt ihr zum Beispiel Informationen über den Status der Installation (Step der Task Sequence, Abgeschlossene Prozent). Weiterhin werden Euch die Anzahl der Fehler sowie Start- und Endzeit der Installation angezeigt.

Bei Bedarf kann man sich sogar direkt per RDP auf den Rechner aufschalten.mdt2012-monitoring

Insgesamt also eine sehr nützliche Funktion.

Adobe Reader Deployment – Ausblenden der Reparieren-Funktion

Standardmäßig bietet der Adobe Reader über das Hilfe-Menü die Menüpunkte “Online-Support” und “Adobe Reader Installation reparieren” an. Während man zig Einstellungen  mittels dem Customization Wizard für ein geeignetes Deployment (auf Clients, Citrix-/Terminalserver etc.) parametrisieren kann, lässt sich der “Reparieren”-Punkt nur mit einem Trick ausblenden.

Adobe Reader: Mit Reparieren- und Online-Support Eintrag im Hilfe-Menü

Und dies ist auf jeden Fall in einer Terminalserver-/Citrix-Umgebung sehr wichtig, denn ansonsten könnte ein unbedachter Anwender den Menüpunkt aufrufen und anschließend den Server neustarten! Grund dafür ist, dass die Reparieren-Funktion per MSI-Installer gestartet wird, welcher im Systemkontext läuft.

Die übrigen Einstellungen im Customization Wizard sind eigentlich selbst erklärend, ein geeignete Anleitung findet ihr aber auch im Blog von Aaron Parker. Im Folgenden möchte ich deshalb nur die notwendigen Schritte zum Ausblenden der Reparieren-Funktion erläutern.

Vorbereitung: Erstellen der HideMenu.js-Datei

Dazu erstellt ihr mittels einem Editor (z.B. Notepad, Notepad++) eine JavaScript-Datei mit folgendem Inhalt:

//HideMenu.js
// [Help - Repair Adobe Reader Installation]
app.hideMenuItem("DetectAndRepair");
// [Help - Online Support]
app.hideMenuItem("OnlineSupport");
// [Help - Online Support - Knowledge Base]
app.hideMenuItem("KnowledgeBase");
// [Help - Online Support - Adobe Support Programs]
app.hideMenuItem("AdobeExpertSupport");
// [Help - Online Support - Adobe User Community]
app.hideMenuItem("AdobeUserCommunity");
// [Help - Online Support - Accessibility Resource Center]
app.hideMenuItem("AccessOnline");
// [Help - Online Support - Generate System Report]
app.hideMenuItem("SystemInformation");

Diese Datei muss anschließend im Installationsordner des Adobe Readers (z.B. C:\Program Files (x86)\Adobe\Reader 10.0) im Unterverzeichnis “Reader\Javascripts” als HideItems.js abgespeichert werden.

Ablegen der HideItems.js

Wie ihr nun Euren Reader startet und ins Hilfe-Menü schaut, werdet ihr sehen dass die Einträge verschwunden sind. Allerdings ist mir aufgefallen, dass dies erst nach einigen Sekunden geschieht. D.h., starte ich den Adobe Reader und klicke sofort ins Hilfe-Menü, sehe ich die Einträge unter Umständen noch für ein paar Sekunden.

Das Hilfe-Menü nach der Anpassung

Klicke ich hingegen erst eine Weile später ins Menü, sind die Einträge weg. Das lässt vermuten, dass die JavaScript-Datei erst nach vollständigem Starten des Readers die interpretiert und abarbeitet, deshalb auch der kurzzeitige Verzug.

Integration ins Setup-Paket

Um die Datei nun entsprechend direkt bei der Verteilung auf Clients oder Terminal-/Citrix-Servern zu integrieren, geht ihr wie folgt vor:

Öffnet im Customization Wizard den Punkt “Files and Folders”. Hier müsst ihr nun im oberen Explorerfenster zu dem Pfad navigieren, wo ihr die HideItems.js abgelegt habt.

Als Nächstes müsst ihr im unteren Explorerfenster den Pfad “Destination Computer > ProgramFilesFolder > Adobe > Reader 10.0 > Reader > Javascripts” öffnen.

Standardmäßiges Deployment der HideItems.js mittels Customization Wizard

In dieses Verzeichnis kopiert ihr die HideItems.js und könnt, sobald ihr alle übrigen Einstellungen vorgenommen habt, das Transform-Script (MST) abspeichern.

Weiterführende Links