Partilhar via

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

  • Artigo

Observação

Criado pelo Rangers do Microsoft 365 Apps, este artigo descreve as práticas comuns observadas nas implementações dos clientes. Recomendamos que avalie a relevância desta orientação para a sua organização e adapte a abordagem conforme necessário.

Enquanto administrador, poderá planear implementar o Microsoft 365 Apps na sua organização. Esta implementação é, muitas vezes, mais do que apenas emitir as Aplicações básicas do Microsoft 365 para dispositivos. Os utilizadores podem precisar de componentes adicionais, por exemplo, pacotes de idiomas, ferramentas de verificação linguística ou produtos adicionais, como o Visio ou o Project. Muitas vezes, referimo-nos a estes cenários como 2.ª instalação, enquanto a instalação inicial do Microsoft 365 Apps é frequentemente denominada 1.ª instalação. Para cenários de 1.ª instalação, veja as opções de instalação e a melhor forma de ajustar o tamanho da sua implementação.

Este artigo mostra-lhe como pode reduzir significativamente os custos de manutenção a longo prazo e melhorar a satisfação do utilizador ao implementar 2ª instalações com pacotes dinâmicos, magros e universais para o Microsoft 365 Apps.

O desafio

Historicamente, a tarefa de suportar cenários de 2.ª instalação foi resolvida através da criação de um pacote de instalação dedicado para cada um. Normalmente, um administrador combinaria os ficheiros de origem necessários (de ~3 gigabytes) com uma cópia da Ferramenta de Implementação do Office (ODT) e um ficheiro de configuração adaptado para o cenário.

No entanto, especialmente em organizações maiores, muitas vezes não tem um único conjunto de configuração do Microsoft 365 Apps. Pode ter uma combinação de canais de atualização, por exemplo, a maioria está no Canal Empresarial Mensal e alguns dispositivos para fins especiais estão no Semi-Annual Canal Empresarial. Talvez esteja a fazer a transição de 32 bits para 64 bits e tenha de suportar ambas as arquiteturas durante algum tempo.

Se criar uma implementação dedicada, por exemplo, do Language Pack para cada canal e arquitetura no exemplo anterior, acabaria por ter quatro pacotes: Via de Atualizações Empresariais Mensais x86, Via de Atualizações Empresariais Mensais x64, Semi-Annual Canal Empresarial x86, Semi-Annual Canal Empresarial x64. Esta não é uma abordagem sustentável e tem as seguintes desvantagens:

  • Custos de manutenção elevados devidos
    • Número elevado de pacotes a criar e manter.
    • Os ficheiros de origem incorporados ficam desatualizados ao longo do tempo e precisam de assistência.
    • Consumo elevado de largura de banda durante a implementação, uma vez que o pacote completo de 3 GB é sincronizado com o dispositivo antes do início da instalação real.
  • Má experiência de utilizador
    • Os utilizadores têm de compreender a configuração atual e escolher o pacote correspondente no portal de software.
    • Tempo de implementação longo, uma vez que os ficheiros de origem completa são sincronizados primeiro.
    • Se os ficheiros de origem incorporados estiverem desatualizados, a instalação mudará para uma versão anterior da instalação completa, antes de o ciclo de atualização iniciar e atualizar todas as aplicações novamente.

Então, como pode criar pacotes que são menos dispendiosos de manter ao longo do tempo e que são mais amigáveis para os utilizadores?

A solução: Pacotes dinâmicos, magros e universais

Pode resolver estes problemas através da implementação de pacotes universais, pequenos e de ajuste autónomos. Vamos abordar os conceitos básicos antes de aprofundarmos os cenários de exemplo.

Crie pacotes dinâmicos onde não codifica nada. Utilize as funcionalidades da Ferramenta de Implementação do Office (ODT) para permitir que os pacotes se ajustem automaticamente aos requisitos:

  • Utilize Version=MatchInstalled para evitar atualizações inesperadas e manter o controlo da versão instalada num cliente. Sem codificação rígida de um número de compilação, que fica desatualizado rapidamente.
  • Utilize Language=MatchInstalled para instruir, por exemplo, o Visio ou o Project a instalar com o mesmo conjunto de idiomas que o Office já está a utilizar. Não é necessário listá-los ou criar um script que injete os idiomas necessários.

Crie pacotes magros ao remover os ficheiros de origem dos pacotes. Isto tem vários benefícios:

  • O tamanho do pacote é menor, de 3 GB para menos de 10 megabytes para o ODT e o respetivo ficheiro de configuração.
  • Em vez de emitir um pacote de instalação de 3 GB para os clientes, permite que os clientes obtenham o que precisam a pedido da Rede de Entrega de Conteúdos (CDN) do Office, que guarda a largura de banda.
    • Quando adiciona o Project a uma instalação existente do Microsoft 365 Apps, tem de transferir menos de 50 megabytes, uma vez que os componentes partilhados do Office já estão instalados.
    • Normalmente, as instalações do Visio são de 100 a 200 megabytes, com base no número de idiomas, uma vez que os modelos/stencils são uma parte substancial da transferência.
    • A instalação de ferramentas de verificação linguística é normalmente de 30 a 50 megabytes, em comparação com um pacote de idiomas completo, que é de 200 a 300 megabytes.
  • Um segundo cenário de instalação é, muitas vezes, menos frequente, o que reduz a carga de tráfego da Internet, reduzindo, em última análise, o impacto.
  • Não tem de atualizar os ficheiros de origem sempre que a Microsoft lançar novas funcionalidades ou correções de segurança e qualidade.

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

  • Deixar de fora o OfficeClientEdition torna o seu pacote universal para ambientes x86/x64 mistos.
  • Sair do Canal torna o seu pacote universal em canais de atualização.

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

