Archiv für das Thema: Admin-Alltag

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

Best Practise: Gruppenrichtlinien-Einstellungen (GPO) für Firefox in einer Enterprise-Umgebung

Bereits 2010 hatte ich von der Möglichkeit berichtet, den Firefox in einer Unternehmensumgebung mittels Gruppenrichtlinien zu steuern.

Grundsätzlich gibt es zwei Möglichkeiten, den Firefox mit Gruppenrichtlinien zu steuern:

  1. Man greift auf die damals beschriebene Extension zurück, die nach wie vor verfügbar ist. Allerdings muss diese per Hand (modifizieren der install.rdf innerhalb der xpi-Datei) angepasst werden, um auch noch mit Firefox 9 zu laufen (evtl. folgt eine Anleitung mal bei Gelegenheit)
  2. Man greift auf die Pakete von Frontmotion zurück, die ebenfalls ADM(X)-Dateien zur Steuerung der (Community)-Edition bereitstellen.

Anhand eben dieser Version von Frontmotion möchte ich auf meine Best Practise Einstellungen der Gruppenrichtlinien eingehen. Die meisten (wenn auch nicht alle neueren Einstellungen) bietet auch die Extension GPO for Firefox, teilweise anderes benamst.

Computereinstellungen

Firefox.adm

Im Folgenden meine gesetzten Einstellungen, die im Computer-Kontext allgemeingültig sind (geladen über die Firefox.adm):

  • Disable Firefox Default Browser Check
    Wert: Aktiviert
    Schaltet die “Default Browser”-Überprüfung ab. Diese Entscheidung nehme ich dem Anwender ab, ganz einfach. Besonders auf einem Terminal/Citrix-Server will ich die Meldung überhaupt nicht sehen ;-)
  • Disable XPI-Installs
    Wert: Aktiviert
    Selber Ansatz wie bei der “Default-Browser”-Überprüfung. Nichts ist schlimmer als zig installierte Extensions in einer homogenen Umgebung, sei es auf Clients oder auf Terminal-/Citrix-Servern. Also verbieten.
  • Proxy Settings
    Wert: Aktiviert
    Grundsätzlich wird wahrscheinlich in jeder größeren Umgebung, der Webtraffic über einen Proxy geschickt. Sei es zwecks Filterung bestimmter Seiten oder aufgrund der Caching-Funktionalitäten.
    Je nachdem, wie ihr das Thema bei Euch abdeckt (PAC-Datei, WPAD), gibt es hier verschiedene Einstellungen. Ich greife z.B. alt bewährt auf eine PAC-Datei zurück – und wähle entsprechend “Automatic Proxy Configuration URL”
  • Set Default Location
    Wert: Set Manually (User-Homelaufwerk)
    Eine “Kann”-Option. Ich “schicke” alle Downloads z.B. auf das Home-Laufwerk des Users.

Mozilla.adm

Zusätzliche (tiefergehende Einstellungen) erfolgen per Mozilla.adm.

Während die vorigen Einstellungen dem Admin eine etwas leichter zu konfigurierende (fast schon assistentenartige Einstellungsoberfläche bietet, geht die Mozilla.adm wesentlich tiefer, sie bietet nämlich (fast) alle (?) Einstellungen, die man im Firefox per about:config konfigurieren “könnte”. Warum könnte? Die mittels GPO scharfgeschalteten Einstellungen lassen sich später vom Anwender nicht mehr ändern, da gesperrt (siehe dazu auch der Eintrag bei Mozilla: Locking preferences). Dies gilt übrigens auch für die bereits oben genannten Einstellungen.

Die folgenden Einstellungen sind alle in der Kategorie “Locked Settings” gesetzt

  • Browser > Browser.Feeds.ShowFirstRunUI
    Wert: Deaktiviert
    Zeigt nicht mehr das initiale RSS-Intro an
  • Browser > browser.rights.3.shown
    Browser > browser.rights.version

    Wert: Deaktiviert
    Zeigt nicht den Lizenzvereinbarungsdialog (“Know your rights”) u.ä. beim ersten Start des Firefox an.
  • Browser > browser.shell.checkDefaultBrowser
    Wert: Deaktiviert
    Siehe oben, bewirkt selbiges: Keine Überprüfung auf Standard-Browser
  • lightweightThemes > lightweightThemes.update.enabled
    Wert: Deaktiviert
    Nein, ich will keine aktivierten Update-Funktionalitäten für Anwender :-) In diesem Fall die Lightweight-Themes.
  • services > services.sync.clients.lastSync
    services > services.sync.engine.history
    services > services.sync.engine.prefs   
    services > services.sync.tabs.lastSync

    Werte: Deaktiviert
    Dito, soweit wie möglich auch die Synchronisations-Funktion abschalten, hier gibt es noch weitere Parameter und Einstellungen, die ich gerade teste.
    Eine Möglichkeit, den gesamten Reiter “Sync” auszublenden, habe ich bis dato leider noch nicht gefunden.
  • startup.homepage_override_url
    Wert: Eure festgelegte Startseite
    Diese Einstellung habe ich wieder deaktiviert. Soviel Freiheit darf der Anwender dann doch haben – seine Startseite festzulegen.
    Wenn das bei Euch nicht gewünscht ist, aus welchen Gründen auch immer, ist hier z.B. die Internet- oder Intranet-Adresse Eures Unternehmens einzutragen.
  • startup.homepage_welcome_url
    Wert: Eure festgelegte Startseite

    Mit dieser Einstellung verhält sich etwas anders, als bei startup.homepage_override_ url. Diese zieht nämlich nur einmal, bzw. nach jedem Update/Upgrade, welches ihr vom Firefox einspielt. Damit die Willkommensseite oder auch “What’s new in Firefox X.X” nicht angezeigt zu bekommen, am besten mit der Webadresse Eures Unternehmen überschreiben.

