Office and Click to run Updates and a request

Not sure if this should be an RFE but when updating Office 365 and click to run, the second action option still requires interaction from the end user once the updates (in the background) is complete as they have to close Skype and outlook or word or any other office product in order for the updates to complete. I think the action script needs the
waithidden {"%22" & value “ClientFolder” of key “HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Configuration” of native registry as string & “\officec2rclient.exe%22 /update user updatepromptuser=False updatetoversion=16.0.12527.20278”} line to have forceappshutdown=true
added to it to make sure it completes when applied out of hours to a machine that has been left locked.

All its doing is, when you take the action, the end user sees a pop up from MS that states Office is being updated in the background and to continue to use Office… Once it completes , it changes the pop up to a “warning” that the applications that are open (outlook, SFB, Excel, Word etc" need to be shut down and waits for the user to click ok , when clicked, the apps close, patch and then re-open theoretically in same state as you left them… But until that final click, the action remains “running” and never completes.

Adding the Forceappsshutdown does exactly that, without the need for the end user to agree, but it still pops up with the Info pop up about being updated in the background… I guess , the best options would also not pop up the info too and I think that switch is displaylevel=False

So the Complete string for Action 2 for all the Office 365/ Click should be…

waithidden {"%22" & value “ClientFolder” of key “HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Configuration” of native registry as string & “\officec2rclient.exe%22 /update user updatepromptuser=False updatetoversion=16.0.12527.20278”} line to have forceappshutdown=true displaylevel=False

2 Likes

The current actions were not meant to force app shutdown. This would be an RFE.

1 Like

Thank you,
I’ll put in an RFE BUT as it stands at the moment, with the action in the Running state till the end user does something, will other actions post this one, also be in a pending state till this one completes?
I’ll run some more tests when I get a moment.

1 Like

Pete_F is right, the current fixlets are not really fit for use because there is too much opportunity for users to ignore or cancel the Office 365 update, leaving the action stuck in a ‘Running’ state (worse when it is part of a baseline).

His option of Forceappshutdown would not be an option for this business either, because patching laptops overnight doesn’t work and killing Office applications during the working day is unacceptable.

updatepromptuser=false works, but then the fixlet needs to be re-coded to recognize when the updates really are complete and continue it processing and the relevance as supplied is inadequate for this method of applying the update.

The documentation for officec2rclient is appalling (yes, Microsoft, I’m looking at you), presumably to try to push SCCM as the patch deployment tool (still looking, Microsoft, no logic in PowerShell going open source when attempting to close out 3rd party patch deployments to Office).

1 Like

Closing the loop on this one. First , @Pete_F thanks for catching this problem and submitting an RFE. A new action was added to the Office 365 fixlet over a year ago (#6) that includes the Forceclose command line, that solves the problems you mentioned. I am certain this was because of your RFC and if not, “Thanks” for reporting any way. These posts helped me to understand why office patching numbers were not great. We have been using Action #6 to forceclose the office apps for a while and our numbers have improved significantly.

1 Like

There is actually no need to close Office 365 apps while patching.

Running OfficeC2RClient from the command-line with parameters ‘/update user updatepromptuser=False displaylevel=False forceappshutdown=false updatetoversion=’ shows that the update installs a complete parallel copy and puts up a banner notification to the user.

There is always a copy of OfficeClickToRun.exe running. Invoking OfficeC2RClient just starts up additional copies of OfficeClickToRun.exe, so my tailored copy of the Office 365 fixlets just waits for the additional OfficeClickToRun processes to close before continuing. Office 365 is updated and the users don’t suffer forced closure of their application.

I still haven’t figured out how to update the proofing languages though - if anyone has the secret sauce for that, I’m all ears.