Teilen über

Erstellen dynamischer, schlanker und universeller Pakete für Microsoft 365-Apps

  • Artikel

Hinweis

Dieser Artikel wurde von den Microsoft 365 Apps Rangers erstellt und beschreibt gängige Methoden, die in kundenspezifischen Implementierungen beobachtet werden. Wir empfehlen Ihnen, die Relevanz dieses Leitfadens für Ihre Organisation zu bewerten und den Ansatz bei Bedarf anzupassen.

Als Administrator planen Sie möglicherweise die Bereitstellung von Microsoft 365-Apps in Ihrer Organisation. Eine solche Bereitstellung ist oft mehr als nur das Pushen der grundlegenden Microsoft 365-Apps auf Geräte. Benutzer benötigen möglicherweise zusätzliche Komponenten, z. B. Sprachpakete, Korrekturhilfen oder zusätzliche Produkte wie Visio oder Project. Wir bezeichnen diese Szenarien häufig als 2. Installation, während die Erstinstallation von Microsoft 365 Apps häufig als 1. Installation bezeichnet wird. Sehen Sie sich für 1. Installationsszenarien die Installationsoptionen und die beste Möglichkeit zur richtigen Größe Ihrer Bereitstellung an.

In diesem Artikel erfahren Sie, wie Sie die langfristigen Wartungskosten erheblich senken und die Benutzerzufriedenheit verbessern können, indem Sie 2. Installationen mit dynamischen, schlanken und universellen Paketen für Microsoft 365-Apps implementieren.

Die Herausforderung

In der Vergangenheit wurde die Aufgabe, 2. Installationsszenarien zu unterstützen, durch die Erstellung eines dedizierten Installationspakets für jedes gelöst. Normalerweise kombiniert ein Administrator die erforderlichen Quelldateien (von ca. 3 Gigabyte) mit einer Kopie des Office-Bereitstellungstools (ODT) und einer auf das Szenario zugeschnittenen Konfigurationsdatei.

Aber vor allem in größeren Organisationen verfügen Sie häufig nicht über einen einzigen Konfigurationssatz von Microsoft 365 Apps. Möglicherweise verfügen Sie über eine Mischung aus Updatekanälen, z. B. befindet sich die Mehrheit im monatlichen Enterprise-Kanal und einige spezielle Geräte befinden sich in Semi-Annual Enterprise-Kanal. Vielleicht sind Sie gerade dabei, von 32-Bit auf 64-Bit umzusteigen, und Sie müssen beide Architekturen für einige Zeit unterstützen.

Wenn Sie im vorherigen Beispiel eine dedizierte Language Pack-Bereitstellung für jeden Kanal und jede Architektur erstellen, würden Sie vier Pakete haben: Monatlicher Enterprise-Kanal x86, monatlicher Enterprise-Kanal x64, Semi-Annual Enterprise Channel x86, Semi-Annual Enterprise Channel x64. Dies ist kein nachhaltiger Ansatz und hat die folgenden Nachteile:

  • Hohe Wartungskosten fällig
    • Hohe Anzahl von Zu erstellenden und zu verwaltenden Paketen.
    • Eingebettete Quelldateien werden im Laufe der Zeit veraltet und müssen gewartet werden.
    • Hoher Bandbreitenverbrauch während der Bereitstellung, da das vollständige 3-GB-Paket mit dem Gerät synchronisiert wird, bevor die eigentliche Installation gestartet wird.
  • Schlechte Benutzererfahrung
    • Benutzer müssen ihre aktuelle Konfiguration verstehen und das entsprechende Paket im Softwareportal auswählen.
    • Lange Bereitstellungszeit, da zuerst vollständige Quelldateien synchronisiert werden.
    • Wenn eingebettete Quelldateien veraltet sind, wird die vollständige Installation von der Installation herabgestuft, bevor der Updatezyklus beginnt und alle Apps erneut aktualisiert werden.

Wie können Sie also Pakete erstellen, die im Laufe der Zeit kostengünstiger zu verwalten sind und benutzerfreundlicher sind?

Die Lösung: Dynamische, schlanke und universelle Pakete

Sie können diese Probleme beheben, indem Sie selbst anpassende, kleine und universelle Pakete implementieren. Lassen Sie uns die grundlegenden Konzepte behandeln, bevor wir uns mit Beispielszenarien befassen.

