none
Pushing Office 365 C2R updates through SCCM 1610 causes Office applications to close unexpectedly on client PCs

    Question

  • Yesterday I deployed Office 365 client update Deferred Channel build 1605-9 32 bit to my pilot group for testing.  We have just updated on SCCM to build 1610.  My test machine had Outlook and Onenote open and running.  The software update deployment ran right on schedule but to my surprise forced all the running office applications on my PC to close without warning.  This was not the behavior in the past when deploying Office 365 updates through SCCM, where it would instead prompt for a machine reboot to complete the install if applications were running.  Is this now considered expected behavior, and if so what would be the recommendation for deploying Office 365 updates via SCCM without impacting end users?
    Thursday, December 15, 2016 4:17 PM

Answers

  • I have installed hotfix 4010155 and deployed the agent update to my clients.  I then created a software update group for the 2/2017 deferred branch build for O365 Pro Plus version 1609 build 7369.2118 and pushed to my test machine.  I had Outlook and Excel open and the update installed smoothly and silently, with no forced close of either application.  After the update completed I received a reboot notification from the software update agent as usual.  Looks like this issue has been resolved in this latest SCCM hotfix.
    • Marked as answer by Ari_P Tuesday, March 7, 2017 10:45 PM
    Tuesday, March 7, 2017 10:43 PM

