Office 365 Deployment Series with ConfigMgr: Post 4 – Deployment Methods

Office 365 Deployment Series with ConfigMgr

Post 4: Deployment Methods

Thanks for making it this far in our Deployment and Maintenance of Office 365 using Microsoft’s Endpoint Manager, Configuration Manager (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]

XML Settings and Deployment

Let’s talk over a few scenarios and show how this works out:

• FORCEAPPSSHUTDOWN = TRUE
  • Required Deployment – Reach Deadline
  • Required Deployment – User Initiates Install Before Deadline
  • Available Deployment – User Initiates
• FORCEAPPSSHUTDOWN = FALSE
  • Required Deployment – Reach Deadline
  • Required Deployment – User Initiates Install Before Deadline
  • 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. If so, this will be the behavior experienced:

1. User Deployment runs at deadline, closes all office apps automatically (no warning) and upgrades / installs Office 365
2. & 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, there is potential for lost work. I’ve confirmed this in my testing — the unsaved documents are gone, not recoverable.

User Clicks Cancel

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, let’s 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: [HKLMSOFTWAREMicrosoftOfficeClickToRunConfigurationCDNBaseUrl]
• Using a CI / Baseline [Blog Post – secureinfra.blog] – Note this is good info, but the Channels and Regkeys will be different. I’ll have an upcoming post with updated materials and scripts in GitHub.
• Group Policy [MS Docs]
• Running the Setup Engine with an 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.

---

Office 365 Deployment Series with ConfigMgr

1. Office 365 Deployment Series with ConfigMgr – Intro & PreReqs 
2. Office 365 Deployment Series with ConfigMgr – Creating the Office Installer – Simple
3. Office 365 Deployment Series with ConfigMgr – Creating the Office Installer – Advanced
4. Office 365 Deployment Series with ConfigMgr – Deployment Methods – You are Here
5. Office 365 Deployment Series with ConfigMgr – Office Updates / ADR
6. Office 365 Deployment Series with ConfigMgr – Channel Info

Next Series

Microsoft 365 Enterprise Deployment – Lessons Learned

• Part 1 – Content
• Part 2 – Changing Channels
• Part 3 – Deployments
• Part 4 – Baseline – Toast Notifications