Updates mit Office 365 ProPlus – Teil 2
Die Office Deployment Tools
Die Office Deployment Tools besteht aus einer Setup.exe die mit Parametern und einer XML-Datei gesteuert wird. In der XML Datei wird die Konfiguration der Unterstützten Office Produkte, inklusive Visio oder Project, vorgenommen. Dabei können auch Anpassungen an Zielpfade, Speicher und Updatepfade, sowie eine Auswahl von Sprachen und Versionen vorgenommen werden. Das Besondere ist, das das Office Deployment Tools nicht nur zum Herunterladen der Installationsquellen genutzt werden kann, sondern auch zu Installation. So kann damit nicht nur eine Stille Installation durchgeführt werden, sondern es können auch Anwendungen von der Installation ausgeschlossen werden. Diese Funktion ist besonders interessant, falls bestimmte Software erst später oder gar nicht eingeführt werden soll, zum Beispiel OneDrive Pro.
Eine weitere Besonderheit ist, das über die Office Deployment Tools die Möglichkeit besteht, Office 365 ProPlus für einen Speziellen Aktivierungsmodus für Computer mit mehreren Benutzern (Auch Simultan) zu installieren. Dieser “Shared computer activation” genannte Modus ist vor allem für VDI, Terminal Server Umgebungen oder Arbeitsplätze die von mehreren Mitarbeitern parallel genutzt werden (zum Beispiel mit der Funktion Sekundäre Anmeldung) notwendig.
Eine weitere Möglichkeit mit dem Office Deployment Tool ist ein entsprechendes App-V Packet entsprechend der Konfiguration zu erzeugen. Dies Paket kann dann wie ein normales App-V Paket behandelt werden.
Die Kontrolle über die Updates
Wie bereits erwähnt, kann die Updatequelle auch innerhalb des Unternehmens sein. Diese Konfiguration und noch viele mehr werden über Gruppenrichtlinien gesteuert. Dafür müssen Sie nur die Administrativen Vorlagen für Microsoft Office 2013 installieren.
Einstellungsmöglichkeiten über Gruppenrichtlinien für Microsoft Office 365 ProPlus Klick2Run Installationen – Screenshot Gruppenrichtlinienverwaltungskonsole
Hier ist es sogar möglich eine Zielversion über Gruppenrichtlinien mit anzugeben. Weiter Möglichkeiten sind zum Beispiel das Anpassen der Zeitdauer, bis der Anwender darauf hingewiesen wird, das Microsoft Office ein Update benötigt.
Mögliche Szenarien mit dem modernen Weg
Über diesen neuen Weg wäre auch eine Mehrstufige Verteilung der Updates möglich. Die Testgruppe bekommt ihren neuen Build zum Beispiel am Patchday von Microsoft. Der Rest von einer lokalen Verteilungsquelle die erst 2 Wochen nach dem Patchday aktualisiert wird. Alternativ kann auch einfach, wie schon beschrieben, die zu installierende Version in einer Gruppenrichtlinie gesetzt werden. Über ein solches Szenario erhält man einen Vollautomatischen Update Zyklus, in den im Bedarfsfall eingegriffen werden kann.
Und die Zukunft?
Hier nun ein Blick in die Zukunft, die Informationen wurden von Microsoft auf der Ignite 2015 Konferenz bekannt gegeben. Da sie sich aber auf Microsoft Office 2016, dass in einer Preview Phase ist, möchte ich das folgende mal als Absichtserklärung darstellen.
In Zukunft wird es nicht nur Sicherheitsupdate im Monatlichen Build geben, sondern auch Funktionserweiterungen. Diese Build Gruppe bezeichnet Microsoft als “Current Branch”. Für Kunden die nicht immer neue Funktionen haben möchten wird ein “Deferred Branch” angeboten werden. Von diesen “Deferred Branch” wird es alle 4 Monate eine neue Version mit neue Funktionserweiterungen geben. Der alte “Deferred Branch” aber noch weitere 4 Monate mit Sicherheitsupdates versorgt. So können neue Funktionen und Erweiterungen erstmal in Ruhe getestet werden. In ein solchen neueren DB-Build fließen dann alle Erweiterungen und neuen Funktionen seit dem letzten DB-Build bis zu dem Aktuellen CB-Build.
Deferred Branch Mechanismus für Zukünftige Microsoft Office 365 ProPlus Update – Quelle: Screenshot Microsoft Ignite Konferenz Unterlagen
Eine weitere Neuerung die geplant ist, ist eine bessere Integration in den Microsoft System Center Configuration Manager (SCCM) für den Verteilungsmechanismus, so das auch SCCM Verteilungspunkte genutzt werden können. Geplant ist dies für SCCM v.NEXT, eine Unterstützung von SCCM 2012 wird noch geprüft.
Über den Autor
Fabian Niesen ist seit Jahren beruflich als IT-Consultant unterwegs und hat von Mai 2012 bis Juli 2015 bei der CONET Solutions GmbH in Hennef gearbeitet. Unter anderem ist er Zertifiziert als MCSA Windows Server 2012, MCSA Office365, MCSE Messeging, Microsoft Certified Trainer und Novell Certified Linux Administrator.