All replies

  • anything relevant in the client-side logfiles (either ccm logs or c2r logs) ?

    e.g.: was the forcecloseapps flag set ?


    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Thursday, December 15, 2016 8:38 PM
  • Thanks for the reply.  I don't see anything interesting in the ccm logs in regards to this update.  It doesn't appear to be in the wuahandler log at least - not sure if it gets logged elsewhere.  I do see where my office apps were shut down in the c2r log in my %temp% directory.  Thats interesting you mention the "forceappshutdown" flag.  We do have that set in the original configuration.xml we use for deployment.  I'm not aware that this value could have an impact during a SCCM software update though.
    Friday, December 16, 2016 1:27 AM
  • The WUA and thus the wuahandler.log have nothing to do with Office 365 updates. Office 365 updates are installed by the c2r client and thus do adhere to and use whatever you have configured for Office 365 and thus that flag you've called out may be causing this.


    Jason | http://blog.configmgrftw.com | @jasonsandys

    • Proposed as answer by Ant_G Friday, January 6, 2017 9:51 AM
    • Unproposed as answer by Ari_P Wednesday, January 25, 2017 5:30 PM
    Friday, December 16, 2016 3:55 AM
  • Hi Jason- thank you for the reply!  Love your blog. We are still using your configmgr startup script, it works great :)

    I'll spin up a test machine where office is installed without the "forcecloseapps" flag to see if it makes a difference and I'll report back.  If it does I'd be curious how to reverse this on our existing machines, I don't see anything relevant in the registry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\Configuration

    Friday, December 16, 2016 4:27 PM
  • Hi,

    I'm having exactly the same issue. The Office apps close down and open again without any data loss.

    Since I've updated to SCCM 1610 (last week) I've just deployed the last patchday of Office 365 (2016). (deferred channel 1605-10 32bit and first release deferred channel 1609-8 32bit)

    Some of my clients (about 10) are in the first release for deferred channel and the rest (currently about 1000) are in the deferred channel.

    In "C:\Windows\Temp" I was able to find a "ForceShutdown:true" in a log.

    Before the update to SCCM 1610 the Office apps haven't closed during the update.

    If you have any news to this topic, please let me know. (also if it's not the same behavior for you)

    Thanks in advance.


    • Edited by Pippone2810 Tuesday, January 24, 2017 6:50 AM add version of update which I've applied
    Tuesday, January 24, 2017 6:45 AM
  • Hi, we experience exactly the same issue as described by lichen8686 and Pippone2810. I've opened a case for it and do not have a solution yet: [REG:117010615141652] ConfigMgr 1610 changed Forced Shutdown behavior O365 Updates

    In December you upgraded your environment to ConfigMgr 1610. Since then you experience different behavior when updating clients with O365 updates. No reboot message anymore, but the update is forcibly closing apps and is doing the update on a way that the user is not available to use Office anymore.

    You expect that the logged on user is give a message that the computer has been updated and needs to be restarted. And given the option to restart directly or postpone for another 4 hours.

    With the new configmgr client (5.00.8458.1007) the O365 update forcibly closes all Office apps without notice. The user cannot start any Office apps, because the message "Office is busy, we're updating" starts. When the user waits a while, they can start the apps again. After the update there is no message to reboot the computer.

    If you test the same update on a ConfigMgr 1606 client (5.00.8412.1307) the O365 update works as expected. A message that software is installed, but a reboot is needed.

    In the O365 installation/update log file we see different information if we compare the O365 update with both ConfigMgr Clients.

    ConfigMgr 1610 client:
    "Start loading UPDATE scenario"

    "Starting Process Killer: ShowUI (false), ForceAppShutdown (true), LiveUpdate (false)"

     

    ConfigMgr 1606 client:

    "Start loading UPDATE scenario"

    Starting Process Killer: ShowUI (false), ForceAppShutdown (false), LiveUpdate (false)

     

    Registries:

    ConfigMgr 1610 client:

    HKLM\Software\Microsoft\Office\ClickToRun\UPDATE\

    "ForceShutdown" REG_SZ "TRUE"

     

    ConfigMgr 1606 client:

    That specific "ForceShutdown" string does not exist or is not created by the O365 update itself!

    when I have news, I will let you know.

    Wednesday, January 25, 2017 1:18 PM
  • Thank you so much for the info Pippone2810 and GvdWakker.  I got pulled away from troubleshooting this and was about to jump back in to the process. It's good to hear I'm not alone.  Hopefully a patch will be released soon to correct this behavior.  In the meantime we have withheld our Office 365 client updates to avoid end user disruption.
    Wednesday, January 25, 2017 5:24 PM
  • I received an answer, and not the one we hoped for:

    ============================================
    Cause:
    By design behavior for SCCM 1610 clients.

    Resolution:
    We have raised a DCR (Design Change Request) to Product Group in order to change this behavior in a future SCCM version release.
    Please note that administratively a DCR is managed as a bug, meaning that all the time invested on this incident will be free of charge. (non-decremented from your contract with Microsoft)

    You can also use the UserVoice platform to raise a request related to this subject. Product Group respond often to UserVoice’s requests
    ============================================

    If a fix is being found, the 1706 release is the first release where it possible will be available.
    There is no nice workaround available, other than use the Application model to update the clients.

    It worked for a few months perfectly, and now it's a nasty user experience where we cannot patch the product silently.
    Someone already made a user voice: Cannot add a hyperlink, because I'm not verified yet. Complete title on the uservoice: Wants to get display notifcation message in clients to close any opened Office 365 apps while updates installation started 


    • Edited by GvdWakker Monday, January 30, 2017 2:55 PM added uservoice
    Monday, January 30, 2017 2:50 PM
  • https://configurationmanager.uservoice.com/forums/300492-ideas/suggestions/17853118-wants-to-get-display-notifcation-message-in-client

    just upvoted this myself


    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Monday, January 30, 2017 8:04 PM
  • it's also logged on connect

    https://connect.microsoft.com/ConfigurationManagervnext/Feedback/Details/3119724


    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Monday, January 30, 2017 8:07 PM
  • Thank you DonPick for posting both links. I cannot see the connect page, as I do not have any rights there. Hoping for a fix soon!
    Monday, January 30, 2017 8:56 PM
  • Thank you DonPick for posting both links. I cannot see the connect page, as I do not have any rights there. Hoping for a fix soon!

    you should be able to register for Connect using this: https://connect.microsoft.com/ConfigurationManagervnext/InvitationUse.aspx?ProgramID=4346&InvitationID=VNXO-DFPW-G6HD

    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Tuesday, January 31, 2017 9:11 AM
  • Thank you DonPick for posting both links. I cannot see the connect page, as I do not have any rights there. Hoping for a fix soon!


    you should be able to register for Connect using this: https://connect.microsoft.com/ConfigurationManagervnext/InvitationUse.aspx?ProgramID=4346&InvitationID=VNXO-DFPW-G6HD

    Don [doesn't work for MSFT, and they're probably glad about that ;]


    Thnx!
    Wednesday, February 1, 2017 3:01 PM
  • Thank you for submitting this to connect and uservoice.  I have upvoted and commented on both.  I hope there is a fix soon.  It's maddening when a software company stands behind the "by design" excuse for issues like this.  Microsoft, this needs to be fixed ASAP.
    Wednesday, February 1, 2017 6:34 PM
  • I've got exactly the same answer for my ticket I've opened up .....

    "Normal behaviour by design"

    Seriously? Are you kidding Microsoft?
    Wednesday, February 8, 2017 12:48 PM
  • I've got exactly the same answer for my ticket I've opened up .....

    "Normal behaviour by design"

    Seriously? Are you kidding Microsoft?

    Add your votes to the uservoice item and Connect item, to show MSFT how you feel about it.

    (raising a DCR doesn't guarantee they will fix it, they need to know how many customers are impacted)


    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Wednesday, February 8, 2017 8:11 PM
  • What setting do you have for User notifications?  I have my deployment set to "Display in Software Center and show all notifications" and SCCM does not close Office and prompts for a reboot. 
    Wednesday, March 1, 2017 7:57 PM
  • What setting do you have for User notifications?  I have my deployment set to "Display in Software Center and show all notifications" and SCCM does not close Office and prompts for a reboot. 

    reboot?

    applying an update to Office C2R doesn't require a reboot... ?

    are you using SUM to do this? or are you using an app deployment to do this?


    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Wednesday, March 1, 2017 8:16 PM
  • Hi Everyone-

    I just got a notification in my console that hotfix 4010155 is now available.  The release notes are available here: https://support.microsoft.com/en-us/help/4010155/update-rollup-for-system-center-configuration-manager-current-branch-v

    Among the various fixes, I saw this:

    Software Updates

    • After you start installation of Office updates from Software Center, users do not receive a notification message to exit all open Office 365 applications. This behavior occurs even with the forceappshutdown=False switch in the Configuration.xml file for Office 365."

    I will be applying this hotfix shortly, hopefully this resolves the issue.

    Wednesday, March 1, 2017 9:14 PM
  • Hi Everyone-

    I just got a notification in my console that hotfix 4010155 is now available.  The release notes are available here: https://support.microsoft.com/en-us/help/4010155/update-rollup-for-system-center-configuration-manager-current-branch-v

    Among the various fixes, I saw this:

    Software Updates

    • After you start installation of Office updates from Software Center, users do not receive a notification message to exit all open Office 365 applications. This behavior occurs even with the forceappshutdown=False switch in the Configuration.xml file for Office 365."

    I will be applying this hotfix shortly, hopefully this resolves the issue.

    wow, that's a big laundry list of bugfixes, and it came sooner than I thought it might. hope it resolves this issue for you

    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Thursday, March 2, 2017 8:34 AM
  • Could you please share your experience after applying the hotfix?

    Will

    Monday, March 6, 2017 1:51 PM
  • I have installed hotfix 4010155 and deployed the agent update to my clients.  I then created a software update group for the 2/2017 deferred branch build for O365 Pro Plus version 1609 build 7369.2118 and pushed to my test machine.  I had Outlook and Excel open and the update installed smoothly and silently, with no forced close of either application.  After the update completed I received a reboot notification from the software update agent as usual.  Looks like this issue has been resolved in this latest SCCM hotfix.
    • Marked as answer by Ari_P Tuesday, March 7, 2017 10:45 PM
    Tuesday, March 7, 2017 10:43 PM
  • I have installed hotfix 4010155 and deployed the agent update to my clients.  I then created a software update group for the 2/2017 deferred branch build for O365 Pro Plus version 1609 build 7369.2118 and pushed to my test machine.  I had Outlook and Excel open and the update installed smoothly and silently, with no forced close of either application.  After the update completed I received a reboot notification from the software update agent as usual.  Looks like this issue has been resolved in this latest SCCM hotfix.

    That's some good news! But there can be some new issues after installing the patch. Do you experience the problems described here:

    https://social.technet.microsoft.com/Forums/en-US/c1665b4a-8ecb-4bdc-9ea6-a77f83413c38/sccm-1610-hotfix-kb4010155-has-some-serious-bugs?forum=ConfigMgrCBGeneral

    Friday, March 10, 2017 8:24 AM
  • I have installed hotfix 4010155 and deployed the agent update to my clients.  I then created a software update group for the 2/2017 deferred branch build for O365 Pro Plus version 1609 build 7369.2118 and pushed to my test machine.  I had Outlook and Excel open and the update installed smoothly and silently, with no forced close of either application.  After the update completed I received a reboot notification from the software update agent as usual.  Looks like this issue has been resolved in this latest SCCM hotfix.

    That's some good news! But there can be some new issues after installing the patch. Do you experience the problems described here:

    https://social.technet.microsoft.com/Forums/en-US/c1665b4a-8ecb-4bdc-9ea6-a77f83413c38/sccm-1610-hotfix-kb4010155-has-some-serious-bugs?forum=ConfigMgrCBGeneral

    I have not observed this behavior with software center in my environment, it still works as expected as far as I can tell.
    Monday, March 13, 2017 8:45 PM
  • I have installed hotfix 4010155 and deployed the agent update to my clients.  I then created a software update group for the 2/2017 deferred branch build for O365 Pro Plus version 1609 build 7369.2118 and pushed to my test machine.  I had Outlook and Excel open and the update installed smoothly and silently, with no forced close of either application.  After the update completed I received a reboot notification from the software update agent as usual.  Looks like this issue has been resolved in this latest SCCM hotfix.

    So we have deployed way too many different variants of o365 over the past year. Knowing that, do we know if the  forceappshutdown=False switch correlates to a specific registry key on the PC?

    We want the application that does initial installs, reinstalls, or changes between channel or architecture to force close their apps, but afterwards we'd like to leave the PC in a state where updates will NOT force close their apps. I think we need a post upgrade action to change the registry to the desired value.

    Any thoughts?


    Will

    Wednesday, June 7, 2017 12:27 PM
  • I have installed hotfix 4010155 and deployed the agent update to my clients.  I then created a software update group for the 2/2017 deferred branch build for O365 Pro Plus version 1609 build 7369.2118 and pushed to my test machine.  I had Outlook and Excel open and the update installed smoothly and silently, with no forced close of either application.  After the update completed I received a reboot notification from the software update agent as usual.  Looks like this issue has been resolved in this latest SCCM hotfix.

    So we have deployed way too many different variants of o365 over the past year. Knowing that, do we know if the  forceappshutdown=False switch correlates to a specific registry key on the PC?

    We want the application that does initial installs, reinstalls, or changes between channel or architecture to force close their apps, but afterwards we'd like to leave the PC in a state where updates will NOT force close their apps. I think we need a post upgrade action to change the registry to the desired value.

    Any thoughts?


    Will


    I have a feeling (not really sure why) that this is a parameter passed at runtime to the updater engine, and isn't stored nor controlled via registry. maybe check uservoice or techcommunity (or ask a question/request there)

    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Wednesday, June 7, 2017 9:16 PM