Criar pacotes dinâmicos, enxutos e universais para Microsoft 365 Apps

Artigo
02/29/2024

Observação

Criado pelo Microsoft 365 Apps Rangers, este artigo descreve práticas comuns observadas entre implementações de cliente. Aconselhamos avaliar a relevância dessas diretrizes para sua organização e adaptar a abordagem conforme necessário.

Como administrador, você pode planejar implantar Microsoft 365 Apps em sua organização. Essa implantação geralmente é mais do que apenas empurrar o Microsoft 365 Apps básico para dispositivos. Os usuários podem precisar de componentes adicionais, por exemplo, pacotes de idiomas, ferramentas de revisão ou produtos adicionais como Visio ou Project. Geralmente, nos referimos a esses cenários como instalações 2ª, enquanto a instalação inicial de Microsoft 365 Apps geralmente é chamada de 1ª instalação. Para os 1º cenários de instalação, confira as opções de instalação e a melhor maneira de dimensionar a implantação com o tamanho correto.

Este artigo mostra como reduzir consideravelmente os custos de manutenção de longo prazo e melhorar a satisfação do usuário implementando a segunda instalação com pacotes dinâmicos, enxutos e universais para Microsoft 365 Apps.

O desafio

Historicamente, a tarefa de dar suporte a dois cenários de instalação foi resolvida criando um pacote de instalação dedicado para cada um. Normalmente, um administrador combinaria os arquivos de origem necessários (de ~3 gigabytes) com uma cópia da Ferramenta de Implantação do Office (ODT) e um arquivo de configuração adaptado para o cenário.

Mas, especialmente em organizações maiores, muitas vezes você não tem um único conjunto de configuração de Microsoft 365 Apps. Você pode ter uma combinação de canais de atualização, por exemplo, a maioria está no Monthly Enterprise Channel e alguns dispositivos de uso especial estão no Semi-Annual Enterprise Channel. Talvez você esteja atualmente em transição de 32 bits para 64 bits, e você tem que dar suporte a ambas as arquiteturas por algum tempo.

Se você criar uma implantação dedicada, por exemplo, do Language Pack para cada canal e arquitetura no exemplo anterior, você terminará com quatro pacotes: Monthly Enterprise Channel x86, Monthly Enterprise Channel x64, Semi-Annual Enterprise Channel x86, Semi-Annual Enterprise Channel x64. Esta não é uma abordagem sustentável e tem as seguintes desvantagens:

Altos custos de manutenção devidos
- Alto número de pacotes para criar e manter.
- Os arquivos de origem inseridos ficam desatualizados ao longo do tempo e precisam de manutenção.
- Alto consumo de largura de banda durante a implantação, pois o pacote completo de 3 GB é sincronizado com o dispositivo antes do início da instalação real.
Experiência ruim do usuário
- Os usuários precisam entender sua configuração atual e escolher o pacote correspondente no portal de software.
- Tempo de implantação longo, pois os arquivos de origem completa são sincronizados primeiro.
- Se os arquivos de origem inseridos estiverem desatualizados, a instalação fará o downgrade da instalação completa antes que o ciclo de atualização insira e atualize todos os aplicativos novamente.

Então, como você cria pacotes que são menos caros de manter ao longo do tempo e são mais amigáveis ao usuário?

A solução: pacotes dinâmicos, enxutos e universais

Você pode resolve esses problemas implementando pacotes autoajustados, pequenos e universais. Vamos abordar os conceitos básicos antes de mergulhar em cenários de exemplo.

Crie pacotes dinâmicos em que você não codifica nada. Use recursos da Ferramenta de Implantação do Office (ODT) para permitir que os pacotes se ajustem automaticamente aos requisitos:

Use Version=MatchInstalled para evitar atualizações inesperadas e manter o controle da versão instalada em um cliente. Nenhuma codificação dura de um número de build, que fica desatualizada rapidamente.
Use Language=MatchInstalled para instruir, por exemplo, o Visio ou o Project a instalar com o mesmo conjunto de idiomas que o Office já está usando. Não é necessário listá-los ou criar um script que injete os idiomas necessários.

Crie pacotes lean removendo os arquivos de origem dos pacotes. Isso tem vários benefícios:

O tamanho do pacote é menor, de 3 GB para menos de 10 megabytes para o ODT e seu arquivo de configuração.
Em vez de enviar um pacote de instalação de 3 GB para os clientes, você permite que os clientes puxem o que precisam sob demanda da CDN (Rede de Entrega de Conteúdo do Office), o que salva a largura de banda.
- Ao adicionar o Project a uma instalação de Microsoft 365 Apps existente, você precisa baixar menos de 50 megabytes, já que os componentes compartilhados do Office já estão instalados.
- As instalações do Visio normalmente são de 100 a 200 megabytes, com base no número de idiomas, pois os modelos/estêncil são uma parte substancial do download.
- A instalação de ferramentas de revisão normalmente é de 30 a 50 megabytes, contra um pacote de idioma completo, que é de 200 a 300 megabytes.
Um segundo cenário de instalação geralmente é menos frequente, o que reduz a carga de tráfego da Internet, reduzindo o impacto.
Você não precisa atualizar os arquivos de origem sempre que a Microsoft libera novos recursos ou correções de segurança e qualidade.

