Office 365 Pro Plus - Closes All Office apps when updates are deployed

[Christopher Hadwin]

We are currently testing Office 365 Pro Plus in hopes to replace the Office 2016 MSI install.  We have Office 365 Pro Plus deployed as follows :

<Configuration>
<Add OfficeClientEdition="32" Channel="Current" Version="16.0.8625.2132" OfficeMgmtCOM="True">
<Product ID="O365ProPlusRetail">
<Language ID="en-us" />
<ExcludeApp ID="Publisher" />
<ExcludeApp ID="Groove" />
<ExcludeApp ID="OneDrive" />
</Product>
</Add>
<Display AcceptEULA="TRUE" />
<Property Name="SharedComputerLicensing" Value="0" />
<Property Name="PinIconsToTaskbar" Value="FALSE" />
<Property Name="AUTOACTIVATE" Value="1" />
<Property Name="ForceAppShutdown" Value="FALSE" />
</Configuration>

We have updates being pushed through configuration manager.  The updates get passed the machine and when they go to install the updates, it forces all office applications to close without any notification to the user.  This is problematic esp since we are a SfB house.  We have a SCCM DSE that i've ran this through and we've troubleshot this for a few days but we can't really find a way to either have the updates installed WITHOUT closing the apps or notify the user that the applications need to close in order to apply the update.  

Has anyone see this behavior before?  Any suggestions to get the outcome that we desire? 

