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

Citrix Fehler: Seamless-Fehler beim Starten einer Anwendung beheben

Neulich hatte ich folgendes Problem beim Starten einer Anwendung in einer Citrix XenApp-Umgebung.

“Sie haben Windows Explorer in Ihrem ICA-Seamless-Sitzungsfenster gestartet.
Dadurch wird Ihr lokaler Explorer-Desktop verborgen.

Melden Sie sich ab und starten Sie die Remoteanwnedung im Seamless-Modus neu, um ICA-Seamless-Verbindung wieder zu aktivieren.”

Citrix: Seamless Fehler beim Starten einer Anwendung

Der Benutzer war gerade frisch angelegt, eine Ursache war auf den ersten Blick nicht ersichtlich.

Eine zu dem Fehler vorgeschlagene Lösung brachte allerdings keinen Erfolg (wird auch im CTX112134 dokumentiert.

Schließlich stellte sich heraus, dass ein Häkchen in den Eigenschaften des AD-Benutzer dafür verantwortlich war, die aber nicht händisch gesetzt worden war:

Unter “Environment” bzw. “Umgebung” war ein Häkchen bei “Start the following program at logon” gesetzt, die beiden Textfelder darunter waren allerdings leer. Nachdem das Häkchen entfernt und der Benutzer aktualisiert war, tauchte der Citrix-Fehler nicht mehr auf.

Ursache: Schuld ist ein falsches Haekchen in den Eigenschaften des AD-Benutzers

MDT 2010: Probleme SQL-Datenbank und versteckten Applikationen

Nachdem ich nun das MDT 2010 weitestgehend so konfiguriert habe, wie ich es mir vorgestellt hatte, möchte ich natürlich auch die Möglichkeit einer anzubindenden SQL-Datenbank nutzen, mit Hilfe derer man z.B. hersteller-/modellbezogen Applikationen und Rollen zuweisen kann.

Problemstellung

Problem während der Konfiguration und den nachfolgenden Tests war allerdings, dass Anwendungen, die unter „Applikationen“ als „versteckt“ markiert waren, während des Deployments nicht installiert wurden.

Nach verschiedenen Ansätzen zum Troubleshooting kam letztendlich dabei raus, dass eben der Parameter „versteckt“ (»Enable this Folder«) die Ursache dafür war.

MDT 2010 - Versteckte Ordner und Applikationen

Warum ich die Ordner versteckt habe? Geplant war, nur einen optionalen Satz an Anwendungen während des Wizards dem Support-Mitarbeiter zur Verfügung zu stellen. Die übrigen Standard- und modellbezogenen Anwendungen sollten nicht sichtbar und voll automatisch installiert werden.

Leider scheint dies ein Bug im MDT 2010 (Update 1) zu sein, einige andere Administratoren berichten vom selben Problem im Web.

Lösung bzw. Workaround

Einziges Workaround ist dafür, entweder alle Anwendungen anzuzeigen oder so genannte „Software Bundles“ zu erstellen und die Anwendungen über „Dependencies“ einzubinden.

So kann ich bei meiner Struktur alle Unterordner, die die tatsächlichen Anwendungen enthalten, verstecken und nur das Software-Bundle sichtbar machen. Auch nicht schön, aber immer noch besser als eine lange Liste von Software + modelbezogene Anwendungen wie WLAN-Assistenten etc. anzeigen zu müssen.

Für jedes Modell lege ich deshalb einen Unterordner an und erstelle ein entsprechendes Software-Bundle, dass ich bei den Modellen in der Datenbank unter “Applikationen” einbinde.

MDT 2010 - Anlegen eines modellbezogenen Software-Bundles

MCITP-Lehrgang: 3/ 3. + 4. Tag

Auch der Kurs 70-646 ist nun schon wieder vorbei. Wie bereits geschrieben, hatten wir uns diese Woche eine Netzstruktur mit verschiedenen Anforderung aufgebaut. Nachdem die ersten zwei Tage ziemlich flott und reibungslos klappten, tauchten gestern die ersten, teilweise zunächst nicht erklärbaren Probleme auf, sodass in den beiden letzten Tagen viel Zeit für Troubleshooting draufging.

Allerdings war dies nicht nur zum Nachteil, schaute man sich verschiedene Einstellungen und Funktionen nochmal viel detaillierter an, um die möglichen Fehlerquellen zu finden.

So stellte sich heraus, dass die Fehlermeldung “In der Endpunktezuordnung sind keine weiteren Endpunkte verfügbar”, die nach der Installation der Remotedesktopdienste auftauchte, mit dem deaktivierten Windows-Firewall-Dienst zusammenhing. Sprich, nicht nur, dass wir die Profile auf “Aus” gestellt hatten, wir hatten den ganzen Dienst deaktiviert und schon funktioniert die Installation nicht mehr sauber.

Auch konnten wir Replikationsprobleme zwischen den DCs feststellen, nachdem wir in einer Gruppenrichtlinie als Authentifizierungsmethoden nur Kerberos 128- und 256-Bit zugelassen hatten. Trotz dem anschließenden Ändern der GPO, dann doch einfach wieder alle Methoden zuzulassen führte nicht zum Erfolg. Abhilfe schuf dann der KB977321, in dem wir den entsprechenden Registry-Key auf jedem DC von Hand resetet haben.