Créer des packages dynamiques, simples et universels pour Microsoft 365 Apps

Remarque

Rédigé par le Microsoft 365 Apps Rangers, cet article décrit les pratiques courantes observées dans les implémentations des clients. Nous vous conseillons d’évaluer la pertinence de ces conseils pour vos organization et d’adapter l’approche si nécessaire.

En tant qu’administrateur, vous pouvez planifier le déploiement de Microsoft 365 Apps dans votre organization. Un tel déploiement est souvent plus qu’un simple envoi de la Microsoft 365 Apps de base aux appareils. Les utilisateurs peuvent avoir besoin de composants supplémentaires, tels que des modules linguistiques, des outils de vérification linguistique ou des produits supplémentaires comme Visio ou Project. Nous faisons souvent référence à ces scénarios en tant que 2e installation, tandis que l’installation initiale de Microsoft 365 Apps est souvent appelée 1ère installation. Pour les 1er scénarios d’installation, examinez les options d’installation et la meilleure façon de dimensionner correctement votre déploiement.

Cet article vous montre comment réduire considérablement les coûts de maintenance à long terme et améliorer la satisfaction des utilisateurs en implémentant deux installations avec des packages dynamiques, lean et universels pour Microsoft 365 Apps.

Défi à relever

Historiquement, la tâche de prise en charge des scénarios d’installation 2 a été résolue en créant un package d’installation dédié pour chacun d’eux. En règle générale, un administrateur combine les fichiers sources nécessaires (d’environ 3 gigaoctets) avec une copie de l’outil déploiement d’Office (ODT) et un fichier de configuration adapté au scénario.

Mais, en particulier dans les grandes organisations, vous n’avez souvent pas un seul ensemble de configuration de Microsoft 365 Apps. Vous pouvez avoir une combinaison de canaux de mise à jour, par exemple, la majorité se trouve sur le canal Entreprise mensuel et quelques appareils à usage spécial se trouve sur Semi-Annual canal Entreprise. Peut-être que vous passez actuellement de 32 bits à 64 bits, et que vous devez prendre en charge les deux architectures pendant un certain temps.

Si vous générez un déploiement de module linguistique dédié, par exemple, pour chaque canal et architecture dans l’exemple précédent, vous vous retrouvez avec quatre packages : Canal Entreprise mensuel x86, Canal Entreprise mensuel x64, Semi-Annual Canal Entreprise x86, Semi-Annual Canal Entreprise x64. Il ne s’agit pas d’une approche durable et présente les inconvénients suivants :

• Coûts de maintenance élevés dus
  • Nombre élevé de packages à créer et à gérer.
  • Les fichiers sources incorporés sont obsolètes au fil du temps et nécessitent une maintenance.
  • Consommation élevée de bande passante pendant le déploiement, car le package complet de 3 Go est synchronisé avec l’appareil avant le démarrage de l’installation réelle.
• Expérience utilisateur incorrecte
  • Les utilisateurs doivent comprendre leur configuration actuelle et choisir le package correspondant dans le portail logiciel.
  • Temps de déploiement long, car les fichiers sources complets sont synchronisés en premier.
  • Si les fichiers sources incorporés sont obsolètes, l’installation rétrograde l’installation complète, avant que le cycle de mise à jour ne démarre et met à jour à nouveau toutes les applications.

Alors, comment créer des packages qui sont moins coûteux à gérer au fil du temps et qui sont plus conviviaux ?

La solution : packages dynamiques, lean et universels

Vous pouvez résoudre ces problèmes en implémentant des packages à ajustement automatique, petits et universels. Examinons les concepts de base avant de nous plonger dans des exemples de scénarios.

Créez des packages dynamiques dans lesquels vous ne codez rien en dur. Utilisez les fonctionnalités de l’outil Déploiement d’Office (ODT) pour permettre aux packages de s’ajuster automatiquement aux exigences :

• Utilisez Version=MatchInstalled pour éviter les mises à jour inattendues et garder le contrôle de la version installée sur un client. Aucun codage en dur d’un numéro de build, qui devient rapidement obsolète.
• Utilisez Language=MatchInstalled pour indiquer, par exemple, à Visio ou Project d’installer avec le même ensemble de langues qu’Office utilise déjà. Il n’est pas nécessaire de les répertorier ou de créer un script qui injecte les langues requises.

Créez des packages lean en supprimant les fichiers sources des packages. Cela présente plusieurs avantages :

• La taille du package est inférieure, de 3 Go à moins de 10 mégaoctets pour l’ODT et son fichier de configuration.
• Au lieu d’envoyer (push) un package d’installation de 3 Go aux clients, vous permettez aux clients d’extraire ce dont ils ont besoin à la demande à partir d’Office Content Delivery Network (CDN), ce qui permet d’économiser de la bande passante.
  • Lorsque vous ajoutez Project à une installation Microsoft 365 Apps existante, vous devez télécharger moins de 50 mégaoctets, car les composants partagés Office sont déjà installés.
  • Les installations Visio sont généralement comprises entre 100 et 200 mégaoctets, en fonction du nombre de langues, car les modèles/gabarits constituent une partie importante du téléchargement.
  • L’installation des outils de vérification linguistique est généralement de 30 à 50 mégaoctets, par rapport à un module linguistique complet, qui est de 200 à 300 mégaoctets.
• Un deuxième scénario d’installation est souvent moins fréquent, ce qui réduit la charge du trafic Internet, ce qui réduit l’impact.
• Vous n’avez pas besoin de mettre à jour les fichiers sources chaque fois que Microsoft publie de nouvelles fonctionnalités ou des correctifs de sécurité et de qualité.

