Office 365 Deployment with MEMCM – Lessons Learned Part 1
Receive notification right in your inbox whenever new content like this is released & sign up for our email list!
We’ll send you the latest updates, how-to’s, and solutions to empower you at every endpoint.
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 set up Office 365 Deployments in a rather large enterprise and was faced with a few “opportunities”.
- Upgrade Office from 2016 to Office 365 and only install Access if it was previously installed
- During Upgrade, Detect and Reinstall Visio Standard / Pro and Project Standard / Pro
- Most of the workforce is on VPN, so optimize deployments
- Share Content between all Installs (Each one of the various install types would actually use the same content id
- PreCache content, to allow Self-Service users to not have to wait when they click “Install” in the software center
- Provide Toast Notifications to Self-Service
- Always deploy office using the latest content
Reminder, the scripts I’m referencing are on GitHub
From the previous posts, you can see how we managed to accommodate the first couple of bullets of detecting and reinstalling different Office Components during the upgrade. But in case I glossed 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?
- We created a single App of Office 365 for PreCache. Using the -PreCache parameter when the install script is called, it takes the downloaded office content and copies it to a local path.
- Content for the PreCache App is the Full Office Suite Content
- The detection method for the PreCache is a PowerShell script. The script checks the CCMCache for the Payload, and it checks the o365_Cache folder for the setup.exe
- Then we create an Install Application for Microsoft Office 365 Suite (Enterprise Monthly, SACE & SACEP), Access, Visio Standard, Visio Pro, Project Standard, Project Pro
- Content for the Apps all point to a single folder that contains 3 scripts.
- Each of the Applications also has the PreCache App set as a dependency.
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 set up identically to the Office 365 Main App, just by 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 set up 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 set up 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 been 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), and 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 a monthly cadence that downloads the content and replaces the content. It’s very straightforward, run the setup.exe with the config file to download the content, replace what is there, update 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, and 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:
Enterprise Deployment Lessons Learned Part 2 – Changing Channels
Enterprise Deployment Lessons Learned Part 3 – Deployments
Enterprise Deployment Lessons Learned Part 4 – Baseline – Toast Notifications