Question: Why did my third-party application fail to patch?
Answer
Some of our supported third-party titles require that the application is not 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 that 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 these applications get patched is to put a reminder in the patch notification text that users should close out of them before allowing the patching to proceed.
Here’s the documentation for custom notifications:
Managing 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:
Third-Party Best Practices
Note: Refer to the Third-Party Overrides Options for information about using Automox Worklets to force close titles that would otherwise not be patched when running.
Other reasons for failure may be an inability to properly connect to our S3 bucket that hosts our third-party patches. You may see errors like the following:
Download of C:\WINDOWS\TEMP\cc302371-b684-410f-aba6-7e34872d31ca\adobe_acrobat_reader_dc_update.msp failed Error: Exception calling "DownloadFile" with "2" argument(s):"The remote name could not be resolved: 'api.automox.com'" Get-Item : Cannot find path 'C:\WINDOWS\TEMP\cc302371-b684-410f-aba6-7e34872d31ca\adobe_acrobat_reader_dc_update.msp' because it does not exist."
In cases like this, we recommend making sure you follow the allow-listing steps from these articles:
Agent Firewall Allowlisting Rules
Globally Trust-listing Automox Through EPP Application Control