Créez des packages universels en ne codant pas en dur des éléments tels que l’architecture ou le canal de mise à jour. ODT correspondra dynamiquement à l’installation existante, de sorte que vos packages fonctionnent sur tous les canaux et architectures de mise à jour. Au lieu d’avoir quatre packages pour installer Visio, par exemple, vous disposez d’un seul package universel qui fonctionne sur toutes les permutations des canaux de mise à jour et des architectures.

• L’absence d’OfficeClientEdition rend votre package universel pour les environnements x86/x64 mixtes.
• L’abandon du canal rend votre package universel sur les canaux de mise à jour.

Comment créer et tirer parti de la création de packages dynamiques, lean et universels

L’idée est de ne rien coder en dur dans le fichier de configuration, mais plutôt d’utiliser autant que possible l’intelligence de l’outil déploiement d’Office.

Examinons un package « classique » qui a été créé pour ajouter Project à une installation existante de Microsoft 365 Apps. Nous avons les fichiers sources (d’environ 3 gigaoctets) et un fichier de configuration, qui indique explicitement ce que nous voulons atteindre :

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

Lorsque nous appliquons les concepts de packages dynamiques, lean et universels, le résultat se présente comme suit :

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

Alors, qu’est-ce que nous avons changé et quels sont les avantages ?

• Nous avons supprimé l’attribut OfficeClientEdition, car l’ODT correspondra automatiquement à la version installée.
  • Avantage : Le fichier de configuration fonctionne désormais pour les scénarios x86 et x64.
• Nous avons supprimé le canal pour la même raison. ODT correspondra automatiquement au canal de mise à jour déjà attribué.
  • Avantage I : le package fonctionne pour tous les canaux de mise à jour (canal actuel, canal entreprise mensuel, canal entreprise Semi-Annual et autres).
  • Avantage II : Il fonctionne également pour les canaux de mise à jour que vous n’offrez pas en tant qu’informatique centrale. Certains utilisateurs exécutent le canal actuel, d’autres utilisant des builds Insider ? Ne vous inquiétez pas, ça marche.
• Nous avons ajouté Version="MatchInstalled », ce qui garantit qu’ODT installera la même version que celle déjà installée.
  • Avantage : vous contrôlez les versions déployées, sans mises à jour inattendues.
• Nous avons ajouté Language ID="MatchInstalled » et TargetProduct pour correspondre aux langues actuellement installées, en remplaçant une liste codée en dur des langues à installer.
  • Avantage I : L’utilisateur a les mêmes langues pour Project que celles déjà installées pour Office.
  • Avantage II : Il n’est pas nécessaire de demander à nouveau les installations du module linguistique.
  • Avantage III : fonctionne également pour les langues rarement utilisées que vous n’avez pas proposées en tant qu’administrateur informatique central, ce qui rend les utilisateurs heureux.
• Nous avons supprimé les fichiers sources. L’ODT récupère l’ensemble correct de fichiers sources à partir du CDN Office juste à temps.
  • Avantage I : Le package n’est jamais obsolète. Aucune maintenance des fichiers sources n’est nécessaire.
  • Avantage II : Le téléchargement est d’environ 50 mégaoctets au lieu d’environ 3 Go.

Autre exemple : ajouter des modules linguistiques et des outils de vérification linguistique de manière dynamique, lean et universelle

Examinons brièvement d’autres scénarios, comme l’ajout de modules linguistiques et d’outils de vérification linguistique. Le fichier de configuration classique pour installer le module linguistique allemand peut ressembler à ceci :

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

Là encore, ce fichier de configuration ne fonctionne que pour un scénario spécifique (le canal de mise à jour est défini sur Canal Entreprise mensuel, 64 bits est installé). D’autres scénarios doivent être couverts par des fichiers et des packages supplémentaires, qui accélèrent la complexité et le coût de possession. Corrigez ce problème en adoptant simplement la méthode dynamique, lean et universelle :

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

Ce fichier de configuration unique fonctionne sur les canaux x86/x64 et tous les canaux de mise à jour, tels que le canal actuel, le canal Entreprise mensuel, Semi-Annual canal Entreprise, etc. Par conséquent, si vous souhaitez proposer cinq langages supplémentaires dans votre environnement, créez simplement cinq de ces packages « fichier de configuration + ODT ». Pour les outils de vérification linguistique, il vous suffit de remplacer le ProductID par « ProofingTools ».

Créer votre propre configuration

Le concept ci-dessus s’applique universellement à tous les produits et installations « Démarrer en un clic », tant que l’ODT est utilisé. Vous pouvez remplacer l’ID de produit spécifié par votre scénario. Pour plus d’informations, consultez la liste des ID de produit pris en charge .

Conditions préalables/notes

Voici quelques prérequis que vous devez respecter pour que ce concept fonctionne dans votre environnement et quelques remarques :

• Utilisez l’outil Déploiement d’Office 16.0.11615.33602 ou version ultérieure pour activer le fonctionnement de Version="MatchInstalled ».
• L’ODT doit être en mesure de localiser les fichiers sources correspondants sur le CDN Office.
• Assurez-vous que le contexte que vous utilisez pour exécuter l’installation peut traverser le proxy. Pour plus d’informations, consultez Office 365 ProPlus Déploiement et conseils sur le serveur proxy.
• Assurez-vous que le compte (utilisateur ou système) utilisé pour installer les applications peut se connecter à Internet.
• Les fichiers de configuration personnalisés indiqués précédemment sont adaptés à l’installation des produits (avec le commutateur /configure), mais ne fonctionnent pas avec le commutateur /download. Cela est normal, car il manque certains détails à l’ODT pour effectuer un téléchargement (comme l’architecture). Pour le concept ci-dessus, il n’est pas nécessaire de télécharger les fichiers au préalable.