Crie pacotes universais não codificando coisas como a arquitetura ou o canal de atualização. O ODT corresponderá dinamicamente à instalação existente, de modo que seus pacotes funcionem em todos os canais e arquiteturas de atualização. Em vez de ter quatro pacotes para instalar o Visio, por exemplo, você tem um pacote universal único que funciona em todas as permutações de canais de atualização e arquiteturas.

Deixar de fora o OfficeClientEdition torna seu pacote universal para ambientes x86/x64 mistos.
Deixar de fora O Canal torna seu pacote universal entre os canais de atualização.

Como criar e se beneficiar da criação de pacotes dinâmicos, enxutos e universais

A ideia é não codificar nada no arquivo de configuração, mas sim utilizar a esperteza da Ferramenta de Implantação do Office o máximo possível.

Vamos dar uma olhada em um pacote "clássico" que foi criado para adicionar o Project a uma instalação existente de Microsoft 365 Apps. Temos os arquivos de origem (de ~3 gigabytes) e um arquivo de configuração, que informa explicitamente o que queremos alcançar:

Pacote de exemplo.

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

Quando aplicamos os conceitos de pacotes dinâmicos, enxutos e universais, o resultado seria assim:

Pacote de exemplo lean.

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

Então, o que mudamos, e quais são os benefícios?

Removemos o atributo OfficeClientEdition, pois o ODT corresponderá automaticamente à versão instalada.
- Benefício: o arquivo de configuração agora funciona para cenários x86 e x64.
Removemos o canal pelo mesmo motivo. O ODT corresponderá automaticamente ao canal de atualização já atribuído.
- Benefício I: o pacote funciona para todos os canais de atualização (Canal Atual, Canal Empresarial Mensal, Semi-Annual Enterprise Channel e outros).
- Benefício II: ele também funciona para canais de atualização que você não oferece como TI central. Alguns usuários estão executando o Canal Atual, alguns estão em builds do Insider? Não se preocupe, só funciona.
Adicionamos Version="MatchInstalled", que garante que o ODT instale a mesma versão já instalada.
- Benefício: você está no controle de versões implantadas, sem atualizações inesperadas.
Adicionamos id="MatchInstalled" e TargetProduct para corresponder aos idiomas instalados no momento, substituindo uma lista codificada de idiomas para instalar.
- Benefício I: o usuário tem os mesmos idiomas do Project que já foram instalados para o Office.
- Benefício II: não é necessário solicitar novamente instalações do pacote de idiomas.
- Benefício III: também funciona para idiomas raramente usados que você como administrador central de TI não oferece, o que faz com que os usuários sejam felizes.
Removemos os arquivos de origem. O ODT buscará o conjunto correto de arquivos de origem da CDN do Office bem a tempo.
- Benefício I: o pacote nunca fica desatualizado. Nenhuma manutenção de arquivos de origem é necessária.
- Benefício II: o download é de cerca de 50 megabytes em vez de cerca de 3 GB.

Outro exemplo: adicionar pacotes de idiomas e ferramentas de prova da maneira dinâmica, enxuta e universal

Vamos dar uma breve olhada em outros cenários também, como adicionar pacotes de idiomas e ferramentas de prova. O arquivo de configuração clássico para instalar o German Language Pack pode ter a seguinte aparência:

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

Novamente, esse arquivo de configuração só funcionaria para um cenário específico (o canal de atualização está definido como Monthly Enterprise Channel, 64 bits está instalado). Outros cenários precisariam ser cobertos por arquivos e pacotes adicionais, que geram a complexidade e o custo da propriedade. Corrija isso apenas seguindo a maneira dinâmica, enxuta e universal:

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

Esse arquivo de configuração única funciona em x86/x64 e em todos os canais de atualização, como Canal Atual, Canal Empresarial Mensal, Semi-Annual Enterprise Channel e outros. Portanto, se você quiser oferecer cinco idiomas adicionais em seu ambiente, basta compilar cinco desses pacotes "arquivo de configuração + ODT". Para ferramentas de revisão, basta alterar o ProductID para "ProofingTools".

Criar sua própria configuração

O conceito acima é universalmente aplicável a todas as instalações e produtos baseados em Click-To-Run, desde que o ODT seja usado. Você pode alterar a ID do produto especificada para o cenário. Confira a lista de IDs de produto com suporte para obter mais informações.

Pré-requisitos/anotações

Aqui estão alguns pré-requisitos que você deve encontrar para fazer esse conceito funcionar em seu ambiente e algumas anotações:

Use a Ferramenta de Implantação do Office 16.0.11615.33602 ou posterior para habilitar Version="MatchInstalled" para funcionar.
O ODT deve ser capaz de localizar os arquivos de origem correspondentes na CDN do Office.
Verifique se o contexto que você está usando para executar a instalação pode percorrer o proxy. Para obter detalhes, consulte Office 365 ProPlus Implantação e Diretrizes do Servidor proxy.
Verifique se a conta (usuário ou sistema) usada para instalar os aplicativos pode se conectar à Internet.
Os arquivos de configuração personalizados mostrados anteriormente são bons para instalar os produtos (com a opção /configure), mas não funcionam com a opção /download. Isso é esperado, pois o ODT está faltando alguns detalhes para executar um download (como arquitetura). Para o conceito acima, não há necessidade de baixar os arquivos com antecedência.