Compilación de paquetes dinámicos, lean y universales para aplicaciones de Microsoft 365

Como administrador, podría planear la implementación de aplicaciones de Microsoft 365 en su organización. Esta implementación suele ser más que simplemente insertar las aplicaciones básicas de Microsoft 365 en los dispositivos. Es posible que los usuarios necesiten componentes adicionales, por ejemplo, paquetes de idioma, herramientas de corrección o productos adicionales como Visio o Project. A menudo nos referimos a estos escenarios como segunda instalación, mientras que la instalación inicial de Aplicaciones de Microsoft 365 se denomina a menudo 1ª instalación. Para los escenarios de 1ª instalación, examine las opciones de instalación y la mejor manera de ajustar el tamaño correcto de la implementación.

En este artículo se muestra cómo reducir considerablemente los costos de mantenimiento a largo plazo y mejorar la satisfacción del usuario mediante la implementación de dos instalaciones con paquetes dinámicos, lean y universales para aplicaciones de Microsoft 365.

El desafío

Históricamente, la tarea de admitir dos escenarios de instalación se resolvió mediante la creación de un paquete de instalación dedicado para cada uno. Normalmente, un administrador combinaría los archivos de origen necesarios (de aproximadamente 3 gigabytes) con una copia de la Herramienta de implementación de Office (ODT) y un archivo de configuración adaptado para el escenario.

Pero, especialmente en organizaciones más grandes, a menudo no tiene un único conjunto de configuración de Aplicaciones de Microsoft 365. Es posible que tenga una combinación de canales de actualización, por ejemplo, la mayoría está en El canal mensual de empresa y algunos dispositivos de uso especial están en Semi-Annual Canal enterprise. Tal vez esté realizando la transición de 32 bits a 64 bits y tenga que admitir ambas arquitecturas durante algún tiempo.

Si crea una implementación dedicada de Language Pack para cada canal y arquitectura del ejemplo anterior, terminaría con cuatro paquetes: Monthly Enterprise Channel x86, Monthly Enterprise Channel x64, Semi-Annual Enterprise Channel x86, Semi-Annual Enterprise Channel x64. Este no es un enfoque sostenible y tiene las siguientes desventajas:

• Costos de mantenimiento elevados debidos
  • Número elevado de paquetes que se van a crear y mantener.
  • Los archivos de origen incrustados se desactualiza con el tiempo y necesitan mantenimiento.
  • Alto consumo de ancho de banda durante la implementación, ya que el paquete completo de 3 GB se sincroniza con el dispositivo antes de que se inicie la instalación real.
• Experiencia de usuario incorrecta
  • Los usuarios tienen que comprender su configuración actual y elegir el paquete coincidente en el portal de software.
  • El tiempo de implementación largo como archivos de origen completos se sincroniza primero.
  • Si los archivos de origen incrustados no están actualizados, la instalación degradará la instalación completa antes de que el ciclo de actualización se inicie y vuelva a actualizar todas las aplicaciones.

Por lo tanto, ¿cómo se crean paquetes que son menos costosos de mantener a lo largo del tiempo y son más fáciles de usar?

La solución: paquetes dinámicos, lean y universales

Para resolver estos problemas, implemente paquetes autoajustados, pequeños y universales. Vamos a tratar los conceptos básicos antes de profundizar en escenarios de ejemplo.

Compile paquetes dinámicos donde no codifique de forma rígida nada. Use las características de la herramienta de implementación de Office (ODT) para permitir que los paquetes se ajusten automáticamente a los requisitos:

• Use Version=MatchInstalled para evitar actualizaciones inesperadas y mantener el control de la versión instalada en un cliente. No hay codificación rígida de un número de compilación, que se queda obsoleto rápidamente.
• Use Language=MatchInstalled para indicar, por ejemplo, a Visio o Project que se instalen con el mismo conjunto de idiomas que Office ya está usando. No es necesario enumerarlos ni compilar un script que inserte los idiomas necesarios.

Compile paquetes lean quitando los archivos de origen de los paquetes. Esto tiene varias ventajas:

• El tamaño del paquete es menor, de 3 GB a menos de 10 megabytes para el ODT y su archivo de configuración.
• En lugar de insertar un paquete de instalación de 3 GB en los clientes, permite que los clientes extraigan lo que necesitan a petición de Office Content Delivery Network (CDN), lo que ahorra ancho de banda.
  • Al agregar Project a una instalación existente de Aplicaciones de Microsoft 365, debe descargar menos de 50 megabytes, ya que los componentes compartidos de Office ya están instalados.
  • Las instalaciones de Visio suelen tener entre 100 y 200 megabytes, en función del número de idiomas, ya que las plantillas o galerías de símbolos son una parte sustancial de la descarga.
  • La instalación de herramientas de corrección suele tener entre 30 y 50 megabytes, frente a un paquete de idioma completo, que es de 200 a 300 megabytes.
• Un segundo escenario de instalación suele ser menos frecuente, lo que reduce la carga del tráfico de Internet y, en última instancia, reduce el impacto.
• No es necesario actualizar los archivos de origen cada vez que Microsoft publica nuevas características o correcciones de seguridad y calidad.

Cree paquetes universales no codificando de forma rígida elementos como la arquitectura o el canal de actualización. ODT coincidirá dinámicamente con la instalación existente, por lo que los paquetes funcionan en todos los canales de actualización y arquitecturas. En lugar de tener cuatro paquetes para instalar Visio, por ejemplo, tiene un único paquete universal que funciona en todas las permutaciones de canales de actualización y arquitecturas.

