Office 365 Deployment Series with MEMCM | Deployment Methods
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.
Thanks for making it this far in our Deployment and Maintenance of Office 365 using Microsoft’s Endpoint Manager, Configuration Manager (MEMCM / SCCM) series, now that we have our Office application setup, it’s time to get it deployed, and look into how we can change the channel [Channel on Docs]. Based on how you deploy it, and a setting in the XML file, you’ll see different behavior.
In the XML, the property setting “FORCEAPPSHUTDOWN” will control the behavior during the upgrade. [MS Docs]
Lets talk over a few scenarios and show how this works out.
- FORCEAPPSSHUTDOWN = TRUE
- 1) Required Deployment – Reach Deadline
- 2) Required Deployment – User Initiates Install Before Deadline
- 3) Available Deployment – User Initiates
- FORCEAPPSSHUTDOWN = FALSE
- 4) Required Deployment – Reach Deadline
- 5) Required Deployment – User Initiates Install Before Deadline
- 6) Available Deployment – User Initiates
So believe it or not, only number one provides a different end user experience, all the rest will prompt the user to close the applications, even if it reached the deadline. Let’s walk through a couple.
Assumptions, you’re using the App Model, and you’ve setup the deployment to show in software center, this will be the behavior experienced:
- User Deployment runs at deadline, closes all office apps automatically (no warning) and upgrades / installs Office 365
- & 3. have the same behavior, the application installer launches prompts to close any open office apps. 4,5,6 all share this same behavior too.
So basically the ONLY time it actually force closes the apps, is when it reaches the deadline and triggers automatically. Any other time, it will prompt the end user to close the app and if the user clicks cancel, it throws and error. Remember, when it force closes the app, the is potential for lost work. I’ve confirmed this in my testing, the unsaved documents are gone, not recoverable.
Now let’s see what happens if a user clicks cancel. When you click cancel, you get a generic error, the same error you’d get for some other situations. Now I’m unsure if the exit code is the same, but the message is.
If you find other exit codes, you can update the script to note different codes and provide better feedback in the logs.
Now that we’ve gotten Office 365 installed, lets say you want to take a group of users and change them from the “broad” channel to a faster release channel, like “Targeted” or “Monthly“,
Changing the Office Channel post deployment. [MS Docs] You can check in office which channel it is by going to the Account Node in one of the office Apps.
- Changing a Registry Key [HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Configuration\CDNBaseUrl]
- Using a CI / Baseline [Blog Post – secureinfra.blog] – Note this is good info, but the Channels and Regkeys will be different. I’ll have a an upcoming post with updated materials and scripts in GitHub.
- Group Policy [MS Docs]
- Running the Setup Engine with a XML Config File [MS Docs]
I’m not going to go over the methods here in this post, but check out the next post where I go into details about how I’ve set it up.
Stick around, in my next series, I’m going to cover how “someone” deployed Office 365 at a large enterprise. Lessons learned.
Check out all posts within this series:
Office 365 Deployment Series with MEMCM – Post 1 – Intro & PreReqs
Office 365 Deployment Series with MEMCM – Post 2 – Creating the Office Installer – Simple
Office 365 Deployment Series with MEMCM – Post 3 – Creating the Office Installer – Advanced
Office 365 Deployment Series with MEMCM – Post 5 – Office Updates / ADR