Kommen wir noch zu einigen Spezialfällen, die insgesamt noch nicht so rund laufen, wie ich es mir vorstelle. Üblicherweise prüft Firefox nach der Installation einer neuen Version alle Extensions hinsichtlich Kompatibilität der installierten Addons.

Dies bekommt man als Anwender mittels Wizard präsentiert und kann auswählen, was aktiviert werden soll und was nicht.

So kann es nun aber sein, dass – obwohl bei Euch offensichtlich keine Extensions im Einsatz sind – sich ja z.B. irgendwo noch die Microsoft .NET Framework oder Java-Extension verirrt hat; Die Folge, der Anwender bekommt den Wizard angezeigt, obwohl sonst eigentlich keine Extensions installiert sind.

Oder ihr verteilt zusätzliche Extensions, von denen ihr nicht wollt, dass der Anwender sie deaktivierten könnte. Wie z.B. das GPO for Firefox Addon, wenn ihr das übliche Setup-Paket vom Firefox nutzt und nicht die Community-Edition, in welcher die GPO-Extension schon integriert ist.

Folgende Einstellungen habe ich bereits aktiviert, in nicht allen Fällen klappte es, sodass ich zusätzlich versucht habe, zunächst z.B. sämtliche Leichen der .NET- und Java-Extension zu löschen.

  • extensions > extensions.checkCompatibility
    extensions > extensions.checkCompatibility.7.0b

    Werte: Deaktiviert
    Prüfe nicht hinsichtlich Kompatibilität. Hier ist die ADM allerdings etwas veraltet, der “Versioneintrag” geht nur bis 7.0b
  • extensions.shownSelectionUI
    Werte: Aktiviert
    Deaktiviert den Extensions-Wizard beim erstmaligen Start nach einem Update
  • extensions.ui.locale.hidden Werte: Deaktiviert
    dito, ebenfalls eine Einstellung zum Ausblenden.
  • extensions.update.autoUpdateDefault
    extensions.update.enabled
    extensions.update.notifyUser

    Werte: Deaktiviert
    Diverse Einstellungen zum Deaktivieren von Extensions-Updates.
  • extensions.autoDisableScopes
    Wert: 11
    Damit werden globale Extensions, die unter %ProgramFiles%\Firefox liegen erlaubt, Extensions von irgendwo anders nicht.

Fazit

Zusammengefasst schnürt die Gruppenrichtlinienmethode für mich ein (fast) perfektes Paket, den Firefox zentral steuern zu können. Wenn Mozilla sich nun endlich dazu durchringt, auch im Enterprise-Bereich einen sauberen Support zu bringen, sprich diese Optionen von Haus aus mitkommen und nicht über Drittprodukte (Extension, Frontmotion-Pakete) gelöst werden müsste, wäre diese noch besser und einfacher.

Probiert die Möglichkeiten aus, hoffentlich helfen Sie Euch in Eurer Umgebung. Habt Ihr noch andere Einstellungen, die ich erwähnen bzw. bei mir setzen sollte? Gerne her damit :-)

Weblinks

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