Office 365 Deployment Series med MEMCM - Enterprise Deployment Lessons Learned Del 1 - Innehåll

Hej Team, tack för att du läste igenom Office 365 -inlägg, förhoppningsvis vid denna tidpunkt har du ett bra grepp om Office -installationsprocessen, distributionsmetoderna och användarupplevelsen. Jag råkar känna en kille som har installerat Office 365 -distributioner i ett ganska stort företag och stod inför några "möjligheter".

Möjligheter:

  • Uppgradera Office från 2016 till Office 365 och installera endast Access om det tidigare var installerat
  • Under uppgraderingen, upptäck och installera om Visio Standard / Pro och Project Standard / Pro
  • Det mesta av arbetskraften är på VPN, så optimera distributionerna
  • Dela innehåll mellan alla installationer (Var och en av de olika installationstyperna skulle faktiskt använda samma innehålls -id
  • PreCache-innehåll, för att tillåta självbetjäningsanvändare att inte behöva vänta när de klickar på "Installera" i programvarucentret
  • Ge skålmeddelanden till självbetjäning
  • Distribuera alltid kontoret med det senaste innehållet

Påminnelse, skripten jag refererar till är på github

Från de tidigare inläggen kan du se hur vi lyckades rymma de första par kulorna med att upptäcka och installera om olika Office -komponenter under uppgraderingen. Men om jag glasade över det snabbt, bryter jag ner det nu. (o365_install.ps1)

Från bilden av ett segment av skriptet kan du se att skriptet använder en enkel WMI -sökning för att se om Office är installerat. Du kan behöva ändra detta utifrån din egen miljö för att se till att det upptäcker de saker du vill ha.

Baserat på den information vi samlar in senare i skriptet, möjliggör det ytterligare avsnitt i XML för att installera Access, Visio, Project, etc. I den här bilden nedan kan du se hur dessa variabler används för att fylla i XML.

Så nu när vi har fattat det, hur kan vi minska mängden data som går över tråden?

Applikationer vs paket har olika fördelar / nackdelar med innehåll. Paket är lättare att styra och manipulera, med sitt paket -id som inte ändras, och att kunna köra flera program på samma innehåll. Medan en applikation har varje distributionstyp du lägger till har ett unikt innehålls -ID, och den ändras varje gång du uppdaterar innehållet. Så även om du pekar varje distributionstyp till samma innehåll på källresursen måste du ladda ner varje applikationsdistributionstyp som är associerad med programmet innan du installerar lämplig distributionstyp när du distribuerar programmet. Om du skapar flera olika distributionstyper för Office, gissa vad du har laddat ner 2,5 GB per distributionstyp.

Hur bestämde vi oss för att gå tillväga?

  • Vi skapade en enda app för Office 365 för PreCache. Med parametern -PreCache när installationsskriptet anropas tar det nedladdat kontorsinnehåll och kopierar det till en lokal sökväg.
  •   Innehållet i PreCache -appen är Full Office Suite -innehållet
  •   Detekteringsmetod för PreCache är ett powershell -skript. Skriptet kontrollerar CCMCache för nyttolasten och det kontrollerar mappen o365_Cache för setup.exe
  • Sedan skapar vi en installationsapplikation för Microsoft Office 365 Suite (Enterprise Monthly, SACE & SACEP), Access, Visio Standard, Visio Pro, Project Standard, Project Pro
  •   Innehållet för apparna pekar alla på en enda mapp som innehåller tre skript.
  •   Var och en av applikationerna har också PreCache -appen som ett beroende.

PreCache -innehåll:

Innehåller Setup.exe (från Office Deployment Toolkit), installationsskriptet och de nedladdade filerna från Office

Kontorsinstallationsappsinnehåll

Innehåller de tre skripten [Github]

Appdistributionstyp. I Office 365 -appen har distributionstypen Office365 -innehållsappen som ett beroende. Alla andra appar konfigureras på samma sätt som Office 365 -huvudappen, bara genom att skicka en annan installationsparameter och lägga till en detektionsmetod för var och en av de olika programmen.

Var och en av Office -programmen, innehållsmappen = källmapp för installationsskript. Beroende = Office Content App (Microsoft 365 -innehåll)

Så det var så vi löste innehållsproblemet.

Vi konfigurerar en användarsamling baserad på en AD -grupp användare som heter Office 365 Deployment. (Långsamt lägga till användare under vår utrullningsperiod)
Vi distribuerade innehållsprogrammet och konfigurerade en Hidden Required Deployment (ASAP Deadline) på Office 365 Deployment -användarsamlingen.

Vi skapade en REQUIRED & HIDDEN Office 365 ProPlus - Semi Annual Channel -distribution till samma användarsamling. På den användarsamlingen distribuerade vi en baslinje med två CI: er. Ett CI som skulle övervaka Office 365 -innehållsprogrammet, och när det innehållet hade laddats ner, skulle ändra LOCAL -policyn för Office 365 ProPlus -distributionen, så att WMI -egenskaperna flyttas från dolda till synliga, så att det dyker upp i mjukvarucentret. Vi har också aktiverat aviseringar. 2: a CI innehöll en Toast Notification (baserat på [Trevors blogg]), varna användare om att Office 365 -programmet var tillgängligt. Den hade tre knappar, Snooze, Läs mer (Öppnar intern webbplats med mer info), Kom igång, som lanserade appen i programvarucentret. Detta kommer att bloggas mer ingående vid en framtida tidpunkt.

Om det verkar vara lite för mycket arbete, här är min rekommendation: Konfigurera en tillgänglig distribution av Office 365 -applikationen till samma användarsamling. Lägg till användare i slutet av dagen. Helst skulle deras primära enhet börja cacha innehållet (Office Content Application with the Hidden Required Deployment) och slutföra nedladdningen över en natt. Vanligtvis laddas innehållet ner innan en användare går till Software Center för att köra det tillgängliga Office Install -programmet.

Om en användare slog för-cacheminnet (Office Content Application Deployment), när Office-installationen utlöses, på grund av beroendet, skulle appen ladda ner och kopiera de nödvändiga filerna innan Office Installer tillät att installera.

När det gäller att hålla innehållet uppdaterat kör vi ett skript [Github] på månadskadens som laddar ner innehållet och ersätter innehållet. Det är väldigt rakt fram, kör setup.exe med konfigurationsfilen för att ladda ner innehållet, ersätta det som finns, uppdaterar detektionsmetoden med det nya hyttfilnamnet och stöter på innehållet. När innehållet uppdateras skapar det det nya Content ID, den obligatoriska distributionen uppdaterar policyn. nästa applikationsutvärdering misslyckas det med att identifiera eftersom hyttfilens namn har ändrats och det laddar ner och kör skriptet före cache igen. - Om du är intresserad, meddela mig så skapar jag ett detaljerat blogginlägg.

Tack, jag hoppas att du har hittat denna beskrivning av hur ett företag distribuerade Office 365. Kolla in min nästa lektion om att ändra kanaler.

Kolla in de andra inläggen i den här serien:

Företagsdistributionslektioner lärt del 2 - Ändra kanaler

Företagsdistributionslektioner lärt del 3 - Distributioner

Företagsdistributionslektioner lärt del 4 - Baslinje - Toast -aviseringar

Se hur Right Click Tools förändrar hur system hanteras.

Öka produktiviteten direkt med vår begränsade, kostnadsfria Community Edition.

Kom igång med Right Click Tools idag:

Dela detta:

Support

  • Detta fält används för valideringsändamål och ska lämnas oförändrat.

Kontakt

  • Detta fält används för valideringsändamål och ska lämnas oförändrat.
sv_SESwedish