Erstellen Sie dynamische Pakete, in denen Sie nichts hartcodierten. Verwenden Sie Die Features des Office-Bereitstellungstools (ODT), um es den Paketen zu ermöglichen, sich selbst an die Anforderungen anzupassen:

  • Verwenden Sie Version=MatchInstalled , um unerwartete Updates zu verhindern und die Kontrolle über die auf einem Client installierte Version zu behalten. Keine harte Codierung einer Buildnummer, die schnell veraltet wird.
  • Verwenden Sie Language=MatchInstalled , um z. B. Visio oder Project anzuweisen, mit demselben Satz von Sprachen zu installieren, den Office bereits verwendet. Es ist nicht erforderlich, sie aufzulisten oder ein Skript zu erstellen, das die erforderlichen Sprachen einschleust.

Erstellen Sie schlanke Pakete, indem Sie die Quelldateien aus den Paketen entfernen. Dies hat mehrere Vorteile:

  • Die Paketgröße ist kleiner, von 3 GB bis weniger als 10 Megabyte für das ODT und seine Konfigurationsdatei.
  • Anstatt ein 3-GB-Installationspaket per Push an Clients zu übertragen, können Sie clients bei Bedarf aus Dem Office Content Delivery Network (CDN) abrufen, wodurch Bandbreite gespart wird.
    • Wenn Sie Project einer vorhandenen Microsoft 365 Apps-Installation hinzufügen, müssen Sie weniger als 50 MB herunterladen, da freigegebene Office-Komponenten bereits installiert sind.
    • Visio-Installationen umfassen in der Regel 100 bis 200 Megabyte, basierend auf der Anzahl der Sprachen, da die Vorlagen/Schablonen ein wesentlicher Bestandteil des Downloads sind.
    • Die Installation von Korrekturhilfen beträgt in der Regel 30 bis 50 Megabyte im Vergleich zu einem vollständigen Sprachpaket, das 200 bis 300 Megabyte umfasst.
  • Ein zweites Installationsszenario ist häufig weniger häufig, was die Last des Internetdatenverkehrs verringert und letztendlich die Auswirkungen verringert.
  • Sie müssen die Quelldateien nicht jedes Mal aktualisieren, wenn Microsoft neue Features oder Sicherheits- und Qualitätskorrekturen veröffentlicht.

Erstellen Sie universelle Pakete, indem Sie Dinge wie die Architektur oder den Updatekanal nicht hart codieren. ODT entspricht dynamisch der vorhandenen Installation, sodass Ihre Pakete über alle Updatekanäle und -architekturen hinweg funktionieren. Anstatt beispielsweise vier Pakete zum Installieren von Visio zu haben, verfügen Sie über ein einzelnes, universelles Paket, das über alle Permutationen von Updatekanälen und -architekturen hinweg funktioniert.

  • Wenn Sie OfficeClientEdition weglassen, wird Ihr Paket universell für gemischte x86/x64-Umgebungen.
  • Wenn Sie Den Kanal weglassen, wird Ihr Paket universell über Updatekanäle hinweg.

Erstellen und Nutzen von dynamischen, schlanken und universellen Paketen

Die Idee besteht darin, nichts in der Konfigurationsdatei zu hartcodieren, sondern stattdessen die Cleverness des Office-Bereitstellungstools so weit wie möglich zu nutzen.

Sehen wir uns ein "klassisches" Paket an, das erstellt wurde, um Project zu einer vorhandenen Installation von Microsoft 365 Apps hinzuzufügen. Wir verfügen über die Quelldateien (von ~3 Gigabyte) und eine Konfigurationsdatei, die explizit angibt, was wir erreichen möchten:

Screenshot eines Beispielpakets. 

<Configuration>
 <Add OfficeClientEdition="64" Channel="MonthlyEnterprise">
  <Product ID="ProjectProRetail">
   <Language ID="en-us" />
  </Product>
 </Add>
 <Display Level="None" />
</Configuration>

Wenn wir die Konzepte dynamischer, schlanker und universeller Pakete anwenden, sieht das Ergebnis wie folgt aus:

Screenshot eines schlanken Beispielpakets. 

<Configuration>
 <Add Version="MatchInstalled">
  <Product ID="ProjectProRetail">
   <Language ID="MatchInstalled" TargetProduct="O365ProPlusRetail" />
  </Product>
 </Add>
 <Display Level="None" />
</Configuration>

