Creare pacchetti dinamici, snelli e universali per Microsoft 365 Apps

Nota

Creato dalla Microsoft 365 Apps Rangers, questo articolo descrive le procedure comuni osservate nelle implementazioni dei clienti. È consigliabile valutare la rilevanza di queste linee guida per l'organizzazione e adattare l'approccio in base alle esigenze.

In qualità di amministratore, è possibile pianificare la distribuzione di Microsoft 365 Apps nell'organizzazione. Una distribuzione di questo tipo spesso non è solo il push dei Microsoft 365 Apps di base nei dispositivi. Gli utenti potrebbero avere bisogno di componenti aggiuntivi, ad esempio Language Pack, strumenti di correzione o prodotti aggiuntivi come Visio o Project. Spesso si fa riferimento a questi scenari come seconda installazione, mentre l'installazione iniziale di Microsoft 365 Apps è spesso chiamata prima installazione. Per gli scenari di installazione 1st, esaminare le opzioni di installazione e il modo migliore per ridimensionare correttamente la distribuzione.

Questo articolo illustra come ridurre notevolmente i costi di manutenzione a lungo termine e migliorare la soddisfazione degli utenti implementando le installazioni 2nd con pacchetti dinamici, snelli e universali per Microsoft 365 Apps.

Problema

In passato, l'attività di supporto degli scenari di installazione 2nd veniva risolta creando un pacchetto di installazione dedicato per ognuno di essi. In genere, un amministratore combina i file di origine necessari (di circa 3 gigabyte) con una copia di Office Deployment Tool (ODT) e un file di configurazione personalizzato per lo scenario.

Ma, soprattutto nelle organizzazioni più grandi, spesso non si dispone di un singolo set di configurazione di Microsoft 365 Apps. È possibile che si disponga di una combinazione di canali di aggiornamento, ad esempio la maggior parte si trova in Monthly Enterprise Channel e alcuni dispositivi speciali si trova in Semi-Annual Enterprise Channel. È possibile che si stia eseguendo la transizione da 32 bit a 64 bit e che sia necessario supportare entrambe le architetture per un certo periodo di tempo.

Se si crea una distribuzione dedicata, ad esempio Language Pack per ogni canale e architettura nell'esempio precedente, si finirà con quattro pacchetti: Monthly Enterprise Channel x86, Monthly Enterprise Channel x64, Semi-Annual Enterprise Channel x86, Semi-Annual Enterprise Channel x64. Questo non è un approccio sostenibile e presenta gli svantaggi seguenti:

• Costi di manutenzione elevati dovuti
  • Numero elevato di pacchetti da creare e gestire.
  • I file di origine incorporati vengono obsoleti nel tempo e necessitano di manutenzione.
  • Utilizzo elevato della larghezza di banda durante la distribuzione, poiché il pacchetto completo da 3 GB viene sincronizzato con il dispositivo prima dell'avvio dell'installazione effettiva.
• Esperienza utente non valida
  • Gli utenti devono comprendere la configurazione corrente e scegliere il pacchetto corrispondente dal portale software.
  • Tempo di distribuzione lungo come file di origine completi vengono sincronizzati per primi.
  • Se i file di origine incorporati non sono aggiornati, l'installazione eseguirà il downgrade dell'installazione completa, prima che il ciclo di aggiornamento inizi e aggiorni nuovamente tutte le app.

Quindi, come si creano pacchetti meno costosi da gestire nel tempo e più facili da usare?

La soluzione: pacchetti dinamici, snelli e universali

È possibile risolvere questi problemi implementando pacchetti autoregolazione, piccoli e universali. Verranno ora illustrati i concetti di base prima di esaminare gli scenari di esempio.

Creare pacchetti dinamici in cui non si esegue il codice rigido. Usare le funzionalità di Office Deployment Tool (ODT) per consentire ai pacchetti di adattarsi automaticamente ai requisiti:

• Usare Version=MatchInstalled per evitare aggiornamenti imprevisti e mantenere il controllo della versione installata in un client. Nessun codice hardcode di un numero di build, che diventa obsoleto rapidamente.
• Usare Language=MatchInstalled per indicare, ad esempio, Visio o Project da installare con lo stesso set di lingue già in uso in Office. Non è necessario elencarli o compilare uno script che inserisce i linguaggi necessari.

Creare pacchetti snelli rimuovendo i file di origine dai pacchetti. Questo offre diversi vantaggi:

• Le dimensioni del pacchetto sono inferiori, da 3 GB a meno di 10 megabyte per ODT e il relativo file di configurazione.
• Invece di eseguire il push di un pacchetto di installazione da 3 GB nei client, è possibile consentire ai client di eseguire il pull su richiesta da Office Content Delivery Network (CDN), risparmiando così la larghezza di banda.
  • Quando si aggiunge Project a un'installazione di Microsoft 365 Apps esistente, è necessario scaricare meno di 50 megabyte, poiché i componenti condivisi di Office sono già installati.
  • Le installazioni di Visio sono in genere da 100 a 200 megabyte, in base al numero di lingue, in quanto i modelli/stencil sono una parte sostanziale del download.
  • L'installazione degli strumenti di correzione è in genere di 30-50 megabyte, rispetto a un Language Pack completo, che è di 200-300 megabyte.
• Un secondo scenario di installazione è spesso meno frequente, il che riduce il carico del traffico Internet, riducendo in definitiva l'impatto.
• Non è necessario aggiornare i file di origine ogni volta che Microsoft rilascia nuove funzionalità o correzioni di sicurezza e qualità.