• Al dejar fuera OfficeClientEdition , el paquete es universal para entornos x86/x64 mixtos.
• Si se deja fuera El canal hace que el paquete sea universal en todos los canales de actualización.

Cómo crear y beneficiarse de la creación de paquetes dinámicos, lean y universales

La idea es no codificar de forma rígida nada en el archivo de configuración, sino usar la inteligencia de la herramienta de implementación de Office tanto como sea posible.

Echemos un vistazo a un paquete "clásico" creado para agregar Project a una instalación existente de Aplicaciones de Microsoft 365. Tenemos los archivos de origen (de aproximadamente 3 gigabytes) y un archivo de configuración, que indica explícitamente lo que queremos lograr:

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

Cuando aplicamos los conceptos de paquetes dinámicos, lean y universales, el resultado tendría este aspecto:

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

¿Qué hemos cambiado y cuáles son las ventajas?

• Hemos quitado el atributo OfficeClientEdition, ya que el ODT coincidirá automáticamente con la versión instalada.
  • Ventaja: el archivo de configuración ahora funciona para escenarios x86 y x64.
• Hemos quitado el canal por la misma razón. ODT coincidirá automáticamente con el canal de actualización ya asignado.
  • Ventaja I: El paquete funciona para todos los canales de actualización (canal actual, canal mensual de empresa, Semi-Annual canal enterprise, entre otros).
  • Ventaja II: también funciona para los canales de actualización que no ofrece como TI central. Algunos usuarios ejecutan el canal actual, ¿otros están en compilaciones de Insider? No te preocupes, sólo funciona.
• Hemos agregado Version="MatchInstalled", que garantiza que ODT instalará la misma versión que ya está instalada.
  • Ventaja: tiene el control de las versiones implementadas, sin actualizaciones inesperadas.
• Hemos agregado Language ID="MatchInstalled" y TargetProduct para que coincidan con los idiomas instalados actualmente, reemplazando una lista codificada de forma rígida de los idiomas que se van a instalar.
  • Ventaja I: El usuario tiene los mismos idiomas para Project que ya se instalaron para Office.
  • Ventaja II: no es necesario volver a solicitar las instalaciones del paquete de idioma.
  • Ventaja III: también funciona para los lenguajes que no se usan con frecuencia y que usted como administrador central de TI no ofrece, lo que hace que los usuarios estén satisfechos.
• Hemos quitado los archivos de origen. ODT capturará el conjunto correcto de archivos de origen de la red CDN de Office justo a tiempo.
  • Ventaja I: El paquete nunca queda obsoleto. No se necesita ningún mantenimiento de los archivos de origen.
  • Ventaja II: la descarga es de unos 50 megabytes en lugar de unos 3 GB.

Otro ejemplo: Agregar paquetes de idioma y herramientas de corrección de forma dinámica, ajustada y universal

Echemos un vistazo brevemente a otros escenarios, como agregar paquetes de idioma y herramientas de corrección. El archivo de configuración clásico para instalar el paquete de idioma alemán podría tener este aspecto:

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

De nuevo, este archivo de configuración solo funcionaría para un escenario específico (el canal de actualización está establecido en Canal mensual de empresa, se instala 64 bits). Otros escenarios tendrían que estar cubiertos por archivos y paquetes adicionales, que impulsan la complejidad y el costo de propiedad. Para corregir esto, basta con ir de la manera dinámica, magra y universal:

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

Este único archivo de configuración funciona en x86/x64 y en todos los canales de actualización, como canal actual, canal mensual de empresa, Semi-Annual canal de empresa, entre otros. Por lo tanto, si desea ofrecer cinco idiomas adicionales en su entorno, solo tiene que crear cinco de estos paquetes de "archivo de configuración + ODT". Para las herramientas de corrección, solo tiene que cambiar ProductID a "ProofingTools".

Compilación de su propia configuración

El concepto anterior es universalmente aplicable a todas las instalaciones y productos basados en hacer clic y ejecutar, siempre y cuando se use el ODT. Puede cambiar el identificador de producto especificado a su escenario. Consulte la lista de identificadores de producto admitidos para obtener más información.

Requisitos previos o notas

Estos son algunos requisitos previos que debe cumplir para que este concepto funcione en su entorno y algunas notas:

• Use la herramienta de implementación de Office 16.0.11615.33602 o posterior para habilitar Version="MatchInstalled" para que funcione.
• El ODT debe ser capaz de encontrar los archivos de origen coincidentes en la red CDN de Office.
• Asegúrese de que el contexto que usa para ejecutar la instalación puede atravesar el proxy. Para obtener más información, vea Office 365 ProPlus Deployment and Proxy Server Guidance (Guía de implementación y servidor proxy de Office 365 ProPlus).
• Asegúrese de que la cuenta (usuario o sistema) que se usa para instalar las aplicaciones puede conectarse a Internet.
• Los archivos de configuración personalizados mostrados anteriormente son adecuados para instalar los productos (con el modificador /configure), pero no funcionan con el modificador /download. Esto se espera, ya que al ODT le faltan algunos detalles para realizar una descarga (por ejemplo, la arquitectura). Para el concepto anterior, no es necesario descargar los archivos de antemano.