[#2]

Interesting, I can see you have not enabled ForceAppShutdown. As a troubleshoot step can you try hashing out that line to see if that makes any difference.

<-- <Property Name="ForceAppShutdown" Value="FALSE" /> -->

Also I can see you dont have any DisplayLevel defined so many update your AcceptEULA line to look like this.

<Display Level="Full" AcceptEULA="TRUE" /> 

[#3]

Thanks for the reply Andrew.  I have tried it using with and without the ForceAppShutdown=true line in it. Matter of fact, we've first found this issue without that line in the config.xml file.  

I will update the display level in the config.xml file and try it again.  Thanks for the suggestion. 

[#4]

Any luck with this?

[#5]

We have a ticket open about this, our TAM is involved and our SCCM DSE is involved.  If/when we find a resolution, i'll be happy to share it on here.  

[#6]

Hi Christopher - interesting bug you're running into. Would it be possible for you to run a small scale (~1-5 machine) test for me? You can force call the Office update mechanism and then specify during that call to not force apps to shutdown, I wonder if that could potentially resolve the issue you're seeing. It wouldn't be a fix, but at least can give us more detail into what's happening

https://docs.microsoft.com/en-us/deployoffice/best-practices/best-practices-channel-management

See specifically the section "Use OfficeC2RClient.exe" for the variables. If you know there's an Office update available, just run it with your normal experience + forceappshutdown = false and see what happens. You can even do this on a VM or test machine that's configured the same as your normal ConfigMgr devices

[#7]

I can give this a shot. According to our DSE, there is a current bug associated with this issue.

If a user runs the updates via software center prior to the deadline, the patching happens as expected. It prompts the user to shut down any running office applications. The issue we are running into is when the deadline for the patch is met, it forces the Office applications to close without any warnings to the user.

Are you wanting me to do something like this:

"%Program Files%\\Common Files\\Microsoft Shared\\ClicktoRun\\OfficeC2RClient.exe" /update user updatepromptuser=false forceappshutdown=false displaylevel=true updatetoversion=16.0.8827.2179 (this build is from January 30th).

[#8]

@Christopher Hadwin has this been any development, we are experiencing the same issue effecting hundreds of clients.

[#9]

@Rob Fuller, After bringing this to our SCCM DSE, he found that this was hardcoded within SCCM and was being changed in a newer build of SCCM.  I believe 1806 or even 1810 might have included the change.  Since then, we have not had any issues with Office Pro Plus clients force closing when updates are installed.  It behaves very similarly to how the MSI version of Office behaves when installing updates.

update: the last couple of Office 365 patches delivered by SCCM provides a prompt that office applications need to close to apply updates.  Once updates are finished applying, the office applications re-open.  

[#10]

@Christopher Hadwin and community, I recently blogged on this topic.  It discusses end user behavior and workflow.. just scroll down to the SCCM section.  If there is something you would like to see added, let me know and I'll update in FAQ

Understanding Office 365 ProPlus Updates for IT Pros (CDN vs SCCM)

[#11]

Thanks for the reply and I had a read of your blog post.
I'm delivering updates via the CDN however all my student users are complaining Office is closing without notice or warnings losing all there work. I've yet to see this behaviour myself but I've had many reports from teachers seeing the issue first hand.
What on earth could be causing this behaviour, I want to allow updates but unless I can control the behaviour I can't.
Any advice greatly received.

[#12]

@Rob Fuller A few suggestions:

1. If you suspect there is a custom script calling officec2rclient.exe out of band then use process monitor with filter for process name officec2rclient.exe + drop filtered events to monitor and trap the event to understand who the caller is and turn off the script.

Download latest ADMX

2. You can turn on "Delay downloading and installing updates for Office".  This is basically N+Days from Patch Tuesday, for example 5.  Roughly five days after build is released updates will be installed. Make the difference in days end up on a weekend.

3. You can turn on Update Deadline. Get buy in from customer on a maintenance window like weekend where installation will take place and users get series of notifications prior to change.

4. Integrate with SCCM with standard Software Update Workflow with restart notifications and so forth.  Most customers I speak with include Windows and Office Updates in the same software deployment so there is a single reboot for maintenance window.

5. Make sure this is set or not present, can't be 1. This suppresses the bizbar notifying the user of pending change

HKLM\SOFTWARE\Policies\Microsoft\office\16.0\common\officeupdate
"hideupdatenotifications"=dword:00000000

[#13]

@DaveGuenthner Thanks I shall work though those suggestions. Do you know if the scheduled task Office Automatic Updates 2.0, if I change that via GPP to not run at user logon but maybe after hours or shutdown that would stop the updates installing in 'business hours'?

[#14]

@Rob Fuller Modification of the trigger of Office Automatic Updates is not supported, so I can't support that suggestion.  For example, there is a feature to apply updates in CDN scenario which computer is detected to be IDLE which would no longer function.  

My suggestion is setup a few test VMs and evaluate GPOs in thread mentioned earlier to get a sense of the normal notification workflow.  Additionally, if it wasn't mentioned earlier.. if a new Office build is staged but cannot be installed because Office program is open, by default Office registers a service called "Microsoft Office Click-to-Run Service" that will apply the update on any computer startup. The idea is to apply the update prior to CTRL + ALT + DEL because we know the first thing user will do is launch Office once they reach desktop.  You may be able to also resolve through combination of deadline + computer restart during agreed upon maintenance window. (This is what SCCM does in effect)

[#15]

@DaveGuenthner @Christopher Hadwin You can recreate the configuration file to point to a specific update location. (AKA an Office folder that is manually updated by you / company) You can configure an XML file at https://config.office.com . I made an example for you to look at below.  It is the text in Red.
<Configuration ID="9ec530f3-7a38-4a08-a125-fc673c704fba">
<Add OfficeClientEdition="64" Channel="Targeted" ForceUpgrade="TRUE">
<Product ID="O365ProPlusRetail">
<Language ID="MatchOS" />
<ExcludeApp ID="Groove" />
<ExcludeApp ID="OneNote" />
<ExcludeApp ID="Publisher" />
</Product>
</Add>
<Property Name="SharedComputerLicensing" Value="0" />
<Property Name="PinIconsToTaskbar" Value="FALSE" />
<Property Name="SCLCacheOverride" Value="0" />
<Property Name="AUTOACTIVATE" Value="0" />
<Property Name="FORCEAPPSHUTDOWN" Value="FALSE" />
<Property Name="DeviceBasedLicensing" Value="0" />
<Updates Enabled="FALSE" UpdatePath="\\server\shared" />
<Display Level="Full" AcceptEULA="TRUE" />
<Logging Level="Off" />
</Configuration>

[#16]

@DBarnhart out of interest if I installed the Office application with the following setting

<Property Name="FORCEAPPSHUTDOWN" Value="TRUE" /> 

does this only apply to the installation of Office or does this continue to updates as well?

I will test out some of the suggestions above and report back, thank you all.

[#17]

@DBarnhart Thanks for the suggestion.  My take is to never use a on-premises file share because it has so many pitfalls. (IT Pro has to download all content and mirror CDN and when you consider all the different channels and architecture combinations cost of ownership is too high in my opinion)  Also, for customers who use SCCM, this breaks it due to UpdatePath having priority.  When possible use CDN or SCCM only.

[#18]

@Rob Fuller FORCEAPPSHUTDOWN is used only during install scenario to close legacy click-to-run applications.  Remember, there was an older version of C2R based on Office 2013.. since deprecated and gone.  This parameter is not relevant to Update scenario.

[#19]

FORCEAPPSHUTDOWN" Value="TRUE" will force close office apps while install / update process is being done.

[#20]

In https://config.office.com it will show you the option to add an exception for your SCCM or CDN connections.