Office 365 Required Updates in 1706 Should Not Force Applications to Close
We can not have production applications close automatically.
Revert back to having required Office 365 updates install at reboot by default and make the force closing of applications with optional display/postpone options a separate configurable option which can be selected per deployment (not client policy).
We have phase 1 of the fix in #SCCM 1802 production build that was released today. It will now prompt them that it needs to be rebooted to be patched. We will take a second fix when SCCM & o365 can get a better experience.
Eric Michaud commented
Can what has changed in 1802 be better explained. It's not clear to me how to take advantage of the new features or if I need to submit a new request to better meet our updating needs.
Current documentation regarding 1802 says: "If any Office 365 applications are running during an Office 365 client update enforcement, the Office applications will not be forced to close. Instead, the update install will return as requiring a system restart"
What is "update enforcement"? How do we enforce an update?
What does this mean: "the update install will return as requiring a system restart"?
I would like to see SCCM force the o365 ProPlus updates on a restart of the computer. I do not want to depend on our users to interact with the information bar in order to receive ProPlus updates. At present, if users do not click the information bar to perform the update, the update never gets installed, even during a reboot. There something I am missing as far as configuration goes to force updates but not have ProPlus force applications to close (i.e. do the updates on restart similar to what was done prior to 1610)?
Seriously, this needs to be rethought. There was nothing wrong with the old way, why would you force user intervention on an update like this? Bring back the old way where no was no user interaction or downtime required to apply Office updates.
When will this be fixed? as Martin Jenkins states "if the user clicks on the update, it warns that all Office apps will be closed, but they aren't. Then it requires a restart, then fails to install, but is flagged as Installed. Next Software Updates Cycles then resets it (correctly) to Not Installed, and it goes again, and requires a restart again."
Martin Jenkins commented
That's nice... if the user clicks on the update, it warns that all Office apps will be closed, but they aren't. Then it requires a restart, then fails to install, but is flagged as Installed. Next Software Updates Cycles then resets it (correctly) to Not Installed, and it goes again, and requires a restart again.
I must say, I'm not a fan of this "improvement" at all.
While the 1710 hotfix fixes the forced close issue, we're not seeing the 365 update install during reboot. After reboot and opening up the office apps, you receive a yellow banner that prompts for the update.
So now our users have to reboot and wait, then they have to manually click update within the yellow banner and wait for their office apps to close and re-open.
The person who was coding this "fix" had to know this would not be acceptable. How do these changes make into production? No wonder why new companies are using gmail.
@djam - Assume this is the same fix as in 1710 hotfix 2 which I am pleased to say works as advertised.
Please don't change it again :)
Just found on the systemcenterdudes blog a post for installing 1710 hotfix rollup 2 which addresses this issue.
The MS bulletin - https://support.microsoft.com/en-gb/help/4086143/update-rollup-2-for-system-center-configuration-manager-current-branch says the same.
Its showing up on our ConfigMgr as being available since Feb 28th so looks like I'll be raising a change request tomorrow to get it installed.
It's KB4086143 BTW
Rene Mortensen commented
This behavior is a blocker for us using ConfigMgr to update our Office 365 Pro plus clients. We need somthing that either silent without user interruption like the Office 2013 MSI patches today or with customizable dialogs that can tell the user that we need to update and they should save thier work. like the dialogs the C2R client can show.
Thanks for your feedback, but is there any estimated time for resolution on this issue? It's been months of pain now.
Any ETA. on this one? Seeing the same issues with ConfigMgr 1710.
Richard Yates commented
Yup, doesn't work, how is this so hard? Not like this isn't a new product for Microsoft?
And this article (https://docs.microsoft.com/en-us/sccm/sum/deploy-use/manage-office-365-proplus-updates) which has a section why the notifications won't appear./ Please remove it, nobody wants to read lines containing "might not" or "it's possible". Either it works correctly, or it doesn't.
How is this a thing? Who came up with the logic of force closing apps without any warning?
Todd Miller commented
Thank you for looking into this problem. We are on the cusp of Office 2016 deployment and trying to make a hard choice between MSI and C2R. The only negative for us so far with C2R is the update UX - but it is a big one. Maybe we can live with the solution we've come up with until you at Microsoft develop something better.
We have worked around this problem in the following way. We configure the patch to be mandatory - but way out in the future. We then have a recurring program that runs on clients to detect pending office updates. If the computer has a pending update and there is a user present, we put up a 30 minute countdown on the screen about office updates. If the user doesn't click "postpone" the update happens. It still closes all the Office apps, but at least it is done with some warning and ability to defer. The user gets nagged every day to take the pending updates until they accept them or the program finds a time when the user is not present. It is not a perfect or even good solution - but is far better than closing the users Office apps with no warning. Thankfully, Office apps save recovery data from time to time, but that offers no help to users who get kicked out in the middle of a SykpefB meeting or in the middle of a powerpoint lecture or sales call -- without any warning.
Time to fix this...
Dave Clarke commented
Hi all in the thread. Since this has been marked as complete and does not allow voting I have opened a new thread at https://configurationmanager.uservoice.com/forums/300492-ideas/suggestions/33241015-office-365-required-updates-in-1710-should-not-for
Please open that one and give it a couple Votes to up its urgency. Thanks
Steven Hansen commented
I agree with other commenters. This should not be marked as "Completed" How was this addressed in 1710? Forcing Office 365 apps closed without any warning is unacceptable, even if the update deployment is past the deadline.
Was literally testing this when I looked at this thread. Yep, its not fixed in 1710. Until you are able to get it using the update process built in to O365, PLEASE revert it back to pre-1706 functionality. I'm sure others will agree this is better than we currently have.
Looks like we are going to have to push out a full O365 upgrade app to our clients each month. We have lots of temp sites on 4G links with limited data allowance. This will kill them even with branchcache
Dave Clarke commented
We have the latest version of SCCM (and hotfix) installed on server and clients and are still getting massive complaints from our users that their office programs close on them. This is still not fixed and is a huge issue for us.
Paul VanDenBerg commented
this behavior is still happening on SCCM 1710 (5.0.8577.100). Can you elaborate on how this is fixed? Office documentation on restart behavior only covers through 1706. https://docs.microsoft.com/en-us/sccm/sum/deploy-use/manage-office-365-proplus-updates
How exactly is this addressed @djam? I just updated to 1710 and also updated the SCCM client on my test system, deployed the newest Office 365 update as required and BOOM, all Office applications were force closed before the update. This is unacceptable behavior. :(