Systems Management
Lessons Learned from Microsoft 365 Deployment with ConfigMgr: Part 1
Topics: Systems Management
Lessons Learned from Microsoft 365 Deployment with ConfigMgr
Part 1
Hey Team, thanks for reading through the Microsoft 365 Deployment Series. 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 Microsoft 365 Deployments in a rather large enterprise and was faced with a few “opportunities.”
Microsoft 365 Deployment Lessons and 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 Microsoft 365 Deployment series, you can see how we managed to accommodate the detection and reinstallation of different Office Components during the upgrade. But in case I glossed over it quickly, I’ll break it down now too. (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.
Data Management
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 and cons for content. Packages are easier to control and manipulate, with their package id that doesn’t change while also 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.
Our Solution
How did we decide to go about this?
- We created a single App of Microsoft 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.
PreCache Content:
Office Install Apps Content:
App Deployment Type. Showing the Microsoft 365 App, the Deployment Type has the Microsoft 365 Content App as a Dependency. All of the other Apps are set up identically to the Microsoft 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.
User Collections
We set up a user collection based on an AD Group of users called Microsoft 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 Microsoft 365 Deployment User Collection.
We created a REQUIRED & HIDDEN Microsoft 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 Microsoft 365 Content Application, and once that content had been downloaded, would change the LOCAL policy on the Microsoft 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 Microsoft 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.
My Recommendation
If that seems like a bit too much work, here is my recommendation: Setup an Available Deployment of the Microsoft 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
- 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.
Conclusion
If you found this write-up explaining how one enterprise deployed Microsoft 365, check out my next lesson learned on Changing Channels.
Lessons Learned from Microsoft 365 Deployment with ConfigMgr
After sharing my series on deploying Microsoft 365 with ConfigMgr, this follow up series details lessons learned by “someone” during a recent large-scale deployment.
