19.4 Installation von Anwendungen
Die Installation von Anwendungen ist die eigentliche Herausforderung bei der Einführung der Remotedesktopdienste. Wenn Sie daran denken, dass es auf dem Desktop durchaus schon kompliziert werden kann, zwei Anwendungen zur Koexistenz zu bewegen, können Sie sich vorstellen, wie viele Schwierigkeiten es gibt, wenn jede Anwendung nicht nur einmal, sondern 30 Mal läuft.
Es ist festzustellen, dass es Anwendungen geben wird, die einfach nicht auf einem Remotedesktop-Sitzungshost laufen können und werden. Wenn eine Applikation unbedingt eine temporäre Datei namens c:\temp\mytemp.dat benutzen möchte, wird es kompliziert, wenn sie 30 Mal läuft und alle Instanzen versuchen, genau diese Datei zu öffnen bzw. anzulegen.
Es gibt unglaublich schlecht gemachte Anwendungen, die sich zwar installieren und starten lassen, aber trotzdem einfach nicht geeignet sind. Ich möchte Ihnen ein besonders krasses Beispiel nennen, das ich in der Tat kürzlich so gesehen habe: Anwendungen verbringen den größten Teil ihrer Zeit mit Warten. Meistens warten sie auf Benutzereingaben, manchmal aber auch auf das Ende von externen Anwendungen oder dergleichen. Die Kunst beim Warten ist, dass die Anwendung keine oder nur minimale Prozessorzeit konsumiert – einleuchtend. In dem besagten Fall rief eine Anwendung eine externe Kommandozeilenapplikation auf, die Daten übertragen sollte. War dieser Vorgang abgeschlossen, sollte der Benutzer benachrichtigt werden. Da der Programmierer die Kommunikation mit der externen Anwendung nicht geschickter realisieren konnte, prüfte er (bzw. seine Applikation) immer wieder nach, ob ein neues Logfile existierte. Weil er nun merkte, dass es nicht optimal war, 100 Mal pro Sekunde das Filesystem abzufragen, baute er eine Routine, die zwischen diesen Abfragen die Zahlen von 1 bis 10.000 addierte. Damit war der Computer jeweils eine Weile beschäftigt – und nach so einer Summation schaute die Anwendung einfach nach, ob mittlerweile ein neues Logfile da war.
Es ist offensichtlich, dass diese Rechnerei den Computer belastet – schließlich tut er ja etwas. Auf einem Einzelplatz-PC ist es in der Tat zu vernachlässigen, ob während des Wartens eine Prozessorauslastung von 40 % auftritt. Es ist sogar egal (oder zumindest »nicht problematisch«), wenn das dreimal pro Minute passiert. Auf einem Remotedesktop-Sitzungshost sieht die Welt aber schon anders aus. Eine solche Anwendung wird, wenn sie von hinreichend vielen Benutzern gleichzeitig ausgeführt ist, fast zur Unbenutzbarkeit des Systems führen.
Der langen Rede kurzer Sinn ist, dass Sie vor dem Installieren einer Anwendung sorgfältig testen müssen:
- Läuft diese Anwendung gemeinsam mit anderen schon installierten Applikationen? (Ein beliebtes Problem ist die DLL-Hölle.)
- Wie ist das Performanceverhalten bzw. der Leistungsbedarf der Anwendung? Um das herauszufinden, hilft nur eine Pilotierung mit »echten« Benutzern und detaillierter Arbeit mit dem Systemmonitor.
- Kann diese Anwendung überhaupt auf einem Remotedesktop-Sitzungshost ausgeführt werden? Einige Applikationen verhindern dies; OEM- und Retailversionen von Office 2013 weigern sich, auf einem Remotedesktop-Sitzungshost ausgeführt zu werden (Abbildung 19.36).
Auch wenn Sie sorgfältig pilotiert und getestet haben (natürlich nicht auf dem produktiven System), sind bei der Installation auf Remotedesktop-Sitzungshosts »erhöhte Sicherheitsvorkehrungen« zu treffen. Wichtig ist, dass Sie jederzeit wieder zum Ursprungszustand zurück können. Einige Möglichkeiten sind:
- Erstellen eines Image-Backups vor Beginn der Installation. Fertigen Sie Offline-Images an! Ich würde nicht empfehlen, auf einem Remotedesktop-Sitzungshost die Erweiterungen zur Erstellung von Online-Images zu installieren (persönliche Meinung).
- Der Systembereich (C-Platte) sollte auf einem RAID-1-Verbund liegen. Damit ist es möglich, vor Beginn der Installationstätigkeiten eine Platte des Spiegels herauszuziehen und zur Seite zu legen. Misslingt die Installation, können Sie von dem gesicherten Spiegel starten und sind schnell wieder auf dem Ursprungszustand.
Abbildung 19.36 OEM- und Retailversionen von Office 2013 laufen nicht auf dem Remotedesktop-Sitzungshost. Nur Versionen aus den Volumenlizenzprogrammen können eingesetzt werden.
Zu der zweiten Variante sind allerdings einige Anmerkungen zu machen:
- Ist eine Platte gezogen, läuft das System nicht mehr redundant – einleuchtend. Hier könnte man Abhilfe schaffen, indem eine dritte Platte ins Spiel kommt, die stattdessen eingesteckt wird. Bedenken Sie, dass das Erzeugen der Spiegelung einige Zeit dauern wird.
- Wenn Sie mit den Platten aus dem RAID-1-Verbund hantieren, sollten Sie sehr genau wissen, was Sie tun. Ich würde mir für solche Arbeiten ein zweites Augenpaar (eine fachkundige Kollegin oder einen versierten Kollegen) hinzuholen und vor Ausführung jedes Schritts kurz das Vorgehen besprechen. Durch eine kleine Unachtsamkeit haben Sie sonst am Ende leere Platten.
- Sie sollten über eine aktuelle »normale« Datensicherung verfügen.
- Sie sollten darauf achten, die Platten nur im heruntergefahrenen Zustand zu wechseln. Zum einen geht es um Datenkonsistenz, zum anderen könnte es sein, dass Garantiebestimmungen verbieten, dass Platten im laufenden Betrieb gezogen werden.
Wenn Sie alle Sicherungsmaßnahmen getroffen haben und sich sicher sein können, dass Sie auf jeden Fall schnell und problemlos den Ursprungszustand wiederherstellen können, ist es an der Zeit, mit der Installation zu beginnen.
Auf Remotedesktop-Sitzungshosts können Sie nicht »einfach so« das Setup-Programm laufen lassen. Vielmehr muss das System in den Installationsmodus versetzt werden. Dies geschieht auf der Kommandozeile. Es stehen folgende Aufrufe zur Verfügung (Abbildung 19.37):
- change user /install: Dieser Aufruf aktiviert den Installationsmodus.
- change user /execute: So wird der Ausführungsmodus aktiviert.
- change user /query: Wenn Sie sich nicht sicher sind, in welchem Modus Sie (bzw. der Remotedesktop-Sitzungshost) sich momentan befinden, können Sie den aktuellen Zustand abfragen.
Abbildung 19.37 Mit dem Kommando »change user« kann der Remotedesktop-Sitzungshost in den Installations- oder Ausführungsmodus versetzt werden.
Genauer gesagt, beginnt jede Installation auf dem Remotedesktop-Sitzungshost mit dem Aktivieren des Installationsmodus und endet mit dem Aktivieren des Ausführungsmodus. Die Aufrufe werden jeweils mit einer Textzeile quittiert; das Wechseln der Modi beansprucht keine wahrnehmbare Zeit.
Extrem interessant im Zusammenhang mit den Remotedesktopdiensten ist die Applikationsvirtualisierung. Diese geht zwar über den Fokus dieses Buchs hinaus, trotzdem möchte ich Ihnen einen Besuch bei der URL www.microsoft.com/softgrid unbedingt empfehlen.
Die Technologie wurde früher unter dem Namen Softgrid vertrieben und ist vor einigen Jahren in MicrosoftApplicationVirtualization (App-V) umbenannt worden (die Softgrid-URL funktioniert aber noch und ist leicht zu merken).
Befindet sich der Remotedesktop-Sitzungshost im Installationsmodus, können Sie mit der »normalen« Installationsprozedur beginnen. In Abbildung 19.38 ist die Installation von Office 2013 auf einem Remotedesktop-Sitzungshost zu sehen – wie Sie sehen, sehen Sie nichts, zumindest keinen Unterschied zu einer »normalen« Installation auf einem PC.
Abbildung 19.38 Die Installation einer Applikation, hier Office 2013, verläuft wie gewohnt.
Es ist zwar durchaus denkbar, dass ein Installationsprogramm erkennt, dass es auf einem Remotedesktop-Sitzungshost läuft und diesen von sich aus in den Installationsmodus versetzt. Es kann aber nicht schaden, wenn Sie sich angewöhnen, grundsätzlich manuell den Installationsmodus zu aktivieren und nach der Installation wieder abzuschalten; so kann nichts schiefgehen.
Wird eine Anwendung ohne das Aktivieren des Installationsmodus installiert, kann es passieren, dass während des Betriebs »merkwürdige Effekte« auftreten, sprich, die Software nicht vernünftig läuft.
Ihre Meinung
Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.