We often find that when installing patches that certain processes need to be killed first. In particular this happens with Microsoft Office patches.
We can quite easily set the fixlet to kill the process, but this is not a very nice end user experience and is something we always get complaints about.
Is there any way to customise the fixlets that require a process to be killed to prompt the user first? This is the type of experience you would get with Windows update and also OS X software update.
Would be nice to know if this is possible on Windows as well as OS X
These patches would be part of a baseline where we already have a message advising to close all app’s. Patching can often take a few minutes so users just tend to ignore the message and carry on working until they are asked to reboot. If a patch needs an app to be closed it would be nice to have another message advising of this which would bug the user until they close it.
This is the experience you’d get with native patching on both Windows and OS X, we’ve in the past just killed the processes but this really isn’t a very nice user experience.
I would recommend separating all patches that require apps to be closed into a separate baseline than those that do not have that requirement.
I would take action on this baseline and target it to machines with no users logged in. Tell it to cache the downloads while waiting on constraints. ( You may need to set the Client Download Cache to be larger ). If the downloads are cached, then the patches can run while a user is logged off EVEN if there is no network connectivity.
Then I would take action again on this same baseline and target it to machines with users logged in with a message to close their apps, but set this action to not start for 1 week or more. This will give the first action the opportunity to run while users are logged off and only bug the users that never get in this state.
In taking the example of updating Firefox, you can also take action on the patch fixlet, but add relevance ( not exists running application “Firefox.exe” ) or similar and it will actually wait until the user closes firefox and then automatically patch it at that point. This is the best way to update applications that would otherwise need to be closed without interrupting the user, but it is also the most manual work.
I already have a solution to automate the creation of baselines and I’m hoping to eventually expand that automation further so this is no longer a manual process.
I do it using vbs script: I create a fixlet that checks if the process is running, then if the answer is yes the prompt window appears.
Example below:
begin prefetch block
if {not exists files ("c:\windows\logs\RunAsCurrentUser.exe")}
add prefetch item name=EE47505EBFB2790B9DA8A20ED70E67158E9753D0 sha1=ee47505ebfb2790b9da8a20ed70e67158e9753d0 size=342528 url=SWDProtocol://127.0.0.1:52311/uploads/EE47505EBFB2790B9DA8A20ED70E67158E9753D0/RunAsCurrentUse.exe.bfswd sha256=1a9b518c775e2a85a7c47801e9b8221df338a65ad8df326485e4cd2aea22fe52
endif
end prefetch block
parameter "baseFolder" = "__Download/"
if {not exists files ("c:\windows\logs\RunAsCurrentUser.exe")}
move "__Download/EE47505EBFB2790B9DA8A20ED70E67158E9753D0" "c:\windows\logs\RunAsCurrentUser.exe"
endif
if {exists running application whose ((it = "winword.exe" OR it = "excel.exe" OR it = "msaccess.exe" OR it = "ONENOTE.EXE" OR it = "POWERPNT.EXE" OR it = "MSPUB.EXE") of (name of it as lowercase))}
delete __appendfile
appendfile result=MsgBox ("Please save your work, close all Office applications and click OK button", vbSystemModal, "Close all Office Applications")
move __appendfile "C:\ProgramData\clickOK.vbs"
waithidden cmd.exe /C cacls.exe "C:\ProgramData\clickOK.vbs" /T /E /G Users:C
wait "c:\windows\logs\RunAsCurrentUser.exe" wscript "C:\ProgramData\clickOK.vbs"
pause while {exists running application whose ((it = "wscript.exe") of (name of it as lowercase))}
delete "C:\ProgramData\clickOK.vbs"
endif
You have to use RunAsCurrentUser.exe app(as in the above example) to show a “vbs window” to a user.
You don’t need to use RunAsCurrentUser.exe anymore. The BES Client can do this natively by using a configuration option in the actionscript to change the behavior of the wait or run command.