Was haben wir uns also geändert, und was sind die Vorteile?

  • Wir haben das OfficeClientEdition-Attribut entfernt, da das ODT automatisch mit der installierten Version übereinstimmt.
    • Vorteil: Die Konfigurationsdatei funktioniert jetzt sowohl für x86- als auch für x64-Szenarien.
  • Wir haben den Kanal aus demselben Grund entfernt. ODT entspricht automatisch dem bereits zugewiesenen Updatekanal.
    • Vorteil I: Das Paket funktioniert für alle Updatekanäle (Aktueller Kanal, monatlicher Enterprise-Kanal, Semi-Annual Enterprise-Kanal usw.).
    • Vorteil II: Es funktioniert auch für Updatekanäle, die Sie nicht als zentrale IT anbieten. Einige Benutzer führen den aktuellen Kanal aus, andere sind Insider-Builds? Keine Sorge, es funktioniert einfach.
  • Wir haben Version="MatchInstalled" hinzugefügt, um sicherzustellen, dass ODT dieselbe Version installiert, die bereits installiert ist.
    • Vorteil: Sie haben die Kontrolle über bereitgestellte Versionen ohne unerwartete Updates.
  • Wir haben Language ID="MatchInstalled" und TargetProduct hinzugefügt, um den aktuell installierten Sprachen zu entsprechen, wobei eine hartcodierte Liste der zu installierenden Sprachen ersetzt wurde.
    • Vorteil I: Der Benutzer verfügt über die gleichen Sprachen für Project, die bereits für Office installiert wurden.
    • Vorteil II: Keine erneute Anforderung von Sprachpaketinstallationen.
    • Vorteil III: Funktioniert auch für selten verwendete Sprachen, die Sie als zentraler IT-Administrator nicht anbieten, was die Benutzer zufrieden macht.
  • Wir haben die Quelldateien entfernt. Das ODT ruft den richtigen Satz von Quelldateien just-in-time aus dem Office CDN ab.
    • Vorteil I: Das Paket wird nie veraltet. Es ist keine Wartung der Quelldateien erforderlich.
    • Vorteil II: Der Download beträgt ca. 50 Mb statt etwa 3 GB.

Ein weiteres Beispiel: Hinzufügen von Sprachpaketen und Korrekturhilfen auf dynamische, schlanke und universelle Weise

Lassen Sie uns auch einen kurzen Blick auf andere Szenarien werfen, z. B. das Hinzufügen von Sprachpaketen und Korrekturhilfen. Die klassische Konfigurationsdatei zum Installieren des Deutsch-Sprachpakets könnte wie folgt aussehen:

<Configuration>
 <Add OfficeClientEdition="64" Channel="MonthlyEnterprise">
  <Product ID="LanguagePack">
   <Language ID="de-de" />
  </Product>
 </Add>
 <Display Level="None" />
</Configuration>

Auch hier würde diese Konfigurationsdatei nur für ein bestimmtes Szenario funktionieren (Updatekanal ist auf Monatlicher Enterprise-Kanal festgelegt, 64-Bit ist installiert). Andere Szenarien müssen durch zusätzliche Dateien und Pakete abgedeckt werden, die die Komplexität und die Betriebskosten erhöhen. Beheben Sie dies, indem Sie einfach den dynamischen, schlanken und universellen Weg gehen:

<Configuration>
 <Add Version="MatchInstalled">
  <Product ID="LanguagePack">
   <Language ID="de-de" />
  </Product>
 </Add>
 <Display Level="None" />
</Configuration>

Diese einzelne Konfigurationsdatei funktioniert für x86/x64 und alle Updatekanäle, z. B. Aktueller Kanal, monatlicher Enterprise-Kanal, Semi-Annual Enterprise-Kanal und andere. Wenn Sie also fünf zusätzliche Sprachen in Ihrer Umgebung anbieten möchten, erstellen Sie einfach fünf dieser "Konfigurationsdatei + ODT"-Pakete. Für Korrekturhilfen ändern Sie einfach die ProductID in "ProofingTools".

Erstellen Einer eigenen Konfiguration

Das oben genannte Konzept ist universell auf alle Klick-und-Run-basierten Installationen und Produkte anwendbar, solange das ODT verwendet wird. Sie können die angegebene Produkt-ID in Ihr Szenario ändern. Weitere Informationen finden Sie in der Liste der unterstützten Produkt-IDs .

Voraussetzungen/Hinweise

Hier sind einige Voraussetzungen, die Sie erfüllen müssen, damit dieses Konzept in Ihrer Umgebung funktioniert, und einige Hinweise: