Management von Office ProPlus (Office-Paket)

Hits: 139

In einem kleinen Büro stellt sich die Frage vielleicht nicht: wenn einige wenige Arbeitsplätze mit Office ProPlus versorgt werden müssen, dann können die Benutzer sich im Office365-Portal anmelden, den Click2Run-Installer herunterladen und sich die Office-Programme installieren. Eine Lizensierung (eigenständig oder über Pakete wie E3) sowie lokale Administratorrechte vorausgesetzt.

In einem Unternehmen mit mehreren Arbeitsplätzen oder mit bestehender Softwareverteilungs-Lösung wie z.B. SCCM ist das nicht praktikabel. Also muss der Administrator/Software Manager sich darum kümmern, dass das Office-Paket auf die Arbeitsplätze wandert.

Gerade in größeren Umgebungen sollte hierfür vor der Installation ein detaillierter Plan gemacht werden. Denn der „Evergreen“-Ansatz von Microsoft ist zwar zeitgemäß, passt aber nicht in jede Infrastruktur. Mit „Evergreen“-Ansatz ist gemeint, dass die Office-Programme ihre Updates (einschließlich Feature-Updates) direkt aus dem Internet beziehen. Sie gehen also eiskalt am WSUS vorbei. Das ist oft nicht so gewollt, da durch Plugins, selbst programmierte Makros usw. die Applikationslandschaft eigentlich homogen gehalten werden soll und Updates gerne vorher von einer Testgruppe evaluiert werden möchten.

Es gibt also verschiedenste Ansätze, die Office-Applikationen an den Benutzer zu bringen. Um nur einige zu nennen:

Eine Musterlösung dazu gibt es nicht und die Planung richtet sich immer an die Anforderungen der jeweiligen Umgebung. Da der Click2Run-Installer selbsterklärend ist, betrachte ich diese Variante an der Stelle nicht weiter.

Viel interessanter ist die Verteilung für mehrere Installationen. Die Älteren unter Euch werden sich bestimmt noch an Zeiten erinnern, in denen das normale Office-Paket von einer DVD kopiert werden und die Setup.exe mit einem Admin-Paramater gestartet wurde. Dann konnte man über eine grafische Oberfläche Einstellungen festlegen, einen Aktivierungsschlüssel hinterlegen und erhielt anschließend eine benutzerdefinierte Datei, die man im weiteren Prozess der Verteilung verwenden konnte. Diese Zeiten sind mit Office ProPlus endgültig vorbei.

Der Einstiegspunkt in die Anpassung ist das ODT (Office Deployment Toolkit, Link) von Microsoft. Hinter dem Download verbirgt sich lediglich ein Entpacker, der euch zwei Dateien zur Verfügung stellt: eine Setup.exe und eine Configuration.xml. Das war’s.

„Ist ja einfach“ werden jetzt sicherlich viele denken, aber dann geht der Spaß erst richtig los. In der Configuration.xml kann man sich nun mit Parametern austoben ohne Ende. Microsoft liefert dazu eine sehr gute Dokumentation, in der alle wichtigen Parameter genannt werden (Link). Das Wichtigste sollte der Funktionsumfang und die Sprache sein. Denn im ersten Schritt definiert man nicht die Installation, sondern den Download. Dieser wird nach der Anpassung der XML-Datei mit „setup.exe /download configuration.xml“ auf der Kommandozeile gestartet. Nun heißt es warten. Einen Fortschrittsdialog gibt es nicht. Ich empfehle, den Task-Manager zu öffnen und den Netzwerk-Durchsatz zu beobachten. Wenn dieser sich nahe der Null-Linie bewegt und die Setup.exe aus den aktiven Prozessen verschwindet, kann man davon ausgehen, dass der Download abgeschlossen ist. Es gibt allerdings auch keine Fehlermeldung, falls etwas schief gegangen ist. Sollte der Download-Ordner um die 1.4 GB groß sein, kann es weiter gehen.

Der zweite Schritt ist nämlich viel interessanter: nun legen wir über eine weitere XML-Datei (z.B. install.xml) fest, was mit den heruntergeladenen Quellen geschehen soll. Daher macht es durchaus Sinn, dass man im ersten Schritt vielleicht mehr heruntergeladen hat, also man benötigt — so kann man bei der eigentlichen Installation auf die gleichen Quellen verweisen und erst bei der Installations-XML-Datei den Funktionsumfang einschränken. Doch richtig spannend wird es beim Update-Verhalten: wenn sich die Clients die Updates aus dem Internet ziehen sollen, dann ab dafür! Falls nicht, müssen wir in der Update-Sektion der XML-Datei auf einen UNC-Pfad verweisen. Der Client schaut dann regelmäßig in diesen Pfad rein und prüft, ob die dort vorhandenen Quellen neuer sind als die Installation selbst. Ist das der Fall, geschieht ein Update. Falls nicht, dann nicht. Der Administrator hat somit also ein Stück weit wieder die Kontrolle über die Updates. Es ist ein denkbares Szenario, dass man zwei getrennte UNC-Pfade anlegt und in jeweils unabhängigen XML-Dateien einen davon referenziert. So kann man einer Gruppe von Benutzern die Updates zeitnah zum Testen zur Verfügung stellen und — wenn es nach einem angemessenen Zeitraum keine Probleme gab — den UNC-Pfad updaten, auf den die breite Masse zugreift.

Print