A ideia é não codificar nada no ficheiro de configuração, mas sim utilizar o mais inteligente possível da Ferramenta de Implementação do Office.

Vamos ver um pacote "clássico" criado para adicionar o Project a uma instalação existente do Microsoft 365 Apps. Temos os ficheiros de origem (de ~3 gigabytes) e um ficheiro de configuração, que indica explicitamente o que queremos alcançar:

Uma captura de ecrã de um 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, magros e universais, o resultado teria o seguinte aspeto:

Uma captura de ecrã de um pacote de exemplo magro. 

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

Então, o que mudámos, e quais são os benefícios?

  • Removemos o atributo OfficeClientEdition, uma vez que o ODT corresponderá automaticamente à versão instalada.
    • Benefício: o ficheiro de configuração funciona agora 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 Canal Empresarial, entre outros).
    • Benefício II: também funciona para canais de atualização que não oferece como TI central. Alguns utilizadores estão a executar o Canal Atual, outros estão em compilações do Insider? Não se preocupe, só funciona.
  • Adicionámos Version="MatchInstalled", que garante que o ODT irá instalar a mesma versão que já está instalada.
    • Benefício: controla as versões implementadas, sem atualizações inesperadas.
  • Adicionámos Language ID="MatchInstalled" e TargetProduct para corresponder aos idiomas atualmente instalados, substituindo uma lista hard-coded de idiomas a instalar.
    • Benefício I: o utilizador tem os mesmos idiomas do Project que já foram instalados para o Office.
    • Benefício II: não é necessário voltar a pedir instalações do pacote de idiomas.
    • Benefício III: também funciona para idiomas raramente utilizados que o administrador de TI central não oferece, o que faz os utilizadores felizes.
  • Removemos os ficheiros de origem. O ODT irá obter o conjunto correto de ficheiros de origem da CDN do Office imediatamente a tempo.
    • Benefício I: O pacote nunca fica desatualizado. Não é necessária manutenção de ficheiros de origem.
    • Benefício II: a transferência é de cerca de 50 megabytes em vez de cerca de 3 GB.

Outro exemplo: Adicionar pacotes de idiomas e ferramentas de verificação linguística da forma dinâmica, magra e universal

Vejamos também outros cenários, como adicionar pacotes de idiomas e ferramentas de verificação linguística. O ficheiro de configuração clássica para instalar o Language Pack alemão poderá ter o seguinte aspeto:

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

Mais uma vez, este ficheiro de configuração só funcionaria para um cenário específico (o canal de atualização está definido como Via de Atualizações Empresariais Mensais, está instalado 64 bits). Outros cenários teriam de ser abrangidos por ficheiros e pacotes adicionais, o que aumenta a complexidade e o custo de propriedade. Corrija isto ao seguir a forma dinâmica, magra e universal:

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

Este ficheiro de configuração único funciona em x86/x64 e em todos os canais de atualização, como Canal Atual, Via de Atualizações Empresariais Mensais, Semi-Annual Canal Empresarial, entre outros. Por isso, se quiser oferecer cinco idiomas adicionais no seu ambiente, basta criar cinco destes pacotes de "ficheiro de configuração + ODT". Para ferramentas de verificação linguística, basta alterar o ProductID para "ProofingTools".

Criar a sua própria configuração

O conceito acima é universalmente aplicável a todas as instalações e produtos baseados em Clique-e-Use, desde que o ODT seja utilizado. Pode alterar o ID do Produto especificado para o seu cenário. Consulte a lista de IDs de Produto suportados para obter mais informações.

Pré-requisitos/Notas

Seguem-se alguns pré-requisitos que tem de cumprir para que este conceito funcione no seu ambiente e algumas notas:

  • Utilize a Ferramenta de Implementação do Office 16.0.11615.33602 ou posterior para ativar Version="MatchInstalled" para funcionar.
  • O ODT tem de conseguir localizar os ficheiros de origem correspondentes na CDN do Office.
  • Certifique-se de que o contexto que está a utilizar para executar a instalação pode atravessar o proxy. Para obter detalhes, consulte Orientação para Implementação e Servidor Proxy do Office 365 ProPlus.
  • Certifique-se de que a conta (utilizador ou sistema) utilizada para instalar as aplicações pode ligar-se à Internet.
  • Os ficheiros de configuração personalizados apresentados anteriormente são adequados para instalar os produtos (com o comutador /configure), mas não funcionam com o comutador /download. Isto é esperado, uma vez que faltam alguns detalhes ao ODT para efetuar uma transferência (como a arquitetura). Para o conceito acima, não é necessário transferir os ficheiros previamente.