Hey Team, thanks for reading through the Office 365 posts, hopefully at this point you've got a good grasp on the Office Setup Process, the Deployment Methods and the user experience. I happen to know a guy who has setup Office 365 Deployments in a rather large enterprise, and was faced with a few "opportunities".
Reminder, the scripts I'm referencing are on github
From the previous posts, you can see how we managed to accommodate the first couple bullets of detecting and reinstalling different Office Components during the upgrade. But in case I glassed over it quickly, I'll break it down now. (o365_install.ps1)
From the image of a segment of the script, you can see that the script is using a simple WMI Lookup to see if Office is installed. You might need to modify this based on your own environment to make sure it detects the things you want.
Based on the information we collect, later on in the script, it enables additional sections in the XML to install Access, Visio, Project, etc. In this image below, you can see how those variables are being used to populate the XML.
So now that we've got that figured out, how do we reduce the amount of data going over the wire?
Applications vs Packages have different pros / cons for content. Packages are easier to control and manipulate, with their package id that doesn't change, and being able to run several programs on the same content. Whereas with an Application, every deployment type you add has a unique content ID, and it changes every time you update the content. So even if you point each Deployment Type to the same content on the Source Share, when you deploy the Application to a machine, it will have to download each application deployment type associated with the application before installing the appropriate deployment type. If you create several different deployment types for Office, guess what, you just downloaded 2.5 GB per deployment type.
How did we decide to go about this?
Office Install Apps Content
App Deployment Type. Showing the Office 365 App, the Deployment Type has the Office365 Content App as a Dependency. All of the other Apps are setup identically to the Office 365 Main App, just with passing a different install parameter, and adding a detection method for each of the different applications.
So that's how we solved the content issue.
We setup a user collection based on an AD Group of users called Office 365 Deployment. (Slowly adding users throughout our roll-out period)
We deployed the Content Application and setup a Hidden Required Deployment (ASAP Deadline) on the Office 365 Deployment User Collection.
We created a REQUIRED & HIDDEN Office 365 ProPlus - Semi Annual Channel deployment to the same user collection. On that user collection, we deployed a Baseline with 2 CIs. One CI that would monitor the Office 365 Content Application, and once that content had downloaded, would change the LOCAL policy on the Office 365 ProPlus Deployment, flipping the WMI Properties from Hidden to Visible, so it would show up in the software center. We also enabled notifications. The 2nd CI contained a Toast Notification (based on [Trevor's Blog]), alerting users that the Office 365 application was available. It had 3 buttons, Snooze, Learn More (Opens Internal Website with more info), Get Started, which launched the app in the software center. This will be blogged in greater depth at a future time.
If that seems like a bit too much work, here is my recommendation: Setup an Available Deployment of the Office 365 Application to the same user collection. Add users at the end of the day. Ideally, their primary device would start caching the content (Office Content Application with the Hidden Required Deployment), and finish downloading overnight. Typically the content will download before a user would go to Software Center to run the available Office Install Application.
If a user did beat the pre-cache (Office Content Application Deployment), when the Office Install is triggered, because of the dependency, the App would download and copy the required files before allowing the Office Installer to try to install.
As for keeping content updated, we run a script [Github] on monthly cadence that downloads the content and replaces the content. It's very straight forward, runs the setup.exe with the config file to download the content, replace what is there, updates the detection method with the new cab file name, and bump the content. Then as the content is updated, it creates the new Content ID, the Required Deployment updates the policy. next application evaluation, it fails detection because the cab file name changed, and it redownloads and runs the pre-cache script. - If interested, let me know and I'll create a detailed blog post.
Thanks, I hope you found this write up of how one enterprise deployed Office 365. Check out my next lesson learned on Changing Channels.
Check out the other posts in this series: