Skip to main content

We get this question regularly, so I thought I’d put it on here to help people find the info. Certain of our supported 3rd party titles require that the app not be running for patches to be applied. We could terminate the application automatically but doing so would risk data loss. For example, Notepad++ is not set to auto-save by default. If we were to close Notepad++ when we detect it running, in order to patch, an end-user could have unsaved work which would be lost. Because of this, you will see failed patches for Notepad++ anytime the patch schedule coincides with the Notepad++ application being open.



One tip for ensuring that Notepad++ gets patched is to put a reminder in the patch notification text that users should close out of Notepad++ before allowing the patching to proceed.



Here’s the documentation for custom notifications:


https://support.automox.com/help/end-user-notifications



And here’s the list of third party titles that we support, and which ones require the software to not be running:


https://support.automox.com/help/third-party-patching-best-practices

Awesome Nic, can you also share what third party updates are hosted by Automox and what are pulled from the source? We notice that not everything is being send from Automox URL.



Can you clarify on this choice to not proxy everything through Automox?


I believe for most of the 3rd party apps, we pull from the source and then send to the endpoints via the agent. There may be some situations where we pull it directly on the agent side. Let me ping one of our engineers who works in that area to see if I can get more details.


Cached 3rd party udpates will be stored here:


https://api.automox.com/api/cache/*



If you upload files for Worklets or Required Software, the content will be stored here:


automox-policy-files.s3.us-west-2.amazonaws.com*


I did get confirmation that all of our third party patches do get downloaded to our console first, and then get pushed out to the agents. The one exception is Chrome where we make use of Chrome’s auto-update feature. We trigger the native Chrome update check so that the patch gets downloaded locally and installed via the Chrome process.


Why is that? I can’t really follow the logic behind this. From common security practice you want to limit access to the internet from servers within the infrastructure. Ofc you could argue that chrome should not be installed too but one of the reasons to go with a patch management solution is to control the network flow and update cycle. Don’t we try to reduce the attack surface?


That’s why we do most of them through us - for Chrome my guess is that there’s some technical issue that makes that not feasible, so we rely on the endpoint to get the download directly. If that’s something that you prefer not to make use of, then you can do a Patch All Except policy and exclude Chrome from inclusion in the Automox patching.


Fair enough i just try to understand the logic behind this.


Reply