Creare pacchetti universali non codificando in modo rigido elementi come l'architettura o il canale di aggiornamento. ODT corrisponderà dinamicamente all'installazione esistente, in modo che i pacchetti funzionino in tutti i canali e le architetture di aggiornamento. Invece di avere quattro pacchetti per installare Visio, ad esempio, si dispone di un singolo pacchetto universale che funziona in tutte le permutazioni di canali e architetture di aggiornamento.

• Se si esce da OfficeClientEdition , il pacchetto è universale per gli ambienti x86/x64 misti.
• L'uscita dal canale rende il pacchetto universale tra i canali di aggiornamento.

Come creare e trarre vantaggio dalla creazione di pacchetti dinamici, snelli e universali

L'idea è quella di non hardcodedare nulla nel file di configurazione, ma di utilizzare invece l'intelligenza dello strumento di distribuzione di Office il più possibile.

Verrà ora esaminato un pacchetto "classico" creato per aggiungere Project a un'installazione esistente di Microsoft 365 Apps. Sono disponibili i file di origine (di circa 3 gigabyte) e un file di configurazione, che indica in modo esplicito cosa si vuole ottenere:

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

Quando si applicano i concetti di pacchetti dinamici, snelli e universali, il risultato sarà simile al seguente:

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

Quindi cosa abbiamo cambiato, e quali sono i vantaggi?

• È stato rimosso l'attributo OfficeClientEdition, perché ODT corrisponderà automaticamente alla versione installata.
  • Vantaggio: il file di configurazione ora funziona sia per gli scenari x86 che x64.
• Il canale è stato rimosso per lo stesso motivo. ODT corrisponderà automaticamente al canale di aggiornamento già assegnato.
  • Vantaggio I: il pacchetto funziona per tutti i canali di aggiornamento (Canale corrente, Canale Enterprise mensile, Semi-Annual Canale Enterprise e altri).
  • Vantaggio II: funziona anche per i canali di aggiornamento che non vengono offerti come IT centrale. Alcuni utenti eseguono Current Channel, altri sono in build Insider? Non preoccuparti, funziona.
• È stato aggiunto Version="MatchInstalled", che garantisce che ODT installerà la stessa versione già installata.
  • Vantaggio: si ha il controllo delle versioni distribuite, senza aggiornamenti imprevisti.
• Sono stati aggiunti Language ID="MatchInstalled" e TargetProduct in modo che corrispondano alle lingue attualmente installate, sostituendo un elenco hardcoded delle lingue da installare.
  • Vantaggio I: l'utente ha le stesse lingue per Project già installate per Office.
  • Vantaggio II: non è necessario richiedere di nuovo le installazioni del Language Pack.
  • Vantaggio III: funziona anche per le lingue usate raramente che l'amministratore IT centrale non offre, il che rende felici gli utenti.
• Sono stati rimossi i file di origine. ODT recupererà il set corretto di file di origine dalla rete CDN di Office appena in tempo.
  • Vantaggio I: il pacchetto non diventa mai obsoleto. Non è necessaria alcuna manutenzione dei file di origine.
  • Vantaggio II: il download è di circa 50 megabyte anziché di circa 3 GB.

Un altro esempio: Aggiungere Language Pack e strumenti di correzione in modo dinamico, snello e universale

Verranno ora esaminati anche altri scenari, ad esempio l'aggiunta di Language Pack e strumenti di correzione. Il file di configurazione classico per installare il Language Pack tedesco potrebbe essere simile al seguente:

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

Anche in questo caso, questo file di configurazione funziona solo per uno scenario specifico (il canale di aggiornamento è impostato su Canale Enterprise mensile, è installato a 64 bit). Altri scenari devono essere coperti da file e pacchetti aggiuntivi, che consentono di aumentare la complessità e il costo di proprietà. Risolvere il problema semplicemente andando nel modo dinamico, snello e universale:

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

Questo singolo file di configurazione funziona in x86/x64 e in tutti i canali di aggiornamento, ad esempio Canale corrente, Canale Enterprise mensile, Semi-Annual Enterprise Channel e altri. Quindi, se si vogliono offrire cinque linguaggi aggiuntivi nell'ambiente, è sufficiente compilare cinque di questi pacchetti "file di configurazione + ODT". Per gli strumenti di correzione, è sufficiente modificare ProductID in "ProofingTools".

Creare una configurazione personalizzata

Il concetto precedente è universalmente applicabile a tutte le installazioni e i prodotti basati su click-to-run, purché venga usato odt. È possibile modificare l'ID prodotto specificato nello scenario. Per altre informazioni, vedere l'elenco degli ID prodotto supportati .

Prerequisiti/note

Ecco alcuni prerequisiti che è necessario soddisfare per far funzionare questo concetto nell'ambiente e alcune note:

• Usare Lo strumento di distribuzione di Office 16.0.11615.33602 o versione successiva per abilitare Version="MatchInstalled" per il funzionamento.
• L'ODT deve essere in grado di individuare i file di origine corrispondenti nella rete CDN di Office.
• Assicurarsi che il contesto usato per l'esecuzione dell'installazione possa attraversare il proxy. Per informazioni dettagliate, vedere Office 365 ProPlus Deployment and Proxy Server Guidance (Linee guida per la distribuzione e il server proxy).
• Assicurarsi che l'account (utente o sistema) usato per installare le app possa connettersi a Internet.
• I file di configurazione personalizzati illustrati in precedenza sono adatti per l'installazione dei prodotti (con l'opzione /configure), ma non funzionano con l'opzione /download. Questa operazione è prevista, poiché all'ODT mancano alcuni dettagli per eseguire un download,ad esempio l'architettura. Per il concetto precedente, non è necessario scaricare i file in anticipo.