Windows Vista versprach uns mit dem Restart Manager in Kooperation mit Windows Installer eine neue Technologie mit deren Hilfe sich die Reboots am Computer hätten minimieren lassen sollen. Ein grosses Bedürfnis, welches wir in der Softwareverteilung schon lange haben. Leider vergass Microsoft (oder ich habs nicht wirklich gesehen und gehört) beim Rühren in der Werbetrommel, darauf hinzuweisen, dass der Restart Manager nur etwas für User ist, welche interaktiv ein Setup aufrufen. Dass dies in der Softwareverteilung in den allerwenigsten aller Fälle so ist, vergass man schlicht.
Zwar wird von Microsoft ausgewiesen, dass ein sessionübergreifender Shutdown von Applikationen nicht unterstützt wird…
Trotzdem müsste man per Definition programmtechnisch via der Property MsiRestartManagerSessionKey über RmStartSession() ein Session-Handle erhalten, mit welchem man anschliessend über RmGetList() eine abgefüllte Struktur von diesen Applikationen und Services erhalten sollte, die Dateien der aktuellen Installation in-use halten. Leider funktioniert diese Abfrage aufgrund eines Architekturfehlers im Restart Manager für in-use-Daten ausserhalb der eigenen session nicht! Was wirklich schade ist, denn oft laufen Installationsprozesse in der Softwareverteilung in einer anderen session, als die Benutzersession und man hätte auch dort hin und wieder das Bedürfnis, Software auch während Zeiten zu installieren, wo der Benutzer gerade im eingeloggten Zustand am arbeiten ist, also in einer anderen session, als der Installationssession Programme und Prozesse verwendet.
Was es bedeuten kann, Software trotzdem, unter Missachtung allfällig entstehender PendingFileRenameOperations Einträge in der Registry zu installieren, muss ich wohl nicht weiter erklären. In einem einmaligen Prozess kann dies sehrwohl gut gehen, folgen aber in der Folge durch Softwareaktualisierungsprozesse weitere Upgrades oder Löschaktionen von Dateien, die schon in den PendingFileRenameOperations markiert sind, wird es dann richtig übel. Effekte, wie der, dass nach einem Reboot plötzlich Daten einer Anwendung fehlen oder in einer falschen Version vorliegen wären die Folge.
Programmtechnisch könnte uns schon eine systemweit korrekt ausgewiesene Liste mit RmGetList() in der Softwareverteilung viele Probleme lösen. Denn erhielte man über eine entsprechend programmierte Windows Installer CustomAction mit Hilfe von RmGetList() eine vollständige Liste aller Applikationen und Services, welche Dateien der Installation in Benützung haben, so könnte man auch wieder angemessen darauf reagieren. Dies müsste ja nicht einmal bedeuten, dass man mit RmShutDown() einen Restart der Applikation oder des Services beabsichtigt, welche entsprechende zu installierende Dateien geöffnet hat. Nein, es könnte schlicht auch bedeuten, dass man eine weitere Installation mit Fehlerausweisung in der Logdatei abbricht und diese später neu absetzt.
Unterdessen bleibt unsereins nur auf eine allfällige Änderung des Verhaltens zu warten. Gem. Aussagen Microsofts liegt diesbezüglich auch ein Design Change Request vor. Realistischerweise sollten wir aber erst mit Windows Installers 4.5 und Vista SP1 mit einer entsprechenden Änderung rechnen.
Bis dahin müssen wir uns mit Alternativen begnügen. Eine davon ist die Verwendung der mit Windows Installer 4.0 eingeführten Property MsiSystemRebootPending. Wird diese in den LaunchConditions geprüft, so wird die Installation nicht fortgesetzt, wenn sich bereits PendingFilesOperations-Einträge in der Registry befinden. Ich muss zugeben, dass sich durch dieses Verfahren der Prozentsatz an Installationen reduziert, die bereits beim ersten Verteilprozess erfolgreich installiert werden können. Dafür hat man dadurch wenigstens einigermassen Gewähr, dass eine in der Logdatei als erfolgreich ausgewiesene Installation auch nach dem nächsten Reboot noch erfolgreich installiert ist.
