# Automox Product & Developer Documentation — Full Corpus > Concatenated text of all Automox product and developer documentation topics. Source pages live at https://docs.automox.com/product/ and are built from the ax-madcap MadCap Flare project. Generated 2026-06-05. Topic count: 221. --- # Automox API Reference _Section: Developer • Source: https://docs.automox.com/product/Content/Developer/Automox%20API%20Reference.htm_ --- # Automox Community Resources _Section: Developer • Source: https://docs.automox.com/product/Content/Developer/Automox%20Community%20Resources.htm_ Here are some resources from the Automox Community. - [Community Quick Start Guide](https://community.automox.com/automox-92/automox-community-quick-start-guide-1603) - [How to Submit a Worklet or API Script](How to Submit Worklets.htm) - [Automox Developer Resources - Community](https://community.automox.com/automox-developer-resources-93) --- # Automox Servers API is now Fast By Default _Section: Developer • Source: https://docs.automox.com/product/Content/Developer/Automox%20Servers%20API%20FBD.htm_ As of January 27, 2025, the Automox Servers API is now Fast By Default. This change improves the performance of the Automox Servers API by optimizing the way that data is retrieved and processed. ## What changed? The simplest way to interact with the servers API is this: [https://console.automox.com/api/servers?o=144237&l=75](https://console.automox.com/api/servers?o=144237&l=75) When using this default configuration, the API **implicitly** includes a lot of additional information about the servers. Expressed **explicitly**, this would be: [https://console.automox.com/api/servers?o=144237&l=75&include_details=1&include_next_patch_time=1&include_server_events=1](https://console.automox.com/api/servers?o=144237&l=75&include_details=1&include_next_patch_time=1&include_server_events=1) To speed up its APIs, Automox is changing this behavior. You now need to **explicitly** request server details, next patch time, and server events. Automox has made several changes to the Automox Servers API to improve performance: - Changes to the default settings: - The Automox Servers API previously returned a lot of detail about each device (server). Automox has updated the default state to return a minimal data set, with the additional detail now being optional. - New Parameters: - Automox has added new parameters to the API that allow you to choose whether to include device details, server events, and next patch time. - The new parameters are: - `include_details` - This parameter allows you to specify whether you want to include details about each device in the response. - By default, this parameter is set to `0`, which means that the value of `details` will be `{}`. - If you set this parameter to `1`, the complete `details` object is included in the response. - `include_server_events` - This parameter allows you to specify whether to include `reboot_deferral_count` and `patch_deferral_count` in the response. - By default, this parameter is set to `0`, which means that the value of `reboot_deferral_count` and `patch_deferral_count` will be `0`. - If you set this parameter to `1`, the `reboot_deferral_count` and `patch_deferral_count` will show the actual values in the response. - `include_next_patch_time` - This parameter allows you to specify whether to include the `next_patch_time` in the response. - By default, this parameter is set to `0`, which means that the value of `next_patch_time` will be `null`. - If you set this parameter to `1`, the `next_patch_time` will show the actual value in the response. This is the most significant performance improvement; depending on the size of your organization the response time can be nearly 10 times faster. If you do not need the devices next patch times, do not set `include_next_patch_time=1` and you will get data much sooner. - `exclude_policy_status` - This parameter allows you to specify whether to exclude `policy_status` and `status` in the response. - By default, this parameter is set to `0`, which means that the values of `policy_status` and `status` are included in the response. - If you set this parameter to `1`, the value of `policy_status` will be `[]`, and the value of `status` will be `{}`. ## Examples - Parity with current behavior: [https://console.automox.com/api/servers?o=123456&l=75&include_details=1&include_next_patch_time=1&include_server_events=1](https://console.automox.com/api/servers?o=123456&l=75&include_details=1&include_next_patch_time=1&include_server_events=1) - (Recommended) Near parity with current behavior, excluding a time-consuming calculation of next patch time: [https://console.automox.com/api/servers?o=123456=75&include_details=1&include_server_events=1](https://console.automox.com/api/servers?o=123456=75&include_details=1&include_server_events=1) - Basic server information: [https://console.automox.com/api/servers?o=123456&l=75](https://console.automox.com/api/servers?o=123456&l=75) - Fastest known query params: [https://console.automox.com/api/servers?o=123456&l=75&exclude_policy_status=1](https://console.automox.com/api/servers?o=123456&l=75&exclude_policy_status=1) - You can define inverse behavior with a value of 0: [https://console.automox.com/api/servers?o=123456&l=500&include_details=1&include_next_patch_time=0&include_server_events=1&exclude_policy_status=0](https://console.automox.com/api/servers?o=123456&l=500&include_details=1&include_next_patch_time=0&include_server_events=1&exclude_policy_status=0) --- # Developer Documentation _Section: Developer • Source: https://docs.automox.com/product/Content/Developer/Developer%20LP.htm_ - [Introduction & Guide to Automox API Standards](Introduction & Guide to Automox.htm) - [Errors](Errors.htm) - [Automox Servers API is now Fast By Default](Automox Servers API FBD.htm) - [Using Global API Keys](Using Global API Keys.htm) - [Automox Community Resources](Automox Community Resources.htm) - [Automox API Reference](Automox API Reference.htm) ## Getting Started for Developers - [Newbie's Guide to Getting Started with Automox API](Newbie's Guide to API.htm) - [Tutorials & Introductions](Tutorials & Introductions.htm) ## API Resources - [Policy and Device Filters, and Scheduling](policy_filters_schedule.htm) - [Scheduled Windows - Fields & Syntax](Scheduled Windows.htm) - ### Audit Trail API & OCSF Information - [OCSF Schema Overview](OCSF Schema Overview.htm) - [OCSF Class Events](OCSF Class Events.htm) - [OCSF Mapping for Custom Roles Events](OCSF Mapping for Custom Roles Events.htm) ## AX Developer Resources - ### Worklets & Scripting - Worklet Development Kit (WDK) - [Welcome to the Worklet Development Kit (WDK)!](WDK Overview.htm) - [Getting Started with WDK!](Getting Started with WDK!.htm) - [Frequently Asked Questions](WDK FAQs.htm) - Networking - [Networking](Networking.htm) - [IPv4](IPv4.htm) - Configuration Management - [Software](Software.htm) - Utility - [Logging](Logging.htm) - Win32 - [Environment](Environment.htm) - [Registry](Registry.htm) - [WinSession](WinSession.htm) - [Worklet Resources](Worklet Resources.htm) --- # Environment _Section: Developer • Source: https://docs.automox.com/product/Content/Developer/Environment.htm_ ## Set-EnvVar ### Overview Allows persistent environment variable creation and immediate update in the host session's env: PSDrive. ### Cmdlet Attributes CmdletBinding : [] Alias : ['export'] ### Parameters Name : `System.String` The name of the environment variable to set. Attributes Parameter : [Mandatory = $true, Position = 0] --- Value : `System.String` The value of the environment variable to set. Attributes Parameter : [Mandatory = $true, Position = 1, ValueFromPipeline = $true] AllowNull : [] AllowEmptyString : [] --- Scope : `System.String` The scope of the environment variable to be set. Default: `'USER'` Attributes Parameter : [] Alias : ['s'] ValidateSet : ['USER', 'MACHINE'] --- NoPersist : `System.Management.Automation.SwitchParameter` If this switch is specified, the environment variable update is reflected only in the `$env:` PSDrive and will not be available once the PowerShell session has exited. Attributes Parameter : [] Alias : ['np'] --- ### Output **Type:**`[ System.Boolean ]` Indicates whether the environment variable was set successfully. ### History | Author | Date | Version | Release Notes | | --- | --- | --- | --- | | Anthony Maxwell | 09/29/2023 | 1.0.0 | - Initial release. | --- # Automox API Error Reference _Section: Developer • Source: https://docs.automox.com/product/Content/Developer/Errors.htm_ Automox uses conventional HTTP response codes to indicate the success or failure of an API request. | Code | Description | | --- | --- | | 200 OK | The request succeeded. | | 201 Created | A new resource was created successfully. | | 202 Accepted | The request was accepted for processing, but processing has not yet completed. There is no content sent for the request. | | 204 No Content | There is no content to send for this request, but the headers may be useful. Frequently seen with DELETE requests. | | 304 Not Modified | This is used for caching purposes. It tells the client that the response has not been modified, so the client can continue to use the same cached version of the response. | | 400 Bad Request | The request was unacceptable, often due to missing a required parameter or incorrect syntax. | | 401 Unauthorized | Used when the client must be authenticated to view the response. | | 402 Payment Required | An Organization’s subscription does not allow access to an endpoint or service. | | 403 Forbidden | Client is authenticated but is not authorized for the resource or action. | | 404 Not Found | The requested resource or endpoint is not found. Services may also send this response instead of 403 to hide the existence of a resource from an unauthorized client. | | 405 Method Not Allowed | The resource exists but the method is not allowed for it. A common usage is to disable DELETE-ing. Should not be used with GET or HEAD requests. | | 429 Too Many Requests | Too many requests hit the API too quickly from this user-agent or IP. | | 503 Service Unavailable | The service is unavailable or overloaded. The client should back off and try again later. | --- # Getting Started with WDK! _Section: Developer • Source: https://docs.automox.com/product/Content/Developer/Getting%20Started%20with%20WDK!.htm_ ## Summary The following example shows how to implement WDK to reduce the complexity and time investment required to perform a common workplace automation task: uninstalling an application. In our example, we'll be removing Mozilla Firefox. ## Prerequisites If you'd like to replicate this behavior in your own Automox environment, please ensure the following prerequisites are met: - The devices targeted meet the **[[Automox Agent Requirements](../Product Documentation/Agents/Agent Requirements/Automox Agent Requirements.htm)](https://docs.automox.com/product/Product_Documentation/Agents/Agent_Requirements/Automox_Agent_Requirements.htm)**. - The devices targeted have Mozilla Firefox installed. - You have an Automox Console account with the **[appropriate permissions](https://docs.automox.com/product/Product_Documentation/Global_Access_Management/Roles_and_Permissions.htm)** to create, read & execute Worklet policies ( **Patch Operator and higher** ). ## Creating the Policy 1. Head to the **[Automox Console](https://console.automox.com)** and sign in with an account holding the required permissions outlined in the **[Prerequisites](#Prerequi)** section. 2. Create the base Worklet policy, providing the name and targeting options for both operating system and Automox device groups. For further guidance on creating a Worklet policy, please refer to **[Creating a Worklet](https://help.automox.com/hc/en-us/articles/5603324231700)**. 3. For this example, you create a Worklet that can be **manually** run to perform a Firefox uninstall. Considering this, our **evaluation** code can simply be `exit 0`. 4. For the **remediation** code, you implement the [`Get-Win32App`](./Software.htm#get-win32app) and [`Remove-Win32App`](./Software.htm#remove-win32app) WDK functions to locate the app and attempt the removal: # define our application name $appName = 'Firefox' # get matching apps # using the -IncludeUsers parameter allows us # to also retrieve matching installs from each # user's profile $apps = Get-Win32App -IncludeUsers | Where-Object { $_.Name -match $appName } # enumerate the collected apps foreach ( $app in $apps ) { # evaluate if we CAN uninstall the app # in some cases, software manufacturers # do not provide the required arguments # to SILENTLY remove the application if ( $app.CanQuietUninstall ) { # uninstall the application $app | Remove-Win32App } else { # generate activity log output if we # cannot uninstall the application out "$( $app.Name ) cannot be quietly uninstalled." } } 1. Create the policy by selecting the **Create Policy** button at the bottom of the page. ## Testing the Policy Now that you have a new policy created, it's time to test it. To do this: 1. Navigate to **Devices** and select a device you'd like to perform this uninstall for. 2. Scroll down to the **Associated Policies** area, and select **Run on this Device** to the right of your newly created **Uninstall Firefox** policy. 3. Now, go to the Activity Log and review the output. ## Reading the Output Take a look at the Activity Log output. Select **Reports** from the top navigation menu then select **Activity Log** from the **Reports** page. In the Activity Log, you now see some output generated: `Mozilla Firefox (x64 en-US) cannot be quietly uninstalled.` Unfortunately, it looks like in this case Firefox cannot be uninstalled without some additional input. Let's insert the silent uninstall switch, via `Remove-Win32App`'s `-AdditionalArgs` switch. ## Providing the Silent Switch Go back to the **Uninstall Firefox** policy page. Tweak the **Remediation** code to perform this install silently. Since we're now providing **known** arguments to perform the removal, we're able to significantly shorten our code: # define our application name $appName = 'Firefox' # locate and remove mozilla firefox, silently Get-Win32App -IncludeUsers | Where-Object { $_.Name -match 'Firefox' } | Remove-Win32App -AdditionalArgs '/S' ## Rerunning the Policy Now, go back to the device page where you performed the manual policy run in [Testing the Policy](#testing-the-policy). Run the policy again via the **Run on this Device** button. ## Reading the Output .. Again! Now once more, review the Activity Log output. You now see the uninstall result has been output as follows: Name ExitCode UninstallerPath UninstallerArgs ---- -------- --------------- --------------- Mozilla Firefox (x64 en-US) 0 C:\Program Files\Mozilla Firefox\uninstall\helper.exe /S The column `ExitCode` value of `0` indicates the uninstall was successful - Firefox is no more! ## Next Steps This document is a simple example that demonstrates WDK capability. This simple policy could be enriched to, for example: - Detect in the **Evaluation** script *if* the application is installed. Through this, you can establish a state of "compliance" around our policy. - Consider the `ExitCode` value returned from the `Remote-Win32App` function, thus comparing to ensure the uninstall was successful. --- # How to Submit Worklets and API Scripts _Section: Developer • Source: https://docs.automox.com/product/Content/Developer/How%20to%20Submit%20Worklets.htm_ You can create your own Worklets and API scripts and submit them to the Automox Community. Just follow the instructions below: 1. Once you have created your new Worklet or API script, log into the Automox Community. 2. Create a new post in the appropriate group: - For Worklets, create a new post in [Worklets & Scripts](https://community.automox.com/community-worklets-12). - For API scripts, create a new post in [Automox API & Integrations](https://community.automox.com/api-integrations-130). 3. Give your new post a title, and add a brief description of what your worklet or API script does. 4. Select the Code option from the menu (under the 3 dots) to create a code block in your post. - For Worklets, you need to use 2 code blocks. One for the evaluation code, the other for the remediation code. 5. Once you're sure that you've got everything you need in your post, submit it. Your worklet or script will then be submitted for review by our team. The Automox team reviews Worklets and API scripts submitted to the community, to ensure that they function properly and that there is no malicious code, before they are posted to the community. If you do not see your post right away, it is likely under review. --- # IPv4 _Section: Developer • Source: https://docs.automox.com/product/Content/Developer/IPv4.htm_ ## Get-IPv4Network ### Overview Converts a provided network ID and CIDR prefix to an object containing the calculated network ID, broadcast address, number of IPs in the subnet and an enumerator. ### Cmdlet Attributes CmdletBinding : [DefaultParameterSetName = 'CIDR-String'] Alias : ['gip4n'] ### Parameters Network : `System.String` A string representation of a subnet in CIDR notation ( ex: `'192.168.255.0/24'` ). Attributes Parameter : [Mandatory = $true, Position = 0, ParameterSetName = 'CIDR-String', ValueFromPipeline = $true] ValidateScriptAttribute : [{ $_.Trim() -match '^\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}/\d{1,2}' }, ErrorMessage = 'Is this a properly formatted CIDR subnet: {0}?'] --- NetworkID A `[ System.Net.IPAddress ]` object to use as the network ID. Attributes Parameter : [Mandatory = $true, Position = 0, ParameterSetName = 'ID-Prefix'] ValidateScriptAttribute : [{ $_ -is [ IPAddress ] -or [ IPAddress ]::TryParse( $_, [ Ref ] $null ) }, ErrorMessage = 'Parameter "NetworkID" must be an IP address as either a System.Net.IPAddress object or string.'] --- PrefixLength : `System.Int32` A `[ System.Int32 ]` number to use as the prefix length for subnet calculation. Attributes Parameter : [Mandatory = $true, Position = 1, ParameterSetName = 'ID-Prefix'] ValidateRangeAttribute : [0, 32] --- ### Example PS> $net = Get-IPv4Network -Network '192.168.1.23/24' PS> $net.ID 192.168.1.0 PS> $net.Broadcast 192.168.1.255 PS> $net.Count 256 PS> $net | Foreach-Object { Write-Host $_ } 192.168.1.1 192.168.1.2 ... 192.168.1.254 ### History | Author | Date | Version | Release Notes | | --- | --- | --- | --- | | Anthony Maxwell | 07/17/2023 | 1.0.0 | - Initial release. | | Anthony Maxwell | 09/01/2023 | 1.1.0 | - Help text rewrite - Removal of IPv4Network class - Implementation of PSCustomObject return | --- # Introduction & Guide to Automox API Standards _Section: Developer • Source: https://docs.automox.com/product/Content/Developer/Introduction%20%26%20Guide%20to%20Automox.htm_ Here, you can find useful information to help you work with the Automox APIs. If you're new to working with APIs, see the [[Newbie's Guide to Getting Started with Automox API](Newbie's Guide to API.htm)](Newbie's Guide to API.htm) that explains how to get started with our API using Postman. ## Automox API Standards The Automox API is a powerful interface that allows you to integrate Automox reporting data into your applications and control your devices, policies, and configurations. All endpoints are only accessible via HTTPS and are located at `https://console.automox.com/api/....` ### Pagination For API endpoints that list results (like events and servers) there is a limit on the number of results returned per request. This is done for performance reasons. These endpoints have two parameters you should use to navigate your data: #### Limit A limit on the number of results to be returned, between 1 and 500 with a default of 500. A validation error will be returned if you attempt a request with a limit value that is outside this range. #### Page The page of results you wish to be returned with page numbers starting at `0`. ### Examples For example, if you have 145 servers and wish to fetch them in chunks of 50 you would have to make three requests: /api/servers?o=&limit=50&page=0 /api/servers?o=&limit=50&page=1 /api/servers?o=&limit=50&page=2 Since the Automox API does not return pagination information with all its endpoints, you may need to compare the number of returned results to the `limit` requested. When the limit and number of results returned are equal, you may need to make an additional request with a higher page number to ensure you have all of your data. See the Community page example: [Example API call with pagination limits](https://community.automox.com/api-integrations-130/example-of-api-call-with-pagination-limits-829) ### Automox Terminology Note that *servers*, *devices*, and *endpoints* are currently used interchangeably. **Keep API Keys Secure!** Depending on your role, your API key may be able to modify users, devices, and policies. API keys should be kept secure and not shared to prevent unforeseen changes or potential security issues. Never email or write down your API key. ### Authentication The API key is a unique identifier that authenticates requests. You can find your API key from the console. Go to **Settings → Keys** to find and manage your API key. Refer to [Managing Keys](../Product Documentation/Settings/Managing_Keys.htm) in the documentation. See also [Newbie's Guide to Getting Started with Automox API](Newbie's Guide to API.htm). ### Default Group ID You can determine an organization's Default Group ID by listing the groups and looking for the group with a blank name: `"name": ""` ## Patch Classification Category ID Mapping The table below lists the values for `patch_classification_category_id`. This parameter is returned with queries to the [GET /orgs/packages](https://docs.automox.com/product/Developer/Automox_API_Reference.htm?tocpath=Developer%20Documentation%7C_____10#tag/packages/GET/orgs/{id}/packages) and [GET /servers/packages](https://docs.automox.com/product/Developer/Automox_API_Reference.htm?tocpath=Developer%20Documentation%7C_____10#tag/devices/GET/servers/{id}/packages) endpoints. This table shows what the values for this parameter denote. | ID | Name | | --- | --- | | 1 | Application | | 2 | Connectors | | 3 | Critical Updates | | 4 | Definition Updates | | 5 | Developer Kits | | 6 | Feature Packs | | 7 | Guidance | | 8 | Security Updates | | 9 | Service Packs | | 10 | Tools | | 11 | Update Rollups | | 12 | Updates | | 13 | Upgrades | ## Rate Limiting Automox uses several rate limiting configurations to safeguard its APIs against bursts of traffic to maximize the stability and reliability of the platform. ### How rate limits are applied Automox associates all authenticated API requests to the user's account and not to individual API keys. For most APIs, Automox allows 100 authenticated requests per second and 15 unauthenticated requests per second. For unauthenticated requests, the rate limits are tracked per client IP address and are not associated to a user account. Specific endpoints may have different limits depending on how resource intensive the requests are. For example, [/servers/batch](https://docs.automox.com/product/Developer/Automox_API_Reference.htm?tocpath=Developer%20Documentation%7C_____10#tag/devices/POST/servers/batch) has a limit of 5 requests per minute. ### How to handle rate limiting gracefully All responses from the Automox API include rate limit status headers. For example: curl -I https://console.automox.com/api/users/self HTTP/2 200 date: Mon, 28 Mar 2022 15:52:47 GMT content-type: application/json x-ratelimit-limit: 100 x-ratelimit-remaining: 99 x-ratelimit-reset: 1648484793 x-request-id: 43ef3dc6c5b9c3a869eb354036f32f23 | Header | Description | | --- | --- | | x-ratelimit-limit | The maximum number of requests permitted in a given time window. | | x-ratelimit-remaining | The number of requests remaining before the rate limiter begins blocking requests. | | x-ratelimit-reset | The time at which the current rate limit window resets as a UTC epoch timestamp. | | retry-after | The number of seconds the user agent should wait before making a follow-up request. | If you exceed the rate limit, then a 429 error response is returned: curl -I https://console.automox.com/api/users/self HTTP/2 429 date: Mon, 28 Mar 2022 15:52:47 GMT content-type: application/json x-ratelimit-limit: 100 x-ratelimit-remaining: 0 x-ratelimit-reset: 1648484793 retry-after: 1 x-request-id: 43ef3dc6c5b9c3a869eb354036f32f23 A basic approach to gracefully handling rate limiting is to check for `429` status codes and build in a retry mechanism. The retry mechanism should ideally have an exponential back-off as well as some jitter built in to safeguard against a [thundering herd](https://en.wikipedia.org/wiki/Thundering_herd_problem) situation. --- # Logging _Section: Developer • Source: https://docs.automox.com/product/Content/Developer/Logging.htm_ ## out ### Overview Provides an alternative to the native "Write-*" cmdlets, allowing you to write directly to out and error streams, rather than the console host. ### Cmdlet Attributes CmdletBinding : [] Alias : ['error', 'debug', 'verbose', 'info', 'warning'] ### Parameters Message The message to send to the specified pipeline. Attributes Parameter : [Mandatory, ValueFromPipeline, Position = 0] AllowNull : [] AllowEmptyString : [] --- NoPrepend : `System.Management.Automation.SwitchParameter` If the `-NoPrepend` switch is provided and a non-default function alias ( ex: `warning`, `verbose`, `error` ) is invoked, the output will **not** be prepended with the alias name. As an example, if this function were invoked with the `verbose` alias **without** the `-NoPrepend` switch, the resultant output would look like: `VERBOSE: Test Message`. Attributes Parameter : [] --- ### Example # the out alias, using positional parameters PS> out 'one' 'two' 'three' one two three # the verbose alias, using pipeline input PS> 'one', 'two', 'three' | verbose VERBOSE: one VERBOSE: two VERBOSE: three ### History | Author | Date | Version | Release Notes | | --- | --- | --- | --- | | Anthony Maxwell | 08/24/2023 | 1.0.0 | - Initial release. | | Anthony Maxwell | 09/06/2023 | 1.1.0 | - Input type change from System.String[] to System.String - Removed erroneous output in InvocationName switch in process block - Message null check - Implemented AllowNull() and AllowEmptyString() parameter attributes for Message parameter | | Anthony Maxwell | 09/14/2023 | 1.1.1 | - Documentation pass. | --- # Networking _Section: Developer • Source: https://docs.automox.com/product/Content/Developer/Networking.htm_ ## Test-NetworkPort ### Overview Allows testing if a TCP port is reachable on the target network host. ### Cmdlet Attributes CmdletBinding : [] Alias : ['nc'] ### Parameters Target The target endpoint of the port scan. This parameter value should either be a `[ System.Net.IPAddress ]` value, or a string representation of an IP address ( ex: `'192.168.255.1'` ). Attributes Parameter : [Mandatory = $true, ValueFromPipeline = $true] Alias : ['t'] ValidateScript : [{ $_ -is [ IPAddress ] -or [ IPAddress ]::TryParse( $_, [ Ref ] $null ) }] --- Ports A `[ System.Array ]` of `[ System.Int32 ]` indicating TCP ports that should be scanned. Attributes Parameter : [Mandatory = $true] Alias : ['p'] ValidateScript : [{ $_ -is [ Int32 ] -or $_ -is [ Int32[ ] ] }] --- Timeout : `System.Int32` How long the port assessment should wait, in milliseconds, before considering the port **closed**. Default: `250` Attributes Parameter : [] Alias : ['w'] --- ### Example PS> Test-NetworkPort -Target '192.168.255.5' -Ports 80, 443 Target 80 443 ------ -- --- 192.168.255.5 True True ### History | Author | Date | Version | Release Notes | | --- | --- | --- | --- | | Anthony Maxwell | 10/18/2023 | 1.0.0 | - Initial Release. | --- # Newbie's Guide to Getting Started with Automox API _Section: Developer • Source: https://docs.automox.com/product/Content/Developer/Newbie's%20Guide%20to%20API.htm_ If you’ve never used an API before and want Automox to be your first (you always remember your first API), then this is the guide for you. By the end of this document you will have made your first API call and can see the results from your environment. This guide is written for Postman, however Phil Sturgeon has an awesome list of [alternatives to Postman](https://apisyouwonthate.com/blog/http-clients-alternatives-to-postman/), if you would prefer to use another tool. **Note:** This article is slightly outdated, but Automox plans to update it soon. ## Step 1: Download Postman Postman is a handy tool for testing out API calls to make sure they work before putting them in a script. They have a freemium version for individuals and small teams that you can [download](https://www.postman.com/). ![Postman](../Resources/Images/postman.png) They’ve got versions for Windows, macOS, and Linux so it doesn’t matter which OS you are working on. Install Postman, create yourself a login, and you’re ready for the next step. ## Step 2: Find your API key in the console In your Automox console, ![AX-Settings](../Resources/Images/Dashboard1.png) Select your API key (the one on the bottom). There’s a handy copy icon to the right of the to get it into your clipboard. ![AX-Keys](../Resources/Images/Keys1.png) ## Step 3: Create your first API call For this exercise, you use the “List Policies” API call. The documentation for that call is found [here](Automox API Reference.htm##tag/policies/GET/policies). Open up Postman and click the New button in the upper left, then Request. From there, paste the following command into the Get window: `https://console.automox.com/api/policies` ![Postman-GET](../Resources/Images/Pm-Get.png) Grab the API key from Step 2, click on the Authorization tab, and select type in the drop-down menu. Then paste your API key in the Token field: ![Postman-Token](../Resources/Images/PM-token.png) It's best to use environment variables in Postman to store sensitive information, like your API keys. collection with teammates. Please see this article [Managing Environments in Postman](https://learning.postman.com/docs/sending-requests/managing-environments/). If you only have one then you can click Send. If not, you will need to add a parameter to specify which organization you want to pull the policies from. To get the Organization ID (or *OrgID*) for the organization, go into your console and switch to the organization you want: ![Console-selectOrg](../Resources/Images/Console-orgsel.png) Then the *OrgID* is the last part of your console URL in the browser: [https://console.automox.com/dashboard?o=0000](https://console.automox.com/dashboard?o=0000) The *0000* is the number you want from the URL (in your case, it is a different number). Once you have the *OrgID*, go back to the Params tab in Postman. In the Key field, put the letter *o*. In the Value field, put the *OrgID*. You’ll notice that the GET field will update to include *?o=0000* at the end of the API call. Click *Send* and then you should see a bunch of code appear in the Body section below the : ![Postman-Response](../Resources/Images/PM-Body.png) This is all the data you would see if you drilled down into a policy on the console, plus some extra stuff such as internal ID numbers for the policies (PolicyID). But in this case you have all the data from all the policies in a handy JSON format that you can then do additional filtering and sorting on. If you get any sort of error code, double-check to make sure you copied your *OrgID* and *API Key* correctly. If they don’t match up, the API won’t return any data because it doesn’t recognize you as authorized to do so: ![Postman-Unauthorized](../Resources/Images/PM-unauth.png) ## Step 4: Pat yourself on the back Congratulations, you’ve made your first API call! Scrolling through the returned [JSON](https://www.w3schools.com/whatis/whatis_json.asp) shows you each of your policies, with all their associated data, in a tree structure. ## Step 5: What now? Now that you’re no longer an API newbie, you can put your API call into a script and start working with your data. Each of the API calls has example code in various languages to the right of the ![Request-Examples](../Resources/Images/retrieve-events.png) Once you’ve extracted the data you need via the API, you can crunch it for handy reporting. You can either use a tool built for that purpose, such as one of [Best Business Intelligence (BI) Tools](https://www.techradar.com/best/best-bi-tools) Or you can do the formatting and output directly in your script. Got questions? Stuck? Contact us at the [Community](https://community.automox.com/)! Don’t include your API key in anything you post to the community! That’s your secret key that you want to keep to yourself to protect access to your data. --- # OCSF Class Events _Section: Developer • Source: https://docs.automox.com/product/Content/Developer/OCSF%20Class%20Events.htm_ Automox currently reports on the following OCSF class events: ## [Account Change Events](https://schema.ocsf.io/1.2.0/classes/account_change?extensions=) - User Created - User Removed - User Role Updated - User Zone Assignment - User Profile Password Changed - User Account 2FA Enabled for Email - User Account 2FA Enabled for Mobile - User Account 2FA Disabled ## [Authentication Events](https://schema.ocsf.io/1.2.0/classes/authentication?extensions=) - User Log In Success - User Log In Failure - User Logged Out ## [Entity Management Events](https://schema.ocsf.io/1.2.0/classes/entity_management?extensions=) - Create/Add API Key - Delete/Remove API Key - API Key Enabled - API Key Disabled - Zone Login Attempts Setting Change - Zone SAML Enabled - Zone SAML Disabled - Zone 2FA Setting Enabled - Zone 2FA Setting Disabled - API Key Decrypted - Group Created - Group Deleted - Group Settings Updated - Devices Associated to Group - Policies Associated to Group - Role Creation - Role Deletion - Role Update ## [User Access Events](https://schema.ocsf.io/1.2.0/classes/user_access?extensions=) - User Role Assignment - User Role Revocation ## [Web Resource Activity Events](https://schema.ocsf.io/1.2.0/classes/web_resource_access_activity?extensions=) - Release Channel Switched from Stable to Beta - Release Channel Switched from Beta to Stable - Agent Auto Update Switched from Off to On - Agent Auto Update Switched from On to Off - Delete Device - Device custom_name Updated - Device Group Updated - Device Tag Updated - Manual Device Reboot Request - Manual Device Scan Request - Manual Packaged Install Request - Cloned Policy Created - Manual Approval Policy Denied - Manual Approval Policy Approved - Policy Created - Non-Scheduled Policy Run (Run Now) - Policy Activated - Policy Configuration Updated - Policy Created from Worklet Catalog - Policy Deactivated - Policy Deleted - Zone Added - Zone Name Updated - Splashtop Remote Control Consent Changed - Splashtop Remote Control Connection Failed --- # OCSF Mapping for Custom Roles Events _Section: Developer • Source: https://docs.automox.com/product/Content/Developer/OCSF%20Mapping%20for%20Custom%20Roles%20Events.htm_ This document outlines the mapping of Automox Custom Roles events to the OCSF (Open Cybersecurity Schema Framework) standard. The following table provides a detailed mapping of each Automox Custom Role event to its corresponding OCSF class and event type. ## Entity Management New events are the mappings for organization role lifecycle operations: Create, Update, and Delete. ### Event Classification Matrix | Operation | Activity ID | Activity Name | Type UID | Type Name | HTTP Status | Message | | --- | --- | --- | --- | --- | --- | --- | | Create | 1 | Create | 300401 | Entity Management: Create | 201 | Organization Role Creation | | Update | 3 | Update | 300403 | Entity Management: Update | 200 | Organization Role Update | | Delete | 4 | Delete | 300404 | Entity Management: Delete | 200 | Organization Role Deletion | ### Actor (User) Information | Field | Description | Example Value | | --- | --- | --- | | actor.user.uid | Primary user identifier (UUID) of the actor | 75c4039f-080d-477c-9eb2-af49d8f586ef | | actor.user.uid_alt | Legacy numeric user ID | 67890 | | actor.user.email_addr | The actor’s email address | admin@automox.com | | actor.user.account.uid | Account/tenant UUID | 538f436e-51b0-48a5-80bc-ddbf6cc1baea | ### Entity (Role) Data #### Common Entity Fields | Field | Description | Example Value | | --- | --- | --- | | entity.type | Entity type classification | "Role" | | entity.uid | Role UUID | 550e8400-e29b-41d4-a716-446655440003 | #### Event-Specific Entity Data | Field | Create | Update | Delete | | --- | --- | --- | --- | | entity.name | ✅ | ✅ | ❌ Not included | | entity.data.description | ✅ | ✅ | ❌ Not included | | entity.data.permissions[] | ✅*Permission: All permissions follow the {resource}:{action} format, such as endpoint:read | ✅*Permission: All permissions follow the {resource}:{action} format, such as endpoint:read | ❌ Not included | | entity.data.scopes[] | ✅‡Scope: Scope is the enum of [ACCOUNT, GLOBAL, ORGANIZATION] | ❌ Not included | ❌ Not included | ### Metadata | Field | Purpose | Value | | --- | --- | --- | | metadata.version | OCSF schema version | 1.1.0 | | metadata.tenant_uid | Multi-tenant isolation identifier | Account UUID | | metadata.correlation_uid | Links related events together | The UUID of the target organization. This unique identifier may correspond to an account, a global organization, or a standard organization. It specifies the organization in which the role-related action is performed. | | metadata.product.name | Generating product name | Automox Audit Trail | | metadata.product.vendor_name | Product vendor | Automox | | metadata.product.version | Product version | 1.0.0-dev | ### Raw Data (API Payloads) The raw_data field preserves the original API request payload for forensic analysis. ### Observables Security-relevant data points extracted for threat detection and SIEM analysis. observables: - name: "actor.user.email_addr" type: "Email Address" type_id: 5 value: "admin@automox.com" - name: "actor.user.org.uid" type: "Organization ID" type_id: 99 value: "b348aa75-c308-41e5-a1e4-26d56438a069" ## User Access New events are the mappings for user role assignment operations: Grant and Revoke. ### Event Classification Matrix | Operation | Activity ID | Activity Name | Type UID | Type Name | Message | | --- | --- | --- | --- | --- | --- | | Grant | 1 | Assign Privileges | 300501 | User Access Management: Assign Privileges | User Role Assignment | | Revoke | 2 | Revoke Privileges | 300502 | User Access Management: Revoke Privileges | User Role Revocation | ### User Information The user object represents the target user receiving or losing privileges (NOT the actor performing the action). user: uid: "75c4039f-080d-477c-9eb2-af49d8f586ef" # Target user UUID email_addr: "target@automox.com" # Target user email | Field | Description | Example Value | | --- | --- | --- | | user.uid | UUID of user receiving/losing privileges | 75c4039f-080d-477c-9eb2-af49d8f586ef | | user.email_addr | Email address of target user | target@automox.com | ### Actor (Unmapped) The actor field isn’t supported in version 1.1.0, but becomes available starting from 1.4.0. For now, the field is stored under unmapped as a temporary workaround. Once Automox upgrades to the latest schema version, it can officially include the actor field in User Access events. | Field | Description | Example Value | | --- | --- | --- | | unmapped.actor.user.uid | Primary user identifier (UUID) of the actor | 75c4039f-080d-477c-9eb2-af49d8f586ef | | unmapped.actor.user.email_addr | The actor’s email address | admin@automox.com | | unmapped.actor.user.account.uid | Account/tenant UUID | 538f436e-51b0-48a5-80bc-ddbf6cc1baea | | unmapped.actor.user.org.uid | The actor log (logged on) | b348aa75-c308-41e5-a1e4-26d56438a069 | ### Resource (Role) Information The resource object describes the role being granted or revoked. resource: uid: "550e8400-e29b-41d4-a716-446655440003" # Role UUID type: "role" # Resource type namespace: "ACCOUNT" # Scope/namespace | Field | Description | Example Value | | --- | --- | --- | | resource.uid | UUID of the role being assigned/revoked | 550e8400-e29b-41d4-a716-446655440003 | | resource.type | Type of resource | role | | resource.namespace | Authorization scope ‡ Scope: Scope is the enum of [ACCOUNT, GLOBAL, ORGANIZATION] | ACCOUNT | ### Privileges Array The privileges array contains UUIDs of roles being granted or revoked in this operation. privileges: - "550e8400-e29b-41d4-a716-446655440003" # Role UUID ### Unmapped Fields Custom fields that don't map directly to OCSF standard schema but provide valuable context. unmapped: scope: "ACCOUNT" # Authorization scope actor: user: uid: "832653b0-b57b-4d8d-8695-f0e8804de91b" | Field | Description | Value | | --- | --- | --- | | unmapped.scope | Authorization scope (ACCOUNT/GLOBAL/ORGANIZATION) | ACCOUNT | **Rationale:** These fields provide Automox-specific context that enhances OCSF events for internal security analysis without breaking OCSF compliance. ### Metadata metadata: version: "1.1.0" # OCSF version uid: "843f7ab9-1dd5-496e-8c5f-285927c3d976" # Event UUID tenant_uid: "538f436e-51b0-48a5-80bc-ddbf6cc1baea" # Tenant ID correlation_uid: "b348aa75-c308-41e5-a1e4-26d56438a069" # Correlation ID product: name: "Automox Audit Trail" vendor_name: "Automox" version: "1.0.0-dev" | Field | Description | Value | | --- | --- | --- | | metadata.version | OCSF schema version | 1.1.0 | | metadata.uid | Unique event identifier | Event-specific UUID | | metadata.tenant_uid | Multi-tenant isolation | Account UUID | | metadata.correlation_uid | Links related events | The UUID of the target organization. This unique identifier may correspond to an account, a global organization, or a standard organization. It specifies the organization in which the role-related action is performed. | | metadata.product.* | Audit system metadata | Product name, vendor, version | ### Observables Security-relevant data points extracted for threat detection and SIEM analysis. observables: - name: "unmapped.actor.user.email_addr" type: "Email Address" type_id: 5 value: "admin@automox.com" - name: "unmapped.actor.user.org.uid" type: "Organization ID" type_id: 99 value: "b348aa75-c308-41e5-a1e4-26d56438a069" | Observable | Type | Type ID | Value | Purpose | | --- | --- | --- | --- | --- | | User Email | Email Address | 5 | Requester's Email | Identity tracking, anomaly detection | | Organization ID | Organization ID | 99 | Requester's Organization (logged) | Event correlation, tenant isolation | --- # OCSF Schema Overview _Section: Developer • Source: https://docs.automox.com/product/Content/Developer/OCSF%20Schema%20Overview.htm_ This document aims to explain at a high level where key pieces of data live within the various schema classes: Entities (id and name of things), Organization / Account, and Authentication information. Because the OCSF schemas do not have fields that uniformly support this content in the same places, this document can serve as a helpful guide. ## Key Pieces of Data - Entity (thing being modified): payload, name and id - Organization / Account info - Authentication - Actor (Who performed the action?) - Role - for a few events only (that is, when User is the entity being acted upon or the Role is changing) ## Class ### Account Change - Entity: payload, name and id - raw_data (payload of the request, in requests that have a payload) - Not for user_removed, no payload for this event. - **In Account Change events, user and actor can be different: one user acting on another** - `user` - who is the subject of the login/logout action - name and id are provided - `actor.user` - who is doing the login/logout - only name (email) is provided, since this section is not the subject entity - Org/Account info - `metadata` - `correlation_uid`: organization (zone) uuid - `tenant_uid`: account uuid - `actor.user.org` - `uid`: organization (zone) uuid - `name`: organization name - Auth - Actor - `actor.user.email` and `actor.user.uid` - Account: `metadata.tenant_uid` - Role: [see below for details](#account-change-schema-detail) on Account Change schema with respect to roles. ### Authentication - Entity: payload, name and id - Caveats - Payload doesn't apply to these events - *name* is always the *email* of the user - id isn't present when login fails - **In Authentication events, user is identical to actor, so name and id is present in both places** - `user` - who is the subject of the login/logout action - `actor.user` - who is doing the login/logout - Org/Account info - Same treatment as *Account Change* - Auth - Same treatment as *Account Change* ### Entity Management - Entity: payload, name and id - entity (`entity.uid`, `entity.name`, `entity.type`) - name, id, and type of the entity - *Agent Access Key Copied* doesn't have a `entity.name` since it doesn't apply - `raw_data` (payload of the request, in requests that have a payload) - Not for `any (3) copied events`, `api_key_decrypted`, `api_key_deleted`, `group_deleted` - Org/Account info - `metadata` - `correlation_uid`: organization (zone) uuid - `tenant_uid`: account uuid - `observables` - `name: organization.id`: organization (zone) uuid - `name: organization.name`: organization name - Auth - Actor - `observables` - `name: 'email'`: actor's email address - Role: not provided ### Web Resources Activity - Entity: payload, name and id - `raw_data` (payload of the request, in requests that have a payload) - Not for `policy_removed`, `device_deleted`, `zone_removed`, no payload for these events. - `web_resources[]` - name and id of the entity - url string for the entity - description and type of the entity - Org/Account info - Same treatment as *Entity Management* - Auth - Same treatment as *Entity Management* ## Role Assignment Endpoints Automox has several endpoints that affect roles. - User Accept Invite (User Created event published) - User Updated - User Zone Assignments - Zone User Assignments ### Expressing Role Assignments Given the structure of the *Account Change* OCSF schema, Automox plans to express changes to role assignments in an explicit way by separating *Attach Policy* and *Detach Policy* events. For simple additions and removals, the corresponding *Attach* or *Detach* event is published. For changes to roles, for example, when Scott, a *Patch Operator*, becomes a *Zone Administrator*, two events will be published: one *Attach Policy* for the gained role (*Zone Administrator*), and one *Detach Policy* for the removed role (*Patch Operator*). Events are published independently for each User. This means that for the Zone Users Assignment endpoint, where roles for different users can change within a zone, events are published for each user that has changes (and role changes for a user can produce more than one event, that is, *Detach Policy* and *Attach Policy*). ### *Account Change* Schema Detail The Account Change OCSF schema provides the following structure for a User: `user --> groups[] --> privileges[]`, where a User has many Groups (zones/organizations), which each have many Privileges (role names, strings). This reflects the [*current state of the User**](#current-state-clarified), at the time of the request, with respect to the roles and zones that the request includes. In the OCSF schema, each User belongs to multiple organizations (Groups) for which they can have many roles (Privileges). Given Automox's current authorization model, where a user only has a single role in a zone, expect only a single role in this *Privileges* array. Consider an example of the OCSF schema, which expresses that Henry has *Patch Operator* in *Zone A*, and *Read Only* in *Zone B*. { "user": { "uid": "1209412", "email_addr": "henry.pimber@automox.com", "groups": [ { "type": "organization", "name": "Zone A", "uid": "259c001d-1540-47c9-83f3-c940867c53ec", "privileges": [ "Patch Operator" ] }, { "type": "organization", "name": "Zone B", "uid": "7ee9f975-6cb7-44e9-afc3-3adbece95d74", "privileges": [ "Read Only" ] } ] } } ### Introducing `user_result` The Account Change OCSF schema also provides another structure for a User, `user_result`, which indicates *"[t]he result of the user account change. It should contain the new values of the changed attributes."* By using both `user` and `user_result` fields in an *Account Change* event, you can express *before* and *after* states for a User. This means that in an *Attach Policy* event, where Jethro is first assigned a role in *Zone A*, he won't have any groups/privileges in `user` (before), but instead, in `user_result` (after). Like this: { "user": { "uid": "1209413", "email_addr": "jethro.furber@automox.com" }, "user_result": { "uid": "1209413", "email_addr": "jethro.furber@automox.com", "groups": [ { "type": "organization", "name": "Zone A", "uid": "259c001d-1540-47c9-83f3-c940867c53ec", "privileges": [ "Patch Operator" ] } ] } } ** A note about "current state"*: While the User may have roles in other zones, if those roles or zones aren't relevant to the changes happening in the request, they aren't included in the OCSF event. That means that the in the `user` (before) field, we don't express group and privileges that aren't relevant to what is changing. ## More Examples ### Zone User Assignments For the *Zone User Assignments* endpoint, multiple users can have their roles changed for a single Zone in one action. In this example, all within the context of *Zone B*, Henry is given the *Billing Admin* role, Jethro is having his role revoked, and Brackett's role is changing from *something* (not provided in the payload) to the *Read Only* role. The endpoint and request payload look like this: `POST /bespoke/accounts/{accountId}/zones/{zoneId}` { "name": "Zone B", "user_assignments": [ { "email": "henry.pimber@automox.com", "rbac_role": "billing-admin", "status": "active", "noDelete": false, "action": "add" }, { "rbac_role": "read-only", "email": "jethro.furber@automox.com", "action": "remove" }, { "rbac_role": "read-only", "email": "brackett.omensetter@automox.com", "status": "active", "noDelete": false, "action": "change" } ] } This produces 4 events: one *Attach Policy* for Henry, one *Detach Policy* for Jethro, and two for Brackett, a *Detach Policy* for the role he previously had which is now revoked, and an *Attach Policy* for *Read Only* that he is assigned. ### User Zone Assignments For the *User Zone Assignments* endpoint, one User can have their roles changed for multiple Zones in one action. In this example, Henry is given two new roles, the *Helpdesk Operator* role in Zone A and *Patch Operator* in Zone B. His *Read Only* role is revoked in Zone C, and his role is changed from something (not provided in the payload) to the *Admin* role in Zone D. The endpoint and request payload look like this: `POST /bespoke/accounts/:accountId/users/:userId` { "account_rbac_role": "no-global-access", "zone_assignments": [ { "action": "add", "name": "Zone A", "zone_id": "e92ae537-ea35-42d9-b6d4-92335f91a3db", "rbac_role": "helpdesk-operator" }, { "action": "add", "name": "Zone B", "zone_id": "e92ae537-ea35-42d9-b6d4-92335f91a3db", "rbac_role": "patch-operator" }, { "action": "remove", "name": "Zone C", "zone_id": "e92ae537-ea35-42d9-b6d4-92335f91a3db", "rbac_role": "read-only" }, { "action": "change", "name": "Zone D", "zone_id": "e92ae537-ea35-42d9-b6d4-92335f91a3db", "rbac_role": "admin" } ] } This produces 2 events: one *Detach Policy* containing role revocations in both Zone C and Zone D (a *Detach Policy* for the role he previously had, that is now changing), and one *Attach Policy* containing role assignments in Zone A, Zone B, and Zone D (where he is assigned his changed role). **For correlating these events, included in the schema is a correlation id that is the same for all events that are sourced from a single request.** Here is a snippet of the OCSF events for both: #### Detach Policy: Read Only role is revoked in Zone C, and previous role (Read Only) revoked in Zone D { "type_name": "Account Change: Detach Policy", "type_uid": 300108, "user": { "uid": "1209412", "email_addr": "henry.pimber@automox.com", "groups": [ { "type": "organization", "name": "Zone C", "uid": "60b1da5c-1db9-4b75-b8e3-6dc81d82a8b8", "privileges": [ "Read Only" ] }, { "type": "organization", "name": "Zone D", "uid": "3bfa00e7-3206-40b6-86e5-4ea934124f0c", "privileges": [ "Read Only" ] } ] }, "user_result": { "uid": "1209412", "email_addr": "henry.pimber@automox.com" } } #### *Attach Policy*: Given three new roles, including the assignment from the role change in Zone D { "message": "User Role(s) Updated", "type_name": "Account Change: Attach Policy", "type_uid": 300107, "user": { "uid": "1209412", "email_addr": "henry.pimber@automox.com" }, "user_result": { "uid": "1209412", "email_addr": "henry.pimber@automox.com", "groups": [ { "type": "organization", "name": "Zone A", "uid": "259c001d-1540-47c9-83f3-c940867c53ec", "privileges": [ "Helpdesk Operator" ] }, { "type": "organization", "name": "Zone B", "uid": "7ee9f975-6cb7-44e9-afc3-3adbece95d74", "privileges": [ "Patch Operator" ] }, { "type": "organization", "name": "Zone D", "uid": "3bfa00e7-3206-40b6-86e5-4ea934124f0c", "privileges": [ "Admin" ] } ] } } --- # Registry _Section: Developer • Source: https://docs.automox.com/product/Content/Developer/Registry.htm_ ## Get-RegistryView ### Overview Returns the appropriate registry view matching the system architecture of the calling device. --- # Scheduled Windows - Fields & Syntax _Section: Developer • Source: https://docs.automox.com/product/Content/Developer/Scheduled%20Windows.htm_ The purpose of this document is to help explain the syntax of the fields used in the Scheduled Windows feature. The logic behind scheduling the windows is based on [iCalendar’s RRule spec](https://icalendar.org/iCalendar-RFC-5545/3-8-5-3-recurrence-rule.html) (RRule standing for recurrence rule, that’s not a typo). Due to UI constraints, Automox supports only a subset of RRule options. A user can create two types of exclusion windows: a recurring window and a one-time window. For reference, here is an example POST request body for a recurring window: { "window_type": "exclude", "window_name": "Recurring window example", "window_description": "made via swagger", "org_uuid": "fa0efcda-9a97-4a84-a753-33008037715e", "rrule": "FREQ=YEARLY;BYMONTH=1,4;BYDAY=+1TU,+1WE,+3TU,+3WE", "duration_minutes": 60, "dtstart": "2025-09-18T09:00:00.000Z", "use_local_tz": false, "group_uuids": [ "0760c581-96ef-4770-8f9b-db2000c0d832" ], "recurrence": "recurring", "status": "active" } ## Recurring Windows Recurring windows have three components to their schedule: the `dtstart`, the `rrule`, and the `duration_minutes` fields. - **recurrence:** recurring - **dtstart:** required - ISO 8601 format - this is the beginning of the window series. The start time will be used in every recurrence. This time must be in UTC so the Z is required. (All dates and times are in UTC for this feature.) - **rrule:** The recurrence pattern. This is the field that has limited support for rrule options. For a recurring rule it MUST be: - **FREQ=YEARLY** required - only yearly is supported - **BYMONTH=** required - comma separated list of month numbers, 1 based (January === 1) - **BYDAY=** required - comma separated list of the occurrence and the rrule weekday constant. The “occurrence” is the first, second, third, fourth, or fifth occurrence of that weekday in the month. Patch Tuesday, for example, would be +2TU . Valid occurrences are 1 through 5 only. Valid weekdays are based on the rrule constants (MO, TU, WE, TH, FR, SA, SU). The example provided in the POST request body `"BYDAY=+1TU,+1WE,+3TU,+3WE"` corresponds to the first and third Tuesday and Wednesday of the month. - **duration_minutes:** required - limit 1440, which is 24 hours represented as minutes. Two hours would be 120. ## One Time Windows One time windows allow the user to schedule a single occurrence, but that single occurrence may span multiple days. It’s composed of different required fields than the recurring window. For reference, here is the POST request body for a one-time window: { "window_type": "exclude", "window_name": "One Time", "window_description": "made via swagger", "org_uuid": "fa0efcda-9a97-4a84-a753-33008037715e", "rrule": "FREQ=DAILY;UNTIL=20250917T100000Z", "dtstart": "2025-09-17T09:00:00.000Z", "use_local_tz": false, "group_uuids": [ "0760c581-96ef-4770-8f9b-db2000c0d832" ], "recurrence": "once", "status": "active" } One-time windows have two components to their schedule, the `dtstart` and the `rrule` fields. - **recurrence:** once - **dtstart:** required - ISO 8601 format - this is the beginning of the window start. This time is in UTC, so the Z is required. (**All dates and times are in UTC.**) - **rrule:** The recurrence pattern. This is the field that has limited support for rrule options. For a one time rule it MUST be: - **FREQ=DAILY** required - only daily supported - **UNTIL=** required - compact ISO 8601 format, again in UTC. No separators but the T and Z are still required. This date time string represents the end of the occurrence. A window with a `dtstart` of `2025-09-18T09:00:00.000Z` and an `UNTIL=20250918T100000Z` will run from 9 am to 10 am on Sept 18 UTC. Note: `duration_minutes` is not used for this recurrence type and should not be provided. ## Other Required Fields This API may support future functionality, so to support this, Automox has two fields that are required but only accept specific values: - `window_type:` "exclude" - `use_local_tz:` false - `window_name` Give your window a meaningful name. - `org_uuid` is a required path parameter. ## Related Topics - [Scheduled Windows](../Product Documentation/Device Management/Scheduled_Windows.htm) - [Managing Exclusion Windows](../Product Documentation/Device Management/Exclusion_Windows.htm) - [Scheduled Windows FAQ](../Product Documentation/Device Management/Scheduled_Windows_FAQ.htm) --- # Software _Section: Developer • Source: https://docs.automox.com/product/Content/Developer/Software.htm_ ## Get-Win32App ### Overview Retrieves Win32 installed applications from either or both of the local machine and user scopes. ### Cmdlet Attributes Alias : ['gw32a'] CmdletBinding : [] ### Parameters IncludeUsers : `System.Management.Automation.SwitchParameter` If provided, retrieves installed Win32 applications for all users on this device. Attributes Parameter : [] Alias : ['iu'] --- UsersOnly : `System.Management.Automation.SwitchParameter` If provided, retrieves ONLY user-scope installed Win32 applications. Attributes Parameter : [] Alias : ['uo'] --- ### Example PS> Get-Win32App InstallDate : 8/1/2023 12:00:00 AM Publisher : Google LLC IsMSI : True Username : UninstallArgs : {[ArgumentList, System.Object[]], [FilePath, MsiExec.exe]} InstallLocation : Scope : MACHINE Name : Google Chrome CanUninstall : True CanQuietUninstall : False ### History | Author | Date | Version | Release Notes | | --- | --- | --- | --- | | Anthony Maxwell | 09/11/2023 | 1.0.0 | - Initial Release. | | Anthony Maxwell | 10/24/2023 | 1.0.1 | - Explicit typing tweaks. - Help text overhaul. | ## New-Win32App ### Overview Creates a Win32 application object using the provided args. Primarily used internally by Get-Win32App. ### Cmdlet Attributes Alias : ['nw32a'] CmdletBinding : [] ### Parameters Name : `System.String` The name of the Win32 application. Attributes Parameter : [Mandatory, Position = 0] AllowEmptyString : [] --- Scope : `System.String` The Scope of the Win32 application. Attributes Parameter : [Mandatory, Position = 1] ValidateSet : ['USER', 'MACHINE'] --- Username : `System.String` The username relative to the Win32 application - primarily used for software installs residing in one or more user profiles. Attributes Parameter : [] --- Version : `System.Version` The version of the Win32 application. Attributes Parameter : [] --- Publisher : `System.String` The publisher of the Win32 application. Attributes Parameter : [] --- InstallDate : `System.DateTime` The install date for the Win32 application. Attributes Parameter : [] --- InstallLocation : `System.String` The path to the root of the application's files. Attributes Parameter : [] --- UninstallArgs : `System.Collections.Hashtable` A `[ System.Hashtable ]` containing keys: 1. `FilePath` - `[ System.String ]` path to the uninstaller. 2. `ArgumentList` - A `[ System.Array ]` of `[ System.String ]` containing optional arguments to be provided to the uninstaller referenced above in `FilePath`. Attributes Parameter : [] --- QuietUninstallArgs : `System.Collections.Hashtable` A `[ System.Hashtable ]` containing keys: 1. `FilePath` - A `[ System.String ]` path to the uninstaller. 2. `ArgumentList` - A `[ System.Array ]` of `[ System.String ]` containing optional arguments to be provided to the uninstaller referenced above in `FilePath`. ** NOTE: The ArgumentList for this parameter should include all necessary command-line arguments to perform a silent uninstall ** Attributes Parameter : [] --- IsMSI : `System.Boolean` An indication of whether the uninstall package for the application is an MSI installer. Attributes Parameter : [] --- VarArgs : `System.Object[]` A `[ System.Array ]`, which must be provided in groups of two, to create any additional Win32App properties that may be useful to specific automation endeavors. Attributes Parameter : [ValueFromRemainingArguments] --- ### Output **Type:**`[ System.Management.Automation.PSObject ]` A PSObject containing all provided arguments and methods for application Uninstall and QuietUninstall. ### History | Author | Date | Version | Release Notes | | --- | --- | --- | --- | | Anthony Maxwell | 09/11/2023 | 1.0.0 | - Initial Release. | | Anthony Maxwell | 09/14/2023 | 1.0.1 | - Documentation pass. | ## Remove-Win32App ### Overview Performs an uninstall of the provided application. ### Cmdlet Attributes CmdletBinding : [SupportsShouldProcess] Alias : ['rw32a'] ### Parameters Application : `System.Management.Automation.PSObject` The PSObject, as returned by `Get-Win32App`, to be uninstalled. Attributes Alias : ['app'] Parameter : [Mandatory, ValueFromPipeline, Position = 0] --- Interactive : `System.Management.Automation.SwitchParameter` If provided, the uninstall requires console session interaction to proceed. ** WARNING: this switch CANNOT be used if invoked from a Worklet script, yet. ** Attributes Alias : ['i'] Parameter : [Position = 1] --- AdditionalArgs Additional command line arguments to be provided to the application to perform the uninstall. Default: `@()` Attributes Parameter : [Position = 2] Alias : ['aa'] --- ### Output **Type:**`[ System.Management.Automation.PSObject ]` A PSObject containing the uninstaller exit code, provided file path and uninstall args used. ### Example PS> Get-Win32App | Where-Object { $_.Name -match 'Google Chrome' } | Remove-Win32App ### History | Author | Date | Version | Release Notes | | --- | --- | --- | --- | | Anthony Maxwell | 09/11/2023 | 1.0.0 | - Initial Release. | | Anthony Maxwell | 09/14/2023 | 1.0.1 | - Documentation pass. | --- # Tutorials & Introductions _Section: Developer • Source: https://docs.automox.com/product/Content/Developer/Tutorials%20%26%20Introductions.htm_ Here is a list of helpful tutorials and resources to help you work with the Automox APIs and with PowerShell. ## Postman Tutorials - [Postman Learning Center](https://learning.postman.com/) ## Stoplight Tutorials - [Intro to Stoplight Studio OpenAPI Designer](https://www.youtube.com/watch?v=7olnV8rR1xc) ## PowerShell Tutorials and Documentation - [Windows Administration with PowerShell](https://www.automox.com/resources/search?search=Windows%20Administration%20with%20Powershell) - [Introduction to PowerShell - Microsoft Learn](https://docs.microsoft.com/learn/modules/introduction-to-powershell?WT.mc_id=modinfra-10826-thmaure) - [PowerShell Documentation - Microsoft](https://docs.microsoft.com/en-us/powershell/) --- # Using Global API Keys _Section: Developer • Source: https://docs.automox.com/product/Content/Developer/Using%20Global%20API%20Keys.htm_ Automox has added Global API Keys, which allow customers to use Automox APIs across all organizations under their account, rather than for a single organization. Note that some API endpoints continue to accept a regular organization API key, assuming that endpoint is only checking permissions at the account and/or global scopes. **Important:****Keep API Keys Secure!** Depending on your role, your API key may be able to modify users, devices, and policies. API keys should be kept secure and not shared to prevent unforeseen changes or potential security issues. Never email or write down your API key. ## API Keys Overview Automox supports two types of API keys: Organization API Keys and Global API Keys. ### Organization API Keys - Created within a specific organization. - Can only be used when making requests to that same organization. - The access granted matches the permissions of the user who created the key within that organization. Some API endpoints continue to accept a regular organization API key, assuming that endpoint is only checking permissions at the account and/or global scopes. ### Global API Keys - Valid across all organizations within your Automox account. - When used, they inherit the permissions that the key owner has in the organization being targeted by the request. - This means your access level depends on your assigned permissions in whichever organization the API call is directed to. #### Quick Example - If you create an Organization API Key in Org A, you can always use it for API calls targeting Org A, but not necessarily for API calls targeting Org B. - If you create a Global API Key, you can use it to make API calls against Org A, Org B, or any other org in your account. The permissions applied in each case match your role in the org you are targeting. ## Permissions and Scopes Automox has various permissions that have scopes associated with them. Some permissions are can only be attached at a specific scope, whereas other permissions can attached at any combination of account, global, organization scopes. Additionally, some permissions have conditions that must be met to use the API. Automox has added information about the required permissions to the API endpoints. See the following table for a listing of permissions and scopes. Note that devices are the same thing as endpoints. For the purposes of this document, we are listing the permissions as they are listed on the Automox console. API responses will use the term "endpoint" for device permissions. | Endpoint | Required Permission | Scope | Conditions | Documentation Notes | | --- | --- | --- | --- | --- | | GET /servers/{id}/queues | devices:read | Organization | | View upcoming commands for a specific device | | POST /servers/{id}/queues | devices:manage | Organization | | Force immediate scan/patch/reboot on a device | | GET /servers | devices:read | Organization | | List all devices in organization | | GET /servers/{id} | devices:read | Organization | | View specific device details | | PUT /servers/{id} | devices:manage | Organization | | Update device configuration | | DELETE /servers/{id} | devices:delete | Organization | | Remove device from organization | | POST /servers/batch | devices:manage | Organization | | Update multiple devices in batch | | GET /device-details/orgs/{org_UUID}/devices/{device_UUID}/inventory | devices:read | Organization | | View device software inventory | | GET /device-details/orgs/{org_UUID}/devices/{device_UUID}/categories | devices:read | Organization | | View device software categories | | GET /servers/{id}/packages | package:read | Organization | | View software packages for specific device | | GET /orgs/{id}/packages | package:read | Organization | | List all packages for organization | | GET /worklet-catalog | custom_policy:read | Organization | | View worklet catalog (deprecated feature) | | GET /worklet-catalog/{uuid-legacy_id} | custom_policy:read | Organization | | View specific worklet (deprecated feature) | | GET /servergroups | server_group:read | Organization | | List all server groups | | POST /servergroups | server_group:create | Organization | | Create new server group | | GET /servergroups/{id} | server_group:read | Organization | User must be affiliated with the group | View specific server group | | PUT /servergroups/{id} | server_group:modify | Organization | User must be affiliated with the group | Update server group | | DELETE /servergroups/{id} | server_group:delete | Organization | User must be affiliated with the group | Delete server group | | GET /approvals | approval:read | Organization | | List manual approval requests | | PUT /approvals/{id} | approval:update | Organization | | Update manual approval status | | GET /events | organization:read | Organization | | View organization event logs | | GET /data-extracts | report:read | Organization | | List data export jobs | | POST /data-extracts | report:read | Organization | | Create new data export job | | GET /data-extracts/{id} | report:read | Organization | | View specific data export job | | GET /data-extracts/{id}/download | report:read | Organization | | Download completed data export | | GET /orgs | organization:read | Account OR Global OR Organization | | List the organizations in the account that the authenticated user has access to. Note: if a user doesn't have "devices:add" org-scoped permission, the corresponding org data is still returned, but no access key attached. Also, any orgs that the user doesn't have org:read permission in in rbac-cr are filtered out. | | GET /policies | Multiple policy types:read | Organization | | Requires read permission for patch_policy, required_software_policy, and/or custom_policy depending on policy types | | POST /policies | Multiple policy types:create | Organization | | Requires create permission for the specific policy type being created | | GET /policies/{id} | Multiple policy types:read | Organization | | Requires read permission for the specific policy type | | PUT /policies/{id} | Multiple policy types:modify | Organization | | Requires modify permission for the specific policy type | | DELETE /policies/{id} | Multiple policy types:delete | Organization | | Requires delete permission for the specific policy type | | POST /policies/{id}/files | Multiple policy types:modify | Organization | | Upload files to policies | | POST /policies/{id}/action | Multiple policy types:execute | Organization | | Execute policy immediately | | POST /policies/device-filters-preview | devices:read | Organization | | Preview devices matching filter criteria | | GET /policystats | report:read | Organization | | View policy compliance statistics | | GET /orgs/{id}/api_keys | all_api_keys:list | Organization | | List all API keys for organization | | GET /users/{userId}/api_keys/{id} | all_api_keys:read OR user_api_key:manage | Organization | all_api_keys:read for admin access, user_api_key:manage for own keys | View API key details | | PUT /users/{userId}/api_keys/{id} | all_api_keys:modify OR user_api_key:manage | Organization | all_api_keys:modify for admin access, user_api_key:manage for own keys | Enable/disable API key | | POST /users/{userId}/api_keys/{id}/decrypt | user_api_key:manage | Organization | User must own the API key | Decrypt API key value | | GET /users | users:read | Account OR Global | | List users | | POST /users | None | None | No authentication required | Public user registration | | GET /users/{id} | users:read | Account OR Global | No permission required if viewing own user data | View user details | | PUT /users/{userId} | users:modify OR None | Organization OR None | users:modify for admin updates, no permission required for self-updates | Update user (full replacement) | | PATCH /users/{userId} | users:modify OR None | Organization OR None | users:modify for admin updates, no permission required for self-updates | Update user (partial update) | | DELETE /users/{id} | users:delete | Organization | Cannot delete own account | Delete user | | GET /users/self | None | None | Authentication required only | View own user profile | | GET /accounts/{accountId}/rbac-roles | role:read | Global | | List available RBAC roles | | GET /accounts/{accountId} | account:read | Account | | View account information | | GET /accounts/{accountId}/users/{userId} | users:read | Account OR Global | No permission required if viewing own data | View account user details | | DELETE /accounts/{accountId}/users/{userId} | users:delete | Required at every scope where user has role assignments | | Remove user from account | | POST /accounts/{accountId}/invitations | users:invite | Required at every scope where role assignments will be made | | Invite user to account with zone access | | GET /accounts/{accountId}/users/{userId}/zones | organization:read | Account OR Global | | List zones user has access to | | POST /accounts/{accountId}/zones | organization:create | Account | | Create new zone | | GET /accounts/{accountId}/zones | organization:read | Account OR Global | | List account zones | | GET /accounts/{accountId}/zones/{zoneId} | organization:read | Organization | | View specific zone details | | GET /accounts/{accountId}/zones/{zoneId}/users | users:read | Organization | | List users in zone | | GET /orgs/{orgID}/remediations/action-sets/upload/formats | remediation:read | Organization | | List supported CSV upload formats | | POST /orgs/{orgID}/remediations/action-sets/upload | remediation:create | Organization | | Upload vulnerability remediation CSV | | GET /orgs/{orgID}/remediations/action-sets/{actionSetID} | remediation:read | Organization | | View specific action set | | DELETE /orgs/{orgID}/remediations/action-sets/{actionSetID} | remediation:delete | Organization | | Delete action set | | GET /orgs/{orgID}/remediations/action-sets/{actionSetID}/solutions | remediation:read | Organization | | List solutions in action set | | GET /orgs/{orgID}/remediations/action-sets/{actionSetID}/issues | remediation:read | Organization | | List issues found during import | | GET /orgs/{orgID}/remediations/action-sets | remediation:read | Organization | | List all action sets | | DELETE /orgs/{orgID}/remediations/action-sets | remediation:delete | Organization | | Bulk delete action sets | | POST /orgs/{orgID}/remediations/action-sets/{actionSetID}/actions | remediation:execute | Organization | | Execute remediation actions | | GET /reports/prepatch | report:read | Organization | When using groupId parameter, user must have report:read permission on the group's organization | View pre-patch report | | GET /reports/needs-attention | report:read | Organization | | View devices needing attention report | | POST /policies/{policyID}/clone | Source policy read permission + target policy create permission | Multiple Organizations | Requires read permission on source policy type and create permission for same policy type in all target organizations | Clone policy to multiple organizations | | DELETE /users/{userId}/api_keys/{id} | all_api_keys:delete OR user_api_key:manage | Organization | all_api_keys:delete for admin access, user_api_key:manage for own keys | Delete API key | | GET /wis/search | None (only need to be authenticated) | N/A | | Search worklets by query | | GET /wis/search/{id} | None (only need to be authenticated) | N/A | | Load a worklet by UUID/Legacy id/Alias | | POST /config/consent/account/{accountUUID}/org/{orgUUID}/device | remote_control_consent:manage | Organization | | Exclude/include a device from remote consent | | DELETE /global/api_keys/{key_id} | user_api_key:manage OR all_api_keys:delete | Account OR Global | If the user only has the user_api_key:manage permission, the user must own the key in order to delete it. | | | GET /global/api_keys | user_api_key:manage OR all_api_keys:list | Account OR Global | If a user only has the user_api_key:manage permission, only the keys they own will be returned. | | | POST /global/api_keys | user_api_key:manage | Account OR Global | | | | POST /global/api_keys/{key_id}/decrypt | user_api_key:manage | Account OR Global | The user must own the key in order to decrypt it. | | | PUT /global/api_keys/{key_id} | user_api_key:manage OR all_api_keys:modify | Account OR Global | If the user only has the user_api_key:manage permission, the user must own the key in order to delete it. | | ## Related Topics - [Roles and Permissions Management](../Product Documentation/Global Access Management/Roles_and_Permissions.htm) - [Managing Global Keys](../Product Documentation/Global Access Management/Managing Global Keys.htm) --- # Frequently Asked Questions _Section: Developer • Source: https://docs.automox.com/product/Content/Developer/WDK%20FAQs.htm_ ## Does WDK support script signing? Yes! All module files are signed using Automox's PKI. ## Does WDK support Linux? Currently, WDK is only designed to target Windows. Stay tuned, though, as a Bash implementation is underway for release in the very near future! ## Can I contribute to WDK? Currently, **direct code** contribution to WDK is not possible. This is a concept Automox will continue to evaluate as the WDK function collection grows and adoption increases. **In the meantime, any potential feedback or contributions are welcome and greatly appreciated over on the [Automox Community in the Worklets section](https://community.automox.com/worklets-99).** --- # Welcome to the Worklet Development Kit (WDK)! _Section: Developer • Source: https://docs.automox.com/product/Content/Developer/WDK%20Overview.htm_ ## Summary Welcome to the Automox Worklet Development Kit (WDK) developer docs! This module covers: - An overview of what WDK is - The value WDK can provide to your organization - How to implement WDK capability ## What is WDK? WDK, at the most basic level, is a PowerShell module designed, deployed & maintained by the Automox team. This module has four major points of focus: - Eliminating PowerShell, C# and other programming language knowledge barriers to achieving complex outcomes. - Creating a consistent and intuitive expectation of code execution - *Example: consistent definition of what constitutes a terminating error* - Eliminating copy/paste recycling of frequently implemented "boilerplate" code. - Infusing all the above with raw programmatic and cybersecurity best-practices, where possible. ## What Value does WDK Offer? WDK offers the ability to: - Accelerate workplace automation development - Broaden horizons of what can be achieved through workplace automation, regardless of programming experience - Achieve the above with the added peace of mind that the Automox team produces this functionality team through processes, both manual and automated, designed to thoroughly test, vet, scrutinize and enforce both raw functionality and secure design. ## How can I Implement WDK Capability? The automated deployment processes implemented for WDK make its functionality available to any and all **Windows** Worklets with no manual steps required, other than simply calling the function. We recommend reviewing the [Getting Started](Getting Started with WDK!.htm) page to review sample function implementation. --- # WinSession _Section: Developer • Source: https://docs.automox.com/product/Content/Developer/WinSession.htm_ ## Send-ActiveUserMessage ### Overview Displays a message to the active user on the device. ### Description BY DEFAULT, this function: - Send a message to the user on the screen with the specified Title and Message - The dialog box contains only the 'OK' response - The dialog box times out in 60 seconds ### Cmdlet Attributes CmdletBinding : [] ### Parameters Title : `System.String` The title message to be displayed in the message box. Attributes Parameter : [Mandatory, Position = 0] --- Message : `System.String` The message to be displayed in the message box. Attributes Parameter : [Mandatory, Position = 1] --- DialogType : `System.String` The set of options which should be displayed in the message box ( ex: `OK`, `OK` and `Cancel`, etc. ). Default: `'OK'` Attributes Parameter : [Position = 2] ValidateSet : ['AbortRetryIgnore', 'CancelTryContinue', 'OK', 'OKCancel', 'RetryCancel', 'YesNo', 'YesNoCancel'] --- Timeout : `System.Int32` The amount of time to wait before returning a `[ MESSAGE_RESPONSE ]` value indicating a timeout was reached. Default: `60` Attributes Parameter : [Position = 3] --- ### Output **Type:**`[ MESSAGE_RESPONSE ]` The response chosen by the logged-in user ( this includes a timeout ). ### Example PS> Send-ActiveUserMessage -Title 'Luke' -Message 'I AM your father!' -DialogType 'AbortRetryIgnore' -Timeout 60 IGNORE ### History | Author | Date | Version | Release Notes | | --- | --- | --- | --- | | Anthony Maxwell | 09/20/2023 | 1.0.0 | - Inital release. | ## Start-ProcessAsActiveUser ### Overview Starts a Windows process in the context of the logged in, active user. ### Cmdlet Attributes CmdletBinding : [] ### Parameters Path : `System.String` The path to the application to launch. Attributes Parameter : [Mandatory = $true, Position = 0, ValueFromPipeline = $true] --- ArgumentList : `System.String[]` Any command-line arguments which should be passed to the launched application. Default: `@()` Attributes Parameter : [Position = 1] --- WorkingDirectory : `System.String` The path to be used as the working directory by the launched application. Default: `"${env:SystemDrive}\"` Attributes Parameter : [Position = 2] --- ### Output **Type:**`[ System.Boolean ]` Indicates if the process successfully launched. ### Example PS> Start-ProcessAsActiveUser -Path "${env:SystemDrive}\Program Files\8x8 Inc\8x8 Work\8x8 Work.exe" True ### History | Author | Date | Version | Release Notes | | --- | --- | --- | --- | | Anthony Maxwell | 09/21/2023 | 1.0.0 | - Initial release. | ## Test-UserActive ### Overview Determines if a user is actively working on the device through RDP or at the physical console. ### Example PS> Test-UserActive True ### History | Author | Date | Version | Release Notes | | --- | --- | --- | --- | | Anthony Maxwell | 09/20/2023 | 1.0.0 | - Inital release. | --- # Worklet Resources _Section: Developer • Source: https://docs.automox.com/product/Content/Developer/Worklet%20Resources.htm_ Here are some resources to help with creating and using Worklets. - [Community Worklets](https://community.automox.com/community-worklets-12) - [Creating a Worklet](https://docs.automox.com/product/Product_Documentation/Policies/Creating_a_Worklet.htm) - [How to use Worklets](https://docs.automox.com/product/Product_Documentation/Worklets___Required_Software/How_to_Use_Worklets.htm) --- # Policy and Filters, and Policy Scheduling _Section: Developer • Source: https://docs.automox.com/product/Content/Developer/policy_filters_schedule.htm_ --- ## Using Scheduling (POST /policies and PUT /policies) Policy schedules are the decimal value of a binary representation of True/False for each day/week/month. ### Example Days per Week For scheduling days of the week, there are 7 digits with a trailing zero to mark the end. This starts on Sunday and ends on Monday. 1 represents ON and 0 represents OFF for each day of the week. **Sun|Sat|Fri|Thu|Wed|Tue|Mon|TrailingZero** Every Day: 11111110 = 254 Mon/Wed/Fri only: 00101010 = 42 ### Example Weeks per Month Weeks are scheduled similarly to days, except there are 5 digits with a trailing zero. This starts on the 5th week of the month and ends with the 1st week of the month. **5th|4th|3rd|2nd|1st|TrailingZero** Every Week: 111110 = 62 2nd/4th weeks only: 010100 = 20 ### Example Months per Year Months continue the trend with 12 digits with a trailing zero. Starting with December and ending with January. **Dec|Nov|Oct|Sep|Aug|Jul|Jun|May|Apr|Mar|Feb|Jan|TrailingZero** Every Month: 1111111111110 = 8190 Mar/Jun/Sep/Dec = 1001001001000 = 4680 ## Advanced Filters The following filter parameters are valid for advanced filters. Anything else returns a 400. | Left Values | Condition Values | Right Values | | --- | --- | --- | | display-name | contains, does-not-contain | text string | | severity | is, is-not, less-than-or-equal-to, greater-than-or-equal-to | other, none, low, medium, high, critical | | patch-source | is, is-not | windowsupdate, opera, mozilla, adobe, oracle, apple, microsoft | | patch-os | is, is-not | windows, mac, linux | | type | is, is-not | upgrades, updates, update-rollups, service-packs, security-updates, tools, guidance, feature-packs, developer-kits, definition-updates, critical-updates, connectors, application | | patch-days-old | is, is-not, less-than, less-than-or-equal-to, greater-than, greater-than-or-equal-to | Integer between 1 and 180 | ## Device Filters - Filter Parameters The [device filters preview](Automox API Reference.htm#tag/policies/POST/policies/device-filters-preview) allows you to view a preview of devices matching a set of Device Targeting criteria that you define. This correlates to the Device Targeting parameters in the Policy Editor screen available in the UI. You can then use the same parameters to [create a new policy](Automox API Reference.htm#tag/policies/POST/policies), or [update an existing policy](Automox API Reference.htm#tag/policies/PUT/policies/%7Bid%7D), targeting those devices. See the above sections for more info on [Using Scheduling](#Using) and [Advanced Filters](#Advanced). | Field | Supported Operators | Value Type | | --- | --- | --- | | os_family | in, not_in | In, not in: list of strings | | os_version_id | in, not_in | In, not in: list of integers | | ip_addr | like_any, not_like_any | List of strings | | tag | like_any, not_like_any, in, not_in | List of strings | | hostname | like_any, not_like_any | List of strings | | organizational_unit | like_any, not_like_any, in, not_in | List of strings | ### Operators Used in API vs. Operators Used in UI Effective July 22, 2022, for improved usability, the operators used for Device Targeting Filters in the UI will be changed. The operators used for Device Targeting Filters in the API have not changed. The table below explains how they correspond to one another: | API Operator | UI Operator | | --- | --- | | in | Is | | not_in | Is Not | | like_any | Contains | | not_like_any | Does Not Contain | --- # Agent Command Line Guide _Section: Product Documentation › Agents › Agent Installation • Source: https://docs.automox.com/product/Content/Product%20Documentation/Agents/Agent%20Installation/Agent_Command_Line_Guide.htm_ This guide provides instructions on managing the Automox agent via command-line interface across different operating systems. It covers topics such as installation paths, setting access keys, assigning device groups, deregistering devices, checking compatibility, redirecting output, configuring script execution directories, and reinstalling the agent. This guide is essential for users seeking to efficiently control and customize the Automox agent's behavior through command-line operations. ## Operating System Install Locations Based on the operating system, the Automox agent installs to these locations: ### macOS /usr/local/bin/amagent ### Windows C:\Program Files (x86)\Automox\amagent.exe ### Linux /opt/amagent/amagent ## Command Line Help --help You can find basic help information for command line options by executing the following: amagent --help amagent -h ## Setting the Organization Access Key --setkey The access key binds the agent and device to a specific organization in the Automox console. Use this command to move a device from one organization to another, or to change the organization if you provided an incorrect access key during installation. Follow these steps: 1. Deregister the device and set the new access key. See [Managing Keys](../../Settings/Managing_Keys.htm) for information about access keys. /amagent --setkey 2. Restart the Automox agent. Linux: sudo service amagent restart macOS: sudo launchctl bootout system/com.automox.agent sudo launchctl bootstrap system /Library/LaunchDaemons/com.automox.agent.plist Windows: net stop amagent net start amagent ## Assigning a Group to a Device --setgrp This command defines the Automox group to place this agent in when it first connects with the Automox platform. This allows you to add the device to a group and is a no-touch way to specify the policies you want to add to the device. When using the `--setgrp` flag, you must predefine the Default Group/ to the group name that you are providing to the setgrp command. When specifying groups, remember to separate them with a forward-slash / character. Follow these steps: 1. To set the device group to the Engineering group, issue the following command: amagent --setgrp 'Default Group/Engineering' (macOS and Linux) 2. amagent --setgrp "Default Group/Engineering" (Windows) Deregister the agent: amagent --deregister 3. Restart the Automox Agent: Linux: sudo service amagent restart macOS: sudo launchctl bootout system/com.automox.agent sudo launchctl bootstrap system /Library/LaunchDaemons/com.automox.agent.plist Windows: net stop amagent net start amagent ## Deregistering a Device --deregister When the Automox agent runs for the first time, it establishes an identity with the Automox servers using public-key cryptographic methods. If you ever need to reset the agent and have it re-register as a new device, you can deregister the agent. ## Checking for Device Compatibility with Automox After a device connects, Automox runs a compatibility check to ensure that it can successfully manage the device. Each operating system has its own compatibility checklist. For more details about what is passing or failing on the compatibility check, click the Review Checklist link to view the Compatibility Checklist in the Device Details page in the Automox console. To perform this check directly from the device via the agent command line, issue this command: ### For Agent Versions 1.43.142 and Earlier amagent --checkcompat ### For Agent Versions 1.44.5 and Later amagent selftest ## Redirect Agent Output to stdout of a Console This command runs the agent in the current console. Logging is piped to stdout. **Note**: Before running this command, disable the agent service. amagent -c ## Setting the Directory for Executing Scripts The Automox agent uses scripts to execute most of its functions including scanning and patching. These scripts execute from a fixed directory on the local device. By default this is set to the following locations: **Windows**: `C:\Program Files (x86)\Automox\` **macOS**: `/Library/Application Support/Automox/` **Linux**: `/var/lib/amagent` If you prefer these actions to run from a different default path, use an agent command to set that on the device (`--setexecdir`). The next time the Automox agent service restarts, it uses the newly specified location for running its scripts. Some endpoint security applications block scripts that don't originate from a designated location. Therefore, the most common reason to modify this setting is to move it to a trusted or preferred directory for your security software. **Note**: For macOS, do not set the execdir to any directory or subdirectory of a user’s Desktop, Downloads, or Documents folder. Temporary directories created for executing commands are not cleaned up if they are in an OS protected special location. See also[Control access to your files and folders on Mac](https://support.apple.com/en-gb/guide/mac-help/mchld5a35146/10.15/mac/10.15). Output from `amagent --help`: automox@ubuntu:/opt/amagent$ ./amagent --help amagent 1.0-28 (go1.12.4) Copyright (c) 2019 Automox, Inc.usage: [--setkey <accesskey>] Sets the access key [--setgrp <groupname>] Sets the initial group name [--setexecdir <directory>] Sets the temporary directory to execute scripts from [--deregister] Deregisters this server from Automox [--checkcompat] Checks the compatibiltiy and connectivity with Automox server # Only versions 1.43.142 and earlier [selftest] Checks the compatibiltiy and connectivity with Automox server # Only versions 1.44.5 and later [-c] Runs the agent in the current console. Logging is piped to stdout. # (It is recommend to disable the agent service before running with this command) [-h | --help] Displays this message **Note**: To restore the default, you can set the original directory path in the same manner as a new one. ## Reinstalling the Automox Agent To reinstall the Automox agent, ensure that you first deregister and then remove the agent. 1. Deregister the agent as described earlier in [Deregistering a Device](#Deregist). 2. Remove the agent. See [Removing the Automox Agent](Removing_the_Automox_Agent.htm). 3. Follow the instructions in [Automox Agent Installation Overview](Automox_Agent_Installation_Overview.htm) for your device. --- # Automox Agent Installation Overview _Section: Product Documentation › Agents › Agent Installation • Source: https://docs.automox.com/product/Content/Product%20Documentation/Agents/Agent%20Installation/Automox_Agent_Installation_Overview.htm_ Before you can use the Automox Console to manage devices in your organization, you need to install the Automox Agent. This small application runs in the background on each device, keeping your systems up to date with all critical patches. You can install the agent through an onboarding wizard, which uses unique identifiers to detect the devices that belong to your organization. After you install the agent, you can set up an initial policy and schedule. After you set up the first system, you can view its hardware and software inventory on the Devices page. You can continue adding devices right from the Dashboard (see Related Topics). **Note**: For agent releases, Automox follows industry standards for major, minor, and patch. Automox provides release notes for all major and minor releases. ## Installing the Automox Agent Before you can use the Automox Console to manage devices in your organization, you need to install the Automox Agent. See also [Supported Operating Systems](../Agent Requirements/Supported_Operating_Systems.htm). --- # Deploy the Latest Automox Agent using PowerShell or MSI via Windows GPO Policy _Section: Product Documentation › Agents › Agent Installation › Bulk Agent Deployment • Source: https://docs.automox.com/product/Content/Product%20Documentation/Agents/Agent%20Installation/Bulk%20Agent%20Deployment/Deploy_the_Latest_Automox_Agent_using_a_Powershell_Script_via_Windows_GPO_Policy.htm_ Using a Windows GPO policy, and a PowerShell script or MSI file, you can deploy the Automox Agent in bulk to your Windows devices. You can configure the GPO policy to either run at login, or have it run as a scheduled task. ## Prepare Your Installer [Download](https://github.com/AutomoxCommunity/se-utilities-public/blob/main/Scripts/Install-AXAgentMSI.ps1) the Automox Installer PowerShell script directly to your local device or Windows Server. If file transfers from your local device to the server are restricted, run the download process directly on the Windows Server. You can find the latest file downloads here: [Download Links for the Latest Automox Installers](../Download_Links_for_the_Latest_Automox_Installers.htm). Alternatively, you can use the PowerShell script method to download the latest version. If you modified the MSI file to include the access key, you must do this again after downloading a newer MSI file. - Run at Login - Scheduled Task ## Create Your GPO - Run at Login To create your GPO, you can either use the PowerShell script option, or use the MSI installer. ### Option A: PowerShell Script 1. Store the script file in a location that is accessible to your target devices. You can use the SYSVOL directory or a network share that is accessible to your device. 2. Create a new Group Policy Object (GPO) and add the script to your GPO. The path is **Computer Configuration → Policies → Windows Settings → Scripts (Startup/Shutdown)** 3. From the right pane, double-click **Startup**. 4. In the dialog box, click the **PowerShell Scripts** tab then click **Add...**. ![](../../../../Resources/Images/win-gpo-addscript.png) 5. Click **Browse** to locate the script file and click **Open**. 6. Edit the following script parameter by adding your Automox access key. Enter the parameter in the **Script Parameters** field and save the script. -AccessKey your-access-key-goes-here 7. After you set these values, you can assign the GPO to your target audience. On startup, the script checks for the agent. If it's not present, it downloads, installs, and starts the service. If it's already there, it takes no further action. ### Option B: MSI Installer With a minor modification, you can deploy the Automox Installer MSI using the Software Installation GPO. This method requires that you include your Automox access key as a parameter. Since deployment using this method doesn't allow for command line arguments, you must either create a Transform file (.mst) or modify the installer file to include the access key. Follow these steps to deploy the installer: 1. For details about modifying the MSI file, see [Embedding Your Access Key into the Automox MSI](../Embedding_Your_Access_Key_into_the_Automox_MSI.htm). 2. After you modify the MSI file, store it in a location that is accessible to your target devices. This requires that you store this in your SYSVOL directory or set up a network share that is accessible to your devices. 3. When your file is in the desired location, add the file to your GPO. The path is **Computer Configuration → Policies → Software Settings → Software Installation → New → Package...** ![](../../../../Resources/Images/win-gpo-newpackage.png) 4. Browse to and select the modified MSI file and click **OK**. 5. In the next dialog box select **Assigned** then click **OK**. 6. After you set these values, assign the GPO to your desired audience. **Note:** You should periodically update this deployment to use the latest Automox installer. An outdated MSI file does not harm existing installations, but installing the latest version when possible is best. ## Create Your GPO - Scheduled Task How to bulk deploy the Automox agent using Windows Group Policy for devices that connect to company networks through a VPN. Remote computers connecting to company networks through a VPN present a challenge for the most common GPO solutions. Many VPNs do not automatically connect at startup. Due to the way Startup scripts and GPO MSI installations policies are designed, they most likely fail to apply for remote devices. Here is an alternative method to use Active Directory GPOs to deploy the Automox agent for your remote users. ### The Challenge You must distribute the file and then install it with elevated rights. Preferably, this should be fully automated. ### The Solution Leverage Group Policy preferences to distribute a PowerShell script to each device, and then after it is in place, create a scheduled task to run the installation. #### Distribute the File 1. Create a new GPO, and open the **Group Policy Management Editor**. 2. Navigate to **Computer Configuration → Preferences → Windows Settings → Files** 3. Right click **Files** and select **New → File** 4. From the **General** tab, update the following: - Source Files: `\\YOUR_DOMAIN.COM\NETLOGON\Install-AXAgentMSI.ps1` - Destination File: `C:\Windows\Temp\Install-AXAgentMSI.ps1` **Note:** Leave the rest of the General settings as default. 5. From the **Common** tab, select the checkbox for **Remove this item when it is no longer applied**. This cleans up the MSI file when the policy is no longer applied. 6. Create a new GPO, and open the **Group Policy Management Editor**. 7. Navigate to **Computer Configuration → Preferences → Control Panel Settings → Scheduled Tasks** 8. Right click **Scheduled Tasks** and select **New → Scheduled Task** (Windows 7 or later) 9. Click the **General** tab, update the following: - Select the Action: **Replace** - Enter a name and optional description. - Set the user account to `NT AUTHORITY\System` - Run whether logged in or not and with the highest privileges. ![](../../../../Resources/Images/create-gpo-axinstall-prop.png) 10. Click the **Triggers** tab, start a new trigger and set the following: - Begin the task: **At task creation/modification** - Clear the checkbox **Delay task for:** - Select **Stop task if it runs longer than:** and set to **1 hour** - Set the preferred activate time and select the checkbox - Set to Enabled ![](../../../../Resources/Images/create-gpo-triggers-prop.png) 11. Click the **Actions** tab and start a program with these settings: - **Program/script:** `C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe` - **Add arguments (with quotes):**` "C:\Windows\Temp\Install-AXAgentMSI.ps1" "-AccessKey YOUR_AUTOMOX_KEY"` ![](../../../../Resources/Images/create-gpo-actions.png) - Your Automox access key is in your console under **Devices → Add Devices**. 12. Click the **Conditions** tab. - Select Start only if the following network connection is available: Any connection ![](../../../../Resources/Images/create-gpo-conditions.png) 13. Click the **Settings** tab and select the following: - Stop the task if it runs longer than: 1 hour - If the running task does not end when requested, force it to stop. - If the task is already running, then the following rule applies: Do not start a new instance. ![](../../../../Resources/Images/create-gpo-settings.png) 14. Click the **Common** tab and select the following: - Remove the item when it is no longer applied. - **Item-level targeting →** click **Targeting** - In the Targeting Editor, click **New Item → File Match**. - For Match type, select File exists - In the Path field enter: `C:\Windows\Temp\Install-AXAgentMSI.ps1` ![](../../../../Resources/Images/create-gpo-common.png) - After you set these values, assign the GPO to your desired audience. #### Additional Group Handling If you need to add devices that you deploy with the GPO policy to a specific Group in Automox, you can amend the arguments in Step 6 with the following: C:\Windows\Temp\Install-AXAgentMSI.ps1" "-AccessKey YOUR_AUTOMOX_KEY" "-GroupName 'My Group Name'" "-ParentGroupName 'My Parent Group Name' **Note**: `ParentGroupName `is only required if the target Group is a child Group in the Automox Console. ## Related Topics - [Embedding Your Access Key into the Automox MSI](../Embedding_Your_Access_Key_into_the_Automox_MSI.htm) - [Download Links for the Latest Automox Installers](../Download_Links_for_the_Latest_Automox_Installers.htm) --- # Deploying Automox via VMware Workspace ONE _Section: Product Documentation › Agents › Agent Installation › Bulk Agent Deployment • Source: https://docs.automox.com/product/Content/Product%20Documentation/Agents/Agent%20Installation/Bulk%20Agent%20Deployment/Deploying_Automox_via_VMware_Workspace_ONE.htm_ This document describes how to deploy the Automox agent through VMware Workspace ONE. The recommended deployment of the Automox agent consists of following 3 configurations. ## Create or Modify Existing Notification Profile Notification configuration profiles are supported by macOS, which ensures delivery of Automox notifications. If no notification payload currently exists, create a new profile with Custom Settings using the following content to allow all Automox and Microsoft Office notification to run: NotificationSettings AlertType 2 BadgesEnabled BundleIdentifier com.automox.automox-notifier CriticalAlertEnabled GroupingType 0 NotificationsEnabled ShowInLockScreen ShowInNotificationCenter SoundsEnabled AlertType 1 BadgesEnabled BundleIdentifier com.microsoft.Word CriticalAlertEnabled GroupingType 0 NotificationsEnabled ShowInLockScreen ShowInNotificationCenter SoundsEnabled AlertType 1 BadgesEnabled BundleIdentifier com.microsoft.Excel CriticalAlertEnabled GroupingType 0 NotificationsEnabled ShowInLockScreen ShowInNotificationCenter SoundsEnabled AlertType 1 BadgesEnabled BundleIdentifier com.microsoft.Powerpoint CriticalAlertEnabled GroupingType 0 NotificationsEnabled ShowInLockScreen ShowInNotificationCenter SoundsEnabled AlertType 1 BadgesEnabled BundleIdentifier com.microsoft.Outlook CriticalAlertEnabled GroupingType 0 NotificationsEnabled ShowInLockScreen ShowInNotificationCenter SoundsEnabled AlertType 1 BadgesEnabled BundleIdentifier com.microsoft.onenote.mac CriticalAlertEnabled GroupingType 0 NotificationsEnabled ShowInLockScreen ShowInNotificationCenter SoundsEnabled AlertType 1 BadgesEnabled BundleIdentifier com.microsoft.OneDrive CriticalAlertEnabled GroupingType 0 NotificationsEnabled ShowInLockScreen ShowInNotificationCenter SoundsEnabled AlertType 1 BadgesEnabled BundleIdentifier com.microsoft.OneDrive-mac CriticalAlertEnabled GroupingType 0 NotificationsEnabled ShowInLockScreen ShowInNotificationCenter SoundsEnabled AlertType 1 BadgesEnabled BundleIdentifier com.microsoft.autoupdate.fba CriticalAlertEnabled GroupingType 0 NotificationsEnabled ShowInLockScreen ShowInNotificationCenter SoundsEnabled PayloadDescription Configures notifications PayloadDisplayName Configures notifications PayloadIdentifier com.apple.notificationsettings.AE35A3DC-56BC-48EB-8C4D-F4C5AE4D1C5C PayloadType com.apple.notificationsettings PayloadUUID AE35A3DC-56BC-48EB-8C4D-F4C5AE4D1C5C PayloadVersion 1 If you have an existing Notifications profile (macOS only supports a single notifications profiles), add the previous content in your existing NotificationSettings array. ![](../../../../Resources/Images/vmware-custom-settings.png) ## Create an Automox Privacy Preferences Profile Automox leverages the Microsoft AutoUpdate Tool to handle Microsoft Office updates. To ensure the Automox agent is also granted access to this, you must create a Privacy Preferences Profile. 1. Devices → Profiles and Resources → Profiles 2. Add Profile 3. Apple macOS 4. Device Profile 5. Select **Privacy Preferences** 6. Add App **Identifier**: `/usr/local/bin/amagent` **Identifier Type**: `Path` **Code Requirement**: `identifier "com.automox.agent" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = DAEQ58A4ES` **Static Code Validation**: `Off` **Apple Events**: `Allow` **Receiver Identifier**: `com.microsoft.autoupdate2` **Receiver Identifier Type**: `Bundle ID` **Receiver Code Requirement**: `identifier "com.microsoft.autoupdate2" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = UBF8T346G9` For best results, be sure to install the latest version of the Automox agent. ## Deploy the Automox Agent as a Native Application 1. Install the VMware Workspace ONE Admin Assistant [https://docs.vmware.com/en/VMware-Workspace-ONE-UEM/1904/Software_Distribution/GUID-AWT-ADMINASSIST.html](https://docs.vmware.com/en/VMware-Workspace-ONE-UEM/1904/Software_Distribution/GUID-AWT-ADMINASSIST.html) 2. Download the latest Automox Agent 3. Pull the Automox Agent pkg file into the Admin Assistant 4. Open the generated plist file ![](../../../../Resources/Images/vmware-open-plist.png) 5. Find the `display_name` and `name` keys and remove the trailing version characters (they should read `AutomoxAgent`). (Workspace ONE does not support dashes in display names) Before: ![](../../../../Resources/Images/vmware-name-before.png) After: ![](../../../../Resources/Images/vmware-name-after.png) 6. Automox also recommends modifying the `version` keys to remove the “-” and use only “.” (example: 1.0.41). This allows the version information to properly display in Workspace ONE. **Note**: Do not modify the `installer_item_location` value as that points to the installer pkg file. 7. Save file. 8. Add a Native Application to Workspace ONE. 9. Upload the Automox pkg installer file. ![](../../../../Resources/Images/vmware-ax-pkginstall.png) 10. Upload the plist as the "Metadata File" ![](../../../../Resources/Images/vmware-plist-metadatafile.png) 11. For automated installations, add the following code to the "Post Install Script" #!/bin/bash /usr/local/bin/amagent --setkey "ENTER_AUTOMOX_ACCESS_KEY_HERE" /usr/local/bin/amagent --setgrp "Default Group/ENTER_GROUP_NAME_HERE" sudo launchctl bootout system/com.automox.agent sudo launchctl bootstrap system /Library/LaunchDaemons/com.automox.agent.plist ![](../../../../Resources/Images/vmware-edit-installscript.png) --- # Deploying the Automox Agent in Bulk _Section: Product Documentation › Agents › Agent Installation › Bulk Agent Deployment • Source: https://docs.automox.com/product/Content/Product%20Documentation/Agents/Agent%20Installation/Bulk%20Agent%20Deployment/Deploying_the_Automox_Agent_in_Bulk.htm_ You can do remote, bulk deployment of the agent using scripts for the tools available for each supported operating system. ## OS Deployment Scripts You can use scripts to deploy to devices for each of the supported operating systems. You must add your access key to a specific section of the script before running it. **Prerequisites**: Administrative privileges required. The deployment tool or target device must have administrator privileges to successfully deploy and install the Automox agent. **Note**: You need your access key for the following scripts. When adding a new device, the Add Devices window provides the access key. From the console you can also retrieve your access key from the **Settings → Secrets & Keys**tab. ### Deploying on macOS You can deploy the Automox agent on a macOS operating system by using the original command required to download the agent installer. #### Copying the Agent Installer Command Follow these steps to copy the curl command: 1. From the Devices page, click **Add Devices**. 2. In the Add Devices dialog window, you can see your access key. You need this key for the script. 3. Select **macOS** from the drop-down menu. 4. From the install options, click **Run Command**. ![](../../../../Resources/Images/add-device-mac-cmd.png) #### Editing the Run Command for macOS Bulk Deployment To bulk deploy the agent on macOS, you must edit the installer command. Add the following code to the deployment command: **Note**: You must replace `accesskey` in the following command with your access key. You can find your key in the **Add Devices** dialog window. curl -sS "https://console.automox.com/downloadInstaller?accesskey=Your-Access-Key-Here" | sudo bash sudo launchctl bootstrap system /Library/LaunchDaemons/com.automox.agent.plist ### Deploying on Windows Using PowerShell You can deploy the Automox agent using the following Windows PowerShell script. This performs an unattended, silent install of the Automox agent on Windows devices. This script performs the following actions: 1. The script downloads the agent from Automox if it hasn't already been downloaded. 2. The script installs the agent on the device if it isn't already installed. 3. The script starts the Automox agent service if it is stopped. **Windows PowerShell Script** 1. Download the installer script from this page: [Install-AxAgentMsi.ps1](https://github.com/AutomoxCommunity/se-utilities-public/blob/main/Scripts/Install-AXAgentMSI.ps1). This script takes the following command line parameters: -AccessKey YOUR-ACCESS-KEY-HERE This is a required parameter that associates the device with your Automox organization. 2. Optionally, if you want your device to join a group at the time of installation, you need to specify a destination Group Name and a Parent Group Name. **Note**: Your destination group can either be under a parent group or stand alone. A parent group parameter is only required if the destination group is under a parent group. If you do not specify a parent group, it ignores the group assignment See the code examples here: **Example 1**: Deploy the Automox agent to your organization inside the group "Accounts Payable", which belongs to a parent group "Finance". Install-AxAgentMsi.ps1 -AccessKey xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx -GroupName "Accounts Payable" -ParentGroupName "Finance" **Example 2**: Deploy the Automox agent to your organization inside the group "Accounts Payable", which does not belong to a parent group. Install-AxAgentMsi.ps1 -AccessKey xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx -GroupName "Accounts Payable" **Example 3:** Deploy the Automox agent for your organization inside the default group. Install-AxAgentMsi.ps1 -AccessKey xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx #### Debugging the Installation Process If you need to debug the installation process performed by this script, you can find logging information in the following file on the device: $env:TEMP\Install-AxAgentMsi.log ### Deploying on Linux You can deploy the Automox agent on a Linux operating system by using the original command required to download the agent installer. #### Copying the Agent Installer Command Follow these steps to copy the curl command. 1. From the Devices page, click **Add Devices**. 2. In the **Add Devices** dialog window, you can see your access key. You need this key for the script. 3. Select **Linux** from the drop-down list. 4. Copy the curl command. ![](../../../../Resources/Images/add-device-linux.png) #### Editing the Curl Command for Linux Bulk Deployment To bulk deploy the agent for Linux, you must edit the installer command. Add the following to the deployment command: service amagent start **Note**: You must replace `accesskey` in the following command with your access key. You can find your key in the Add Devices dialog window. curl -sS "https://console.automox.com/downloadInstaller?accesskey=Your-ACCESS-Key-Here" | sudo bash service amagent start ## Deploying with Ansible You can distribute the Automox agent with Ansible using the Ansible playbook: [get-automox.yml](https://patch.automox.com/rs/923-VQX-349/images/get-automox.yml). Contact Automox Support for help. From the directory that contains the `get-automox.yml` file, invoke the playbook with the following command, substituting your access key as indicated: ansible-playbook get-automox.yml --extra-vars "organization=YOUR-ACCESS-KEY-HERE ## Deploying with JumpCloud JumpCloud® is a cloud-based Directory-as-a-Service platform that provides authentication, authorization, and management of a company's employees and the systems and IP resources they need access to. The JumpCloud platform provides a Commands tab that lets you run commands across any number of devices. This makes it possible to quickly automate tasks across many servers, launch those tasks based on many different types of events, and get full auditing of all command results. ### macOS Version 1. Navigate to the Commands tab of the JumpCloud console and click the + button to create a new command. 2. Select Mac as the target operating system, provide a name for the command, and in the RUN AS: drop-down list, select root. 3. Paste the deployment script as specified in Deploying on OS X / Mac into the COMMAND: text field. Select the systems or tags to receive the Automox agent, and then press save command to create the command on the JumpCloud platform. 4. Click the Run Now button next to the command you just created to execute the script on all the target devices. 5. The Exit Code (0 = success) appears when the command finishes running on each system. Click the details button to view the execution log. 6. Finally, as the Automox agent registers itself with the Automox platform, you can see the new devices on the Devices page of the Automox console. ### Windows Version 1. Navigate to the Commands tab of the JumpCloud console and click the + button to create a new command. 2. Select Windows as the target operating system. 3. Provide a name for the command and select the target devices to receive the Automox agent. 4. Select Windows PowerShell and copy and paste the script into the script box. 5. Click the Save button to return to the command tab. Your command shows in the list of available commands to run. Click the Run Now button next to the command you just created to execute the script on all target devices. 6. Finally, as the Automox agent registers itself with the Automox platform, you can see the new devices on the Devices page of the Automox console. ### Linux Version 1. Navigate to the Commands tab of the JumpCloud console and click the + button to create a new command. 2. Select Linux as the target operating system, provide a name for the command and in the RUN AS: drop-down list, select root. 3. Paste the deployment script as specified in Deploying on Linux into the COMMAND: text field. Select the systems or tags to receive the Automox agent, and then press save command to create the command on the JumpCloud platform. 4. Click the Run Now button next to the command you just created to execute the script on all the target devices. 5. The Exit Code (0 = success) appears when the command finishes running on each system. Click the details button to view the execution log. 6. Finally, as the Automox agent registers itself with the Automox platform, you can see the new devices on the Devices page of the Automox console. ## Deploying with Chef Use this Chef recipe to deploy the Automox agent: # Note: This will deploy the agent to the Default Group. # To specify a target Automox group, update the options line with the appropriate # GROUP = < group name here > # see: https://help.automox.com/hc/en-us/articles/5352260844564-Silent-Agent-Deployment-on-Windows windows_package 'Automox Installer' do source 'https://console.automox.com/installers/Automox_Installer-latest.msi' retries 2 installer_type :custom options '/qn /norestart ACCESSKEY=insert_your_installer_access_key_here' action :install end --- # Deploying the Automox Agent in Bulk for macOS with Jamf Pro _Section: Product Documentation › Agents › Agent Installation › Bulk Agent Deployment • Source: https://docs.automox.com/product/Content/Product%20Documentation/Agents/Agent%20Installation/Bulk%20Agent%20Deployment/Deploying_the_Automox_Agent_in_Bulk_for_macOS_with_Jamf_Pro.htm_ This article describes how to deploy the Automox agent with Jamf Pro. For Apple Silicon devices, refer to [Install and Configure Automox Agent for Apple Silicon Devices](../Install_and_Configure_Automox_Agent_for_Apple_Silicon_Devices.htm) for information on creating a new local service account and granting secure token access. A local service account with secure token access is required for Apple Silicon devices. ## Install with Automox agent installation package and post-install script Download the Automox agent installation package: 1. From the Automox console, select the **Devices** tab. 2. Click **Add Devices**. 3. Copy the user key from the Add Devices dialog window. 4. Select **macOS** as the operating system. 5. Click **Download Installer**. Download the [Automox post-install script](https://patch.automox.com/rs/923-VQX-349/images/amagent_postinstall.sh). Update the post-install script: - Add the access key you copied in the preceding operation to the accessKey variable in the script. The following procedure uses this script: Deploy with Jamf: 1. Log in to your Jamf Pro server and go to **Computers → Management Settings → Scripts**. 2. Click the **+ New**button in the upper-right corner to create a new script. 3. In the **General** tab, enter your script name and select a category. Include whatever information or notes necessary for your organization. 4. In the **Script** tab, paste the contents of the post-install script that includes your user key. 5. In the **Options** tab, set the priority to **After**. 6. Click **Save** in the lower-right corner to save your script. **To add the Automox agent installer package, continue with these steps:** 7. Navigate to **Computers → Management Settings** and click **Packages.** 8. To add a new package, click **+ New** in the upper-right corner**.** 9. Enter a display name for the package and choose a category from the drop-down menu. 10. Click **Choose File** and upload the Automox agent installer that you downloaded from the Automox console. 11. Fill in any other field used by your organization and click **Save**. After the package is uploaded and available, do the following: 12. To add a new policy, go to **Computer → Policies** and click **+ New.** 13. Enter a name for the policy**.** 14. Set the site, category, trigger, execution frequency, and other required fields. 15. Click **Packages** on the left and add the Automox agent installer package to the policy. 16. Click **Scripts** on the left and add the post-install script. 17. Set the priority of the script to **After**. 18. If you’ve created Smart Groups or extension attributes to detect the installation of the agent, then adding the Update Inventory option from the Maintenance section might be helpful. Otherwise, add a Scope and any desired Self Service or User Interaction settings and save your policy. The Automox agent now starts installing on your scoped Mac devices. ## Repackage the installer for use with Jamf Pro or other MDMs You can repackage the Automox agent installer with a post-install script for use in Jamf Pro, Intune, other MDMs, or manually through several methods. You can repackage the installer using [Jamf Composer](https://www.jamf.com/products/jamf-composer/), Packages, or other similar tools. This example uses [WhiteBox Packages](https://github.com/packagesdev/packages). Download and install Packages from [https://github.com/packagesdev/packages](https://github.com/packagesdev/packages) Download the Automox agent installation package: 1. From the Automox console, select the **Devices** tab. 2. Click **Add Devices**. 3. Copy the user key from the Add Devices dialog window. 4. Select **macOS** as the operating system. 5. Click **Download Installer**. Download the [Automox post-install script for packaging](https://patch.automox.com/rs/923-VQX-349/images/amagent_postinstall_for_packaging.sh). Update the post-install script: - Add the access key you copied in the preceding operation to the accessKey variable in the script. The following procedure uses this script: Repackage Automox installer using Packages: 1. On your computer, launch **Packages** and choose **Raw Package** as the template. 2. Click **Next**. 3. Enter a name and directory for your project, then click **Create**. 4. In the Settings tab, enter an identifier name and version for your installer package. 5. Select "**Require admin password for installation**". 6. In the Scripts tab, choose the updated post-install script under the Post-installation option. 7. Under Additional Resources click the **+** button and add the Automox agent installer. 8. Save the project. 9. From the menu bar, click **Build** and from the drop-down menu click **Build** again. After testing the repackaged installer, follow these steps: 1. Log in to your Jamf Pro server and go to **Computers → Management Settings → Packages.** 2. Click the **+ New** button in the upper-right corner to add a new package. 3. Enter a display name for the package and choose a category from the drop-down menu. 4. **Click Choose File** and upload the repackaged Automox agent installer. 5. Fill in any other field used by your organization and click **Save**. After the package is uploaded and available, do the following: 6. To add a new policy, go to **Computer → Policies** and click **+ New.** 7. Enter a name for the policy**.** 8. Set the site, category, trigger, execution frequency, and other required fields. 9. Click **Packages** on the left and add the repackaged Automox agent installer package to the policy. 10. If you’ve created Smart Groups or extension attributes to detect the installation of the agent, then adding the Update Inventory option from the Maintenance section might be helpful. Otherwise, add a Scope and any desired Self Service or User Interaction settings and save your policy.. The Automox agent now starts installing on your scoped Mac devices. ## Related Topics - [Jamf Pro](https://www.jamf.com/products/jamf-pro/) - [Deploying the Automox Agent in Bulk](Deploying_the_Automox_Agent_in_Bulk.htm) --- # Deploying the Automox Agent to Intune-enrolled Devices _Section: Product Documentation › Agents › Agent Installation › Bulk Agent Deployment • Source: https://docs.automox.com/product/Content/Product%20Documentation/Agents/Agent%20Installation/Bulk%20Agent%20Deployment/Deploying_the_Automox_Agent_to_Intune_enrolled_Devices.htm_ This article describes how to deploy the Automox agent to Intune-enrolled devices. **Prerequisites:** The following applications are required to deploy the Automox agent to Intune-enrolled devices: - Intune - Microsoft Endpoint Manager - Azure AD, P1 or P2 Enterprise License. - Microsoft 365 E3, E5, F1, F3, G3, or G5 license for end users. - Intune/Endpoint Manager administration role in Azure AD. ## Video Walkthrough [https://university.automox.com/microsoft-intune-instructions/1072541](https://university.automox.com/microsoft-intune-instructions/1072541) ## Procedure 1. Log into your AzureAD Instance: [https://aad.portal.azure.com/](https://aad.portal.azure.com/) 2. Create a target group for the application deployment. - Select **All Groups > New group**. ![](../../../../Resources/Images/intune-create-target.png) 3. Specify the group type, name, description, and membership type. - Optionally, add your group members (devices) now. ![](../../../../Resources/Images/intune-new-group.png) 4. Open Microsoft Endpoint Manager: [https://endpoint.microsoft.com/](https://endpoint.microsoft.com/) 5. Click **Apps** on the left-hand panel. ![](../../../../Resources/Images/intune-apps.png) 6. Select your target operating system platform (this example targets Windows devices). ![](../../../../Resources/Images/intune-platform.png) 7. Click **Add**. ![](../../../../Resources/Images/intune-add-win.png) 8. Select LOB (line of business) app from the drop-down menu and click **Select** to confirm. ![](../../../../Resources/Images/intune-apptype.png) 9. Click **Select app package file** then click the blue folder icon from the new window that opens. Select your Automox MSI installer file. Click **OK**. **Note:** You can find the latest Automox installation media for Windows here: [https://console.automox.com/installers/Automox_Installer-latest.msi](https://console.automox.com/installers/Automox_Installer-latest.msi) ![](../../../../Resources/Images/intune-app-pkgfile.png) 10. Confirm your application deployment variables. Set the required **Publisher** field and any other optional fields. ![](../../../../Resources/Images/intune-confirm-var.png) - Enter the command-line argument as noted, where ACCESSKEY is the key to your Automox organization./qn /norestart ACCESSKEY=XXXXXXXXXXXXXX 11. After completing the app information page, click next to associate your target groups. Select **Add Group** under Required. Locate the target you created. Select and confirm it, and click **Next**. ![](../../../../Resources/Images/intune-assoc-target.png) - Optionally, instead of targeting a specific group you can select the **Add all device** option to target all devices within your Azure AD instance. 12. Review your app configuration and click **Create**. ![](../../../../Resources/Images/intune-app-config-save.png) ![](../../../../Resources/Images/intune-app-config-create.png) 13. A confirmation notice is sent when the MSI has been uploaded and the application package has been finalized. ![](../../../../Resources/Images/intune-upload-finish.png) 14. The next time your Intune-enrolled devices that are within your target group check in/sync, they download and install the Automox agent based on the application package that was just created. ## Troubleshooting Steps - [Troubleshooting Intune app installation issues](https://docs.microsoft.com/en-us/troubleshoot/mem/intune/troubleshoot-app-install) ## Related Topics - [Managing Keys](../../../Settings/Managing_Keys.htm) --- # Change Automox Script Execution Location _Section: Product Documentation › Agents › Agent Installation • Source: https://docs.automox.com/product/Content/Product%20Documentation/Agents/Agent%20Installation/Change_Automox_Script_Execution_Location.htm_ Automox executes actions from a fixed location. You can change this location if you prefer. The Automox agent uses PowerShell scripts to execute most of its functions including scanning and patching. These scripts execute from a fixed directory on the local device. By default this is set to the following locations: - **Windows:** - For Agent ≥ 40: - For 32-bit systems: `C:\Program Files\Automox\` - For 64-bit systems: `C:\Program Files (x86)\Automox\ ` - For Agent ≤ 39: - `C:\ProgramData\amagent\ ` - **macOS**: `/Library/Application Support/Automox/` - **Linux**: `/var/lib/amagent` ## Changing the Default Execution Location If you prefer these actions to run from a different default path, you can set that using an agent command on the device (`--setexecdir`) The next time the Automox agent service restarts, it uses the newly specified location for running its scripts. Some endpoint security applications block scripts that don't originate from a designated location. The most common reason to modify this setting is to move it to an allowlist or preferred directory for your security software. ### Windows 64-bit Systems 'C:\Program Files (x86)\Automox\amagent.exe' --setexecdir C:\MyPath\MyDir 32-bit Systems 'C:\Program Files\Automox\amagent.exe' --setexecdir C:\MyPath\MyDir ### macOS /usr/local/bin/amagent --setexecdir /MyPath/MyDir ### Linux /opt/amagent/amagent --setexecdir /MyPath/MyDir --- # Configuring WSUS for Automox Integration _Section: Product Documentation › Agents › Agent Installation • Source: https://docs.automox.com/product/Content/Product%20Documentation/Agents/Agent%20Installation/Configuring_WSUS_for_Automox_Integration.htm_ To configure Windows Server Update Service (WSUS) for Automox, follow these instructions. **Prerequisites**: Configure your desired products and classifications, languages, synchronization schedule, and Automatic approvals. These settings are specific to your environment. ## Configure Update Files and Languages (Local Caching) - The **Update Languages** tab of this wizard is specific to your environment. - Configure the **Update Files** tab as follows: - Select **Store update files locally on this server**>**Download update files to this server only when updates are approved**. ![](../../../Resources/Images/update-files.png) ### Automatic Approvals - **Update Rules**: This is specific to your environment. The goal here is to have WSUS automatically approve any update it finds. This rule should mirror the products and classifications that you have configured on your WSUS server. - **Advanced**: This is specific to your environment. ![](../../../Resources/Images/automatic-approvals.png) ## Configure Devices - Configure WSUS Server in the Automox console for desired groups. - Disable OS automatic updates in the Automox console for desired groups (recommended for all groups). ![](../../../Resources/Images/configure-wsus.png) ## Maintaining your WSUS Environment - Periodically remove unneeded update files using the following command: Invoke-WsusServerCleanup -CleanupObsoleteComputers -CleanupUnneededContentFiles -CompressUpdates -CleanupObsoleteUpdates -DeclineExpiredUpdates -DeclineSupersededUpdates - Schedule task to run at least once a month. - Additional Documentation: [https://docs.microsoft.com/en-us/powershell/module/wsus/invoke-wsusservercleanup?view=win10-ps](https://docs.microsoft.com/en-us/powershell/module/wsus/invoke-wsusservercleanup?view=win10-ps) --- # Download Links for the Latest Automox Installers _Section: Product Documentation › Agents › Agent Installation • Source: https://docs.automox.com/product/Content/Product%20Documentation/Agents/Agent%20Installation/Download_Links_for_the_Latest_Automox_Installers.htm_ Links for macOS, Linux, and Windows installer files. | Operating System | Installer Link | | --- | --- | | 32-bit CentOS, Fedora or Red Hat | https://console.automox.com/installers/amagent-latest.386.systemd.rpm | | 64-bit CentOS, Fedora or Red Hat | https://console.automox.com/installers/amagent-latest.x86_64.systemd.rpm | | 32-bit SUSE | https://console.automox.com/installers/amagent-latest.suse.386.systemd.rpm | | 64-bit SUSE | https://console.automox.com/installers/amagent-latest.suse.x86_64.systemd.rpm | | 32-bit Debian or Ubuntu | https://console.automox.com/installers/amagent_latest_i386.systemd.deb | | 64-bit Debian or Ubuntu | https://console.automox.com/installers/amagent_latest_amd64.systemd.deb | | macOS | https://console.automox.com/installers/AutomoxAgent-latest.pkg | | Windows | https://console.automox.com/installers/Automox_Installer-latest.msi | --- # Embedding Your Access Key into the Automox MSI _Section: Product Documentation › Agents › Agent Installation • Source: https://docs.automox.com/product/Content/Product%20Documentation/Agents/Agent%20Installation/Embedding_Your_Access_Key_into_the_Automox_MSI.htm_ To deploy the agent without parameters, modify the Automox MSI installer directly to include your access key. This key ensures that the device appears in your management console. The simplest way to embed the access key is by using Microsoft's MSI editing tool, Orca. You can download Orca as part of the Windows Installer SDK from the link below: [Windows Installer SDK ISO Download](https://go.microsoft.com/fwlink/p/?linkid=2083448&clcid=0x409) While other MSI editing tools are available, Orca is free and provided by Microsoft, making it the preferred choice for this procedure. ## Editing the MSI with Orca To edit the MSI file with Orca, follow these steps. 1. Install and launch Orca. 2. Click **File → Open**... - The MSI file loads into the editor. 3. Retrieve your access key from the Automox console. 1. Sign into the Automox console. 2. Go to **Settings → Secrets & Keys**and copy from the Agent Access Key field. 4. In the Orca editor, click **Property** from the **Tables** list. 5. To add the access key you copied, double-click the first empty cell in the Property column to add a new entry. ![](../../../Resources/Images/orca-propertycolumn.png) 6. In the Property field, type **ACCESSKEY** and press **Enter**. This is case-sensitive. The field changes from Property to Value. 7. In the **Value** field, paste the access key and click **OK**. You'll see a new row with your new property and value entries. 8. Confirm that your access key is correct. 9. Save the file (Click **File → Save**). You can now deploy this modified MSI without being prompted for a key. ![](../../../Resources/Images/orca-accesskey.png) This applies to both Silent and GUI-based installations. Do NOT use the **Save As** option when saving your modified installer to avoid corrupting the MSI file. If you prefer to use the **Save As** option, you must first perform the following steps: 1. Open Orca. 2. Click **Tools → Options** 3. Select the **Database** tab. 4. Enable the checkbox for **Copy Embedded Streams During Save As** 5. Click **OK** to apply the setting. 6. You can then use the **Save As** option for the modified installer. ## Related Topics - [Managing Keys](../../Settings/Managing_Keys.htm) --- # Install and Configure Automox Agent for Apple Silicon Devices _Section: Product Documentation › Agents › Agent Installation • Source: https://docs.automox.com/product/Content/Product%20Documentation/Agents/Agent%20Installation/Install_and_Configure_Automox_Agent_for_Apple_Silicon_Devices.htm_ Apple Silicon devices require additional configuration to install macOS updates. If enabled, the Automox agent creates a new local service account to install macOS patches. This service account is created on Apple Silicon devices only; Intel devices do not require this account and are excluded. ## One-time Action Required For Apple Silicon devices, Automox creates a local account that needs to be granted secure token rights by an existing secure token enabled account. Apple restricts patching of rebootable macOS updates on Apple Silicon devices to administrator accounts that have secure token access. Other features, such as third-party software updates and custom policies, should continue to work as expected without the Automox service account. There are two ways to grant Automox service account secure token access, beginning with the Agent 35 release. You can use the command line option or the user prompt option. These are both described here. ### Command Line Option To create the Automox service account and grant it secure token access, run this command on the device (Apple Silicon devices only): sudo /usr/local/bin/amagent --adminuser 'admin_username' --adminpass 'admin_password' Replace `admin_username` and `admin_password` with an existing user account that has administrator privileges and secure token access. **Note**: You must account for Bash/zsh special characters. For example, escape passwords that use single quotes (such as: 'pass\'word'). An exit code of `0` indicates the command completed successfully. You can find the full list of exit codes in the [Command Line Responses](#Command2) table. You can now install all macOS updates using the agent. The Automox console updates to show the device is fully compatible after the next device scan. This is a one-time action. If the Automox service is deleted, you must run this command again. If needed, you can use the following command to check the secure token status of the Automox service account: sudo sysadminctl -secureTokenStatus _automoxserviceaccount ### Command Line Responses | Exit Code | Standard Error | Notes | | --- | --- | --- | | 0 | N/A | The command completed successfully and is enabled for macOS system patching. | | 1 | Given account password invalid | An incorrect password was entered to the --adminpass flag | | 2 | Given account not found | The local account provided does not exist on this device. | | 3 | Given account is not properly credentialed | The account provided does not have admin privileges and secure token access. | | 4 | Automox service account does not exist, retry command. If issue persists, contact Automox support. | Internal error within the agent. | | 5 | Automox service account is disabled. SecureToken cannot be granted. | The Automox service account is disabled. | | 6 | Command not compatible on this platform. | The command to grant secure token was run on a non-Apple Silicon device. | ### User Prompt Option The user prompt is disabled by default. To enable the prompt, run this command on the device (Apple Silicon devices only): sudo /usr/local/bin/amagent --automox-service-account enable sudo /usr/local/bin/amagent --automox-user-prompt enable This enables the local user prompt. Automox recently switched from using an Automox-branded prompt to the native macOS password prompt. Using the native macOS prompt improves security. This prevents the administrator password from being cached by a local process and ensures it receives special handling by macOS. ![](../../../Resources/Images/old-secure-token-notification.png) ![](../../../Resources/Images/new-secure-token-notification.png) The next time the device is scanned (configurable in the Automox Console), the agent creates the service account. If the local user has administrator privileges and secure token access, the agent prompts them to enter their password. **This is a one-time action**. After you enter your password, the Automox service account is granted secure token access to install current and future macOS patches. **Note**: If you ignore or dismiss the prompt, the agent continues to prompt you every time it scans the device (minimum every 24 hours). You can now install all macOS updates using the agent. The Automox console updates to show the device is fully compatible after the next device scan. - To disable the user prompt, run the following command: sudo /usr/local/bin/amagent --automox-user-prompt disable - To disable the creation of an Automox managed service account, run the following command: sudo /usr/local/bin/amagent --automox-service-account disable ## Automox Service Account Details The Automox service account is only used on Apple Silicon Mac devices. However, the account is not created by default. ### Account Name The Automox service account is created with the following name: - **Short name:** _automoxserviceaccount - **Long name:** Automox Service Account This account is visible on the pre-boot screen and in the user accounts table. Apple [does not allow](https://support.apple.com/en-us/HT203998)FileVault accounts to be hidden on the initial login screen. ### Account Password When the Automox agent creates the account, the agent also generates a password for the account. The randomly generated password is a minimum of 32 characters long, including alphanumeric characters and special characters. ### Password Security The service account password is randomly generated and is unique to that device. No two devices have the same password. Automox encrypts the password and stores it locally on the device. No credentials are stored in the Automox cloud; the password never leaves the device. ### Password Rotation Automox rotates the password after every software update and also when the password is used. A random password is generated for each device. --- # Installing the lshw package for SUSE Linux Enterprise Server 12 _Section: Product Documentation › Agents › Agent Installation • Source: https://docs.automox.com/product/Content/Product%20Documentation/Agents/Agent%20Installation/Installing_SUSE_Linux_Enterprise_Server_12_lshw.htm_ Before you can enroll SUSE Linux Enterprise Server 12 (SLES 12) devices in the Automox console, you must add the lshw (list hardware) package. ## Overview lshw (list hardware) is a unix application that retrieves details about a device’s hardware. [From the Linux man page](https://linux.die.net/man/1/lshw): "lshw is a small tool to extract detailed information on the hardware configuration of the machine. It can report exact memory configuration, firmware version, mainboard configuration, CPU version and speed, cache configuration, bus speed, etc. on DMI-capable x86 or IA-64 systems and on some PowerPC machines (PowerMac G4 is known to work)." The default package repo that comes with SLES 12 does not contain lshw. Before you can enroll SLES 12 devices in the Automox console, you must add this package. ## Installation To install lshw, you must first add another package repo to the device. The required repo is the[openSuSE Hardware package repo](https://build.opensuse.org/project/show/hardware). To install it, run the following commands on the device as root: zypper addrepo https://download.opensuse.org/repositories/hardware/SLE_12_SP4/hardware.repo zypper refresh zypper install -y lshw After you install the lshw package, you can enroll the device in Automox. Automox patching keeps lshw and any other packages added from the openSuSE repo up to date. --- # Installing the Automox Agent on Linux _Section: Product Documentation › Agents › Agent Installation • Source: https://docs.automox.com/product/Content/Product%20Documentation/Agents/Agent%20Installation/Installing_the_Automox_Agent_on_Linux.htm_ To install, restart, and remove the Automox agent on Linux devices, refer to the commands listed here. ## Install the agent To install the Automox agent, run this command: curl -sS https://console.automox.com/downloadInstaller?accesskey=YOUR-ORGANIZATION-KEY | sudo bash ### Check the status Use service manager to check the status of the agent. sudo service amagent status ### Inspect the process list You can also use this command to check the process. ps aux | grep amagent ## Start the agent service Use this command to start the agent, if it is not already running. sudo service amagent start ## Restart the agent You might want to restart the agent (for example, during an update). sudo service amagent restart ## Uninstall the agent You can use these commands to remove the agent from your device. ### Red Hat, CentOS sudo yum erase amagent ### Debian, Ubuntu sudo apt-get purge amagent ### Fedora sudo dnf remove amagent --- # Removing the Automox Agent _Section: Product Documentation › Agents › Agent Installation • Source: https://docs.automox.com/product/Content/Product%20Documentation/Agents/Agent%20Installation/Removing_the_Automox_Agent.htm_ Depending on your operating system, there are different steps to remove the Automox agent from your device. ## Removing the Agent Using the Console (Recommended) You can remove the agent by going to the Devices page. Using the console to remove the agent is the recommended method. For details, see [Managing Devices](../../Device Management/Managing_Devices.htm). ![](../../../Resources/Images/remove-device.png) To manually remove the Automox agent from a device, you must follow the steps specific to your operating system. ## Removing the Agent for Apple macOS 1. Open a terminal. 2. Run the following commands: 3. If Automox Tray (Agent version 2.1+) is still showing after running the previous commands, run this command: `sudo launchctl bootout gui/${uid}/com.automox.agent-ui`, where `uid` is the uid of the logged in user. ## Removing the Agent for Microsoft Windows - Go to **Local Services** and stop the agent. ![](../../../Resources/Images/win-stop-services.png) - Open a command prompt in Administrator mode and **deregister** the Automox agent. ![](../../../Resources/Images/deregister-agent.png) - Uninstall the agent. ![](../../../Resources/Images/uninstall-agent.png) ## Removing the Agent for Debian-based Linux Operating Systems 1. Open a terminal. 2. Run the following commands: ## Removing the Agent for SLES/SuSE and Red Hat-based Linux Operating Systems (SLES, Red Hat, CentOS, Amazon Linux, Fedora): 1. Open a terminal. 2. Run the following commands: sudo service amagent stop sudo /opt/amagent/amagent --deregister sudo rpm -qa | grep amagent sudo rpm -e amagent-1.0-19.x86_64 # (for example, should match what previous command returns) ## Reinstalling the Automox Agent To reinstall the Automox agent, ensure that you first deregister and then remove the agent. 1. Deregister the agent. See [Agent Command Line Guide](Agent_Command_Line_Guide.htm). 2. Remove the agent, as described here. 3. Follow the instructions in [Automox Agent Installation Overview](Automox_Agent_Installation_Overview.htm). --- # Silent Agent Deployment on Windows _Section: Product Documentation › Agents › Agent Installation • Source: https://docs.automox.com/product/Content/Product%20Documentation/Agents/Agent%20Installation/Silent_Agent_Deployment_on_Windows.htm_ You can silently deploy the Automox agent on Windows devices using the Windows installer .msi file. You can deploy to a destination group that can also be under a parent group. Follow the command examples to ensure desired group deployment. ## Deploying to a destination group using Windows installer 1. Download the latest Automox agent from this link: [https://console.automox.com/installers/Automox_Installer-latest.msi](https://console.automox.com/installers/Automox_Installer-latest.msi). 2. To execute the installer, modify the command to use your access key. You can retrieve the access key in the console from the **Settings → Secrets & Keys**tab, or from the **Add Devices** dialog. (Replace "YOUR_ACCESS_KEY" in the command with your access key.) 3. To ensure the agent deploys to a specific group, add the group name in following format: (GROUP="Default Group/Group Name") ### Installer command msiexec.exe /i "Automox_Installer-latest.msi" /qn /norestart ACCESSKEY=YOUR_ACCESS_KEY GROUP="Default Group/My Destination Group" ### Example 1 In the following example command, the access key is 12345-789-0 and the destination group is "Accounts Payable". msiexec.exe /i "Automox_Installer-latest.msi" /qn /norestart ACCESSKEY=12345-789-0 GROUP="Default Group/Accounts Payable" ### Example 2 In the following example command, the access key is 12345-789-0 and the destination group is "Accounts Payable", which is under the parent group "Finance". msiexec.exe /i "Automox_Installer-latest.msi" /qn /norestart ACCESSKEY=12345-789-0 GROUP="Finance/Accounts Payable" **Note**: Your destination group can either be under a parent group or stand alone. A parent group parameter is only required if the destination group is under a parent group. If you do not specify a parent group, it ignores the group assignment. ## Deploying to a destination group using PowerShell You can also deploy using PowerShell. Use the following command: Start-Process 'msiexec.exe' -ArgumentList '/i "Automox_Installer-latest.msi" /qn /norestart ACCESSKEY=YOUR_ORGANIZATION_KEY GROUP="Default Group/My Destination Group"' The requirements related to the "GROUP=" parameter for the installer also apply here. You must specify a parent group, or no group assignment follows. See also [Deploying the Automox Agent in Bulk](Bulk Agent Deployment/Deploying_the_Automox_Agent_in_Bulk.htm). --- # Using the Automox Agent With a Proxy Server _Section: Product Documentation › Agents › Agent Installation • Source: https://docs.automox.com/product/Content/Product%20Documentation/Agents/Agent%20Installation/Using_the_Automox_Agent_With_a_Proxy_Server.htm_ How to configure a device that uses a proxy server. ## Proxy Server Configurations Many organizations use a proxy server to manage and monitor internet traffic. A proxy server acts as an intermediary between a client and the external network. Popular proxy servers include ProxySG and Squid, among others. Two configurations are typical: caching and transparent. The most common is a caching proxy. A caching proxy requires that the client is configured to use the proxy. You can do this through DHCP or manual configuration. As an example, the web proxy for a client is set to `10.0.0.2` with port `3128`. The network is then configured to only allow traffic outbound from `10.0.0.2` and not directly from the client. ![](../../../Resources/Images/proxy-server-config.png) In a transparent proxy, the client does not need to know about the proxy server. It most often runs in line with the router. No client-side configuration is needed. ### Proxy Evaluation Order If a proxy is set, the client attempts to use it. If that proxy is unreachable, the client checks the next one. The order of proxy evaluation by Automox is as follows: 1. AUTOMOX_PROXY/automox_proxy 2. HTTPS_PROXY/https_proxy 3. HTTP_PROXY/http_proxy 4. Windows Only: IE Proxy (Dynamic via PAC file) 5. Windows Only: IE Proxy (Static) 6. Direct **Note**: The agent runs as a local system. You must configure the proxy settings at the system level, not the user level. Follow the examples for configuring the environment variables. ## Automox Client Configuration: Linux The Automox client needs one of the preceding proxy settings configured. For example, if you are using `HTTP_PROXY` and `HTTPS_PROXY`, you can set these in your current session using `export HTTP_PROXY=http://10.0.0.1:3128` and `export HTTPS_PROXY=http://10.0.0.1:3128` replacing `10.0.0.1:3128` with your proxy server address and port. However, because the Automox agent runs automatically at startup, the best practice is to set this globally in the file `/etc/profile`. 1. Begin by editing either the file `/etc/profile` or creating a file `/etc/profile.d/automox.sh`. ![](../../../Resources/Images/linux-edit-profile.png) 2. Append `export AUTOMOX_PROXY=http://yourProxyServer:yourProxyPort`, `export HTTP_PROXY=http://yourProxyServer:yourProxyPort` and `export HTTPS_PROXY=http://yourProxyServer:yourProxyPort`. ![](../../../Resources/Images/linux-apend-export.png) 3. To verify the setting, you can log out of your session, log in again, and run `echo $AUTOMOX_PROXY`, `echo $HTTP_PROXY` or `echo $HTTPS_PROXY`. ![](../../../Resources/Images/linux-run-echo.png) ## Automox Client Configuration – Windows The Automox client requires you to set a system environment variable. This is not a profile environment variable but rather a system environment variable. For Windows clients, Automox supports the use of PAC files for proxy deployments and attempts to use your IE proxy settings. 1. In the Control Panel, click **System and Security**. 2. Click **System**. 3. Click **Advanced System Settings**. 4. Click **Environment Variables**. 5. Under System variables, click **New**. 6. As an example, you can configure variables as follows: - For Variable name enter: `HTTP_PROXY` - For Variable value enter: the IP/Name of your proxy server and port. - Click **OK**. 7. Repeat steps 5 and 6 for the `AUTOMOX_PROXY`, `HTTPS_PROXY`, and `HTTP_PROXY` variables. **Note:** Be sure to leave the protocol as **http**, leaving out the "s", for `HTTP_PROXY`. 8. Click **OK**. Your Automox Agent is now configured to use your proxy server. You can automate setting the proxy by using a worklet. Refer to [Creating a Worklet](../../Policies/Creating_a_Worklet.htm) and the [Automox Community](https://community.automox.com/worklets-12) for examples of creating and applying worklets. ## Related Topics - [Creating a Worklet](../../Policies/Creating_a_Worklet.htm) - [Automox Community](https://community.automox.com/worklets-12) --- # Platform Firewall Allowlisting Rules _Section: Product Documentation › Agents › Agent Requirements • Source: https://docs.automox.com/product/Content/Product%20Documentation/Agents/Agent%20Requirements/Agent_Firewall_Allowlisting_Rules.htm_ Refer to this document for a list of addresses to optimize Automox platform functionality as well as addresses needed to patch Microsoft OS versions from Windows update. **Regarding Ad Blockers** - We recommended disabling ad blockers (such as uBlock Origin) for the Automox Console, as ad blockers can adversely impact the functionality of the product. ## Network and firewall requirements for running the Automox platform If your organization has egress filtering on the firewall, you will need to allow access to the following hostnames / IP addresses for the Automox platform to communicate with the cloud platform. All platform communications take place over port 443 (https). - **Note: [The platform-IP addresses are subject to change](#Automox)**. Add the hostnames to your list of trusted sites, if possible, or regularly check for the latest IPs assigned to the platform. - **SSL Inspection / MiTM Bypass Required** SSL inspection (also known as TLS interception or MiTM proxy analysis) must be bypassed for all agent traffic. These mechanisms break mutual TLS (mTLS) certificate authentication by replacing the agent's client certificate during the handshake, causing authentication failures. Ensure your firewall or proxy is configured to exempt endpoints running the Automox agent from SSL inspection policies. ### Recommended approach using URL | Domain | Protocols | Direction | Ports | | --- | --- | --- | --- | | *.automox.com | TCP | Outbound | 443 | | *.digicert.com | TCP | Outbound | 80 | | *.digicertcdn.com | TCP | Outbound | 80 | | automox-policy-files.s3.us-west-2.amazonaws.com | TCP | Outbound | 443 | ### Additional Recommendations for Automox Remote Control with Splashtop Please refer to [Splashtop's documentation](https://support-splashtopbusiness.splashtop.com/hc/en-us/articles/115001811966-What-Are-the-Firewall-Exceptions-and-IP-addresses-of-Splashtop-Servers-Services) for updated firewall requirements, in the event that things do not work as expected. | Domain | Protocols | Direction | Ports | | --- | --- | --- | --- | | *.api.splashtop.com | TCP | Outbound | 443 | | *.relay.splashtop.com | TCP | Outbound | 443 | | update.splashtop.com | TCP | Outbound | 443 | | update-g3.splashtop.com | TCP | Outbound | 443 | #### Optional and Performance Ports for Automox Resolve, powered by Splashtop | Port | Purpose | | --- | --- | | 6783 (TCP) | For local connections on the same network, direct connections are point-to-point via TCP port 6783(configurable port). Only required if internal device-to-device communication is being blocked locally. No external access needed. | | 9527-9528 (TCP) | Used only for local (loopback) communication between components. No firewall action is typically required. | | 3749 (UDP) and all UDP Ports | Splashtop uses QUIC for optimized end-to-end connections. This requires outbound UDP port 3479 and dynamic UDP port allocation. | ### Additional Recommendations for Analytics | Domain | Protocols | Direction | Port | | --- | --- | --- | --- | | *.thoughtspot.cloud | TCP, UDP | Outbound | 443 | | mp.proxy.thoughtspot.cloud | TCP, UDP | Outbound | 443 | | automox.thoughtspot.cloud | TCP, UDP | Outbound | 443 | - Alternative approach using IP addresses: - Check for current IP addresses by running the following command: `nslookup api.automox.com` ### Recommended Approach Using Specific URLs In addition to the URLs shown above, the following URLs should be added to your allowlist, particularly if your firewall does not support the use of wildcards: | Domain | Protocols | Direction | Ports | | --- | --- | --- | --- | | api.automox.com | TCP | Outbound | 443 | | console.automox.com | TCP | Outbound | 443 | | ct.automox.com | TCP | Outbound | 443 | | storage-cdn.automox.com | TCP | Outbound | 443 | | worklet-signing.automox.com | TCP | Outbound | 443 | | installation-reporting-service.automox.com | TCP | Outbound | 443 | | llm.automox.com | TCP | Outbound | 443 | | download-export-cdn.automox.com | TCP | Outbound | 443 | | rtt.automox.com | TCP | Outbound | 443 | | agent-content-cdn.automox.com | TCP | Outbound | 443 | | command-storage-cdn.automox.com | TCP | Outbound | 443 | | command-storage.automox.com | TCP | Outbound | 443 | | third-party-cdn.automox.com | TCP | Outbound | 443 | | telemetry.automox.com | TCP | Outbound | 443 | | app.launchdarkly.com | TCP | Outbound | 443 | | cdn.automox.com | TCP | Outbound | 443 | ## Automox Platform and Splashtop Static IP List We offer static IPs for customers who need to allowlist according to specific IP addresses. As our platform IP addresses are subject to change, please refer to our [Static IP List](https://ax-static.automox.com/ip/v4.txt). This file is updated as needed. ## Proxy and Firewall Considerations ### Windows See [Windows Update troubleshooting: Issues related to HTTP/Proxy](https://docs.microsoft.com/en-us/windows/deployment/update/windows-update-troubleshooting#issues-related-to-httpproxy) You might choose to apply a rule to permit HTTP RANGE requests for the following URLs: `*.download.windowsupdate.com` `*.dl.delivery.mp.microsoft.com` `*.delivery.mp.microsoft.com` ### Firewall See [Windows Update troubleshooting: Device cannot access update files](https://docs.microsoft.com/en-us/windows/deployment/update/windows-update-troubleshooting#device-cannot-access-update-files) | Protocol | Endpoint URL | | --- | --- | | TLS 1.2 | *.prod.do.dsp.mp.microsoft.com | | HTTP | emdl.ws.microsoft.com | | HTTP | *.dl.delivery.mp.microsoft.com | | HTTP | *.windowsupdate.com | | HTTPS | *.delivery.mp.microsoft.com | | TLS 1.2 | *.update.microsoft.com | | TLS 1.2 | tsfe.trafficshaping.dsp.mp.microsoft.com | **Note**: - Make sure to not use HTTPS for those endpoints that specify HTTP, and vice-versa. The connection will fail. - When leveraging split-tunneling with a VPN, make sure to include these endpoints in your list of sites with direct access to the internet. The Automox Agent Notifier must be added to the Windows Defender Firewall Allowed Applications. ### Microsoft Windows 11 Connection Points Microsoft provides a complete list of connection points per Windows 11 feature version. Here is a link to the connection point document for Windows 11 Enterprise (refer to the links on the left for other feature versions). [Connection Endpoints for Windows 11 Enterprise - Windows Privacy](https://docs.microsoft.com/en-us/windows/privacy/manage-windows-20h2-endpoints) ### macOS See [Use Apple products on enterprise networks](https://support.apple.com/en-us/HT210060). --- # Automox Agent Requirements _Section: Product Documentation › Agents › Agent Requirements • Source: https://docs.automox.com/product/Content/Product%20Documentation/Agents/Agent%20Requirements/Automox%20Agent%20Requirements.htm_ This table lists the system requirements for implementing the Automox agent. | | Windows | macOS | Linux | | --- | --- | --- | --- | | Memory utilization | 100 MB*Varies based on agent activity. | 150 MB*Varies based on agent activity. | 100 MB*Varies based on agent activity. | | Disk space requirements | 80 MB‡Additional free space will be needed to download and install updates. | 175 MB‡Additional free space will be needed to download and install updates. | 290 MB†Varies depending on distro.‡Additional free space will be needed to download and install updates. | | .NET | ≥ 3.51 | N/A | N/A | | OS support | For details about the operating systems and versions that Automox supports, see Supported Operating Systems. | | PowerShell | PowerShell 5.1 or later | For agents 2.1.44 and later, the Automox Tray introduces a new executable: `amagent-ui.exe`, a dedicated UI process responsible for the persistent tray experience. This binary is signed on Windows to ensure a trusted and secure experience for both users and IT administrators. This is separate from `amagent.exe` and not associated with `osqueryi`. --- # Location of Files Required By Automox _Section: Product Documentation › Agents › Agent Requirements • Source: https://docs.automox.com/product/Content/Product%20Documentation/Agents/Agent%20Requirements/Location_of_Files_Required_By_Automox.htm_ This describes the files and their respective locations that support the agent, which you might add to a list of trusted items. ## The following describes file locations per operating system: For **Linux**, the Automox Agent files are located here: | File Location | Description | | --- | --- | | /etc/init.d/amagent | This is the location of the initialization script for the agent. | | /var/lib/amagent/ | This is the amagent.db database as well as dynamically generated exec folders and scripts for executing the scripts required for the product to function. | | /var/lib/amagent/osqueryi | This file assists with device attribute enumeration (Agent version 1.45.48 and later) | **Note**: - Sensitive database values are encrypted and obfuscated to enhance the security of the Automox agent. - Only root user and group have read/write permissions. All others are denied access. #### Example folder layout: drwxr-xr-x 7 root root 224 May 10 16:17 . drwxr-xr-x 19 root root 608 May 11 16:03 .. -rw-r--r-- 1 root root 16384 May 10 16:17 amagent.db drwx------ 3 root root 96 May 8 15:16 execDir118111890 drwx------ 3 root root 96 May 8 14:30 execDir419776156 drwx------ 3 root root 96 May 8 14:40 execDir534130416 drwx------ 3 root root 96 May 8 14:41 execDir993973924 **Note**: The agent runs scripts to execute its functions within dynamically created folders with the prefix "execDir". | File Location | Description | | --- | --- | | /opt/amagent/amagent | This is the agent executable that runs as a service | #### Logs (Linux) - Agent logs are written to `/var/log/amagent/amagent.log` - Agent command logs are written to `/var/log/amagent/command.log` All logging goes to the amagent folders. The amagent logs can be viewed with any of these commands: - `systemctl status amagent` - `cat /var/log/amagent/amagent.log` - view the contents of amagent.log - `cat /var/log/amagent/command.log` - view the contents of command.log - `cat /var/log/messages | grep amagent` To put the contents of the log into a text file, use one of the following commands: - `cat /var/log/amagent/amagent.log &> amagentlog.txt` - `cat /var/log/amagent/amagent.log | tee amagentlog.txt` #### macOS For **macOS**, the Automox Agent files are located as described here: | File Location | Description | | --- | --- | | /var/tmp/amagent-accesskey.txt | This is the temporary location for the access key during agent installation and startup. | | /var/tmp/automox/installerlog*******.txt | This is the log containing output and potential errors from actual agent install. Note: This requires root permissions. | | /Library/LaunchDaemons/com.automox.agent.plist | This is the plist file for Automox Agent daemon process. | | /Library/Application Support/Automox/ | This location stores the amagent.db database, the Automox Notifier.app, as well as dynamically generated exec folders and scripts for executing the scripts required for the product to function. The notifier provides notifications to end users for patch events and restarts. | | /Library/Application Support/Automox/osqueryi | This file assists with device attribute enumeration. | | /Library/Application Support/Automox/agent-ui | This file provides the Automox Tray UI (Agent version 2.1.x and later) | **Note**: - Sensitive database values are encrypted and obfuscated to enhance the security of the Automox agent. - Only root user and group have read/write permissions. All others are denied access. #### Example folder layout: drwxrwxrwx 7 root wheel 224 May 10 16:17 . drwxr-xr-x 19 root admin 608 May 11 16:03 .. -rwxrwxrwx 1 root wheel 16384 May 10 16:17 amagent.db drwx------ 3 root wheel 96 May 8 15:16 execDir221989621 drwx------ 3 root wheel 96 May 8 14:30 execDir266587032 drwx------ 3 root wheel 96 May 8 14:40 execDir399049188 drwx------ 3 root wheel 96 May 8 14:41 execDir591069041 **Note**: The agent runs scripts to execute its functions within dynamically created folders with the prefix **execDir**. | File Location | Description | | --- | --- | | /usr/local/bin/amagent | This is the agent executable that runs as a launch daemon. | #### Logs (macOS) Agent logs are written to `/var/log/amagent/amagent.log` Agent command logs are written to `/var/log/amagent/command.log` Previous versions of the agent are logged to `/var/log/system.log` {grep for 'amagent'} Software Update restart logs are written to `/var/log/amagent/restart.log` or `/var/log/amagent/restart.err` (macOS Ventura and later) Automox Tray logs are written to `$HOMEDIR/Library/Logs/com.automox.agent-ui/amagent-ui_[username].log` ## Windows The Automox agent is a 32-bit application. Automox Agent ≥ 2.3.34 uses an additional executable, `amagent-watchdog.exe`. Please see [Agent 2.3.34 Release Notes](../../Release Notes/Agent Release Notes/Agent 2.3.x Release Notes.htm) for details. For Windows systems, the supporting files are in the following locations: | File Location | Description | | --- | --- | | C:\ProgramData\amagent\ | This is the location for the amagent.db database as well as dynamically generated exec folders and scripts for executing the scripts required for the product to function. | | C:\ProgramData\amagent\amagent.log | The Automox agent log file location. | | $HOMEDIR\AppData\Local\com.automox.agent-ui\Logs\amagent-ui_[username].log | The Automox Tray log file location. | | For 32-bit systems | | | C:\Program Files\Automox\ | All other supporting files are in this directory. This directory requires system or administrator privileges for access. | | C:\Program Files\Automox\osqueryi.exe | This file assists with device attribute enumeration | | C:\Program Files\Automox\amagent-ui.exe | This file provides the Automox Tray UI (Agent version 2.1.44 and later) | | C:\Program Files\Microsoft\EdgeWebView\Application\\msedgewebview2.exe | This file provides the WebView2 Runtime, which is required by Automox Tray (Agent version 2.1.x and later). | | C:\Program Files\Automox\amagent-watchdog.exe | For agent ≥ 2.3.34, this file is required for Automox Tray to receive and show notifications. | | For 64-bit systems | | | C:\Program Files (x86)\Automox\ | All other supporting files are in this directory. This directory requires system or administrator privileges for access. | | C:\Program Files (x86)\Automox\osqueryi.exe | This file assists with device attribute enumeration | | C:\Program Files (x86)\Automox\amagent-ui.exe | This file provides the Automox Tray UI (Agent version 2.1.x and later) | | C:\Program Files (x86)\Automox\amagent-watchdog.exe | For agent ≥ 2.3.34, this file is required for Automox Tray to receive and show notifications. | | C:\Program Files (x86)\Microsoft\EdgeWebView\Application\\msedgewebview2.exe | This file provides the WebView2 Runtime, which is required by Automox Tray (Agent version 2.1.x and later). | ## PowerShell The **PowerShell** 5.0+ feature called **Language Modes** generates two files used to detect the current language mode. These files end up blocked, but this does not affect Automox features. For a more detailed description of this scenario, contact [Automox support](https://help.automox.com/hc/en-us/requests/new). See also [About Language Modes](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_language_modes?view=powershell-6). --- # Supported Operating Systems _Section: Product Documentation › Agents › Agent Requirements • Source: https://docs.automox.com/product/Content/Product%20Documentation/Agents/Agent%20Requirements/Supported_Operating_Systems.htm_ **Automox supports the following operating systems:** If you are leveraging any of the following operating systems, Automox will support and address known issues, and apply hot-fixes, if needed. ## Windows Desktop | OS Version | Architecture | Minimum Agent Version | | --- | --- | --- | | Windows 11 | x86-64, ARM64 | 2.3.30 | | Windows 10 | x86-32, x86-64 | 2.x | | Windows 10 S | x86-64 | 2.x | ## Windows Server | OS Version | Architecture | Minimum Agent Version | | --- | --- | --- | | Server 2025 | x86-64 | 2.x | | Server 2025 Core | x86-64 | 2.2.26 | | Server 2022 | x86-64 | 2.x | | Server 2019 | x86-64 | 2.x | | Server 2016 | x86-64 | 2.x | | Server 2012 R2 | x86-64 | 2.x | ## macOS | OS Version | Architecture | Minimum Agent Version | | --- | --- | --- | | 26 (Tahoe) | x86-64, ARM64 | 2.3.35 | | 15 (Sequoia) | x86-64, ARM64 | 2.x | | 14 (Sonoma) | x86-64, ARM64 | 2.x | ## Linux - RPM-based | OS Version | Architecture | Minimum Agent Version | | --- | --- | --- | | Fedora 44 | x86-64 | 2.5.68 | | Fedora 43 | x86-64, ARM64 | 2.x | | Red Hat Enterprise Linux (RHEL) 10 | x86-64, ARM64 | 2.x | | Red Hat Enterprise Linux (RHEL) 9 | x86-64, ARM64 | 2.x | | Red Hat Enterprise Linux (RHEL) 8 | x86-64 | 2.x | | CentOS Stream 10 | x86-64, ARM64 | 2.x | | CentOS Stream 9 | x86-64, ARM64 | 2.x | | Rocky Linux 10 | x86-64, ARM64 | 2.x | | Rocky Linux 9 | x86-64, ARM64 | 2.x | | Rocky Linux 8 | x86-64 | 2.x | | AlmaLinux OS 10 | x86-64, ARM64 | 2.x | | AlmaLinux OS 9 | x86-64 | 2.x | | AlmaLinux OS 8 | x86-64 | 2.x | | Oracle Linux 9 | x86-64 | 2.x | | Oracle Linux 8 | x86-64 | 2.x | | CloudLinux 9 | x86-64 | 2.x | | Amazon Linux 2023 | x86-64, ARM64 | 2.x | | Amazon Linux 2 | x86-64, ARM64 | 2.x | ## Linux - DEB-based | OS Version | Architecture | Minimum Agent Version | | --- | --- | --- | | Debian 13 | x86-64, ARM64 | 2.x | | Debian 12 | x86-64 | 2.x | | Debian 11 | x86-64 | 2.x | | Ubuntu 26.04 LTS | x86-64, ARM6 | 2.5.68 | | Ubuntu 24 | x86-64, ARM64 | 2.x | | Ubuntu 22 | x86-64 | 2.x | | Ubuntu 20 | x86-64 | 2.x | | Ubuntu 18 | x86-64 | 2.x | | Ubuntu 16 | x86-64 | 2.x | | Elementary OS 7 | x86-64 | 2.x | | Peppermint OS 11 | x86-64 | 2.x | | Zorin OS 16 | x86-64 | 2.x | ## Linux - RPM-based (SUSE) | OS Version | Architecture | Minimum Agent Version | | --- | --- | --- | | SUSE Linux Enterprise Server (SLES) 15.5 | x86-64 | 2.x | Windows IoT is not currently supported. ## Operating Systems - End of Life **Note:** Automox cannot guarantee that patching will function after an OS reaches end-of-life. It will likely fail when patching is attempted. Additionally, end-of-life operating systems are no longer tested ahead of product releases. ### Windows Desktop | OS Version | | --- | | Windows 8.1 | | Windows 8 | | Windows 7 | | Windows Vista | | Windows XP | ### Windows Server | OS Version | | --- | | Windows Server 2008 R2 | | Windows Server 2008 | | Windows Server 2003 | | Windows Vista | | Windows XP | ### macOS | OS Version | | --- | | 13 (Ventura) | | 12 (Monterey) | | 11 (Big Sur) | | macOS 10.x | | Mac OS X | ### Linux - RPM-based | OS Version | | --- | | Fedora 42 | | Fedora 41 | | Fedora 40 | | Fedora 39 | | Fedora 38 | | Fedora 37 | | Fedora 36 | | Red Hat Enterprise Linux (RHEL) 7 and earlier | | CentOS Stream 8 | | CentOS 7 | ### Linux - DEB-based | OS Version | | --- | | Debian 10 | | Lubuntu 23 | | Linux Mint 10 | --- # TLS Configuration Requirements for Automox _Section: Product Documentation › Agents › Agent Requirements • Source: https://docs.automox.com/product/Content/Product%20Documentation/Agents/Agent%20Requirements/TLS_Configuration_Requirements.htm_ ## TLS Configuration Requirements Automox requires secure Transport Layer Security (TLS) configurations to protect communication between the Automox agent and the cloud console. This document details supported protocols, cipher suites, and system requirements for maintaining connectivity. ## Supported Protocols and Cryptography To align with industry best practices and AWS security policies, Automox supports TLS 1.2 and TLS 1.3. Systems must use cryptographic primitives that provide forward secrecy and authenticated encryption. ### Technical Standards - **Protocols**: TLS 1.2, TLS 1.3 - **Hashing Algorithms**: SHA256, SHA384 - **Keys**: - RSA - ECDSA (where dual-stack certificates are supported) - **Key Exchange**: ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) - **Encryption Algorithms**: AES-GCM, ChaCha20-Poly1305 Legacy algorithms, including static RSA key exchange and deprecated hashing functions, are unsupported for agent-to-console communication. ## System Requirements Administrators must ensure managed endpoints meet these cryptographic requirements to prevent connection failures. ### Supported Configuration Reference | Component | Requirement | | --- | --- | | Operating Systems | See Supported Operating Systems | | PowerShell Version | See Automox Agent Requirements | | Key Exchange | ECDHE must be enabled in SCHANNEL | | Cipher Policy | Must support at least one suite from AWS CloudFront TLSv1.2_2019 or newer | ### Registry Configuration Paths Windows TLS behavior is controlled by these registry keys: - **ECDH Key Exchange**: `HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\ECDH` - **SSL Cipher Order**: `HKLM:\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002` - **Enable strong cryptography for .NET applications (including PowerShell)** `HKLM:\SOFTWARE\Microsoft\.NETFramework\v2.0.50727` `HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319` `HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727` `HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319` For detailed guidance on configuring these registry paths or troubleshooting environment issues, see the Automox documentation: - [Force PowerShell to Use TLS 1.2](https://help.automox.com/hc/en-us/articles/31578579603732-Force-PowerShell-to-Use-TLS-1-2) - [Proxy Blocks Downloads Due to TLS Setting](https://help.automox.com/hc/en-us/articles/31580534058132-Proxy-Blocks-Downloads-from-Automox-Due-to-TLS-Setting#h_01JK6PFYMRZT1VYNBHM07HD6GM) For manual configuration, administrators can use the [IIS Crypto tool by Nartac Software](https://www.nartac.com/Products/IISCrypto). It offers a graphical interface to manage SCHANNEL registry keys, enable TLS 1.2 and 1.3, disable insecure cryptographic methods, and reorder cipher suites. ## Connectivity Validation All agent operations require successful TLS negotiation. Verify connectivity by testing outbound HTTPS requests to the primary Automox infrastructure endpoints. ### Validation Endpoints | Endpoint | Expected Result | Note | | --- | --- | --- | | https://api.automox.com | Success | Primary API communication | | https://storage-cdn.automox.com | Success (403 Forbidden) | A 403 response confirms a successful TLS handshake | ### Manual Validation (PowerShell) To verify that a system can establish a secure connection with the required TLS protocols, run this command in PowerShell. The script uses .NET sockets to confirm the negotiated protocol version: Test-AutomoxConnectivity.ps1 #!/usr/bin/env pwsh <# .SYNOPSIS Tests connectivity to Automox endpoints and verifies TLS 1.2+ configuration. .DESCRIPTION This script checks if the client computer can successfully connect to Automox endpoints and verifies that PowerShell is configured to use TLS 1.2 or higher. .EXAMPLE .\Test-AutomoxConnectivity.ps1 #>[CmdletBinding()] param() #region Functions # Helper function to display color-coded test results function Write-Result { param([string]$Test, [bool]$Pass, [string]$Message) $status = if ($Pass) { "PASS" } else { "FAIL" } $color = if ($Pass) { "Green" } else { "Red" } Write-Host "[$status] " -ForegroundColor $color -NoNewline Write-Host "$Test`: $Message"} # Tests HTTP/HTTPS connectivity to an endpoint # Can optionally force a specific TLS version for testing # Returns $true if the response code matches expected codes, $false otherwise function Test-Endpoint { param([string]$Url, [int[]]$ExpectedCodes, [System.Net.SecurityProtocolType]$ForceTLS) # Store original TLS setting to restore later $original = [Net.ServicePointManager]::SecurityProtocol try { # If ForceTLS parameter was provided, temporarily override the TLS setting if ($PSBoundParameters.ContainsKey('ForceTLS')) { [Net.ServicePointManager]::SecurityProtocol = $ForceTLS } # Attempt to connect to the endpoint $response = Invoke-WebRequest -Uri $Url -Method Get -UseBasicParsing -ErrorAction Stop return $response.StatusCode -in $ExpectedCodes } catch { # Some endpoints return errors but still establish connection (for example, 403 for CDN) if ($_.Exception.Response) { $code = [int]$_.Exception.Response.StatusCode return $code -in $ExpectedCodes } return $false } finally { # Always restore original TLS setting [Net.ServicePointManager]::SecurityProtocol = $original } } #endregion #region Main Script # Display header Write-Host "`n================================================" -ForegroundColor Cyan Write-Host " Automox Connectivity Test" -ForegroundColor Cyan Write-Host "================================================`n" -ForegroundColor Cyan #region Smoke Test - Verify basic network connectivity before detailed testing Write-Host "=== Network Smoke Test ===" -ForegroundColor Cyan $endpoints = @("api.automox.com", "storage-cdn.automox.com") $smokePass = $true # Test DNS resolution for both Automox endpoints foreach ($endpoint in $endpoints) { try { $ips = [System.Net.Dns]::GetHostAddresses($endpoint) Write-Result "DNS: $endpoint" $true "Resolved to $($ips[0].IPAddressToString)" } catch { Write-Result "DNS: $endpoint" $false "Failed to resolve" $smokePass = $false } } # Test basic TCP connectivity on port 443 (HTTPS) try { $tcp = New-Object System.Net.Sockets.TcpClient $connect = $tcp.ConnectAsync("api.automox.com", 443) if ($connect.Wait(5000) -and $tcp.Connected) { Write-Result "TCP: api.automox.com:443" $true "Connection successful" $tcp.Close() } else { Write-Result "TCP: api.automox.com:443" $false "Connection timeout" $smokePass = $false } $tcp.Dispose() } catch { Write-Result "TCP: api.automox.com:443" $false "Connection failed" $smokePass = $false } # If smoke test fails, abort - no point testing TLS if basic connectivity is broken if (-not $smokePass) { Write-Host "`nSMOKE TEST FAILED - Check internet, DNS, and firewall settings" -ForegroundColor Red exit 2 } #endregion #region TLS Configuration Check - Verify PowerShell defaults to TLS 1.2 or higher Write-Host "`n=== TLS Configuration ===" -ForegroundColor Cyan # Get the default TLS protocols configured for this PowerShell session $protocols = [Net.ServicePointManager]::SecurityProtocol # Check if TLS 1.2 and 1.3 are enabled using bitwise AND $hasTLS12 = $protocols -band [Net.SecurityProtocolType]::Tls12 $hasTLS13 = try { $protocols -band [Net.SecurityProtocolType]::Tls13 } catch { $false } # Automox requires at least TLS 1.2 $isSecure = $hasTLS12 -or $hasTLS13 # Display current TLS configuration Write-Host "Default: $protocols"Write-Host " TLS 1.2: $(if ($hasTLS12) { 'Enabled' } else { 'Disabled' })" -ForegroundColor $(if ($hasTLS12) { 'Green' } else { 'Red' }) Write-Host " TLS 1.3: $(if ($hasTLS13) { 'Enabled' } else { 'Disabled' })" -ForegroundColor $(if ($hasTLS13) { 'Green' } else { 'Gray' }) Write-Result "TLS 1.2+ Available" $isSecure $(if ($isSecure) { "Ready for Automox" } else { "Not configured" }) #endregion #region Connectivity Testing - Test endpoints with different TLS configurations # Define test cases: first with default config, then forcing specific TLS versions $testCases = @( @{ Label = "Default Config"; TLS = $null } # Test with system defaults @{ Label = "TLS 1.2 Forced"; TLS = [Net.SecurityProtocolType]::Tls12 } # Force TLS 1.2 only ) # Add TLS 1.3 test if the PowerShell version supports it try { $tls13 = [Net.SecurityProtocolType]::Tls13 $testCases += @{ Label = "TLS 1.3 Forced"; TLS = $tls13 } } catch { } # Store results from each test case $results = @{} # Run connectivity tests for each configuration foreach ($test in $testCases) { Write-Host "`n=== Testing: $($test.Label) ===" -ForegroundColor Cyan # Set up parameters for both endpoints # API expects HTTP 200, CDN expects HTTP 403 (no direct access without path) $apiParams = @{ Url = "https://api.automox.com"; ExpectedCodes = @(200) } $cdnParams = @{ Url = "https://storage-cdn.automox.com"; ExpectedCodes = @(403) } # If this test case specifies a TLS version, add it to the parameters if ($test.TLS) { $apiParams['ForceTLS'] = $test.TLS $cdnParams['ForceTLS'] = $test.TLS } # Test both endpoints $apiSuccess = Test-Endpoint @apiParams $cdnSuccess = Test-Endpoint @cdnParams # Display results Write-Result "api.automox.com" $apiSuccess $(if ($apiSuccess) { "Connected" } else { "Failed" }) Write-Result "storage-cdn.automox.com" $cdnSuccess $(if ($cdnSuccess) { "Connected" } else { "Failed" }) # Store results for summary $results[$test.Label] = @{ API = $apiSuccess; CDN = $cdnSuccess } } #endregion #region Summary - Display quick overview of all test results Write-Host "`n=== Summary ===" -ForegroundColor Cyan foreach ($test in $testCases) { $label = $test.Label $r = $results[$label] $pass = $r.API -and $r.CDN # Both endpoints must pass Write-Host "$label`: " -NoNewline Write-Host $(if ($pass) { "PASS" } else { "FAIL" }) -ForegroundColor $(if ($pass) { "Green" } else { "Red" }) } #endregion #region Recommendation - Provide actionable guidance based on test results Write-Host "`n=== Recommendation ===" -ForegroundColor Cyan # Determine what worked and what didn't $defaultWorks = $results["Default Config"].API -and $results["Default Config"].CDN $tls12Works = $results["TLS 1.2 Forced"].API -and $results["TLS 1.2 Forced"].CDN # Scenario 1: Everything works with default config - system is properly configured if ($isSecure -and $defaultWorks) { Write-Host "System properly configured for TLS and Automox connection!" -ForegroundColor Green exit 0 # Scenario 2: Default config lacks TLS 1.2+, but TLS 1.2 works when forced # This means the system CAN do TLS 1.2, it's just not configured as the default } elseif (-not $isSecure -and $tls12Works) { Write-Host "ACTION REQUIRED: Update system TLS configuration" -ForegroundColor Red Write-Host "" Write-Host "Your system supports TLS 1.2 but doesn't use it by default." -ForegroundColor Yellow Write-Host "Automox requires TLS 1.2+ to be enabled by default." -ForegroundColor Yellow Write-Host "" Write-Host "To fix:" -ForegroundColor White Write-Host " 1. Install latest Windows updates" -ForegroundColor White Write-Host " 2. Install .NET Framework 4.7 or higher" -ForegroundColor White Write-Host " 3. Configure registry settings for TLS 1.2" -ForegroundColor White Write-Host "" Write-Host "Details: https://help.automox.com/hc/en-us/articles/31580534058132-Proxy-Blocks-Downloads-from-Automox-Due-to-TLS-Setting#h_01JK6PFYMRZT1VYNBHM07HD6GM" -ForegroundColor Cyan exit 1 # Scenario 3: Even TLS 1.2 doesn't work - likely firewall/network issue } elseif (-not $tls12Works) { Write-Host "CRITICAL: Cannot connect even with TLS 1.2" -ForegroundColor Red Write-Host "Check firewall, proxy, or network restrictions" -ForegroundColor Yellow exit 1 # Scenario 4: Unknown issue - shouldn't normally hit this } else { Write-Host "Configuration issues detected - review results above" -ForegroundColor Yellow exit 1 } #endregion #endregion ## Implementation and Remediation ### Automated Remediation Automox offers automated tools to evaluate and enforce TLS standards across your environment via the [Automox Worklet Catalog](https://console.automox.com/worklet-catalog). - [Windows - Security - Enable Strong Crypto and TLS Defaults for .Net Framework](https://console.automox.com/manage/worklet-catalog/2788bea9-92f5-44ba-827d-cf97b05c6f06) **Warning:** Changing TLS standards and cipher suite order can affect Windows applications relying on SCHANNEL. Test thoroughly in a lab before broad deployment. ### Manual Remediation For manual updates, follow the Automox Knowledge Base article: [Force PowerShell to Use TLS 1.2](https://help.automox.com/hc/en-us/articles/31578579603732-Force-PowerShell-to-Use-TLS-1-2#h_01KE7VK9Z9TXBB0EGEDZT5B91W). It explains how to adjust registry and session settings to prioritize secure protocols in PowerShell and .NET Framework. **Note:** These requirements align with AWS TLS standards and improve Automox platform security. --- # Automated Vulnerability Remediation FAQ _Section: Product Documentation › Automox Integrations › Automated Vulnerability Remediation (AVR) • Source: https://docs.automox.com/product/Content/Product%20Documentation/Automox%20Integrations/Automated%20Vulnerability%20Remediation%20(AVR)/Automated_Vulnerability_Remediation_FAQ.htm_ FOR EXISTING CUSTOMERS ONLY! The following are common questions and answers about Automated Vulnerability Remediation (AVR) 1. **If I execute any actions from AVR, will it restart those systems?** - No - The patch executes, but the system is not restarted 2. **Can I recreate a connection?** - If an API key needs updating, Automox currently recommends creating a new connection with the updated API key and region information. 3. **Can you use Automated Vulnerability Remediation with Rapid7 Nexpose?** - No - AVR is a platform to platform integration and does not support pulling data directly from the Rapid7 Nexpose console. 4. **Is it currently possible to leverage worklets from the Worklet Catalog for remediations?** - You can use worklets from the catalog as long as the worklet is already defined as a custom policy within the organization. 5. **Is it possible to configure the integration to run at a particular time during the day?** - No - The integration with Rapid7 is only configured to run on a schedule once per day at 4 AM MT. 6. **Why don't I see any CVEs for App Store on macOS?** - Automox now includes severity data for native macOS packages. However, updates for applications that are included with macOS are updated as part of the OS update. For example, App Store would be updated when you install the macOS update. For more information, see [macOS Best Practices: Patch Notifications & CVEs](../../Patching/macOS_Best_Practices__Patch_Notifications___CVEs.htm). ## Troubleshooting 1. **When a saved configuration runs, I receive an “invalid action connection unauthorized” error.** - This error occurs when you select an invalid API key or region when creating a connection. Create a new connection and verify the API key and region are correct for your Rapid7 Platform organization. ![](../../../Resources/Images/remediations-failed.png) --- # Automated Vulnerability Remediation Integration _Section: Product Documentation › Automox Integrations › Automated Vulnerability Remediation (AVR) • Source: https://docs.automox.com/product/Content/Product%20Documentation/Automox%20Integrations/Automated%20Vulnerability%20Remediation%20(AVR)/Automated_Vulnerability_Remediation_Integration.htm_ FOR EXISTING CUSTOMERS ONLY! Automated vulnerability remediation (AVR) brings together vulnerability detection and remediation. AVR shortens the vulnerability remediation cycles. AVR allows you to do the following: - Automatically import prioritized vulnerabilities from InsightVM's Platform API into the Automox console - Extend remediation actions through Worklets using Rapid7 vulnerability solution details - Identify coverage gaps in managed devices between Rapid7's InsightVM API and the Automox console - Remediate third-party vulnerabilities. Refer to [Understanding Automox Severity Data](../../Patching/Understanding_Automox_Severity_Data.htm) for a list of software packages Automox can update. ![](../../../Resources/Images/avr-success.png) ## Setting up for Rapid7 Integration Follow these requirements and configuration steps to ensure the integration with Rapid7 is successful. **Prerequisites**: - You must have the required permissions for the organization where the devices are located. - Your organization is under a plan that includes Automated Vulnerability Remediation. ### Requirements To use AVR, you need the following information: - Your active Rapid7 license for InsightVM (Cloud Enabled) - Your active Rapid7 Insight Platform API key - Rapid7 Insight Platform region information - You have an active Automox license that includes AVR - **Note**: InsightConnect is **not** required ### Accessing your Rapid7 API key Before configuring a connection to Rapid7 InsightVM from within Automox, first collect the information needed to save a connection. This includes generating a Rapid7 Insight Platform API key and identifying the appropriate Rapid7 region. See also [Rapid7 Api key](https://docs.rapid7.com/insightvm/servicenow-security-operations/#rapid7-api-key)documentation. 1. Using an administrator account, login to the Rapid7 Insight Platform at [https://insight.rapid7.com/platform#/](https://insight.rapid7.com/platform#/) 2. After logging in, capture the region information (you need this later) and click the gear icon **()** to reveal the **API Keys** sub-menu. Click **API Keys** to continue. ![](../../../Resources/Images/api_key_menu.png) 3. Click **New User Key** 4. To generate a new user key, select an **Organization** from the drop-down menu and assign a **Name**to that organization. ![](../../../Resources/Images/generate_new_user_key.png) 5. Click **Generate**. 6. Copy the API key from the dialog window. You need this to configure the provider connection in a later step. When you are finished, click **Done**. ![](../../../Resources/Images/copy_api_key.png) ## Creating a Connection and Configuration for the Rapid7 integration To set up the automated vulnerability remediation integration with Rapid7, follow the steps described in this section: 1. **Creating a Connection** to the Rapid7 Platform API 2. **Creating a Configuration**, which defines Asset and Vulnerability scope After you complete these steps, Automox pulls remediations on a recurring basis. ### Creating a Connection 1. From the Automox console, select **Automate → Remediations**. 2. **Note**: **If you are accessing the Remediations page for the first time**, two boxes appear as shown here. Select the **Get Started**button in the Partner Integration: Rapid7 box and skip to Step 6 to configure the connection. ![](../../../Resources/Images/remediations-firsttime.png) 3. The Remediations page opens to the **Automated** tab. ![](../../../Resources/Images/remediations-auto-addnew.png) 4. Click **Add New**. 5. From the Integration Provider drop-down menu, select **Rapid7 InsightVM**. Click **Next.** ![](../../../Resources/Images/avr-integration-provider.png) 6. Follow these steps to configure the connection: - Select **Create a new connection**. Make sure you have the required information ready. - In the **Connection Name** field, enter a descriptive instance name. (For example, for customers with multiple organizations or regions: division01-us3 an division02-us2). - Enter the **Rapid7 API key**. - Select the region from the **Rapid7 Region** menu. - Click **Next**. 7. Because connections are reusable, you only need to perform these steps more than once if there are multiple Rapid7 organizations in the environment. If only a single connection is necessary, select the existing connection from the Connection drop-down menu. ### Creating a Configuration After creating or selecting a connection, define the configuration settings. ![](../../../Resources/Images/enter-conn-details.png) For information about R7 Asset Tags, see [Rapid7 Insight documentation](https://docs.rapid7.com/insightvm/applying-realcontext-with-tags/). 1. Enter a descriptive **Configuration Name**. 2. Add any **Rapid7 Asset Tags** that you would like to scope from Rapid7. Hit enter or tab to define multiple tags. ![](../../../Resources/Images/tags.png) 3. From the **Rapid7 Vulnerability Scope** drop-down list, select a scope from the options available: - **Exploitable Critical Vulnerabilities**:Vulnerabilities with critical exploits available - **Common Exploitable Vulnerabilities**: Commonly exploited vulnerabilities - **Vulnerabilities with 3+ Exploits**: Vulnerabilities that have three or more exploits published - **CISA Recommended Vulnerabilities**: Cybersecurity and Infrastructure Security Agency identified threats - **CVSS Score > 8**: (CVSSv3) Vulnerabilities that are greater than a severity score of 8 4. Click **Submit** to complete the configuration. Automox saves the integration and immediately starts a pull of Rapid7 data. **Note**: If you do not want to immediately fetch data, clear the checkbox for **Fetch latest remediations now**. 5. When the sync successfully finishes, the status is updated in the banner area of the Automox Console. You can now see the Automated tab and any reports. Refer to [Remediation and Configuration Management](Remediation_and_Configuration_Management.htm) for further details. ## Related Topics - [Remediation and Configuration Management](Remediation_and_Configuration_Management.htm) - [Automated Vulnerability Remediation FAQ](Automated_Vulnerability_Remediation_FAQ.htm) - [Using Automox Vulnerability Sync](../../Vulnerability Sync/Using_Automox_Vulnerability_Sync.htm) --- # Remediation and Configuration Management _Section: Product Documentation › Automox Integrations › Automated Vulnerability Remediation (AVR) • Source: https://docs.automox.com/product/Content/Product%20Documentation/Automox%20Integrations/Automated%20Vulnerability%20Remediation%20(AVR)/Remediation_and_Configuration_Management.htm_ FOR EXISTING CUSTOMERS ONLY! After you set up and connect your integration for Automated Vulnerability Remediation (AVR), from the Remediations page, you can view remediation reports, create new connections, filter and search for recent reports, and manage configurations. **Prerequisites** - You must have the required permissions for the organization where the devices are located. See [Roles and Permissions](../../Global Access Management/Roles_and_Permissions.htm). - Your organization is under a plan that includes automated vulnerability remediation. ## Automated Remediations Table From the main Remediation page, select the **Automated** tab to view the following data about recent remediations. ![](../../../Resources/Images/automated-table.png) | Column name | Description | | --- | --- | | Report | Click View Report to view remediation details. | | Status | This shows the status of the remediation. | | Configuration | Click the name to view the configuration associated with the selected report. | | Patchable Vulnerabilities | This shows the number of patchable vulnerabilities. | | Rapid7 Solutions | This shows the number of Rapid7 solutions. | | Unknown Devices | This shows the number of devices that are unknown (they do not currently exist in your Automox account). | | Updated | This shows the date and time when the report was created. | | Actions | Possible actions: View ReportDelete | ## Filter Panel The filter panel includes different options that allow you to customize the display of the remediations table. You can clear selections individually or select **Clear All**to reset the panel to the default settings. ![](../../../Resources/Images/automated-filters.png) ### Reports Filter By default, the table shows all reports generated for each configuration. The filter selected is: **Include previous executions**. Select **Show latest executions only** to limit the number of reports listed by the last generated report per configuration. ![](../../../Resources/Images/filter-reports.png) ### Status Filter To filter the list of reports by status, select one or a combination of all options: - **Ready To View**: The details of these reports are available - **Building**: The report is in progress - **Error**: If the remediation fails, the report is listed with this status ### Configuration Filter You can filter the list to show only reports for a specific configuration. From the configuration drop-down menu, you can search by name and select the configuration. ### Display Options This filter allows you to group the reports by configuration. Select **Sort Groups by** and choose from the options to show reports in the order you want: - **Latest Update (Asc)**: Show the most recently updated reports in ascending order: oldest first - **Latest Update (Desc)**: Show the most recently updated reports in descending order: newest first. - **Name (Asc)**: Show reports by configuration name in ascending (A to Z) order. - **Name (Desc)**: Show reports by configuration name in descending (Z to A) order. Clear the checkbox **Group by configuration** to show data listings for all configurations. When you clear this, the Configuration column reappears in the table. ## Configurations Table Select the **Configurations** tab to view and manage configurations. Use the **Actions** menu to edit a configuration. The table provides the following data. ![](../../../Resources/Images/config-tab.png) | Column name | Description | | --- | --- | | Name | This is the name of the configuration. | | Connection | This is the connection associated with the configuration. | | Rapid7 Asset Tags | This lists all Rapid7 asset tags associated with the configuration. | | Rapid7 Vulnerability Scope | This specifies the Rapid7 vulnerability scope type, which can be: Exploitable Critical VulnerabilitiesCommon Exploitable VulnerabilitiesVulnerabilities with 3+ ExploitsCISA Recommended VulnerabilitiesCVSS Score > 8 | | Next Scheduled Run | This shows the time and date of the next scheduled run. | | Actions | Possible actions: EditDeleteView ReportsFetch Latest RemediationsDisable Scheduling | ## Viewing Remediation Details You can view the **Remediation Details** page of any report. This provides a detailed view of the specific vulnerabilities affecting your environment and options to remediate them. - From the Automated page, click **View Report** to open the details page. ![](../../../Resources/Images/remediations-details.png) Identified vulnerabilities are automatically parsed into three categories: - Patchable Vulnerabilities - Rapid7 Solutions - Unknown Devices ## Patchable Vulnerabilities Patchable Vulnerabilities lists vulnerabilities in packages that are grouped by severity. The package includes the CVEs and affected devices. **Note**: Automox now includes severity data for native macOS packages. However, updates for applications that are included with macOS are updated as part of the OS update. For example, App Store would be updated when you install the macOS update. For more information, see macOS Best Practices: Patch Notifications & CVEs. ![](../../../Resources/Images/remediations-details-patchablevuln.png) - Click **Remediate** to install and patch the devices without a schedule. **Note**: - If the device is online and available, the patch is installed immediately. - If the device is offline or unavailable, the status shows as pending and patches when the device is available. - If a patch install requires a reboot, this action will not automatically restart a device. - When the remediation is in progress, a status will show which patches are **In Progress**, **Failed**, or were a **Success.** ### Filtering and searching for packages You can use the filter panel and search bar to search for specific remediations by severity, CVE ID, or KB. You can also search for specific devices within each remediation Devices list. ## Rapid7 Solutions Vulnerabilities that must be remediated using a workflow other than patching, such as configuration changes, are listed under the **Rapid7 Solutions** tab. Rapid7 supplies information about how to remediate with the vulnerability data. See also [Rapid7 plugin listings](https://extensions.rapid7.com/extension?query=automox&sort=relevance). ![](../../../Resources/Images/remediations-details-R7.png) - Click **Remediate With Worklet** to view a list of your existing worklet policies to remediate vulnerabilities with. ![](../../../Resources/Images/remediate-w-worklet.png) - You can use the search bar in the Remediate with Worklet window to find a specific worklet. - Click **View Details** to review and edit a worklet. A separate browser window opens. - Click **Remediate** to schedule the worklet. ### Filtering and searching for solutions From the main Rapid7 Solutions page, you can use the filter panel and search bar to search for specific solutions by vulnerability or CVE ID. Click the individual drop-down menus of a solution to search for CVEs, devices, or to view the Fix Details of the Rapid7 solution ![](../../../Resources/Images/solution-details.png) ## Unknown Devices The **Unknown Devices** tab lists devices that are enrolled in Rapid7, but cannot be found in your Automox account. You can use this information to identify gaps in your environment where the Automox Agent is not already installed. The list of device hostnames can be exported and used in a tool like [Automox Agent Deployer](../Automox_Agent_Deployer.htm), which supports automatic deployment to CrowdStrike-managed devices. ![](../../../Resources/Images/unknown-devices.png) - Click **Export CSV** for a list of all unknown devices. ## Related Topics - [Automated Vulnerability Remediation Integration](Automated_Vulnerability_Remediation_Integration.htm) - [Automated Vulnerability Remediation FAQ](Automated_Vulnerability_Remediation_FAQ.htm) - [Using Automox Vulnerability Sync](../../Vulnerability Sync/Using_Automox_Vulnerability_Sync.htm) --- # Automox Agent Deployer _Section: Product Documentation › Automox Integrations • Source: https://docs.automox.com/product/Content/Product%20Documentation/Automox%20Integrations/Automox_Agent_Deployer.htm_ The Automox Agent Deployer is a locally downloaded and executed client binary that allows you to deploy Automox agents to CrowdStrike managed device estate using the CrowdStrike API for the Real-Time-Response module. After configuring variables using a CLI-based GUI for ease of use, the client installs the Automox agent on devices scoped in the configurator step. ## Configuring and setting up scripts This consists of 5 steps. The following sections describe them. ### Step 1: Download the deployer application | OS - Architecture | File | | --- | --- | | Linux - arm64 | ax-agent-deployer_linux_arm64 | | Linux - amd64 | ax-agent-deployer_linux_amd64 | | macOS - arm64 | ax-agent-deployer_macos_arm64 | | macOS - amd64 | ax-agent-deployer_macos_amd64 | | Windows - arm64 | ax-agent-deployer_windows_arm64.exe | | Windows - amd64 | ax-agent-deployer_windows_amd64.exe | **Note**: - For **Windows**, open up a PowerShell window and call the .exe file directly. - For **Linux**or**macOS**, open a terminal window in the directory where you have downloaded the file, and run `chmod a+x `, replacing `` with the name of the downloaded file. You can then execute the file by running `./`. ### Step 2: Configurator (for first-time use) After you download and install the Agent Deployer application, select `command-config`. Now you can set up the configuration including the file path, Automox access key, CrowdStrike Client ID, CrowdStrike secret, the CrowdStrike API region, and the platform deployment size. All of these elements are required. ![](../../Resources/Images/agent-deployer.gif) #### Requirements - Automox Access Key - CrowdStrike API Client ID - CrowdStrike API Client Secret - CrowdStrike API Region - To identify the API key region, refer to the Cloud environment column in the overview table of your CrowdStrike API reference article, which is accessible from here: [https://falcon.crowdstrike.com/documentation/46/crowdstrike-oauth2-based-apis](https://falcon.crowdstrike.com/documentation/46/crowdstrike-oauth2-based-apis). ![](../../Resources/Images/CS-cloud-API-ref.png) - CrowdStrike API Client Permissions - Hosts - read - For getting details on hosts being deployed to - Host Groups - read - For getting available groups and membership details - Real time response - read and write - For executing the RTR installation scripts. The write permission here allows custom scripts to run. If opting to upload RTR installation scripts, the **RTR (admin) - write** permission is **temporarily** required. For security reasons, remove this permission after uploading is completed. - Response policies - For verifying that the selected groups have Real time response capabilities enabled - Group Response Policy Configuration - All groups selected for deployment must have the following Real Time Response Policy settings enabled - Real Time Response - enabled - Custom scripts - enabled - Falcon scripts - enabled ![](../../Resources/Images/deployer-sensor-settings.png) After you configure the Automox key and CrowdStrike configuration values, the deployer uses those details to connect to the CrowdStrike API to get a list of available groups and provide them for picking where to deploy. Multiple groups can be selected. ### Step 3: Select upload or print custom scripts The configurator provides an option to upload or print the RTR scripts necessary for deployment of the Automox agent. If opting to upload RTR installation scripts, the **RTR (admin) - write** permission is **temporarily** required. For security reasons, remove this permission after uploading is completed. The upload route is the easiest and most likely to ensure success when deploying as there is no risk of errors related to formatting/new lines from copying and pasting the printed scripts. #### Upload Scripts ![](../../Resources/Images/deployer-upload-scripts.png) 1. Before you continue, confirm that the Real time response (admin) - write permission is enabled for the CrowdStrike API Client being used by the deployer. If it is not configured when attempting to upload, 2 retries are allowed before the configurator exits. ![](../../Resources/Images/deployer-realtime-response.png) 2. The deployer then attempts to upload the installation script for each platform. - The scripts are uploaded with permissions that allow them to be used by any user with the RTR Active Responder role or API Client with the **Real time response - write**permission (non-admin). 3. If successful, the configurator continues. Ensure that the **Real time response (admin) - write**permission is removed at this point. It is not needed for normal operation of the deployer and provides too much permission. #### Print Scripts ![](../../Resources/Images/deployer-print-scripts.png) **Note**: The credentials have been rotated in this example. 1. When selecting **print**, the script for each platform is printed for copying and pasting into the CrowdStrike console under **Response Scripts & Files**. The names of the scripts need to make those provided by the deployer. ![](../../Resources/Images/deployer-custom-scripts.png) 2. Navigate to **Response Scripts & Files**and click **Create a script.** 3. Enter the name and description and ensure the correct shell type is selected for each OS. Be aware that Real Time Responder roles are required for this action. **These can be added via User Management in the CrowdStrike console.** - OS Shell Types - Windows: PowerShell - Linux: Bash - macOS: Zsh - **Permissions:**RTR Active Response and RTR Administrator - This permission allows the deployer to use this script without admin permissions. ![](../../Resources/Images/deployer-print-permissions.png) Repeat the steps for macOS and Linux by pressing any key twice and using the name and script content printed for each. **Note**: If the user intends to deploy on all OSes, there must be 3 different scripts for each OS uploaded here. ### Step 4: Set up recurring schedule to run the scripts ![](../../Resources/Images/deployer-recurring-schedule.png) - For the prompt: “Print commands for scheduling the tool to run”, enter **Yes**. - Provide path - defaults to the existing path and determine the frequency. **This is only available for Linux and Windows.** #### Scheduler Example - Windows The application prints the PowerShell script for scheduling when you select Windows as the scheduling platform. - Open PowerShell and run printed script. ![](../../Resources/Images/deployer-PS-example.png) Review Task Scheduler ![](../../Resources/Images/deployer-task-scheduler.png) After you run the recurring schedule script, a new automated task appears in the Task Scheduler. All arguments are pre-populated with necessary flags. You can change any parameters within the Task Scheduler. **Note**: Plain text API secrets are in this scheduled task, which represents a potential security risk. ### Step 5: Save configuration and pre-check You can opt to save the configuration to a file. You can reference this file using the `--config` flag when running the deployer. A configuration file is not required if using the schedule task/cron schedulers as the commands are generated with the configuration values as flags Finally, the deployer attempts to validate that the selected groups for deployment have Real time response capabilities enabled. Any groups with incorrect settings will be logged. ## Deployment Select `command-deploy` to see results of your actions. ![](../../Resources/Images/deployer-cmd-deploy.png) Deploy command and results. For devices that are not online, the commands are queued up via the `queue offline` flag within CrowdStrike. ### Troubleshooting Look out for a few known errors when deploying. #### Missing scripts RTR Custom Script 'AutomoxAgentInstaller-' is missing, cannot deploy. Please run configuration to upload or print the required script" This error message appears when the specified RTR Custom Script is not found in the CrowdStrike platform. A couple of reasons are possible: 1. The scripts were not created. - In this case, run the `config` command to upload or print the scripts. 2. The permissions are not correct on the script. - Set the script permissions to the RTR Active Responder and Admin ![](../../Resources/Images/deployer-permissions-rtr.png) #### Offline Hosts host 'abc-123' (device-id) was offline, deployment will be performed by Crowdstrike when the device is online This message is not necessarily an error. It appears when a host in the deployment group was offline. CrowdStrike attempts to run the command when the host is online; however, the deployer does not track these queued commands. #### Invalid scripts RTR Custom Script 'AutomoxAgentInstaller-' returned an error during deploy. This is usually due to the script being improperly formatted or invalid. Please run configuration to upload or print the required script to fix. If manually uploading, refer to the README for troubleshooting steps. If the scripts were manually uploaded to the CrowdStrike platform, they might not have been pasted correctly. The most common reason for this is trailing empty lines at the end of a script. Remove these and try again. If this doesn’t fix the issue or if there are no empty lines, try uploading the scripts via the deployer. ![](../../Resources/Images/deployer-invalid-script.png) #### Timeout **The installation commands run during the deployment must succeed within 30 seconds.** If the command takes longer than 30 seconds to complete, an error appears stating that the command timed out. This could be due to a slow connection or some other error for the host. One thing to try is rebooting the host that failed to install (if that’s an option). #### Other deployment errors The deployment might capture other errors. Unknown errors return the raw details from the deploy operation. These are usually helpful in understanding what went wrong. --- # Automox Content Pack for Palo Alto Networks Cortex XSOAR _Section: Product Documentation › Automox Integrations • Source: https://docs.automox.com/product/Content/Product%20Documentation/Automox%20Integrations/Automox_Content_Pack_for_Palo_Alto_Networks_Cortex_XSOAR.htm_ Cortex XSOAR is the Palo Alto Networks security orchestration automation and response (SOAR) product. The Automox content pack for Cortex XSOAR provides organizations with the necessary tools to immediately and autonomously take action in the Automox platform from XSOAR. ## What does the content pack do? - Upload Vulnerability Reports - Get and approve/reject batches of tasks - Get, update, and delete device groups - Get and update devices - Get organizations and their users - Get and run policies ## The content pack includes: - The Automox integration, containing many commands that you can use ad hoc from incident war rooms, or as the building blocks in playbooks and scripts to address specific administration or remediation incidents. - A sub-playbook titled "Upload Vulnerability Report to Automox" which automates the upload and approval process for vulnerability remediation in Automox. This sub-playbook provides your incident team with complete control over remediation efforts using Automox. You can find and install the latest version of the Automox Content Pack for XSOAR in the marketplace of your licensed version of Cortex XSOAR. Additionally, to view the complete documentation of this pack and to download the files to install manually, you can visit the [Cortex XSOAR Marketplace](https://xsoar.pan.dev/marketplace/details/Automox). ## Using the "Upload Vulnerability Report to Automox" sub-playbook After installing the Automox content pack, a new playbook appears in your playbooks catalog titled "Upload Vulnerability Report to Automox." This playbook accepts the entryId of a Vulnerability Report CSV file as its input. Integrate this sub-playbook into other playbooks that generate vulnerability reports to automatically upload those reports, and create the tasks for remediation in Automox. --- # Automox Plugin for Rapid7 InsightConnect _Section: Product Documentation › Automox Integrations • Source: https://docs.automox.com/product/Content/Product%20Documentation/Automox%20Integrations/Automox_Plugin_for_Rapid7_InsightConnect.htm_ InsightConnect is the Rapid7 Security Orchestration Automation and Response (SOAR) product. The Automox plugin for Rapid7 InsightConnect provides the ability for teams to orchestrate daily IT operations tasks such as device management, triggering remote outcomes on endpoint devices, and Automox platform administration. Through the use of the plugin, teams can build workflows to orchestrate repeatable tasks and streamline integrations between Vulnerability Management and Patch Management teams. Key features of the plugin include: - Retrieve and manage Automox managed devices - Manage Automox groups - Initiate Vulnerability Sync uploads and remediation of issues - Trigger workflows based on Automox platform events You can find the latest version of the plugin in the [Rapid7 Extension library](https://extensions.rapid7.com/extension/automox). ## Vulnerability Sync Workflow This pre-built workflow automatically imports the vulnerability detection reports from InsightVM through InsightConnect into Automox. You can find this workflow in the Rapid7 Extension Library: - [Orchestrate Automox Vulnerability Sync with Rapid7 InsightVM](https://extensions.rapid7.com/extension/Orchestrate-Automox-Vulnerability-Sync-with-Rapid7-InsightVM) When you use this method, remediation teams do not need to coordinate the export of Rapid7 InsightVM/Nexpose vulnerabilities report from their security teams. In addition, you do not need to manually upload a vulnerability report into Automox. When the imported report is ready, you can continue with the vulnerability process from the point of observing the mapping process until it is complete and taking actions. Follow the description in the Vulnerability Sync documentation: [Syncing the Imported Report](https://help.automox.com/hc/en-us/articles/8273423308564-Using-Automox-Vulnerability-Sync). ## Slack and Teams Workflow The InsightConnect plugin also allows you to display the device details from Automox in your ChatOps tools: Slack and Teams. You can find the two workflows and documentation on using them in the Rapid7 Extension library: - [Lookup Automox Host from Slack](https://extensions.rapid7.com/extension/Lookup-Automox-Host-From-Slack) - [Lookup Automox Host from Teams](https://extensions.rapid7.com/extension/Lookup-Automox-Host-From-Teams) For more information about these topics refer to these links: - [Rapid7 Extension Library](https://extensions.rapid7.com/) - [About Automox Vulnerability Sync](../Vulnerability Sync/About_Automox_Vulnerability_Sync.htm) ## Related Topics - [Automox & Rapid7](https://www.automox.com/automox-and/rapid7) --- # Automox Splunk Integration _Section: Product Documentation › Automox Integrations • Source: https://docs.automox.com/product/Content/Product%20Documentation/Automox%20Integrations/Automox_Splunk_Integration.htm_ The Automox Splunk apps are applications released to Splunkbase, which consist of two primary components: 1. [Automox Technology Add-On for Splunk](https://splunkbase.splunk.com/app/6119/) 2. [Automox Dashboard for Splunk](https://splunkbase.splunk.com/app/6120/) In combination, these two apps allow you to pull Automox console data consisting of device, policy, and event information into Splunk Enterprise or Splunk Cloud platforms and they enable you to visualize and search across the imported Automox data. ## Installation You can install both the **Automox Technology Add-On for Splunk** and the **Automox Dashboard for Splunk** apps either through your Splunk instance or with a more manual process of downloading the package from Splunkbase to install manually. The following sections outline both options. You must first install and configure the Automox Technology Add-On app before the Automox Dashboard for Splunk can populate with any visualizations or searches. In organizations where visualizations are custom tailored, the Automox Dashboard for Splunk is a nice starting point; however, it is not required to receive value from the Automox data imported with the Technology Add-On. ### Install within Splunk When you install apps from within a Splunk instance, follow these steps: 1. On the home page left menu, select **+ Find More Apps**. 2. From the **Browse More Apps** page, search for **Automox**. 3. Click **Install** for both apps: - Automox Dashboard for Splunk - Automox Add-On for Splunk 4. Provide Splunkbase credentials and submit. ### Download and Install from Splunkbase When you install the apps from Splunkbase, first log in to Splunkbase and then download the two app packages. After you download these, follow these steps: 1. On the home page, select the **Apps** menu and then click **Manage Apps**. 2. Select **Install app from file**. 3. Select the downloaded app packages. 4. Perform a restart of Splunk when prompted. When the installation is complete, the apps are visible under the **Apps** menu in Splunk. ## Configuring the Technology Add-On After you install the Automox Technology Add-On, you must configure it to enable the collection of data from Automox. This configuration requires two steps: 1. [Connection Setup](#Connecti) 2. [Input Creation](#Input) ### Connection Setup Within the Splunk interface, navigate to the **Apps** menu and click **Automox Add-On for Splunk**. ![splunk-ax-addon.png](../../Resources/Images/splunk-ax-addon.png) This takes you to the configuration items as part of the add-on. Select the **Configuration** tab, which allows you to create and manage connections, configure proxy settings, and configure the log settings. In most environments, it is only necessary to create a new connection: ![splunk-add-connection.png](../../Resources/Images/splunk-add-connection.png) To add a new connection, provide details for the following: 1. **Connection Name**: A unique name provided to your connection to reference during input configuration. 2. **API Key**: An Automox API key is required to pull details from the Automox API. Refer to [Managing Keys](../Settings/Managing_Keys.htm) for details about how to create a new API key. 3. **Organization ID**: This is a required ID. This is valid for both single and multi-org environments. After you configure at least one connection, define the inputs for the add-on. ### Input Creation The add-on currently provides three types of inputs that you can configure: 1. Automox Event Import 2. Automox Endpoint Import 3. Automox Policy Details Import You can configure each input independently to allow flexibility in which data to import into a Splunk environment. To configure a new input, select **Create New Input** and then select which import to use. ![splunk-ax-event-import.png](../../Resources/Images/splunk-ax-event-import.png) When configuring an input, you must provide: 1. **Name**: A unique and descriptive name for the input 2. **Interval**: Define the number of seconds to wait between each input collection 3. **Index**: The index to import events into Splunk from the input 4. **Connection**: The name of the connection configured in the previous section Automox currently recommends the following settings for **Interval** for each input type: | Input | Interval Value (in seconds) | Description | | --- | --- | --- | | Automox Event Import | 3600 | Every hour | | Automox Endpoint Import | 86400 | Once per day | | Automox Policy Details Import | 86400 | Once per day | Due to the nature of the data pulled through the Automox API, currently only the **Event Import** input type allows you to only import "new" events. This input uses an internal checkpoint to track when it last imported an event, ensuring duplicate events are not received. Conversely, the Endpoint and Policy Details inputs pull all data each time the inputs run. This is why Automox recommends running the **Endpoint Import** and **Policy Details Impo**rt only one time per day. ## Collected Data Types All data collected by this add-on contains a source beginning with "automox_". The source type of the data varies by the events associated with the input. The following table provides a breakdown of input to sourcetypes imported: | Input | Source | Sourcetypes | | --- | --- | --- | | Automox Event Import | automox_event_import | automox:console:events | | Automox Endpoint Import | automox_endpoint_import | automox:endpointautomox:endpoint:software | | Automox Policy Details Import | automox_policy_details_import | automox:policy | ### Dashboards After you import Automox data into Splunk with the Automox Technology Add-On, you can start visualizing the events. The Automox Dashboard for Splunk provides an out of the box and convenient way to visualize endpoints, policies, and events. Install the Dashboard app and navigate to it from within the Splunk interface: ![splunk-ax-dashboard.png](../../Resources/Images/splunk-ax-dashboard.png) This app provides three dashboards: Endpoints, Policy Details, and Console Events. Each dashboard lets you select the index where imported events are stored, additional filtering such as groups and tags for devices, and the time period of the data. Remember, this dashboard provides a starting point for end users. Automox encourages adding new visualizations to dashboards to better visualize based on business needs. ### Searches You can use the following example searches after you configure the Technology Add-On. - List the different Automox sourcetypes with counts: index=* source=automox_* - List the number of compliant and non-compliant endpoints: index=* sourcetype="automox:endpoint" - List the number of endpoints by operating system: index=* sourcetype="automox:endpoint" - List the different Automox console events with counts: index=* sourcetype="automox:console:events" ## Troubleshooting See the following troubleshooting topics. ### Logs To troubleshoot any issues, particularly with the Technology Add-On, collect and review the logs from both the Splunk environment and the add-on logs. If you are pulling the logs from the Splunk host directly, they are usually located here: /var/log/splunk/ The most useful logs to review are: - `ta_automox_add_on_for_splunk_automox_endpoint_import.log` - `ta_automox_add_on_for_splunk_automox_event_import.log` - `ta_automox_add_on_for_splunk_automox_policy_details_import.log` - `splunkd.log` Each of these log files correlate to the respective input as well as the splunkd.log file used for troubleshooting any larger environment related issues. You can also query directly within the Splunk interface for logs resulting from the add-on. - Navigate to **Search & Reporting** and search for: index="_internal" sourcetype="taautomoxaddonforsplunk:log" This provides events from the **Automox Technology Add-On** for use in diagnostics and troubleshooting. These events show the number of events, endpoints, and policies imported when inputs run, as well as ERROR messages related to issues. ### Changing Log Level If you need more granular logging, you can change the log level of the add-on by following these steps: 1. Navigate to **Automox Add-On for Splunk** from the Apps drop-down menu. 2. Select the **Configuration** tab. 3. Within the configuration, select the "Logging" tab 4. Change the log level from the default of **INFO** to **DEBUG.** You can also change the log level so that only ERROR or CRITICAL logs are emitted, which reduces logging from the add-on. ### No Data is Populated in the Automox Dashboard This issue is usually related to one of three things: 1. The Technology Add-On hasn't been installed or configured yet. 2. The index where events are pulled differs from what you configured in the Technology Add-On inputs. 3. Events of the specific dashboard were from an earlier time interval (default: Today). Perform an initial search within Splunk to ensure that events have been imported. Check that you are searching across the correct index. Then increase the time period to include a larger time frame from when the app was installed and configured: ![splunk-new-search.png](../../Resources/Images/splunk-new-search.png) You can use the following example search query: index=automox source=automox_* If a search finds no events, ensure the inputs are properly configured and review the logs from the Technology Add-On. --- # ServiceNow Service Graph Connector for Automox _Section: Product Documentation › Automox Integrations • Source: https://docs.automox.com/product/Content/Product%20Documentation/Automox%20Integrations/ServiceNow_Service_Graph_Connector_for_Automox.htm_ The Service Graph Connector for Automox is an application for the ServiceNow platform that provides configuration management database (CMDB) import capabilities for Automox device data. For teams operating out of or collaborating with ServiceNow, importing Automox devices into ServiceNow can improve the accuracy of your CMDB. This enables improved decision making, asset tracking, incident management, and cross-functional collaboration. The ServiceNow Store page for the app is here: [Service Graph Connector for Automox](https://store.servicenow.com/sn_appstore_store.do#!/store/application/f377c1848772b410490f52883cbb353d/) ## Imported Classes The application imports data for multiple built-in CMDB CI classes, along with the custom Automox Device class. ### Computers Conditional checks against the OS Family and the OS Name define the CMDB class for computer records. The `cmdb_ci_computer class` is a fallback condition if there is no match for the OS Family and Name. - Personal Computer (`cmdb_ci_pc_hardware`) - Linux Server (`cmdb_ci_linux_server`) - Windows Server (`cmdb_ci_windows_server`) - Computer (`cmdb_ci_computer`) #### Fields - Name - If the Automox agent obtained the FQDN for the device, it is used in this field. Otherwise, the name value is the name in Automox. - Serial number - Set to the system serial number - Vendor - RAM (MB) - Manufacturer - Model ID - OS Version - IP Address - The IPv4 address of the primary network adapter - Operating System - The operating system for the device including OS Family, Name, and Version - CPU name - MAC Address - Network Adapter - First connected network adapter for the system - Used for CI lookup - Serial Number - Used for CI lookup - System (if available) - IP Addresses - IPv4 and IPv6 addresses associated with the first NIC of the device - First public IP address for the device ### Network Adapters The first connected network adapter for each device is imported and used for CI lookup. - Network Adapter (`cmdb_ci_network_adapter`) #### Network Adapter Fields - MAC Address - Name - Set to the network adapter device name (for example, Network Adapter 1 or en0) - IP Address - Set to the primary IPv4 address of the network adapter ### Serial Numbers Serial numbers for the device are imported, including system serial number if it is available. - Serial Number (`cmdb_serial_number`) #### Serial Number Fields - Serial Number - Serial Number Type - `system` - Absent - Valid ### IP Addresses The IPv4 and IPv6 addresses for the first connected network adapter of the device are imported, along with the first public IP address for the device. - IP Address (`cmdb_ci_ip_address`) #### IP Address Fields - Name - IP Version - IP Address - Nic - Reference to the primary device network adapter - Owned by Configuration Item - Reference to the device CI ### Automox Device Automox Device is a custom table included with the application that extends the Configuration Item (`cmdb_ci`) table. The table provides most of the device-specific fields available on an Automox device. **Note:** Software packages and policy details do not get imported with the current version of the application. **Note**: Any references to **Reboot** are now displayed as "Restart" in the Automox Console. - Automox Device (`x_aut12_service_gr_automox_device`) #### Automox Device Fields | ID Organization ID Configuration ItemReference to the computer CI Last Process Time Reboot Deferral Count IP Addresses PublicList of public IP addresses Last Logged In User Deleted Refresh Interval Serial Number IP Addresses PrivateList of private IP addresses Name Reboot is Delayed By User Display Name Connected CPU Vendor Patch Deferral Count Server Group ID OS Family Reboot is Delayed By Notification Model ID Create Time Device Statue IP Address Compliant Last Disconnect Time | Policy Status Needs Reboot Timezone UUID Next Patch Time MAC Address Model Pending Patches Needs Attention Last Update Time Custom Name Service Tag OS Version ID Pending Notification Count Last Refresh Time Uptime OS Name Reboot Notification Count RAM Tags ConnectionReference to the http_connection record used to import the device Is Delayed By User Manufacturer OS Version Agent Version Is Delayed By Notification Patches | | --- | --- | ## Installation The installation section and the rest of this guide assume that your organization already has a ServiceNow instance. It is common to have sub-production and production instances. If your organization has both, you can test the application before deploying it in production by installing it on your sub-production instance. ### Application Dependencies The application requires the following ServiceNow plugins/applications for installation: - ITOM Licensing (`com.snc.itom.license`) - ITOM Discovery License (`com.snc.itom.discovery.license`) - Contract Management (`com.snc.contract_management`): 1.0.0 - Configuration Management (CMDB) (`com.snc.cmdb`): 1.1 - CMDB CI Class Models (`sn_cmdb_ci_class`): 1.30.0 - System Import Sets (`com.glide.system_import_set`): 1.0.0 - Integration Commons for CMDB (`sn_cmdb_int_util`): 2.6.3 - CMDB Workspace (`sn_cmdb_workspace`): 1.0.0 Optionally, you can use the **IntegrationHub ETL** application to modify the default CMDB mappings. ### Store Listing The ServiceNow Store listing is here: [Service Graph Connector for Automox](https://store.servicenow.com/sn_appstore_store.do#!/store/application/f377c1848772b410490f52883cbb353d/). Click the **Get** button on the listing to select which ServiceNow instances you want to allow access to the application. ### Plugin Dependency Activation Before you install the application, you must activate the ITOM Discovery License plugins in your instance. The rest of the dependencies are installed as part of the application installation. To check whether these plugins are activated, follow these steps: 1. Navigate to the **System Plugins List**. 2. Type `sys_plugins.list` into the filter navigator and press enter. 3. Verify that **ITOM Licensing** and **ITOM Discovery License** are in the list. #### Plugin Installation To install the ITOM Licensing and ITOM Discovery License plugins if they are not already installed and active, follow the steps described here: **ITOM Licensing Installation** 1. Navigate to the ServiceNow Support portal: [https://support.servicenow.com](https://support.servicenow.com). 2. In the menu, select **Activate a Plugin**. This option links to a separate support page. - Select your target instance. - For the plugin, enter `ITOM Licensing`. - Set a time for activation from the scheduler and submit. 3. To have the activation occur sooner, navigate back to the Support portal. 4. Select **My Open Changes**. 5. Select the Change case for the plugin installation. 6. Update the schedule with a new date and time. 7. Wait for confirmation of successful installation. **ITOM Discovery License Activation** 1. Navigate to the System Plugin State List. **Note:** This is different from the previous list. - Type `v_plugin.list` into the filter navigator and press enter. - Filter the results by ID by entering the ITOM Discovery License plugin ID, `com.snc.itom.discovery.license`. - Select the record. - In the related links for the record, click **Activate**. ### Application Installation After installing and activating the plugin dependencies for the application, you can install the Service Graph Connector for Automox. 1. Navigate to the **All Applications** list by using the filter navigator. 2. Search for **Service Graph Connector for Automox**. 3. Install the application. 4. Refresh the browser window. 5. You should now see the Service Graph Connector for Automox application menu in the filter navigator. A background process during the installation executes the **SG-Automox Discovery Source** Fix Script that the application provides. This fix script installs the **SG-Automox** discovery source and registers the discovery source with ITOM Licensing. ## Setup With the application installed on your ServiceNow instance, you are ready to start the setup process. The Setup module includes a Guided Setup experience for setting up the entire application. Start by navigating to the **Service Graph Connector for Automox > Setup** module using the filter navigator. You should see a Guided Setup that looks similar to the following image: ![](../../Resources/Images/sg-setup.png) The guided setup is a sequential set of steps. Each step in the guided setup provides Embedded Help pages that are viewable via the Embedded Help panel. Note, the embedded help does not display when viewing the modules/pages directly. If you do not see the Embedded Help, click the help (?) icon in the menu bar in ServiceNow to display the help bar. As you complete the guided setup, mark each step as completed to unlock subsequent steps. You can skip some steps, which are labeled accordingly. ### Configure the Connection The **Configure the Connection** group includes steps to create a new HTTP(S) connection (http_connection) associated with the `SG-Automox_Conn_Cred_Alias` Connection and Credential Alias, validate the connection and configure its organizations, and assign the Automox devices read-only role that provides access to the Automox Device table. #### Configure the API Key To use the application to query Automox for devices, you need an HTTP(S) connection and an Automox API key. Use a new API key instead of an existing one. 1. In the Automox console, navigate to **Settings > Keys** to create a new key. 2. Copy the key and navigate back to ServiceNow. 3. Click the **Create New Connection & Credential** related link to create a new connection. 4. Enter the name for the connection. 5. Paste your new API key. 6. Save the connection. 7. Mark this step as complete. To stage a connection; but not use it, mark it as inactive after creation. #### Validate Connection and Set Organizations Follow these steps to validate that the application can access the Automox platform using the API key you provided. 1. Select a connection using the Connection reference field. - A message appears when the application attempts to retrieve the list of organizations for the connection. - If you receive an error message or no organizations are returned, try pasting your API key in your connection once more. 2. To import Automox devices into the CMDB, select the Automox organizations for those devices. 3. Click the **Copy Organization IDs** button. 4. A message appears confirming that the copy action was successful. The message includes a link to the connection record. 5. Select the **Click here** record link in the message window to navigate to the selected connection record. 6. Paste the organization IDs into the **Organization IDs** field. 7. Click the **Update** button to update the organizations associated with the connection. 8. Mark this step as complete. If you have more than one connection, you can set the organizations for the other connections before moving on to the next step. #### Configure the Computer "name" Field Precedence (Optional) When importing devices from Automox, multiple values can be valid as the name for a device. The application allows you to customize the order of fields used with the first non-null value being used. By default, the **name** field on an imported configuration item (CI) is set to the fully qualified domain name (FQDN) if it was discovered by Automox or the **hostname** (`name`) if no FQDN was discovered. In addition, the **custom name** (`custom_name`) can be used to set the name of a CI to the custom name specified in Automox. This is useful for situations where there are hostname collisions across computers within Automox. Because custom names are not necessarily an accurate representation of the identity of a computer in an environment, this value is not used in the default precedence list. The available options for the `name` field precedence list are: - **fqdn**: the first discovered fully qualified domain name for the computer - **custom_name**: the custom name set for the computer in Automox - **name**: the hostname of the computer If none of the fields specified have a value or the value for this list is invalid, the **name** is used as a default. The precedence list value is stored in the `x_aut12_service_gr.computer_name_precedence` System Property. The guided setup provides a link to the **Configure Computer Name Field Precedence** UI page that is included with the application to assist with setting the value of this property. 1. Add the desired precedence fields to the column on the right. 2. Order the fields from top to bottom. 3. Click the **Update Precedence** button to update the precedence list value. #### Review the Invalid Serial Numbers Table (Optional) ServiceNow provides an Invalid Serial Numbers table (`dscy_invalid_serial`) that is used by the application during the import process to determine whether a serial number discovered by Automox is invalid. The Serial Number value is checked against the Invalid Serial Numbers table. When one of the rules specified in this table matches a serial number for a computer, it is marked as invalid. Marking the serial number as invalid ensures that it will not be used for lookup in the IRE during the import process, which prevents the creation of invalid serial numbers and prevents incorrect correlation of multiple devices that share this serial number value. Examples of invalid serial numbers are the `0` and `Unknown` values. The Automox agent can set these values if it was unable to discover the serial number for a computer. As such, it is important to include these values in the Invalid Serial Numbers table, along with other known common values within your environment. ServiceNow includes a record for the `Unknown` value, and the application includes an additional record for the `0` value. However, it can still be important to review a sample set of the computers in your environment within the Automox console to identify additional rules that should be added to this table. 1. Navigate to the **Devices** menu in the Automox console. 2. Review the Device Details page for a selection of devices, taking note of any serial number values that are invalid. 3. Navigate to the Invalid Serial Numbers table in ServiceNow using the **Configure** button for this step in the Guided Setup. 4. Add a new record to the table by clicking the **New** button. 5. Select the matching rule and enter the value for the invalid serial number. 6. Click **Submit**. 7. Repeat steps four through six if you have additional invalid serial number values to add. The application uses the [Cleanse Serial Number](https://docs.servicenow.com/bundle/rome-servicenow-platform/page/product/configuration-management/concept/integration-commons-for-cmdb.html#d2727903e1159) transform that is included with the Integration Commons for CMDB plugin to check the imported values against this table. #### Assign the Automox Device User Role (Optional) By default, only users with the **administrator** role have access to Automox Device details in the Automox Device table and CI related lists. The application includes the `x_aut12_service_gr.automox_device_user` role that provides read-only access to the Automox Devices table. This role can be added to an existing role, for instance, the `cmdb_read` role, to grant all users with that role access to the table. 1. Search for the role to which you would like to add the `x_aut12_service_gr.automox_device_user` role. 2. Select the role and click **Edit...** in the **Contains Roles** related list. 3. Select the `x_aut12_service_gr.automox_device_user` role and save the form. 4. Mark this step as complete. If you do not want to provide access to Automox Device details now, you can always come back to this step. ### Configure the CMDB Mappings (Optional) **Caution:** This is an advanced step. Automox recommends starting with the default mappings and reviewing the results before modifying the defaults. The **Configure the CMDB Mappings** group in the guided setup is an optional step group for installing the IntegrationHub ETL application and reviewing/modifying the default CMDB mappings. Additional information on the IntegrationHub ETL application is available here: [Product Documentation ServiceNow](https://docs.servicenow.com/bundle/rome-servicenow-platform/page/product/configuration-management/concept/integrationhub-etl.html) **Note:** If you would like to use the default mappings, you can skip these steps. #### Add IntegrationHub ETL Application Entitlements This step links to the ServiceNow store to add instance entitlements for the IntegrationHub ETL application. The ETL application provides a guided experience for viewing, modifying, and testing the Robust Transform Maps included with the Service Graph Connector for Automox. After adding the application entitlements, mark this step as complete. #### Install the IntegrationHub ETL Application Click the **Configure** button for this step to navigate to the application list with a filter for `IntegrationHub ETL`. 1. Install the IntegrationHub ETL application. 2. Mark this step as complete. #### Review or Modify the Automox Devices CMDB Mappings This step navigates to the CMDB Integration Studio module that the IntegrationHub ETL application provides. The Integration Studio provides an interface for viewing, modifying, and testing the default mappings for the **SG-Automox Devices** data source. It has a similar flow to the guided setup, with later steps locked pending completion of dependent steps. 1. Click the **Provide Basic Information for the ETL Transform Map** step and mark it as complete. - This step runs an import for testing the included mappings. 2. Mark the **Preview and Prepare Data** step as completed. - The transformations in this step are adjustable; however, the usage of these transformations in the **Select CMDB Classes to Map Source Data** should first be reviewed. 3. Click the **Select CMDB Classes to Map Source Data** step to view the classes mapped by the application. Click an individual CMDB class to view the field mappings for this class. If the import in step 1 was successful, you should see example data on the right side of the page when viewing the mappings for a specific class. - Complete this step after reviewing/editing the mappings. 4. Review the relationships created in the **Add Relationships** step and mark the step as complete. 5. Finally, click the **Test and Rollback Integration Results** and then **Run Integration** to test the mappings and view the CMDB import results. - These changes can be rolled back when marking this step as complete or when clicking the back button on the page. **Note:** Do not configure the import schedule via the IntegrationHub ETL as the application includes a default that you should use (or copy) instead. ### Configure the Import Schedule The final guided step group links to the default import schedule that imports Automox devices through the **SG-Automox Devices** data source. This schedule runs daily upon activation and provides pre-checks to ensure that two import jobs do not run simultaneously. #### Configure Scheduled Jobs The **Configure Scheduled Jobs** guided setup step links to the default import schedule provided by the application. This file is a part of the application scope, so it is necessary to switch to the application scope to edit it. Copying the schedule provides the default configuration in a new import job while retaining the original default record for later use or reference. Start by clicking the **Configure** button for the step. #### Copying the Included Schedule To copy the included import schedule, right-click the form head and select **Insert**. The insert action creates a copy of the import schedule in the current scope. ServiceNow will automatically navigate back to the guided setup page. Follow the steps below to find and activate the new import schedule. 1. Navigate to the Scheduled Data Import list by entering `scheduled_data_import.list` into the filter navigator. 2. Search for the new record. - A filter on the Application scope and name can help if there are many records. 3. Click the record - Modify the schedule if desired. Daily import is recommended. - Clear the **Run As** field. - Click **Active** to activate the schedule. - Click **Update**. #### Modifying the Included Schedule To modify the included import schedule, follow the steps below. 1. Click the link in the message at the top of the form that states, **This record is in the Service Graph Connector for Automox application, but Global is the current application. To edit this record click here**. 2. Modify the schedule if desired. Daily import is recommended. 3. Ensure that the **Run As** field is blank. 4. Click **Active** to activate the schedule. 5. Click **Update**. ### Application Modules The Service Graph Connector for Automox application menu provides application modules for reviewing the state of the integration and configuring it outside of the Guided Setup. - Setup - The Guided Setup for the Application - Integration Dashboard - A dashboard for reviewing the results of CMDB Application executions - Data Sources - A list of data sources included with the application - Import Schedules - A list of import schedules that use the included Data Sources - Automox Devices - A list view of the Automox Device (`x_aut12_service_gr_automox_device`) table - Support - Contains support details for the application - Configuration - Menu section containing application configuration related modules - Configuration → Connections - A list of HTTP(S) Connection (`http_connection`) records associated with the included `x_aut12_service_gr.SG_Automox_Conn_Cred_Alias` Connection and Credential Alias - Configuration → Get Connection Organizations - A UI page that allows for updating of the organizations associated with a connection - Configuration → Configuration Computer Name Field Precedence - A UI page to aid with setting the precedence list of values to use for the `name` field on imported computer CIs - Configuration → Properties - A filtered view of the `sys_properties` table displaying System Properties included with the application #### Setup Setup is the guided setup module for the application. Review the [Setup](#) section of this documentation for more information. #### Integration Dashboard The Integration Dashboard links to the CMDB Integration Dashboard included with the Integration Commons for CMDB application on which the Service Graph Connector for Automox depends. If you have other Service Graph Connectors installed, this module links to the same dashboard as those. ![](../../Resources/Images/sg-integration-dashboard.png) #### Data Sources This module is a list view of data sources (`sys_data_source`) included with the application. Each data source performs a specific data import for the application. Included data sources: - SG-Automox Devices - Imports Automox device details and patching metrics into the CMDB #### Import Schedules A list view of the Import Schedules (`scheduled_data_import`) associated with the included data sources, including the default import schedule for reference and copying. Import schedules: - SG-Automox - Default - Executes the **SG-Automox Devices** data source - Future releases of the application may add data sources. In that event, this default import schedule may receive updates to execute all included data sources sequentially. #### Automox Devices This module is a list view of all Automox devices imported by the **SG-Automox Devices** data source. The default form includes sections that separate summary details for the device from more specific host and patching-related information. Relationships to `cmdb_ci_hardware` derived CIs are displayed. Finally, the **Connection** field references the Connection record used to import the device. To view the data in this table, a user must have the `x_aut12_service_gr.automox_device_user` role assigned. ![](../../Resources/Images/sg-ax-device-import.png) #### Support The Support module provides a link to the Automox Support website. **Note:** You must have an administrator ServiceNow role to configure the Service Graph Connector for Automox. #### Configuration The configuration section of the application menu includes modules for the configurable components of the application. These are configurable using the Setup module. #### Connections A list view of the HTTP(S) Connections (`http_connection`) that are configured to use the included `x_aut12_service_gr.SG_Automox_Conn_Cred_Alias` Connection and Credential Alias. Multiple connections are supported. When multiple **active** connections exist, the data source will perform an import for each. The data source ignores inactive records. To save steps when setting up a new connection, use the **Create New Connection & Credential** related link. The link is available through the **Configure the API Key** step in the Guided Setup or you can search for **Connection & Credential Aliases** in the filter navigator and click **SG-Automox_Conn_Cred_Alias.** ![](../../Resources/Images/sg-create-connection.png) **Note:** While multiple connections are supported, most use cases require only one. #### Get Connection Organizations A UI page that allows for configuration of the Automox organizations that are associated with a connection. Connections do not require organization associations; however, accounts with more than one organization do require that organizations be set to import devices from multiple organizations. Connections without the Organization IDs field set only import defaults from the default organization for the API key of the connection. The page also provides connection validation. For instance, if the Automox API Key set for the connection is not valid, an error message appears. Valid connections return a list of organizations from which to select. The organization list retrieval process retains prior organization selections. To use the page, first select a connection via the reference selector. The application then attempts to retrieve the list of organizations for the connection. The form displays any error messages received during the organization retrieval process. Each data source loops through the organizations associated with a connection, running import for the data in each organization. ![](../../Resources/Images/sg-get-orgids.png) #### Configure Computer Name Field Precedence This is a UI page that assists with configuration of the `x_aut12_service_gr.computer_name_precedence` System Property. The current value for the property is loaded into the selection bucket on the right side and available, but unselected options are shown on the left. Moving a value from left to right will add it to the list. The order of precedence is from top to bottom. Use the up and down arrow buttons to change the order of the selected fields. Click the **Update Precedence** button to update the value of the System Property. Future imports use this new precedence. ![](../../Resources/Images/sg-automox-computer-name-field-precedence-form.png) #### Properties A filtered view of the `sys_properties` table displaying a list of the System Properties included with the application. The list of included System Properties is: - `x_aut12_service_gr.computer_name_precedence`: a | delimited list of fields to select from when setting the name value for a CI to import. If this property contains an invalid value, `name` is the default value. These values are supported: - `fqdn`: the first discovered fully qualified domain name for the computer - `custom_name`: the custom name set for the computer in Automox - `name`: the hostname of the computer - `x_aut_12_service_gr.automox_support_url`: the link to the Automox Support site used within the UI pages and scripts included with the application - `x_aut_12_service_gr.automox_status_url`: the link to the Automox Status page used within the UI pages and scripts included with the application ## Importing Automox Devices You are ready to import Automox devices after finishing the [Setup](#). For scheduled import, Automox recommends importing on a daily schedule. For testing after installation, you can manually execute the import schedule created or updated during the guided setup. ### Execute the Schedule To import Automox devices, navigate to a schedule configured for the **SG-Automox Devices** data source. The [Import Schedules](#) module provides a list of all import schedules associated with the included data sources. On the import schedule form, click the **Execute Now** button. This action creates a new import set, runs the ETL transformations on the imported data, and inserts the transformed records into the CMDB. The [Identification and Reconciliation Engine (IRE)](https://docs.servicenow.com/bundle/rome-servicenow-platform/page/product/configuration-management/concept/ire.html) handles identification of existing records during the import process, updating records that matching the import set data if found. ### CMDB Lookups The [Robust Import Set Transformers (RTE)](https://docs.servicenow.com/bundle/rome-platform-administration/page/administer/import-sets/concept/robust-import-set-transformers.html) for **SG-Automox Devices** data source includes multiple lookup criteria passed to the [Identification and Reconciliation Engine (IRE)](https://docs.servicenow.com/bundle/rome-servicenow-platform/page/product/configuration-management/concept/ire.html). These lookups determine whether the data associated with a particular Automox device is new to the CMDB or whether it corresponds with an existing record. The default CMDB mappings use the following lookups: #### Hardware - Fields: - Name - Use: - All `cmdb_ci_hardware` derived class (computers) - The first FQDN for the device is used if it was discovered by the Automox agent. Otherwise the hostname for the device is used. #### Network Adapter - Fields: - MAC Address - Name - Name is set to the device name of the network adapter, e.g `Ethernet 1` or `en0` - Use: - All `cmdb_ci_hardware` derived classes (computers) #### Serial Number - Fields: - Serial Number - Serial Number Type - Use: - All `cmdb_ci_hardware` derived classes (computers) #### IP Address - Fields: - Name - Type #### Automox Device - Fields: - ID - Organization ID - Use: - Automox Device class ### Reviewing Results #### Integration Dashboard The primary way to review results of Automox device imports is via the included [Integration Dashboard](https://github.com/PatchSimple/servicenow-service-graph-connector/blob/main/README.md####Integration-Dashboard) module. For more details on this dashboard, review ServiceNow's documentation for the dashboard: - [ServiceNow Product documentation: CMDB Integrations Dashboard](https://docs.servicenow.com/bundle/rome-servicenow-platform/page/product/configuration-management/concept/integration-commons-for-cmdb.html#integration-commons-for-cmdb__section_fxg_lh4_blb) The dashboard provides high-level statistics on CMDB integration executions across your entire ServiceNow instance. To filter by the Service Graph Connector for Automox, select it from the **CMDB Applications** filter on the right side of the dashboard. You can view import performance, CI classes updated, errors that occurred during import executions, and more. Click any of the statistics on the dashboard to navigate to the source table for the data, allowing you to learn more about the specifics of a particular import. #### Computers Table To view computers that have been created or updated by the Service Graph Connector for Automox, you can filter the list view of the Computers (`cmdb_ci_computers`) table by the SG-Automox Discovery Source. 1. Navigate to the Computers table list view by typing `cmdb_ci_computers.list` into the filter navigator and pressing enter. - You can also search for **Computers** and select the **Configuration > Base Items > Computers** module. 2. Click the filter icon 3. Configure the filter as follows: - Field: `Discovery Source` - Condition: `is` - Value: `SG-Automox` 4. Click `Run` The filter updates the list to only display devices that have a discovery source of **SG-Automox**. The application installation process creates this discovery source using a Fix Script. ![](../../Resources/Images/sg-ax-results-filter.png) Click on a record to display the details for the computer, including the CIs related to the computer, such as the Network Adapter, IP Addresses, Serial Numbers, and the Automox Device. ![](../../Resources/Images/sg-record-details.png) ## Troubleshooting The ServiceNow system logs are helpful in many application troubleshooting situations. To access the system logs, search for **System Logs** in the filter navigator and select the **System Log > All** module. To filter for logs specific to the Service Graph Connector for Automox, configure a filter with the **Application** set to **Service Graph Connector for Automox.** **Caution:** In some scenarios, relevant log messages emit without an application association. As such, it is helpful to search around a particular log message of interest without the **Application** filter applied. If you find many logs to search through, adding a filter on the log level is necessary. For example, select log messages where the log level is **Warning** or **Error**. ### Installation Most errors related to the installation of the application are due to dependencies for the application not being satisfied. If the application fails to install, the best course of action is to review the [Installation](#Installa) documentation section. Additionally, investigate the ServiceNow system logs for errors around the time of application installation. ### Configuration This section describes errors related to the configuration of the application. #### Connections Invalid Automox API Key An import fails to run if the Automox API key is invalid. The Automox API key is invalid if you see the following error in the system log: Error executing script : org.mozilla.javascript.JavaScriptException: received bad status code 403 Method failed: (/api/servers) with code: 403 - Forbidden username/password combo (sys_script_include.27ac118487b2b410490f52883cbb3562.script; line 104) You can verify that the Automox API key is invalid by navigating to the **Service Graph Connector for Automox > Configuration > Connection Organizations** module and selecting the connection in the reference field. If you receive an error message, the Automox API key for the connection needs to be updated. There are three primary reasons that the API key may not be working: 1. The API key does not match a key in the Automox console. 2. A user with access to the `http_connection` table modified the API key value for the connection. 3. The API key expired. Navigate to the following page in the Automox console to copy your API key details or create a new one if the key has expired: - [https://console.automox.com/settings/keys](https://console.automox.com/settings/keys) MID Server Offline If the connection uses a ServiceNow MID Server, but the MID server is not online, imports using that connection fail to execute. Review the **MID Server > Servers** module to troubleshoot the status of the MID server that is unavailable or in an error state. #### CMDB Mappings Automox recommends using the default CMDB mappings. If you would like to provide a recommendation for changes to the mappings, contact [support](mailto:support@automox.com). Alternatively, you can change the included mappings by following the steps in the [Configure the CMDB Mappings](#) section of this documentation. **Caution:** Automox does not support changes made to the default mappings. ### Running This section describes errors related to running the application. #### Import Schedules Will Not Run The default import schedule (and copies of it) include a pre-check condition that prevents execution of an import if there is an active import running by reviewing the status of the **most recent** execution. An error message similar to the following indicates that the pre-check condition is blocking the execution of the import: Most recent SG-Automox execution [CEX0001020] is not complete [transforming], cancelling current scheduled execution. To review all executions, see the 'sn_cmdb_int_util_cmdb_integration_execution' table To review the status of the running execution: 1. Navigate to the **Service Graph Connector for Automox > Integration Dashboard** module 2. Filter by the **Service Graph Connector for Automox** CMDB Application 3. Click the number value for **Total Imports**. - This navigates you to the list view for the CMDB Integration Execution (`sn_cmdb_int_util_cmdb_integration_execution`) table. ![](../../Resources/Images/sg-automox-cmdb-executions-list.png) 4. Click on the most recent record in the list to review the execution details. If the execution does not appear to be running, but the state is still **transforming**, manually change the state to **complete** to allow the import schedule pre-check condition to pass, allowing new imports to run. The form for the individual execution record does not allow for updates. However, updates to the state of an execution record are possible by clicking the state field on the CMDB Integration Execution list view. ### Import #### Multiple Automox Device Associations for a Single CI A single CI can have multiple Automox Devices associated with it. The most common reason for this is that Automox has more than one device with the same name. To resolve this issue, update the device names to fix the name collision. Subsequent imports should associate the device with a new or existing CI with the new name. ## Related Topics - [Automox and ServiceNow](https://www.automox.com/automox-and/servicenow) --- # Analytics Board and Report Scheduling _Section: Product Documentation › Automox Reports • Source: https://docs.automox.com/product/Content/Product%20Documentation/Automox%20Reports/Analytics%20Board%20and%20Report%20Scheduling.htm_ You can receive data from Analytics automatically by creating a schedule to email an entire board or by setting and scheduling alerts for individual KPI-based reports. These features help you track critical trends and metrics without signing in to the console daily. ## Creating an Email Schedule for a Board You can schedule full Analytics boards—including custom views—to be sent by email on a recurring schedule. Scheduled boards are delivered as attachments in the format you select. To set up a recurring email schedule for a board, complete the following steps: 1. In the console, select **Insights → Analytics**. 2. Navigate to the board you want to schedule. 3. At the top right of the board, select **Schedule**. 4. From the drop-down list, select **Create schedule**. 5. In the **Set up schedule** dialog, configure the schedule: - **Schedule name**: Enter a name for the schedule. - **Send every**: Select a frequency: **N minutes**, **Hour**, **Day**, **Week**, or **Month**. - **Time**: Select the delivery time using a 24-hour clock. The default is**09:00**. - **Attachment type**: Choose **PDF**, **XLSX**, or **CSV**. - **Recipients**: Enter one or more email addresses. Use commas to separate them. - **View** (optional): Select a custom saved view to apply filters to the scheduled board. 6. Select **Create** to save the schedule. **Note:** You can send scheduled boards to the email address used at login or to manually entered addresses. ### Managing Board Schedules To modify or delete a board schedule, complete the following steps: 1. At the top right of the board, select **Schedule**. 2. Select **Manage schedules**. 3. Edit or delete existing schedules as needed. ## Creating and Scheduling Alerts for KPI Reports You can create and schedule alerts for individual reports that are based on a KPI. These reports may include numeric values or visual indicators, but alerts are triggered by underlying performance metrics. Alerts can notify recipients when a condition is met, on a regular schedule, or both. To create and configure alerts for KPI-based reports, complete the following steps: 1. In the console, select **Insights → Analytics**. 2. Find the report that you want to create an alert for. 3. At the top of the report, select the **Monitor** icon (bell) or select from the menu. 4. In the alert panel, enter a **Name** for the alert. 5. Configure the alert settings: - **Threshold condition**: Trigger the alert when the KPI meets a specific condition. - Select a comparison operator (for example: equals, greater than, less than). - Enter a **Threshold value**. - Change the time the condition is checked, if needed. - **Schedule**: Send the alert on a recurring basis. - Select a frequency: **Hourly**, **Daily**, **Weekly**, or **Monthly**. - The default time is **09:00**. You can change this. - Don’t send on weekendsis selected by default. You can adjust this setting. - You can also change the time zone (default is UTC). 6. Enter the email addresses of recipients. Use commas to separate addresses. 7. Select **Create Alert**. **Note:** Threshold and schedule options are part of the same alert. The alert sends when either condition is met. ### Managing Alerts To view, edit, or delete alerts, complete the following steps: 1. Open the report where the alert was created. 2. Select the **Monitor** icon. 3. Use the alert panel to manage your alerts. **Reminder:** Alerts are currently limited to the logged-in user. ## Related Topics: - [Analytics](Analytics.htm) - [Automox University: Leveraging Automox Analytics](https://university.automox.com/automox-expert-insights-leveraging-automox-analytics) --- # Analytics _Section: Product Documentation › Automox Reports • Source: https://docs.automox.com/product/Content/Product%20Documentation/Automox%20Reports/Analytics.htm_ You can access reports to track patching progress and identify security gaps. Browse prebuilt reports to analyze your device management data. **Prerequisites**: You must have **Reports: Read** permissions for the organization you want to view analytics reports for. See [Roles and Permissions Management](../Global Access Management/Roles_and_Permissions.htm). ![](../../Resources/Images/analytics-example.png) ## Viewing and Filtering Analytics Reports To view analytics reports, go to **Insights → Analytics** in the console. These reports include data from all organizations that you have permissions to view. From the **Analytics** page, choose the type of reports you want to view from the **Select Board** list. You can currently select from these boards: | Name of board | Description | | --- | --- | | Health and Device Status | These reports offer a deep dive into individual device health and status, providing critical insights into update readiness, patching needs, and potential issues for effective troubleshooting. | | Organization Insights | These reports provide a comprehensive snapshot of your organization, detailing operating system distribution, licensing, and connection status. | | Patch Impact and Performance Reports | This board tells the story around applying patches irrespective of vulnerability, providing actionable reporting around patch activity and predictability on the impact of applying patches within an environment. | | Policy Execution | These reports collectively provide a granular overview of policy execution, success, and failure rates across organizations, alongside a detailed breakdown of policy results. | | Risk and Mitigation Reports | This board tells the story around applying patches respective of vulnerability, providing actionable reporting around patch activity and predictability on the impact of applying patches within an environment. | | Organizational Risk and Patch Trend | This board delivers risk and patch trend data that highlights how a customer's environment is changing over time, how well risk and patches are being addressed and offers more insight into how Automox is helping to remediate and automate tasks. | You can perform the following actions on the different boards: - **Filter:**Filter the available reports - **Download PDF**: Download the data as a PDF - **Present**:Present reports for larger, detailed views - **Schedule**: Create a schedule to send a PDF, XLSX, or CSV by email - **Hover**: Hover over individual reports to view more information **Note**: Automox refreshes the data hourly. **Tip**: If you close the information tiles that initially appear above the reports and would like to access them again, you must **clear your browser data**. ### Filtering Reports You can apply several filters to refine the data shown in analytics reports. The available filters depend on the board you select. ![analytics filters](../../Resources/Images/analytics-filters.png) The following filters are available: - **Date Last 90 Days**: Select a value to filter policy events by. Data beyond 90 days may not be available, even if included in your filter. - **Days Since Last Disconnect**: Select to filter by the number of days a device was last disconnected. The default setting is 3 days. - **Device**: Select one or more devices to filter by. By default, all devices are selected. - **Group**: Select one or more groups to filter by. By default, all groups are selected. - **Install Date Last 90 Days**: Select to view analytics based on a rolling install date or a fixed date range. While the date filter allows you to select a wider range, the report will only include up to 90 days of data. Data beyond 90 days from the selected end date may not be available, even if included in your filter. - **Operating System**: Select one or more operating systems to filter by. By default, all operating systems are selected. - **Organization**: Currently, if you are logged into a specific organization, the reports show data for **all** organizations you have permissions to view. Use the **Organization** filter to include or exclude organizations, depending on your permissions and preferences. - **OS Family**: Select one or more operating systems to filter by. The available options are Linux, Mac, and Windows. - **Package Category**: Select from options such as browser, communication, utility, and other. By default, all options are selected. - **Package Name**: Select one or more packages to filter by. By default, all packaged are selected. - **Package Source Type**: Select from first-party or third-party packages. By default, both are selected. - **Policy**: Select one or more policies to filter by. By default, all policies are selected. - **Policy Type**: Select one or more policy types (Patch, Required Software, or Worklet) to filter by. By default, all policy types are selected. - **Severity:**Use the **Severity** filter to include or exclude specific CVSS severity levels. **Note**: For more information, see [Understanding CVE Scoring and Severity Data](#Understa). - **Target MTTP**: You can change this value. Use this filter to select a target **Mean Time to Patch (MTTP)** value from **1**through**30**. - **Target MTTR**: You can change this value. Use this filter to select a target **Mean Time to Remediate (MTTR)** value from**1**through**30**. See the [Glossary](#Glossary) section for details.) #### Additional Filters For the **Patch and Impact Performance** board, you can select from additional filters for groups of reports based on these categories. ![](../../Resources/Images/patch-impact-perf-tabs.png) - **Overview** - **Patching Performance** - **Patching Drilldown** ### Available Actions In addition to the **Download PDF** button available from the board, you can interact with individual reports using the following actions: ![](../../Resources/Images/report-actions.png) - **Explore**: Provides access to additional filters and customization options to refine the data further - **Show Underlying Data**: Displays the detailed data that supports the report’s metrics - **Download**: Exports the report in your preferred format: **CSV**, **XLSX**, or**PNG** - **Present**: Opens the report in a larger, more detailed view for closer inspection - **Alerts:**You can select **Create alert** (bell icon) and **Manage alerts**. For more information about alerts, see [Analytics Board and Report Scheduling](Analytics Board and Report Scheduling.htm). ### Managing Customized Views You can save any filter modifications you make to the analytics board in a customized board view. You can add, delete, and manage custom views for yourself. 1. When you modify a filter and apply the change, the **Save view** option appears along with the filters. You can apply multiple filters to the same view or create individual custom views. 2. Click **Save view** and enter a custom name that reflects the new board view. 3. To switch back to the default view, select **Reset Liveboard** from the drop-down menu. 4. Select **Manage views** to edit custom view names or delete a custom board view. ![](../../Resources/Images/analytics-custom-view.png) **Note**: The option to share views with other users or organizations is currently disabled. They can create their own views and save them individually. ## Patch Impact and Performance Reports The reports associated with patch impact and performance are listed here. They are grouped in three categories. Click the areas for details about each report. You can find detailed descriptions for each in [Report Calculation Methodology - Security and Patch Performance](#Report2), select**Patch Impact and Performance Reports**. 1. **[Overview tab](#Overview)** - Mean Time to Patch (MTTP) - MTTP Achievement - Patch Policy Success Rate - Patches Applied by Month - MTTP calculation including outstanding patch instances - Adjusted MTTP - Devices in Scope for Active Patch Policies - Packages Up to Date - MTTP Trend by Device Count - Policies with Highest Execution Count - Applied Packages by Patch Instance Count - Applied Packages by Device Count - Patching Progress by Device Count - Outstanding Packages by Device Count - Outstanding Packages by Patch Instance 2. [Patching Performance](#Patching) - Overall Policy Success - Patch Policy Execution History - Applied Patch Instances by OS Family - Patching Progress by Outstanding Patch Instance Count - Patch Policy Schedule - Patch Policy Executions 3. [Patching Drilldown](#Patching2) - Applied Package History - Recently Executed Patching Policies - Patching Progress by Outstanding Device Count - Drilldown - Outstanding Packages by Device - Outstanding Packages by Patch Instance ## Risk and Mitigation Reports The reports associated with risk and mitigation are listed here. You can find detailed descriptions for each in [Report Calculation Methodology - Security and Patch Performance](#Report2), select **Risk and Mitigation**. - Mean Time to Remediate in Days (MTTR) - MTTR Account Achievement - Comparison against Target MTTR - KEV Vulnerability Instances Remediated - Vulnerability Instances Remediated - Vulnerability Instances Remediated - Remediation Trend by Vulnerability Instance - MTTR Trend vs Number of Devices In Scope - Projected MTTR - Active Policies By Projected MTTR - Top Active CVEs By Exposure In Days - Vulnerabilities Remediated by Severity - MTTR Target Breach by Exposure in Days - Outstanding Vulnerability Instances ## ## Health and Device Status The reports associated with health and device status are listed here. You can find detailed descriptions for each in [Report Calculation Methodology - Operational Insights](#Report), select **Health and Device Status**. - Patch Policies Successful by Month - Patch Policies Successful - Devices Requiring Restart - Not Compatible Device Count - Last Scan Failed by Device Count - Outstanding Patch Instances - Outstanding Patch Instances - Patch Instances Requiring Restart - Outstanding Critical Patch Instances - Outstanding Patch Instances by CVSS Severity - Device Health by Group - Devices Not Compatible - Outstanding Critical Patches by Organization and Group - Devices Requiring Restart by Organization and Group - Last Scan Failed by Organization and Group ## Organization Insights The reports associated with organization insights are listed here. You can find detailed descriptions for each in [Report Calculation Methodology - Operational Insights](#Report), select **Organization Insights**. - Subscription - Device Count - Max Device Count - Devices Deployed - Group Count - Recently Added Devices - Deployment Trend by Day - Environment by OS - Connection Status by Device Count - OS Distribution - Disconnected Devices 1–30 Days - Disconnected Devices 31–60 Days - Disconnected Devices 61–90 Days - Disconnected Devices Greater than 90 Days - Disconnected Devices Breakdown ## Policy Execution The reports associated with health and device status are listed here. You can find detailed descriptions for each in [Report Calculation Methodology - Operational Insights](#Report), select **Policy Execution.** - Policy Success Rate - Policy Executions by Month - Unique Policy Executions - Policy Count - Active Policy Count - Unscheduled Worklets with Associated Groups - Policy Execution Status by Date - Policy Success Rate by Type - Policy Count by Type - Policy Successes and Failures by Type - Scheduled Policies by Type ## Organizational Risk and Patch Trend The reports associated with Organizational Risk and Patch Trend are listed here. You can find detailed descriptions for each in [Report Calculation Methodology – Organizational Risk and Patch Trend](#Report4). - Risk Reduction Trend - Net Patch Instance Delta - KEV Reduction Trend - Average Days Risk Exposure by Month - Net Risk Delta - Risk Score by CVSS Severity - Remediation Vulnerability Instances by CVSS Severity - Patch Instance Trend by Day - Average Exposure Days by CVSS Severity - Critical Vulnerability Instance Trend by Device Count **Note**: Automox introduces additional report types over time. As new reports become available, they appear on the Analytics page without requiring any configuration changes. ## Understanding CVE Scoring and Severity Data Automox Analytics reports include CVE and CVSS Severity information to help you interpret vulnerabilities more effectively. ### CVSS Score The **CVSS Score** is a numerical value from **0 to 10** that represents a qualitative measure of severity. Automox Analytics displays the **most current score available** in this priority order: - **CVSSv4** - **CVSSv3** - **CVSSv2** If no CVSS score is available, the system displays **NULL**. ### CVSS Severity The CVSS Severity is a text (string) representation of the numerical CVSS range that reflects the most recent severity available. If no severity is available, the value is **NONE**. **Note**: For more information about CVSS and severity ratings, visit the [National Vulnerability Database.](https://nvd.nist.gov/vuln-metrics/cvss) ## Report Calculation Methodology To support accurate interpretation of analytics data, this section provides the calculation methodology for each report. Reports are grouped into categories based on their focus areas: - [Report Calculation Methodology - Security and Patch Performance](#Report2): Includes the Patch Impact and Performance and Risk and Mitigation boards. These boards focus on patching activity and effectiveness, with or without a vulnerability context. - [Report Calculation Methodology - Operational Insights](#Report3)\: Includes the Health and Device Status, Organization Insights, and Policy Execution boards. These boards provide operational visibility into devices, policies, and organization-level metrics. - [Report Calculation Methodology – Organizational Risk and Patch Trend:](#Report4) This board focuses on tracking changes in risk exposure, vulnerability remediation, and patch activity over time. Automox adds additional boards over time, and each includes its own methodology section as applicable. ### Report Calculation Methodology - Security and Patch Performance This section explains how analytics calculates metrics for each report using defined formulas and associated variables. - Patch Impact and Performance - Risk and Mitigation This describes the calculations for the Patch Impact and Performance reports. You can select reports from three tabs: [Overview](#Overview), [Patching Performance](#Patching), and [Patching Drilldown](#Patching2). This list provides the calculations used for the patch impact and performance reports. ### Overview #### Mean Time to Patch (MTTP) - **Formula** MTTP: `sum ( Day Diff ) / Package Count` - **Variables**: MTTP, Install Date Monthly - **Description**: Displays the average number of days it takes to apply a patch to a device, calculated from the package creation timestamp (when the patch was first available) to the install timestamp (when the patch was successfully applied on a device). This metric currently measures the patch time per patch instance. This answer also compares data to the previous month's data. #### MTTP Achievement - **Variables**: MTTP Achievement, Install Date Monthly - **Description**: Compares the current MTTP to the **Target MTTP Parameter** defined by the end user and displays a percentage rate of achievement. This answer also compares data to the previous month's data. #### Overall Policy Success Rate - **Formula** [Success Rate](#Success): safe_divide ( Policies Succeeded, Total Policy Executions) - **Variables**: Success Rate, Event Time Monthly, Policy Type = Patch - **Description**: Displays the percentage of patch policies that executed successfully (exit code 0) in the environment based on the selected time interval. #### Patches Applied By Month - **Variables**: Package Count, Install Date Monthly - **Description**: Displays the number of patch instances successfully applied each month within the selected timeframe. This report compares the current month's performance against the previous month to highlight trends and progress over time #### Adjusted MTTP - **Variables**: Adjusted MTTP, Device Package Count, Diff in Days - **Description**: Shows MTTP including outstanding patch instances. Projects MTTP if all outstanding patches were applied today. #### Devices in Scope for Active Patch Policies - **Formula** [In Scope Policy Devices](#Scope): safe_divide ( Total Active Patch Policy Devices, Total Devices ) - **Variables**: In Scope Policy Devices - **Description**: Displays the number of devices that are currently in scope based on active patch policies, considering any applied device filtering. This helps to distinguish between the total device count and those actively managed by patch policies. #### Packages Up-to-Date - **Formula** [Fully Patched Percentage](#Fully): `Fully Patched Package Count / Total Package Count` - **Variables**: Fully Patched Percentage - **Description**: Shows the percentage of installed software packages that are fully patched across the environment. #### MTTP Trend by Device Count - **Variables**: MTTP, count Server ID, Install Date Weekly - **Description**: Displays a weekly trend of MTTP and devices in scope. #### Policies with Highest Execution Count - **Variables**: Total Policy Executions, Policy Name, Event Time Monthly - **Description**: Lists patch policies ranked by the number of executions within the selected time interval. This helps identify which policies are most active, either due to a broad device scope or a more aggressive scheduling strategy. #### Applied Packages by Patch Instance Count - **Variables**: Package Name, Package Count - **Description**: Shows how often each patch was applied within the selected time interval. #### Applied Packages by Device Count - **Variables**: Package Name, count Server ID - **Description**: Shows the number of unique devices that have received a specific package within the selected time interval. #### Patching Progress by Device Count - **Variables**: Package Name, Installed Device Count, Outstanding Device Count - **Description**: Sorted by Total Device Count #### Outstanding Packages by Device Count - **Variables**: Server Name, Package Count, Installed = False - **Description**: Displays devices with the highest number of outstanding patches. ### Patching Performance #### Patch Policy Success - **Variables**: count Policy ID, Status Name - **Description**: Displays the success and failure rate of ALL policies (Patch, Worklet, and Required Software) in the environment based on the filtered time interval. #### Patch Policy Execution History - **Variables**: count Policy Event ID, Status Name, Policy Type = Patch, Event Time Weekly - **Description**: Tracks successful and failed patch policy executions over the selected time interval. #### Applied Patch Instances by OS Family - **Variables**: Package Count, OS Family, Install Date Weekly - **Description**: Displays the count of applied patch instances by operating system family. #### Patching Progress by Outstanding Device Count - **Variables**: Package Name, Installed Device Count, Outstanding Device Count - **Description**: Displays the number of devices running the latest version of a package in comparison to those still pending the latest patch. #### Patch Policy Schedule - **Variables**: Organization Name, Hour 24, Policy ID Count by Hour - **Description**: Displays the policy schedule based on the hour of day and broken out by organization. This report provides insights into how policies are scheduled and helps determine if adjustments are needed to optimize execution timing. #### Patch Policy Executions - **Variables**: count Policy ID, Organization Name, Policy Event Hour hour of day, Policy type = Patch - **Description**: Displays when patch policies have executed, broken down by the hour of day. This report shows the distribution of policy execution times and can help determine if policies are running as scheduled or if adjustments are necessary. ### Patching Drilldown #### Applied Package History - **Variables**: Package Name, Server Name (Device), Install Date detailed, Is Managed = True - **Description**: Lists packages that have successfully applied over the time interval. **Note**: This only includes devices that have successfully completed the **GetSoftware scan** to ensure accuracy in reporting package status. #### Recently Executed Patching Policies - **Variables**: Policy Name, Server Name (Device), Status, Policy Name - **Description**: Lists patching policies that have most recently been executed. #### Patching Progress by Outstanding Device Count - **Variables**: Package Name, Installed Device Count, Outstanding Device Count - **Description**: Lists the number of devices running the latest version of a package in comparison to those still pending the latest patch. #### Outstanding Packages by Device - **Variables**: Package Name, Server Name, Version, Package Count, Installed = False - **Description**: Lists devices with missing patches to highlight patching gaps. #### Outstanding Packages by Patch Instance - **Variables**: Package Name, Version, count Server ID, Installed = False - **Description**: Lists patch instances pending installation, showing the version pending per device. Return to [Report Calculation Methodology](#Report). ### Risk and Mitigation This describes the calculations for **Risk and Mitigation** reports. #### Mean Time to Remediate in Days (MTTR) - **Formula** [MTTR](#MTTR2): `SUM ( ``[Day Diff](#Day) ``) / ``[Remediation Count](#Remediat)` - **Variables**: Average Day Diff, Install Date - **Description**: Displays the average number of days it takes to remediate a vulnerability instance using **Created At** (Release date of the package) and **Install Timestamp** (The timestamp of the scan after package was installed). This answer also compares data to the previous month's data. #### MTTR Account Achievement Comparison to Target MTTR - **Formula** [MTTR Achievement](#MTTR): `Target MTTR / ``[MTTR](#MTTR2)` - **Variables**: MTTR Achievement, Install Date - **Description**: Compares the current MTTR to the **Target MTTR Parameter** defined by end user and displays a percentage rate of achievement. This answer also compares data to the previous month's data. #### KEV Vulnerability Instances Remediated (KEV) Known Exploitable Vulnerabilities - **Variables**: Unique Count of Vulnerability Instances, Known Exploitable Vulnerabilities, Install Date - **Description**: Displays the number of vulnerability instances with active exploits in the wild that have been remediated this month. This answer also compares data to the previous month's data. #### Vulnerability Instances Remediated - **Variables**: Unique Count CVE ID, Install Date - **Description**: Displays the number of vulnerability instances that have been installed during the install date filter. This also provides comparative analytics for current vs previous month's data. #### Remediation Trend by Vulnerability Instance - **Variables**: Unique Count Vulnerability Instance, Install Date, CVSS Severity - **Description**: Displays a weekly trend of remediated vulnerability instances by severity. #### MTTR Trend vs Number of Devices In Scope - **Variables**: Average Day Diff, Install Date, Unique Count of Devices - **Description**: Displays a weekly trend of MTTR and devices in scope. #### Projected MTTR Anticipated MTTR based on active policy schedule pattern - **Variables**: Average Days Between Active Policy Schedules - **Description**: Provides the projected MTTR based on active patch policy schedules. #### Active Policies By Projected MTTR - **Variables**: Policy Name, Average Days Between Schedules - **Description**: Provides a ranked list of patch policies with the largest gap in schedules. #### Top Active CVEs By Exposure In Days - **Formula** [Days Exposed](#Days): `CURRENT_DATE - Package Version Created At` - **Variables**: Max Days Exposed, CVE ID, CVSS Severity - **Description**: Displays the top 10 CVEs based on active exposure in days. Conditional logic for the colors ranges from Yellow to Red. Any CVE with a maximum exposure in days greater than 90 days will be red. #### Vulnerabilities Remediated by Severity - **Variables**: Unique Count Vulnerability Instances, Severity - **Description**: Displays a total count of installed vulnerability instances based on the **Install Date** filter. #### MTTR Target Breach by Exposure in Days - **Variables**: Package Display Name, Severity, Max Exposure in Days > Target MTTR - **Description**: Provides the top packages in breach of the **MTTR Target** sorted by exposure in days. Conditional color scheming is based on **CVSS Severity**. #### Outstanding Vulnerability Instances - **Variables**: Unique Count of Vulnerability Instances, CVSS Severity - **Description**: Displays the total number of vulnerability instances that are outstanding in the environment over all time. Return to [Report Calculation Methodology](#Report). ### Report Calculation Methodology - Operational Insights This section explains how analytics calculates metrics for each report using defined formulas and associated variables. - Health and Device Status - Organization Insights - Policy Execution ### Health and Device Status This describes the calculations for **Health and Device Status** reports. #### Patch Policies Successful by Month - **Variables**: Policy Event ID, Policy Type, Event Time, Success - **Description**: Displays a date trend chart showing the number of successful patch policy executions over the previous month. #### Patch Policies Successful - **Variables**: Policy Event ID, Policy Type, Success - **Description**: Displays the number of successful patch policy executions over the selected date filter. #### Devices Requiring Restart - **Variables**: Deleted, Needs Reboot, Server ID - **Description**: Displays the number of devices in the organization that need to be restarted. #### Average Package Exposure by CVSS Severity and OS - **Variables**: Average Package Exposure, CVSS Severity, OS Family - **Description**: Provides outstanding patch instances by CVSS severity and OS Family #### Not Compatible Device Count - **Variables**: Server ID, Compatibility - **Description**: Displays the number of deployed devices that are not compatible with Automox #### Last Scan Failed by Device Count - **Variables**: Server ID, Last Scan Failed - **Description**: Displays the number of deployed devices that failed their last scan. #### Outstanding Patch Instances - Packages In-Scope with Active Policies - **Variables**: Package ID, Installed, Policy Scope - **Description**: Displays the number of patches that are yet to be installed and are associated with a policy. #### Outstanding Patch Instances - Includes Out-of-Scope Packages - **Variables**: Package ID, Installed - **Description**: Displays the number of patches that are yet to be installed regardless of association with a policy. #### Patch Instances Requiring Restart - **Variables**: Pending Patches, Reboot Required - **Description**: Displays the number of patches that are available, regardless of policy association, and require a restart to be installed. #### Outstanding Critical Patch Instances - **Variables**: Package Version ID, Installed, CVSS Severity - **Description**: Displays the number of patches that are not installed that have a CVSS score of Critical. #### Outstanding Patch Instances by CVSS Severity - **Variables**: Package Version ID, Installed, CVSS Severity - **Description**: Displays a pie chart showing a breakdown of available patches by the CVSS severity, regardless of policy association. #### Device Health by Group - **Variables**: Group Name, Server ID, Device Health - **Description**: Displays a stacked bar graph showing the amount of healthy and unhealthy devices, organized by group. #### Devices Not Compatible - **Variables**: Compatibility, Server ID, Compatibility, Organization Name - **Description**: Displays a heatmap showing the number of deployed devices that are not compatible with Automox, grouped by organization name and incompatibility detail. #### Outstanding Critical Patches by Organization and Group - **Variables**: Package Version ID, Organization Name, Installed, Group Name, CVSS Severity - **Description**: Displays a stacked bar graph showing the number of patches that are not installed, regardless of policy association, grouped by organization name and group name. #### Devices Requiring Restart by Organization and Group - **Variables**: Organization Name, Group Name, Server ID, Needs Reboot - **Description**: Displays a stacked bar graph showing the number of devices that require a restart, grouped by organization name and group name. #### Last Scan Failed by Organization and Group - **Variables**: Organization Name, Group Name, Server ID, Last Scan Failed - **Description**: Displays a stacked bar graph showing the number of devices that failed their last scan, grouped by organization name and group name. Return to [Report Calculation Methodology - Operational Insights](#Report3). ### Organization Insights This describes the calculations for **Organization Insights** reports. #### Subscription - **Variables**: Account Sub Systems - **Description**: Displays the maximum number of devices the organization has licenses for. #### Device Count - **Variables**: Server ID, Deleted - **Description**: Displays the current number of active devices in the organization. #### Max Device Count - **Variables**: Device Count, Date Trend - **Description**: Displays the total number of devices added over the previous date filter. #### Devices Deployed - **Variables**: Server Count, Max Sub Systems, Deleted - **Description**: Displays the percentage of non-deleted systems compared against the organization’s license. #### Group Count - **Variables**: Group UUID - **Description**: Displays the number of groups within the organization. #### Recently Added Devices - **Variables**: Server ID, Create Time, Deleted - **Description**: Displays a line graph of the devices created during the selected date filter. #### Deployment Trend by Day - **Variables**: Date Trend daily, Organization Name, Max Device Count, Subscribed Systems - **Description**: Displays a line graph showing deployed devices by day compared against the maximum amount of devices allowed, limited by the date filter. #### Environment by OS - **Variables**: Server ID, OS Family, Deleted - **Description**: Displays a pie chart showing the percentage breakdown of deployed devices by the OS Family (Windows, Mac, Linux). #### Connection Status by Device Count - **Variables**: Server ID, Deleted, Connection Status - **Description**: Displays a bar graph showing the total number of devices that are connected (shown in green) and disconnected (shown in red). #### OS Distribution - **Variables**: OS Family, OS Name, Server ID, Deleted - **Description**: Displays a Sankey chart showing a detailed number of deployed devices by specific operating system name. #### Disconnected Devices 1–30 Days - **Variables**: 1–30 Days, Server ID, Deleted - **Description**: Displays the number of devices that have been disconnected between 1 and 30 days. #### Disconnected Devices 31–60 Days - **Variables**: 31–60 Days, Server ID, Deleted - **Description**: Displays the number of devices that have been disconnected between 31 and 60 days. #### Disconnected Devices 61–90 Days - **Variables**: 61–90 Days, Server ID, Deleted - **Description**: Displays the number of devices that have been disconnected between 61 and 90 days. #### Disconnected Devices Greater than 90 Days - **Variables**: > 90 Days, Server ID, Deleted - **Description**: Displays the number of devices that have been disconnected for more than 90 days. #### Disconnected Devices Breakdown - **Variables**: Server Name, Days Since Last Disconnect, Last Disconnect Time Updated, Server ID, Organization Name, Deleted - **Description**: Displays a table of disconnected devices with details about how long each device has been disconnected, sorted by Days Since Last Disconnect. Return to [Report Calculation Methodology - Operational Insights](#Report3). ### Policy Execution This describes the calculations for **Policy Execution** reports. #### Policy Success Rate - **Variables**: Success Rate, Event Time - **Description**: Displays a graph showing overall policy execution success rate for the selected date filter. #### Policy Executions by Month - **Variables**: Policy Event ID, Event Time - **Description**: Displays a graph showing the total number of policy executions for the selected date filter. #### Unique Policy Executions - **Variables**: Policy ID, Event Time - **Description**: Displays the number of unique policies executed for the selected date filter. #### Policy Count - **Variables**: Policy ID - **Description**: Displays the total number of policies in an organization. #### Active Policy Count - **Variables**: Auto Patch - **Description**: Displays the total number of policies that are active, with Auto Patch set to true. #### Unscheduled Worklets with Associated Groups - **Variables**: Server Group ID, Policy Type, Scheduled - **Description**: Displays the total number of worklet policies associated to groups that do not have a schedule. #### Policy Execution Status by Date - **Variables**: Policy Event ID, Event Time weekly, Success string - **Description**: Displays a stacked area graph showing the number of policy executions by result (success or failure) over time. #### Policy Success Rate by Type - **Variables**: Policy Type, Success Rate - **Description**: Displays a bar graph showing the success rate of policies by policy type. #### Policy Count by Type - **Variables**: Policy ID, Policy Type - **Description**: Displays a pie chart showing the number of policies grouped by policy type. #### Policy Execution Count by Status and Type - **Variables**: Policy Event ID, Policy Type, Event Time, Status Name - **Description**: Displays a stacked bar graph showing the number of policy executions grouped by policy type and result (success or failure), , limited by the date filter. #### Scheduled Policies by Type - **Variables**: Policy ID Count by Hour, Hour 24, Policy Type - **Description**: Displays a stacked bar graph showing the number of scheduled policies by hour of the day and policy type. Return to [Report Calculation Methodology - Operational Insights](#Report3). ### Report Calculation Methodology – Organizational Risk and Patch Trend This section provides the calculation methodology for the Organizational Risk and Patch Trend board. These reports focus on tracking changes in risk exposure, vulnerability remediation, and patch activity over time. #### Risk Reduction Trend - Variables: Vulnerability Instances, Date, CVSS Severity - Description: Displays a KPI chart showing the change in vulnerability instances between the current month and the previous month. #### Net Patch Instance Delta - Variables: Sum of the net change patch instances, Date - Description: Displays a KPI chart showing the sum of all changes for patch instances by comparing the current month to the previous month. #### KEV Reduction Trend - Variables: Max In Kev for time period, Date - Description: Displays a KPI chart showing the change in Known Exploitable Vulnerability (In KEV) instances between the current month and the previous month. #### Average Days Risk Exposure by Month - Variables: Average number of exposure days, Date - Description: Displays KPI chart showing the average number of days vulnerabilities were exposed in the environment, comparing the current month to previous months. #### Net Risk Delta - Variables: Sum of the net change in risk, Date - Description: Displays a KPI chart showing the sum of all changes for risk using CVSS scores comparing the current month to the previous month. #### Risk Score by CVSS Severity - Variables: Risk Score, Date, CVSS Severity - Description: Displays an area chart showing the trend of Risk sliced by CVSS severity. #### Remediation Vulnerability Instances by CVSS Severity - Variables: CVSS Severity, Remediated Vulnerability Instances - Description: Displays a bar chart showing the number of vulnerability instances that were remediated, broken down by CVSS severity using the board’s date filter. #### Patch Instance Trend by Day - Variables: Patch Instance Count, Date - Description: Displays an area chart showing the daily trend of patch instances over time. #### Average Exposure Days by CVSS Severity - Variables: CVSS Severity, Date, Average Days Exposed - Description: Displays a stacked area chart showing the trend of days exposure for vulnerability instances affecting in-scope organizations. #### Critical Vulnerability Instance Trend by Device Count - Variables: Vulnerability Instances, Date, Device Count - Description: Displays an area chart showing the vulnerability instance trend over time along with a device count over time to view the relationship between vulnerability instance counts compared to the device count. ## Strategies for Improving Metrics You can use insights from the reports to take targeted actions that reduce risk and improve your organization's performance against key metrics. This section provides a few examples to illustrate how to interpret report data and act on it. The screenshots in this section highlight how specific reports can uncover actionable trends. Use these examples as guidance for identifying your own areas of improvement. - **Active Policies By Projected MTTR**: This report helps you identify policies with large gaps between scheduled runs. If you notice long intervals for certain policies, consider adjusting their schedules to reduce patching delays. Reducing the time between executions can help you get ahead of vulnerabilities and decrease your overall MTTR. ![](../../Resources/Images/example-active-policies.png) - **Outstanding Vulnerability Instances**: Use this report to determine if there’s a high number of unresolved vulnerabilities—the following example shows those with High or Medium severity. If your environment shows elevated counts for these severities, you may need to refine your policies to target them more aggressively and close the gap on remediations. ![](../../Resources/Images/example-outstanding-vuln.png) - **MTTR Account Achievement**: This report helps you monitor whether your remediation efforts align with the Target MTTR Parameter. If the percentage is low, focus on reducing delays in the patch deployment cycle and consider streamlining approvals or improving device readiness. ![](../../Resources/Images/example-mttr-achieve.png) ## Glossary - **Known Exploitable Vulnerability (KEV)**: A CVE (Common Vulnerabilities and Exposures) that has documented evidence of active exploitation in the wild. These vulnerabilities are typically listed in authoritative sources such as the CISA KEV catalog and represent higher risk due to confirmed use in real-world attacks. - **Key Performance Indicator (KPI)**: The term KPI refers to metrics used to evaluate progress or change over time. Each KPI chart described compares values across time periods or categories to highlight trends in patching and risk reduction - **Vulnerability Instance**: A specific occurrence of a security vulnerability (CVE) on a device or package. Device, Package, Version, and Install Date (historical trend) are attributes that make up this occurrence | Formula | Definition | | --- | --- | | Day Diff | diff_days ( Install Date , Created At ) | | Days Exposed | diff_days ( CURRENT DATE, Created At ) | | Remediation Count | Unique count ( Vulnerability Instance) | | MTTP | sum ( Day Diff ) / Package Count | | MTTP Achievement | Target MTTP / MTTP | | MTTR | sum ( Day Diff ) / Remediation Count | | MTTR Achievement | Target MTTR / MTTR | | Package Count | Count ( Package Version ID ) | | Success Rate | Policies Succeeded / Total Policy Executions | | In Scope Policy Devices | Total Active Patch Policy Devices / Total Devices | | Fully Patched Percentage | Fully Patched Package Count / Total Package Count | ## CVE Legend CVSS scores are mapped to the following severities: | Severity | Severity score range | | --- | --- | | Critical | 9–10 | | High | 7–8.9 | | Medium | 4–6.9 | | Low | 0.1–3.9 | | None | 0.0 | ## Related Topics - [Analytics Board and Report Scheduling](Analytics Board and Report Scheduling.htm) - [Creating Reports](Creating_Reports.htm) - [Policy Results Report](Policy_Results_Report.htm) - [Data Extracts](Data_Extracts.htm) - [Automox Console API: Create a new Data Extract](https://developer.automox.com/openapi/axconsole/operation/createExtract/) --- # Creating Reports _Section: Product Documentation › Automox Reports • Source: https://docs.automox.com/product/Content/Product%20Documentation/Automox%20Reports/Creating_Reports.htm_ You can create reports that provide information about the devices in your organization. The following reports are available from the **Reports** page. To view each type of report, click the corresponding **View**button ## Activity Log The activity log tracks all automated and manual actions taken over a given period of time on the devices in your organization. - Use the filter options to create the desired report. - Click the **Export CSV** button to export this information to a CSV file. - Click the name of the device to view the Device Details page. - Select **Full Logs** for more information. ![](../../Resources/Images/activity-log.png) **Note**: The generated logs represent complete and unfiltered data from your organization. The following filtering and searching options enable you to fine-tune and export the results you want. ## Filtering and Searching in the Activity Log The filter panel to the left of the activity log list includes different types of options to fine-tune your report. You can filter the list of activity logs by date, policy type, policy name, device name, and group. When you select any of the individual filters, the resulting log list automatically updates. You can clear selections individually, or select **Reset Filters** to clear all. ![](../../Resources/Images/activity-log-filter.png) You can hide or show the filter panel, as needed. The filter panel shows by default. | Filter | Description | | --- | --- | | Date Range | Use the Date Range options to find the desired activity log results. The last selection is saved in local storage and becomes the new default. Note: The Automox console retains 90 days of data, which is accessible in increments of 30 days.From the date range options, when you select a Custom report, you are limited to a maximum date range of 31 days.Data is filtered by UTC. Select from the filter options to show log results for Today, Yesterday, Last 7 Days, Last 30 Days, or Custom. Use the calendar options to create a custom search. | | Policies: Policy Type | Click the All Policy Types drop-down list to filter results by Patch, Worklet, or Required Software. | | Policies: Policy Name | Click the All Policies drop-down list to filter results by the name of any policy in your organization. | | Devices | Use the Device Name field to search for a specific device or devices. This search shows all entries that match any of the individual search criteria you set. | | Groups | Use the Groups field to search for specific groups of devices. This search allows you to select multiple groups. | ### Search by log details Use the **search bar** at the top of the Activity Log to find specific details listed in the Log Summary column, such as package names and KB numbers. This helps you quickly find useful log entries. Click Full Logs for complete information about the logged activity. You can also show all details by turning on the **Expand All Log Details** toggle. Each log entry also includes a **View Additional Logs** link. Clicking this opens the **Device Logs** on the **Device Details** page, where you can see logs from recent scans of the device. The types of data shown in these logs are described in [Device Details](../Device Management/Device_Details.htm). **Note**: This search bar does not search for devices or policies. ![](../../Resources/Images/activity-log-searchlog.png) By entering a string, the list populates with matching entries. You can use multiple strings to narrow your search results. ### Sorting search results You can sort the list of results by clicking the arrow at the column heading. This type of sort is available for Device Name, Policy Name, Group, and Event Time columns. **Note**: The search parameters you select are now stored in the page URL. The back button in your browser functions as expected and filter searches can now be bookmarked and shared. ## Overview Report The overview report provides a summary of the state of devices in your organization. This includes the device overview, history of patches applied, and patches by group. You can export this report to a PDF. ### Navigating the Overview Report ![](../../Resources/Images/overview-report.png) - Hover over points on the charts to reveal details. - Use the drop-down menu to change the time span of the history. - Click the severity level legend to turn details on and off. - Click highlighted text to jump to a filtered list of devices. - Click **Export PDF** to download a PDF of this report. #### Overview Report - Device Overview The **Device Overview** section provides status insights for managed devices. - **Needs Attention** This is the percentage of devices requiring action due to one or more of the following conditions: - Not Compliant: For example, a new patch is detected. - Needs Restart: A restart is needed to complete installation. - Disconnected for 30+ Days: The device has not checked in with the Automox API for over 30 days. - **Up To Date** Devices that are compliant with policies and require no further action. - **Scheduled Update** This is the percentage of devices with scheduled updates. - **Excluded from Reports** Indicates the percentage of devices excluded from reports, which are not included in outstanding patch counts. - **Needs Approval** Pertains to manual approval policies where patches await approval before deployment. ## Needs Attention Report This report provides a list of devices that need attention, defined as devices which have one or more of the following statuses: - Not Compliant - Needs Restart - Disconnected for 30+ Days Any relevant information about the devices is listed here. You can run this report for an individual group or all groups. The Needs Attention report shows devices that are excluded from reports. ### Creating a Needs Attention report 1. From the Reports page, click **View** for Needs Attention Report. 2. Click **Select Group** from the drop-down menu. Scroll to select the group you want a report for. **Note**: You can select an individual group or All Groups. 3. The report opens in a new window. 4. To switch between groups, select **Choose Group Option**. - You can use the search bar to narrow down results - You can sort by clicking on the column heading - You can set the page view up to 500 rows You can spot any devices that need attention. The report includes the following information: | Needs Attention Report Details | Description | | --- | --- | | Device Name | This is the name of the device in your organization. You can search for this name on the Devices page. | | Policy | This field lists any policies the device is associated with. | | Status | This shows the connection status of the device. | | Last Scanned | This shows the last time the system scanned the device. | | Issue | The reason the device needs attention is listed here. | | Severity | The severity level is provided here. See also the following CVE severity scoring table. | | Days Exposed | Calculated based on the first time the package was detected. | ### CVE severity scoring Automox defines severity levels in the following manner: --- # Data Extracts _Section: Product Documentation › Automox Reports • Source: https://docs.automox.com/product/Content/Product%20Documentation/Automox%20Reports/Data_Extracts.htm_ A Data Extract allows you to access data such as historical patching and API activity in a download file. This describes how you can view, generate, and download data extracts from the Automox console. ## Viewing Data Extracts You can view previously created data extracts from the Data Extracts page. 1. From the **Reports** page, click **View** for Data Extracts. 2. If any data extracts are available, you can click to download them. If no extracts are available, you can generate a new extract. 3. The Data Extracts table consists of the following columns: | Column name | Description | | --- | --- | | Data Requested | Exact time and date when the extract was generated. | | Date Range | Start and end dates of the requested extract. | | Extract Expiration | Time and date the extract will no longer be available for download. After this date, the Status shows as expired. Note: Extracts are available for 24 hours. | | Type | This shows which type of data extract was generated: Patch History or API Activity | | Status | This can show the following statuses: Queued Running Complete Failed Canceled Expired | - **Note**: The table can be sorted by **Date Requested** or **Status**. - **Note**: If you see a failed state, you can contact Automox Support by submitting a request through the customer portal. Provide the Data Extract ID so that Automox can help diagnose what went wrong. ## Generating Data Extracts You can generate an extract that provides details about **patch activity** or **API activity** for a defined time period. 1. From the Reports page, click **View** for Data Extracts. 2. Click **Generate New**. 3. Select the Extract Type you want to generate: Patch History or API Activity. 4. Enter the start date and end date for the extract you want to generate. You can generate an extract that is a maximum of 90 days. This represents the 90-day time frame leading up to the day before the extract is issued. For example, on 2020-12-01 the default time-frame start should be 2020-09-02 and it should end with 2020-11-30. 5. Click **Generate**. **Note**: This process can take several minutes. 6. You can view the process and status of the new extract on the Data Extracts page. ## Downloading Data Extracts You can download and save data extracts that you have created. **Note**: Extracts are only available to be downloaded for 24 hours after being created. 1. From the Reports page, click **View** for Data Extracts. 2. On the Data Extracts page, find the extract you want to view and click **Download**. 3. The extract (CSV) includes the following information for the time frame requested, depending on which type of extract: ### What is in the download for each extract type? Extract type: **Patch History** | Data Type | Exported Column Name | Meaning | Description | | --- | --- | --- | --- | | Device Information | device_name | Device Name | Name of device (typically hostname) | | device_custom_name | Device Custom Name | Name assigned to the device by the customer. | | organization_id | Organization ID | This is the organization ID | | device_id | Device ID | This number is the same as the server ID | | agent_version | Agent Version | Version of the Automox agent installed on the device | | group | Group | Name of the group this device is assigned to | | package_id | Package ID | Identifier for the specific package | | device_ignored | Device Ignored | This indicates if a software package is ignored for a device (from the Device Details) | | group_ignored | Group Ignored | This indicates if a software package is ignored globally from the Software page | | Patch Information | patch_name | Patch Name | Name of the software update (patch) | | patch_version | Patch Version | Version number of the software update | | patch_knowledge_base | Patch Knowledge Base | Knowledge base identifier associated with the update | | Mutual Device/Patch Information | operating_system_family | Operating System Family | OS family (Windows, Mac, or Linux) | | operating_system_name | Operating System Name | OS name of the installed system | | operating_system_version | Operating System Version | Installed OS version | | managed_patch | Managed Patch | This shows if the update is managed by Automox | | Event Data | event_timestamp | Event Timestamp | Timestamp of the event | | patch_action | Event Type (patch action) | "Patch available" or "Patch installed" | | patch_available_timestamp | Patch Available Timestamp | Timestamp that informs when patch became available for installation | | patch_installed_timestamp | Patch Installed Timestamp | Timestamp that informs when patch was installed on the device | | exposure_time_hours | Exposure Time | Amount of time the device was not updated with the available patch | | Vulnerability Data | patch_severity | Patch Severity | Severity (if any) of vulnerability associated with the patch (for example: critical, high, medium, low) | | cves | CVEs | CVEs (if any) associated with the patch | Extract type: **API Activity** The CSV download includes the following exported data. | Column Name | Description | | --- | --- | | UUID | Universally unique identifier for the log entry | | created_at (Creation Time) | Time and date that the extract was created | | created_by (Created By) | Automox service that handled the request | | environment | Automox environment the activity was logged in | | organization_id | ID of the organization | | user_id | ID of the user who made the request | | identity_id | The ID of the identity used to make the request. For users, this is identical to the User ID field. For API keys, this is the ID of the API key used to make the request. | | identity_type | The type of identity used to make the request (api-key, user) | | request_id | Unique identifier for the request | | method | HTTP method | | path | URL path (for example: /api/servers) | | content_type | Content-type header, if present | | remote_ip | IP of the remote client who made the request | | server_ip | IP of the server that handled the request | | referer | HTTP referer, if present | | query | HTTP query string | | request_body | HTTP request body | | response_code | HTTP response code | | files | An array of the file ref objects that were uploaded in the request. Each file ref has the following fields: Name: The original name of the uploaded file Byte_size: file size in bytes Hash: sha256 hash of file contents | --- # Policy Results Report _Section: Product Documentation › Automox Reports • Source: https://docs.automox.com/product/Content/Product%20Documentation/Automox%20Reports/Policy_Results_Report.htm_ The Policy Results report allows you to view historical data for policy runs in an organization. You can see the success rates and understand which devices had failures so that you can take action. You can access this report by selecting **Insights → Reports** in the main console. ## Policy Results Overview The policy results report lists the results for the last 400 days for all policy types (patch policies, required software policies, and worklets). Results are shown in a table with status bars. **Note**: - Historical data in this report does not pre-date March 1, 2024. - You can use the Export CSV button to export this report. ## Policy Results Report Table From the Reports page, click **View** for the Policy Results Report. The following information is available from this table. | Column | Description | | --- | --- | | Actions | Possible options: Run Policy View Policy View Device Table View Policy History | | Run Time | This shows the date and time of when the last run was started for this policy. Click this timestamp to open the Device Table. | | Devices | This lists the number of devices that were associated with the policy during the run. | | Policy Name | Click the policy name to open the Policy Run History. The current name of the policy is shown with historical information for that policy even if the policy has been renamed. If a policy is deleted, that will be indicated. The most current name of that policy is used. | | Results | This visualization provides at a glance results for this policy. Hover over the bar to view details. | ## Status tiles: Legend You can identify the status of the most recent policy runs by reviewing the status tiles. Use these as a reference for the filters and report details. This legend is hidden by default. Click the arrow to show or hide the details. ![](../../Resources/Images/policy-results-legend.png) | Status tile name | Description | | --- | --- | | Successful | The policy successfully ran on the device. | | Pending | The device was reached, but the policy has not run yet. Check back later to see an updated result. | | Failed | An error occurred when attempting to run the policy on the device. You can view the reason for the failure within the report. | | Blocked | The device was in an active exclusion window when the policy was scheduled. | | Remediation Not Applicable | The device was evaluated and no action is required. The device was already up to date with the policy. Specifically, the device was scanned and no remediation is necessary. | | Not Included | The device was not included in this policy run because it was disconnected or filtered out as a result of, for example, device targeting. | ## Filtering and Searching in the Policy Results Report The filter panel includes different types of options to fine-tune your report. You can filter the list of policy runs by date range, results, policies, and display options. When you select any of the individual filters, the table automatically updates. You can clear selections individually or select Clear All. You can hide or show the filter panel, as needed. The filter panel shows by default. ### Date Range You can filter the list of policy result runs by date. Open the **Date Range** menu and select from the options: - Last 24 Hours - Last 48 Hours - Last 7 Days - Last 30 Days - Custom: Use the calendar options to create a custom search. For details, see Using the custom date calendar. ### Using the custom date calendar You can create a custom date search by using the calendar options. **Note**: - Historical data is unavailable for dates before March 1, 2024. The collection of data is ongoing and when collection reaches 400 days, the oldest date is replaced with new data every 24 hours. - You cannot select more than 100 days at a time. 1. To use the custom calendar, click into the **Start Date** field. The calendar allows you to select the desired start date and time. ![](../../Resources/Images/custom-date-start.png) 2. Use your mouse to select a time, or use the drop-down menu. You can tab to continue to the next field. 3. Select an end date and time. The format for dates are: MM-DD-YY (for example, 02-14-23). **Note**: You cannot select more than 100 days at a time. ![](../../Resources/Images/custom-date-end.png) Results are immediately updated. ### Status Results filter You can filter the policy results report by the status results. You can select multiple policy status results to filter the list by. The corresponding view is updated immediately. - Successful - Pending - Failed - Blocked - Remediation Not Applicable - Not Included ### Policies You can filter the policy results report by policy. The filter allows you to select by policy type and the individual corresponding policies in your organization. - **Select Policy Type**: Patch, Required Software, and Worklet. - Depending on the policy type or types you select, the **Select Policies** option shows the corresponding policy names that you can filter by. ### Display Options Use the **Display Options** filter to sort policy run results by policy name. 1. Select **Group by policy**. - The list automatically groups all runs of a policy together. You can see how many times a policy ran for the date range selected. 2. Click the arrow in the **Sort by** filter. - Sort by Policy name: The groups are in order by policy name - Sort by Last run: The groups are in order by the most recent policy run - Sort by Total runs: The groups are in order by the most runs per policy You can switch between ascending and descending (default) order. ![](../../Resources/Images/filters-displayoptions-group.png) ### Search for a policy You can narrow down data from the filtered search by using the search bar at the top of the table. This enhanced search allows multiple queries and partial matching. If a policy is deleted, the table indicates that. The report uses the most current name of that policy. ![](../../Resources/Images/policy-search.png) ### Show all columns of data The default setting of the policy results report does not show all available columns. You can show more data or rearrange how the columns are presented. - Click the **Columns** button and select the checkboxes to show or hide columns. - You can rearrange the order of the data by dragging the column names to the desired position. ## Policy Results Device Table You can view details about a specific policy run. You can open the Device Table from the main policy results report in two ways. - From the Policy Results Report page, for a specific policy select**Actions → View Device Table.** - For a specific policy, go to the **Run Time** column and click the timestamp. The Device Table opens as shown in this example. **Note**: - **No results** appear for the following scenarios: - If all devices are offline when a scheduled policy runs. - If all devices are offline and a policy was manually triggered to run. - A scheduled policy ran, but it had no devices associated with it. - Currently, if a device was in a deferred state at the time the policy ran (either reboot or policy deferral), there will be no results. The Policy Results Report registers the total number of devices associated with a policy, however, the number of devices listed in the Device Table will not include any deferred devices. - The report can show run results with devices marked as **Not Included**. This result comes from these possible causes, which are evaluated in the following order: - The device OS does not match the policy requirement. - The device was offline. - The device was filtered out by device targeting. ![](../../Resources/Images/policyrun-device-table.png) | Column | Description | | --- | --- | | Device | Name of the device that is in the policy. | | Result | Possible outcomes (For details see Status tiles: Legend): Successful, Pending, Failed, Blocked, Remediation Not Applicable, Not Included | | Event Time | Time that the specific event was recorded. | | Summary | Use the search box at the top to find logs for specific details listed in the Summary column such as package names and KBs. | | Details | Click the down arrow for complete information about the logged activity. | | Worklet Exit Code | The exit code is listed here, if available. This column is hidden by default. | From the Device Table, you can do the following: - Select a different run time. Go to the **Run Time** drop-down list and find the date and time of the run you want details for. - You can select multiple devices and from the **Actions** menu you can choose to: Run Policy or Reboot. ### Columns (Device Table) Use the **Columns** drop-down menu to adjust the Device Table. You can rearrange the order of the data by dragging the column names to the desired position. ![](../../Resources/Images/device-table-columns.png) ### Device Table Details You can view details about each run from the **Details** column of the Device Table. 1. Make sure you are showing the **Details** column. 2. Find the device and run time that you want details for. 3. Click the arrow to view information that supplements the summary. Use your cursor to scroll through the details. ![](../../Resources/Images/device-table-details.png) ## Policy Run History You can view history for a specific policy run. You can open the Policy Run History page from the main policy results report in two ways. - For a specific policy select**Actions → View Policy History.** - For a specific policy, go to the Policy Name column and click the name. The Policy Run History page opens. ![](../../Resources/Images/policy-run-history-graph.png) ![](../../Resources/Images/policy-run-history-table.png) The report shows the event results graphically. This page provides a visual representation of the Device Table event data that you can drill into for specific dates. Use the drop-down menu to adjust the number of days presented. ## CSV Export Description of what you can find in the CSV export files. Use this list for reference. | CSV Export column | Description | | --- | --- | | custom_name | Name assigned to the device by the user. | | device_count | This lists the number of devices included in the policy run. | | device_deleted_at | Time and date when the device was removed. | | device_id | Device ID (same as server ID) | | device_uuid | Device UUID (universally unique identifier) | | display_name | If configures, this shows the custom name, otherwise this is the hostname. | | event_time | Time that the specific event was recorded. | | exit_code | Remediation exit code returned by a worklet or advanced policy. | | failed | This lists the number of devices with unsuccessful policy runs. | | hostname | Unique label assigned to a device. | | not_included | This is the number of devices not included in the policy run because they were disconnected or filtered out as a result of, for example, device targeting. | | org_uuid | This is the ID for the current organization. | | pending | This lists the number of devices for which the policy run has started but is not yet completed. | | policy_deleted_at | This lists the specific date and time of when the policy was deleted. | | policy_id | This is the legacy Policy ID. | | policy_name | This is the name of the policy. | | policy_type | This lists the policy type: Patch, Required Software, or Worklet | | policy_uuid | This is the Policy ID (universally unique identifier). | | remediation_not_applicable | This is the number of devices that were evaluated and no action was required. The devices were already up to date with the policy. Specifically, the devices were scanned and no remediation is necessary. | | result_reason | This explains the result status. | | result_status | This shows one of the known statuses: Successful, Pending, Failed, Remediation Not Applicable, or Not Included | | run_time | This shows the date and time of when this run was started for this policy. | | stderr | Standard error: available details listed in the report are included here. | | stdout | Standard output: available details listed in the report are included here. | | success | The number of devices for which the policy run was successful. | | blocked | The number of devices for which the policy run was blocked by an active exclusion window. | ## Caveats - Data does not pre-date March 1, 2024. - When a device is available again being offline, it checks for all missed patches and executes them in a single run. This run appears as a new policy run. - When a policy or device is renamed, the report shows only the most current name but retains all historical information. - For example, if a previous run had policy A, and policy A was renamed to policy B, all future runs will show policy B (even the previous run that was run under the old name). - These results do not include runs initiated using the Run Now (FixNow) feature. ## Related Topics - [Creating Reports](Creating_Reports.htm) - [Data Extracts](Data_Extracts.htm) - [Automox Policy Results API](https://developer.automox.com/openapi/policy-history/overview/) --- # Account Management Using the Automox Console or PowerShell _Section: Product Documentation › Best Practices • Source: https://docs.automox.com/product/Content/Product%20Documentation/Best%20Practices/Account_Management_Using_the_Automox_Console_or_PowerShell.htm_ Follow these best practices to clean up unnecessary user accounts. ## Account Management Using the Automox Console Follow these steps to clean up unnecessary user accounts using the Automox console. ![](../../Resources/Images/user-accounts.png) 1. Go to **Settings** ( ⋮ ) in the console. 2. Select **Users** from the menu. 3. Review the **User Accounts** list and select any unnecessary accounts. You can also use the search bar to filter the list. 4. Select the **Actions** drop-down menu and click **Remove User**. 5. Confirm the selected accounts so that only approved user accounts remain in the console. ## Account Management Using PowerShell Follow these steps to delete multiple users from an organization based on the user email addresses using a PowerShell script. This logs the successes and failures in a location that you specify. --- # Disconnected Devices Cleanup Using the Console, PowerShell, or Python _Section: Product Documentation › Best Practices • Source: https://docs.automox.com/product/Content/Product%20Documentation/Best%20Practices/Disconnected_Devices_Cleanup_Using_the_Console_or_PowerShell_Python.htm_ Follow these best practices to clean up disconnected devices. ## Disconnected Devices Cleanup Using the Automox Console Follow these steps to clean up disconnected devices using the console. ![](../../Resources/Images/devices-disconnected-for.png) 1. Go to **Devices** in the console. 2. Select **Columns**. 3. Select the **Disconnected For** option in the Columns drop-down menu. 4. Sort by **Disconnected For** to get a list of devices based on how many days they have been disconnected. 5. Select the checkbox for all the devices greater than X amount of days. This example selects anything disconnected longer than 44 days. 6. Click the **Actions** drop-down menu and select **Remove**. 7. All devices disconnected for more than X days are immediately removed from the console with this action. ## Disconnected Devices Cleanup Using PowerShell or Python - PowerShell - Python Follow these best practices to clean up disconnected devices using a PowerShell script. You can use a PowerShell script to remove devices that have been disconnected longer than X days. This script automates the removal using an API call to check the last disconnected date and remove any devices older than the number of days you specify in the code. ## Disconnected Devices Cleanup Using Python The following script uses Python, and is functionally the same as the PowerShell script. # # [-------------------------------------DISCLAIMER-------------------------------------] # This script is provided as-is with no implicit # warranty or support. It's always considered a best practice # to test scripts in a DEV/TEST environment, before running them # in production. # Please proceed with caution. # Do not distribute your API Key to any untrusted third party. # [-------------------------------------DISCLAIMER-------------------------------------] # import requests from datetime import datetime, timedelta url = 'https://console.automox.com/api/servers' # START Configurable Items # User enters API key api_key = input("Please enter your Automox API key: ") # User enters org ID while True: try: org_id = int(input("Please enter the org ID: ")) # Cycle repeats until an integer value is entered for org ID except ValueError: print("The value you have entered is not an integer. Please enter an integer for org ID.") else: break # User enters max_days while True: try: max_days = int(input("Please enter the maximum number of days disconnected before deleting: ")) # Cycle repeats until an integer value is entered for max_days except ValueError: print("The value entered is not an integer. Please enter an integer for max days.") else: break # END Configurable Items # Calculate Cutoff Date cutoff_date = datetime.now() - timedelta(days=max_days) # Prepare the query query = { "o": org_id, "limit": 500, "page": 0, } headers = { "Content-Type": "application/json", "Authorization": "Bearer " + api_key } # Submit the query get_response = requests.get(url, headers=headers, params=query) # Get user input while True: try: dry_run = bool(input('Dry run? True/False: ')) except ValueError: # The cycle repeats until the user enters True or False print("Error! You have not entered a Boolean value. Please try again.") else: break # Do a dry run, display list of devices to be deleted without actually deleting them if dry_run is True: # Iterate through devices for device in get_response.json(): # Filter out connected devices if device['last_disconnect_time'] is not None: # Reformat the last disconnected date last_disconnect_date = datetime.strptime(device['last_disconnect_time'].split("+")[0], "%Y-%m-%dT%H:%M:%S") # If device has been disconnected before the cutoff date, include it in the list if datetime.date(last_disconnect_date) < datetime.date(cutoff_date): print("Device " + str(device['name']) + " with Device ID " + str(device['id']) + " will be deleted.") del_url = url + "/" + str(device['id']) query = { "o": org_id } # Live run - displays list of devices to be deleted, and then actually deletes those devices if dry_run is False: # Iterate through devices for device in get_response.json(): # Filter out connected devices if device['last_disconnect_time'] is not None: # Reformat the last disconnected date last_disconnect_date = datetime.strptime(device['last_disconnect_time'].split("+")[0], "%Y-%m-%dT%H:%M:%S") # If device has been disconnected before the cutoff date, include it in the list and delete it if datetime.date(last_disconnect_date) < datetime.date(cutoff_date): print("Device " + str(device['name']) + " with Device ID " + str(device['id']) + " will be deleted.") del_url = url + "/" + str(device['id']) query = { "o": org_id } print("Deleting devices...") del_response = requests.delete(del_url, headers=headers, params=query) ## Related Topics - [Community: Powershell script to remove devices that have been disconnected longer than X days](https://community.automox.com/automox-labs-8/powershell-script-to-remove-devices-that-have-been-disconnected-longer-than-x-days-270) --- # Identify Software Install Count Using PowerShell _Section: Product Documentation › Best Practices • Source: https://docs.automox.com/product/Content/Product%20Documentation/Best%20Practices/Identify_Software_Install_Count_Using_PowerShell.htm_ Use a PowerShell script to identify software packages installed on every device in an organization referenced by the computer name. By altering the script you can add additional fields. Make sure the `Set-Content` line reflects all the fields you add to the `Select-Object` part of the last line of the script. You'll also want the `Set-Content` line to have the fields in the same order as the `Select-Object`. Available fields: [List All Software Packages for All Devices](https://developer.automox.com/openapi/axconsole/operation/getOrganizationPackages/) --- # Retrieve Policy List and Schedules Using PowerShell _Section: Product Documentation › Best Practices • Source: https://docs.automox.com/product/Content/Product%20Documentation/Best%20Practices/Retrieve_Policy_List_and_Schedules_Using_PowerShell.htm_ Use a PowerShell script to retrieve a list of all policies and schedules for your organization and put them in an Excel spreadsheet. **Note:** Due to the way Excel auto-formats numbers, the “schedule months” column may show in scientific notation due to the length. To fix the display of them, highlight the column, right-click on the column, click Format Column, choose Custom, then set the Type to 0. --- # Software Install List of Devices Using PowerShell _Section: Product Documentation › Best Practices • Source: https://docs.automox.com/product/Content/Product%20Documentation/Best%20Practices/Software_Install_List_of_Devices_Using_PowerShell.htm_ Use a PowerShell script to retrieve a list of devices that have a unique software package installed. This list includes the version number on the export file, but the search uses the software package name. This example output uses a search for Microsoft Edge Chromium: ![](../../Resources/Images/example-output-psscript.png) --- # Worklet Policy Best Practices _Section: Product Documentation › Best Practices • Source: https://docs.automox.com/product/Content/Product%20Documentation/Best%20Practices/Worklet_Policy_Best_Practices.htm_ Follow these best practices for effective use of Worklets. **Note**: The Evaluation code is run every time a device is scanned, even if a policy or worklet doesn't have an assigned schedule. ## Using Device Targeting Use Device targeting to ensure that a Worklet policy doesn't negatively impact an account compliance score. **Prerequisites**: You have the required administrative permissions to manage Worklets. 1. Go to the **Edit Worklet** page of the policy. 2. Select **Device Targeting** and set the Attribute **OS** to match the operating system setting of the policy itself. ![](../../Resources/Images/edit-worklet.png) This device targeting setting ensures that the Worklet policy runs against devices with the same OS. Otherwise, the policy would count against the compliance score due to any Worklet failures when run against devices with different OSes. ## Manually Running a Worklet If you want to manually run a Worklet and want to include the evaluation code, using the **Run Policy** option requires some additional actions. **What to know**: When you run a Worklet using the**Run Policy** option, the evaluation code is not executed. Only the remediation code is executed. **Recommendation**: When you are developing and testing a Worklet and want to include the evaluation code, follow these steps: 1. Schedule the Worklet policy to run 10 minutes from the current time. 2. Perform a device scan on the testing device to make it aware of the Worklet policy change. 3. Monitor the results. ### PowerShell Examples **Evaluation Code:** <# .SYNOPSIS Worklet to test evaluation code OS Support: Windows 8/10/11 Required modules: NONE .DESCRIPTION This script does an evaluation test to check and see if a file exist on the endpoint. If it doesn't, it will create them. .REQUIREMENTS PowerShell 2.0 .EXAMPLE .NOTES Author :Robert Eickleberry Modified By : Prerequisite :PowerShell V2 and up over Win 8/10/11 Date :16 Aug 2022 #> #variables to look for in evaluation $file = "Test.txt" $folder = "C:\Automox\" #variables combined to create test path location $location = "$folder$file" #funcation to add date and time to file function Get-TimeStamp { return "[{0:MM/dd/yy} {0:HH:mm:ss}]" -f (Get-Date) } #checks if file exist if (Test-Path -Path $location) { #if location exist, adds message Add-Content -path $location -value "$folder and $file exist. Evaluation code - Using Exit 0. $(Get-TimeStamp)" Exit 0 } else { Exit 1 } **Remediation Code**: <# .SYNOPSIS Worklet to test remediation code OS Support: Windows 8/10/11 Required modules: NONE .DESCRIPTION This script is does an evaluation test to check and see if a file exist on the endpoint. .REQUIREMENTS PowerShell 2.0 .EXAMPLE .NOTES Author :Robert Eickleberry Modified By : Prerequisite :PowerShell V2 and up over Win 8/10/11 Date :16 Aug 2022 #> #variables to look for in remediation $file = "Test.txt" $folder = "C:\Automox\" #variables combined to create test path location $location = "$folder$file" #funcation to add date and time to file function Get-TimeStamp { return "[{0:MM/dd/yy} {0:HH:mm:ss}]" -f (Get-Date) } #adds message to already existing file #if location does not exist, creates folder and file New-Item -ItemType Directory -Force -Path $folder New-Item -path $folder -name $file -type "file" #after folder and file is created, adds message Add-Content -path $location -value "Created folder $folder and file $file via Remediation Code. $(Get-TimeStamp)" Exit 0 ## Related Topics - [What is a Check-In vs. Device Scan?](https://help.automox.com/hc/en-us/articles/6795093118868-What-is-a-Check-In-vs-Device-Scan) --- # Automox Console Dashboard _Section: Product Documentation › Console Overview • Source: https://docs.automox.com/product/Content/Product%20Documentation/Console%20Overview/Automox%20Console%20Dashboard.htm_ The Dashboard is the default landing page for the Automox **Important**: Most data displayed on the dashboard is refreshed on a delay. The service that provides dashboard data caches results for up to 15 minutes. As a result, values shown in dashboard sections may be up to 15 minutes old. This does not apply to the Scheduled Policies timeline, which retrieves data through a separate process. **Note**: Refer to [Navigation](#Navigati2) for more about the new top navigation in the Automox console. ![](../../Resources/Images/dashboard-status-tiles.png) You can download the contents of this page to a PDF. To do this, click **Export PDF**. ## Status Tiles At the top of the Automox dashboard, you can identify the organization and status date for the dashboard you are viewing. The first set of tiles provide an overview of device and policy status. These status tiles are described here. | Status tile name | Description | | --- | --- | | Compliant Devices | Shows the number of devices that are up-to-date based on their policies and schedules. Click to open the list of devices filtered for Compliant. | | Policies Executed | Shows the number of policies that have run in the last 7 days. Click to open a list of these policy run results. | | Available Updates | Shows the number of available updates that have been exposed within the last 7 days. Click to open a list of available software updates. | | New Devices | Shows the number of devices added to your organization within the last 7 days. Click to open a list of recently added devices. | ## Device Troubleshooting Use the Device Troubleshooting section to review any devices that need attention. ![](../../Resources/Images/dashboard-troubleshooting.png) | Device Troubleshooting status | Description | Click graph or status | | --- | --- | --- | | Needs restart | The device has patches or software installed that require a restart before installation can be fully completed. | Click to open the list of Devices filtered for Needs Restart | | Failed update attempts | View all devices that failed to successfully install new patches. Manual intervention might be required. | Click to open the list of Devices filtered for Failed Update Attempts | | Disconnected for 30+ days | View devices that are not connected. You cannot take any patching actions until these devices are connected again. | Click to open the list of Devices filtered for Disconnected 30+ Days | | Not compatible | View devices that do not pass the compatibility check. See the Troubleshooting section of the Device Details page for more information. | Click to open the list of Devices filtered for Not Compatible | ## Outstanding Patch Count This grid shows both scheduled or available patches in relation to the number of days a patch has been left unpatched. These patches can be part of either active or inactive policies. The number of devices affected by any of the outstanding patches is listed below the grid. A device might have more than one outstanding patch. ![](../../Resources/Images/dashboard-patch-count.png) 1. Click any patch count number to view the Software page filtered by the severity level and days exposed. 2. Click the highlighted devices link after the grid to view a list of all devices with outstanding patches. 3. Click the highlighted outstanding patches link to view a list of all software patches that impact devices in your environment. **Note**: The following are not included in the outstanding patch count: - Software marked as ignored (set directly in the software table and not through a policy filter) - Devices that are excluded from reports **Recommendation**: Perform a rescan of any device marked as ignored to ensure it is accurately recorded. Use this information to determine which policies to review and activate, if necessary. ## Scheduled Policies You can view all scheduled policies from the Scheduled Policies scrolling timeline. These are organized in tabs by policy type. **Note**: This shows the policy schedule in local time, even if the scheduled policy is in UTC. ![](../../Resources/Images/dashboard-scheduled-policies.png) - The main **View All** tab shows the next 40 scheduled policies. - The tabs by type depend on the policies you have configured. To view a list of scheduled policies for a specific policy type, click the corresponding tab. This will list up to 40 scheduled policies per type. - Click the name of the policy to open that individual policy page. - Click **View Devices** to open the list of devices filtered by that policy. - Click **View Policies** to view a list of all policies. **Note**: The **Packages Ready For Approval** page is accessible from the top navigation. Select **Manage → Manual Approvals**. ## Environment by OS The Environment by OS chart shows the device OS distribution for the current organization. ![](../../Resources/Images/environment-os.png) - Click the number under the OS to open the devices page filtered by that specific operating system. - Click **Add a Device** to install the Automox agent on your device. See also [Automox Agent Installation Overview](../Agents/Agent Installation/Automox_Agent_Installation_Overview.htm). ## Device Health by Group The Device Health by Group chart provides a count of devices that have had an outstanding patch within the timeframe selected, shown by group. These are sorted in descending order. ![](../../Resources/Images/device-health.png) Click **Select Groups** to select specific groups or Select All from the drop-down list. You can use the search bar to find specific groups. Select from the different lengths of time to view device groups with available outstanding patches for that period of time. The number above the column shows the number of devices. - You can select from different time periods, such as: 0–7 days (Last 7 Days), 0–30 days (Last 30 Days), 0–90 days (Last 90 Days), or 0–180 days (Last 180 Days). - The default time period is 7 days. - If no groups are selected, the first 10 groups are shown in descending order. When you click inside a group column, the Devices page opens filtered by that group and specific period of time. ## Critical Severity Patches The Critical Severity Patches table shows the top 5 critical patches in your environment. The list starts with the highest number of devices not patched. ![](../../Resources/Images/dashboard-critical-sev-patches.png) | Critical Severity Patches table | Description | | --- | --- | | Patch Name | Name of the software update (patch). Click name to open the Software page. | | % Patched | Shows the percentage of devices that have been patched. | | Devices Impacted/Total | Lists the number of devices impacted by the patch. The highlighted number of devices need to be patched. You can click the number to open the Devices page filtered by the impacted devices. The bottom number (Total) is all devices in your environment with the patch. | ## Next Steps Guide When you initially access the console, you will find patch policy recommendations that you can access directly from the dashboard under **Next steps for Automox Demo**. ![](../../Resources/Images/next-steps.png) If you close (Dismiss) these recommendations, you can still access the policy templates in the [Automation Maturity Playbook](https://university.automox.com/automation-maturity-playbook/1887294) of Automox University. ## Navigation The interface navigation is above the dashboard. **Note**: New top navigation uses the following options: **Dashboard**, **Devices**, **Automate**, **Manage**, and **Insights**. From **Automate** you can access: - **Policies**, **Worklet Catalog**, and **Remediations** ![](../../Resources/Images/nav-automate.png) From the **Manage** tab you can access: - **Groups**, **Software**, and **Manual Approvals** ![](../../Resources/Images/nav-manage.png) From **Insights** you can access: - **Analytics** and **Reports** ![](../../Resources/Images/nav-insights.png) ## Managing Your Organization You can manage organizations and users by selecting the top navigation menu next to your name. Depending on your permissions, you can create a new organization from here. For more information, see **[Managing Organizations](../Global Access Management/Managing_Organizations.htm)**. ![](../../Resources/Images/navigation-orgs.png) ## Help Click the question mark at the top of the console to access the following links: - [Knowledge Base](https://help.automox.com/): This opens the Customer Portal where you can find Knowledge Base articles and submit requests to the Automox support team. - [Release Notes](../Release Notes/Documentation Release Notes/ReleaseNotesLP.htm): As an active customer, you have access to Automox product documentation and agent release notes. - [Technical Release Feed](https://technicalreleasefeed.automox.com/): A subscribable feed that provides updates on technical releases and related documentation changes. - [Community](https://community.automox.com/): Join the Automox community to find time-saving resources and best practices. - [API Reference Guide](https://developer.automox.com/): This opens the Automox Developer Portal, where you can find API documentation and other developer resources. - [Automox University](http://university.automox.com/): Access to the free Automox on-demand training platform. ## Settings To access settings for your account, in the upper right, click the menu icon to open the drop-down list of options. ![](../../Resources/Images/settings-menu.png) Depending on your permissions, you can access your profile, billing information, user account details, secrets, keys (API and access keys), script signing, and security settings such as two-factor authentication. Refer to [Roles and Permissions](../Global Access Management/Roles_and_Permissions.htm). --- # Automox Compliance _Section: Product Documentation › Console Overview • Source: https://docs.automox.com/product/Content/Product%20Documentation/Console%20Overview/Automox_Compliance.htm_ How does compliance work in Automox? ## Compliant and Ready Statuses and their Meanings You can view the device, connection, and policy status of a device from the Devices page. The statuses and meanings are described in [What the Statuses Found in the Automox Console Mean](What_the_Statuses_Found_in_the_Automox_Console_Mean.htm). See also [Filtering and Searching on the Devices Page](../Device Management/Filtering_and_Searching_on_the_Devices_Page.htm). The Devices page shows the current status of the device, as in this example: ![](../../Resources/Images/devices-page-status.png) A policy is **Compliant** when it has no Scheduled Patches or failed remediations. A device is labeled as **Ready** when it has no command impacting the device. Any device that has a scheduled patch count greater than zero falls into the Ready status until it is actually running when it shows a status of either Installing or Pending. This can change a device from Compliant to Non-Compliant as soon as a new patch is detected--assuming that the new patch is applicable to the device’s patch policies. ## Scheduled Patches vs Total Patches **Scheduled Patches** are the number of patches that are available to a device and are applicable to its current policy assignments and policy rules. **Note**: For a patch to be counted as Scheduled, the patch policy must have a Policy Status of Active (On). Policies that are set to Inactive (Off) are not considered in this count. See also [Creating a Patch Policy](../Policies/Creating_a_Patch_Policy.htm). **Total Patches** are the number of total patches currently available to a device regardless of policy assignments or filters. ![](../../Resources/Images/devices-scheduled-total-patches.png) ## What Does This Mean for Me? Device, Policy, and Connection statuses are updated once per scan and are based on the latest software inventory and policy settings. This takes into account anything that has changed since the previous scan of the device. When new patches are detected, the Policy status changes. The Device status is Ready until any processes are started, such as installing. ## Example of different device statuses using three devices - **Device A** has a Patch All policy - **Device B** only has a Patch by Critical Severity policy - **Device C** has no policies The devices are all currently Compliant. Device C also shows a status of **Unmanaged** because no policies are associated with it. ### A new patch releases with a severity rating of Low: - For **Device A**, the Policy Status shows **Non-Compliant**. The Device Status shows Installing when the policy is remedying. The patch is installed the next time the policy runs on schedule. This device’s entry in the Device page list shows 1 under Scheduled Patches and 1 under Total Patches. After the policy runs, the Policy Status shows Compliant. - For **Device B**, the Policy Status remains **Compliant**. This new patch is not applicable to its associated policy and is not installed. Since the patch isn’t relevant to this device’s policy rules, it is considered Ready. This device’s entry in the list shows 0 under Scheduled Patches and 1 under Total Patches. - For **Device C**, the Policy Status also remains **Compliant**. The Device Status shows Ready. With no associated or enabled patch policies, no patches are considered to be Scheduled. This device’s entry in the list also shows 0 under Scheduled Patches and 1 under Total Patches. ## Related Topics: - [What the Statuses Found in the Automox Console Mean](What_the_Statuses_Found_in_the_Automox_Console_Mean.htm) --- # Automox Okta Single Sign-on (SSO) Integration _Section: Product Documentation › Console Overview • Source: https://docs.automox.com/product/Content/Product%20Documentation/Console%20Overview/Automox_Okta_Single_Sign_on__SSO__Integration.htm_ You can configure single sign-on through Okta for all your Automox users. Automox integrates with Okta Identity Management through a series of steps. Automox also has a pending application available on the Okta app marketplace. This supports both service provider (SP) and identity provider (IdP) initiated sign on. Users can either click the Automox app on their Okta dashboard to sign in, or provide their email address on the sign in page to be redirected to Okta for authentication. ## Initial Setup To set up Okta, you need the following information from Automox: - Your unique ACS URL - Entity ID --- # Automox and Reporting Your Environment _Section: Product Documentation › Console Overview • Source: https://docs.automox.com/product/Content/Product%20Documentation/Console%20Overview/Automox_and_Reporting_Your_Environment.htm_ Automox has reporting available for you to view and download. Included are our activity log, data extracts, needs attention report, overview report, policy results report, and pre-patch report. From the **Reports** page, select **View** for the type of report you want to view. ![](../../Resources/Images/reports-main.png) ## Available Reports Each report provides a different perspective on your organization’s patching activity, device status, or system actions. You can view reports directly in the console or download them for further analysis. ### Activity Log Lists historical events, including automated and manual actions performed on devices in your organization. You can export this log for review or troubleshooting purposes. For device-specific logs captured from recent scans, see **Device Logs** on the Device Details page. ### Data Extracts The Data Extracts report provides two export options: - **Patch History**: Provides detailed patch and policy execution data for all devices in your organization. Use this export to analyze patch history, policy results, or overall remediation activity within a selected time range. - **API activity**: Captures historical API usage across your organization, including API requests, methods, response codes, and timestamps. Use this export to audit API activity and monitor integration performance over time. ### Needs Attention Report Identifies devices that require attention, such as those with failed patches or pending remediations. This report highlights where issues occurred so you can act quickly. ### Overview Report Summarizes the overall state of devices in your organization. It includes historical patch data, device group information, and scheduled policy details for a broad operational view. ### Policy Results Report Displays historical results for policy runs. Use this report to see which devices completed successfully, which failed, and when each policy executed. ### Pre-Patch Report Lists all upcoming scheduled patches per device. It includes severity and exposure details to help you assess potential impact before deployment. ## Related Topics - [Creating Reports](../Automox Reports/Creating_Reports.htm) - [Policy Results Report](../Automox Reports/Policy_Results_Report.htm) - [Data Extracts](../Automox Reports/Data_Extracts.htm) - [Analytics](../Automox Reports/Analytics.htm) - [Device Details](../Device Management/Device_Details.htm) --- # Configuring SAML for Microsoft Entra ID (Azure ID) _Section: Product Documentation › Console Overview • Source: https://docs.automox.com/product/Content/Product%20Documentation/Console%20Overview/Configuring_SAML_for_Microsoft_Entra_ID__Azure_ID_.htm_ This describes how you can set up SAML with Microsoft Entra ID. Microsoft renamed Azure Active Directory (Azure AD) to Entra ID. If you are currently using Azure AD in your organization, you can continue to use the service without interruption. **Prerequisites**: You have the required administrative permissions to configure SAML support in the Automox console and in the Microsoft management service. ## Automox Configure SAML Window To complete this procedure, you must log in to the Automox console and have the information available from the Configure SAML window. Refer to SAML-based Single Sign-on (SSO) in [Security](../Settings/Security.htm) for details about accessing the **Security > SAML** data. ## Setting Up SAML with Microsoft Admin Center In the Microsoft admin center, you must configure an Enterprise Application (Automox) and enable users for it. Refer to the Microsoft [documentation](https://learn.microsoft.com/en-us/entra/) for the most up-to-date version of the process. The basic outline is described here: Log in to the [Microsoft admin center](https://entra.microsoft.com/): **Note**: In this guide, **Microsoft** refers to Microsoft Entra ID or Azure AD. 1. Go to **Enterprise applications.** See also: [https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/add-application-portal](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/add-application-portal). 2. Click **New Application**. 3. Click **Create your own application**. 4. Enter a name for your app. - Under “What are you planning to do with your application”, select**Integrate any other application you don’t find in the gallery (Non-gallery)**. - Click **Create**. 5. Go to **Manage >****Single sign-on** and select **SAML**. 6. Under **Basic SAML Configuration,** click **Edit**. Now refer to your **Automox console**: - From the Automox console, navigate to Settings (⋮). - Select **Security** and click the **Enable** button for SAML. Follow the 2FA prompts to launch the configuration window with the information you need. - Copy and paste these entries into the **Microsoft Basic SAML Configuration.** Remember to modify the URL to point to your org: - Automox Entity ID → Identifier (Entity ID) - Automox ACS URL → Reply URL (Assertion Consumer Service URL) - Automox Dashboard URL including org id → Relay State. For example: `https://console.automox.com/dashboard?o=` - Click **Save**. Close this configuration window. 7. In Microsoft, go to **SAML****Certificates**, then follow these steps: - **Important**: Before you download the certificate, click **Edit**. After the SAML Signing Certificate modal appears, click X to close the modal. This step is necessary to fix an observed issue with Azure generating a legacy CN (common name) for the certificate (accounts.accesscontrol.windows.net). See the related [support article](https://help.automox.com/hc/en-us/articles/39333837582484-Azure-SAML-SSO-Setup-fails-and-loops-back-to-Login-Screen) for details. - Download the **Certificate (Base64)**. - Open the certificate using a basic text editor and **copy the certificate**(excluding any trailing blank lines). This is known as x509 for the next step. - Go to the **Automox > Configure SAML window** and paste into the **x509**field. 8. In Microsoft, scroll to **Set up Automox** (where “Automox” is whatever you named your Enterprise Application in Microsoft). Refer to this page to configure SAML in Automox. - Copy and paste the following from **Microsoft**to the**Automox Configure SAML**window: - Login URL → Login URL - Microsoft Entra Identifier → Entity ID - Logout URL → Logout URL - Select **(Optional) Provision New Users.** (**Note**: This setting is recommended to make it easier to add users who are new to Automox.) - Switch on **Enable SAML for users of the organization**. (This is at the top of the Automox Configure SAML window.) - Save the SAML configuration in Automox. - Logout of Automox. 9. Enable Automox (your Enterprise App) to appear in the app launcher for users ([https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/access-panel-collections](https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/access-panel-collections)) - Microsoft → **Manage**, click **User Settings.** - “User feature previews” section → click Manage user feature preview settings - “Users can use preview features for My Apps” → select **All**. 10. You can enable users to access Automox from within Microsoft. - Go to **Manage → Enterprise Applications → Automox** (or whatever you called your enterprise app). - In the Getting Started section, click **Assign users and groups**. - **+ Add user/group.** - Select and assign the users. Use the search to find users, as needed. 11. The newly displayed user can access Automox with this same email address by going to **My Apps** in Microsoft 365. Select the new enterprise app (Automox) tile. ## User Provisioning To automatically provision a user, select the **(Optional) Provision New users**checkbox in the Automox Configure SAML window. Then do as follows: - The user must log in to [https://myapplications.microsoft.com/](https://myapplications.microsoft.com/) - The Automox Enterprise Application should appear. Click the tile to launch Automox. ## Manual Provisioning To manually provision a user with SAML/SSO enabled, follow these steps in Automox: 1. Navigate to the Global Users management page (Manage Organizations and Users button underneath the Org selection tab). 2. Click **Users**, then click **Add User**. Enter the same email address that is associated with the user account that you added to the Enterprise Application on the Microsoft side. 3. Once you add the user, Automox sends an invitation email to the address for the user to authorize their account. After that is completed, the user can log in through [console.automox.com](http://console.automox.com/) with their email address; this forwards them to Microsoft for authentication. Users can also log in to the console with the tile from the My Apps page in Microsoft. **Note**: When provisioning users, the user is created in Automox as a Read Only user. You must have the required permissions to adjust the role for the newly created users. This can be done from the Global View, Setup & Configuration → Users page. Refer to [Understanding Global Access Management](../Global Access Management/Understanding_Global_Access_Management.htm) and [Roles and Permissions](../Global Access Management/Roles_and_Permissions.htm). ## Related Topics - [Automox University: Microsoft Entra ID (Azure AD) SAML Walkthrough](https://university.automox.com/ax-azure-ad-saml-walkthrough) - SAML-based Single Sign-on (SSO) in [Security](../Settings/Security.htm) - [Microsoft Entra Quickstart](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/add-application-portal) - [Managing Users](../Global Access Management/Managing_Users.htm) --- # Inviting Users When Single Sign-on (SSO) is Enabled _Section: Product Documentation › Console Overview • Source: https://docs.automox.com/product/Content/Product%20Documentation/Console%20Overview/Inviting_Users_When_Single_Sign_on__SSO__is_Enabled.htm_ When single sign-on (SSO) is enabled in Automox, the way you invite users has changed. Currently, you **cannot** invite users to an organization with SSO enabled. This prevents a password from being set for the new user. To invite users to an organization with SSO enabled, you must enable Provisioning within Automox's SSO settings. Today, users can only be provisioned when attempting login through **IdP (Identity Provider)**initiated SSO. --- # Multi-Organization SAML Single Sign-On _Section: Product Documentation › Console Overview • Source: https://docs.automox.com/product/Content/Product%20Documentation/Console%20Overview/Multi_Organization_SAML_Single_Sign_On.htm_ This describes how to use SAML/SSO for multi-organization environments. **Prerequisites**: You have the required permissions for all organizations that you want to manage in this configuration. Automox supports multiple SAML configurations for all organization that you manage. Multi-organization SAML allows you to create a SAML configuration for each organization, providing specific access based on the organization and users. Currently, multi-organization SAML only supports a one-to-one relationship with organization. Each organization needs its own configuration and its own SAML app. ## Configuration The process for configuring multi-organization SAML is the same as single-organization SAML. In any organization, follow [Security](../Settings/Security.htm) to setup a SAML configuration. Once configured, any user with an account in the organization with SAML enabled is redirected to the IDP for login, unless they specify an organization at login. ## Logging In ### IDP-Initiated IDP-initiated logins behave as expected. When a user clicks on a specific app in your IDP for an organization, they are redirected to that organization. After they log in, they can optionally navigate to another organization that they are part of if they use the Automox multi-organization drop-down menu. ### SP-Initiated SP-initiated logins behave in many different ways depending on how you want users to reach their specific organizations: **Generic Login:**If a user visits [console.automox.com](http://console.automox.com/) and attempts to log in, Automox defaults to the SAML configuration of the lowest organization ID that the specific user has access to. If organization A for the user has SAML, the SAML configuration for organization A is used. If organization A has password login, and organization B has SAML enabled, organization B’s SAML configuration is used. **Define an Organization ID:**Users can login directly to a specific organization if they specify an organization ID in the URL at login. If a user specifies organization A in their login URL, they will use organization A’s SAML configuration to login. Specify an organization ID in the login URL as follows: - You can find the organization ID for any given account when logged into the console. The URL shows a parameter for “?o=XXXX,” where XXXX is the organization ID. - Copy and paste the same “?o=XXXX” parameter into the login URL (https://console.automox.com/login) to force login to that specific organization. Automox recommends bookmarking specific login URLs so that users can navigate directly to specific accounts. ## Inviting and Provisioning Users ### Inviting Users With Multi-organization SAML enabled, you can invite users to other organizations through the regular user invite workflow. If SAML is enabled in the organization that you are inviting them to, they will need appropriate access to the SAML app in your IDP. ### Provisioning Provisioning users from the IDP is only supported on IDP-initiated login. To provision a user to a specific organization, enable provisioning when setting up the SAML configuration and give the user access to the appropriate app in your IDP. When they attempt login, an account will be created for them in the appropriate organization. --- # Resetting Your Password _Section: Product Documentation › Console Overview • Source: https://docs.automox.com/product/Content/Product%20Documentation/Console%20Overview/Resetting_Your_Password.htm_ If you forget your password, you can reset it from the console login page. [https://console.automox.com/](http://console.automox.com/) 1. Enter your email address in the login window. 2. Click: [Forgot Password](https://console.automox.com/forgot-password) 3. Enter your email address to receive a reset link. 4. Click **Send Reset Link**. ![](../../Resources/Images/forgot-password.png) ### Password Requirements Password requirements are as follows: - Must be at least 12 characters in length, but no more than 64 - Must contain at least one lowercase and one uppercase letter - Must contain at least one number - Must contain at least one special character: ~ ! @ # $ % ^ & * _ - + = ` \ | ( ) [ ] : ; " ' < > , . ? / - Automox screens passwords (new or updated) against lists of commonly used or compromised passwords --- # Supported Browsers for the Automox Platform _Section: Product Documentation › Console Overview • Source: https://docs.automox.com/product/Content/Product%20Documentation/Console%20Overview/Supported_Browsers_for_the_Automox_Platform.htm_ This page describes the supported browsers for the use of Automox. **Note**: It’s possible that Automox works for some unsupported browsers. However, for the best experience, Automox recommends using the latest versions of these browsers: - Chrome - Edge - Firefox With the End of Life for Internet Explorer (IE), Automox no longer supports updates for IE. ## Related Topics - [Clearing Your Browser Cache to Optimize Automox Console](https://help.automox.com/hc/en-us/articles/5352237535380-Clearing-Your-Browser-Cache-to-Optimize-Automox-Console) --- # What the Statuses Found in the Automox Console Mean _Section: Product Documentation › Console Overview • Source: https://docs.automox.com/product/Content/Product%20Documentation/Console%20Overview/What_the_Statuses_Found_in_the_Automox_Console_Mean.htm_ Throughout the Automox console, Automox relies heavily on status messages to indicate the current operating state of devices, policies, and agents. While these status messages indicate state, the underlying meaning of each one is not always clear. To provide more details, this section outlines the definition of each status message. ## Device Status You see several different states for your devices in the Automox platform. To convey this information, every device is assigned a **status** that indicates exactly how Automox is interacting with the device at any given time. | Device Status | Icon | Description | | --- | --- | --- | | Initializing | | This indicates that the device has successfully connected to Automox, but has not yet completed the first system scan. | | Installing | | This indicates that a patch is being installed. | | Uninstalling | | The device is currently uninstalling software, per a policy. | | Needs Restart | | The device has installed patches or software that require a restart before installation can be fully completed. | | Rebooting | | The device is rebooting. | | Refreshing | | The device is updating previously scanned software and hardware configurations or a worklet is being tested. | | Ready | | No command is impacting the device. | | Not Ready | | This status appears when the device is disconnected. | | Pending | | This status can indicate that a command is running on a device or that a worklet is executing on the device. | | Excluded From Reports | | This status indicates that the device is excluded from reports. | | Available Patches | | This status indicates that applicable patches have been detected, which are not necessarily associated with a scheduled policy. You can view these on the Device Details page under Software > Status. Search for Update Available. | **Note**: The **Last System Scan** can periodically be out of sync until the scanning process completes. The timestamp is updated when a scan is initiated and when it ends. ## Policy Status Besides the **Device Status**, policies assigned to the device also have their own statuses. These policy statuses indicate the current state of a given policy's evaluation and remediation steps. | Policy Status | Icon | Description | | --- | --- | --- | | Unmanaged | | No policy is associated with the device. | | Compliant | | Policies with a status of Compliant have no scheduled updates or failed remediations. | | Non-Compliant | | Policies with a status of Non-Compliant are either scheduled or have failed remediation. While the definition of "remediation" can differ depending on the policy type, this generally means that the policy has failed to successfully install new patches and manual intervention may be required. | | Scheduled | | A schedule is set for the policy. | ## Connection Status A device's connection status indicates whether the Automox agent installed on the device is communicating with the Automox API. While this status isn't a firm indication that something is wrong with the device, you can use it to determine how up-to-date the device's information is. | Connection Status | Icon | Description | | --- | --- | --- | | Connected | | A status of Connected indicates that the agent has checked in with the Automox API within the last two minutes. | | Disconnected | | A status of Disconnected indicates that the agent installed on a device hasn't checked in to the Automox API within the last two minutes. | ## Related Topics - [Device Details](../Device Management/Device_Details.htm) --- # Configuring Software on a Device _Section: Product Documentation › Device Management • Source: https://docs.automox.com/product/Content/Product%20Documentation/Device%20Management/Configuring_Software_on_a_Device.htm_ You can configure how to update software on your devices from the Device Details page. You can configure actions for individual or multiple software patches on a device. ## Configuring Individual Software Patches on a Device You can take the following actions to configure the software patches available on a device. 1. Go to the **Devices** page. 2. Click the name of the device to open the Device Details page. 3. From the Software section, you can use the **Filter** field to search for software. 4. Click the **Bulk Actions** drop-down list associated with the software. See the following table for details. **Note**: When you select an action, you must confirm any action selected. The following table describes the possible configuration actions you can apply to individual software. | Actions | Description | | --- | --- | | Roll Back | If available, this means you can downgrade the software selected. | | Patch | If a patch is available, select Patch Now to update to the available version. | | Ignore | This ignores any available updates. Note: Perform a scan on the device after selecting this option to ensure it is recorded on the device. | | Defer | If a version is available, select Defer and enter a date to resume the patch. | | Use Global Setting | The package patches in the next patch window for the policy that governs it. | ## Configuring Multiple Software Patches on a Device You can select an action that applies to multiple available software patches for a device. 1. Go to the **Devices** page. 2. Click the name of the device to open the **Device Details** page. 3. From the **Software** section, you can select the checkbox for multiple individual packages, or select all on the current page. 4. You can use the page selector to change the number of packages displayed on one page. The maximum number is 100. 5. Click the **Bulk Actions** drop-down list. Refer to the previous table for details about these actions. 6. Select the action to apply. In the actions message window, you can see a list of all packages selected for that action. Confirm your selection. 7. You can then apply this action to more packages by scrolling to the next page of packages. ## Related Topics - [Device Details](Device_Details.htm) --- # Device Details _Section: Product Documentation › Device Management • Source: https://docs.automox.com/product/Content/Product%20Documentation/Device%20Management/Device_Details.htm_ The **Device Details** page provides an organized inventory of data collected for individual devices. This updated experience introduces new categories of information and arranges them in a tabbed layout that includes Summary, Health, Hardware, Network, Security, Services, System, and Users. Each tab presents device-specific data to help administrators verify configuration, investigate issues, and take appropriate action. The page also includes options to restart a device, initiate a scan, delete the device, or run a policy. Notable changes include: - New tabbed structure for navigating device information - Significant expansion of available data points across all categories - Device Snapshot section for quick reference to system and network details This documentation describes how to access and use the Device Details page to review device data and perform management tasks. **Note**: The **Summary** tab is available on all Automox plans. Access to additional device information in the **Health**, **Hardware**, **Network**, **Security**, **Services**, **System**, and **Users** tabs requires a higher-level plan. As new data becomes available from the agent, it is automatically displayed on the applicable tabs. The Automox Platform and available plans are described here: [Automox Plans](https://www.automox.com/pricing) ## Viewing Details for a Device To view details for an individual device in your organization, follow these steps: ![](../../Resources/Images/device-name-hover.png) 1. Click **Devices** to view the list of devices for your organization. 2. Hover over the device name of the device that you want to view details for. If a custom name has been created for this device, you see that listed here. 3. Click the name to open the details view for that device. ## Taking Action on a Device You can take the following actions on a device from either the Devices page or the Device Details page. The available actions depend on which page you are viewing. ![](../../Resources/Images/device-details-controls.png) - **Remote Control**: Start a remote control session for the selected device (if enabled for your device). - **Refresh View** (Device Details page only): Reload the Device Details page to view the most current information without initiating a new scan. - **Restart**: Restart the device. You must confirm the action before it proceeds. - **Scan**: Run a scan to retrieve the latest status of the device. - **Delete Device**: Remove the device from Automox. **Note**: If you remove a device that is offline, when it checks in again it uninstalls. The status shows as uninstall pending. The **Last Restart** timestamp below the controls shows the date and time the device was last restarted. ## Device Details Fields The following describes the fields on the **Device Details** page. This includes the device status tiles, Device Information, Device Snapshot, Device Logs, Associated Policies, and Software. See also [Data Refresh Intervals](#Data) and [Data Availability Notes](#Data2). **Note**: For the Device Information, the **Summary** tab is available on all Automox plans. Access to additional device information in the **Health**, **Hardware**, **Network**, **Security**, **Services**, **System**, and **Users** tabs requires a higher-level plan. ## Device Status Tiles The status tiles provide immediate important information about the device. ![](../../Resources/Images/device-details-tiles.png) ### Agent Status The two possible agent status states are described here. | Status | Description | | --- | --- | | Healthy | This status indicates that all data points evaluated in the healthy data check have passed the health check. The device's data is complete, current, and consistent with expectations. | | Health Warning | This status appears when at least one inventoried data point from the healthy data check fails the health check. This can signal missing, outdated, or inconsistent data that requires review or remediation. See Health. | The Agent Status tile includes a **Last Disconnected** timestamp with information about the time the device was most recently disconnected from the network. ### Device Status The following lists the status of a device and the description for that status. | Status | Description | | --- | --- | | Initializing | This indicates that the device has successfully connected to Automox, but has not yet completed the first system scan. | | Installing | This indicates that a patch is being installed. | | Uninstalling | The device is currently uninstalling software, per a policy. | | Needs Restart | The device has installed patches or software that require a restart before installation can be fully completed. | | Rebooting | This appears when Automox restarts a system due to patching or when the administrator initiates a restart through the console. | | Refreshing | The device is updating previously scanned software and hardware configurations or a worklet is being tested. | | Ready | No command is impacting the device. | | Not Ready | This status appears when the device is disconnected. | | Pending | This status can indicate that a command is running on the device or that a worklet is executing on the device. | | Pending User Install | Indicates whether the device is currently in a pending state due to install notifications. Note:This requires that Agent version 2.1.x or later be installed on the device. | | Pending User Restart | Indicates whether the device is currently in a pending state due to restart notifications. Note:This requires that Agent version 2.1.x or later be installed on the device. | The Device Status tile includes a **Last Scanned** timestamp. --- # Device Explorer _Section: Product Documentation › Device Management • Source: https://docs.automox.com/product/Content/Product%20Documentation/Device%20Management/Device_Explorer.htm_ This document describes how you can create device queries in the **Device Explorer** using the **Device Query**. A query acts as a ruleset of criteria that filters devices based on selected attributes. From the main **Devices** page, select the **Device Explorer** tab. Initially, all devices in your organization are listed in the table. Use queries to filter this list of devices. From the **Device Explorer** page, you can create and save queries that filter devices into lists according to the criteria in the saved query. ![](../../Resources/Images/device-explorer.png) ## Device Query Use the **Device Query** to select conditions and values for the attributes that you want to filter your devices by. Each **criterion** consists of an attribute, a condition, and a value. You can add unlimited criteria to refine your results. The only limitation is that you can nest criteria **up to three levels deep**. Saved queries appear in the query selector, and you can reuse, duplicate, and amend them. The list of devices below the query updates as you work and can be exported to a CSV file. ### Creating a query Follow these steps to create a query. Refer to the **Attributes Reference** list for details about each attribute. 1. Open the **Attributes** drop-down list and select an attribute. This field is searchable and organized by scope. See [Attributes Reference](#Attribut) . 2. Select a **Condition**. The available conditions depend on the attribute selected. 3. In the **Value** field, enter a value or select from the available options, depending on the attribute. 4. Select **Add Criteria** to include additional attributes, as needed. 5. Use the operators **AND**, **OR**, and **NOT**, and apply **Subsets**, as needed. - **AND** lists devices where ALL the criteria specified are true. - **OR** lists devices where ANY of the criteria specified are true. - **NOT** lists devices where the criteria specified are NOT TRUE. 6. Select **Save Query**. Enter a unique name up to 64 characters in length. The new query appears in the **Saved Queries** selector. You can create a new query from an existing query. Open the query to use, modify the query as needed, and save using a unique name. ### Example queries Example of a CPU and IP address filter query: ![](../../Resources/Images/query-example-cpu.png) Example of an agent version query: ![](../../Resources/Images/query-example-agentversion.png) ### Deleting a query If you are creating a new query and want to start over, select **Clear All**. This resets all entries. To delete a saved query, open the query from the **Saved Queries** selector and select **Delete Query**. Confirm your selection. The query is removed from the **Saved Queries** selector. ### Viewing saved queries You can view a list of queries from the **Saved Queries** selector. Select the down arrow to open a list of all queries. If this list is empty, you have no saved queries. ![](../../Resources/Images/query-selector.png) ### Show or hide Query details You can hide the details of a query. To do this, select the arrow above the query details. When the query details are hidden, a number indicates how many criteria were used to create the query. Select the arrow to show the full details again. ![](../../Resources/Images/query-hide-details.png) ### Attributes reference The following tables list available scopes, attributes, and descriptions that you can use to create queries. #### About scopes Attributes are grouped into **scopes**. Each scope contains related attributes, and the scopes appear together in the **Attributes** drop-down list to help you locate an attribute more easily. Use the search capability of the Attribute field to search for the scope and attribute you are looking for. The available scopes are: **Devices**, **Disks**, **IP Address**, **NICS, Software**, and **Tags**. **Example:** Search for a Software-related attribute by starting to type out the name of the attribute you're searching for. The list filters down to allow for quick attribute identification. ![](../../Resources/Images/attribute-typeahead.png) #### Devices scope | Attribute | Description | | --- | --- | | Active Directory OU | Active directory organizational unit filter path, if configured | | Agent Version | Version of the Automox agent running on the device. | | Compatible | Device compatibility status with Automox. | | CPU | Model of the CPU. | | Custom Name | Name assigned to the device by the user. | | Date Added | When the device was first added to Automox. | | Device ID | ID of the device in the database | | Device Name | Permanent device name (hostname) | | Device UUID | Universally unique identifier for the device | | Disk | Disk partitions, file systems, and usage (JSON) | | Distinguished Name | Unique name for the device in your active directory - organizational unit | | Do Uninstall | Agent marked for uninstallation on next check-in | | FQDN | Fully qualified domain name | | Group ID | Group ID that the device is assigned to | | Group Name | Name of the group that the device is assigned to | | Instance ID | Cloud instance ID | | Last Disconnect Time | Last time device disconnected | | Last Refresh Time | Last time device refreshed. Update of the display information. | | Last Scan Failed | Last time device scan failed | | Last Update Time | Last update timestamp | | Last User Login | The name of the user who last logged in to the device | | Model | Type of computer | | Needs Restart | The device has installed patches or software that require a restart before installation can be fully completed. | | Next Check In Time | Next expected check-in | | Notes | Notes field | | OS | This is the OS type of the device, either macOS, Windows, or Linux | | OS Family | Operating system: Windows, Mac, or Linux | | OS Version | Operating system build number | | OS Version ID | OS version ID | | OS Version Language | OS language | | Outstanding Patch Age | Number of days a patch has been left unpatched | | Outstanding Patch Severity | Patch severity level | | Outstanding Patch Status | Whether a patch is available or not | | PowerShell Version | Version number of the installed build (Windows only) | | RAM | RAM in bytes | | Serial Number | Serial number for a device | | Service Tag | Tag number that comes from the manufacturer | | UTC Offset | Time offset of the device | | Vendor | Hardware vendor | #### Disks scope | Attribute | Description | | --- | --- | | Disk Available Space | Usable disk capacity after system-reserved space is deducted | | File System Type | File system type of installed storage drives | | Disk Free Space | Free disk space is the total amount of disk capacity that is not currently occupied by any file or directory | | Disk Name | Disk label that is a human-readable name for a partition | | Mount Point | Volume information with mount points (JSON - exact match only) | #### IP Address scope | Attribute | Description | | --- | --- | | IP Address | IP address assigned to the device | | IP Type | Type of IP address (private or public) | #### NICS scope | Attribute | Description | | --- | --- | | Device | Name of network interface controller | | MAC Address | Media access control address of the machine | | Interface Type | Type of network interface controller | | Vendor | Manufacturer | | Connected | NIC status | #### #### Software scope | Attribute | Description | | --- | --- | | Automox Supported | Packages that Automox can patch (also known as managed) | | Needs Restart | Software that requires a restart before installation can be fully completed. | | Severity | Severity level (critical, high, medium, low, no known CVE, none, unknown) | | Software Installation Status | Package display name - Auto-Complete | | Software Package Display Name | Package display name - Auto-Complete | | Software Package Name | Package name - Auto-Complete | | Software Package Repository | Package repository - Source of the software patch | | Software Package Version | Package version - Auto-Complete | | Software Uninstallable | Shows if the software can be uninstalled | #### Tags scope | Attribute | Description | | --- | --- | | Tags | User defined label assigned to a device | ### Conditions and Values Depending on the **attribute** you select, the **Condition** field shows only the operators that apply to that attribute. Conditions fall into the following groups. #### String comparison conditions These conditions evaluate text values. - Equal to - Not equal to - In - Matches - Starts with - Ends with - Is empty ![](../../Resources/Images/example-conditions-string.png) #### True or False conditions These conditions apply to attributes that accept a Boolean value. - Equal to - Not equal to #### Numeric, date, and version conditions These conditions apply to attributes that represent ordered values, such as numbers, timestamps, dates, or versions. - Equal to - Not equal to - In - Greater than - Greater than or equal to - Less than - Less than or equal to #### Values The **Value** field adjusts automatically depending on the attribute and condition. The following examples show how values can be selected or entered. **In (select multiple values)** Use **In** to include devices that match any of the selected values. ![](../../Resources/Images/example-condition-In.png) **Matches (select a single value)** Use **Matches** to include devices that match only the selected value. ![](../../Resources/Images/example-condition-Matches.png) **True or False** Attributes that accept a Boolean value display **True** and **False** as selectable options. ![](../../Resources/Images/example-condition-boolean.png) **Other value types** - **Pre-populated lists**: Typing in the Value field displays selectable matching values. - **Date picker**: Attributes that require a date allow you to type the date or select it from a calendar. - **Autocomplete fields**: For some attributes, suggestions appear as you type. - **Free-text or version values**: Some attributes accept manually entered text or version strings. ## Devices Table Results The devices table displays the results of the query defined in the Device Query section. If no query is set, the table lists all devices in the organization. - The Disks and Software columns will only show data in the Results table when an associated attribute is used in the query. - The Software, Disks, IP Address, and NICS columns show additional information on hover. ![](../../Resources/Images/software-hover.png) ![](../../Resources/Images/disk-hover.png) The devices table does not include a search field. Use the Device Query to refine results. ### Default columns By default, the devices table displays these columns: - Last User Login - OS - Agent Version - Device Name - Custom Name - Group Name This table also includes the following Actions: - Apply Tags - Remove Tags - Assign to Group - Delete Device ![](../../Resources/Images/device-table-actions.png) ### Show or hide columns The devices table has a default setting of data that can be changed. You can hide, show, and rearrange the columns of data in the list of devices. 1. Select **Columns** to see all available columns. 2. Drag and drop column names to reorder them. The table adjusts automatically. 3. Select or clear checkboxes to show or hide data. **Note:** Only visible columns appear in CSV exports. ## Device Summary Sidebar From the Devices table, you can select a device to view the device summary sidebar. You can view only one summary at a time. The sidebar provides a quick view of pertinent information about the device, offering a summary of what is available on the more detailed Device Details page. ![](../../Resources/Images/device-details-sidebar.png) Interacting with the sidebar: 1. Select the device's **checkbox** to open the summary. 2. View status and connection details about the device. 3. Select the device name or the arrow to open the Device Details page. 4. Review Available Patches: - This status indicates if applicable patches have been detected. Note that these might not be associated with a scheduled policy. - To view a list of available patches for a device, click the device name to open the Device Details page. Go to the Software section. The Status column lists any available patches. Search for **Update Available**. - It is recommended that you scan the device to ensure that this status is accurate. The information provided in this sidebar is an excerpt of the details provided on the current Device Details page. For more information about this data, see [Device Details](Device_Details.htm) . See also [What the Statuses Found in the Automox Console Mean](../Console Overview/What_the_Statuses_Found_in_the_Automox_Console_Mean.htm) . **Note**: The Export CSV does not include this sidebar status information. For details about the CSV file, see [Export the Device List to a CSV File](#Export) . ## Export the Device List to a CSV File You can export the results of any query by selecting the **Export CSV** button. This exported file only includes the devices from the results of the query . The data exported includes the following information (refer to the [Attributes Reference](#Attribut) for descriptions). Only columns shown in the table are included in the CSV export. | CSV Export | Attribute equivalent | | --- | --- | | agentVersion | Agent Version | | CPU | CPU | | createdAt | Date Added | | customName | Custom Name | | deviceUuid | Device UUID | | DISKS | Disk | | DISTINGUISHED_NAME | Distinguished Name | | FQDNS | FQDN | | ipAddrs | IP Address | | ipPrivateAddrs | Private IP Address | | lastLoggedInUser | Last User Login | | MODEL | Model | | name | Device Name | | NICS | NIC | | organizationalUnit | Active Directory OU | | osFamily | OS Family | | os | OS | | osVersion | OS Version | | PS_VERSION | PowerShell Version | | RAM | RAM | | serial | Serial Number | | serverGroup | Group ID | | serverGroupName | Group Name | | SERVICETAG | Service Tag | | VENDOR | Vendor | | VERSION | Version | ## Related Topics - [Managing Devices](Managing_Devices.htm) --- # Managing Exclusion Windows _Section: Product Documentation › Device Management • Source: https://docs.automox.com/product/Content/Product%20Documentation/Device%20Management/Exclusion_Windows.htm_ Exclusion windows allow administrators to define specific periods when Automox does not run tasks such as patching, policy execution, required software installation, or worklets on devices. By scheduling these controlled pauses, administrators can prevent restarts or other interruptions during critical business hours and maintain predictable maintenance behavior across devices. Each exclusion window includes configuration details such as its name, schedule type, duration, and associated device groups. You can create exclusion windows from the **Scheduled Windows** page, and edit or delete them from the **Exclusion Windows** page. **Prerequisites**: You must have **Full Administrator**, **Operational Administrator**, or a custom role with **Scheduled Windows**: **Create**, **Read**, **Modify**, or **Delete** permissions to manage exclusion windows. Other roles have Read-only access. See [Roles and Permissions Management](../Global Access Management/Roles_and_Permissions.htm). Exclusion windows apply to all policy types: Patch All, Severity, Patch Only, Manual Approval, Patch All Except, Advanced, as well as Worklets and Required Software policies. ## Creating an Exclusion Window You can create an exclusion window to prevent Automox from performing processes during a defined time period. **To create an exclusion window, follow these steps:** 1. Navigate to **Manage → Scheduled Windows**. 2. Select **Create Exclusion Window**. 3. In the **Details** section, complete the following fields: - **Exclusion Window Name**: Enter a descriptive name for the scheduled window. - **Notes**: Enter optional context or details about the purpose of the scheduled window. - **Status**: Select **Active** to enable the scheduled window, or **Inactive** to save it without applying it. 4. In the **Groups** section, select **Associate Groups** and assign one or more device groups. Automox does not run tasks on the devices in these groups during the scheduled time. 5. In the **Schedule** section, configure when the exclusion window takes effect: - **Recurring**: Select one or more **months**, **occurrences**, and **days**. For example, to create an exclusion window that occurs on the second Monday of June, select June, 2nd, and Mon. This setting applies to the second occurrence of Monday in the month, regardless of the calendar week. - **One time**: Specify a start date and time and an end date and time. - All times are displayed in UTC. 6. Under **Duration**, specify how long the exclusion window lasts. The duration cannot exceed the selected start and end times. 7. Review the **Device Preview** section to confirm which devices are included in the selected groups. You might need to scroll to view this table. See [Managing Devices](Managing_Devices.htm) for details of the devices table. 8. To save the exclusion window, click **Create Exclusion Window**. When an exclusion window is active, Automox prevents affected devices from running tasks during the defined time period. ## Editing an Exclusion Window You can update details, scheduling, or group associations for an existing exclusion window. **Note:** Before making any changes, check whether the exclusion window is in progress. Modifying an active window can cause scheduled policy runs to resume once the change takes effect. **To edit an exclusion window:** 1. Navigate to **Manage → Scheduled Windows**. 2. Select the name of the exclusion window you want to edit. 3. Update any necessary fields, such as **Status**, **Groups**, or **Schedule**. 4. Save the changes. ## Deleting an Exclusion Window You can remove exclusion windows that are no longer needed. **Note:** Before deleting an exclusion window, check whether it is in progress. Deleting an active window can cause scheduled policy runs to resume once the deletion takes effect. **To delete an exclusion window:** 1. Navigate to **Manage → Scheduled Windows**. 2. Select the name of the exclusion window you want to delete. 3. In the edit window click **Delete Window**. 4. A pop-up window shows any affected devices and their corresponding groups. Review the affected devices and, if you are sure, select **Delete Window**. 5. Another warning window allows you to make a final decision to delete it or not. Select **Cancel** or **Delete Window**. ## Manual Overrides You can override an active exclusion window if you have execution permissions. When you manually run a policy, worklet, or required software task during an active window, Automox displays a confirmation dialog warning that the task falls within the exclusion window. If you continue, the action is logged in both the Activity Log and the Policy Results Report as a manual bypass of the exclusion window. For Run Now / Fix Now, devices that are in an active exclusion window show as Unavailable. ## Related Topics - [Scheduled Windows](Scheduled_Windows.htm) - [Scheduled Windows FAQ](Scheduled_Windows_FAQ.htm) - [Automox University: Learn About Exclusion Windows](https://university.automox.com/scheduled-windows) --- # Filtering and Searching on the Devices Page _Section: Product Documentation › Device Management • Source: https://docs.automox.com/product/Content/Product%20Documentation/Device%20Management/Filtering_and_Searching_on_the_Devices_Page.htm_ You can use the devices filter panel and search bar to search for devices in your organization. From the **Devices** page, you can view a complete list of all the devices in your organization. Use the Devices filter panel on the left to filter for those devices that you are interested in seeing. With the enhanced device search at the top of the page, you can narrow down that filtered data even more using a partial matching search across multiple device fields. ![](../../Resources/Images/devices-overview-filter.png) **Note:**The search parameters you select are now stored in the page URL. The back button in your browser functions as expected and filter searches can now be bookmarked and shared. ## Device Filter Panel The filter panel includes options to fine-tune your search. When you select any of the individual filters, a number in parentheses shows how many are selected. You can clear selections individually, or select **Clear All**. The panel can also be collapsed. These settings are saved in the URL. When you navigate to other pages and return to the page, your settings are maintained. By default, this list shows all devices, including devices that are excluded from reporting. To hide these devices, uncheck the **Show Excluded From Reports**. See [Device Details](Device_Details.htm) for information about excluding devices from reporting. ![](../../Resources/Images/Default-view-shows-all.png) ## Device Status To filter the list of devices by device status, select from the following options available from the device filter panel. The resulting list of devices updates immediately when an option is selected. You can select from **Connected** or **Disconnected**, which are mutually exclusive options: | Status | Description | | --- | --- | | Connected | View only devices that are online and connected. You can view the current status and take actions on these devices. | | Disconnected | View only devices that are not connected. You cannot take any patching actions until these devices are connected again. | You can select from **Up To Date**, **Failed Update Attempts**, or **Scheduled**, which are mutually exclusive options: | Status | Description | | --- | --- | | Up To Date | View all devices with no other updates for the device. These are fully compliant, do not need attention, and have no other pending status conditions. | | Compliant | View all devices that are up-to-date based on their policy and schedule. | | Failed Update Attempts | View all devices that failed to successfully install new patches. Manual intervention might be required. | | Scheduled | View all devices that are awaiting a planned update (as per the policy details). | You can also select **Needs Attention**, or one or more of the Needs Attention subcategories (**Not Compatible, Needs Restart, Disconnected for 30+ Days**). This provides a more granular way to see which devices need attention, and for what reason. | Status | Description | | --- | --- | | Needs Attention | View all devices that have failed to patch for any reason. These devices might need manual intervention. | | Not Compatible | Use this to filter devices that do not pass the compatibility check. See the Troubleshooting section in Device Details for more information. | | Needs Restart | Use this to filter devices that need to be restarted. | | Disconnected for 30+ Days | Use this to filter devices that have been disconnected for 30 or more days. | The filter logic has been improved and now shows devices that meet one or more of the selected criteria, so you can get more clarity on the status of your devices. You can also select the following filter statuses to specify **Recently Added (Last 7 Days)**, or devices that are **Excluded from Reports**: | Status | Description | | --- | --- | | Recently Added (Last 7 Days) | View a list of all devices that were added within the last seven days. | | Excluded From Reports | View all devices that have been identified as "special" or to be excluded from reports (formerly "exception"). These can, for example, be devices used for testing or are legacy devices. These devices are not included in the reporting and metrics but continue to be managed. | ### Device Info To filter the list of devices by device name, tags, IP address, last logged in user or serial number, select from the **Device Info** drop-down menu. You can search by all filters concurrently. Searches allow partial matching. For example, you can enter `win` in the Hostname field to retrieve all devices that have that term in the hostname. | Device Info Category | Description | | --- | --- | | Hostname | Enter one or more search terms to retrieve results by hostname. This is not case sensitive. | | Tags | Enter one or more Tags to retrieve results by tag name. This field is not case sensitive. | | Last User Login | You can search by the login name of the user who last logged in to the device. | | IP Address | Enter one or more IP addresses to search by IP address. You can enter both public and private IP addresses. This searches only within the IP Address column. | | Serial Number | You can retrieve a list of devices by serial number. You must scan devices inside Automox before they are searchable. Multiple and partial entries are allowed. | ### OS You can set a filter to search for devices by OS. Select the **OS** drop-down menu. This filter offers different options: - Use the search bar above the list of OSes to find individual OS names. - Select the checkbox(es) to add the OS name from the search results. - Or, you can select the complete OS family. ### Policies 1. You can filter the list of devices by Policy. 2. Select the **Policies** drop-down menu. 3. (Optional) Enter the policy name in the search field to narrow down the list of policies. 4. Select the policy that you want to view a list of devices for. 5. To start a new search click the **x** next to the selected policy names or select **Clear All**at the top of the filter panel to clear all selected options. ### Groups You can filter the list of devices by Group. 1. Select the **Groups** drop-down menu. 2. (Optional) Enter the group name in the search field to narrow down the list of groups. 3. Select the group that you want to view a list of devices for. 4. To start a new search click the **x** next to the selected group names or select **Clear All** at the top of the filter panel to clear all selected options. ### Severity You can search for a device with an available software package that has a specific severity. The software package can be scheduled or unscheduled. By default, severity checkboxes are not selected. 1. Select the Severity drop-down menu. 2. Select one or more severities that you want to view a list of devices for. When you select multiple severities, it shows any matches. 3. To clear your search, clear the checkbox. To clear all filters currently set within the filter panel, click **Clear All** at the top of the filter panel. ### Vulnerability or CVE ID You can search for a device that has a specific vulnerability or CVE ID. You must enter a valid ID and a minimum of 6 characters. The list of devices automatically populates when an existing devices has a matching ID. To clear your search, click **x** next to the ID you entered. ### Hide/Show Filter Panel You can hide or show the Device filter panel by clicking the arrow. The filter panel shows by default. ![](../../Resources/Images/show-hide.png) ## Enhanced Device Search You can quickly narrow down data from the filtered search by using the search bar at the top of the Devices page. This enhanced search allows multiple queries and partial matching. This search does not show results outside of data results acquired from the device filter panel. ![](../../Resources/Images/device-search.png) This searches across multiple fields: - OS - Device Name - Group - Tags - IP address (public and private IP address search) - OS Version When you enter search criteria in the search bar, each entry appears in the search bar. To remove a query, click **x**. You can add as many search items as you want. The results will include any matching data and will not exclude other matches. ### IP Address Search From the Devices page, you can search for both public and private IP addresses. Multiple devices can be associated with the same public IP address. --- # Managing Devices _Section: Product Documentation › Device Management • Source: https://docs.automox.com/product/Content/Product%20Documentation/Device%20Management/Managing_Devices.htm_ From the **Devices** page, you can view your inventory, assign a device to a group, apply and remove tags, scan, restart, export details, and remove a device. ![](../../Resources/Images/devices-overview-filter.png) ## Viewing Device Inventory The following information is available from the Devices page: | Table Column | Description | | --- | --- | | Status | This column shows details about any status associated with a device. For example, it can show the last time a patch was processed, if the device is up-to-date, if a patch is scheduled, and if the device has been excluded from reports. | | OS | This is the OS type of the device, either macOS, Windows, or Linux, which is depicted with an icon. | | Device Name | This is the name that the device either assigns by default, or the name the user assigned to the individual device. Hover over the name of the device and click to open the detail view. See also Device Details. | | Disconnect Time | The date and time that a device last disconnected from the platform. Note: Sort using this column, with the oldest at the top, to identify decommissioned devices. You can then remove the devices from the console. | | Group | The associated group membership is displayed here. See also Managing Groups. | | Tags | Tags are optional. There is no character limit and no limit on the number of tags you can apply to a device. | | IP Address | IP address assigned to the device. Hover over an entry to show all associated addresses. | | OS Version | OS version currently installed on the device. | | Scheduled Patches | This shows if there are any scheduled patches for this device based on the patch policies. | | Needs Attention | This column shows devices that require action due to one or more of the following conditions: A new patch is detected, the device needs a restart to complete installation, or the device has not checked in for over 30 days. | | Device ID | This number is the same as the server ID. | | Disconnected For | The amount of time the device has been disconnected in days. | | Last User Login | The login name of the user who last logged in to the device. (Note: This is dependent on the last scan run on the device.) | | Active Directory OU | The active directory organizational unit filter path, if configured. | | Total Patches | This shows the total number of patches installed on the device. | | Agent Version | This field indicates what version of the Automox agent is running on the device.Note: This column does not show immediately for existing devices. Use the Columns button to show the agent version for all devices. | | Serial Number | This lists all serial numbers for the devices. This column is hidden by default. | | Date Added | The date and time that the device was added. Hover over the text to view in UTC. This column is hidden by default. | | Signing Certificate Status | This shows the status of certificates for the device. | | Pending User Install | Indicates whether the device is currently in a pending state due to install notifications. Note:This requires that Agent version 2.1.x or later be installed. | | Pending User Restart | Indicates whether the device is currently in a pending state due to restart notifications. Note:This requires that Agent version 2.1.x or later be installed. | | Actions | The actions you can take on a device are the same as the Actions button above the table. | --- # Managing Your Inventory _Section: Product Documentation › Device Management • Source: https://docs.automox.com/product/Content/Product%20Documentation/Device%20Management/Managing_Your_Inventory.htm_ After you install the Automox agent, you can manage and add to your inventory. ## Viewing Your Inventory You can view the full inventory and status of your devices from the **Devices** page. From the Devices page, you can do the following with any or all your devices. For details, see [Managing Groups](../Group Management/Managing_Groups.htm) and [Managing Devices](Managing_Devices.htm). - Assign a device to a group - Rescan - Restart - Export the listed device information to a CSV file - Remove devices from your inventory ## Adding Devices to Your Inventory You can add devices to your Automox inventory from the **Devices** page. Find out about adding Linux, macOS, and Windows devices to your inventory here. ### Adding Linux Devices You can use the command line method to add Linux devices. ![](../../Resources/Images/add-device-linux.png) 1. From the Devices page, click **Add Devices**. 2. In the modal that appears, select **Linux** from the OS options. 3. Copy the curl command and paste it into the terminal. 4. Run the command. 5. The agent is installed and you can view the new device from the Devices page of the Automox console. ### Adding macOS Devices You can add macOS devices by using either the command line method or the installer method. ![](../../Resources/Images/add-device-mac-cmd.png) 1. From the Devices page, click **Add Devices**. 2. In the modal that appears, select **macOS** from the OS options. 3. To use the command line method, from the Choose Install Option menu, click **Run Command**. 4. To use the installer method, from the Choose Install Option menu, click **Download Installer**. 5. The agent is installed. You can view the new device from the Devices page of the Automox console. ### Adding Windows Devices You can add Windows devices by using the installer method. ![](../../Resources/Images/add-device-win.png) 1. From the Devices page, click **Add Devices**. 2. In the modal that appears, select **Windows** from the OS options. 3. Click **Download Installer**. 4. The agent is installed. You can view the new device from the Devices page of the Automox console. ## Related Topics - [Use API to Get a Hardware Inventory of Your Organization](https://community.automox.com/automox-labs-8/use-api-to-get-a-hardware-inventory-of-your-organization-1399) --- # Scheduled Windows _Section: Product Documentation › Device Management • Source: https://docs.automox.com/product/Content/Product%20Documentation/Device%20Management/Scheduled_Windows.htm_ Use **Scheduled Windows** to control when Automox performs or pauses tasks on devices. This page lists all scheduled windows in your organization. You can currently schedule exclusion windows, which allow you to pause tasks such as patching, policy execution, or worklets. Navigate to **Manage → Scheduled Windows** to open the page. ![](../../Resources/Images/scheduled-windows.png) ## Viewing Scheduled Windows The Scheduled Windows page displays all current scheduled windows. You can view details, edit an existing scheduled window, or perform actions. Each scheduled window includes the following columns: - **Name**: The name of the scheduled window. - **Window Type**: The type of scheduled window, such as **Exclusion**. - **Schedule**: The defined schedule. - **Schedule Type**: Whether the scheduled window is **Recurring** or **One time**. - **Groups**: The number of device groups included in the scheduled window. - **Duration**: The length of time the scheduled window remains in effect. - **Status**: Indicates whether the scheduled window is **Active** or **Inactive**. ## Filtering and Searching on the Scheduled Windows Page The filter panel includes options to fine-tune your view and focus on specific scheduled windows. Filters let you view the windows that match selected criteria, such as group association, schedule type, or status. The panel shows selected counts, includes a **Clear All** option, and preserves your selections when you navigate away from the page and return later. You can use the following filters to narrow the list of scheduled windows: | Filter | What it filters by | | --- | --- | | Group | Scheduled windows that include the group or groups you select. | | Status | Scheduled windows that are configured as Active or Inactive. | | Schedule Type | Scheduled windows that are configured as Recurring or One time. | After applying filters, the table updates to display all scheduled windows that match your selected criteria. ## Table and Columns The table lists all scheduled windows. You can sort columns and customize which columns are displayed. - **Columns**: Select **Columns** to show or hide data, and drag column headers to reorder them. - **Sorting**: Select a column header to sort the list in ascending or descending order. ## Related Topics - [Managing Exclusion Windows](Exclusion_Windows.htm) - [Scheduled Windows FAQ](Scheduled_Windows_FAQ.htm) --- # Scheduled Windows FAQ _Section: Product Documentation › Device Management • Source: https://docs.automox.com/product/Content/Product%20Documentation/Device%20Management/Scheduled_Windows_FAQ.htm_ The following answers address common questions about how scheduled windows interact with policies, devices, and manual actions in Automox. You can currently create exclusion windows, and additional window types might be added in the future. What happens if a policy is scheduled during an exclusion window? If a policy’s scheduled run time falls within an active exclusion window, Automox prevents it from executing. The policy run is marked as **Blocked** in the **Policy Results Report** and logged as an **Activity** in the **Activity Log**, both displaying the reason identified as “scheduled within an exclusion window.” What happens if a policy starts before an exclusion window begins? If a policy or worklet has already started when an exclusion window begins, Automox allows the current task to complete but does not start new tasks until the window ends. The results show as **Partial Success** for the incomplete portions. Can I manually run a policy during an exclusion window? Yes. You can manually run a policy, worklet, or required software task during an active exclusion window if you have execution permissions. Automox displays a confirmation dialog before continuing. If you proceed, the action is logged in both the **Activity Log** and the **Policy Results Report** as a manual bypass of the exclusion window. Policy runs via Run Now / Fix Now cannot be run as a manual bypass of the exclusion window. Do exclusion windows apply to all policy types? Exclusion windows apply to all policy types: **Patch All**, **Severity**, **Patch Only**, **Manual Approval**, **Patch All Except**, **Advanced**, as well as **Worklets** and **Required Software** policies. Are tasks queued to start after an exclusion window ends? No. Tasks or policies scheduled during an exclusion window do not automatically run when the window ends. They wait for their next scheduled cycle. What happens if I edit an exclusion window while it is in progress? If you change an exclusion window that is currently in progress, your changes take effect immediately. Modifying an active window can cause scheduled policy runs to resume once the change takes effect. What happens if I delete an exclusion window that is in progress? Deleting an active exclusion window immediately removes its restrictions. Policies or other scheduled work that fall within that time period can run once the deletion takes effect. What time zone do exclusion windows use? All exclusion window times are currently displayed and scheduled in **UTC**. Recurring and one-time schedules both use this standard. What happens when an exclusion window activates while a policy is executing? - If the current package being installed is a third-party package, the installation completes and no further packages are installed. - If first-party updates are downloading but have not yet started installing, no first-party updates install. - If first-party packages have started installing, all first-party updates complete but no further packages are updated. - If a patch requires a restart, the device does not restart and remains in a **Needs Restart** state until the command is triggered again. ## Related Topics - [Managing Exclusion Windows](Exclusion_Windows.htm) - [Scheduled Windows](Scheduled_Windows.htm) --- # Automox FAQs _Section: Product Documentation › FAQs • Source: https://docs.automox.com/product/Content/Product%20Documentation/FAQs/Automox%20FAQs.htm_ ## What is Automox? Automox is the first cloud-based patching platform that fully automates the patch remediation process across Windows, macOS, Linux, and third-party software—including Adobe, Firefox, Chrome, and Windows. The platform works across both clients and servers. From “click, set, forget” automation, to complete scheduling and workflow control, Automox enables customers greater security, improved productivity, and radical time savings. Refer to these links to discover more: - [Automox](https://www.automox.com/) - [Automox Community](https://community.automox.com/) ## How is Automox Better than Simply Running Auto-Updates? Running auto updates is like taking your security policy and dividing it up among each of your employees; and hoping that they patch and maintain their individual systems. This is fine for individuals or small companies (10 employees or less) but for larger companies Auto Updates is more of a liability than a solution. What you DON’T GET with Auto Updates: - Almost every software has an update feature, making the process of updating software a constant nuisance for the IT manager and the end user. - No system outside of Automox combines all the OS and software updates into a single easy-to-manage dashboard. - Auto Updates does not give IT a central / single location for reporting on inventory, patch level, configuration settings, or compliance status. - Auto Updates provides no reporting or verification of device status, patches applied, or level of vulnerability. - Auto Updates is inconsistent and unable to force the user to update / install critical security releases. ## How Does Automox Work Behind the Scenes? You can think of Automox as a powerful policy-based engine that is constantly evaluating the state of a client or server and checking that state against a predefined policy. If the device or server is out of compliance with a policy, Automox executes a remediation action that brings the client or server back into compliance. Learn more on our [How It Works](https://www.automox.com/how-it-works) page. ## Where Do I Find Release Notes? Please refer to [Documentation Release Notes](../Release Notes/Documentation Release Notes/ReleaseNotesLP.htm) ## Does Automox Host Patch Repositories? Automox uses the OS vendor-supplied system update tool to determine which patches are available for a device and to apply those patches at the scheduled time. Automox does not host patch repositories on its servers. ## What Does the Automox Agent Access on a Device? The Automox agent has limited access to the device and is not natively capable of accessing or removing data or files from it. Compared with other tools like Airwatch and others that have control of the camera, access to the mic, and can intercept data in transit, that is not the intended functionality of Automox. Automox is not as invasive as other tools and can only add, update, and delete software and configuration settings. ## What Does End of Support for Windows Server 2008 R2 Mean to My Organization? The discontinuation of Windows Server 2008 R2 patch deployment means you stop seeing new patches every month. As long as vendors continue support for Windows Server 2008 R2, third-party patches, required software, and most Worklets will continue to apply and be relevant. If your organization has a need to continue using Windows Server R2, Microsoft offers Extended Security Updates on a per server basis. For more information, see their FAQ: [https://www.microsoft.com/en-us/cloud-platform/extended-security-updates](https://www.microsoft.com/en-us/cloud-platform/extended-security-updates) ## What Are My Payment Options? You can use your credit card to pay for your Automox plan directly in the console. To do this, go to the **Settings → Billing** tab. You must have the required user privileges to add this information. Currently, you cannot add ACH/check details in the console. If you prefer to pay using a Purchase Order, please contact your sales representative or email [Sales@automox.com](mailto:Sales@automox.com). ## Contacting Automox Support Contacting Automox Support is simple and expedient. A support engineer typically responds within an hour during business hours of 6 AM to 6 PM mountain time Monday through Friday. --- # Automox University _Section: Product Documentation › Getting Started • Source: https://docs.automox.com/product/Content/Product%20Documentation/Getting%20Started/Automox_University.htm_ Automox University (AXU) is a free on-demand training platform that contains a catalog of interactive courses and videos. AXU courses are short, easy to follow, and provide a comprehensive overview of Automox's features and functionality. You can start upskilling with the courses: - [Getting Started with Automox](https://university.automox.com/path/automox-onboarding-the-basics) - [Removing Software Using Worklets](https://university.automox.com/removing-software-using-worklets) - [Best Practices for Third-Party Patching](https://university.automox.com/third-party-patch-policies) - [Remote Control](https://university.automox.com/remote-control) Here are some of the benefits of using Automox University: **Available to all new, existing, and prospective customers.** Interactive courses and videos in Automox University are available to new, existing, and prospective customers regardless of your subscription plan. **Learn at your own pace.** Automox University’s on-demand course offerings enable you to learn when it’s convenient for you. **Keep up-to-date with new features.** Automox University consistently releases new courses so you can stay up-to-date on the latest features and functionality. Check out [Automox University](https://university.automox.com/) today and sign up for courses using your company email. ![](../../Resources/Images/axu-home.png) --- # Navigating the Automox Console _Section: Product Documentation › Getting Started • Source: https://docs.automox.com/product/Content/Product%20Documentation/Getting%20Started/Navigating%20the%20Automox%20Console.htm_ This guide introduces the structure of the Automox console and explains how to find key functionality using the top navigation tabs: **Dashboard**, **Devices**, **Automate**, **Manage**, **Insights**, and the per-organization **Settings** menu. It also explains how to access the **Global View**, which provides centralized account and user management across all organizations. Use this guide as a reference when other articles refer to filters, navigation paths, or role-based access. This centralized explanation ensures those elements are documented in one place. **Note:** The options and features visible in the console depend on your account-level or global-level permissions. See [Roles and Permissions Management.](../Global Access Management/Roles_and_Permissions.htm) ## Console Overview The Automox console uses a horizontal top navigation bar. Each top-level tab opens a corresponding page and may display subcategories within the main content area. The animation illustrates these subcategories. For details about accessing organization settings and the Global View, see [Accessing Settings and Global View](#Accessin). ![Animated overview showing each top-level tab and the sub-areas it opens](../../Resources/Images/nav-overview.gif) | Top-Level Tab | What You Can Access | | --- | --- | | Dashboard | Device and policy status, outstanding patches, chronological scrollable list of scheduled policies | | Devices | Device inventory, Device Details, Device Logs, and Device Explorer | | Automate | Policies, Worklet Catalog, and Remediations | | Manage | Groups, Software, Manual Approvals, and Scheduled Windows | | Insights | Analytics dashboards and Reports | ## Dashboard The **Dashboard** is the default landing page in the Automox console. It provides a summary of device and policy status, outstanding patches, a chronological scrollable list of scheduled policies, and quick access to troubleshooting resources. For details about the dashboard, see [Automox Console Dashboard](../Console Overview/Automox Console Dashboard.htm). ## Devices Tab Use the **Devices** tab to access the **Devices** page, **Device Details**, and **Device Explorer**. ### Devices Page The **Devices** page lists all devices in your organization. From this page, you can view device status, apply filters or search terms to refine results, initiate scans or restarts, and open individual device details for more information. See [Managing Devices](../Device Management/Managing_Devices.htm). ![Automox Devices page with numbered callouts identifying navigation and interface elements](../../Resources/Images/devices-overview.png) The following numbers correspond to the elements highlighted in the image: 1. **Page tabs**: Access the All Devices view or the Device Explorer. 2. **Filter panel**: Filter devices by properties such as status, OS, or severity. 3. **Table toolbar**: Search, export, and manage visible data. ### Device Details The **Device Details** view provides comprehensive information about a single device. Depending on your plan, this page includes device inventory details such as kernel status, operating system version, device drivers, update settings, and configuration information. For more information, see [Device Details](../Device Management/Device_Details.htm). ![](../../Resources/Images/nav-device-details.png) Each Device Details page also includes a **Device Snapshot** section that summarizes key information such as operating system, agent version, and last check-in time. From the same page, you can also access **Device Logs**, which provide recent activity details from device scans. ### Device Explorer The **Device Explorer** is a separate view available under the Devices tab. It allows you to create and run queries that filter devices based on selected attributes. Each query acts as a reusable ruleset for targeting devices that meet specific criteria. For more information, see [Device Explorer](../Device Management/Device_Explorer.htm). ![](../../Resources/Images/nav-device-explorer.png) ## Manage Tab Use the **Manage** tab to access groups, software, manual approvals, and scheduled windows. - **Groups**: Define group membership for targeting policies - **Software**: View and search for software installed across devices - **Manual Approvals**: Approve or reject policies awaiting admin input - **Scheduled Windows**: Control when Automox performs or pauses tasks on devices For more information about these areas, see [Managing Groups](../Group Management/Managing_Groups.htm), [Viewing Software Inventory](../Software/Viewing_Software_Inventory.htm), [Using a Manual Approval Policy](../Patching/Using_a_Manual_Approval_Policy.htm), and Scheduled Windows. ## Insights Tab Use the **Insights** tab to access analytics dashboards and reports. - **Analytics**: Measure patching progress, identify security gaps, and view data-driven insights across your devices - **Reports**: Access prebuilt reports to review operational trends and device management data For more information about analytics and reporting, see [Analytics](../Automox Reports/Analytics.htm) and [Creating Reports](../Automox Reports/Creating_Reports.htm). ## Filtering and Search Filter panels and search fields appear throughout the Automox console to help refine visible data. ### Filter Panels Filter panels appear on the **left side** of pages like Devices, Software, and Policies. The following are examples of what you might filter data by: - Device information such as IP address - Operating system (OS) - Severity - Groups - Status When you select a filter, the number of selected items appears in parentheses. Further options are: - Clear individual filters or use **Clear All** - Collapse the filter panel to save space - Maintain filters when navigating away and returning. Settings are generally saved in the URL. ### Search Fields Search bars appear above tables and update results in real time. Here are some examples of what you can search by: - Device name - Tag - Policy name - Software title Search supports partial string matches and works alongside filters. ## Customizing Table Columns Many pages in the Automox console include a **Columns** button that lets you control which data appears in tables. ![](../../Resources/Images/manage-columns.gif) To customize columns: - Click the **Columns** button above the table - Select or deselect checkboxes to show or hide specific columns - Drag and drop column names to rearrange the order To view off-screen data, use the horizontal scroll bar at the bottom of the table. You can also scroll using the arrow keys on your keyboard. ## Sorting Tables Most tables in the Automox console allow you to sort data by clicking the arrow next to the column header. Each click toggles between ascending and descending order. Sorting updates the visible data but does not affect any applied filters or searches. ![](../../Resources/Images/sort.png) ## Exporting Data Many pages in the Automox console include an **Export CSV** option that allows you to download data for external review or reporting. You can export table data from the **Devices** page, **Device Explorer**, **Software**, **Activity Log**, and **Policy Results Report**. Some pages also include options to export data in other formats, such as PDF. ## Accessing Settings and Global View The Automox console includes both organization-level and account-level settings, which you can access from the upper-right corner of the console. The options available to you depend on your account-level or global-level permissions. ### Organization Settings To access per-organization settings, locate the settings icon in the upper-right corner of the console. ![](../../Resources/Images/settings-menu.png) 1. Click the **three vertical dots icon (⋮)** in the upper-right corner. 2. From here you can select from the list: **Profile**, **Agent**, **Billing**, **Users**, **Secrets & Keys**, **Script Signing**, **Security**, and **Logout**. This opens the Settings page to the selected tab. These settings apply only to the selected organization. ### Global View (Global Access Management) The **Global View** provides centralized account-level administration for Automox users who are managing one or more organizations from the **Setup & Configuration** page. Access to the Global View depends on your account-level or global-level permissions. ![](../../Resources/Images/global-view-access.png) To access Global View: 1. Click the **organization selector** in the upper-right corner. 2. Select **Manage Orgs and Users** to open the Setup & Configuration page. 3. From here you can select from the tabs: **Keys**, **Organizations**, **Roles & Permissions**, **Users**, and **Settings**. ## Quick Reference: Where to Find Key Features Use this table to locate common tasks in the Automox console. | Task | Where to Go | | --- | --- | | Add and manage devices | Devices | | Create or manage policies | Automate → Policies | | Use or browse Worklets | Automate → Worklet Catalog | | Manually approve policy actions | Manage → Manual Approvals | | Create or manage exclusion windows | Manage → Scheduled Windows | | View analytics dashboards | Insights → Analytics | | Export reports | Insights → Reports | | Access organization settings and details | Settings (⋮) icon → Select an option from the drop-down menu | | Manage organizations and users globally | Global View → Manage Orgs and Users | ## Related Topics - [Automox Console Dashboard](../Console Overview/Automox Console Dashboard.htm) - [Roles and Permissions Management](../Global Access Management/Roles_and_Permissions.htm) --- # Onboarding Jumpstart Guide - Manage Your Environment _Section: Product Documentation › Getting Started • Source: https://docs.automox.com/product/Content/Product%20Documentation/Getting%20Started/Onboarding_Jumpstart_Guide___Manage_Your_Environment.htm_ ## Overview As you begin to organize your new Automox account and organization Each company account has its own unique challenges, and there is no one-plan-fits-all solution. This guide provides you with resources and recommendations to help you define the best use of Automox for your company. ## Automox Documentation Automox has created content in several different formats. Here are the primary links to find that information and documentation: - Automox Home: [Automated Patch Management + Better Cyber Hygiene](https://www.automox.com/) - Automox Help Center: [https://help.automox.com](https://help.automox.com/) - Product and User Documentation: [https://docs.automox.com](https://docs.automox.com/) - Developer Documentation: [Automox Developer Documentation](../../Developer/Developer LP.htm) - API: [Automox API Reference](../../Developer/Automox API Reference.htm) - Blog: [The Automox Blog](https://automox.com/blog) - Webinars: [Automox Webinars](https://patch.automox.com/videos) - Quick Start Guide: [Learn the Basics in Minutes](https://help.automox.com/hc/en-us/articles/5352274607892) - Automox Community: [Community for Automox users](https://community.automox.com/) ## Console Overview The console is your primary user interface to interact with Automox. You might have already explored the console during your trial and initial setup. Due to the intuitive and ease of use of the console’s design, this section provides resources for additional information and detail rather than a detailed walkthrough. ### Link to console - [Console login](https://console.automox.com/) ### Dashboard This is your landing page in the console. You can find an overview of your environment and links to actions that might interest you to manage your organization ### Devices - Device Filter Panel: Search, sort, and filter devices. See [Filtering and Searching on the Devices Page](../Device Management/Filtering_and_Searching_on_the_Devices_Page.htm) - Device Details and Status. See [Device Details](../Device Management/Device_Details.htm) - Device queries: See [Device Explorer](../Device Management/Device_Explorer.htm) - [What the Statuses Found in the Automox Console Mean](../Console Overview/What_the_Statuses_Found_in_the_Automox_Console_Mean.htm) - Manage group placement, view/export inventory, scan/restart/remove devices. See [Managing Devices](../Device Management/Managing_Devices.htm) - [Viewing Software Inventory](../Software/Viewing_Software_Inventory.htm) - [Automox Compliance](../Console Overview/Automox_Compliance.htm) ### Automate This is where policies, Worklet Catalog, and remediations are managed. (These topics are discussed again later in the document and/or document series.) ### Manage This is where you manage groups, software, and manual approvals. (These topics are discussed again later in the document and/or document series.) ### Insights Under Insights, you can find Automox Analytics for pre-built risk and mitigation reporting. - [Analytics](../Automox Reports/Analytics.htm) Reports includes the following descriptions of reports and how to export data from the console: - [Creating Reports](../Automox Reports/Creating_Reports.htm) - [Policy Results Report](../Automox Reports/Policy_Results_Report.htm) - [Data Extracts](../Automox Reports/Data_Extracts.htm) ### Software This section provides topics with tips and links related to the Software page. #### Filtering and Searching - [Filtering and Searching on the Software Page](../Software/Filtering_and_Searching_on_the_Software_Page.htm) #### Exclusions/blocklist - [Adding Patches to the Block List in the Automox Console](../Miscellaneous/Adding_Patches_to_the_Block_List_in_the_Automox_Console.htm) - Some columns contain drill-down links or additional information when you click them. As an example, some items in the **Severity** column are blue. If you click on them, a related CVE number appears. - If you click the blue number under the **Impacted** or **Updated** column, you see a list of devices that have available updates or have already applied that patch. You can export these lists. #### Software Info - Automox scans for software listed here in addition to a few unique paths for the third-party software supported by Automox (for example: Zoom, OneDrive) - **macOS** - /Applications/*.app - /Applications/**/*.app - /System/Applications/*.app - /System/Applications/**/*.app - **Windows** - HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall\* - HKEY_LOCAL_MACHINE\Software\wow6432node\Microsoft\Windows\CurrentVersion\Uninstall\*. - Program Files - Program Files (x86) - **Linux** - Query the package manager using the appropriate language for OS. - dnf/yum - Aptitude - zypper #### Settings - [Settings Overview](../Settings/Settings_Overview.htm) - **Profile:** Manage your user information, password, and notifications (email or Slack) If you forget your password, you can reset it from the console login page. Enter your email address and you see a link to reset your password: [Resetting Your Password](../Console Overview/Resetting_Your_Password.htm) - **Secrets & Keys - API:**see [Managing Organization Keys](../Settings/Managing_Keys.htm) - API key access rights are based on the account the key is created for. It allows the same rights as the user assigned role. You can limit the available actions an API key can make by generating a key for a user assigned the appropriate role. As an example, use a key generated for a read-only user to collect report details. This key does not allow the user to make changes in the environment. - You can only create a new API key for yourself. You can manage API keys (enable, disable, or delete) if you are a Full Administrator or have a custom role with Organization: Read and Manage permissions. - **[Security](../Settings/Security.htm)****:** Two-factor Authentication, Define Login Attempts, and SAML. See [Multi-Organization SAML Single Sign-On](../Console Overview/Multi_Organization_SAML_Single_Sign_On.htm). Request Automox support from the [Automox Help Center](https://help.automox.com/hc/en-us). After you register, you can select **Submit a request**. In the console you can also click the **?** to view resources such as our Help Center and Community. | System Requirements | Automox Agent Requirements Windows The built-in Windows Update Agent \ Service must be healthy and enabled. .NET Framework 3.51 or later PowerShell 5.1 or later x86 and x64 based processor (ARM processors supported for Windows 11 with agent version ≥ 2.3.35) | | --- | --- | | Environmental Considerations | Globally Trust-listing Automox Through EPP Application Control Local agent and log directories are useful for configuring antivirus rules. See Location of Files Required By Automox To ensure uninterrupted functionality, please consider if EPP (endpoint protection platform)/antivirus rules are required in your environment. Customize Script Execution Location: This is useful if you need to control where processes run on your devices. Change Automox Script Execution Location Update Sources: Each managed device requires access to all update sources when scans and policies run. Notable update sources are:Windows Update sitesWSUS (if used in your environment)See list of Internet URLs in the Miscellaneous → Important URLS (for firewall and routing rules) section at the end of this document for a more detailed list of URLs to allow access. Firewall considerations All managed systems require access (and potential defined routing) to api.automox.com port 443IP addresses for the API change often and dynamically. If an IP address list is required by your company, the following article provides a suggestion about how to identify the current list. Make sure to keep firewall exceptions up-to-date.Uploaded content for required applications or Worklets is stored in Amazon S3. A rule should be configured to allow access to automox-policy-files.s3.us-west-2.amazonaws.comSee Agent Firewall Allowlisting Rules Important URLS (for firewall and routing rules) Proxy and routing. See Using the Automox Agent With a Proxy Server Starting with agent version 29, Windows automatically identifies proxy settings if they are set per the current user or set for the system. Devices behind a proxy may need a route to be configured (for example, pac file or proxy application permissions). Add routing, if needed. Ubuntu and CentOS (Debian and YUM) Proxy configurationAdjust /etc/init.d/amagent daemon by adding the following settings if missing just after the variable definitions: # PATH should only include /usr/* if it runs after the mountnfs.sh script PATH=/sbin:/usr/sbin:/bin:/usr/bin DESC="Automox agent" NAME=amagent DAEMON=/opt/amagent/amagent DAEMON_ARGS="" PIDFILE=/var/run/$NAME.pid # Proxy settings export HTTP_PROXY="Proxy server" export HTTPS_PROXY="PROXY server" # Exit if the package is not installed [ -x "$DAEMON" ] || exit 0 | | Agent Installation | Where to find the agent: Download Links for the Latest Automox InstallersInstallation Methods: Here are several examples including manual installation, bulk deployments, group policies, and use of automation tools to get your agents deployed. Bulk agent installation options (includes command lines for each OS): Deploying the Automox Agent in Bulk GPO options: Deploy the Latest Automox Agent using a PowerShell Script via Windows GPO Policy Windows installation tips:Modify the MSI to include your access keyEmbedding Your Access Key into the Automox MSIWindows silent install switchesSilent Agent Deployment on Windows Linux: Installing the Automox Agent on Linux Intune: Example of how to configure a msi line-of-business app | | Agent: Various topics | Move device to another organization: Moving Devices From One Organization to Another Removing the Automox Agent: Removing the Agent Using the Console (Recommended)Manual agent removal instructions in article above (best practice, remove from console) How to Create a Gold Image VM If you apply your image with a step-by-step or scripted process, consider disabling the Automox agent in your image and later enabling it in your deployment process when you are ready for Automox to become active. | | Troubleshooting | Agent Initialization: Cert (Unknown Authority): Agent Error: x.509 Certificate Signed By Unknown Authority macOS: Troubleshooting the Automox Agent Installation on macOS Tips for troubleshooting agent installation: See Location of Files Required By Automox. You can review the amagent.log to help identify a cause for agent initialization issues.Check the Device Status, Connection Status and the Troubleshooting section of the device details in the console. This can help detect issues with the following: Connection to the API, identify if a restart is needed, identify low disk space (less than 3 GB), and if patch source is unreachable.If you deregister an agent manually, ensure you do it as an administrator. If you run it without administrator rights, it can orphan the agent certificate. | ## Groups You can arrange groups by department, geography, or whatever makes sense for your organization. You can use groups to efficiently manage patching, required software, and Worklet policies across your devices. You also use groups to define scan interval, and OS Patch Management configurations. Refer to the following: - [Managing Groups](../Group Management/Managing_Groups.htm) - [Searching and Filtering for an Individual Policy or Group](../Policy & Group Interactions/Searching_and_Filtering_for_an_Individual_Policy_or_Group.htm) Here are some helpful group management tips: - This is a prime opportunity for you to simplify your administration tasks by applying a functional group structure. Groups can be based on OS, Test/Production, or a business case such as organization administration or location and department. - Parent groups are for organizational purposes ONLY. - Policies are not inherited based on group hierarchy/structure. Policies must be directly assigned to each group where you want it to be applied. - Use a predetermined naming convention for your groups and policies to get quick views of relevant objects. If you search for Worklet, Patch, or Required in the policies filter, it will filter to that type of policy. - You can use the Windows PowerShell bulk installer script to automatically add devices to a specific group at agent installation time. ### Scan - Scans evaluate the status of your device and return hardware, software, and patch inventory. A scan returns the compliance state for Patch, Required Software, and Worklet policies assigned to the group. Scans also check if a restart is needed. - Scan Interval - You can set the scan interval per group from 6–24 hours (default is 24 hours). - Groups - Best Practices - Define your scan interval - In most cases, setting the scan interval to 24 hours is ideal. This returns policy compliance and inventory 1 time per day. - If you are onboarding and bringing your devices up to a current patch compliance state, you might want to shorten the scan interval temporarily for a current group-level compliance view. - Automox best practice: - Scan Interval - 24 hours* * If you have a reason to shorten the time, then set this based on your needs. A scan runs after each policy runs. ### Set your OS Patch Management Settings The OS Patch Management settings are key in controlling your patching process. Take a moment to consider these settings and configure them appropriately. This is one of the Automox configurations that may help shape your group structure. See [OS Patch Management Settings for Groups](../Group Management/OS_Patch_Management_Settings_for_Groups.htm). #### Automox Best Practice - **Windows and macOS Patch Management - Disable OS automatic updates** This option prevents the device from automatically installing updates outside of your defined patch policies. Your patch policy defines when the device will pull updates from Microsoft Updates (or WSUS) and what patches to install. - **Windows Update Source - Windows Update - or - WSUS** - **If the devices in this group do not download content from a local WSUS server, set this to Windows Update.** ![](../../Resources/Images/patch-mgmt-winupdate.png) **Note**: This is the Automox Best Practice - If the devices in this group leverage a local WSUS server, set this to **WSUS** and enter your WSUS server address (for example, http://myserver.com:8530). ![](../../Resources/Images/patch-mgmt-wsus.png) #### Manage non-Automox patch configurations #### GPOs - Remove settings or set to “Not Configured” - Behavior: - Automox applies OS Patch Management settings when a scan runs. - GPOs apply based on the policy refresh settings (default every 90 minutes). - If they are set differently, your device WU agent might toggle patch source and potentially download content at unexpected times. - Allow Automox to manage the WU settings when you are managing patching through Automox. #### Default Group - Automox assigns all new devices to the Default group. Defining the settings and policies targeting the Default group can add to your device management strategy. Here are a few concepts for the Default group configuration. **Note**: Policy overview and best practices provided in the Worklet and Patching Jumpstart guides. #### Scenario 1 - Soft Landing - Intent - Get the agent installed, but don’t enforce any changes until the device is moved to its proper management group. - Suggested settings: OS Patch Management - Windows and macOS Patch Management - Keep Device’s Setting - Windows Update Source - Keep Device’s Setting - Policy Assignment: None - Outcome: When the agent initializes and the object is added to the Default group, the device settings remain unmanaged. The devices can then be moved into another group, which will define the patch setting and become managed based on the policies assigned to the new group. #### Scenario 2 - Standardize - Intent - Bring devices to a known standardized state as the devices are added to Automox management. This is ideal for a managed new computer setup, but without a current user. - Suggested settings: OS Patch Management - Windows and macOS Patch Management - Disable OS automatic updates - Windows Update Source - Windows Update (or alternatively WSUS with defined WSUS server address) - Policy Assignment: - Assign Patch policies with the **Schedule** → **Select All** checkbox selected, the missed patch window (If a device misses a configured patch time, it will patch the next time the device checks in.) checkbox selected, and **Automatic Restart** enabled. - (Optional) Create multiple Patch policies as defined above and schedule every few hours. - Assign Required Software and Worklet policies to install line of business applications and configure your device to bring your device to standard - Outcome: Device patch settings are configured for Automox management. Patch state is brought to current, and required configurations and software are installed when devices are added to the Automox environment. #### Group Structure Groups provide two primary functions and one major setting. - They provide an organizational structure for your devices. - They provide a way to organize policy assignments. - The OS Patch Management Settings define your patch source. - Automox is built with simplicity in mind. This should motivate you to build your group structure in a way that simplifies your administration when using Automox to manage your devices. **Tips for group structures**: - Policies are not inherited through parent groups, although the policy assignment is per group. Use this to help determine your hierarchy. - Groups are sorted alphabetically by hierarchy. A naming convention will help with organization. #### Group Structure Examples #### Scenario 1 - Simplified Group Structure - This scenario is ideal for simplifying administrative tasks. You can place all OS versions in the same groups because only the proper policies apply. Here you can control your deployment times and verify deployments to pilot groups prior to production. The server groups demonstrate a way to separate your systems by a maintenance window based on your environmental needs. ## Miscellaneous - [Documentation Release Notes](../Release Notes/Documentation Release Notes/ReleaseNotesLP.htm) - [Automox Status Board](../Miscellaneous/Automox_Status_Board.htm): Operational status board for Automox services - **RSS Feed**: [https://status.automox.us/history.rss](https://status.automox.us/history.rss) ## Important URLS (for firewall and routing rules) ### Windows URLs (TCP/80-443) http://microsoft.com windowsupdate.com nsatc.net phicdn.net http://windows.com ### All Windows updates URLs *.delivery.dsp.mp.microsoft.com.nsatc.net *.dl.delivery.mp.microsoft.com* *.wac.phicdn.net *.windowsupdate.com* *dsp.mp.microsoft.com *dsp.mp.microsoft.com.nsatc.net *emdl.ws.microsoft.com* *geo-prod.do.dsp.mp.microsoft.com* *prod.do.dsp.mp.microsoft.com* *wac.phicdn.net* *windowsupdate.com* au.download.windowsupdate.com* cs9.wac.phicdn.net download.windowsupdate.com* fe2.update.microsoft.com* fe3.*.mp.microsoft.com.* fe3.delivery.dsp.mp.microsoft.com.nsatc.net fe3.delivery.mp.microsoft.com* fe3cr.delivery.mp.microsoft.com fe2cr.update.microsoft.com v10.events.data.microsoft.com v20.events.data.microsoft.com fe3.update.microsoft.com geo-prod.do.dsp.mp.microsoft.com sls.update.microsoft.com* sls.update.microsoft.com* slscr.update.microsoft.com slscr.update.microsoft.com* Tsfe.trafficshaping.dsp.mp.microsoft.com sls.update.microsoft.com fe2.update.microsoft.com fe3.delivery.mp.microsoft.com au.download.windowsupdate.com sls.update.microsoft.com.nsatc.net fe2.update.microsoft.com.nsatc.net fe3.delivery.dsp.mp.microsoft.com.nsatc.net audownload.windowsupdate.nsatc.net ### Delivery Optimization (DO) URLs for Split-Tunneling VPN [Delivery Optimization for Windows 10 updates - Windows Deployment](https://docs.microsoft.com/en-us/windows/deployment/update/waas-delivery-optimization) From this Microsoft solutions content, you can find further relevant URLs under the following sections: - Delivery Optimization service endpoint: - https://*.prod.do.dsp.mp.microsoft.com - Delivery Optimization metadata: - http://emdl.ws.microsoft.com - http://*.dl.delivery.mp.microsoft.com - Windows Update and Microsoft Store backend services and Windows Update and Microsoft Store payloads: - http://*.windowsupdate.com - https://*.delivery.mp.microsoft.com - https://*.update.microsoft.com ## Related Topics - [Onboarding Jumpstart Guide - Patching](Onboarding_Jumpstart_Guide___Patching.htm) - [Onboarding Jumpstart Guide - Worklets and Required Software](Onboarding_Jumpstart_Guide___Worklets_and_Required_Software.htm) --- # Onboarding Jumpstart Guide - Patching _Section: Product Documentation › Getting Started • Source: https://docs.automox.com/product/Content/Product%20Documentation/Getting%20Started/Onboarding_Jumpstart_Guide___Patching.htm_ As you begin to build out your new Automox Each organization has its own unique challenges, and there is no one-plan-fits-all solution. This guide provides you with resources and recommendations to help you define the best use of Automox ## Policy Overview - View and Create Policies ### Managing Policies Types of Patch Policies: - Patch All - Patch All Except - Patch Only - Manual Approval - [Using a Manual Approval Policy](../Patching/Using_a_Manual_Approval_Policy.htm) - Severity - [Understanding Automox Severity Data](../Patching/Understanding_Automox_Severity_Data.htm) - [Patching When the Severity Level Is Unknown](../Patching/Patching_When_the_Severity_Level_Is_Unknown.htm) - Advanced Policy - [Using the Advanced Patch Policy](../Patching/Using_the_Advanced_Patch_Policy.htm) ## Notifications and Restarts Windows and macOS patch policies have restart and notification functionality built-in. See [End-User Notifications](../Notifications & Restarts/End_User_Notifications.htm) for the latest. ### Notifications #### macOS - [Allowing Automox Notifications in macOS (Starting with Catalina)](../Notifications & Restarts/Allowing_Automox_Notifications_in_macOS__Starting_with_Catalina_.htm) To reset event notifications manually, use the following command: `sudo tccutil reset AppleEvents` - [macOS Privacy Preferences - amagent wants access to control Microsoft AutoUpdate](../Notifications & Restarts/macOS_Privacy_Preferences___amagent_wants_access_to_control_Microsoft_AutoUpdate.htm) If the amagent is not allowed to control Microsoft AutoUpdate, the latest version in the console is empty and does not automatically update. - [macOS Privacy Preferences - amagent wants access to control Microsoft AutoUpdate](../Notifications & Restarts/macOS_Privacy_Preferences___amagent_wants_access_to_control_Microsoft_AutoUpdate.htm) [Automox Tray and End-User Notifications FAQ](../Notifications & Restarts/Automox Tray FAQ.htm) - If Automox restarts on a BitLocker managed device, BitLocker is bypassed for the managed restart. - Notifications are currently not supported on Linux systems. ## Third-Party Software Updates - [Third-Party Software Support](../Third-Party Software/Third_Party_Software_Support.htm) - [Third-Party Patching Best Practices](../Third-Party Software/Third_Party_Patching_Best_Practices.htm) - [Naming Scheme for Third-Party Software Packages](../Third-Party Software/Naming_Scheme_for_Third_Party_Software_Packages.htm) ## Patch Status Status icons and messages found in the console can be helpful when checking into device health, connection status, or the state of a policy that is attempting to run, or currently running. Refer to [What the Statuses Found in the Automox Console Mean](../Console Overview/What_the_Statuses_Found_in_the_Automox_Console_Mean.htm). Here are a few examples: - **Excluded From Reports:** This device is flagged as an exception and does not show up in reporting. Automox still tries to patch according to the policies assigned to the group that it is in. - **Unmanaged:** This device has been added to Automox, but the group it is in does not have any policies assigned to it. ## Patch Installation Methods ### Scheduled Policy **Important**: Devices with Automox Agent version 2.1.44 or later use deadline-based notifications. Refer to [End-User Notifications](../Notifications & Restarts/End_User_Notifications.htm) for details. - The policy runs at the local time for each device defined within the policy. - If notifications are configured, a notification and the defined deferral option appear at the scheduled deployment time, allowing 15 minutes to respond. - If the Automatic Restart option is enabled in the policy, and one or more patches require a restart, the restart message is displayed. In any other scenario with Notifications, the Notification message is displayed. - If Automatic Restart is configured, a final restart notification is displayed after patches are installed allowing 15 minutes, but only if a restart is required to complete the patch installation. The user can click Restart now, or Close. If they select close, or do not respond to a restart notification, the computer will restart at the time specified. - If Restart notification deferrals are enabled, the policy defined deferrals are displayed within the restart notification. - When the **If a device misses a patch window, patch it the next time the device checks in** checkbox is selected, as long as the machine has run a scan between the time the policy was created, and the policy schedule time, the policy will run when the device next communicates with Automox. - Notifications are only displayed if there is an active user session (only if a user is logged on). If no user is logged in, installation and restart actions run automatically. ### Manually Run Policy You can manually run enabled and assigned policies at any time (this includes scheduled policies). - You can trigger a manual policy run from Device Details (for an individual device) or from the policy Actions menu (on all targeted computers at one time). - Manually running a policy honors the Automatic Restart configuration but does not display notifications. - Manually running a Worklet policy ignores evaluation and immediately runs the remediation code. - Manually running a policy without a schedule set it the only way to trigger the policy to run. ### Individually You can install or uninstall (if applicable) updates from device details under the actions column drop-down menu. No notifications are displayed and no restart is forced when manually installing an individual patch from the Actions drop-down menu. You can manually trigger a restart after the patch from the Devices or Device Details page. ### Patch all like OS devices where patch is missing You can install a patch for all like OS devices that show a patch is Awaiting installation. From the Software page, search for the patch of interest. One or more versions of the patch might be listed, because the software is displayed by OS as well as patch display name. You can see how many devices require the patch from the **Impacted Devices** column. (The number in this column is also a hyperlink to the device list of impacted devices). To the right, there is an action drop-down button where you can install the patch on all impacted devices. ## Patch Scenarios ### Scenario: Patching Pilot - Policies and Groups Patching a pilot group of systems before patching all production systems can help reduce potential risk incurred by installing updates to applications or operating systems. Here are a few tips: - Build pilot groups that include like or similar systems to your production systems. Include devices with the same operating systems, applications, and similar patch levels. This will help to build confidence that your production patch deployment will work as expected when deployed to your production groups. - Ensure that you review critical applications after patching, allowing enough time to make adjustments should a patch negatively impact your app functionality. - Provide enough time to evaluate the pilot devices, to keep the timing between pilot and production releases as short as possible to ensure dynamic rules do not modify the patch set between testing and production deployments. Example (This is an example, used for demonstration purposes. Please adjust for your environment.) **Build the following groups:** - Pilot - Client Systems - Pilot - Servers - Production - Client Systems - Production - Server Systems 1 - Production - Server Systems 2 **Build the following policies:** - Pilot - Client Patch all except (or Advanced) - Pilot - Server Patch All except (or Advanced) - Servicing Stack Updates Pilot - Servicing Stack Updates Client Production - Servicing Stack Updates Server Production - Production Client Patch all except (or Advanced) - Production Server Patch all except (Saturday 10:00 pm) - Production Server Patch all except (Sunday 12:00 am) **Scheduling:** - Schedule the Pilot policies to run every Wednesday at 12:00 PM, with restart. - Schedule the Client Production policy to run Fridays at 10:00 AM, Notify users before patching and allow deferral for both patching and restart. Install if the system is offline during scheduled time. - Schedule Servicing Stack Update Pilot policy to install at 10:00 AM every day. Install if the system is offline during scheduled time. No restart or notifications. - Schedule the Servicing Stack Update Client Production policy to run Thursdays and Fridays at 9 AM. No restart or notifications. - Schedule the Servicing Stack Update Server Production policy to run on Saturday at 9 PM. No restart or notification. - Schedule the Production Server Patch all except (Saturday 10:00 PM) policy to run every Saturday at 10:00 PM. Include restart without deferral. - Schedule the Production Server Patch all except (Sunday at 12:00 AM) policy to run at 12:00 AM every Sunday. Include restart without deferral. **Logic in this scenario:** - The industry has determined that it takes an average of seven days for a bad character to take advantage of a new exploit. By patching weekly, you will test and deploy patches released within the previous 7 days. - Pilot and production deployments are scheduled closely together. This allows dynamic policy rules to remain more relevant than scheduling them far apart. As patches are released or superseded, some patches may be added or removed from the dynamic policy patch set. This is a potential drawback to this scenario. The trade off is a set-it and forget-it rule set with the ability to keep your environment up to date with little manual administration effort. - Patch schedules are simple and predetermined. This should simplify communications and employees can plan around the patch schedules. ## Tips and Best Practices [What Are the Recommended Best Practices for Patching in Automox?](../Patching/What_Are_the_Recommended_Best_Practices_for_Patching_in_Automox_.htm) - **Tip:** Policies are not inherited based on group hierarchy/structure. Policies must be directly assigned to each group where you want it to be applied. - **Tip:** Search filters are helpful. Use a predetermined naming convention for your groups and Policies to get quick views of relevant objects. If you search for Worklet, Patch, or Required Software in the Policies filter, it will filter to that type of policy. - **Tip:** Each managed device needs access to all update sources when scans and policies run. Notable updates sources are: - [Windows Update troubleshooting](https://docs.microsoft.com/en-us/windows/deployment/update/windows-update-troubleshooting#device-cannot-access-update-files) - WSUS server (if used in your environment) ### Templates Here are API scripts (PowerShell) to create the patch policies from the previous Recommended Best Practices article: Primary Patch Policy - [https://github.com/AutomoxCommunity/Templates_And_Examples/blob/main/CreatePrimaryPatchPolicy.ps1](https://github.com/AutomoxCommunity/Templates_And_Examples/blob/main/CreatePrimaryPatchPolicy.ps1) Servicing Stack Update Policy - [https://github.com/AutomoxCommunity/Templates_And_Examples/blob/main/CreateServicingStackPatchPolicy.ps1](https://github.com/AutomoxCommunity/Templates_And_Examples/blob/main/CreateServicingStackPatchPolicy.ps1) Windows 10 Feature Update Policy - [https://github.com/AutomoxCommunity/Templates_And_Examples/blob/main/CreateFeatureUpdatePatchPolicy.ps1](https://github.com/AutomoxCommunity/Templates_And_Examples/blob/main/CreateFeatureUpdatePatchPolicy.ps1) Optional: Defender Definition Update Policy - [https://github.com/AutomoxCommunity/Templates_And_Examples/blob/main/CreateDefinitionUpdatePatchPolicy.ps1](https://github.com/AutomoxCommunity/Templates_And_Examples/blob/main/CreateDefinitionUpdatePatchPolicy.ps1) **Note**: Policy rules are best suited for English-based systems. Use of Advanced policies might be more appropriate than Patch All Except policies when international language support is required (when standardized rule sets are preferred). ## WSUS - [Configuring WSUS for Automox Integration](../Agents/Agent Installation/Configuring_WSUS_for_Automox_Integration.htm) - [OS Patch Management Settings for Groups](../Group Management/OS_Patch_Management_Settings_for_Groups.htm) Integration with WSUS provides a way for you to cache Microsoft updates on-premise to reduce download bandwidth. Third-party updates are not stored in WSUS, and are downloaded from the internet directly. When you set your Group OS Patch Management "Windows Update Source" to WSUS, and you define your WSUS Server Address, your device scans for Microsoft-based updates and determines compliance and applicability using your WSUS server as the update source. (**Note**: you can also use the “Keep Device Settings” options if WSUS policies are already applied and preferred). Make sure to configure WSUS Products and Classifications to include everything needed, as only the patch metadata available in your WSUS DB (the patches included in the cab downloaded from WSUS) is used to determine what patches are available for compliance or download. ### At Scan Time Automox directs the device's WU agent to scan for updates against its update source. In this case it scans against WSUS. ### At Policy Run Time Automox directs the devices WU agent to download and install the updates it detected in a needed state. It also verifies third-party applications included in the patch policy, and will download them from the internet. Tip: If you configure your group to use WSUS, your device MUST have access to your WSUS server when scans and policies run. ### GPO vs Automox Group settings GPO and Automox Group Patch Management settings can conflict. GPO Windows Update settings apply based on the domain schedule (default every 90 minutes). Automox Patch Management Settings apply based on the group defined scan interval. If they are different, your device could toggle between patch sources, or temporarily go to default. This can cause misalignment in needed patches and potentially install updates or feature updates directly from the internet. Automox recommends using the group Patch Management Settings, and removing the WU settings from GPO to avoid this type of issue. ## Troubleshooting - WU Error codes - [Windows Update error code list by component - Windows Deployment](https://docs.microsoft.com/en-us/windows/deployment/update/windows-update-error-reference) - Patch troubleshooting resources: - [Windows Update Troubleshooting Process](https://help.automox.com/hc/en-us/articles/31737315610516-Windows-Update-Troubleshooting-Process) - [Windows Update troubleshooting - Windows Deployment](https://docs.microsoft.com/en-us/windows/deployment/update/windows-update-troubleshooting) - Windows Update Agent and WSUS troubleshooting - [Windows Update - Additional resources - Windows Deployment](https://docs.microsoft.com/en-us/windows/deployment/update/windows-update-resources) ## Miscellaneous - Patch rollbacks - [How to Roll Back an Installed Patch on Devices](../Miscellaneous/How_to_Roll_Back_an_Installed_Patch_on_Devices.htm) - [Windows Patch Rollback Worklet](../Worklets & Required Software/Windows_Patch_Rollback_Worklet.htm) - Exclusion - Block list - [Adding Patches to the Block List in the Automox Console](../Miscellaneous/Adding_Patches_to_the_Block_List_in_the_Automox_Console.htm) ## Related Topics - [Onboarding Jumpstart Guide - Manage Your Environment](Onboarding_Jumpstart_Guide___Manage_Your_Environment.htm) - [Onboarding Jumpstart Guide - Worklets and Required Software](Onboarding_Jumpstart_Guide___Worklets_and_Required_Software.htm) --- # Onboarding Jumpstart Guide - Worklets and Required Software _Section: Product Documentation › Getting Started • Source: https://docs.automox.com/product/Content/Product%20Documentation/Getting%20Started/Onboarding_Jumpstart_Guide___Worklets_and_Required_Software.htm_ As you begin to build out your new Automox organization, understanding what is available, and having access to best practices help you install software where you need it, and build some amazing Worklets while avoiding common pitfalls. ## Required Software - [Using the Required Software Policy](../Worklets & Required Software/Using_the_Required_Software_Policy.htm) - [How to Find Application Names and Versions for Required Software Policies](../Worklets & Required Software/How_to_Find_Application_Names_and_Versions_for_Required_Software_Policies.htm) ## Worklets What can you use Worklets for? Well, pretty much anything you can script! You can install software, customize settings and configurations, or copy items to your devices. Being a SaaS solution, you can apply Worklets to devices that are anywhere! They just need to have an agent, and internet access. - [Creating a Worklet](../Policies/Creating_a_Worklet.htm) - [How to Use Worklets](../Worklets & Required Software/How_to_Use_Worklets.htm) - [Automox University: Worklets 101](https://university.automox.com/worklets-101) ### Evaluation The evaluation code block determines whether devices are compliant, or require remediation to bring your device into compliance. As an example, you can check if software is installed, review registry settings, check folders or files, or set to non-zero to continuously apply remediation scripts on a schedule. - Evaluation and remediation happens at different times. Evaluations run based on the scan interval set in the group the device is placed in. Evaluations also run after policies run. - You can use evaluations in different ways. The way you configure the evaluation may change the status for your device. Here are a few options based on your need: - Primary use: define evaluation code to verify if your Worklet is already compliant, or if it needs remediation. - If you want a policy to only run on-demand and always show as compliant, you can set your evaluation to `exit 0`. - If you want to enforce a Worklet to re-apply on a schedule, you can set the evaluation code to `exit -1` (or anything that is not `0`). This will always show status for the devices in groups where the policy is assigned to show as "pending". ### Remediation - You can run policies automatically on a schedule, or on-demand. - You can run policies on-demand per device or group. - If you run a Worklet policy on demand, Automox ignores the evaluation and runs only the remediation. #### Error Handling Best practice - Add the following exit code handler at the beginning of your script: trap { $host.ui.WriteErrorLine($_.Exception); exit 90 } - All scripts must return zero for success, and non-zero for failure **Note**: Worklets currently do not properly work as a monitoring tool. The process you run in your Worklet must exit before the agent continues on to its next task. Make sure your Worklet runs a process and exits out on success or failure to keep the agent active and functional. #### Logging and Reporting Logging is integral with automation. Consider adding output to a local log, centralizing output to the Automox activity log, or both. Worklets return either the success or failure return stream in the activity log based on the outcome of the Worklet process. If the worklet completes successfully, all success returns are listed in the activity log. If the worklet process fails, the error returns are listed in the activity log instead. Return information from a Worklet: - Linux - `stdout` or `stderr` to write to the activity log - Windows - `Write-Output` or `Write-Error` to the activity log Creating a local log: A more verbose log can be useful for audit and/or troubleshooting. Here is an example of a PowerShell installation command line including a local log creation: Start-Process -FilePath 'msiexec.exe' -ArgumentList ('/i', '7z1900-x64.msi', '/qn', “/L*V`“C:\Windows\Temp\7z1900-x64.log`””) -Wait -Passthru ### Windows #### OS Architecture When writing Worklets for Windows, consider the OS architecture you are targeting. If you are targeting both 64-bit and 32-bit devices, additional sections of code might be required for both to work. As an example, 32-bit applications typically are installed into the “Program Files” directory on 32-bit operating systems, and in the “Program Files (x86)” directory on 64-bit systems. Another example is where SOFTWARE registry keys are stored. This can become even more complex when you consider the Automox agent is a 32-bit application, and runs 32-bit PowerShell by default. #### Running Profile Automox runs a system. Worklets do not have access to current user resources such as mapped drives, or user based network share permissions. #### System vs User The Automox agent runs under the system context. This is important to consider when testing your scripts. - System context allows installation of applications for all users, and may make system wide changes. - The system profile does not have access to network resources, current user registry or directories that are available when running your tests as yourself (even when running ISE x86 in an elevated context). - User prompts are not displayed. The script must complete and close successfully without user interaction. #### Manage User Profiles Managing user profiles and settings can be a challenge as configured today. Most solutions involve the use of a scheduled task to run as user, or querying the registry to detect all users profile registry hives, then mounting user registry of each user to identify shell folder paths for file placement, or to set user based key values. Here is an example of managing user based registry settings from a Worklet: [Modify registry key/value under HKEY_USERS (HKCU Workaround)](https://community.automox.com/worklets-12/modify-registry-key-value-under-hkey-users-hkcu-workaround-1371) #### Testing - Best Practices Testing your scripts locally before attempting to run them through a worklet can save a good deal of time and help to avoid applying changes to remote devices that may be difficult to reverse. PowerShell ISE x86. This is preinstalled on modern versions of Windows, and comes in both 32-bit and 64-bit versions. When testing for use with Automox, use the 32-bit version which runs in the same environmental context as a script runs through the Automox agent. #### Run as System The Automox agent runs under SYSTEM context. When testing your scripts, you can verify your scripts have access to the local resources (drives, profiles and directories, registry hives) and environmental resources (network shares, remote applications, access to other systems and the internet) required for your script to successfully run. One way to test your script using SYSTEM context is by using PsExec from the SysInternals suite ([PsExec - Windows Sysinternals](https://docs.microsoft.com/en-us/sysinternals/downloads/psexec)) to run PowerShell ISE (x86). This will mimic both the 32-bit PowerShell environment, and running in SYSTEM context as the Automox agent will when running your script in production. Command to launch PowerShell ISE (x86) with psexec: PsExec.exe -s -i %windir%\syswow64\WindowsPowerShell\v1.0\PowerShell_ISE.exe [Enforce Windows Registry Settings Worklet](../Worklets & Required Software/Enforce_Windows_Registry_Settings_Worklet.htm) - When not testing under SYSTEM context , always use an elevated Windows PowerShell ISE (x86) instance. - When you need to access 64-bit resources like HKLM:\SOFTWARE and don’t want your code to redirect to the WOW6432Node, try wrapping your code in the following script block, and running it from an elevated PowerShell ISE (x86). It will force the code within the scriptblock to run in the appropriate environment for your system. **Example of Scriptblock** [https://github.com/AutomoxCommunity/Templates_And_Examples/blob/main/Example_ScriptBlock.ps1](https://github.com/AutomoxCommunity/Templates_And_Examples/blob/main/Example_ScriptBlock.ps1) **Tips** - Ensure your evaluation and remediation code properly exit (even on failure). If a process is left running, it can cause the Automox agent to hang (it will wait for the process to complete before additional actions can be applied). - Worklets are not currently built to run as monitoring processes for this reason. Monitoring processes is something we are working on for a future feature improvement. - Consider adding output logging into your Remediation code. It is written into your activity log and made available in the Activity Log Report. - Content uploaded for Required Applications or Worklets is stored in Amazon s3. If you use a proxy application or strict firewall rules, consider allowlisting: automox-policy-files.s3.us-west-2.amazonaws.com - For backwards compatibility, Automox uses -NoProfile. When invoking web requests in a Worklet, consider adding support for newer security protocols to ensure the connection is made. Here is an example of some code you can add to your scripts in this scenario: - [https://github.com/AutomoxCommunity/Templates_And_Examples/blob/main/Example_SecurityProtocol.ps1](https://github.com/AutomoxCommunity/Templates_And_Examples/blob/main/Example_SecurityProtocol.ps1) [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Ssl3, [Net.SecurityProtocolType]::Tls, [Net.SecurityProtocolType]::Tls11, [Net.SecurityProtocolType]::Tls12; Further, you can define the required protocol only. ### Examples #### Windows Executable (.exe) Evaluation and Remediation *Evaluation using 64 bit script block (Works for 64-bit OS):* [https://github.com/AutomoxCommunity/Templates_And_Examples/blob/main/Example_EXE_EVALUATION_ScriptBlock.ps1](https://github.com/AutomoxCommunity/Templates_And_Examples/blob/main/Example_EXE_EVALUATION_ScriptBlock.ps1) *Remediation - Install .exe with switches and msi pass through switches* Example remediation code as a function. You could use this as part of a more complex script. [https://github.com/AutomoxCommunity/Templates_And_Examples/blob/main/Example_EXE_REMEDIATION.ps1](https://github.com/AutomoxCommunity/Templates_And_Examples/blob/main/Example_EXE_EVALUATION_ScriptBlock.ps1) #### Microsoft Installer (.msi) Evaluation and Remediation *Evaluation - Example (Works for 32-bit and 64-bit Software):* Example MSI Installer Evaluation and Remediation - Evaluate for either 32-bit or 64-bit software via registry. This example is based on the following Worklet to Uninstall existing Software: [Worklet:Enforced Application Uninstall for Windows - Worklets](https://community.automox.com/worklets-12/enforced-application-uninstall-for-windows-1552) **Example Code:** [https://github.com/AutomoxCommunity/Templates_And_Examples/blob/main/Example_EVALUATION_32and64Bit_Architecture.ps1](https://github.com/AutomoxCommunity/Templates_And_Examples/blob/main/Example_EVALUATION_32and64Bit_Architecture.ps1) *Remediation - Install .msi* **Example Code:** [https://github.com/AutomoxCommunity/Templates_And_Examples/blob/main/Example_MSI_REMEDIATION.ps1](https://github.com/AutomoxCommunity/Templates_And_Examples/blob/main/Example_MSI_REMEDIATION.ps1) ## Worklet Catalog Automox offers a growing number of Verified Worklets, available for immediate use. Most require a plan that includes Worklets. We now include a subset of for all users. To access the Worklet Catalog, in the console go to **Automate → Worklet Catalog**. See [Creating a Worklet](https://help.automox.com/hc/en-us/articles/5603324231700) and [Using the Worklet Catalog](../Worklet Catalog/Using_the_Worklet_Catalog.htm). ## Related Topics - [Automox University Best Practices: Worklets](https://university.automox.com/best-practices-worklets) - [Community Worklets](https://community.automox.com/worklets-12) - [Onboarding Jumpstart Guide - Manage Your Environment](Onboarding_Jumpstart_Guide___Manage_Your_Environment.htm) - [Onboarding Jumpstart Guide - Patching](Onboarding_Jumpstart_Guide___Patching.htm) --- # Quick Start Guide - Patch Management in Minutes _Section: Product Documentation › Getting Started • Source: https://docs.automox.com/product/Content/Product%20Documentation/Getting%20Started/Quick_Start_Guide___Patch_Management_in_Minutes.htm_ You can be up and running using Automox ## Tips for Getting Started - Browse the Automox [website](https://www.automox.com/) to request a demo and explore resources. - Visit the [Product Documentation](http://docs.automox.com/) site for in-depth product information, including features, configuration, and usage guides. - Click **?** in the upper right corner of the product console to access the Automox Help Center, where you can find solutions-based articles and submit a support request. - If you have any issues or would like to connect directly with an Automox - Ensure you have the required permissions to manage policies. See [Roles and Permissions](../Global Access Management/Roles_and_Permissions.htm) **Character Limits:** Keep the following character limits in mind when using the Automox Console: - **Organization name -** 45 Characters - **API Key name** - 45 Characters - **Billing company name** - 45 Characters - **Group Name** - 45 Characters - **Policy Name** - 100 Characters - **Policy Cloning** - 69 Characters ## Add Devices Before you can use the Automox 1. Go to **Devices → Add Devices** ![](../../Resources/Images/add-devices.png) 2. In the Add Devices window, select your OS and choose **Download****Installer**. 3. Download the installer file. 4. Open the installer file to complete agent installation. ![](../../Resources/Images/download-installer.png) You can install the agent through an onboarding wizard. After adding your devices, Automox inventories all hardware, software, patches, and configuration details, which is visible from the Devices page. Want to do more? Automox has several methods to install the agent in bulk across multiple domains or servers. You can read more about bulk deployment and other product use cases in our user documentation. This is also accessible by clicking the help question mark in the console. ## Group Your Devices Automox Groups enable you to segment your organization and simplify management. Whether you sort your devices by department, operating system, or region, groups simplify the management of your security infrastructure. Follow these steps to add a group, and assign devices: 1. Go to **Devices → Create Group** ![](../../Resources/Images/add-group.png) ![](../../Resources/Images/qsg-edit-group.png) 2. Enter a Group Name for your new group. 3. Click **Create**. 4. In the Edit Group window, click **Assign Devices** to assign devices to the group. You can accept all other defaults for your new group. 5. Click **Update Group** to save your group settings. After you create more than one group, you can look at the options that help you identify groups for easier management. And, as you become more familiar with Automox you can choose to customize your group settings. Want to do more? Consider how you want to group and segment your devices for patching and endpoint hardening. You can create and assign policies to one group or multiple groups, and you also can choose to create sub-groups under a Parent Group for easier management. ## Create a Policy Policies automate cyber hygiene, helping you patch systems, ensure the right software is installed, and maintain configurations. You can create policies once and assign them to multiple groups of devices, quickly update policies for every device without the need to touch code or hardware, and create one policy to manage a mix of Windows, macOS, and Linux devices. To get you started, Create a Patch All policy: 1. Go to **Automate → Policies**. 2. Click **Create Policy → Patch All**. ![](../../Resources/Images/qsg-create-policy.png) 3. Enter a**Policy Name** for your new Policy and ensure the Policy Status is **Active** (On). This enables patching. You can accept all other defaults for your new policy. 4. Before saving the policy, assign a group by clicking the plus sign in the **Associate Groups**section. 5. Click **Create Policy**. Want to do more? You can choose to configure the other policy settings at a later time such as: device filters, automatic restart, scheduling, user notifications, and deferral settings. These settings are not required for this quick start configuration, but are key for how you want to manage your devices long term based on your patching requirements. ## Scan Devices and Run Policies, As Needed Now that you've added your devices and assigned a policy to your specific group, manually scan your devices to determine their patching status. Go to **Devices → [Your Named Device] → Scan Device**. After scanning: If the policy status is non-compliant with the latest patches, you see a Needs Attention status. If the policy status associated with your device is compliant, then you’re all set. Under Associated Policies, you can choose to run a policy to put your devices in compliance with the latest patch updates. Click **Run On This Device** next to the associated policy. Want to do more? You can customize the device scan interval to between 6–24 hours. You pick how frequently or infrequently you want Automox to scan the status of your devices. Be sure to check back regularly to see how your device statuses might have changed. ## There's So Much More You Can Do in Automox You've got the basics covered. Pretty simple, right? Here's a quick list of what more you can do to realize how Automox - Get familiar with the Automox dashboard. The Automox dashboard view provides full visibility into the statuses of your devices, allowing you to quickly identify misconfigured systems, missing patches, or compliance issues. - Add more devices and begin grouping them according to your patch management policies or organizational architecture. For example, group by department, operating system, or region. The ability to group your devices allows you to enforce specific policies according to your business needs. - Check for a software version in your application inventory. Because Automox provides access and visibility of all your devices, you can confirm that they are running the latest version of a specific software to keep them better protected and secure from known vulnerabilities. - Create a policy from a template using the Next Steps guide that appears in the console when onboarding. Automox recommendations establish a best practice 7-day cycle with basic (and customizable) policies. - Set a password policy across your available devices using an Automox Worklet. Automox leveraged cybersecurity best practices to create a worklet that lets you enforce these password policies across your devices: see [Automox Worklet - Set Password Policies](https://www.automox.com/blog/automox-worklet-set-password-policies) to create and run this worklet in your environment. You can learn more about Automox Worklets at: [www.automox.com/use-cases/worklet](https://www.automox.com/use-cases/worklet). ## Manage Your Automox Subscription Go to the **Settings** page in the Automox If you prefer, feel free to connect directly with your Automox sales representative to discuss the available subscriptions and discuss the best plan for you. You also can connect with Automox Sales at: [sales@automox.com](mailto:sales@automox.com). --- # Security Best Practices When Setting Up Your Environment _Section: Product Documentation › Getting Started • Source: https://docs.automox.com/product/Content/Product%20Documentation/Getting%20Started/Security_Best_Practices_When_Setting_Up_Your_Environment.htm_ Here are some best-practices when setting up your environment for the first time. Some of these topics are covered in [Security](../Settings/Security.htm) description of the documentation, but the following topics are what Automox recommends. Two-factor authentication (2FA) and single-sign on (SSO) greatly reduce the possibility of your account getting compromised. When using 2FA, prefer the use of OTP (one-time pins) over mobile push. In the event mobile push is necessary, enable challenge-response features where possible to protect employees against authentication spam attacks. **If you have an SSO IDP, enable SSO for your organization:** - [Automox Okta Single Sign-on (SSO) Integration](../Console Overview/Automox_Okta_Single_Sign_on__SSO__Integration.htm) - [Configuring SAML for Microsoft Entra ID (Azure ID)](../Console Overview/Configuring_SAML_for_Microsoft_Entra_ID__Azure_ID_.htm) - SSO is beneficial in that it reduces the overall attack surface and prevents account sprawl. If you have many administrators in your Automox organization, SSO eliminates the need to track down that account when that person leaves the company. SSO is beneficial in that it reduces the overall attack surface and prevents account sprawl. If you have many administrators in your Automox organization, SSO eliminates the need to track down that account when that person leaves the company. **Lower the threshold for which accounts lock after a certain number of failed login attempts.** Rate limiting sign-in attempts reduces the chance of successful brute-force or password spray attacks on your account. For more information on this feature, see Login Attempts Settings in [Security](../Settings/Security.htm). **Only create API keys if necessary, and if you do, set a reasonable expiration based on your company’s security policy.** - Rotating API tokens reduces your overall attack surface. Keys that are handled by humans regularly should be rotated more often, while keys that are not accessed often or ever and are stored securely may warrant a longer expiration period. - Discard tokens that are no longer in use by auditing on a regular cadence. Store agent access keys in a secure vault or a secure location, never in plain-text in a publicly accessible location. See [Managing Keys](../Settings/Managing_Keys.htm). **When you create your first worklet, avoid (if possible) storing sensitive data like API tokens, secrets, or username/password combinations in them.** **The**`--setexecdir`**flag is a useful option for admins who need scripts run in a certain directory depending on security standards.** For more information about this, see [Change Automox Script Execution Location](../Agents/Agent Installation/Change_Automox_Script_Execution_Location.htm). See also [Location of Files Required By Automox](../Agents/Agent Requirements/Location_of_Files_Required_By_Automox.htm). **When adding users to manage your organization, only give the permissions they require for their job function.** Over-provisioning access could lead to unintended consequences. However, under-provisioning can create blockers and workflow interruptions for your team. It’s a balancing act, so find what works best for you and your team. When in doubt, use the principle of least-privilege. Refer our [Roles and Permissions](../Global Access Management/Roles_and_Permissions.htm). --- # Global Session Expiration Settings _Section: Product Documentation › Global Access Management • Source: https://docs.automox.com/product/Content/Product%20Documentation/Global%20Access%20Management/Global_Session_Settings.htm_ You can customize the console time-out period for each organization. To access the global session settings, go to the **Manage Orgs and Users** page. **Prerequisites**: You are an **Account** or **Full Administrator** or you have **Users: Modify** permissions. See [Roles and Permissions Management](Roles_and_Permissions.htm). ## Session Expiration You can view and configure the default settings for session expiration (also known as console timeout) from the **Settings** tab. ![](../../Resources/Images/global-session-expiration.png) ### Maximum Session Lifetime The maximum session lifetime is the amount of time that a session can exist before the session is terminated and the user must log in again. The maximum is 90 days (2160 hours). The **default maximum session timeout** is 12 hours. ### Idle Session Timeout The idle session timeout is the amount of time a session can exist without user input (inactivity) before the session is terminated and the user must log in again. The maximum is 30 days (720 hours). The **default idle session timeout** is 30 minutes. ## Configuring Session Expiration You can edit the default settings for the session expiration. 1. To change the default settings for session expiration, click in the hours and minutes fields and enter the desired settings. 2. Click **Update** to save the changes. ## Related Topics - [Managing Organizations](Managing_Organizations.htm) - [Managing Users](Managing_Users.htm) - [Roles and Permissions Management](Roles_and_Permissions.htm) --- # Managing Global Keys _Section: Product Documentation › Global Access Management • Source: https://docs.automox.com/product/Content/Product%20Documentation/Global%20Access%20Management/Managing%20Global%20Keys.htm_ From the **Setup & Configuration → Keys** tab, you can view the **Account UUID**, **Global Organization UUID**, and manage **Global API keys**. Global API keys differ from organization API keys in scope: - **Global API keys**: Provide access across all organizations in an account. They are managed at the global level and are useful for automation or integrations that need to span multiple organizations. - **Organization API keys**: Provide access only within a single organization. They are managed at the organization level and are useful when access should remain limited to one organization. Global API keys reduce the need to create and maintain separate organization-level keys when you need cross-organizational access **Prerequisites**: You must meet the following requirements before you can create or manage global API keys: - You are a **Full Administrator** or have a global custom role with **Organization**: **Read** and **Manage** permissions. - You have**All API Keys**: **Read, Modify, List,**and**Delete** permissions. ![](../../Resources/Images/global-key-management.png) **Keep API Keys Secure!** API keys should be kept secure and not shared to prevent unforeseen changes or potential security issues. Never email or write down your API key. **API Keys and Permissions** API keys inherit the same permissions that the user has. For example, an API key belonging to a Full Administrator has the same permissions as in the console, and allows them to perform functions using the API that require Full Administrator permissions. ## Viewing Keys Go to **Setup & Configuration → Keys** to access the Global Key Management page. The following information is available on this page: - **Account UUID**: The UUID for the account. The account name is listed with this unique identifier. - **Global Organization UUID**: The UUID required when using global API keys across all organizations in an account. You can copy both UUIDs using the clipboard button. - **Global API Keys**: The Global API Keys table lists all global API keys created for the account. How you view or interact with these keys depends on your permissions. See [Global API Key Permissions and Actions](#Managing) for details. Use the global API key to access the [Automox API](https://developer.automox.com/). **Note**: Global API keys are not automatically generated for new users or new organizations. See [Adding Global API Keys](#Adding). ## Global API Key Permissions and Actions Global API keys allow administrators to authenticate and manage resources across multiple organizations in an account. What you can do with these keys depends on your assigned permissions. ![](../../Resources/Images/show-API-key.png) - To view (decrypt) an API key, click the **Show** button to the right of the hidden characters. The key automatically hides again after 10 seconds. - To copy the API key, click the **Copy** button (clipboard) to the right of the field. It is automatically decrypted. ### Listing Global API Keys You can list or view global API keys if you have the correct permissions. - To list all global API keys, you must have **All API Keys: Read** permission. - To view (decrypt) your own API key, you must have **Personal API Key: Manage** permission. ### Adding Global API Keys You can create up to 10 global API keys per user account. - To add a global API key for yourself, you must have **Personal API Key: Manage** permission. Steps to add a global API key: 1. Select **Add**. 2. Enter a unique name for the key. 3. (Optional) Select an expiration date. 4. Select **Create**. ### Enabling and Disabling Global API Keys You can enable or disable (modify) global API keys if you have the correct permissions. - To modify global API keys for any listed user, you must have **ALL API Keys: Modify** permission. - To modify global API keys from your account, you must have **Personal API Key: Manage** permission. ### Deleting Global API Keys You can permanently delete global API keys. - To delete global API keys for any listed user, you must have **ALL API Keys: Delete** permission. - To delete your own API keys, you must have **Personal API Key: Manage** permission. **Note**: When an API key is deleted, all API requests using the key are rejected and return an error. ## Example Scenarios This table provides examples of what actions are available in the **Global API Keys** table based on user role and assigned permissions. | Scenario | Permission | Decrypt | Enable/Disable | Delete | | --- | --- | --- | --- | --- | | User on their own key | Personal API Key: Manage | Yes | Yes | Yes | | Admin on another user’s key (Modify only) | All API Keys: Modify | No | Yes | No | | Admin on another user’s key (Delete only) | All API Keys: Delete | No | No | Yes | | Admin on another user’s key (Modify and Delete) | All API Keys: Modify and All API Keys: Delete | No | Yes | Yes | **Note**: Decrypt is always limited to the key owner. Administrators cannot decrypt another user’s key, even with All API Keys permissions. ## Related Topics - [Managing Organization Keys](../Settings/Managing_Keys.htm) --- # Managing Organizations _Section: Product Documentation › Global Access Management • Source: https://docs.automox.com/product/Content/Product%20Documentation/Global%20Access%20Management/Managing_Organizations.htm_ You can manage organizations from the **Setup and Configuration** page. To access this page, select the Global View (Manage Orgs and Users **Prerequisites**: - You are an **Account Administrator** or **Full Administrator** or you have **Organization: Manage** permissions. See [Roles and Permissions Management](Roles_and_Permissions.htm). - Only **Account Administrators** or custom roles with account-level based **Organization: Create** permissions can create organizations. **Note**: You cannot remove an organization An organization is a collection of the devices of a company’s IT infrastructure. Users can be given a role to access an organization with certain permissions. These permissions are then only related to the devices in that organization. A user can therefore be assigned different permissions for different organizations. (See [Roles and Permissions Management](Roles_and_Permissions.htm).) ## Viewing Organizations The **Organization** page shows all available organizations. **Prerequisities**: You must have **Organization: Read** permissions. ![](../../Resources/Images/setup-orgs-tab.png) The following information is available from the Organizations table: | Organizations Table Column | Description | | --- | --- | | Name | Name of the organization | | Organization UUID | This is the universally unique identifier (UUID) associated with the organization | | Organization ID | This lists the integer associated with the organization (org ID) | | Created | Time and date that the organization was created | | Modified | Time and date when the organization was updated or changed | | Created by | Email address of the user who created the organization | | Users | Number of users added to the organization | | Devices | Number of devices added to the organization | | SAML | Shows if SAML is enabled or disabled for the user | | Status | Shows if this organization is enabled or disabled | | Account UUID | This is the unique identifier for the Account. This column is hidden by default. | | Global Organization UUID | This is the global-level Organization UUID. This column is hidden by default. | | Actions | Edit Organization: You can modify the organization name and manage user roles assignments for this organization | ## Adding Organizations You can configure organizations based on the needs of your company’s IT structure. **Prerequisites**: You have **Account Administrator** or **Organization** permissions. See [Roles and Permissions Management.](Roles_and_Permissions.htm) Follow these steps to add an organization. 1. From the **Organizations** page, click **Add Organization**. 2. Enter a name for the organization 3. (Optional) To add users at the organization level only, go to **Organizational Level Roles** and select the email address from the Add User list. See also [Managing Users](Managing_Users.htm). 4. Select the role for the added user. **Note**: Account and global full administrators are automatically added to a new organization during the initial setup. 5. Click **Save**. ### Naming rules - **Maximum Length**: The organization name must not exceed 45 characters. - **Allowed Characters**: - **Letters**: Uppercase and lowercase (A-Z, a-z) - **Digits**: 0-9 - **Special Characters**: Underscore (_), hyphen (-), pipe (|), comma (,), apostrophe ('), and space - **Prohibited Characters**: Any character or symbol not listed above is not allowed. ## Editing Organizations You can modify organizations from the **Edit Organization** page. **Prerequisites**: You have **Account Administrator, Full Administrator,** or **Organization: Manage** permissions. See [Roles and Permissions Management.](Roles_and_Permissions.htm) Follow these steps to edit an organization. 1. Go to the **Organizations** page. 2. You can access the **Edit Organization** page in two ways: - Click the name of the organization you want to edit, or - Go to the Actions menu (...) and click **Edit Organization**. The **Edit Organization** page includes the following sections: ### Details This section provides an overview of the information listed on the main organization page, but for this one organization. You can find the following details about this organization: - Account UUID, Global Organization UUID, Organization UUID, Organization ID, Creation Date, and number of users associated with this organization listed by role level. - You can modify the organization name here. ### Account Roles This lists all account-level roles associated with this organization. To modify these, go to the **Roles and Permissions** tab. ### Global Roles This lists all global-level roles associated with this organization. To modify these, go to the **Roles and Permissions** tab. ### Organization Level Roles This lists all users and their assigned roles for this individual organization. From here you can take the following actions: - Add a user and assign a corresponding role or roles - Modify the role for an existing user - Remove a user. (Click the **x** next to the user to remove them from this organization.) - Confirm any modifications. **Note**: - When you remove a user from a specific organization, it does not remove the user from the company account. - A user may be listed multiple times if they are assigned multiple roles within the same organization. ## Related Topics - [Understanding Global Access Management](Understanding_Global_Access_Management.htm) - [Roles and Permissions Management](Roles_and_Permissions.htm) - [Managing Users](Managing_Users.htm) - [Global Session Expiration Settings](Global_Session_Settings.htm) - [Managing Global Keys](Managing Global Keys.htm) --- # Managing Users _Section: Product Documentation › Global Access Management • Source: https://docs.automox.com/product/Content/Product%20Documentation/Global%20Access%20Management/Managing_Users.htm_ From the **Setup & Configuration → Users** tab, you can view, add, edit, and delete users associated with organization **Prerequisites**: You have **Account Administrator**, **Full Administrator**, or **Users: Read**,**Modify**,**Delete**,or**Invite** permissions, depending on the function. See [Roles and Permissions Management](Roles_and_Permissions.htm). ![](../../Resources/Images/setup-users-tab.png) ## Viewing Users You can view the following details about users from the **Users** page: | Users Table | Description | | --- | --- | | Email | Email address of the user | | First Name | First name of the user | | Last Name | Last name (surname) of the user | | Status | Active: the user account is active Pending Invite: the user was invited, but has not yet accepted Unassigned: the user account is active, but they have no role assignment | | 2FA | This shows the setting for two-factor authentication for this user. This can be email, mobile, or disabled. | | Actions | Options available: Edit User Remove User | ## Adding Users to Organizations You can add users to organization **Prerequisites**: You have **Account Administrator**, **Full Administrator**, or **Users: Invite** permissions for the specific organization you want to add users to. 1. Click **Add User**. 2. On the Add User page, enter the email address for the user you want to add. 3. Select if the user should have an **Account** or **Global** role. 4. Under Organization 5. You can add the user to multiple organization 6. Click **Save**. **Note**: - A user who is new to the account receives an invitation to join the organization - Existing users to the account do not receive an invitation. ## Editing Users You can modify user details from the**Users**page. See [Roles and Permissions Management](Roles_and_Permissions.htm) for details about the types of roles and corresponding permissions. 1. You can access the **Edit User** page in two ways: 1. Click the email address of the user you want to edit. The**Edit User** page opens. 2. Go to the **Actions** column and click **Edit User**. 2. From here you can remove an assigned role, assign a new role, or make changes to organization assignments. 3. Click **Save**. **Note**: - When a user has an active account, but no role, the status shows as **Unassigned**. - If a user wants to use a different email address, they must first be removed from the organization and then invited using the new email address. This requires a user with permissions to delete and invite users. ## Deleting Users You can remove a user from an organization **Note**: - When you remove a user, they are removed from all organization - You cannot remove the only **Account** or **Global Full Administrator**. Find the user you want to remove: 1. Select the **Actions** menu (...) for that user. 2. Click **Remove User**. 3. Confirm the message to delete the user. ## Resetting 2FA You can reset 2FA for a user from the **Users** page. 1. Select the email for the user or users you want to reset 2FA for. 2. From the **Actions** drop-down menu, click **Reset 2FA**. ## Related Topics - [Roles and Permissions](Roles_and_Permissions.htm) - [Understanding Global Access Management](Understanding_Global_Access_Management.htm) - [Managing Organizations](Managing_Organizations.htm) - [Global Session Settings](Global_Session_Settings.htm) --- # Moving Devices From One Organization to Another _Section: Product Documentation › Global Access Management • Source: https://docs.automox.com/product/Content/Product%20Documentation/Global%20Access%20Management/Moving_Devices_From_One_Organization_to_Another.htm_ Sometimes you must move a device from one organization (org) to another within the console. This process involves two steps, both of which are performed directly on the target device. **Note:** Do not attempt this operation as a Worklet. --- # Roles and Permissions Management _Section: Product Documentation › Global Access Management • Source: https://docs.automox.com/product/Content/Product%20Documentation/Global%20Access%20Management/Roles_and_Permissions.htm_ This document outlines the roles and permissions for users within the Automox Automox includes two main administrative roles with global permissions across all organizations in an account: **account administrator** and **full administrator**. The account administrator manages account-related details such as billing, user and role management, and creating or deleting organizations. The full administrator manages operational functions across organizations, including devices, groups, policies, remediations, reports, and API keys. From the **Roles and Permissions** page, you can select either **Account** to view details for the account administrator, or **Global (All Organizations)** to view details for the full administrator and other global roles. **Prerequisites**: - Access to the **Roles and Permissions** tab in the console is managed through RBAC Roles permissions. - You can view the tab with **RBAC Roles: Read** permissions, or you can manage it if you are, for example, a **Global Full Administrator**. - See [Default User Roles and Permissions](#Default). **API Keys and Permissions** API keys inherit the same permissions that the user has. For example, an API key belonging to a **full administrator** has the same permissions as in the console, and allows them to perform functions using the API that require full administrator permissions. An API key belonging to an **organization operator** is only able to access and view organizations where they are assigned organization operator permissions using the API. ## About the Roles and Permissions Page From the Manage Orgs and Users This page allows you to manage and create user roles with precise permissions for your organization's needs. ![](../../Resources/Images/roles-permissions.png) **Options available**: 1. Role association: Account or Global (All Organizations) ![](../../Resources/Images/global-dropdown.png) 2. List of roles: View, duplicate, and add or remove users from roles 3. List of permissions: View permissions available to each role. Scroll to view the full list. 4. Custom role creation: Assign specific permissions for tailored use. ## Default User Roles and Permissions This section describes the pre-defined (default) roles and their permissions. From the **Roles and Permissions** tab, select the role level that you want to view details for: **Account** or **Global (All Organizations)**. **Note**: - You **cannot** modify default roles. - Some features require additional role and permission combinations. See [Feature-Specific Access Requirements](#Feature-) for details. ### 1. Account Administrator **Description**: Account administrators manage account details, users and their roles, and billing globally for all organizations associated with the account. They can create and manage organizations. Only account administrators can add (invite) users to an account or assign roles at the account level. **Note**: Only account administrators or custom roles with account-level based **Organization: Create** permissions can create organizations. | Function | Permissions | | --- | --- | | Account | Read, Modify, Delete | | Billing | Read, Modify | | Organization | Read, Create, Manage | | Personal API Keys | Manage | | RBAC Roles | Read, Modify, Delete, Create, Grant, Revoke | | Users | Read, Modify, Delete, Invite | ### 2. Full Administrator **Description**: Full administrators have global permissions for operational management across all organizations in the account. They can manage devices, groups, policies, remediations, reports, and API keys, and can create and manage custom roles that fall under the Global (All Organizations) role type. You can assign a full administrator globally from the **Roles and Permissions** page or at the organization level from **Settings → Users**. When assigned at the organization level, the same operational permissions apply, but only within that organization. **Note:** Each organization must have at least one user with global full administrator permissions. | Function | Permissions | | --- | --- | | Agent Settings | Read, Modify | | All API Keys | Read, Modify, Delete, List | | Approval | Read, Update | | Billing | Read, Modify | | Devices | Read, Delete, Add, Control, Manage | | Groups | Read, Modify, Delete, Create | | Organization | Read, Manage | | Package | Read, Manage | | Patch Policy | Read, Modify, Delete, Create, Execute | | Personal API Keys | Manage | | Queries | Read, Manage | | Remediation | Read, Modify, Delete, Create, Execute | | Remote Control Consent | Manage | | Reports | Read | | Required Software Policy | Read, Modify, Delete, Create, Execute | | RBAC Roles | Read, Modify, Delete, Create, Grant, Revoke | | SAML | Read, Manage | | Scheduled Windows | Read, Modify, Delete, Create | | Software | Read | | 2FA (Two-factor authentication) | Read, Modify, Delete, Create | | Users | Read, Modify, Delete, Invite | | Worklets | Read, Modify, Delete, Create, Execute | ### 3. Organization Operator **Description**: Organization operators have full administrative rights for **policies**, **groups**, and **devices** in a specific organization. They can also conduct **remote control** sessions. | Function | Permissions | | --- | --- | | Agent Settings | Read | | Approval | Read, Update | | Devices | Read, Delete, Add, Control, Manage | | Groups | Read, Modify, Delete, Create | | Organization | Read | | Package | Read, Manage | | Patch Policy | Read, Modify, Delete, Create, Execute | | Personal API Keys | Manage | | Queries | Read, Manage | | Remediation | Read, Modify, Delete, Create, Execute | | Reports | Read | | Required Software Policy | Read, Modify, Delete, Create, Execute | | RBAC Roles | Read | | SAML | Read | | Scheduled Windows | Read, Modify, Delete, Create | | Software | Read | | Worklets | Read, Modify, Delete, Create, Execute | ### 4. Patch Operator **Description**: Patch operators can **create**, **modify**, and **delete** patch policies, **read** and run (**execute**) worklets and required software policies, and **read**, but not manage devices | Function | Permissions | | --- | --- | | Agent Settings | Read | | Devices | Read | | Groups | Read, Modify | | Organization | Read | | Package | Read | | Patch Policy | Read, Modify, Delete, Create, Execute | | Personal API Keys | Manage | | Queries | Read | | Remediation | Read | | Reports | Read | | Required Software Policy | Read, Execute | | RBAC Roles | Read | | SAML | Read | | Scheduled Windows | Read | | Software | Read | | Worklets | Read, Execute | ### 5. Helpdesk Operator **Description**: Helpdesk operators have full **read** rights within a specific organization. They can also conduct **remote control** sessions. | Function | Permissions | | --- | --- | | Agent Settings | Read | | Devices | Read, Control | | Groups | Read | | Organization | Read | | Package | Read | | Patch Policy | Read | | Personal API Keys | Manage | | Queries | Read | | Reports | Read | | Required Software Policy | Read | | RBAC Roles | Read | | SAML | Read | | Scheduled Windows | Read | | Software | Read | | Worklets | Read | ### 6. Billing Administrator **Description**: Billing administrators have full read rights and can **read** and **modify** **billing** information and subscriptions. | Function | Permissions | | --- | --- | | Billing | Read, Modify | | Devices | Read | | Groups | Read | | Organization | Read | | Package | Read | | Patch Policy | Read | | Personal API Keys | Manage | | Queries | Read | | Reports | Read | | Required Software Policy | Read | | RBAC Roles | Read | | SAML | Read | | Scheduled Windows | Read | | Software | Read | | Users | Read | | Worklets | Read | ### 7. Read Only **Description**: Users with this role can **read** all content within a organization. | Function | Permissions | | --- | --- | | Agent Settings | Read | | Billing | Read | | Devices | Read | | Groups | Read | | Organization | Read | | Package | Read | | Patch Policy | Read | | Personal API Keys | Manage | | Queries | Read | | Remediation | Read | | Reports | Read | | Required Software Policy | Read | | RBAC Roles | Read | | SAML | Read | | Scheduled Windows | Read | | Software | Read | | 2FA | Read | | Users | Read | | Worklets | Read | **Note**: Only you can decrypt your **personal API keys**; no role has the ability to decrypt an API key on behalf of another user. ## Custom User Roles Administrators and users with the required RBAC Roles permissions can create, delete, and assign **custom roles** with tailored permissions. **Prerequisites**: - **Account-Level Custom Roles**: To create or delete roles at the account level, you must have account-level permissions. These roles are not visible at the global or organization level. - **Global-Level Custom Roles**: To create or delete roles at the global level, you must have global-level permissions. Global-level roles are inherited by all organizations associated with the account. Refer to [Guidelines for Single Organization RBAC Management](Single_Org_RBAC_Guidelines.htm) if you are considering expanding your account. ### Creating a Custom User Role You can create a custom user role from the **Custom Roles** section of the **Account** or **Global (All Organizations)** page. **Important**: - Custom roles have no restrictions or safeguards, so be mindful of dependencies when assigning permissions. For example, a role managing devices must also include the ability to read device information to function properly. Always review permissions to ensure the role works as intended. - For feature-level requirements that are not shown in the permissions tables, see [Feature-Specific Access Requirements](#Feature-). - You can now delete a custom role from the list of custom roles. Deleting a role is permanent and cannot be reversed. See [Deleting a Custom User Role.](#Deleting) **Tip**: Use the [Duplicating a Role](#Duplicat) functionality to assist in creating custom roles. See also [Dependency Mapping](#Dependen). ![](../../Resources/Images/create-custom-role.png) 1. **Choose a role association**: - Choose whether the new role has **Account** or **Global (All Organizations)** permissions. - **Note**: Roles assigned within the **Setup & Configuration → Roles and Permissions** page are then available across all organizations. 2. **Select the create button**: - If you selected Account in the previous step, go to Custom Roles and select **Create Account Role**. - If you selected Global (All Organizations) in the previous step, go to Custom Roles and select **Create Global Role**. - **Note**: The available permissions differ between account and global roles. 3. **Define Role Name and Description**: - Enter a unique name for the role. - Write a brief description to explain the role's purpose. 4. **Select Base Permissions**: - Start with a set of base permissions similar to existing roles (for example, Patch Operator or Helpdesk Operator). - **Note**: You can also duplicate an existing role or custom role, and modify its permissions as needed. 5. **Customize Permissions:** - Add or remove specific permissions as needed. Permissions can include: - Read, Modify, Delete, Create permissions for different data types (for example: remediation, patch policies, RBAC) - Ability to manage specific settings such as manual approval, or remote control consent 6. **Assign Role to Users:** - Assign the custom role to one or more users. - **Note**: You can assign multiple roles to users simultaneously. ### Deleting a Custom User Role You can delete a custom user role from the **Custom Roles** section of the **Account** or **Global (All Organizations)** page. You must have the corresponding required permissions to delete global and account-level custom roles. 1. Locate the custom role you want to delete. 2. Under Actions, select **Delete Role**. 3. In the confirmation dialog, review the details and confirm that you want to delete the role. **Important**: Deleting a role is permanent and cannot be undone. - All users are removed from the deleted role. - If a user assigned to this role has another role assigned, only this role is removed and the other assignment remains. - If a user is only assigned to this role, deleting it leaves them unassigned to any role. - If you do not have the required permissions, the Delete Role option is disabled. - Automox **Default Roles** cannot be deleted. ### Legend The legend is available when you are creating or editing a custom role. This explains permissions for each function. Use it as a reference when creating custom roles to ensure proper access control. - **Add**: Permits appending new items or data to existing sets or collections. - **Control**: Provides the ability to initiate a remote control session. - **Create**: Allows the generation or addition of new information or data. - **Delete**: Provides the ability to remove information or data. - **Execute**: Allows performing or carrying out specific tasks or operations. - **Grant**: Allows you to add users to default and custom roles. - **Invite**: Allows the capability to invite others to join or participate in the console. - **Manage**: Enables comprehensive control, including configuring settings and overseeing operations. - **Modify**: Permits changing or editing existing information or data. - **Read**: Allows viewing and accessing information or data. - **Revoke**: Allows you to remove users from default and custom roles. - **Update**: Allows the user to approve or reject a patch. ### Custom Roles Table From the custom roles table, you can view the list of all created roles and their permissions. ![](../../Resources/Images/custom-roles-table.png) | Table Option | Description | | --- | --- | | Roles / Permissions | Click Roles to view all roles available. Click Permissions to view the corresponding permissions assigned to each custom role. | | Users Assigned to Role | This shows the number of users assigned this role. Click to open a list of assigned users. | | Add to Roles | Click to add users to this role. | | Actions | Duplicate Role: Select to create a copy of an existing custom role. Remove Users from Role: This dialog window allows you to select and remove users from this role. If a user has no other role, you must first assign a different role before you can remove them. Edit Role: Click to make any changes to the existing role. Delete Role: Click to delete the existing role. | ### Viewing a Custom Role Click the name of the custom role to view the details of the role. On the details page, you can edit the information or permissions, create a duplicate, or add or remove user assignments. - Save any changes or to exit this page, click **Back**. ### Duplicating a Role To simplify creating a new role, you can create a copy of an existing default or custom role and modify it as needed. ![](../../Resources/Images/duplicate-role.png) 1. From the **Roles** tab, find the role you want to use as a basis for a new custom role. 2. Under **Actions**, click **Duplicate Role**. This creates a copy of the role on the custom role page. 3. Edit the Custom Name and provide a description for the new role. 4. Make any adjustments to the permissions. (Ensure this is what you want before saving.) 5. Save and assign any users to the new role. ### Assigning Users to a Role You can add users to an existing role or a new role at the time of creating a custom role. 1. To add users to a role, select **Add to Role** for the corresponding role. 2. In the Add Users to Role window, select the email address for each user you want to assign the role to. 3. **Click Add User**. A notification appears in the console to confirm the status of the added role. 4. You can view the assigned users by clicking on the number in the Users Assigned to Role column. **Note**: Roles assigned within the **Setup & Configuration → Roles and Permissions** page are then available across all organizations. **Example**: When you assign the role Help Operator to a user from the global **Roles and Permissions** page, they appear as a Help Operator throughout all organizations related to the account. ### Removing Users from a Role You can remove users from a role at any time. **Note**: - You must have at least one user in the **Full Administrator** role at all times. If you want to remove a user from that role, you must assign the Full Administrator role to another user. - A user **can be removed from all roles**. If the user is removed and does not have a role assignment, they are still visible in the **Users** table and can be edited and added to a role by anyone with the required permissions. When the user logs into the console, a message appears that informs them to contact their administrator to be assigned a role. ![](../../Resources/Images/remove-user.png) You can remove users from a role in two ways: 1. Select **Actions → Remove Users from Role**. 2. In the **Remove Users from Role** dialog window, select the email address of each user you want to remove from the role. 3. Click **Remove User**. 4. Confirm the removal. You can also start from the **Users Assigned to Role** column. 1. Click the number in the **Users Assigned to Role** column. 2. In the dialog window, select the email address of each user you want to remove from the role. 3. Click **Remove User**. 4. A notification appears in the console to confirm the status of the revoked role. ## Example Custom User Roles ### 1. Global Worklet Manager **Description**: This Global Worklet Manager has full permissions associated with Worklets and can read reports. **Permissions**: - Read, modify, delete, create, and execute worklets - Read reports ### 2. Device Administrator **Description**: Device administrators can manage all aspects of managing devices for the organization they are assigned to. **Permissions**: - Read all device information. - Add, delete, and manage devices - Use remote control to manage devices remotely ### 3. HR Manager **Description**: HR Managers handle user management and administrative tasks related to employee data. **Permissions**: - Read, modify user accounts - Manage user roles and permissions - Limited access to billing and subscription details ## Dependency Mapping The following table shows examples of dependencies to consider when creating custom roles. Refer to [Default User Roles and Permissions](#Default). | Function | Dependency: Assign these permissions together | | --- | --- | | Remote control consent requires the ability to read devices. | Remote Control Consent: Manage Devices: Read | | To add a device requires the access key. You need permission to view the organization. | Devices: Add Organization: Read | | A policy manager might require group read permissions to be able to associate the policies they create to groups. | Patch Policy: Read, Modify Groups: Read | | A role with RBAC permissions also requires organization and user read permissions. | RBAC: Read Organization: Read Users: Read | | A role that can modify a user account requires other RBAC permissions. To be able to assign roles you need the following: | Users: Modify RBAC: Grant Organization: Read | | Billing administrators need the permission to read within the organization. | Billing: Read Organization: Read | | Group management (adding or editing groups) requires the ability to read devices. | Group: Read Group: Modify Devices: Read | | A role with permissions to read reports also requires the permission to read the organization. | Report: Read Organization: Read | ## Feature-Specific Access Requirements Some features in Automox require a combination of roles and permissions beyond what the standard permissions table showss. The following table lists common examples. ### Access within organizations Roles assigned at the organization level apply only to devices within that organization. | Feature | Dependency: These roles or permissions are required | | --- | --- | | Ask Otto | Enable Ask Otto: Account Administrator role, or a custom role with Account: Modify permission Use Ask Otto: Full Administrator or Organization Operator role, or a custom role with Worklets: Read, Create, Modify permissions Plan requirement: Must include Worklets | | Script Signing | Opt in to Script Signing: Account Administrator role, or a custom role with Organization: Create permission Use Script Signing: Full Administrator, Organization Operator, or a custom role with Worklets: Create, Execute permissions | | Secrets Management | View Secrets Management: All default global roles, or a custom role with Worklets: Read permission Use Secrets Management: Full Administrator, Organization Operator, or a custom role with Worklets: Create permission Plan requirement: Must include Worklets | | Query Management | View and create (but not save or delete) queries: All default global roles, or a custom role with Queries: Read permission Create and save queries, view, edit, delete saved queries: Full Administrator, Organization Operator, or a custom role with Queries: Manage permission Note: You can create a custom role without query read permissions. The assigned user would have no access to the Device Explorer | | Remote Control | Change Remote Control Consent behavior: Full Administrator, or a custom role with Remote Control Consent: manage Install / Uninstall Streamer (single device): Full Administrator, Helpdesk Operator, Organization Operator, or a custom role with Remote Control Actions: manage (device) Bulk Install / Uninstall Streamer: Full Administrator, or a custom role with Remote Control Deployment: manage View Streamer Deployment Settings: Full Administrator, Helpdesk Operator, Organization Operator, or a custom role with Remote Control Deployment: read Start Remote Control Session: Full Administrator, Helpdesk Operator, Organization Operator, or a custom role with Device: control | ## Known Issues and Caveats | Issue | Description | | --- | --- | | Removing a custom role | Resolved: You can now delete custom roles. See Deleting a Custom User Role. Previously, you could not remove a custom role. | | Role changes lag time | There may be a lag of up to 30 minutes between making organizational preference changes in the admin console and being able to see them reflected. | | Edit / Add Organization | A user might be listed multiple times if you assign them multiple roles within the same organization | | Use of basic auth for API calls breaks | Using basic auth for API calls breaks, and you must use an API Key or JWT. | | Removing a user from their last assigned role | You can remove a user from all roles. The user is then directed to a notification page alerting them to this. They will then need to contact their administrator. | ## Related Topics - [Guidelines for Single Organization RBAC Management](Single_Org_RBAC_Guidelines.htm) - [Understanding Global Access Management](Understanding_Global_Access_Management.htm) - Automox University: - [Managing Access with Custom Roles](https://university.automox.com/managing-access-with-custom-roles) - [Creating and Assigning a Custom Role Walkthrough](https://university.automox.com/creating-and-assigning-a-custom-role-walkthrough) --- # Guidelines for Single Organization RBAC Management _Section: Product Documentation › Global Access Management • Source: https://docs.automox.com/product/Content/Product%20Documentation/Global%20Access%20Management/Single_Org_RBAC_Guidelines.htm_ Managing role-based access control (RBAC) within a single organization requires a clear understanding of role assignments and permissions. This guide outlines best practices for assigning roles effectively, ensuring security, and planning for future growth. If you are considering expanding your account or are on a trial version, it is crucial to understand how roles function at both the global and organization levels. Refer to [Roles and Permissions Management](Roles_and_Permissions.htm) for details about creating roles. ## Understanding Role Assignments When managing roles within a single organization, you must distinguish between **global roles** and **organization-specific roles**, as this impacts future access control. ![](../../Resources/Images/role-permissions-users-orgs.png) ### Global Roles - You can only assign **Account** and **Global** roles from the **Setup & Configuration** pages: - **Roles and Permissions** page: **Add to Role** - **Users** page: **Add User** or click the email to open the **Edit User** page - These roles apply across all current and future organizations added to the account. - A role assigned at the **global level** is inherited by any future organizations. **Example**: When a global Full Administrator role is assigned to a user, that user will have these permissions for all new organizations added to the account. - When you assign a global role to a user from the organization-level **Settings > Users** page, that role is then limited to that specific organization. ### Organization-Level Roles You can limit the permissions of any user to just **one organization**. You can configure this setting in two ways: 1. From the **Setup & Configuration > Users** page (see previous image), select **Add User** and under **Organizations** select the organization and role you want the user to have access to. You can select more than one organization or role, as needed. 2. You can also assign user roles from an organization’s **Settings > Users** page. Select **Add User** and select from the roles available. Any role selected here is only applicable to the specific organization. **Note**: This is useful for an administrative user role that is limited to one organization. With the corresponding permissions to assign roles to other users, that administrator will be able to assign roles within the specific organization. ![](../../Resources/Images/single-org-add-user.png) - If you do not want roles to be automatically inherited across all future organizations, ensure that you assign roles at the organization level rather than global level. ## Role Management Best Practices To effectively manage role-based access control (RBAC) within a single organization, consider the following best practices: ### Assess Access Needs - Evaluate the access requirements of each role based on job functions. - Identify necessary permissions to ensure employees can perform their responsibilities without excessive access. ### Define Clear Roles Based on Job Functions - Create roles that align with specific job responsibilities. - Avoid unnecessary overlap between roles to maintain clarity in access control. ### Apply the Least Privilege Principle - Grant only the minimum necessary permissions required for a role to perform its duties. - Reduce security risks by limiting unnecessary access. ### Audit Access Regularly - Conduct periodic reviews of role assignments and permissions. - Ensure users have appropriate access levels as roles evolve within the organization. ## Related Topics - [Roles and Permissions Management](Roles_and_Permissions.htm) --- # Understanding Global Access Management _Section: Product Documentation › Global Access Management • Source: https://docs.automox.com/product/Content/Product%20Documentation/Global%20Access%20Management/Understanding_Global_Access_Management.htm_ Global access management allows an **Account Administrator** or a **(Global) Full Administrator** of a company's IT infrastructure to manage all organizations and users from a centralized Global View. **Account administrators** have the following permissions: - Manage all aspects of an account - View all users for all organizations - Create and manage organizations - Add, modify, and remove users - Create custom roles at the Account level and assign or remove users from roles **Full administrators** at the global level have the following permissions: - View all users for all organizations - View and manage all organizations - Add, modify, and remove users - Create custom roles at the Global level and assign or remove users from roles To access the Setup & Configuration page, click the **Global View** button where organizations are listed. Select **Manage Orgs and Users** from the menu. ![](../../Resources/Images/global-view.png) For more information about these roles, refer to [Roles and Permissions Management](Roles_and_Permissions.htm). ## Related Topics - [Managing Global Keys](Managing Global Keys.htm) - [Managing Organizations](Managing_Organizations.htm) - [Managing Users](Managing_Users.htm) - [Global Session Expiration Settings](Global_Session_Settings.htm) - [Roles and Permissions Management](Roles_and_Permissions.htm) --- # Managing Groups _Section: Product Documentation › Group Management • Source: https://docs.automox.com/product/Content/Product%20Documentation/Group%20Management/Managing_Groups.htm_ You can organize and manage systems updates using groups. You access these group settings from the main console by clicking **Manage → Groups**. You can arrange groups by department or geography, or whatever makes sense for your organization. You can use groups to form a test group. Patches can then run against this group for a specified period of time after which those same patches can be rolled to another group or into production automatically. Software can also be deployed by group. ## Viewing Groups You can view a list of all groups in your organization from the **Manage → Groups** page. - To access this page, select the **Manage** tab and then select **Groups** from the drop-down menu. - From the Groups page, use the Search **Groups** field to search for groups. - Click the **Unused Groups** tile to toggle between all groups and the groups that are not in use. ## Creating a Group You can create a new group to manage devices according to your needs. 1. From the Groups or **Devices** page, click **Create Group**. 2. In the Create Group dialog window, enter a **name** for your new group and select **Create**. You have now created a group that uses default settings. The Edit Group page opens. To save the new group with only default settings, click **Update Group**. ![](../../Resources/Images/edit-group.png) ## Editing a Group The Edit Group page includes four configurable sections: Info, OS Patch Management, Devices, and Policies. These are described in the following sections. **Note**: To save all changes made in the Edit Group page, click **Update Group**. ### Info Configure the group Info fields, as needed: | Field Name | Description | | --- | --- | | Group Name | This field is automatically populated when you first create the group. You can click in this field to make any changes. The name must be 45 characters or less. The following special characters are not allowed: < > { } / \ | | Parent Group | To choose the group structure, click the drop-down menu and select from existing groups. Selecting anything other than Default creates a subgroup. Subgroups help to better distinguish different groups in the Automox console. There is no policy inheritance between a Parent Group and any Subgroups. | | Scan Interval | To change the scan interval, click the drop-down menu. The default is 24 hours. The scan interval indicates how often Automox re-inventories a device for hardware, software, system information, and available patches. | | Group Color | For easier management, go to the Group Color field and select a color to better identify the group. This includes a customizable group color pane. | | Note | Add a note, if required. | ### OS Patch Management Select how you want to handle patching for the devices in this group. - **Windows and macOS Patch Management:** - Use this field to configure automatic update settings for devices. - **Windows Update Source:** - Use this field to configure the source from which Windows devices pull updates. For further details, see [OS Patch Management Settings for Groups](OS_Patch_Management_Settings_for_Groups.htm) #### Devices / Policies The **Devices** and **Policies** sections are described in detail below. After you make all required updates, click **Update Group**. The new group membership can be viewed from the Group Membership column of the Devices page. ## Assigning Devices to a Group To assign a device to a group, follow these steps. **Note**: Administrative privileges required. The deployment tool or target device must have administrative privileges to successfully deploy and install the Automox Agent. You can assign devices to only one group at a time. When you assign a device to a group, but it is already in another group, it will be moved to the new group. 1. From the Groups page, find the group you want to add a device to and click the name to open the Edit Group page. 2. From the Devices area of the Edit Group page, click **Assign Devices**. 3. In the **Assign Devices to Group** dialog window, select the checkbox for the devices you want to add to the group. Click **Assign Devices To Group**. 4. Click **Update Group**. ## Removing Devices from a Group You can remove devices from a group. A device must be assigned to a group, therefore, if no other assignment is made, the device will be assigned to the Default group. 1. From the Groups page, find the group you want to edit and click the name to open the **Edit Group page**. 2. From the Devices area, select the checkbox for the device that you want to remove. 3. Click **Move Selected To Group**. 4. Click **Update Group**. ## Viewing Devices Assigned to a Group You can view devices assigned to a group. - From the Groups page, find the group you want to view details for and click the name to open the **Edit Group page**. - The list of devices is available in the Devices area of the page. - For more information about the columns of this table, see [Viewing Software Inventory](../Software/Viewing_Software_Inventory.htm). - To modify the information listed, click the **Columns** button and clear any column names you want to leave out. The table adjusts automatically. ## Associating Policies With a Group The Policies section shows any policies associated with this group. When you associate a policy with a group, the group patches according to the schedule of the policy. 1. To associate a policy with this group, click **Associate Policies**. 2. In the Associate Policies dialog window, select the policy or policies that you want to associate this group with. 3. Click **Update Group.** ## Filtering Groups You can use the search filter to view a list of groups from the Devices page. 1. From the **Devices** page, go to the search field and enter the group name. For more about the enhanced search available, see Enhanced Device Search in [Filtering and Searching on the Devices Page](../Device Management/Filtering_and_Searching_on_the_Devices_Page.htm). 2. From the Groups page, enter the names into the Group search field to view the desired group. ## Related Topics - [Managing Policies](../Policies/Managing_Policies.htm) --- # OS Patch Management Settings for Groups _Section: Product Documentation › Group Management • Source: https://docs.automox.com/product/Content/Product%20Documentation/Group%20Management/OS_Patch_Management_Settings_for_Groups.htm_ You can configure how you want to handle patching for the devices in a group. 1. Go to **Manage → Groups.** 2. Click the name of the Group to open the **Edit Group** page. 3. In the OS Patch Management area, configure the settings for the respective group according to the following: **Windows and macOS Patch Management** Use this field to configure automatic update settings for devices. By default, devices from Microsoft and Apple are configured to patch any automatic updates that may become available. As these automatic updates can interfere with the Automox patching process, Automox recommends disabling automatic updates when possible. ![](../../Resources/Images/groups-os-patch-management.png) 4. Click the drop-down menu to select from the following configuration options: - **Keep Device’s Setting**: Automox does not modify the automatic update configuration for the device. Whatever is configured on the device will persist when it is added to the respective group. - **Disable OS automatic updates**: Automox modifies the device configuration by disabling automatic updates. This configuration will persist. If the device configuration changes, it will be changed back during the next scan. - **Enable OS automatic updates**: Automox modifies the device configuration by enabling automatic updates. This configuration will persist. If the device configuration changes, it will be changed back during the next scan. 5. **Windows Update Source** Use the **Windows Update Source** field to configure the source from which Windows devices pull updates. By default, Microsoft distributes their devices to use the Windows Update catalog for pulling updates. ![](../../Resources/Images/groups-wu-source.png) 1. Click the drop-down menu to select from the following configuration options: - **Keep Device’s Setting:** Automox does not modify the update source configured on the device. Whatever is configured on the device will persist when it is added to the respective group. - **Windows Update:** Automox will modify the device configuration to use the Windows Update Catalog as its update source. The configuration will persist, whenever an endpoint configuration changes it will be changed back during the next scan. - **WSUS:** Automox will modify the device configuration to use a WSUS server. This option should only be selected if you already have a WSUS environment configured in your domain. When this option is selected a third field will appear as described in the following: - **WSUS Server Address:** This field is used to provide the WSUS server URL that will be used when configuring a device to use WSUS. (for example, [http://Lab-WSUS:8530](http://lab-wsus:8530/)) ![](../../Resources/Images/groups-wsus-server.png) | 6. Click **Update Group** to save these settings. **Windows Environment Advisory:** These settings can be, and often are, configured through Group Policies (GPOs) in a Windows domain/enterprise environment. Avoid using Automox and GPOs to configure these settings concurrently. The GPO takes precedence in such a scenario. Therefore, if you are already using GPOs to configure these settings, select **Keep Device’s Setting** for the fields described earlier in this topic --- # Agent Versioning and Support _Section: Product Documentation › Maintenance Policy and Agent Update Policy • Source: https://docs.automox.com/product/Content/Product%20Documentation/Maintenance%20Policy%20and%20Agent%20Update%20Policy/Agent_Versioning_and_Support.htm_ ## Agent Versioning The Automox agent follows industry standards for Major, Minor, and Patch. ![](../../Resources/Images/major-minor-patch.png) ### Major Version Number In general, a major version means a release of an Automox agent that contains substantial changes in functionality, code, or compatibility and incorporates any existing previous release or fixes. Unless otherwise specified for a particular product, a version is designated by the number to the left of the decimal point such as 1.0, 2.0, 3.0, etc. ### Minor Version Number The minor version number means a release of an Automox agent which may contain minor new product functionality, code, or compatibility and incorporates any previous fixes since the last version. Unless otherwise specified for a particular product, a release is tied to the preceding version and is designated by a number to the right of the decimal point such as 1.1, 1.2, 1.3, etc. ### Patch Version The patch version number means a release of the Automox agent that includes defect fixes only since the last minor release. Unless otherwise specified for a particular product, the patch version is tied to the preceding Major. Minor version and is designated by the number to the right of the minor version number such as 2.1.12, 2.1.25, 2.1.37, etc. ## Version Support Process / Policy ### Support Scope Automox defines Agent support and deprecation at the **major.minor version level** (for example, 4.2). Patch releases (for example, 4.2.14 or 4.2.37) inherit the lifecycle of their parent major.minor version and do not reset or extend support timelines. ### Active Support Each Automox Agent **major.minor** version is supported for at least **12 months from General Availability (GA)**. During Active Support, Automox provides: - Security updates - Critical bug fixes - Compatibility updates - Standard technical support ### End-of-Support/Life (EOS/EOL) #### End of Support (EOS) After the Active Support period, a version enters **End of Support (EOS)**. At EOS: - Automox provides no further bug fixes or enhancements. - Automox may provide security fixes at its discretion. - Support may require upgrade as a prerequisite for investigation. #### End of Life (EOL) After EOS, a version proceeds to **End of Life (EOL)** following a defined deprecation window. At EOL: - The agent version is fully unsupported. - Automox may prevent it from connecting to the Automox platform. - Automox may enforce automatic upgrades where supported. - Support and Engineering do not investigate issues. #### Deprecation Timeline Automox provides clear notice before EOS and EOL: - **At least 3 months’ notice before EOS.** - **At least 6 months’ notice before EOL.** Automox calculates dates in **whole calendar months**, with EOS and EOL occurring at the end of the applicable month #### Agent EOS/EOL List | Agent Version | EOS Date | EOL Date | | --- | --- | --- | | All versions < 2.0.28 | June 15, 2025 | October 15, 2025 | | All versions between 2.0.28 and 2.1 | May 31, 2026 | August 31, 2026 | | 2.1 | May 31, 2026 | August 31, 2026 | | 2.2 | -- | -- | | 2.3 | -- | -- | | 2.4 | -- | -- | | 2.5 | -- | -- | | 2.6 | -- | -- | ## Related Topics - [Manually Upgrading Your Automox Agent](https://help.automox.com/hc/en-us/articles/31577944392596-Manually-Upgrading-Your-Automox-Agent#h_01JJ7RBNM1G87QW6TVWERB8QT8) - [Automox Agent 1.x End of Support - June 15, 2025](https://help.automox.com/hc/en-us/articles/37950277862548-Automox-Agent-1-x-End-of-Support-June-15-2025) - [Managing Agent Configurations](../Settings/Managing Agent Configurations.htm) - [Troubleshooting - Agent is Not Auto Updating](https://help.automox.com/hc/en-us/articles/31577828559380-Agent-is-Not-Auto-Updating) --- # Automox Agent Update Policy _Section: Product Documentation › Maintenance Policy and Agent Update Policy • Source: https://docs.automox.com/product/Content/Product%20Documentation/Maintenance%20Policy%20and%20Agent%20Update%20Policy/Automox_Agent_Update_Policy.htm_ Automox automatically updates its device agents to ensure that you always have the latest Automox platform functionality. Refer to [Managing Agent Configurations](../Settings/Managing Agent Configurations.htm) for information on how to manage or defer agent updates. **Note:** If an Automox device agent update is necessary to remediate a critical security vulnerability, then Automox notifies all customers and automatically updates device agents. ## Related Topics - [Agent Versioning and Support](Agent_Versioning_and_Support.htm) - [Managing Agent Configurations](../Settings/Managing Agent Configurations.htm) --- # Customer Data Deletion _Section: Product Documentation › Maintenance Policy and Agent Update Policy • Source: https://docs.automox.com/product/Content/Product%20Documentation/Maintenance%20Policy%20and%20Agent%20Update%20Policy/Customer_Data_Deletion.htm_ After your subscription term ends, your account is locked and you are unable to access or use the Automox platform. 60 days after your subscription term ends, Automox begins an automated data deletion process. The automated data deletion process deletes Customer Data no later than 90 days after your subscription term ends. --- # Maintenance Policy _Section: Product Documentation › Maintenance Policy and Agent Update Policy • Source: https://docs.automox.com/product/Content/Product%20Documentation/Maintenance%20Policy%20and%20Agent%20Update%20Policy/Maintenance_Policy.htm_ Automox conducts regularly scheduled preventive maintenance and upgrades to the Automox platform. Monthly maintenance windows can happen on the **Thursday of the week following Patch Tuesday** each month (barring any other conflicts) **from 8 PM - midnight Eastern Time (US)** for planned maintenance windows, if one is necessary. The default duration is approximately **4 hours**, but Automox can expand it if needed, with notice, depending on the nature of the operations. Expect intermittent disruptions to the Automox console and API, as well as policy execution, during these maintenance windows. You can track updates at [status.automox.com](http://status.automox.com/). --- # Adding Patches to the Block List in the Automox Console _Section: Product Documentation › Miscellaneous • Source: https://docs.automox.com/product/Content/Product%20Documentation/Miscellaneous/Adding_Patches_to_the_Block_List_in_the_Automox_Console.htm_ You can block a patch from running from the Device Details page or Software page using the Bulk Actions or Actions menu for the patch in question. On the **Device Details** page, the list of software and patches appears at the bottom of the page: 1. Select the checkbox for the software you want to block. 2. Select Ignore from the **Bulk Actions** drop-down menu. 3. Confirm the selection. ![](../../Resources/Images/software-ignore.png) On the **Software** page, you can also use the Actions drop-down menu to ignore the patch. - Select **Ignore** from the Actions menu. **Note**: No confirmation message appears, and the change is effective immediately. ![](../../Resources/Images/software-page-ignore.png) ## Related Topics - [Device Details](../Device Management/Device_Details.htm) - [Viewing Software Inventory](../Software/Viewing_Software_Inventory.htm) --- # Automox REST-based API _Section: Product Documentation › Miscellaneous • Source: https://docs.automox.com/product/Content/Product%20Documentation/Miscellaneous/Automox_REST_based_API.htm_ Automox has a complete REST-based API built into the core of the product. The Automox API is a powerful interface that allows you to integrate Automox reporting data into your applications and control the various settings of your account. See the [Automox API Reference](../../Developer/Automox API Reference.htm). --- # Automox Status Board _Section: Product Documentation › Miscellaneous • Source: https://docs.automox.com/product/Content/Product%20Documentation/Miscellaneous/Automox_Status_Board.htm_ The **Automox System Status** page provides the current status and incident history for Automox systems. You can subscribe to receive updates through email, text message, Slack, Atom, and RSS feeds: [Automox Status Page](https://status.automox.com/) ![](../../Resources/Images/status-board.png) --- # Billing Policy for Agents on Virtual Instances _Section: Product Documentation › Miscellaneous • Source: https://docs.automox.com/product/Content/Product%20Documentation/Miscellaneous/Billing_Policy_for_Agents_on_Virtual_Instances.htm_ This describes how Automox bills agents on virtual machine (VM) instances. Keep in mind that if Automox agents are part of your VM image build, those agents check in as unique and become active when you launch any temporary or test instances. Avoid overage charges by monitoring your device usage and removing unwanted, test, or dormant instances. Automox uses your total number of unique instances at the end of the month to calculate your bill. Deregister agents by the 25th of each month at 0:00 UTC to avoid charges. ## Deregistering the Agent Using the command line or terminal, run the following command corresponding to your operating system: ### macOS sudo /usr/local/bin/amagent --deregister ### Windows "C:\Program Files (x86)\Automox\amagent.exe" --deregister ### Linux sudo /opt/amagent/amagent –-deregister Agent re-registration happens automatically when you run this command again. If the device was listed on the Devices page of the console, the device entry is automatically updated with the new registration identity. If the device was previously deleted from the Devices page, deregistering the device adds it back to the list of devices being managed by Automox. --- # How to Roll Back an Installed Patch on Devices _Section: Product Documentation › Miscellaneous • Source: https://docs.automox.com/product/Content/Product%20Documentation/Miscellaneous/How_to_Roll_Back_an_Installed_Patch_on_Devices.htm_ On occasion, it might be necessary to uninstall a recently applied patch due to unexpected system instability or application errors following patch installation. A feature that is currently only available for Windows-based devices, an Automox patch rollback is an reliable way to "undo" the installation of unstable or undesired patches. - Rolling back a patch is currently only available for Windows-based devices. - **Note:** Not all patches can be rolled back. ## Removing a Patch Using the Automox Console To roll back an installed patch in the Automox console, first navigate to the target device's **Device Details** page and scroll down to the **Software** section. When you locate the patch you would like to roll back, select it and the **Bulk****Actions**drop-down menu. Click **Roll Back**. Keep in mind that this is an inherently risky process that can cause operating system or application failures, so Automox highly recommends testing rollbacks before applying them to critical systems. ![](../../Resources/Images/rollback-patch.png) ## Removing a Patch Using the Rollback Windows Patches Worklet Another option is to use the Automox Verified Worklet called Rollback Windows Patches. 1. In the console, go to **Automate → Worklet Catalog.** 2. Search for and select **Rollback Windows Patches**. 3. Select the **Code Preview** arrow to open the Evaluation and Remediation Code details. 4. This worklet removes one or multiple KBs from a device. Add KBs by placing the KB number (for example, KB1234567) between single quotes in the `$KBNumbers` variable. ![](../../Resources/Images/select-worklet.png) ![](../../Resources/Images/rollback-worklet.png) If you want to block a released patch, refer to [Adding Patches to the Block List in the Automox Console](Adding_Patches_to_the_Block_List_in_the_Automox_Console.htm). This reduces the remediation footprint. ## Uninstallable Patches Not all patches can be rolled back. To be flagged as *uninstallable*, a patch must meet the following criteria: - The target device's operating system must be Windows Server 2008 R2/Windows 7 or newer - The applied patch must have an associated Knowledge Base article identifier - The applied patch must have been installed with Windows Update, Microsoft Update, or Windows Server Update Services - The package must be specifically marked as uninstallable For more information, refer to Microsoft's [Uninstallable Patches](https://docs.microsoft.com/en-us/windows/desktop/Msi/uninstallable-patches) documentation. ## Related Topics - [Windows Patch Rollback Worklet](../Worklets & Required Software/Windows_Patch_Rollback_Worklet.htm) - [Adding Patches to the Block List in the Automox Console](Adding_Patches_to_the_Block_List_in_the_Automox_Console.htm) --- # Allowing Automox Notifications in macOS (Starting with Catalina) _Section: Product Documentation › Notifications & Restarts • Source: https://docs.automox.com/product/Content/Product%20Documentation/Notifications%20%26%20Restarts/Allowing_Automox_Notifications_in_macOS__Starting_with_Catalina_.htm_ You can use your MDM to force allow first time Automox notifications for macOS computers starting with 10.15 (Catalina). ![](../../Resources/Images/allow-automox-notifications-with-button.png) Privacy controls in macOS starting with macOS 10.15 (Catalina) require users to allow or deny new notification center messages. For macOS computers—this includes 10.15, 11, and 12 (Catalina, Big Sur, and Monterey)—users might not see the first Automox notification sent even if Allow is selected. If you use a Mobile Device Manager (MDM), you can push out a notifications payload to force allow all Automox notifications. Currently, Apple allows only one notifications payload per device, so you must include Automox notification settings in any existing notifications payloads. **Note**: The preferred domain for notifications is *com.apple.notificationsettings* ## How to Generate the `payloadUUID` for Your Mac 1. Run `uuidgen` to generate the `payloadUUID` for your specific Mac. This should also generate a `payloadIdentifier` key. 2. Replace the given `payloadUUID` and `payloadIdentifier` with those you have generated. For more information about `payloadUUID` and configuration profiles, please see the [Apple Developer Documentation](https://developer.apple.com/documentation/devicemanagement/configuring_multiple_devices_using_profiles). ## Example - Automox Notifications MDM payload PayloadContent NotificationSettings AlertType 2 BadgesEnabled BundleIdentifier com.automox.automox-notifier CriticalAlertEnabled GroupingType 0 NotificationsEnabled ShowInLockScreen ShowInNotificationCenter SoundsEnabled PayloadDescription Configures notifications settings for Automox PayloadDisplayName Configures notifications settings for Automox PayloadIdentifier com.apple.notificationsettings.AE35A3DC-56BC-48EB-8C4D-F4C5AE4D1C5C PayloadType com.apple.notificationsettings PayloadUUID AE35A3DC-56BC-48EB-8C4D-F4C5AE4D1C5C PayloadVersion 1 PayloadDisplayName Set Automox Notifications PayloadIdentifier com.automox.notifications PayloadRemovalDisallowed PayloadType Configuration PayloadScope System PayloadUUID 9BDB7BAF-A3D0-4231-89DB-029D2A3745C2 PayloadVersion 1 ## Adding Automox to your existing Notifications payload If you need to add Automox to your existing notifications payload, add the following to your existing payload: AlertType 2 BadgesEnabled BundleIdentifier com.automox.automox-notifier CriticalAlertEnabled GroupingType 0 NotificationsEnabled ShowInLockScreen ShowInNotificationCenter SoundsEnabled ### Example - allow notifications for Microsoft Office and Automox PayloadContent NotificationSettings AlertType 2 BadgesEnabled BundleIdentifier com.automox.automox-notifier CriticalAlertEnabled GroupingType 0 NotificationsEnabled ShowInLockScreen ShowInNotificationCenter SoundsEnabled AlertType 2 BadgesEnabled BundleIdentifier com.microsoft.Word CriticalAlertEnabled GroupingType 0 NotificationsEnabled ShowInLockScreen ShowInNotificationCenter SoundsEnabled AlertType 1 BadgesEnabled BundleIdentifier com.microsoft.Excel CriticalAlertEnabled GroupingType 0 NotificationsEnabled ShowInLockScreen ShowInNotificationCenter SoundsEnabled PayloadDescription Configures notifications settings for Automox PayloadDisplayName Configures notifications settings for Automox PayloadIdentifier com.apple.notificationsettings.AE35A3DC-56BC-48EB-8C4D-F4C5AE4D1C5C PayloadType com.apple.notificationsettings PayloadUUID AE35A3DC-56BC-48EB-8C4D-F4C5AE4D1C5C PayloadVersion 1 PayloadDisplayName Set Automox Notifications PayloadIdentifier com.automox.notifications PayloadRemovalDisallowed PayloadType Configuration PayloadScope System PayloadUUID 9BDB7BAF-A3D0-4231-89DB-029D2A3745C2 PayloadVersion 1 --- # Allowing Automox Notifications on macOS When Screen Sharing _Section: Product Documentation › Notifications & Restarts • Source: https://docs.automox.com/product/Content/Product%20Documentation/Notifications%20%26%20Restarts/Allowing_Automox_Notifications_on_macOS_When_Screen_Sharing.htm_ The macOS Notifications Center requires an extra step to allow Automox Notifications to appear during screen sharing sessions. To allow notifications during shared sessions, do the following: 1. On your computer, go to **System Settings** and select **Notifications**. 2. Switch on the toggle for **Allow notifications when mirroring or sharing the display** This ensures that notifications appear in the top-right corner of your screen when mirroring or sharing. ![](../../Resources/Images/allow-when-mirroring.png) ## Related Topics - [Managing End-User Notifications](Managing_End_User_Notifications.htm) --- # Automox Tray and End-User Notifications FAQ _Section: Product Documentation › Notifications & Restarts • Source: https://docs.automox.com/product/Content/Product%20Documentation/Notifications%20%26%20Restarts/Automox%20Tray%20FAQ.htm_ These are common questions users may ask, which administrators should be prepared to answer. ## Why is there an Automox Tray on my device? The tray is required to manage software updates and restart requirements. It is part of your organization's policy for keeping systems secure and up to date. ## Can I dismiss or delay a restart notification? No. Notifications are scheduled based on policy, and cannot be snoozed or turned off. The restart happens automatically if not completed before the deadline. ## Why does the tray still show I need to restart even though I already restarted? For patch policies, starting with **2.3.34**, you can restart your device using either the **Restart Now** button in the Automox tray or the standard restart option in your operating system (such as the Start menu in Windows or the Apple menu in macOS). In most cases, the tray will recognize the restart and the message will clear automatically. Beginning with agent version **2.4**, the same behavior applies to worklets that require a restart. Restarts are recognized whether you use the Automox tray or your operating system’s restart option. If the tray still shows that a restart is required after you have restarted, contact your IT administrator or Automox Support for assistance. ## What if I see "Installation in Progress" for a long time? This can happen if the device was offline during the scheduled update. A restart from the tray should resolve the status. If it does not, users should contact IT support. ## Can I disable the Automox Tray? Starting with Agent 2.3.34, a [worklet](Tray Customization Worklets.htm) is available to disable the Automox Tray on **Windows** devices. This gives flexibility in environments where the tray is not required or should be temporarily suppressed. Outside of this worklet, the tray remains a required component to support deadline-based notifications and ensure users comply with update and restart policies. ## Is there a way to suppress pop-up reminders from occurring? (For example, when a manager wasn't able to patch in the morning and is about to present for two hours.) You cannot currently suppress pop-up reminders. A few options can help you avoid it. - You can disable update and restart notifications in the policy configuration. - For **Windows** systems, you can disable the tray through a worklet. ## Can the tray be customized? - The Automox tray supports custom notification text from IT admins. Any custom messaging configured in existing policies appear in the tray. - Starting with 2.3.34, you can replace the text "Managed by your IT Administrator" with your own custom text. See [Tray Customization Worklets](Tray Customization Worklets.htm) for more information about customizing the Automox tray. ## Why is there a delay when I change Do Not Disturb (DND) on my Mac? On macOS, changes to Do Not Disturb (enabling or disabling) take about 30 seconds before the Automox tray reflects the new state. This delay does not occur on Windows. See also: [End-User Notifications](End_User_Notifications.htm) for details about configuring Do Not Disturb (DND) in policies. ## What happens if multiple policies are scheduled on my device? When multiple policies are scheduled on a device, the Automox tray displays notifications tied to the deadline of the first policy that will run. ## Related Topics - [End-User Notifications](End_User_Notifications.htm) - [Tray Customization Worklets](Tray Customization Worklets.htm) --- # Deploying Automox Notification Configuration Profile via Jamf Pro _Section: Product Documentation › Notifications & Restarts • Source: https://docs.automox.com/product/Content/Product%20Documentation/Notifications%20%26%20Restarts/Deploying_Automox_Notification_Configuration_Profile_via_Jamf_Pro.htm_ Automox You can solve this by either creating a new Configuration Profile in Jamf or amending an existing one. ## Create or amend a Configuration Profile To create or amend the configuration in Jamf Pro, navigate to **Configuration Profiles.**Select to add or edit the existing profile then select**Notifications**. Use the configuration listed here: | Payload Configuration | | --- | | App Name: Automox | | Bundle ID: com.automox.automox-notifier | | Critical Alerts: Enabled | | Notifications: Enabled | | Banner alert type: Persistent | | Notifications on Lock screen: Display | | Notifications in Notification Center: Display | | Badge app icon: Display | | Play sound for notifications: Enable | ![](../../Resources/Images/jamf-ax-notifications.png) When configured properly, this is what the settings look like on the device under **System Settings → Notifications:** ![](../../Resources/Images/axnotifier-settings.png) **Note**: If a device has never had an Automox --- # End-User Notifications _Section: Product Documentation › Notifications & Restarts • Source: https://docs.automox.com/product/Content/Product%20Documentation/Notifications%20%26%20Restarts/End_User_Notifications.htm_ ## Configuring Policies and Understanding Tray Behavior This guide explains how to configure Automox policies that deliver update and restart notifications to end users through the Automox Tray. These notifications are **deadline-based**, giving users a defined window to install updates or restart their devices before enforcement occurs. The guide also outlines what users will see in the tray so administrators can anticipate the end-user experience and ensure compliance with patching requirements. ## Part 1: Setting Up End-User Notifications in a Policy ### Overview Automox uses policy settings to control whether users receive notifications for installing updates and restarting their devices. These notifications are delivered through the Automox tray on Windows and macOS. ![](../../Resources/Images/example-tray-callouts.png) **Important:** The Automox Tray works out of the box with your existing policies–no changes are required for it to function. It automatically reads the deferral settings from your current patch and restart policies and uses them to calculate and display a single restart deadline to end users. **Custom notification messaging is supported**: Policy-configured messages (such as restart warnings or app closure notices) appear in the **upper section** of the tray notification. **Customizable default messaging**: You can use a **worklet** to update the **bottom section** of the tray message. This area can display a trusted message **provided by an authorized IT administrator or service provider**. This requires Agent version 2.3.34. **Prerequisites**: - Devices must have **Automox Agent version 2.2.24** or later installed. See [Agent 2.2.24 Release Notes](../Release Notes/Agent Release Notes/Agent 2.2.x Release Notes.htm). - You must have the required permissions to configure policies. See [Roles and Permissions Management](../Global Access Management/Roles_and_Permissions.htm). ## Default User Notifications You can access a policy and view the user notification settings from the **Automate → Policies** page in the console. This table lists the **default settings** and their descriptions for when you create a new policy. Be aware that there are behavioral differences compared to the previous notification management. (If you have an agent version earlier than 2.1.44, refer to [Managing End-User Notifications](Managing_End_User_Notifications.htm)). | Default User Notification Settings | Description | Console View | | --- | --- | --- | | Enable automatic restart after updates are installed | This is selected by default. This means that (for updates that require a restart) after an update, the device automatically restarts the operating system. | | | Install Notification Settings | This is on by default. End users receive a tray notification when an update is available. The corresponding message can be customized. See Custom Install Notifications. | | | Before installing any update | This is selected by default. The notification message is sent before any update install. | | | Do Not Disturb (DND) | You can configure how notifications are handled when a device has Do Not Disturb (DND) enabled. The default setting is Bypass DND: Notifications are always shown, even if the end user has DND enabled. See Do Not Disturb (DND)for details. | | | Install Deadline | This represents the amount of time the user has to complete the installation. | | | Restart Notification Settings | This is on by default. If the update requires a restart, the end users receive a tray notification, as described in Part 2: What Users See in the Automox Tray. The corresponding message can be customized. See Custom Restart Notifications. | | | Restart Deadline | This represents the amount of time the user has to complete the restart from the tray prompt. | | ### What to expect for default user notifications If you choose to use the **default settings** for a policy, the end user can expect the following: **Prerequisites**: The associated policy is active and scheduled. **For Install Updates**: - The end user has this entire time to complete the installation. - At the deadline, the installation of updates starts for the end user. **For Restart Updates**: - The end user has this entire time to complete the restart. - The restart installation starts after software installation is complete. - At the deadline, the restart installation starts for the end user. Refer to [Part 2: What Users See in the Automox Tray](#Part) for details about what a user experiences. ## How to Configure User Notifications Follow these steps to configure end-user notifications that are **based on a deadline**. ### Create or Edit a Policy 1. Navigate to the **Policies** section in the Automox console. 2. Create a new policy or edit an existing one that governs update and restart behavior for your target devices. 3. Go to **User Notifications → Automatic Restart**: - Select **Enable automatic restart after updates are installed** if you want the device to restart automatically after updates are applied. - Select **Do not enable automatic restart after updates are installed** if you want the user to manually initiate the restart. ![](../../Resources/Images/user-notifications-auto-restart.png) ### Enable End-User Notifications Two user notification settings are available. You can enable one or both depending on how much control you want to give the user. **Note:** Policies configured with no end-user notifications will always execute on their defined schedule, even if an Interactive policy (one with notifications enabled) is currently blocked in a "Pending User" or deferral state. How the system handles the execution and endpoint restarts depends on the policy's Automatic Restart configuration: 1. **Silent Policies (Automatic Restart: Disabled)** - **Background Execution:** The policy executes background updates immediately without waiting for the user to approve prompts or complete actions from other active policies. - **Restart Handling:** Because Automatic Restart is disabled, these policies will never trigger a system restart. 2. **Silent Automated Policies (Automatic Restart: Enabled)** - **Background Execution:** The policy bypasses any active "Pending User" blocks to execute its scheduled installations immediately. - **Consolidated Remediation & Restart:** A system restart will only occur if Automatic Restart is enabled and an installed package (from either the current silent policy or the pending policy) requires a restart. If a restart is required, the sequence will simultaneously process and finalize all pending installations and restart requirements from the deferred interactive policy. This effectively clears the device's backlog and brings the endpoint into full compliance in a single, consolidated cycle. #### Install Notification Settings Go to **End User Notifications → Install Notification Settings**. ![](../../Resources/Images/user-notif-install.png) - Turn **on** notifications if you want users to receive a message when an update is available. - This is useful for updates that do not require a restart but still need user action. - The tray will show a deadline to install the update. - Turn **off** notifications if you do not require users to take action on available updates. #### Restart Notification Settings Use this setting to control whether users are notified when a restart is required after updates. ![](../../Resources/Images/restart-notification-toggle.png) - Turn **on** Restart Notification Settings: End users receive a tray notification when a restart is required. A specific deadline is shown, and reminders appear leading up to the deadline. - Turn **off** Restart Notification Settings: No restart notifications or reminders are shown in the tray. - **Note**: Automatic Restart must be enabled to use this setting. Users can restart their device either by selecting the **Restart Now** button in the Automox tray **or** by using the operating system's standard restart options (such as the Start menu in Windows or the Apple menu in macOS). **Both methods are supported and will satisfy the policy requirement**. If you want users to be notified about both installations and restarts, both settings must be turned on. ### Do Not Disturb (DND) You can configure how notifications are handled when a device has Do Not Disturb (DND) enabled. On macOS this setting is called Do Not Disturb, and on Windows it is known as Focus mode. In the Automox console, the **Do Not Disturb (DND)** setting applies to both. ![](../../Resources/Images/do-not-disturb-bypass.png) - **Bypass DND** (default): Notifications are always displayed on the device, even if the user has Do Not Disturb enabled. This ensures that users receive update and restart reminders according to the policy schedule, regardless of any local preference to suppress notifications. - **Honor DND**: Notifications are suppressed when Do Not Disturb is enabled on the device. This allows users to avoid interruptions while Do Not Disturb is active. However, the policy is still enforced at the deadline, and users will still be notified five minutes and one minute prior to enforcement. **Note**: - When you select **Honor DND**, users do not receive regular reminders while Do Not Disturb is active. They only see the final notifications at five minutes and one minute before the deadline. Consider whether suppressing reminders could reduce user readiness for updates or restarts. - Do Not Disturb (DND) functionality requires Automox agent 2.4+. - This feature is currently **not supported** on macOS Tahoe or Windows Servers. See also [Automox Tray and End-User Notifications FAQ](Automox Tray FAQ.htm) for details about platform-specific behavior when Do Not Disturb is enabled or disabled on a device. ### Save and Apply the Policy After configuring the notification settings, click Create Policy or save your edits. Devices assigned to the policy will begin receiving deadline-based notifications in the Automox tray. ## Part 2: What Users See in the Automox Tray This section explains how notifications configured in a policy appear to end users through the Automox tray. Understanding this behavior will help you support users and ensure policy settings produce the intended experience. ![](../../Resources/Images/up-to-date.png) ### Automox Tray Overview - The Automox tray is always visible in the system tray on Windows and macOS. - It shows users the current update or restart status. - If notifications are enabled in a policy, users see messages prompting them to install updates or restart their devices by a specific deadline. - Users are reminded as the deadline approaches (reminders apply to both install updates and restarts). Reminder cadence: - Daily - 24 hours before deadline - 3 hours before - 1 hour before - 5 minutes before - 1 minute before ### When an Update is Available If **Install Notification Settings** are enabled: - The tray notifies the user that an update is available. - A deadline appears, indicating when the user must take action. - Users are reminded as the deadline approaches. - If the update does not require a restart, the user can install and continue working. ### When a Restart is Required If **Restart Notification Settings** are enabled: - A **dot** indicator on the tray icon means a restart is pending. - The tray shows a clear restart deadline. - Users are reminded as the deadline approaches. These reminders appear even during Do Not Disturb mode. You cannot control the reminder cadence. ### Restarting the Device When a restart is required, the tray displays a clear deadline and shows reminders as the deadline approaches. Users can restart their device at any time before the deadline. Restarting from either the Automox tray or the operating system (such as the Start menu in Windows or the Apple menu in macOS) will fulfill the policy requirement. The tray clears the restart message once the restart is complete. If the user does not restart before the deadline: - The system restarts automatically after the final reminder. - If the device is offline, the restart triggers as soon as it reconnects. ### User Workflow Summary **Note**: Example images show notifications for macOS. Windows messaging is identical; however the reminders do not appear with a dark background. | Scenario | Result | | --- | --- | | Updates Ready to Install: When an update is available, the user is notified that the install is ready to take place. | Tray shows update available; user sees install deadline | | Install Initiated: After the user initiates the install, the tray displays a notification indicating that the installation is in progress. | Tray shows installation in progress or completes silently. | | Restart Required: When the install is complete and a restart is required, the tray shows a specific restart deadline, indicating when the restart must occur. | The tray displays a specific deadline by which the restart must happen. | | Restart Initiated: After the restart has been initiated, the tray displays a notification indicating that the restart process has begun. It may take a few minutes for your computer to restart. | Restart is registered; tray clears the requirement | | When the user restarts using OS menu | Restart is registered; tray clears the requirement. | | Restart deadline passes | System restarts automatically | | Device is offline at deadline | Restart occurs on next re-connection | ## Customizing Notification Messages You can configure how a user receives notice of an update that is scheduled to be installed or for updates requiring a restart. ### Custom Install Notifications To configure install notification messages, turn on **Install Notifications Settings**. ![](../../Resources/Images/user-notif-install-settings.png) If you do not want to use the default message, you can create your own. - For updates that do not require a restart, configure the **Install Message (No Restart Required)**. Fill in the text box with the **messaging of your choice**. The message can be up to 125 characters for Windows or 70 characters in length for macOS. - For updates that **require a restart**, configure the **Install Message (Restart Required)**. Fill in the text box with the **messaging of your choice**. The message can be up to 125 characters for Windows or 70 characters in length for macOS. ### Custom Restart Notifications To configure restart notification messages, turn on **Restart Notification Settings**. - Under Automatic Restart, select **Enable automatic restart after updates are installed**. - Turn on Restart Notification Settings. ![](../../Resources/Images/user-notif-restart-settings.png) Configure the Restart Notification Message for end users: - You can do nothing and use the default message. - You can set a **custom notification message** for restart. Fill in the text box with the **messaging of your choice**. The message can be up to 125 characters for Windows or 70 characters in length for macOS. - This message remains in the Automox tray until the update is complete. #### What an administrator can expect The administrator must decide on the required deadline. - Take into consideration the requirements of the end user to best set the deadline. - Consider adjusting the notification message to ensure your end users understand how to proceed. Your custom messaging will replace the default message in the Automox tray. #### What a user can expect **Install does not require a restart** The user can start the install at any time before the deadline. However, no action is required. The software installs automatically in the background when the deadline is reached. Install requires a restart The user sees a notification in the Automox tray and must restart before the deadline. **Users can now restart manually outside of the tray or use the Restart Now button in the tray**. When the deadline is reached, the install begins automatically. ## Related Topics - [Automox Tray and End-User Notifications FAQ](Automox Tray FAQ.htm) - [Tray Customization Worklets](Tray Customization Worklets.htm) - [Allowing Automox Notifications on macOS When Screen Sharing](Allowing_Automox_Notifications_on_macOS_When_Screen_Sharing.htm) - [Automox Agent Installation Overview](../Agents/Agent Installation/Automox_Agent_Installation_Overview.htm) - [Agent 2.2.24 Release Notes](../Release Notes/Agent Release Notes/Agent 2.2.x Release Notes.htm) - [Agent 2.3.34 Release Notes](../Release Notes/Agent Release Notes/Agent 2.3.x Release Notes.htm) --- # Managing End-User Notifications _Section: Product Documentation › Notifications & Restarts • Source: https://docs.automox.com/product/Content/Product%20Documentation/Notifications%20%26%20Restarts/Managing_End_User_Notifications.htm_ User notification messages allow you to give end users notice of important updates or restarts on Windows and macOS devices. It is also possible to configure deferral options that allow users to control when an update or restart happens. --- # Tray Customization Worklets _Section: Product Documentation › Notifications & Restarts • Source: https://docs.automox.com/product/Content/Product%20Documentation/Notifications%20%26%20Restarts/Tray%20Customization%20Worklets.htm_ This document provides guidance for using **Automox Worklets™** to customize aspects of the Automox Tray experience on user devices. These worklets allow administrators to configure functionality beyond what is available in policy settings, such as defining a persistent message or enabling or disabling the tray interface. Automox will introduce additional customization worklets in future agent releases. [View Tray Management Worklets in the Worklet Catalog](https://console.automox.com/manage/worklet-catalog?categories=tray_management&limit=25&q=Tray) **Prerequisites**: - Your Automox plan must include worklets to access the worklet catalog. - If your plan does not include access to the worklet catalog, you can manually create a worklet using the corresponding script provided for each item in this document. - You must have the required permissions to create or manage worklets in your organization. ## Customize Trusted Message This section describes two worklets that allow you to customize the message displayed at the bottom of the Automox Tray notification window. This static message helps users recognize that the notification is provided by an authorized IT administrator or service provider and is safe to act on. These worklets are available for both **Windows** and **macOS**. The message supports up to two lines of text (approximately 75 characters total). Text beyond this limit is cut off. This configuration is not controlled through policy settings and must be applied using a worklet. **View in Worklet Catalog:** - [Windows - Tray Notification - Customize Trusted Message](https://console.automox.com/manage/worklet-catalog/5ed179b0-ade8-4566-afcd-2fcbff78c4f1) - [macOS - Tray Notification - Customize Trusted Message](https://console.automox.com/manage/worklet-catalog/62b51e25-672a-4a73-90e0-df8f7f8bb621) ## Remove Custom Trusted Message To remove an applied custom message, update the text in the worklet or apply a new worklet with empty text to reset to the default messaging. ## Enable or Disable the Automox Tray This section includes two worklets that let administrators enable or disable the Automox tray on supported **Windows** devices. Disabling the tray prevents it from displaying to users, while enabling it restores its visibility. These settings are applied locally through the presence or absence of a control file and are not managed through policy. **View in Worklet Catalog:** - [Windows - Enable Automox Tray](https://console.automox.com/manage/worklet-catalog/9b4c5d6e-7f8a-9b0c-1d2e-3f4a5b6c7d8e) - [Windows - Disable Automox Tray](https://console.automox.com/manage/worklet-catalog/9b4c5d6e-7f8a-9b0c-1d2e-3f4a5b6c7d8e) ## Customize Tray Branding Icon This section describes a new worklet that allows you to customize the system icon displayed on an endpoint. This icon, shown in the Menu Bar on macOS and in Window’s System Tray allows users to launch the Agent Tray. This customization helps deliver a more intuitive, professional, and tailored experience to end users. **Icon Requirements** - Device must be running **Agent v2.5.x** or higher - **File Types Supported:** Only .png is currently supported - **File Size (Pixels) Supported:** Files must be 256 x 256 pixels - Both a Light Mode and Dark Mode file are required, with the following naming conventions; `lightModeIcon.png`, `darkModeIcon.png` respectively. - **Note:** On macOS, the tray icon updates automatically with OS theme changes. On Windows, the icon updates after an Agent restart or with certain Agent activity. **View in Worklet Catalog:** - [Windows - Tray Notification - Customize Branding Icon](https://console.automox.com/manage/worklet-catalog/fba84c65-a343-4f11-88c5-e05a52660bd3) - [Windows - Tray Notification - Reset Branding Icon](https://console.automox.com/manage/worklet-catalog/965ec103-d589-4591-a27e-496772d770ef) - [macOS - Tray Notification - Customize Branding Icon](https://console.automox.com/manage/worklet-catalog/7c08c4eb-b1e6-42a4-a5ce-056ecd330924) - [macOS - Tray Notification - Reset Branding Icon](https://console.automox.com/manage/worklet-catalog/b7910fd0-e55a-4cb1-b2a7-2a702055bebc) ## Customize Icon Tooltip (Windows Only) This section describes a new worklet that allows you to customize the tooltip string that is displayed when hovering over the Agent icon in the Windows system tray. This enhancement is supported on Windows only at this time. **Tooltip Requirements** - Endpoint must be running Agent v2.5.x or higher - Custom tooltip text must be 75 characters or less - Field supports UTF-8 character encoding **View in Worklet Catalog:** - [Windows - Tray Notification - Set Tooltip Text](https://console.automox.com/manage/worklet-catalog/a1b2c3d4-e5f6-7890-abcd-ef1234567890) - [Windows - Tray Notification - Reset Tooltip Text](https://console.automox.com/manage/worklet-catalog/b2c3d4e5-f6a7-8901-bcde-f12345678901) ## Customize Tray Title (Windows Only) This section describes a new worklet that allows you to customize the title string in the Tray. This enhancement is supported on Windows only at this time. **Title Requirements** - Device must be running Agent v2.5.x or higher - Custom title text must be 20 characters or less - Field supports UTF-8 character encoding View in Worklet Catalog: - [Windows - Tray Notifications - Set Titlebar Title](https://console.automox.com/manage/worklet-catalog/c3d4e5f6-a7b8-9012-cdef-123456789012) - [Windows - Tray Notification - Reset Titlebar Title](https://console.automox.com/manage/worklet-catalog/d4e5f6a7-b8c9-0123-defa-234567890123) ## Related Topics - [End-User Notifications](End_User_Notifications.htm) - [Automox Tray and End-User Notifications FAQ](Automox Tray FAQ.htm) - [Creating a Worklet](../Policies/Creating_a_Worklet.htm) --- # Understanding Restart Error Notifications _Section: Product Documentation › Notifications & Restarts • Source: https://docs.automox.com/product/Content/Product%20Documentation/Notifications%20%26%20Restarts/Understanding_Restart_Error_Notifications.htm_ This article explains restart error notifications and provides examples that help you understand how to interact with them. --- # Using Restart Notifications _Section: Product Documentation › Notifications & Restarts • Source: https://docs.automox.com/product/Content/Product%20Documentation/Notifications%20%26%20Restarts/Using_Restart_Notifications.htm_ For Windows and macOS devices, a restart notification warns end users when their computer needs to restart. --- # macOS Privacy Preferences - amagent wants access to control Microsoft AutoUpdate _Section: Product Documentation › Notifications & Restarts • Source: https://docs.automox.com/product/Content/Product%20Documentation/Notifications%20%26%20Restarts/macOS_Privacy_Preferences___amagent_wants_access_to_control_Microsoft_AutoUpdate.htm_ This describes how to automatically allow Automox to patch macOS without a pop-up. ![](../../Resources/Images/autoupdate-prompt.png) New privacy controls implemented in macOS 10.14 (Mojave) require this prompt which can cause confusion for your end users or worse, prevent them from patching Microsoft Office applications. If you use a Mobile Device Manager (MDM) with your macOS devices, you can hide this prompt and force allow this patching behavior with a Privacy Preferences Policy Control profile and Automox Agent 28 or newer. This profile payload can apply to devices that have a User Approved MDM Profile or devices deployed with Apple Business Manager (previously named Apple Device Enrollment Program). Depending on your MDM, this payload might be named Privacy Preference or Privacy Preferences Policy Control. The following information is needed to populate this profile: Identifier: /usr/local/bin/amagent Identifier Type: Path Code Requirement: identifier "com.automox.agent" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = DAEQ58A4ES Validate the Static Code Requirement: Off App or Service: AppleEvents Access: Allow Receiver Identifier: com.microsoft.autoupdate2 BundleID: identifier "com.microsoft.autoupdate2" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = UBF8T346G9 ## Jamf Pro ![](../../Resources/Images/privacy-pref-policy-control.png) ## SimpleMDM ![](../../Resources/Images/simplemdm.png) --- # macOS Requires Security Approval for Microsoft Office Patches _Section: Product Documentation › Notifications & Restarts • Source: https://docs.automox.com/product/Content/Product%20Documentation/Notifications%20%26%20Restarts/macOS_Requires_Security_Approval_for_Microsoft_Office_Patches.htm_ Apple has introduced a security measure in macOS Mojave (10.14) and newer that is required for some third-party updates. macOS uses the Microsoft AutoUpdate for patching Microsoft Office applications which is the Microsoft supported mechanism for this OS. The Automox - When macOS prompts you for the security approval for the Automox --- # About Ask Otto _Section: Product Documentation › Otto AI • Source: https://docs.automox.com/product/Content/Product%20Documentation/Otto%20AI/About_Ask_Otto.htm_ Ask Otto, powered by Automox Otto AI™, is your generative AI script assistant that writes PowerShell and Bash scripts to help automate configuration and remediation across your environment with Worklets. ## Ask Otto uses generative AI technologies to write scripts While Otto AI provides the valuable script assistant experience called Ask Otto, you must approach script generation with caution. Generative AI technologies have inherent limitations and should be seen as tools to assist developers rather than complete replacements. The script generated by Ask Otto is based on patterns and examples from training data and might not always adhere to specific scripting standards or best practices. Automox strongly urges you to "trust but validate" the script generated by Ask Otto by carefully reviewing and testing it before implementation. **Important**: You carry the responsibility for script quality and security for your organization. Contact your representative for more information about this feature. ## Related Topics - [Enabling and Using Ask Otto by Automox](Enabling_and_Using_Ask_Otto_by_Automox.htm) - [Otto AI FAQs](Otto_AI_FAQs.htm) - [Short Guide to Ask Otto Prompts](Short_Guide_to_Ask_Otto_Prompts.htm) - [Ask Otto Gen AI Scripting Demo](https://discover.automox.com/menu/demo/ask-otto-ai-73PU-263Y4.html) --- # Enabling and Using Ask Otto by Automox _Section: Product Documentation › Otto AI • Source: https://docs.automox.com/product/Content/Product%20Documentation/Otto%20AI/Enabling_and_Using_Ask_Otto_by_Automox.htm_ You can use Ask Otto, powered by Automox Otto AI, to write PowerShell and Bash scripts to test and plug into Worklets. Contact your representative for more information about this feature. - Only available to customers who have Premium Support or Premium Support Plus services. For an overview of Automox support services, see [https://www.automox.com/pricing](https://www.automox.com/pricing). - You must have the required permissions to enable and use Ask Otto for an organization. See [Roles and Permissions](../Global Access Management/Roles_and_Permissions.htm). - You should have experience with the scripting language you use. ![](../../Resources/Images/worklet-step1.png) ## Enabling Ask Otto Follow these steps to enable Ask Otto for an organization. --- # Otto AI FAQs _Section: Product Documentation › Otto AI • Source: https://docs.automox.com/product/Content/Product%20Documentation/Otto%20AI/Otto_AI_FAQs.htm_ The following are common questions and answers about Ask Otto, the generative AI script assistant powered by Automox Otto AI™. ## General | Question | Answer | | --- | --- | | Who has access to Ask Otto? | The Ask Otto module is included with the purchase of Premium Support or Premium Support Plus services. See Automox Pricing. You must have full administrator or Manage: Organization permissions to enable Ask Otto for an organization. Any full administrator, organization operator, or custom role with Worklets: Create, Execute permissions can use Ask Otto. | | Can I disable Ask Otto after it is enabled? | To disable Ask Otto after it is enabled, contact Automox Support. | | Is Otto AI expected to be able to evaluate the code in an existing worklet without having to put the actual code into the prompt? | No, for security reasons Automox does not automatically send worklet contents through Otto AI. | | Is Otto AI using data from Automox to help formulate its response? | No. Otto AI uses Anthropic's Claude Haiku 4.5 model via AWS Bedrock. Claude's responses come from Anthropic's training data — not from Automox customer data. Per AWS's commercial data privacy commitment, Bedrock does not store your prompts or completions, and Anthropic does not use them to train future models. | ## Security | Question | Answer | | --- | --- | | What is the architecture for Otto AI? | The Otto AI backend is a serverless service running entirely inside Automox’s AWS account (us-west-2). Chat requests flow: User → Automox Console (HTTPS) → AWS API Gateway (authenticated) → Lambda → AWS Bedrock → Anthropic Claude (Haiku 4.5).User input never traverses the public internet to a third-party AI provider. The Bedrock API call is internal to AWS.Cross-region inference (AWS-managed) may route the model invocation to us-east-1, us-east-2, or us-west-2; all are within AWS. | | What happens to data entered into Otto AI? Is there anything else or anywhere else data sharing is happening? | Your prompts and Otto AI's responses are processed by AWS Bedrock (Anthropic Claude Haiku 4.5). They are: NOT sent to OpenAI, ChatGPT, or any public AI service.NOT stored by AWS Bedrock beyond the request lifecycle.NOT used by Anthropic to train future models (per AWS commercial terms).Stored briefly in an Automox-owned DynamoDB table to maintain chat session history. Sessions are automatically deleted 30 days after their last activity.Aggregated, anonymized usage metrics (tokens consumed, request counts) are kept for billing and capacity planning. | | How do I know that the code generated by Otto AI is good and not malicious? | Otto AI applies multiple safety layers before returning a response: AWS Bedrock Guardrails filter inputs and outputs for hate, insults, sexual content, misconduct, and high-risk content categories. Prompt injection / prompt attack detection is active on user input.PII filtering automatically anonymizes email addresses, IP addresses, and phone numbers; secrets (credentials, tokens) are blocked outright.Topic restriction (in the system prompt) keeps Otto AI focused on endpoint-management worklet scripting. Off-topic requests (creative writing, news, personal advice, non-endpoint software development) are declined. Even with these layers, Otto AI is a code-generation assistant — always review generated scripts before running them on your fleet, and test in a non-production worklet first. This is true of any AI-generated code regardless of provider. | | What if our AI provider has a security incident? | Otto AI does not depend on OpenAI / ChatGPT. AWS Bedrock and Anthropic's commercial offering have stronger data-handling commitments than the OpenAI consumer ChatGPT product: AWS Bedrock does not persist prompts or completions.Anthropic does not train on customer-submitted data.Bedrock runs inside Automox's AWS account, behind AWS IAM authentication — there is no exposed public endpoint that an attacker could query with our credentials. A hypothetical AWS Bedrock service incident would be governed by AWS's standard SLA and our enterprise agreement. Automox would be notified through AWS's standard channels. | | What happens if an Otto AI generated script breaks something in my environment? | Validate output from Otto AI before running it on a device. Refer to the agreement that all Otto AI users must accept prior to usage: The Ask Otto interface allows your users to access AI-generated Worklet script suggestions through the Automox console. Use of Ask Otto will comply with the Anthropic Usage Policy . Input to Ask Otto is not confidential. Do not include any personal data or proprietary information. Output from Ask Otto is Third Party Content for purposes of your agreement with Automox, and it may be subject to third-party licenses, including open source licenses. The Output is available "AS IS" without warranty or support by Automox or its AI provider. If you do not want to enable Ask Otto for your organization, please select "Close." | | What AI model powers Otto AI? | Anthropic's Claude Haiku 4.5 (released October 2025), accessed via AWS Bedrock. Automox uses AWS's cross-region inference profile, which lets Bedrock route invocations to the nearest healthy AWS US region (us-east-1, us-east-2, or us-west-2) for the best latency and availability. | | Does Anthropic or AWS train on our data? | No. Per AWS's commercial data privacy commitment and Anthropic's published policy for Bedrock customers, your inputs and Otto AI's outputs are not used to train, retrain, or improve any AI model. | | What changed when Otto AI moved from ChatGPT to Claude | In 2026, Automox migrated Otto AI from OpenAI's ChatGPT to Anthropic's Claude on AWS Bedrock. The user experience is unchanged — same chat interface, same worklet script generation — but the underlying model, data-handling commitments, and infrastructure improved: Data no longer leaves the AWS ecosystem. Stronger commercial data privacy commitments (no training on customer data). Lower latency (responses are typically faster). | ## Related Topics - [About Ask Otto](About_Ask_Otto.htm) - [Enabling and Using Ask Otto by Automox](Enabling_and_Using_Ask_Otto_by_Automox.htm) - [Short Guide to Ask Otto Prompts](Short_Guide_to_Ask_Otto_Prompts.htm) - [Creating a Worklet](../Policies/Creating_a_Worklet.htm) - [How to Use Worklets](../Worklets & Required Software/How_to_Use_Worklets.htm) - [Learn more](https://www.automox.com/resources/ask-otto) --- # Short Guide to Ask Otto Prompts _Section: Product Documentation › Otto AI • Source: https://docs.automox.com/product/Content/Product%20Documentation/Otto%20AI/Short_Guide_to_Ask_Otto_Prompts.htm_ This guide helps you effectively use the Ask Otto script writing assistant to draft PowerShell and BASH-based Worklets. For requirements and details, refer to [Enabling and Using Ask Otto by Automox](Enabling_and_Using_Ask_Otto_by_Automox.htm). ## Things to note when using Ask Otto When you are creating a new worklet and request help from Ask Otto, you can start it in two ways. - If you are trying to create an evaluation script, make sure to use to the chatbot assistant within the Evaluation Code section. - Correspondingly, to create a remediation script, make sure to use the chatbot assistant within the Remediation Code section. ## Use cases and prompt examples The following use cases and examples help you test the functionality. ### Vulnerability Remediation This example script finds and then fixes the Oracle CredSSP remote code execution vulnerability. **Evaluation Prompt Entry:** Create a PowerShell Evaluation script that mitigates CVE-2018-0886. The script should check for a registry key named "AllowEncryptionOracle" under the "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters" hive. If the key does not exist or does not have a value of 1, Write-Output "The device is not compliant" and Exit 1. If the key exists and has a value of 1, Write-Output "The device is compliant." And Exit 0. **Remediation Prompt Entry:** Create a PowerShell Remediation script that sets the "AllowEncryptionOracle" registry under "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters" to a value of 1. If the key does not exist, create it. If it already exists, but is not a value of 1, set it to 1. Perform this in a Try/Catch block and return error logging. If the Try is successful, Write-Output "Remediation was successful." And Exit 0 If the Try fails, Write-Output "Remediation failed." Provide the error exception message, and Exit 1. ### Audit scripts to check and report on configurations, settings, and status **Remediation Code:** Write a worklet to validate that Intune auto-enrollment was successful in PowerShell. If the worklet was successful, write-output “Intune auto-enrollment successful.” If the auto-enrollment was unsuccessful, write-output “Intune auto-enrollment is unsuccessful” ### Fix a help desk issue Many examples of scripts can fix help desk-related issues such as rebuilding an Outlook profile, printer configurations, clearing a browser cache, etc. This example checks whether a specific network printer is installed on a device; if not, the script installs it. **Evaluation Code** Write a PowerShell worklet to check if a network printer is installed on a device. If the network printer is installed Exit 0, if it is not installed Exit 1 **Remediation Code** Write a PowerShell script to install a network printer on a Windows 10 device. If successfully installed, write-output "network printer installed". If the install is not successful, write-output "network printer install failed" ### Other use cases - Audit type worklets that report against a state configuration that's unique to their environment. - Specific software installs/uninstalls - homebrew apps or special non-general configurations - larger scale project type worklets such as domain migrations, email alerting, write-backs to other APIs, etc. ## Related Topics - [About Ask Otto](About_Ask_Otto.htm) - [Enabling and Using Ask Otto by Automox](Enabling_and_Using_Ask_Otto_by_Automox.htm) - [Otto AI FAQs](Otto_AI_FAQs.htm) - [Creating a Worklet](../Policies/Creating_a_Worklet.htm) - [How to Use Worklets](../Worklets & Required Software/How_to_Use_Worklets.htm) --- # How to Ensure You're Really Patching What You Think _Section: Product Documentation › Patching • Source: https://docs.automox.com/product/Content/Product%20Documentation/Patching/How_to_Ensure_You_re_Really_Patching_What_You_Think.htm_ Review severity settings of policies to make sure you are patching at the scope you want. The severity level **High** was added to the Automox console with CSVSSv3, which means you should check if your policies still include the level of patching you are expecting. The scope of **Critical** has a different range (9.0–10.0). If you require the full span of 7.0–10.0, you must select **High** in your policy. --- # On-Premise Bandwidth Optimization Options _Section: Product Documentation › Patching • Source: https://docs.automox.com/product/Content/Product%20Documentation/Patching/On_Premise_Bandwidth_Optimization_Options.htm_ ## Summary Automox is the easiest-to-use, most-recommended, most efficient cloud-native solution for endpoint hardening--anywhere, in an instant. Being a cloud-native platform, Automox makes it possible to manage Windows, macOS, and Linux devices with one solution without purchasing physical hardware or installing a management application. As companies move to internet-based modern solutions, some of the challenges of legacy solutions are immediately solved, while others remain. The purpose of this document is to present the most common challenges, and provide guidance on how to utilize native technologies while working to preserve the intent of a cloud first, infrastructure-less solution. ## Solutions ### Quality of Service (QoS) Palo Alto Networks explains Quality of Service (QoS) as the following: “Quality of Service (QoS) is a set of technologies that work on a network to guarantee its ability to dependably run high-priority applications and traffic under limited network capacity. QoS technologies accomplish this by providing differentiated handling and capacity allocation to specific flows in network traffic. This enables the network administrator to assign the order in which packets are handled, and the amount of bandwidth afforded to that application or traffic flow…” “The QoS mechanisms for ordering packets and allotting bandwidth are queuing and bandwidth management respectively. Before they can be implemented however, traffic must be differentiated using classification tools. The classification of traffic according to policy allows organizations to ensure the consistency and adequate availability of resources for their most important applications. Traffic can be classified crudely by port or IP, or using a more sophisticated approach such as by application or user. The latter parameters allow for more meaningful identification, and consequently, classification of the data. Next, queuing and bandwidth management tools are assigned rules to handle traffic flows specific to the classification they received upon entering the network. The queuing mechanism allows for packets within traffic flows to be stored until the network is ready to process it. Priority Queuing (PQ) is developed to ensure the necessary availability and minimal latency of network performance for the most important batches of applications and traffic by providing an assigned priority and specific bandwidth to them based on their classification. This ensures the most important activities on a network are not starved of bandwidth by activities of lower priority. Applications, users, and traffic can be batched in up to 8 differentiated queues. Bandwidth management mechanisms measure and control traffic flows on the network to avoid exceeding its capacity and the resulting network congestion that occurs. Mechanisms for bandwidth management include traffic shaping, a rate limiting technique used to optimize or guarantee performance and increase usable bandwidth where necessary, and scheduling algorithms, which offer varied methods for providing bandwidth to specific traffic flows.” (See [References](#Referenc).) ### Windows Delivery Optimization (DO) Microsoft explains Delivery Optimization (DO) as the following: “[Delivery Optimization](https://docs.microsoft.com/en-us/windows/deployment/update/waas-delivery-optimization) is a new peer-to-peer distribution method in Windows 10. Windows 10 clients can source content from other devices on their local network that have already downloaded the updates or from peers over the internet. Using the settings available for Delivery Optimization, clients can be configured into groups, allowing organizations to identify devices that are possibly the best candidates to fulfill peer-to-peer requests. “Windows updates, upgrades, and applications can contain packages with very large files. Downloading and distributing updates can consume quite a bit of network resources on the devices receiving them. You can use Delivery Optimization to reduce bandwidth consumption by sharing the work of downloading these packages among multiple devices in your deployment. Delivery Optimization can accomplish this because it is a self-organizing distributed cache that allows clients to download those packages from alternate sources (such as other peers on the network) in addition to the traditional Internet-based servers. Delivery Optimization is a cloud-managed solution. Access to the Delivery Optimization cloud services is a requirement. This means that in order to use the peer-to-peer functionality of Delivery Optimization, devices must have access to the internet.” (See [References](#Referenc).) #### DO Requirements and Supported Download Package Types ##### Requirements The following table lists the minimum Windows 10 version that supports Delivery Optimization (See [References](#Referenc).): | Device type | Minimum Windows version | | --- | --- | | Computers running Windows 10 | 1511 | | Computers running server core installations of Windows Server | 1709 | | IoT devices | 1803 | ##### Types of download packages supported by delivery optimization | Download package | Minimum Windows version | | --- | --- | | Windows 10 updates (feature updates and quality updates) | 1511 | | Windows 10 drivers | 1511 | | Windows Store files | 1511 | | Windows Store for Business files | 1511 | | Windows Defender definition updates | 1511 | | Microsoft 365 Apps and updates | 1709 (for more information, see Delivery Optimization and Microsoft 365 Apps) | | Win32 apps for Intune | 1709 | | XBox Game Pass games | 2004 | | MSIX apps (HTTP downloads only) | 2004 | | Configuration Manager Express updates | 1709 + Configuration Manager version 1711 | | Edge browser installs and updates | 1809 | | Dynamic updates | 1903 | ##### How Microsoft uses Delivery Optimization “At Microsoft, to help ensure that ongoing deployments weren't affecting our network and taking away bandwidth for other services, Microsoft IT used a couple of different bandwidth management strategies. Delivery Optimization, peer-to-peer caching enabled through Group Policy, was piloted and then deployed to all managed devices using Group Policy. Based on recommendations from the Delivery Optimization team, we used the "group" configuration to limit sharing of content to only the devices that are members of the same Active Directory domain… More than 76 percent of content came from peer devices versus the Internet.” (See [References](#Referenc).) #### DO: Frequently Asked Questions ##### Does Delivery Optimization work with WSUS? Yes. Devices obtain the update payloads from the WSUS server, but must also have an internet connection as they communicate with the Delivery Optimization cloud service for coordination. ##### Which ports does Delivery Optimization use? Delivery Optimization listens on port 7680 for requests from other peers by using TCP/IP. The service registers and opens this port on the device, but you might need to set this port to accept inbound traffic through your firewall yourself. If you don't allow inbound traffic over port 7680, you can't use the peer-to-peer functionality of Delivery Optimization. However, devices can still successfully download by using HTTP or HTTPS traffic over port 80 (such as for default Windows Update data). If you set up Delivery Optimization to create peer groups that include devices across NATs (or any form of internal subnet that uses gateways or firewalls between subnets), it will use Teredo. For this to work, you must allow inbound TCP/IP traffic over port 3544. Look for a "NAT traversal" setting in your firewall to set this up. Delivery Optimization also communicates with its cloud service by using HTTP/HTTPS over port 80. ##### What are the requirements if I use a proxy? For Delivery Optimization to successfully use the proxy, you should set up the proxy by using Windows proxy settings or Internet Explorer proxy settings. For details see [Using a proxy with Delivery Optimization](https://docs.microsoft.com/en-us/windows/deployment/update/delivery-optimization-proxy). Most content downloaded with Delivery Optimization uses byte range requests. Make sure your proxy allows byte range requests. For more information, see [Proxy requirements for Windows Update](https://support.microsoft.com/help/3175743/proxy-requirements-for-windows-update). ##### What hostnames should I allow through my firewall to support Delivery Optimization? For communication between clients and the Delivery Optimization cloud service: *.do.dsp.mp.microsoft.com. For Delivery Optimization metadata: - *.dl.delivery.mp.microsoft.com - *.emdl.ws.microsoft.com For the payloads (optional): - *.download.windowsupdate.com - *.windowsupdate.com ##### Does Delivery Optimization use multicast? No. It relies on the cloud service for peer discovery, resulting in a list of peers and their IP addresses. Client devices then connect to their peers to obtain download files over TCP/IP. ##### How does Delivery Optimization deal with congestion on the router from peer-to-peer activity on the LAN? Starting in Windows 10, version 1903, Delivery Optimization uses LEDBAT to relieve such congestion. For more details see this post on the [Networking Blog](https://techcommunity.microsoft.com/t5/Networking-Blog/Windows-Transport-converges-on-two-Congestion-Providers-Cubic/ba-p/339819). ##### How does Delivery Optimization handle VPNs? Delivery Optimization attempts to identify VPNs by checking the network adapter type and details and treats the connection as a VPN if the adapter description contains certain keywords, such as "VPN" or "secure." If the connection is identified as a VPN, Delivery Optimization suspends uploads to other peers. However, you can allow uploads over a VPN by using the [Enable Peer Caching while the device connects via VPN policy](https://docs.microsoft.com/en-us/windows/deployment/update/waas-delivery-optimization-reference#enable-peer-caching-while-the-device-connects-via-vpn). If you have defined a boundary group in Configuration Manager for VPN IP ranges, you can set the DownloadMode policy to 0 for that boundary group to ensure that there will be no peer-to-peer activity over the VPN. When the device is not connected via VPN, it can still leverage peer-to-peer with the default of LAN. With split tunneling, make sure to allow direct access to these endpoints: Delivery Optimization service endpoint: - https://*.prod.do.dsp.mp.microsoft.com Delivery Optimization metadata: - http://emdl.ws.microsoft.com - http://*.dl.delivery.mp.microsoft.com Windows Update and Microsoft Store backend services and Windows Update and Microsoft Store payloads - http://*.windowsupdate.com> - https://*.delivery.mp.microsoft.com - https://*.update.microsoft.com - https://tsfe.trafficshaping.dsp.mp.microsoft.com " [6] ### Troubleshooting You can find common problems and solutions here: [Troubleshooting](https://docs.microsoft.com/en-us/windows/deployment/update/waas-delivery-optimization#troubleshooting) ### Caching #### Content Caching (macOS) Content Caching allows a Mac administrator to set up a single or multiple macOS devices to download software updates to this device and then distribute them to all other macOS devices without downloading the software updates again for each device from the internet. Content caching will also give you the flexibility to choose what content gets cached as well. ##### How do I set up Content Caching? Setting up content caching on the host and peer devices is covered in the Apple [guide](https://support.apple.com/guide/mac-help/set-content-cache-clients-peers-parents-mac-mchl9b56e1cf/11.0/mac/11.0) on how to do this. ##### Why would I want to set up Content Caching? Content Caching can be helpful in environments where internet bandwidth is limited. Deploying a Patch Policy via Automox to all devices in a centralized location can cause saturation to your local network, and can slow it down for your end-users. ##### When do I want to set up Content Caching? Set up Content Caching if you have multiple macOS devices in a centralized location, in most cases a corporate office. Setting up one or more hosts will allow any macOS devices in the same subnet (or in some cases, the same Public IP address) to pull cached content from those host devices. You can also set up Content Caching for macOS devices that are on the go, that way if they can’t see the host device it will update the operating system from the internet instead. Content Caching does not need to be set up for organizations that have a fully remote staff. Content Caching is also not recommended to be used over a VPN. ##### Requirements to setup Content Caching: - A Mac device running macOS 10.13.5 or higher - Apple recommends any device running OS X 10.8.2; however, at the time this article is written, Automox only supports macOS 10.13+. - You can also set up multiple macOS host devices to distribute content to specific devices, if necessary. - The macOS device connected to the internet. - Hardwire a device with ethernet if possible. - It is also recommended to disable any other connections on the device. - A 1 GB ethernet connection or greater is recommended. - Line-of-sight to devices that download software updates from the host device. - This can also be accomplished with multiple subnets, as long as those devices have the same Public IP address. - Other Best Practices provided by Apple: - Allow all Apple push notifications. - Don’t use manual proxy settings. - Don’t proxy client requests to content caches. - Bypass proxy authentication for content caches. - Specify a TCP port for caching. (See Port key in [Configure advanced content caching settings on Mac](https://support.apple.com/guide/mac-help/configure-advanced-content-caching-settings-mchl91e7141a/11.0/mac/11.0).) - Manage inter-site caching traffic. - Block rogue cache registration. - Use a static public IP address for content caches ##### Bandwidth Limiting Ensure that your local network can handle passing data to multiple devices before setting up content caching. While your local network bandwidth may be high, it is good to remember that each macOS software update is usually around 3 GBs or more, and multiple devices receiving this update simultaneously will saturate your local network. It is also good to note that Content Caching is not useful if you are supporting a largely remote environment, as bandwidth may not be as much of a concern. If you want to deploy cached content to local machines, you may use [this guide](https://support.apple.com/guide/mac-help/configure-advanced-content-caching-settings-mchl91e7141a/11.0/mac/11.0) from Apple to modify the existing com.apple.AssetCache plist to help with limiting bandwidth on your local network. The defaults write command can accomplish this, or an MDM that can deploy configuration profiles. Add these plist strings to com.apple.AssetCache to help with bandwidth limiting: ![](../../Resources/Images/onprem-plist-strings.png) Plist strings to add to the "com.apple.AssetCache" plist ##### Considerations Cached content is stored in the boot drive of the host machine. If your boot drive free space gets too full, old cached content that is rarely used will be deleted in place of newer versions. The AllowCacheDelete plist string is enabled by default to clear old cached content. After you set up Content Caching, peer devices may take some time to discover the host device. While Apple does not publish how long this takes, restarting the peer machine may help discover the host device quicker. ##### Helpful Links - [What is content caching on Mac?](https://support.apple.com/guide/mac-help/what-is-content-caching-on-mac-mchl9388ba1b/mac) - [Set up content cache clients, peers, or parents on Mac](https://support.apple.com/guide/mac-help/set-content-cache-clients-peers-parents-mac-mchl9b56e1cf/11.0/mac/11.0) - [Use multiple content caches on Mac](https://support.apple.com/guide/mac-help/use-multiple-content-caches-on-mac-mchle150fb54/11.0/mac/11.0) - [Content types supported by content caching in macOS](https://support.apple.com/en-us/HT204675) - [Configure advanced content caching settings on Mac (Plist Modification)](https://support.apple.com/guide/mac-help/configure-advanced-content-caching-settings-mchl91e7141a/11.0/mac/11.0) ## Considerations [Set up Delivery Optimization for Windows 10 updates](https://docs.microsoft.com/en-us/windows/deployment/update/waas-delivery-optimization-setup) [Delivery Optimization reference](https://docs.microsoft.com/en-us/windows/deployment/update/waas-delivery-optimization-reference) [Blog - Michael Niehaus (details unreferenced elsewhere)](https://docs.microsoft.com/en-us/archive/blogs/mniehaus/windows-10-delivery-optimization-and-wsus-take-2) ## Best Practices ### Delivery Optimization Automox has a few examples of how to configure Delivery Optimization settings to increase peer sharing and throttle network bandwidth. These are provided as a fully functional example, but consider what settings are most appropriate for your environment. #### Suggested for 1803 and later - Download Mode: LAN (1) - Group ID : (GUID per location. Only needed with specific Download modes)*** - Select the source of Group IDs : (The options set in this policy only apply to Group (2) download mode. If Group (2) isn't set as Download mode, this policy will be ignored.)*** - Absolute Max Cache Size: 30 GB - Allow uploads while the device is on battery while under set Battery level: 40 - Delay background download from http (in secs): 600 (10 min)** - Delay Foreground download from http (in secs): 600 (10 min)** - Max Cache Age: 2592000 (30 days)Maximum Download Bandwidth (in KB/s): 500 (500 KB/s = 4 mbit)* - Minimum Peer Caching Content File Size (in MB): 1 - Minimum RAM (inclusive) allowed to use Peer Caching (in GB): 2 *The Maximum Download Bandwidth setting was removed in version 2004, and replaced with new settings for throttling traffic based on Foreground or Background channels. **NOTE: As of March 31 2021, Automox leverages the Foreground channel to download updates. Work is underway to change the channel used for downloading updates to the background channel. Suggestion is to delay the background channel traffic only and not delay the foreground channel once Automox switches its channel use. ***Specific to Download Mode and Group settings. Only needed in association with specific selections. #### **Suggested for 2004 and later** - Settings defined for 1803 and later - Maximum Foreground Download Bandwidth (in KB/s): 500* - Maximum Background Download Bandwidth (in KB/s): 500* *NOTE: As of March 31 2021, Automox leverages the Foreground channel to download updates. Work is underway to change the channel used for downloading updates to the background channel. Suggestion is to throttle the background channel traffic only and not throttle the foreground channel once Automox switches its channel use. [https://docs.microsoft.com/en-us/windows/deployment/update/waas-delivery-optimization-reference#maximum-foreground-download-bandwidth-in-kbps](https://learn.microsoft.com/en-us/windows/deployment/do/waas-delivery-optimization-reference#maximum-background-download-bandwidth-in-kbs) #### **Considerations per environment** - Download Mode - Several options are available for different environments. Common options are: - 1 for LAN. Optionally add the “Select a method to restrict peer selection = 1” settings to further restrict sharing to other devices on the same subnet mask. This can be useful in large WAN environments with a centralized internet egress point to ensure devices share within their subnets only. - 2 - Group. There are extensive options when utilizing Active Directory Sites, DHCP, DNS suffix, or Azure groups are utilized. You can also define a custom GUID to define your group. Please see the options available in the Microsoft documentation here: [https://docs.microsoft.com/en-us/windows/deployment/update/waas-delivery-optimization-reference#select-the-source-of-group-ids](https://docs.microsoft.com/en-us/windows/deployment/update/waas-delivery-optimization-reference#select-the-source-of-group-ids) - 3 - Internet. This is ideal for devices that are always remote. - GroupID - Only relevant with specific download modes - Select the source of Group IDs - The options set in this policy only apply to Group (2) download mode. If Group (2) isn't set as Download mode, this policy will be ignored. - Select a method to restrict Peer Selection - option to filter peer selection by subnet mask when selecting LAN or Group Download Mode - Delay background download from http (in secs) - discuss your installation expectations. The scenario above forces clients to leverage peer sharing by delaying fall back to downloading content directly from the internet for 10 minutes. - Maximum Foreground and Background Download Bandwidth - discuss with the networking team to optimize settings. This could be specific to a specific office as an example should there be a high client count and\or low available bandwidth. - Minimum Peer Caching Content File Size (in MB). Automox suggests lowering the minimum file size to share to encourage a higher peer-to-peer sharing percentage. - Minimum RAM (inclusive) allowed to use Peer Caching (in GB). Automox recommends setting the minimum RAM requirement from the default of 4GB in environments where virtual devices or automated RAM allotment solutions are in place. If a device has less than the defined minimum RAM amount, DO will not honor the assigned configurations. #### Automox and Delivery Optimization To propagate peer-to-peer content sharing, consider staging updates before scheduled production patch policy time. This would match up well with a pilot patch policy run a day or so before production patch policies are scheduled (or within an appropriate amount of time to ensure the patches distributed earlier would match those needed at the production policy run time). Peer-to-peer content sharing via DO becomes more effective when there are 10 or more peers within a group. DO content sharing breaks up content into small portions, allowing peer connections to 10s - 100s of other devices at a time. Updates are not shared as a full patch, rather as smaller bits of content. This concept is important when considering a staging strategy. #### **GPO and Registry Information** ##### Download Mode - DODownloadMode | Specifies the download method that Delivery Optimization can use in downloads of Windows Updates, Apps and App updates. Supported on: At least Windows 10 Server, Windows 10 or Windows 10 RT Registry Hive: HKEY_LOCAL_MACHINERegistry Path: SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimizationValue Name: DODownloadModeValue Type: REG_DWORDValue: The following list shows the supported values: 0 = HTTP only, no peering. 1 = HTTP blended with peering behind the same NAT. 2 = HTTP blended with peering across a private group. Peering occurs on devices in the same Active Directory Site (if exist) or the same domain by default. When this option is selected, peering will cross NATs. To create a custom group use Group ID in combination with Mode 2. 3 = HTTP blended with Internet Peering. 99 = Simple download mode with no peering. Delivery Optimization downloads using HTTP only and does not attempt to contact the Delivery Optimization cloud services. 100 = Bypass mode. Do not use Delivery Optimization and use BITS instead. | | --- | ##### Group ID - DOGroupId | Group ID must be set as a GUID. This policy specifies an arbitrary group ID that the device belongs to. Use this if you need to create a single group for Local Network Peering for branches that are on different domains or are not on the same LAN.Note: this is a best effort optimization and should not be relied on for an authentication of identity. Supported on: At least Windows 10 Server, Windows 10 or Windows 10 RT Registry Hive: HKEY_LOCAL_MACHINERegistry Path: SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimizationValue Name: DOGroupIdValue Type: REG_SZ Note: You can generate a GUID easily with PowerShell: [guid]::NewGuid() | | --- | ##### Select the source of Group IDs - DOGroupIdSource | Set this policy to restrict peer selection to a specific source.When set, the Group ID will be assigned automatically from the selected source. If you set this policy, the GroupID policy will be ignored. The options set in this policy only apply to Group (2) download mode. If Group (2) isn't set as Download mode, this policy will be ignored. For option 3 - DHCP Option ID, the client will query DHCP Option ID 234 and use the returned GUID value as the Group ID. Supported on: At least Windows 10 Server, Windows 10 or Windows 10 RT Registry Hive: HKEY_LOCAL_MACHINERegistry Path: SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimizationValue Name: DOGroupIdSourceValue Type: REG_DWORDValue: Options available are: 1 = AD Site. 2 = Authenticated domain SID. 3 = DHCP Option ID. 4 = DNS Suffix. 5 = AAD Tenant ID. | | --- | ##### Select a method to restrict Peer Selection - DORestrictPeerSelectionBy | Set this policy to restrict peer selection via selected option. Registry Hive: HKEY_LOCAL_MACHINERegistry Path: SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimizationValue Name: DORestrictPeerSelectionByValue Type: REG_DWORDValue: Options available are: 1 = Subnet mask (more options will be added in a future release). Option 1 (Subnet mask) applies to both Download Mode LAN (1) and Group (2). | | --- | ##### Absolute Max Cache Size (in GB) - DOAbsoluteMaxCacheSize | Specifies the maximum size in GB of Delivery Optimization cache.This policy overrides the DOMaxCacheSize policy. The value 0 (zero) means "unlimited" cache; Delivery Optimization will clear the cache when the device runs low on disk space. Supported on: At least Windows 10 Server, Windows 10 or Windows 10 RT Registry Hive: HKEY_LOCAL_MACHINE|Registry Path: SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimizationValue Name: DOAbsoluteMaxCacheSizeValue Type: REG_DWORDDefault Value: 10Min Value: 0Max Value: 4294967295The default value is 10 G | | --- | ##### Delay background download from http (in secs) - DODelayBackgroundDownloadFromHttp | This policy allows you to delay the use of an HTTP source in a background download that is allowed to use P2P. After the max delay has reached, the download will resume using HTTP, either downloading the entire payload or complementing the bytes that could not be downloaded from Peers. Note that a download that is waiting for peer sources, will appear to be stuck for the end user. Supported on: At least Windows 10 Server, Windows 10 or Windows 10 RT Registry Hive: HKEY_LOCAL_MACHINERegistry Path: SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimizationValue Name: DODelayBackgroundDownloadFromHttpValue Type: REG_DWORDDefault Value: 0Min Value: 0Max Value: 4294967295The default value is 0 (no delay) | | --- | ##### Delay Foreground download from http (in secs) - DODelayForegroundDownloadFromHttp | This policy allows you to delay the use of an HTTP source in a foreground (interactive) download that is allowed to use P2P. After the max delay has reached, the download will resume using HTTP, either downloading the entire payload or complementing the bytes that could not be downloaded from Peers. Note that a download that is waiting for peer sources, will appear to be stuck for the end user. Supported on: At least Windows 10 Server, Windows 10 or Windows 10 RT Registry Hive: HKEY_LOCAL_MACHINERegistry Path: SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimizationValue Name: DODelayForegroundDownloadFromHttpValue Type: REG_DWORDDefault Value: 0Min Value: 0Max Value: 4294967295The default value is 0 (no delay) | | --- | ##### Maximum Download Bandwidth (in KB/s) - DOMaxDownloadBandwidth | Specifies the maximum download bandwidth in KiloBytes/second that the device can use across all concurrent download activities using Delivery Optimization. The default value 0 (zero) means that Delivery Optimization dynamically adjusts to use the available bandwidth for downloads. Supported on: At least Windows 10 Server, Windows 10 or Windows 10 RT Registry Hive: HKEY_LOCAL_MACHINERegistry Path: SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimizationValue Name: DOMaxDownloadBandwidthValue Type: REG_DWORDDefault Value: 0Min Value: 0Max Value: 4294967295The default value is 0 (unlimited) | | --- | ##### Maximum Background Download Bandwidth (in KB/s) - DOMaxBackgroundDownloadBandwidth | Specifies the maximum background download bandwidth in KiloBytes/second that the device can use across all concurrent download activities using Delivery Optimization. The default value 0 (zero) means that Delivery Optimization dynamically adjusts to use the available bandwidth for downloads. Supported on: At least Windows 10 Server, Windows 10 or Windows 10 RT Registry Hive: HKEY_LOCAL_MACHINERegistry Path: SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimizationValue Name: DOMaxBackgroundDownloadBandwidthValue Type: REG_DWORDDefault Value: 0Min Value: 0Max Value: 4294967295The default value is 0 (unlimited) | | --- | ##### Maximum Foreground Download Bandwidth (in KB/s) - DOMaxForegroundDownloadBandwidth | Specifies the maximum foreground download bandwidth in KiloBytes/second that the device can use across all concurrent download activities using Delivery Optimization. The default value 0 (zero) means that Delivery Optimization dynamically adjusts to use the available bandwidth for downloads. Supported on: At least Windows 10 Server, Windows 10 or Windows 10 RT Registry Hive: HKEY_LOCAL_MACHINERegistry Path: SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimizationValue Name: DOMaxForegroundDownloadBandwidthValue Type: REG_DWORDDefault Value: 0Min Value: 0Max Value: 4294967295The default value is 0 (unlimited) | | --- | ##### Max Cache Age (in seconds) - DOMaxCacheAge | Specifies the maximum time in seconds that each file is held in the Delivery Optimization cache after downloading successfully. The value 0 (zero) means "unlimited"; Delivery Optimization will hold the files in the cache longer and make the files available for uploads to other devices, as long as the cache size has not exceeded. Supported on: At least Windows 10 Server, Windows 10 or Windows 10 RT Registry Hive: HKEY_LOCAL_MACHINERegistry Path: SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimizationValue Name:DOMaxCacheAgeValue Type: REG_DWORDDefault Value: 259200Min Value: 0Max Value: 4294967295The default value is 3 days | | --- | ##### Allow uploads while the device is on battery while under set Battery level (percentage) - DOMinBatteryPercentageAllowedToUpload | Specify any value between 1 and 100 (in percentage) to allow the device to upload data to LAN and Group peers while on DC power (Battery). The recommended value to set if you allow uploads on battery is 40 (for 40%). The device can download from peers while on battery regardless of this policy. The value 0 means "not-limited"; The cloud service set default value will be used. Supported on: At least Windows 10 Server, Windows 10 or Windows 10 RT Registry Hive: HKEY_LOCAL_MACHINERegistry Path: SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimizationValue Name: DOMinBatteryPercentageAllowedToUploadValue Type: REG_DWORDDefault Value: 0Min Value: 0Max Value: 100The default value is 0 (unlimited) | | --- | ##### Minimum RAM capacity (inclusive) required to enable use of Peer Caching (in GB) - DOMinRAMAllowedToPeer | Specifies the minimum RAM size in GB required to use Peer Caching. For example if the minimum set is 1 GB, then devices with 1 GB or higher available RAM will be allowed to use Peer caching. Recommended values: 1 GB to 4 GB. Supported on: At least Windows 10 Server, Windows 10 or Windows 10 RT Registry Hive: HKEY_LOCAL_MACHINERegistry Path: SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimizationValue Name: DOMinRAMAllowedToPeerValue Type: REG_DWORDDefault Value: 4Min Value: 1Max Value: 100000The default value is 4GB | | --- | ## Index ### Sources 1. [Delivery Optimization for Windows 10 updates - Windows Deployment](https://docs.microsoft.com/en-us/windows/deployment/update/waas-delivery-optimization) 2. [Optimize update delivery for Windows 10 updates (Windows 10) - Windows Deployment](https://docs.microsoft.com/en-us/windows/deployment/do/waas-optimize-windows-10-updates) 3. [Set up Delivery Optimization - Windows Deployment](https://docs.microsoft.com/en-us/windows/deployment/update/waas-delivery-optimization-setup) 4. [Delivery Optimization reference - Windows Deployment](https://docs.microsoft.com/en-us/windows/deployment/update/waas-delivery-optimization-reference) 5. [What is Quality of Service?](https://www.paloaltonetworks.com/cyberpedia/what-is-quality-of-service-qos) 6. [Quality of Service (QoS) Policy](https://docs.microsoft.com/en-us/windows-server/networking/technologies/qos/qos-policy-top) 7. [What is content caching on Mac?](https://support.apple.com/guide/mac-help/what-is-content-caching-on-mac-mchl9388ba1b/mac) 8. [How to create a local mirror of the latest update for Red Hat Enterprise Linux 5, 6, 7, 8 without using Satellite server?](https://access.redhat.com/solutions/23016) 9. [Create an Apache-based YUM/DNF repository on Red Hat Enterprise Linux 8](https://www.redhat.com/sysadmin/apache-yum-dnf-repo) 10. [Repositories/Personal - Community Help Wiki](https://help.ubuntu.com/community/Repositories/Personal) 11. [Setup Delivery Optimization (DO) for ConfigMgr Current Branch - Deployment Research](https://www.deploymentresearch.com/setup-delivery-optimization-do-for-configmgr-current-branch/) ### References - "What is Quality of Service? - Palo Alto Networks." [https://www.paloaltonetworks.com/cyberpedia/what-is-quality-of-service-qos](https://www.paloaltonetworks.com/cyberpedia/what-is-quality-of-service-qos) . Accessed 8 Mar. 2021. - “Delivery Optimization for Windows 10 updates”, [https://docs.microsoft.com/en-us/windows/deployment/update/waas-delivery-optimization](https://docs.microsoft.com/en-us/windows/deployment/update/waas-delivery-optimization) --- # Patching When the Severity Level Is Unknown _Section: Product Documentation › Patching • Source: https://docs.automox.com/product/Content/Product%20Documentation/Patching/Patching_When_the_Severity_Level_Is_Unknown.htm_ When a software patch listed in the Automox console shows a severity level of "Unknown", this generally means that Automox was unable to retrieve sufficient information to give it a rating. Additionally, some vendors announce a vulnerability, reserve a CVE, but then do not provide any information. To ensure CVEs with no severity score are automatically updated, you can use either a Patch All or an Advanced Policy. Automox recommends using a **Patch All** policy. --- # Sometimes Patch Scoring Differs Between Automox and Other Tools _Section: Product Documentation › Patching • Source: https://docs.automox.com/product/Content/Product%20Documentation/Patching/Sometimes_Patch_Scoring_Differs_Between_Automox_and_Other_Tools.htm_ What to do if there is a discrepancy between the patches Automox shows vs. another tool. You might find a difference between the patches the Automox platform shows and another tool. The reasons for this could be based on the following: - Automox consumes feeds and scores from sources such as, but not limited to: NVD, Microsoft Security Updates, RedHat, Debian, and Ubuntu. - Not all sources work the same way or provide the same information. - Discrepancies are usually due to the policy scopes that have been selected, but can sometimes be due to missing source information or data from an unsupported OS. - Apple does not release severity data for macOS patches. ### What to do? If you see a discrepancy, [contact Support](https://help.automox.com/hc/en-us/requests/new) in the Automox Help Center. --- # Understanding Automox Severity Data _Section: Product Documentation › Patching • Source: https://docs.automox.com/product/Content/Product%20Documentation/Patching/Understanding_Automox_Severity_Data.htm_ Automox provides severity data for Windows, macOS, and Linux operating systems, as well as top third-party software packages. Where does the vulnerability severity score come from and how is it calculated? What are the effects on my patching? Severity information used by Automox originates from OS and app providers. An independent group of security researchers calculates the CVSS severity score. How this is calculated is described in the [National Vulnerability Database](https://nvd.nist.gov/vuln-metrics/cvss). ## Automox severity scoring The severity of CVEs are based on CVSS scores. These scores have different mappings to severity classifications. The following mapping table shows how Automox defines the previous version 2 and the new version 3 severity ratings of a package: --- # Using a Manual Approval Policy _Section: Product Documentation › Patching • Source: https://docs.automox.com/product/Content/Product%20Documentation/Patching/Using_a_Manual_Approval_Policy.htm_ The manual approval policy installs only packages that an administrator approves. When you create a manual approval policy and associate it with a group, you can approve or reject packages that are available for approval. ## Manual Approval Policy page ![](../../Resources/Images/edit-manual-approval-policy.png) ### Manage Approvals from the Package Ready For Approval page ![](../../Resources/Images/packages-ready-table.png) The basic manual patch approval process is as follows: **Prerequisites**: This assumes that a manual policy already exists and is associated with a group. For information about creating a manual approval policy, see Creating a Manual Approval Policy in [Creating a Patch Policy](../Policies/Creating_a_Patch_Policy.htm). 1. Go to the **Automate → Policies** page and find the manual approval policy you want to approve patches for. 2. To see the list of packages, open the **Packages Ready For Approval** page: - From the **Policies** page, click the Name of the policy to open the policy and click **Manage Approvals**, or - From the **Policies** page, click the **Actions** menu on right, and click **Manage Approvals**. - **Note**: The policy must be associated with at least one group for any packages to be available for approval. 3. From the **Packages Ready For Approval** page, select the check box for the package and click **Approve** or **Reject**. You can do this for multiple packages at the same time. 4. When you select **Approve**, the software is approved for your policy and is applied on your policy’s next scheduled update. 5. When you select **Reject**, the package is not scheduled for remediation and the software status changes to **Rejected**. You can use the filter on the left to view by OS or status. **Note**: To search for specific packages by name use the general search box or filter by OS or Status. --- # Using the Advanced Patch Policy _Section: Product Documentation › Patching • Source: https://docs.automox.com/product/Content/Product%20Documentation/Patching/Using_the_Advanced_Patch_Policy.htm_ Automox supports the ability to exclude particular patches or the ability to only deploy patches that match a particular query. The advanced patch policy takes this a step further by allowing you to create custom patching configurations by choosing certain conditions that best match the desired compliance requirement for the device. See [Creating a Patch Policy](../Policies/Creating_a_Patch_Policy.htm): Advanced Policy. --- # What Are the Recommended Best Practices for Patching in Automox? _Section: Product Documentation › Patching • Source: https://docs.automox.com/product/Content/Product%20Documentation/Patching/What_Are_the_Recommended_Best_Practices_for_Patching_in_Automox_.htm_ Automox offers a variety of templates to create policies that conform to Automox best practice recommendations. These templates are available from our Next steps guide (available on the dashboard in the console), or you can use these links to quickly create these policies within your environment. ## Cross-OS [https://console.automox.com/manage/policies/catalog/8494e6e3-bae7-4b7d-8ad0-daed2cfb7a72](https://console.automox.com/manage/policies/catalog/8494e6e3-bae7-4b7d-8ad0-daed2cfb7a72)[Cross-OS - Patch Browsers](https://console.automox.com/manage/policies/new?template_id=1) - *Ensure web browsers are secure and updated* [Cross-OS - Third-Party Updates](https://console.automox.com/manage/policies/catalog/6e9a1ee6-18b7-475a-9989-97f5a4b8f882) - *Apply updates to all supported third-party software* ## Windows [Windows - Servicing Stack Updates](https://console.automox.com/manage/policies/catalog/14164b2c-35f4-4e98-89e8-d41243b835b7) - *Ensure core patching can execute by keeping your servicing stack up-to-date* [Windows - Security Definitions Updates](https://console.automox.com/manage/policies/catalog/9b5c1cd7-15b0-4b9b-a798-7bff024a5580) - *Apply security definition updates for Windows* [Windows - First-Party Updates](https://console.automox.com/manage/policies/catalog/53924f74-ff55-4b4a-bda6-4920c4e0dbc7) - *Apply first-party Windows updates 7 days after their release date* [Windows - Microsoft Office KB updates](https://console.automox.com/manage/policies/catalog/454fcea7-ab88-4802-9bbc-e251136eb097) - *Ensure Microsoft Office packages are secure and updated* [Windows - Feature Upgrades](https://console.automox.com/manage/policies/catalog/eecf9807-84b7-4f2e-a261-444cbb352d10) - *Apply feature updates for Windows Workstations* ## macOS [macOS - Security Definitions Updates](https://console.automox.com/manage/policies/catalog/cfcaa5c5-02ee-4bed-9eb0-affca570fca8) - *Apply security definition updates for macOS* [macOS - First-Party Updates](https://console.automox.com/manage/policies/catalog/94096c17-f600-402a-b2df-0b81813cee0f) - *Apply first-party macOS updates 7 days after their release date* ## Linux [Linux - First Party Updates Not Requiring a Restart](https://console.automox.com/manage/policies/catalog/bfa8421b-dcfa-4af5-b30a-acebc67d1a48) - *Apply updates to Linux packages that do not require a restart* [Linux - First Party Updates Requiring a Restart](https://console.automox.com/manage/policies/catalog/988f4661-2559-4db8-83d9-aee42cb16119) - *Apply updates to Linux packages that require a restart* [Linux - Apply All Updates](https://console.automox.com/manage/policies/catalog/715d0cd4-17de-4292-aa7c-de55db73e663) - *Apply updates to all Linux packages* ## Related Topics - See [Third-Party Patching Best Practices](../Third-Party Software/Third_Party_Patching_Best_Practices.htm) for details about third-party overrides options. - [Automox Console Dashboard](../Console Overview/Automox Console Dashboard.htm) --- # What Happened to "Other" Severity Packages _Section: Product Documentation › Patching • Source: https://docs.automox.com/product/Content/Product%20Documentation/Patching/What_Happened_to__Other__Severity_Packages.htm_ The possible severity score of software packages called **Other** shows as **Unknown**. When the severity level for a package is not scored and/or the vendor provides an insufficient amount of information, the console shows **Unknown**. If the package receives a score, the console reflects it and any applicable policies will deploy it accordingly. **Unknown** indicates that a CVE is has not been scored yet or Automox has insufficient information to provide a severity score. ## Related Topics - [Understanding Automox Severity Data](Understanding_Automox_Severity_Data.htm) --- # What are macOS Background Updates? _Section: Product Documentation › Patching • Source: https://docs.automox.com/product/Content/Product%20Documentation/Patching/What_are_macOS_Background_Updates_.htm_ You can view or modify software update settings for macOS. Default settings on macOS enable Apple to routinely and silently push out updates to your device. You can view or modify this preference in the Software Update preference pane: ![](../../Resources/Images/os-auto-updates.png) Background updates include important updates to these built-in macOS security tools: **Gatekeeper**: Validation of third-party applications **Malware Removal Tool (MRT)**: Anti-malware **XProtect**: Signature-based antivirus In the Automox console Group settings, you can select **Disable OS Automatic Updates** under OS Patch Management. For more about Groups, see [Managing Groups](../Group Management/Managing_Groups.htm). ![](../../Resources/Images/os-patch-mgmt-disable.png) With this setting, Automox manages background updates in the console, and they appear as follows: Gatekeeper Configuration Data MRTConfigData XProtectPlistConfigData ## Related Topics - [Protecting against malware](https://support.apple.com/en-om/guide/security/sec469d47bd8/1/web/1) --- # Why a Patch Changed From Critical to High _Section: Product Documentation › Patching • Source: https://docs.automox.com/product/Content/Product%20Documentation/Patching/Why_a_Patch_Changed_From_Critical_to_High.htm_ Why does a Critical patch I just installed now show a severity of High? Severity services have migrated to CVSSv3 scoring. These are based on the CVSS as described in the [National Vulnerability Database](https://nvd.nist.gov/vuln-metrics/cvss). The scoring range for **Critical** was previously defined by Automox as from 7.0–10.0. The change from v2 to v3 ranges are as follows: --- # macOS Best Practices: Patch Notifications & CVEs _Section: Product Documentation › Patching • Source: https://docs.automox.com/product/Content/Product%20Documentation/Patching/macOS_Best_Practices__Patch_Notifications___CVEs.htm_ For patch administrators, be aware that Apple Inc. does not have a consistent patching schedule for when they release macOS security and feature updates. This is in contrast to Microsoft, who provides Patch Tuesday updates. This can create a problem for macOS administrators, because this requires they consistently check their devices if a patch is available, and in some cases, they might get a patch later than their fleet. ## Patch Notifications There are two ways you can get notifications about new patches for macOS devices. 1. Apple has a public security notifications and announcements mailing list you can sign up for. This sends an automatically generated email any time that Apple releases a patch for macOS (this includes patches for iOS, tvOS, etc.). - You can sign up [here](https://lists.apple.com/mailman/listinfo/security-announce/); please make sure to review the document before subscribing to the mailing list. 2. Apple also posts all its security updates and patches [here](https://support.apple.com/en-us/HT201222). This page provides patch names, patch information, affected devices, and release dates. - This list includes updates and patches for macOS and app updates, such as Safari and Bootcamp. - Some of these updates also include CVEs in the patch notes, although the CVEs and Severity are not included in the metadata of these patches. ## CVEs As stated earlier, Apple Inc. does not include CVEs in the metadata of patches they release. This can be a pain point for Mac administrators. Automox now includes severity data for native macOS packages. However, updates for applications that are included with macOS are updated as part of the OS update. For example, App Store would be updated when you install the macOS update. Third-party macOS packages are not included at this time. See also: [Apps included on your Mac](https://support.apple.com/en-ca/guide/mac-help/mchl110b00b7/mac). | Question | Answer | | --- | --- | | What kind of severity data are we providing for macOS packages? | Severity data is shown for CVEs that are specifically fixed by the patch. CVEs fixed by prior versions are not shown. | | What if I have a macOS 13.2 installed, but the newest is 14.2? | The only severity score that shows for this package are CVEs relevant for all security flaws between versions 14.1 and 14.2. | | Are there any known limitations? | Automox uses the National Vulnerability Database (NVD) for severity information. Because the NVD and the Apple security repositories are out of sync, there can be a lag in the list of CVEs that are mapped to packages. The true severity of a patch could be misrepresented. To see the full list of CVEs applicable to a macOS package, refer to Apple Security Releases. | | How can I remediate macOS vulnerabilities? | Use the By Severity policy to ensure you’re patching devices according to the severity you want to see patched. Alternatively, you can patch a specific package using the Patch Only policy. | ## Related Topics - [Understanding Automox Severity Data](Understanding_Automox_Severity_Data.htm) - [Creating a Patch Policy](../Policies/Creating_a_Patch_Policy.htm) --- # Cloning Policies _Section: Product Documentation › Policies • Source: https://docs.automox.com/product/Content/Product%20Documentation/Policies/Cloning_Policies.htm_ You can clone individual policies from the **Automate → Policies** page. This allows you to create a duplicate, or clone, of a policy within the current organization or to one or more other organizations. This action clones the device targeting, package targeting, schedule, and user notification configurations, if available. This does not clone the group settings. By default, the policy status is always Inactive. **Note**: Currently, you cannot clone required software policies or worklets. You can also use the Automox API to clone policies. Refer to the [Automox Developer Portal](http://developer.automox.com/) for more information. **Prerequisites**: You must have permissions to create policies for the organization you are cloning to. In the console, follow these steps to clone a policy to one or more organizations: 1. From the **Policies** page, find the policy you want to clone and select the **Actions** menu. 2. Click **Clone Policy**. 3. In the Clone Policy window, select the destination organization or organizations that you want to clone the policy to. 4. Click **Clone Policy**. This creates a policy or policies with the prefix “Clone of” in the corresponding organizations that you chose to clone to. The name of the cloned policy also includes the time and date when the clone was created. **Note**: You can clone to the current organization. 5. In the next window, you can select a policy to immediately view or edit. This cloned policy opens in a new browser window. This shortcut allows you to easily open cloned policies in the corresponding organizations. 6. Click **Done** to return to the Policies page. **Note**: Cloned policies require additional configuration before they are available to use. Select from the list of links in the cloned policies window to view each policy. You can also select the clone from the Policies page of the organization where it was created. Complete the desired configuration before you activate them. All cloned policies are inactive by default. Example of a clone created in the current organization: ![](../../Resources/Images/clone-policy.png) ### Completing the configuration of a cloned policy From the **Policies** page of the organization where you cloned a policy to, you see the Name with the suffix “Clone of”. In the previous example, the original policy is named *Apply All Patches*. The cloned policy is *Clone of Apply All Patches*. The new policy name includes the time and date of when the clone was created. 1. To edit the cloned policy, click the name of the policy. 2. In the Edit policy window, update the Policy Name. This must be a unique name within an organization. 3. Edit the following fields, as required: - Change the Policy Status to **Active**. - To run the policy, you must associate groups with the policy. Click **Associate Groups**to assign groups to this policy. - Adjust the device targeting, package targeting, schedule, and user notifications, if applicable. 4. Click **Save Policy**. ### Searching for cloned policies If you closed the window with the list of cloned policies, but you want to finish a configuration or remove a cloned policy, follow these steps to find the cloned policy. 1. Go to the destination organization of the cloned policy. 2. Enter “Clone” in the search bar. All cloned policies appear in alphabetical order. You can decide to edit and save the clone under a different name, or remove the clone from the current organization. ![](../../Resources/Images/search-clone.png) ### Removing a cloned policy You might want to remove a cloned policy that you no longer want to activate. This action removes only the cloned policy from the current organization. 1. Go to the Policies page of the organization where the cloned policy is listed. 2. Click **Actions → Remove Policy**. 3. A warning message allows you to confirm the policy you are about to remove. Click **Remove Policy**. **Note**: This action only removes a cloned policy from the current organization. It does not remove the same clone from other organizations. --- # Creating a Patch Policy _Section: Product Documentation › Policies • Source: https://docs.automox.com/product/Content/Product%20Documentation/Policies/Creating_a_Patch_Policy.htm_ Patch policies patch some or all of the software that Automox natively supports. From the main console, click **Automate → Policies.** Click **Create Policy.** The following types of patch policies are available and are described here. **Note**: For information about configuring device targeting, user notifications, or setting a patching schedule, refer to [Device Targeting with Filters](Device_Targeting_with_Filters.htm), [Managing End-User Notifications](../Notifications & Restarts/Managing_End_User_Notifications.htm), and [Setting a Patching Schedule](Setting_a_Patching_Schedule.htm) . ![](../../Resources/Images/create-policy-overview.png) ## Patch All Use this policy type to patch all supported software. This includes all operating system patches and supported third-party software. To create a Patch All policy, follow these steps: 1. From the Policy page, click **Create Policy**. 2. From the Create Policy page, click **Patch All**. 3. You can now edit the details of the Patch All policy. **Note**: You can use the **Type** menu to switch between patch policy types. 4. In the Info area of the Create Patch All Policy page, configure the following: - In the **Policy Name** field, enter a unique name for the policy. This field is required. - In the **Notes** field, enter any notes, if required. 5. Switch the **Policy Status** to Active or Inactive. This enables or disables patching. If you want to pause patching, select Inactive. 6. To automatically install any Windows updates, choose **Yes** for the **Install Optional and Recommended Windows Update**. The default is No. This allows for the policy to install items that have the optional patch scope condition. (See also [Can Automox Patch Driver or Firmware/Hardware Updates?](https://help.automox.com/hc/en-us/articles/31577553349012-Can-Automox-Patch-Driver-or-Firmware-Hardware-Updates)) 7. (Optional) Set filters under Device Targeting, as needed. 8. Set the patching schedule. 9. (Optional) From the User Notifications section, select what kind of notifications you want. 10. To assign this policy to a group, click **Associate Groups**. Select a group or groups that you want associated with this policy. Click **OK**. 11. Click **Create Policy**. ## Severity Use this policy type to select the severity level you want to have included in the patch update: Critical, High, Medium, Low, None, and Unknown. You can select multiple severities. The severity levels are defined by the CVE score. See also [Understanding Automox Severity Data](../Patching/Understanding_Automox_Severity_Data.htm). To create a By Severity policy, follow these steps: 1. From the Policy page, click **Create Policy.** 2. From the Create Policy page, click**Severity**. 3. In the Info area of the Create By Severity Policy page, configure the following: - In the **Policy Name** field, enter a unique name for the policy. - In the **Notes** field, enter any notes, if required. 4. Switch the Policy Status to Active or Inactive. This enables or disables patching. If you want to pause patching, select Inactive. 5. To automatically install any Windows updates, choose **Yes** for the **Install Optional and Recommended Windows Update**. The default is No. This allows for the policy to install items that have the optional patch scope condition. 6. (Optional) Set filters under Device Targeting, as needed. 7. Use the [Package Targeting](#Package) area to select the severities that you want to have patched. You can select one or all of the following severity types: Critical, High, Medium, Low, None, and Unknown. 8. Set the patching schedule. 9. (Optional) From the User Notifications section, select what kind of notifications you want. 10. To assign this policy to a group, click **Associate Groups**. Select a group or groups that you want associated with this policy. Click **OK**. 11. Click **Create Policy**. ## Patch Only For this type of policy, you can select all packages that you want patched. Use the filter options to find these packages. Select the checkbox next to each package that you want to include in the patch. Your selections will appear on the right. To create a Patch Only policy, follow these steps: 1. From the Policy page, click **Create Policy**. 2. From the Create Policy page, click **Patch Only.** 3. In the Info area of the Create Patch Only Policy page, configure the following: - In the Policy Name field, enter a unique name for the policy. This field is required. - In the Notes field, enter any notes, if required. 4. Switch the Policy Status to Active or Inactive. This enables or disables patching. If you want to pause patching, select Inactive. 5. To automatically install any Windows updates, choose Yes for the Install Optional and Recommended Windows Update. The default is No. 6. (Optional) Set filters under **Device Targeting**, as needed. 7. Use the [Package Targeting](#Package) area to identify and select specific packages that you want to patch. - Select the Automox Supported checkbox to filter the list for only software packages that are managed by Automox. - Use the filter field or scroll through the list of packages associated with this device. - Select the checkbox next to each package that you want to include in the patch. - Your selections will appear on the right. - See the information tip in the console for further guidance. 8. Set the patching schedule. 9. (Optional) From the User Notifications section, select what kind of notifications you want. 10. To assign this policy to a group, click **Associate Groups**. Select a group or groups that you want associated with this policy. Click **OK**. 11. Click **Create Policy**. ## Manual Approval A manual approval policy installs only patches that an administrator approves. This policy type can be activated to run on a schedule at the frequency of your choice. To create a manual approval policy, follow these steps: 1. From the Policy page, click **Create Policy**. 2. From the Create Policy page, click **Manual Approval**. 3. In the Info area of the Create Manual Approval Policy page, configure the following: - In the **Policy Name** field, enter a unique name for the policy. This field is required. - In the **Notes** field, enter any notes, if required. 4. Switch the **Policy Status** to Active or Inactive. This enables or disables patching. If you want to pause patching, select Inactive. 5. To automatically install any Windows updates, choose **Yes** for the **Install Optional and Recommended Windows Update**. The default is No. This allows for the policy to install items that have the optional patch scope condition. 6. Click **Associate Groups** and select the groups that should be associated with this policy. Click **OK**. 7. (Optional) Set filters under Device Targeting, as needed. 8. Set the patching schedule. 9. (Optional) From the User Notifications section, select what kind of notifications you want. 10. Click **Create Policy**. ### Managing Approvals After the policy is created, you can view and manage packages that are ready for approval, or save the policy and manage approvals at a later time. **Note**: The policy must be associated with at least one group for any packages to be available for approval. 1. To view the packages that are ready for approval, click **Manage Approvals**. - You can also use the Manage drop-down menu from the top navigation of the console to access the approvals list. 2. From the **Packages Ready For Approval** page, use the filters and search options to sort the list of packages. 3. Select the checkbox of packages that you want to approve or reject. Click Approve or Reject for each package, or for a group of selected packages. **Note**: When you approve a patch, the software is applied on the policy's next scheduled update. 4. Click **Edit Policy** to return to the Manual Approval Policy page. **Note**: The package scope here is limited to only the devices associated with the group or groups associated with the policy. ## Patch All Except For this type of policy, you can select all packages that you do not want patched. Use the filter options to find these packages. Select the checkbox next to each package that you want to exclude from the patch. Your selections will appear on the right. To create a Patch All Except policy, follow these steps: 1. From the Policy page, click **Create Policy**. 2. From the Create Policy page, click **Patch All Except**. 3. In the Info area of the Create Patch All Except Policy page, configure the following: - In the **Policy Name** field, enter a unique name for the policy. This field is required. - In the **Notes** field, enter any notes, if required. 4. Switch the **Policy Status** to Active or Inactive. This enables or disables patching. If you want to pause patching, select Inactive. 5. To automatically install any Windows updates, choose **Yes** for the **Install Optional and Recommended Windows Update**. The default is No. This allows for the policy to install items that have the optional patch scope condition. 6. (Optional) Set filters under Device Targeting, as needed. 7. Use the [Package Targeting](#Package) area to identify and select packages that you do not want to patch. - Select the **Automox Supported** checkbox to filter the list for only software packages that are managed by Automox - Use the search box or scroll through the list of packages associated with this device. - Select the checkbox next to each package that you want to exclude from the patch. Your selections will appear on the right. - See the information tip in the console for further guidance. 8. Set the patching schedule. 9. (Optional) From the User Notifications section, select what kind of notifications you want. 10. To assign this policy to a group, click **Associate Groups**. Select a group or groups that you want associated with this policy. Click **OK**. 11. Click **Create Policy**. ## Advanced Policy Use the advanced patch policy to create custom patching configurations by choosing certain conditions that best match the desired compliance requirement for the device. To create an advanced patch policy, follow these steps: 1. From the Policy page, click **Create Policy**. 2. From the Create Policy page, click **Advanced**. 3. In the Info area of the Create Advanced Policy page, configure the following: - In the **Policy Name** field, enter a unique name for the policy. - In the **Notes** field, enter any notes, if required. 4. Switch the Policy Status to Active or Inactive. This enables or disables patching. If you want to pause patching, select Inactive. 5. To automatically install any Windows updates, choose **Yes** for the **Install Optional and Recommended Windows Update**. The default is No. This allows for the policy to install items that have the optional patch scope condition. 6. (Optional) Set filters under Device Targeting, as needed. 7. Use the Package Targeting area to select the conditions that you want to have patched. See [[Package Targeting](#Package)](https://help.automox.com/hc/en-us/articles/5775441950356#CreatingaPatchPolicy-PackageTargetingtarget) for details. 8. Set the patching schedule. 9. (Optional) From the User Notifications section, select what kind of notifications you want. 10. To assign this policy to a group, click **Associate Groups**. Select a group or groups that you want associated with this policy. Click **OK**. 11. Click **Create Policy**. ### Package Targeting In addition to setting filters to target specific devices, you can add package targeting to your **patch only**,**patch all except**,**by severity**, and**advanced policies**. This is a custom patching configuration that targets packages according to the filter options that fit your requirements. The following are the current options for package targeting for an advanced patch policy: - Patch Source (Microsoft, Apple, etc.) - Patch OS - Type (Windows Only) - Display Name - Patch Severity - Patch Age ![](../../Resources/Images/advanced_policy_pkg.png) Example for Package Targeting: Patch OS - In the following example, you select **Patch OS** as the first condition which targets all patches based on the OS the device is running. This example is targeting any device that is running Microsoft Windows. ![](../../Resources/Images/pakg-target-patchos.png) Example for Package Targeting: Patch Severity - You can add as many conditions as desired. The policy continues to refine the list of patches it remediate it runs on the devices. In the following same example, you can see that **Patch Severity** was added as an additional condition, for which the severity is **Critical**. ![](../../Resources/Images/pkg-target-patch-sev.png) Example for Package Targeting: Patch Age - You can also add the option to target only packages that are over a certain number of days old. Use the option **Patch Age** and set a number between 1 and 180. Use this option if you want to only push a patch if the patch was released x number of days ago. This is useful if you do not want to push out brand new patches on your production devices until there has been a period of time that has passed. **Note:** This option is currently only available for Advanced policies. ![](../../Resources/Images/pkg-target-patch-age.png) After you configure all the conditions, to preview the patches the policy remediates, click **Preview Packages That Would Be Patched**.This will show all of the packages that are targeted by the policy for remediation. --- # Creating a Required Software Policy _Section: Product Documentation › Policies • Source: https://docs.automox.com/product/Content/Product%20Documentation/Policies/Creating_a_Required_Software_Policy.htm_ The required software policy distributes and installs software to the devices in your organization. By uploading an installation binary and setting the package name, installation command, and schedule, you can deploy software to an unlimited number of systems. **Note**: The file size limit is **10 GB**. To create a required software policy, follow these steps: 1. From the main console, click **Automate → Policies**. 2. Click **Create Policy**. 3. From the Create Policy page, go to the **Required Software Policy** section and select the corresponding OS for the policy you want to create. 4. In the Policy Info area, configure the following: - **Policy Name**: Enter a name for the policy. This field is required. - **Notes**: Enter any notes, if required. 5. (Optional) Set filters under Device Targeting, as needed. 6. Complete the **Scope** section: (**Note:**These fields no longer auto-populate.) - Enter the required **Package Name** - Enter the **Package Version** 7. Click **Upload File** to upload the installation file for the software update. 8. Use the Installation Command field to create a script for the software installation. (**Note:**This field no longer auto-populates.) This is required if a script is not found on the device. 9. In the **Schedule area**, set the patching schedule that runs on the device. The Schedule Preview provides a calendar view of the patching schedule. See [Setting a Patching Schedule](Setting_a_Patching_Schedule.htm). 10. (Optional) Associate this policy with a group by selecting the plus in the upper right of the page and selecting the desired groups. When the policy is saved, the group is then assigned to the policy. 11. Click **Create Policy**. ## Related Topics - [Managing Policies](Managing_Policies.htm) - [Device Targeting with Filters](Device_Targeting_with_Filters.htm) - [Automox University: Required Software Policies](https://university.automox.com/required-software-policies) --- # Creating a Worklet _Section: Product Documentation › Policies • Source: https://docs.automox.com/product/Content/Product%20Documentation/Policies/Creating_a_Worklet.htm_ Use the Worklet™ option to perform any scriptable action on devices, including disabling a vulnerable process, managing native OS controls, mass rollback of patches, and moving unwanted applications. You can include variables to securely retrieve secrets. You can also configure restart notifications and deferral settings for worklets. **Note**: - Before you create a worklet from scratch, browse the [Worklet Catalog](https://help.automox.com/hc/en-us/articles/17985679771796-Using-the-Worklet-Catalog) for available and customizable worklets. - To view the Worklet Catalog, your organization must be under a plan that includes Worklets. However, a subset of worklets are available to all users. These worklets are tagged as Base in the catalog. ## Creating a Worklet To create a worklet, follow these steps: 1. From the main console, click **Automate → Policies**. 2. Click **Create Policy**. 3. From the Create Policy page, go to the Worklets section and select the corresponding OS for the policy you want to create. **Note**: The worklet you create should be run on a device of the same OS. 4. In the Policy Info area, configure the following: - **Policy Name**: Enter a name for the worklet. This field is required. - **Notes**: Enter any notes, if required. 5. (Optional) Set filters under **Device Targeting**, as needed. See [Device Targeting with Filters](Device_Targeting_with_Filters.htm) for more information. 6. (Optional) Configure **Inputs**. Use the Inputs section to add environment variables to the worklet code. See [Secrets Management](../Settings/Secrets_Management.htm) for more information. 7. (Optional) Configure **Payload**. Select a file to deploy with the worklet. **Note:** The file size limit is **10 GB**. 8. In the **Scope** section, enter a script for the worklet you are creating. - Enter the evaluation and remediation code required for your worklet. - Refer to [How to Use Worklets](../Worklets & Required Software/How_to_Use_Worklets.htm). For example worklets, browse our Worklet Catalog for Automox verified worklets, or the [Community Worklets](https://community.automox.com/community-worklets-12) library. - **Note:** If you switch to a different OS, the code fields are automatically cleared. 9. In the **Schedule** area, set the patching schedule that runs on the device. The Schedule Preview provides a calendar view of the patching schedule. See [Setting a Patching Schedule](Setting_a_Patching_Schedule.htm). 10. After you set the schedule, you can configure **Restart Notifications**. Refer to [End-User Notifications](../Notifications & Restarts/End_User_Notifications.htm). 11. **Associate Groups** to associate this policy with the desired groups. When the policy is saved, the group is then assigned to the policy. 12. Click **Create Policy**. ![](../../Resources/Images/create-worklet.png) ![](../../Resources/Images/worklet-scope.png) ![](../../Resources/Images/worklet-schedule-notifications.png) ## Disabling a Worklet To disable a worklet, follow these steps: 1. From the Policy page, click the worklet you want to disable. 2. From the **Edit Worklet**page, go to **Groups** and remove any associated groups. 3. Click **Save Policy**. ## Browse the Worklet Catalog The catalog of worklets allows you to immediately use a verified worklet for your purposes. You can also create a new policy based on an existing worklet. Refer to [Using the Worklet Catalog](../Worklet Catalog/Using_the_Worklet_Catalog.htm) for details. --- # Device Targeting with Filters _Section: Product Documentation › Policies • Source: https://docs.automox.com/product/Content/Product%20Documentation/Policies/Device_Targeting_with_Filters.htm_ Device targeting allows you to execute policies on a filtered collection of devices. All policy types and worklets can be configured to use device filtering. ## Creating a Device Filter on a Policy You can apply filters on new and existing policies or worklets to target devices. You can add up to 10 filters per policy and 10 values per filter. For details about creating a policy or worklet, see [Managing Policies](Managing_Policies.htm). **Note**: The Condition field options have been updated. Refer to the table in **[Filters and their values](#Filters)** for a description of the options. ![](../../Resources/Images/device-targeting.png) 1. From the Create or Edit Policy page, use the toggle to turn on **Device Targeting.** 2. From the **Select Attribute** drop-down menu, select the filter you want to use. You can filter by: - Device Tag - IP Address - Hostname - OS - OS Version - Active Directory Organizational Unit (Windows only) 3. Select from the options available in the **Condition** field. The options available depend on the attribute selected. 4. Use the **Value** field to enter the options related to the filter. You can select a maximum of 10 options. 5. Click **Preview Impacted Devices** to retrieve a list of all devices included in the policy. The resulting Devices Preview window helps to ensure that you have correctly configured the filter. 6. If you are creating a new policy or worklet, at this point you can also set a schedule and configure user notifications. Click **Create Policy.** 7. If you are editing a policy or worklet, click **Save Policy**. ### Filters and their values You can create up to 10 filters and apply up to 10 values per filter. Each filter row uses an "And" operation. These narrow down the results to fit all filters. The values set within the Options field use an "Or" operation. The following table describes the filter types and the values that are currently available. | Filter | Values | Description | | --- | --- | --- | | Attribute | Device Tag IP Address Hostname OS OS Version Active Directory Organizational Unit | These are the types of filters you can apply to this policy. | | Condition | Is Is not Contains Does not contain | Depending on the type of attribute, you can use these conditions to define the filter. | | Value | The value options available depend on the attribute selected. | | **Example 1** A single filter (row) with multiple values targets any device with value option 1 or value option 2, or both. ![](../../Resources/Images/device_targeting_or.png) The impacted devices include at least one of the value options. Therefore, in this example, the tags "Accounting" and "test_UX" include all devices with these tags. If there are more tags, the device will still be included because it uses at least one of the values selected. **Devices Preview:** This is a preview of the devices the device targeting filter currently applies to. This device targeting filter only applies to devices that are in groups associated with this policy. Ensure you have the correct groups associated with this policy. ![](../../Resources/Images/preview_or.png) **Example 2** Separate filters (rows) are an "And" condition. In this example, both "accept" and "1.2.3.4" are valid. An impacted device must have each filter condition. ![](../../Resources/Images/device_targeting_and.png) The impacted devices now reflect the conditions required for all filters. In this example, only the devices with exactly the IP address `1.2.3.4` and the Tag `accept`, are targeted. ![](../../Resources/Images/device_targeting_and_preview.png) ### Other filter examples - [Hostname](#Hostname) - [IP Address](#IP) - [Creating an Active Directory Organizational Unit Device Filter](#Creating) #### **Hostname** Use the Hostname to target devices. You can use partial name searches to gather the list of devices to which you want to apply a policy. 1. Select the attribute **Hostname**. 2. Select from the Condition field: Contains or Does Not Contain. 3. Enter a values or partial value. 4. Click **Preview Impacted Devices** to see results. The result shows all devices that have a Hostname with the value "desktop": #### **IP Address** IP address filters currently match on any partial string in the IP address field. For example, if you filter for 1.1, all the following IP addresses match: 1.1.5.6 10.10.1.1 11.12.5.7 192.168.1.1 192.1.1.55 192.11.1.65 **Note**: The IP filter evaluates all network interfaces on a device. In some instances the primary network interface address may not match the filter, however, if any of the other network interfaces on the device contain the search string then it will result in a match. ## Device Targeting Based on OU Information You can use the device targeting filter **Active Directory Organizational Unit (AD OU)** to run policies based on Organizational Units. This allows you to filter devices based on your AD structure. The AD OU information is collected when a device is scanned. Therefore, the policy automatically applies to newly added devices. The AD OU filter allows you to match a string or strings. Example: /Locations/Sheriff/Computers/CAD Stations/Computers You can target a higher-level OU by using a partial match on the path. **Note:** - The Active Directory OU filter is available only for Windows devices - The maximum string length is 2048 characters - You can copy/paste the path structure into the Option field - This feature requires no direct Active Directory Domain Controller access because Automox pulls the AD OU information directly from each device. - Azure AD OU information requires a hybrid AD and Microsoft Entra ID (Azure AD) setup ### Creating an Active Directory Organizational Unit Device Filter Follow these steps to set up device filtering based on Organizational Units (OU). **Note**: Automox queries Active Directory OU information every time a device is scanned (when adding a device or at least every 24 hours - depending on your scan interval). ![](../../Resources/Images/device_targeting_ADOU.png) 1. From the Create or Edit Policy page, use the toggle to turn on **Device Targeting** and activate the feature toggle. 2. From the Select Attribute field, click **Active Directory Organizational Unit**. 3. Use the Select Condition field to select from the following operators: - Is, Is Not, Contains, Does Not Contain. 4. In the **Add Option** field, enter or paste one or more path structures. 5. Click **Preview Impacted Devices** to review the devices affected by the policy. 6. Click **Create Policy** or **Save Policy.** The policy runs according to the schedule. #### Targeting specific OUs To target a specific OU, use the **Is** condition. This filter requires full paths to the OU. Any sub-OUs are not included. ![](../../Resources/Images/device_targeting_ADOU_specific.png) ## Viewing and Searching for Policies with Device Targeting From the **Policies** page, you can see if the device filter is configured. - Use the Columns list to ensure that the device targeting columns is showing. - Sort the list of policies by the **Has Device Targeting** column. - Use the search box to find a specific policy. ## Deleting a Device Filter To delete an existing device filter in a policy or worklet, go to **Device Targeting**on the Edit page. 1. Click the delete ![(error)](https://automox.atlassian.net/wiki/s/2084916014/6452/fbd62261516448b37010ae3592fbc974b7f0453d/_/images/icons/emoticons/error.png) button to remove the device filter. 2. Click **Save Policy**. ## Related Topics - API Reference Guide: [Device Filters Preview - Filter Parameters](https://developer.automox.com/developer-portal/policy_filters_schedule/#device-filters---filter-parameters) - [Learn about Flexible Device Targeting](https://www.youtube.com/watch?v=qFXtPLJNDI4) --- # Filtering and Searching on the Polices Page _Section: Product Documentation › Policies • Source: https://docs.automox.com/product/Content/Product%20Documentation/Policies/Filtering_and_Searching_on_the_Polices_Page.htm_ From the **Automate → Policies** page, you can view a complete list of all the policies in your organization. Use the search bar and filter panel on the left to filter for those policies that you are interested in viewing. ![](../../Resources/Images/manage-policies-table.png) ## Policies Search Bar Use the **Search Policies** field to search for a specific policy. This search bar does not have the same functionality as the enhanced device search. Use the side filter panel for a more detailed search result. ## Policies Filter Panel The filter panel includes options to fine-tune your search. When you select any of the individual filters, a number in parentheses shows how many are selected. You can clear selections individually, or select **Clear All**. The panel can also be collapsed. ![](../../Resources/Images/policy-filter-panel.png) ### Policy Type To filter the list of policies by **Policy Type**, select from the options available in the filter panel. The resulting list of policies updates immediately when an option is selected. ### OS To filter the list of policies by OS**,**select the **OS** drop-down menu to choose from **Linux**, **macOS**, and **Windows**. You can select one or more. ### Groups To filter the list of policies by **Group**, select the menu and choose the groups that you want to view a list of policies for. Select and clear the checkboxes as needed. (Optional) Enter the group name in the search field to narrow down the list of groups. ### Patch Policy Status You can filter the list of policies by status. Select from Active or Inactive. An **Active** policy means patching is enabled. Select **Inactive** to filter the list of policies that have patching disabled. ## Related Topics - [Creating a Patch Policy](Creating_a_Patch_Policy.htm) - [Managing Policies](Managing_Policies.htm) --- # Managing Policies _Section: Product Documentation › Policies • Source: https://docs.automox.com/product/Content/Product%20Documentation/Policies/Managing_Policies.htm_ You can create patch, software, and custom configuration policies (Worklets) that are enforced regardless of geographic location. From the main console, click **Automate** to access these settings. ## Viewing Policies You can view a list of all policies in your organization from the **Automate → Policies** page. - Use the **Search Policies** field to search for a specific policy. ![](../../Resources/Images/manage-policies-table.png) ## Creating a Policy You can create new patch policies from the Policies page. 1. Click **Create Policy** to create different types of policies. 2. On the Create Policy page, click the type of policy you want to create. The types of policies are described in the following section. ## Policy Types Here are the types of policies you can create. Click the headings for detailed descriptions. ### [Creating a Patch Policy](Creating_a_Patch_Policy.htm) These policies patch some or all of the software that Automox natively supports. - Patch All - Patch Only - Patch All Except - Manual Approval - By Severity - Advanced Policy ### [Creating a Required Software Policy](Creating_a_Required_Software_Policy.htm) You can install and patch software packages that do not have native support from Automox. ### [Creating a Worklet](Creating_a_Worklet.htm) Worklets can perform any scriptable action on devices, including disabling a vulnerable process, managing native OS controls, mass rollback of patches, removing unwanted applications, and many other system configurations. ## Setting a Patching Schedule When you create a policy or worklet, you must set a schedule. Refer to [Setting a Patching Schedule](Setting_a_Patching_Schedule.htm) for details about start times and ensuring the schedule is configured for your needs. ### User Notifications You can configure user notifications to alert end users about upcoming updates or required restarts on Windows and macOS devices. These notifications appear in the Automox Tray and include a visible deadline for when action must be taken. For details about configuring user notifications and managing the Automox Tray experience, see [End-User Notifications](../Notifications & Restarts/End_User_Notifications.htm). Complete any other options according to the policy or worklet you are creating or editing and select Create Policy or Save Policy. ## Related Topics - [Creating a Patch Policy](Creating_a_Patch_Policy.htm) - [Filtering and Searching on the Polices Page](Filtering_and_Searching_on_the_Polices_Page.htm) - See the [Community discussions](https://community.automox.com/community-worklets-12) around worklets --- # Policy Catalog _Section: Product Documentation › Policies • Source: https://docs.automox.com/product/Content/Product%20Documentation/Policies/Policy%20Catalog.htm_ ## Overview The **Policy Catalog** is a page in the Automox console that provides a curated list of policy templates maintained by Automox®. These templates capture best-practice configurations so you don't have to build every policy from scratch. Use the Policy Catalog to quickly find recommended starting points, preview configurations, and create new policies tailored to your environment. ## Key Concepts - **Policies** — Active, saved configurations that run in your environment. - **Policy templates** — Read-only, best-practice starting points maintained by Automox. You can view them in the Policy Catalog and convert them into editable policies. With the Policy Catalog, you can: - Quickly find a recommended template instead of building a policy from scratch. - Filter and search templates by OS, type, or category. - Preview templates in read-only mode before using them. - Click **Create Policy** to copy a template into a new, editable policy. ## Where to Find the Policy Catalog 1. Sign in to the Automox console. 2. Click **Automate → Policies** in the main navigation. 3. At the top of the Policies page, select the **Policy Catalog** tab. You'll see two tabs: - **Policies** — Your active policies. - **Policy Catalog** — The catalog of Automox-maintained templates. The **Policy Catalog** page includes: - A table of policy templates - A search bar above the table - Filter controls (for example: OS, Policy Type, Category) - A **Create Policy** button for each template - An optional column selector to show or hide table columns ## Browsing Policy Templates When you open the **Policy Catalog** tab, you'll see a table of templates maintained by Automox. Typical columns include: - **Name** — Template name (for example, *Windows Patch Best Practice — Servers*) - **OS** — Target operating systems - **Type** — Policy type (for example, Patch Only, Advanced) - **Category** — For example, Third Party Software or OS Software - **Last Updated** — When Automox last updated the template - **Notes** — Short description of what the template does ### To browse templates 1. Go to **Policies → Policy Catalog**. 2. Scroll through the table to review available templates. 3. (Optional) Use the column selector to show or hide columns based on what matters most to you. ## Filtering the Policy Catalog Filters help you quickly narrow down templates based on your environment or use case. Available filters may include: - **OS** - **Type** - **Category** ### To filter templates 1. Open **Policies → Policy Catalog**. 2. Use the filter controls. 3. Select one or more values, such as: - OS (Windows, macOS, Linux) - Type (Patch Only, Advanced) - Category (Third Party Software, OS Software) The table updates automatically to display only matching templates. ### To clear filters - Deselect individual filter options. ## Searching the Policy Catalog Use the search bar above the templates table to locate specific templates. You can search by: - Template name - Operating system - Severity (if available) - Keywords in descriptions or tags ### Search behavior - Search is **case-insensitive**. - Results are returned if any word in your search phrase matches. - Fuzzy matching applies to short descriptors such as name, OS, or severity. - Exact matching applies to long descriptions, tags, or dates. - Results are prioritized based on: - The number of words in your search phrase that match - The total number of matches within each template ### To search for a template 1. Open **Policies → Policy Catalog**. 2. Click the search bar above the table. 3. Enter your search phrase. 4. Press **Enter** or wait for results to update. 5. Review the filtered results. ## Viewing a Template (Read-Only) You can open each template in a read-only view to inspect its configuration before creating a policy. ### To view a template 1. Go to **Policies → Policy Catalog**. 2. Locate the template. 3. Click either: - The template name, or - **View Details**. The template opens in a read-only page. Review the configuration and confirm it aligns with your needs. From this page, you can click **Create Policy** to generate a new editable policy using the template's settings. ## Creating a Policy from a Template When you create a policy from a template, Automox copies the template values into a new draft policy that you can edit before saving. Once saved, the new policy behaves like any other policy in your environment. ### Create a Policy from the Table View 1. Go to **Policies → Policy Catalog**. 2. Locate the template using filters or search. 3. Click **Create Policy** in the template row. You are redirected to the standard **Create Policy** form, pre-populated with: - Template name (editable) - OS and policy type - Default schedule (if defined) - Recommended options and settings 4. Review and update fields as needed: - Rename the policy for your environment. - Confirm or modify device targeting. - Associate groups. - Adjust scheduling. - Update any environment-specific settings. 5. Click **Save**. After saving, the new policy appears under the **Policies** tab. ### Create a Policy from the Read-Only View 1. Open a template from **Policies → Policy Catalog**. 2. Review the template details. 3. Click **Create Policy**. 4. Adjust settings as needed. 5. Click **Save**. ### Best Practice Use templates as a strong baseline, but always verify: - Scheduling - Device scoping - Group assignments This helps prevent applying settings too broadly during initial rollout. ## Managing Policies Created from Templates After you create policies from the catalog: - They appear on the **Policies** page. - They function like any other policy. You can: - Edit them - Disable them - Clone them (for example, to create development / test / production variations) - Remove them The **Policy Catalog** is only for browsing templates. Ongoing policy management occurs on the **Policies** page. ## Summary The Policy Catalog helps you: - Discover Automox-maintained, best-practice policy templates. - Quickly narrow options with filters and search. - Inspect templates safely in read-only mode. - Create new policies with a single click and customize them for your environment. Use the Policy Catalog to accelerate policy creation while maintaining flexibility and control. --- # Setting a Patching Schedule _Section: Product Documentation › Policies • Source: https://docs.automox.com/product/Content/Product%20Documentation/Policies/Setting_a_Patching_Schedule.htm_ Each policy or worklet must include a schedule. When creating or editing a policy, you can select from two schedule types: - **Custom**: Select specific months, occurrences, and days. - **Patch Tuesday**: Automatically schedule based on the second Tuesday of each month, with a configurable delay. ## Setting a Custom Schedule You can set a custom schedule from any policy or worklet page. 1. From the **Automate → Policies** page, click**Create Policy**. 2. Select the type of policy you want to create. 3. In the **Schedule** section of the Create Policy or Create Worklet page, select **Custom** from the schedule options. Use the following options to define the schedule: - **Months**: Select one or more months such as JAN, FEB, or MAR. - **Occurrences**: Select the occurrence of the day to run the policy: 1st, 2nd, 3rd, 4th, or 5th. - **Days**: Select one or more days such as MON, TUE, or WED. **Example**: To run a policy on the second Monday of June, select **JUN**, **2nd**, and **MON.** This applies to the second occurrence of Monday in the month, regardless of the calendar week. For example, June 9, 2025, is the second Monday of the month but occurs in the third week. 4. Click **Select All** to preselect all months, occurrences, and days. 5. Deselect any options that do not apply. The calendar preview updates automatically. ![](../../Resources/Images/schedule-occurrence.png) ## Setting a Patch Tuesday Schedule To set a **Patch Tuesday schedule**, select **Patch Tuesday** from the schedule type options. The following appears: **Patch Tuesday (second Tuesday of the month) [4] Days** The number represents the number of days after Patch Tuesday when the policy runs. This number is selected from a drop-down list ranging from 0 to 26. - Select **0** to run the policy on Patch Tuesday. - The **default value**, **4,** schedules the policy to run on the Saturday after Patch Tuesday. - The policy always runs in relation to the second Tuesday of the month, based on the number of days you select. ![](../../Resources/Images/schedule-patch-tuesday.png) ## Setting the Scheduled Start Time You can specify whether the policy starts based on the device's local time or UTC. ### Local Time of Device ![](../../Resources/Images/schedule-local.png) - Select**Local Time Of Device** if you want the policy to start the update according to the time zone where the device is located. - Use the drop-down list to set the start time. - When multiple devices in different time zones are associated with the policy, the time of the update starts according to the time zone of each device. ### UTC - Select UTC to start the policy at the same universal time for all the devices - Use the drop-down list to set the UTC start time. When multiple devices in different time zones are associated with the policy, the time of the update starts according to the UTC setting. All devices are updated at the same time, regardless of time zone. ![](../../Resources/Images/schedule-utc.png) **Note**: Scheduling according to UTC means finding the least disruptive time for the patch. The local time zones for users should be considered. At the same time, this type of scheduling could be used when there is an outage or maintenance window and the policy needs to start at a very precise time that spans across time zones. ### Handling missed patches You can decide how you want the device to patch if it misses a configured patch time. By selecting the checkbox after Scheduled Start Time, the device will patch the next time it checks in. ![](../../Resources/Images/schedule-missed-patches.png) Complete any other options according to the policy or worklet you are creating or editing and select **Create Policy** or **Save Policy**. ## Related Topics - [How to Use Global Scheduling in Automox Patch Management](https://patch.automox.com/video-automox-product-feature-global-scheduling) - See the [Community discussions](https://community.automox.com/community-worklets-12) around worklets --- # Determining Which Policies are Assigned to Which Group _Section: Product Documentation › Policy & Group Interactions • Source: https://docs.automox.com/product/Content/Product%20Documentation/Policy%20%26%20Group%20Interactions/Determining_Which_Policies_are_Assigned_to_Which_Group.htm_ You can view policy and group assignments from the **Automate → Policies** or**Manage → Groups** page. ## Viewing What Policies Are Associated With a Group You can view which policies are associated with a group. ![](../../Resources/Images/view-assoc-policies.png) 1. Go to the **Manage → Groups** page. 2. To view associated policies, hover over the number in the **Policies** column. 3. You can also view associated policies from the Edit Group page. Click the name of the group to open the Edit Group page. Associated polices are listed on the right. ## Viewing What Groups Are Associated With a Policy You can view which groups are assigned to a policy. ![](../../Resources/Images/view-assoc-groups.png) 1. Go to the **Automate → Policies** page. 2. To view associated groups, hover over the number in the **Groups** column. 3. You can also view associated groups from the **Edit Policy** page. Click the name of the policy to open the **Edit Policy** page. Associated groups are listed on the right. ## Run Policy While you are viewing the Policy associations, you can decide to immediately run the policy. 1. From the**Policies**page, click **Actions** for the policy you want to run. 2. To immediately execute the policy, click **Run Policy.** 3. Confirm by clicking **Run Policy**. - A message confirms that the policy is scheduled for immediate remediation. **Note**: If you choose to run a policy manually, Automox does not send notifications to the users. If notifications are required, Automox recommends creating a schedule instead. --- # Managing Policy and Group Assignments _Section: Product Documentation › Policy & Group Interactions • Source: https://docs.automox.com/product/Content/Product%20Documentation/Policy%20%26%20Group%20Interactions/Managing_Policy_and_Group_Assignments.htm_ From the **Automate → Policies** or **Manage → Groups** page, you can manage how policies and groups are assigned to each other. ## Associating Groups with a Policy You can associate a group or multiple groups with a policy from the **Policies** page or from the **Edit Policy** page. ![](../../Resources/Images/associate-groups.png) To associate a group from the Policies page, follow these steps: 1. From **Automate → Policies**, find the name of the policy that you want to associate a groups with. 2. On the right, click **Actions → Associate Groups** for that policy. 3. In the Associate Groups dialog window, select the group or groups that you want to associate with the policy and click **Associate**. To associate a group from the **Edit Policy** page, follow these steps: 1. From **Automate → Policies**, find the name of the policy that you want to associate a group with. 2. Click the name of the policy to open the **Edit Policy** page. 3. On the right side of the Edit Policy page, click **Associate Groups**. 4. In the Associate Groups dialog window, select the group or groups that you want to associate with the policy and click **Associate**. 5. Click **Save Policy**. ## Associating Policies with a Group You can associate a policy or multiple policies with a group from the **Groups** page or from the **Edit Group** page. ![](../../Resources/Images/associate-policies.png) To associate a policy from the Groups page, follow these steps: 1. From the **Manage** → **Groups** page, find the name of the group that you want to associate a policy with. 2. On the right, click **Actions → Associate Policies**. 3. In the Associate Policies dialog window, select the policy or policies that you want to associate with the group and click **OK**. To associate policies from the **Edit Group** page, follow these steps: 1. From the **Manage → Groups** page, click the name of the group to open the **Edit Group** page. 2. On the right side of the Edit Group page, click **Associate Policies.** 3. In the Associate Policies dialog window, select the policy or policies that you want to associate with the group and click **OK**. 4. Click **Update Group**. ## Removing an Associated Policy from a Group You can remove a policy from a group from the **Groups** page or **Edit Group** page. ![](../../Resources/Images/remove-assoc-policy.png) 1. From the **Manage → Groups** page, click the name of the group to open the **Edit Group** page. 2. Remove an associated policy by clicking on the minus sign ( **-** ) next to the policy name on the right. 3. Click **Save Group** to confirm. ## Removing an Associated Group from a Policy You can remove a group from a policy from the **Policy** page or **Edit Policy** page. ![](../../Resources/Images/remove-assoc-group.png) 1. From the **Automate → Policies** page, click the name of the policy to open the**Edit Policy** page. 2. Remove an associated group by clicking on the minus sign ( **-** ) next to the group name on the right. 3. Click **Save Policy** to confirm. ## Scheduling a Policy for Immediate Remediation 1. From **Automate → Policies**, find the name of the policy. 2. On the right, click **Actions → Run Policy**. A dialog box warning appears. 3. Click **Run Policy** or Cancel. **Note**: Manually executing a worklet triggers the remediation script regardless of the compliance status of the device. *Use this with caution*. --- # Searching and Filtering for an Individual Policy or Group _Section: Product Documentation › Policy & Group Interactions • Source: https://docs.automox.com/product/Content/Product%20Documentation/Policy%20%26%20Group%20Interactions/Searching_and_Filtering_for_an_Individual_Policy_or_Group.htm_ From the **Automate → Policies**or **Manage → Groups**page, you can use the search bars on the Policy or Groups pages to find an individual policy or group. ![](../../Resources/Images/search-groups.png) - From the Policies or Groups page, enter the name of the policy or group into the corresponding filter search bar. - If your Group does not have any devices associated with it, it is classified as an **Unused Group**. Turn on this toggle to filter the list to only show the Unused Groups. ## Related Topics - [Managing Groups](../Group Management/Managing_Groups.htm) --- # Agent 2.0.28 Release Notes _Section: Product Documentation › Release Notes › Agent Release Notes • Source: https://docs.automox.com/product/Content/Product%20Documentation/Release%20Notes/Agent%20Release%20Notes/Agent%202.0.28%20Release%20Notes.htm_ End Of Life Beta Release Date: January 7, 2025 GA Release Date: January 21, 2025 ## Improvements - **Agent Connection Status Fixes** - In previous versions, the agent could sometimes appear connected to the platform but show as disconnected in the Console. With Agent 2.0, this issue has been resolved, ensuring accurate status updates. - **Improved Stuck Statuses** - Agent 2.0 enhances connection reliability and introduces agent-managed command history. These improvements reduce the occurrence of stuck commands, ensuring smoother operation and fewer disruptions. - **Duplicate Command Prevention** - The new command history feature in Agent 2.0 prevents the agent from processing a command that it has already received. This is especially important for reducing unexpected or duplicate reboots, which can impact system performance. - **More Scalable and Reliable Back-end Communication** - All agent command communications now use a more scalable and reliable back-end. This update enhances the overall stability of the platform and ensures better handling of commands across a wide range of environments. - **Reconnection Delay Configuration** - Agent 2.0 introduces the ability to adjust the frequency of the agent’s reconnection attempts. This feature has been particularly beneficial in environments with network policy enforcement for devices (for example, Cisco ISE) where increasing reconnection delays has improved overall reliability. - **Persistent Outgoing Response Queuing** - This update improves the delivery of agent command responses by ensuring better reliability in sending responses. Even in heavy traffic or intermittent connectivity environments, responses will be queued and delivered reliably. - **Firewall Rules** - The firewall rules mentioned in Agent 1.45.48 Release Notes are now required. Refer to [Agent Firewall Allowlisting Rules](../../Agents/Agent Requirements/Agent_Firewall_Allowlisting_Rules.htm) for details. --- # Agent 2.0.29 Release Notes _Section: Product Documentation › Release Notes › Agent Release Notes • Source: https://docs.automox.com/product/Content/Product%20Documentation/Release%20Notes/Agent%20Release%20Notes/Agent%202.0.29%20Release%20Notes.htm_ End Of Life Release Date: February 21, 2025 Agent version 2.0.29 is a HotFix that includes the following updates: - We fixed a Windows notifications bug affecting reboot notifications, where clicking "Reboot Now" would not restart the device. - We improved the debugging process of command results. --- # Agent 2.1.44 & Automox Tray Release Notes _Section: Product Documentation › Release Notes › Agent Release Notes • Source: https://docs.automox.com/product/Content/Product%20Documentation/Release%20Notes/Agent%20Release%20Notes/Agent%202.1.44%20Release%20Notes.htm_ End Of Support Release Date: March 31, 2025 ## Summary We’re excited to announce the General Availability (GA) of the Automox Tray for Windows and macOS. This release delivers a significantly improved patching experience for end users and IT administrators by offering clearer restart deadlines, greater flexibility, and reduced support burdens. **Important Security Note** The Automox Tray introduces a new executable: `amagent-ui.exe`, a dedicated UI process responsible for the persistent tray experience. This binary is signed on Windows to ensure a trusted and secure experience for both users and IT administrators. This is separate from `amagent.exe` and not associated with `osqueryi`. Customers can expect to see this new process running as part of the updated agent footprint. ## Notification Experience Update When upgrading to this version of the agent, end users transition from transient notifications to a persistent system tray experience. The tray provides ongoing visibility into restart and installation deadlines, making it easier for users to take timely action. ### No Policy Changes Required — But Behavior Will Differ The Automox Tray works out of the box with your existing policies — no changes are required for it to function. It automatically reads the deferral settings from your current patch and reboot policies and uses them to calculate and display a single restart deadline to end users. With Automox Tray, the option for Automatic Deferrals no longer applies, as the user does not need to actively defer within the established update period. ### However, please be aware of these behavioral differences: - **Custom Messaging Not Supported:** Any custom messaging configured in existing policies (for example, warnings about closing apps) will not appear in tray notifications. While the custom text fields remain visible in the console, the Automox Tray does not currently support displaying custom content. - **Custom Deferral Intervals Are Ignored:** If your policy includes multiple deferral intervals (for example, 2, 6, and 8 hours), the Automox Tray will only use the longest interval (8 hours) to calculate a fixed deadline. Intermediate reminders at earlier deferral points (like 2 or 6 hours) will not be shown. This simplifies the experience for end users, but may differ from how deferrals functioned previously. - **Proactive Notifications Are Based on the Final Deadline:** Users receive a standardized set of tray notifications as the deadline approaches — daily reminders, and then alerts at 3 hours, 1 hour, 5 minutes, and 1 minute before restart is required. ## Automox Tray- New Features - **Persistent System Tray App:** The Automox Tray now appears in the system tray at all times, providing a consistent interface for restart and update notifications. - **Restart Deadline Visibility:** Users can see the date and time by which they must restart their device. - **Restart & Install from Tray:** Users can reboot or install updates directly from the tray with one click. - **Proactive Reminders:** Users receive notifications leading up to restart deadlines, including: - Daily reminders, plus alerts at 3 hours, 1 hour, 5 minutes, and 1 minute before the deadline. - **Works Even in DND Mode:** Notifications appear even when Do Not Disturb is enabled, ensuring visibility of critical actions. ## Agent 2.0 Improvements - Behind-the-scenes Improvements: - **Agent 2.0 Stability & Performance Enhancements:** Includes refinements originally introduced in the Agent 2.0 series, such as improved policy durability, enhanced communication reliability, and better handling of policy retries and large command results. - **Bug Fixes:** Resolves several customer-reported issues related to script syncing, command execution errors, oversized result handling, and missing version metadata. (See full list in the [Bug fixes](#Bug) section below.) - **New Monitoring Capability:** The agent now includes basic tracking for changes to TeamViewer installations - Policy Flow Enhancements - **Policy Result Capacity:** We’ve increased the size limit for policy results. Results too large for communication pipelines will return a result indicating so, enabling policy flow to continue. - **Limited Automatic Policy Retries:** If a policy is interrupted by an agent shutdown, it will automatically retry running up to a set number of attempts. - **Policy Durability:** We’ve improved the reliability persisting policies on the agent. - **Improved Communication:** We’ve updated our communication layer to fix bugs and increase visibility of connection issues. ## Bug fixes - **Devices not updating local DCU scripts:** Some customers experienced an issue where updated versions of ax_platform_health_check were not being reflected in the local repository on devices. This release ensures that local scripts are correctly updated when changes are pushed live. - **Missing metadata in Windows agent executable:** The `amagent.exe` file was missing details in its file properties on Windows (for example, version info). This has now been corrected to improve transparency and trust. - **Help message missing version flag:** The agent’s CLI help output now includes the version command, improving usability for IT admins. - **Command processor**`database not open`**error:** This fix resolves instability in the command history database that caused command failures. The database connection logic has been rewritten to improve reliability. - **Oversized command results blocked execution:** Large command results (>1 MB) previously caused policies to hang. These are now handled gracefully by returning a placeholder response and allowing policy flow to continue. - **Notifications keep spawning with ACK or Timeout response:** This resolves an issue that caused user responses to notifications to be ignored. ## Related Topics - [End-User Notifications](https://docs.automox.com/product/Product_Documentation/Notifications___Restarts/End_User_Notifications.htm) - [Automox Tray FAQ](https://docs.automox.com/product/Product_Documentation/Notifications___Restarts/Automox_Tray_FAQ.htm) --- # Agent 2.1.45 Release Notes _Section: Product Documentation › Release Notes › Agent Release Notes • Source: https://docs.automox.com/product/Content/Product%20Documentation/Release%20Notes/Agent%20Release%20Notes/Agent%202.1.45%20Release%20Notes.htm_ End Of Support Automox Agent version 2.1.45 is a hotfix and includes the following: Bugfix: - Resolved a potential issue in the Automox Tray where if the notification window is zoomed, or the text size enlarged, the button on the bottom of the window could be cut off. This has been resolved in the Automox Agent Version 2.1.45. This agent version is available via manual update. --- # Agent 2.2.26 Release Notes _Section: Product Documentation › Release Notes › Agent Release Notes • Source: https://docs.automox.com/product/Content/Product%20Documentation/Release%20Notes/Agent%20Release%20Notes/Agent%202.2.26%20Release%20Notes.htm_ Automox Agent version 2.2.26 is a hot-fix and includes the following: ### Bug-fixes: - Mitigated a potential issue where the Automox agent could lock when a system transitioned from sleep mode to active, often requiring a manual agent restart to resolve. This condition occurred when one process was initiated prior to another upon system wake from sleep and resulted in dropped messages. This fix assures both processes are running prior to the Automox Agent transitioning to an active state. - Mitigated an issue where the Automox Tray was launched on Windows Core Systems without a GUI resulting in increased CPU utilization. This fix stops the Tray from launching on CLI only based Windows Core Systems. --- # Agent 2.2.24 Release Notes _Section: Product Documentation › Release Notes › Agent Release Notes • Source: https://docs.automox.com/product/Content/Product%20Documentation/Release%20Notes/Agent%20Release%20Notes/Agent%202.2.x%20Release%20Notes.htm_ ## Summary Automox Agent version 2.2.24 contains the following additions and improvements: ### Added - Added the ability for Administrators to create and surface custom notification messages into the Automox Tray for policy execution. - Added an end-user notification within the Automox Tray to inform an end user if the system is off-line. ![](../../../Resources/Images/tray-end-user-notification.png) ### Improvements - Enhanced the notification UI on macOS systems. - Hardened the backend Automox agent-to-server communication flow. ### Bugfixes - Resolved an issue where a newly created policy incorrectly reports compliant before verifying. - Resolved an issue where the Automox Tray was ACKing an end-user action which could result in the associated reboot or patch not completing. - Resolved an issue where a system reboot initiated through the Automox Tray would not clear the notification for action required by the end-user. - Resolved an issue where if a reboot command is initiated early via the agent, failed to send, or failed to complete successfully, the tray notification could be delayed and continue to show that it is processing. - Resolved a potential issue in the Automox Tray where if the notification window is zoomed, or the text size enlarged, the button on the bottom of the window could be cut off. This was resolved in the Automox Agent Version 2.1.45. --- # Agent 2.3.35 Release Notes _Section: Product Documentation › Release Notes › Agent Release Notes • Source: https://docs.automox.com/product/Content/Product%20Documentation/Release%20Notes/Agent%20Release%20Notes/Agent%202.3.35%20Release%20Notes%20Tahoe.htm_ ## Summary Automox Agent version 2.3.35 contains the following additions and improvements: ### Added Advanced support for macOS Tahoe 26 ### Bugfixes Resolved an issue with Agent 2.3.34 where the Automox Tray doesn’t load on Apple Silicon devices without Rosetta installed. --- # Agent 2.3.34 Release Notes _Section: Product Documentation › Release Notes › Agent Release Notes • Source: https://docs.automox.com/product/Content/Product%20Documentation/Release%20Notes/Agent%20Release%20Notes/Agent%202.3.x%20Release%20Notes.htm_ ## Summary Automox Agent version 2.3.34 contains the following additions and improvements: ### Added - Administrators can customize the “Managed by your IT Administrator” text displayed in the Automox Tray notifications. This can be accomplished via an Automox Worklet. ![Automox Tray with text updated by worklet](../../../Resources/Images/tray-updated-branding-text.png) - macOS Worklet: [macOS - Tray Notification - Customize Trusted Message](https://console.automox.com/manage/worklet-catalog/62b51e25-672a-4a73-90e0-df8f7f8bb621) - Windows Worklet: [Windows - Tray Notification - Customize Trusted Message](https://console.automox.com/manage/worklet-catalog/5ed179b0-ade8-4566-afcd-2fcbff78c4f1) - Administrators can disable the Automox Tray application on Microsoft Windows devices via an Automox Worklet. - [Enable Agent Tray](https://console.automox.com/manage/worklet-catalog/8a3b9c2d-4e5f-6a7b-8c9d-1e2f3a4b5c67) - [Disable Agent Tray](https://console.automox.com/manage/worklet-catalog/9b4c5d6e-7f8a-9b0c-1d2e-3f4a5b6c7d8e) - This version of the agent officially supports Windows 11 ARM ### Improvements - The Automox Agent now detects restarts initiated outside of the tray when updating either the operating system or installed software recognized by Automox for Patch Policies thus clearing any associated Tray notifications. Please note that Worklets requiring restarts will still need to be executed through the Automox Tray. - Moved the Automox Tray local logs to a more consistent directory: - macOS Tray log directory: `$HOMEDIR/Library/Logs/com.automox.agent-ui` - Windows Tray log directory: `$HOME/AppData/Local/com.automox.agent-ui/Logs` ### Bugfixes - Mitigated an issue where the Automox Tray sometimes persisted the message “Preparing to install updates” after the end user attempts to install the update. Note that there is a very rare chance that the notification could persist for up to 12 hours if for some reason this install update command stalls. - Added “RunAtLoad” to the Automox Agent .plist on macOS devices mitigating a bug where upon wake from sleep, the device might not reconnect to the Automox server. ### Open Bugs - **Known Issue:** The updated agent installs a new executable, which may be flagged as a false positive by EPP (Endpoint Protection Providers) and potentially quarantined, thus supressing the Automox Tray on impacted devices. - **Workaround:** Please add `AMAGENT-WATCHDOG.EXE` to the allow list within your EPP application. - **Known Issue:** High CPU Usage and Tray Errors After Agent Uninstall on macOS - **Applies to:** Agent version 2.2 and above on macOS - **Status:** Known issue – fix planned for next release - After stopping Agent service with version 2.2 and above on macOS, customers may experience the following behavior: - The `agent-ui` process may remain active, even though the tray icon disappeared. - This process can consume excessive system resources, potentially using up to 100% CPU. - These symptoms occur when the agent is unloaded or removed using `launchctl bootout`. - **Workaround:** - Restarting or reinstalling the agent stops the behavior. - Reinstalling and then properly uninstalling again may also help in clearing the lingering process. - Restarting or force-quitting the Tray will mitigate high CPU usage. --- # Agent 2.4.31 Release Notes _Section: Product Documentation › Release Notes › Agent Release Notes • Source: https://docs.automox.com/product/Content/Product%20Documentation/Release%20Notes/Agent%20Release%20Notes/Agent%202.4%20Release%20Notes.htm_ ## Summary Automox Agent version 2.4.31 contains the following additions and improvements: ### Added - End-user notifications can now be configured to either Honor or Bypass local Do Not Disturb (DnD) settings. Note that Honor DnD will suppress the tray warning notifications, however the policy will still be enforced at the deadline and the end-user will still be notified five minutes and one minute prior to enforcement. ![](../../../Resources/Images/DnD Setting.png) This is not currently supported on macOS Tahoe or Windows Servers. ### Improvements - The Automox Agent now detects restarts initiated outside of the tray for worklets thus clearing any associated Tray notifications. - When multiple policies are scheduled on a device, users now see notifications tied to the deadline of the first policy that will run. This helps them understand the upcoming action and prepare accordingly. ### Bugfixes: - Added the ability to detect recurring DNS errors and reset the HTTP client to mitigate potential agent service issues. - Resolved an issue where after a reboot is initiated outside of the tray, sometimes the tray would still show a reboot is pending. - Resolved an issue where the Automox Tray would not display correctly, or be hidden on end-user systems using multiple monitors. --- # Agent 2.4.33 Release Notes _Section: Product Documentation › Release Notes › Agent Release Notes • Source: https://docs.automox.com/product/Content/Product%20Documentation/Release%20Notes/Agent%20Release%20Notes/Agent%202.4.33%20Release%20Notes.htm_ ## Summary Automox Agent version 2.4.33 contains the following additions and improvements: ## Added This release includes behind-the-scenes updates to prepare for the upcoming launch of our [new Remote Control integration](https://www.globenewswire.com/news-release/2025/10/28/3175530/0/en/New-Partnership-Automox-and-Splashtop-Partner-to-Deliver-Reliable-Secure-Remote-Control-for-IT.html). - No changes to existing Remote Control functionality. - No immediate customer action required. - These updates ensure agent readiness for future feature enablement. ## Bugfixes - Reduced the frequency of occurrence of an issue where Windows devices are experiencing high CPU consumption from `amagent-ui.exe` when `amagent.exe` is stopped. --- # Agent 2.4.42 Release Notes _Section: Product Documentation › Release Notes › Agent Release Notes • Source: https://docs.automox.com/product/Content/Product%20Documentation/Release%20Notes/Agent%20Release%20Notes/Agent%202.4.42%20Release%20Notes.htm_ ## Summary Agent 2.4.42 is a hotfix that addresses bugs related to Windows Modern Standby (S0 Network Disconnected). While the agent was running on a Windows device in low power mode and the OS network stack was powered off, the agent would continue to try to reconnect to the Automox platform. These persistent network calls would cause the OS to crash the agent on certain devices. The agent would at times also have trouble starting back up because it was shut down uncleanly. ## Improvements - This agent can install or update without requiring the installation of VBSCRIPT Windows (optional feature). ## Bugfixes - Improved agent's shutdown and handling of shutdown signaling. - Ensured that Windows named pipe resources are cleaned up on shutdown. - Added back-offs around IPC startup if a failure occurs during initial connection and setup. - Added back-offs around Websocket dialing to ensure that requests are not overly sent. - Fixed a bug with worklet reboots, where every second Reboot command would be ignored regardless of whether it was out of band or not. --- # Agent 2.5.68 Release Notes _Section: Product Documentation › Release Notes › Agent Release Notes • Source: https://docs.automox.com/product/Content/Product%20Documentation/Release%20Notes/Agent%20Release%20Notes/Agent%202.5.68%20Release%20Notes.htm_ Agent 2.5.68 is a hotfix release, and includes the all additions, improvements, and bugfixes included in [Agent 2.5.67 Release Notes](Agent 2.5.x Release Notes.htm), as well as the following bugfix: Bugfixes: - This release addresses a defect related to the `--deregister` behavior in the Agent. Before this fix, Agents told to run the `--deregister` function were inadvertently removing their AccessKey, prohibiting automatic re-registration with the Automox platform. For more information on addressing this issue, please see [How to fix devices that are missing from the Dashboard](https://help.automox.com/hc/en-us/articles/47573681729172-How-to-fix-devices-that-are-missing-from-the-Dashboard). --- # Agent 2.5.70 Release Notes _Section: Product Documentation › Release Notes › Agent Release Notes • Source: https://docs.automox.com/product/Content/Product%20Documentation/Release%20Notes/Agent%20Release%20Notes/Agent%202.5.70%20Release%20Notes.htm_ Agent 2.5.70 is a patch release, and includes the all additions, improvements, and bugfixes included in [Agent 2.5.67](Agent 2.5.x Release Notes.htm) and [Agent 2.5.68](Agent 2.5.68 Release Notes.htm), as well as the following bugfix: **Bugfix:** - This release addresses a defect related to the Custom Icon feature introduced in Agent 2.5.67. Before this fix, Agents in certain Windows environments lacked required permissions to access custom icon files set by the user. With this fix, the custom icon directory has been moved to a more user-accessible directory. --- # Agent 2.5.67 Release Notes _Section: Product Documentation › Release Notes › Agent Release Notes • Source: https://docs.automox.com/product/Content/Product%20Documentation/Release%20Notes/Agent%20Release%20Notes/Agent%202.5.x%20Release%20Notes.htm_ ## Summary Agent 2.5.67 is a major release focusing on Agent Tray feature enhancements and quality of service improvements. It contains the following features, improvements, and fixes: ## Additions - **Custom Branding Icon in the Agent Tray** This release allows Administrators to **customize the Automox Agent Tray icon** that is displayed on an end user’s machine. This icon, shown in the Menu Bar on macOS, in the Windows System Tray, and in the Agent Tray itself allows users to launch the Agent Tray. This customization helps deliver a more intuitive, professional, and tailored experience to end users. **About this Enhancement:** - Custom icon is supported on macOS and Windows systems. - Define and manage the custom icon through new base **Worklets** available in the Automox Console. Access these Worklets through search or the *Tray Management* Category filter. - `[SET] Windows - Tray Notification - Customize Branding Icon` - `[SET] macOS - Tray Notification - Customize Branding Icon` - `[RESET] macOS/Windows - Tray Notification - Reset Branding Icon` - **Icon Requirements:** - File Types Supported: Only `.png` format is supported at this time. - File Size (Pixels) Supported: Files must be `256 x 256 pixels.` - Both a *Light Mode* and *Dark Mode* file are required, with the following naming conventions; `lightModeIcon.png`, `darkModeIcon.png` respectively. - **Note:** On macOS, the tray icon updates automatically with OS theme changes. On Windows, the icon updates after an Agent restart or a policy status change. - **Tray Title and Tooltip Customization (Windows Only)** This release enhances the configurability of the Agent Tray by allowing Administrators to **customize the title string** in the Tray as well as the **tooltip string** that is displayed when hovering over the Agent icon. These enhancements are supported on Windows only at this time. **About this Enhancement:** - Customization of the title and tooltip strings are only supported on Windows systems - Define and manage the custom strings through new base Worklets available in the Automox Console. Access these Worklets through search or the Tray Management Category filter. - `[SET] Windows - Tray Notification - Set Titlebar Title` - `[RESET] Windows - Tray Notification - Reset Titlebar Title` - `[SET] Windows - Tray Notification - Set Tooltip Text` - `[RESET]Windows - Tray Notification - Reset Tooltip Text` - **Text Requirements (Windows Only)** - Custom **title** text must be 20 characters or fewer. - Custom **tooltip** text must be 75 characters or fewer. - Both fields support UTF-8 character encoding. - **Patch Transparency in the Agent Tray** This release adds real-time tracking for OS updates and third-party application patches directly within the Agent Tray. End users can now view specific patch names and version numbers at a glance. For better organization, updates are grouped by type (Operating System or Third-Party) and listed alphabetically. **About this Enhancement:** - Supported on both macOS and Windows systems - No configuration required. These changes are effective immediately with the 2.5 update. ## Improvements - **Enhanced PowerShell script security:** The Automox Agent now automatically installs the required Automox code-signing certificates during startup, allowing PowerShell scripts to run under the AllSigned execution policy and reducing security tool alerts - **Improved action auditing:** Notification events now include the username of the person who took action from the system Tray, making it easier to audit activity on shared or multi-user systems. - **Improved Service Account management (macOS):** Improved how the Agent stores and retrieves the service account password within Keychain in the OS, improving secure token behavior. - **Agent Telemetry:** Major enhancements to Agent’s Application and Debug logging mechanisms. Configurable by Automox, telemetry information will be sampled and streamed to new collectors in the Automox platform, when enabled. Telemetry, as with all communications from the Agent, takes place over Port 443 (https). - **Note:** Depending on your network and firewall configurations, `https://telemetry.automox.com/` may need to be added to your allowlisting rules. See [Agent Firewall Allowlisting Rules](../../Agents/Agent Requirements/Agent_Firewall_Allowlisting_Rules.htm) for more information. ## Bugfixes - **Tray CPU usage fix:** Fixed a bug that could cause elevated CPU usage in the system Tray when the Agent was offline or not running. - **Notifications reliability fix:** Resolved an issue where expiring patch notifications could appear with an unspecified status. - **Tray notification state fix:** Resolved a mismatch where the Tray reported no notifications despite pending notifications being present. - **Incorrect CPU Core count fix:** Resolved an issue where the Agent was reporting an inflated count of CPU Cores for certain Linux VMs, visible in the Console’s Device Details page. --- # Agent Release Process: Beta + General Availability _Section: Product Documentation › Release Notes › Agent Release Notes • Source: https://docs.automox.com/product/Content/Product%20Documentation/Release%20Notes/Agent%20Release%20Notes/Agent%20Release%20Process.htm_ At Automox, we strive for transparency and reliability in our release processes. This document provides a high-level overview of what happens once an agent version is ready for Beta testing and how we manage its rollout through General Availability (GA). ## Beta Release Process Once we have an agent version ready for Beta, we begin a monitoring and feedback phase that typically lasts up to one week. During this period: - We closely monitor performance and behavior of the agent across a sample set of devices that have opted into our beta program. - We actively collect and assess customer feedback to identify any potential issues. - The goal of this period is to ensure stability, performance, and compatibility before a wider roll-out. Once an agent reaches Beta, we aim to keep the feature set stable through GA. While we may address critical issues, non-blocking bugs or enhancements identified during Beta may not be fixed before GA. These will be evaluated and potentially addressed in future agent updates. ### How to Opt In to Beta Customers who wish to participate in Beta testing and gain early access to upcoming agent versions can configure their agent settings accordingly. Instructions on how to manage agent configurations, including opting into Beta releases, can be found in our documentation here: [Managing Agent Configurations](../../Settings/Managing Agent Configurations.htm) ## General Availability (GA) Process Following a successful Beta period, the agent moves into General Availability. This stage involves a controlled roll-out to all customers. Rather than upgrading all devices at once, we use a staggered deployment strategy: - The GA window is a span of time during which devices are upgraded in batches. - The start date of the GA window represents the earliest date the agent may begin rolling out. - Devices are upgraded at various times throughout the GA window, allowing us to monitor performance and ensure a stable deployment across environments. This phased approach helps us maintain the highest quality and reliability for your systems while reducing the potential impact of unforeseen issues. **Note** While this document outlines our standard agent release process, Automox reserves the right to modify this process as needed, including accelerated releases or targeted hot-fix deployments in response to critical issues or escalations. These exceptions are made in the interest of maintaining security, stability, and customer trust. --- # April 2025 Release Notes _Section: Product Documentation › Release Notes › Documentation Release Notes • Source: https://docs.automox.com/product/Content/Product%20Documentation/Release%20Notes/Documentation%20Release%20Notes/April%202025%20Release%20Notes.htm_ ## April 25, 2025 Added: - New supported third-party titles: - Zoom VDI Plugin (Windows, macOS) - Beyond Compare 5 (Windows, macOS) Updated: - Updated the [Analytics](../../Automox Reports/Analytics.htm) documentation to show download types and filters. Added Strategies for Improving Metrics. - Updated [Location of Files Required By Automox](../../Agents/Agent Requirements/Location_of_Files_Required_By_Automox.htm) to show that the Webview2 runtime is required on Windows for Automox Tray functionality (agent versions 2.1.x and later) - Updated [Supported Operating Systems](../../Agents/Agent Requirements/Supported_Operating_Systems.htm) to note that Windows Core and IoT are not currently supported. Bugfixes: - We fixed an issue that prevented devices with duplicate system UUIDs from coexisting. - We fixed an issue where the Automox Splunk Dashboard was displaying Compliant Endpoints inaccurately. - We fixed an issue with Windows profile enumeration that was affecting 1Password installs involving AzureAD. - We fixed an issue where the link to the software to be installed on the Patchable Remediations card was broken. ## April 18, 2025 Added: - Added release notes for [Agent 2.2.x - Coming Soon](../Agent Release Notes/Agent 2.2.x Release Notes.htm). Updated: - Updated [Supported Operating Systems](../../Agents/Agent Requirements/Supported_Operating_Systems.htm) to include Windows Server 2025. - Updated [Agent 2.1.44 & Automox Tray Release Notes](../Agent Release Notes/Agent 2.1.44 Release Notes.htm) with info regarding Automatic Deferrals. - Updated [Third-Party Software Support](../../Third-Party Software/Third_Party_Software_Support.htm) to reflect that we no longer support third-party patching for MS Visual Studio Community Edition 2019, as updates are now behind a paywall for this version. - We updated a majority of the documentation to reflect the change from zones to organizations. - Corrected the Actions button for removing a device (Delete) in [Managing Devices](../../Device Management/Managing_Devices.htm) ## April 11, 2025 Added: - New supported third-party titles: - IntelliJ IDEA Ultimate 2024.3 (Windows, macOS) - IntelliJ IDEA Community Edition 2024.3 (Windows, macOS) Updated: - We improved patching guidance in these documents with clearer, more actionable next steps for patching: - [Automox Console Dashboard](../../Console Overview/Automox Console Dashboard.htm) - [Creating a Patch Policy](../../Policies/Creating_a_Patch_Policy.htm) - [What Are the Recommended Best Practices for Patching in Automox?](../../Patching/What_Are_the_Recommended_Best_Practices_for_Patching_in_Automox_.htm) - Updated commands to remove the agent, and restart the agent on macOS in these docs: - [Deploying Automox via VMware Workspace ONE](../../Agents/Agent Installation/Bulk Agent Deployment/Deploying_Automox_via_VMware_Workspace_ONE.htm) - [Agent Command Line Guide](../../Agents/Agent Installation/Agent_Command_Line_Guide.htm) - [Removing the Automox Agent](../../Agents/Agent Installation/Removing_the_Automox_Agent.htm) - [Troubleshooting the Automox Agent Installation on macOS](../../Troubleshooting/Troubleshooting_the_Automox_Agent_Installation_on_macOS.htm) - [Deploying the Automox Agent in Bulk](../../Agents/Agent Installation/Bulk Agent Deployment/Deploying_the_Automox_Agent_in_Bulk.htm) - [Moving Devices From One Organization to Another](../../Global Access Management/Moving_Devices_From_One_Organization_to_Another.htm) - Updated the [Device Details](../../Device Management/Device_Details.htm) documentation to include the new Device Logs section. This section shows logs from the last 4 scans within the past 30 days and is accessible from the Activity Log Report. The update also describes how to view the logs and explains the types of data shown. Bugfixes: - We fixed an issue for Worklet policies, where the next patch time was not showing on policy creation. - We fixed an issue for Patch policies where the policy wasn't scheduled until after the device scan completed. ## April 4, 2025 Added: - [Agent 2.1.44 & Automox Tray Release Notes](../Agent Release Notes/Agent 2.1.44 Release Notes.htm) - Automox Tray documentation - [End-User Notifications](../../Notifications & Restarts/End_User_Notifications.htm) - [Automox Tray and End-User Notifications FAQ](../../Notifications & Restarts/Automox Tray FAQ.htm) - [Analytics](../../Automox Reports/Analytics.htm) Updated: - **"Zones"** have been renamed to **"Organizations"** across the console. (Documentation updates coming soon!) - The [top navigation bar](../../Console Overview/Automox Console Dashboard.htm) has changed: - It previously included: **Dashboard | Devices | Software | Manage | Reports** - It now shows: **Dashboard | Devices | Automate | Manage | Insights** - We updated and corrected a file path in [Location of Files Required By Automox](../../Agents/Agent Requirements/Location_of_Files_Required_By_Automox.htm) - We updated [What Are the Recommended Best Practices for Patching in Automox?](../../Patching/What_Are_the_Recommended_Best_Practices_for_Patching_in_Automox_.htm) - We updated information around updating email addresses (This will likely change in the near future). Bugfixes: - We fixed a bug where users were unable to change MFA from email to mobile. - We fixed a bug where users were unable to determine device group during missed policy execution. - We fixed a bug where users were logged out when visiting [console.automox.com](https://console.automox.com/). --- # April 2026 Release Notes _Section: Product Documentation › Release Notes › Documentation Release Notes • Source: https://docs.automox.com/product/Content/Product%20Documentation/Release%20Notes/Documentation%20Release%20Notes/April%202026%20Release%20Notes.htm_ ## April 24, 2026 Added: - We added [third-party support](../../Third-Party Software/Third_Party_Software_Support.htm) for **Microsoft Teams New** (macOS). Updated: - Agent 2.5.70 is now in GA! See [Agent 2.5.70 Release Notes](../Agent Release Notes/Agent 2.5.70 Release Notes.htm) for details. - We updated [End-User Notifications](../../Notifications & Restarts/End_User_Notifications.htm) to add a note about silent policies (policies that are configured without end-user notifications and with automatic restarts disabled). - We fixed an issue that was causing the **Test Request** button on the [Automox API Reference](../../../Developer/Automox API Reference.htm) to be non-functional. - We corrected a domain name in [TLS Configuration Requirements for Automox](../../Agents/Agent Requirements/TLS_Configuration_Requirements.htm). ## April 17, 2026 Added: - Agent 2.5.70 is now in Beta! See [Agent 2.5.70 Release Notes](../Agent Release Notes/Agent 2.5.70 Release Notes.htm) for details. Updated: - [Third-Party Title Support](../../Third-Party Software/Third_Party_Software_Support.htm): - Oracle Java JDK 26 (Windows, macOS) - Oracle Java JDK 25 (Windows, macOS) - Yubico Authenticator (Windows, macOS) - Cursor (Windows, macOS) - Notion (Windows, macOS) - RStudio Desktop (Windows, macOS) - ChatGPT Desktop (macOS) - Postman (Windows, macOS) - PDF24 Creator (Windows) - Keeper (Windows, macOS) - Dialpad (Windows, macOS) ## April 10, 2026 Updated: - [Third-Party Title Support](../../Third-Party Software/Third_Party_Software_Support.htm): - Tortoise SVN (Windows) - We updated [Scheduled Windows FAQ](../../Device Management/Scheduled_Windows_FAQ.htm) and [Policy Results Report](../../Automox Reports/Policy_Results_Report.htm) documentation to reflect that we now have a Blocked status to indicate when a policy is scheduled during an active exclusion window. - We removed the worklet code from [Tray Customization Worklets](../../Notifications & Restarts/Tray Customization Worklets.htm) in favor of linking to the Worklet Catalog. This will ensure that the latest worklet code is used. ## April 3, 2026 Updated: - Automox Agent 2.5.68 is now in GA! See [Agent 2.5.68 Release Notes](../Agent Release Notes/Agent 2.5.68 Release Notes.htm) for details. - Third-Party: The product name for Citrix Workspace was updated to "Citrix_Workspace". --- # August 2025 Release Notes _Section: Product Documentation › Release Notes › Documentation Release Notes • Source: https://docs.automox.com/product/Content/Product%20Documentation/Release%20Notes/Documentation%20Release%20Notes/August%202025%20Release%20Notes.htm_ ## August 29, 2025 Updated: - We revamped and updated [Supported Operating Systems](../../Agents/Agent Requirements/Supported_Operating_Systems.htm) for easier navigation and better readability. - We added location information for the Automox Tray log files to [Location of Files Required By Automox](../../Agents/Agent Requirements/Location_of_Files_Required_By_Automox.htm). ## August 22, 2025 Updated: - Updated [Roles and Permissions Management](../../Global Access Management/Roles_and_Permissions.htm) to include feature-specific access requirements (such as for Ask Otto, Script Signing, and Secrets Management). - Updated [Configuring SAML for Microsoft Entra ID (Azure ID)](../../Console Overview/Configuring_SAML_for_Microsoft_Entra_ID__Azure_ID_.htm) to add an important step when downloading the SAML certificate in Microsoft to prevent an error. Bugfixes: - We fixed an issue where devices were showing as disconnected for multiple days, with the agent stuck in a "STOPPING" state. - We fixed an issue where customers were receiving a 401 error when patching third-party applications. ## August 15, 2025 Updated: - [Roles and Permissions Management](../../Global Access Management/Roles_and_Permissions.htm): Added descriptions for roles and permissions. You can now delete a custom user role. - [Using the Required Software Policy](../../Worklets & Required Software/Using_the_Required_Software_Policy.htm): Updated installation instructions to reflect the new file size limit. Added example commands to demonstrate how to run installers manually. - [Device Details](../../Device Management/Device_Details.htm): Added descriptions of the control buttons at the top of the page. - [Analytics](../../Automox Reports/Analytics.htm): We corrected an entry for downloading individual reports. We removed PDF from the list of options. Bugfixes: - We fixed an issue where the "Install Latest Agent on Systems with Old Agents" (now "Upgrade Automox Agents") worklet was not cleaning up installation files and scheduled tasks. ## August 8, 2025 Added: - We added [Tray Customization Worklets](../../Notifications & Restarts/Tray Customization Worklets.htm), which explains how to use worklets to customize the Automox Tray messaging or disable the tray entirely. Updated: - We updated the look & feel of the product documentation website. - We updated [Agent 2.3.34 Release Notes](../Agent Release Notes/Agent 2.3.x Release Notes.htm), which is now GA. - We added a note to the [Profile](../../Settings/Profile.htm) document, regarding Slack channel notifications. - We updated [Automox Tray and End-User Notifications FAQ](../../Notifications & Restarts/Automox Tray FAQ.htm), [End-User Notifications](../../Notifications & Restarts/End_User_Notifications.htm), and [Managing Policies](../../Policies/Managing_Policies.htm) to reflect that, with agent ≥ 2.3.34, the system can detect restarts even when they are not initiated from the Automox Tray. The updates also describe new customization options available through worklets, including modifying tray notification text or disabling the tray. - We updated [Supported Operating Systems](../../Agents/Agent Requirements/Supported_Operating_Systems.htm) to reflect that Rocky Linux 10 is now supported, and Windows 11 ARM is now supported on devices with agent ≥ 2.3.34. - We updated [Creating a Required Software Policy](../../Policies/Creating_a_Required_Software_Policy.htm) and [Creating a Worklet](../../Policies/Creating_a_Worklet.htm) to show that we have increased the file upload size from 1 GB to 10 GB. Bugfixes: - We fixed an issue where the device was set to non-compliant after a worklet was updated. - We fixed an issue where the "Installing Updates" Tray message did not go away after restarting the device. - We added a way to disable Tray installation for headless servers with agent ≥ 2.3.34. - We mitigated an issue where the PrePatch Report API was returning 504 errors and no data. - We fixed an issue where using an apostrophe in a device query, in Device Explorer, was causing an error message to be displayed. ## August 1, 2025 Updated: - We updated [Supported Operating Systems](../../Agents/Agent Requirements/Supported_Operating_Systems.htm) to include CentOS Stream 10. Bugfixes: - We fixed an issue where the macOS Adobe Acrobat Unified Installer was not being updated. --- # December 2025 Release Notes _Section: Product Documentation › Release Notes › Documentation Release Notes • Source: https://docs.automox.com/product/Content/Product%20Documentation/Release%20Notes/Documentation%20Release%20Notes/December%202025%20Release%20Notes.htm_ ## December 12, 2025 Updated: - We updated Device Explorer to include a number of enhancements. See [Device Explorer](../../Device Management/Device_Explorer.htm) and [Roles and Permissions Management](../../Global Access Management/Roles_and_Permissions.htm) for details: - 33 additional attributes are available in the query builder. - Attributes are now broken out by scope: **Device**, **Disks**, **NIC**, **IP Address**, **Software**, **Tags** - 'Smart' functionality for a number of attributes, including type-ahead and pre-populated values. - Search criteria is now unlimited. - CSV Export enhancements (we are now leveraging our unified service). - Scalable architecture & enhanced performance. - New user actions! Easily **apply tags**, **remove tags**, **assign to a group** and **delete a device** directly from the results table. - NEW query permissions for read and manage. - Developer Portal: We have added [new endpoints](https://developer.automox.com/developer-portal/whats-new/#12112025) and operations for Device Explorer. - Agent 2.4.42 is now officially in GA. See [Agent 2.4.42 Release Notes](../Agent Release Notes/Agent 2.4.42 Release Notes.htm) for details. - Debian 13 is now supported for x86-64 and ARM64. See [Supported Operating Systems](../../Agents/Agent Requirements/Supported_Operating_Systems.htm) for details. - We removed references to obsolete agents from [Location of Files Required By Automox](../../Agents/Agent Requirements/Location_of_Files_Required_By_Automox.htm). Bugfixes: - Device Details: We fixed an issue where the "Exclude..." tooltips didn't show any text on hover. - We fixed an issue where reboot commands from worklets were ignored as being out of band. - We fixed an issue where the Outstanding Patch Age shown in Device Explorer didn't match the information shown on the Software page. ## December 5, 2025 Updated: - Updated [Device Details](../../Device Management/Device_Details.htm) to clarify what is included in higher-level plans, refreshed the scan results description, added hover-text tips for inventory details, updated images, added Video and Volume information to the Hardware section. Updated [Managing Devices](../../Device Management/Managing_Devices.htm) to clarify the Needs Attention description. - Automox Agent 2.4.42 is now officially in Beta. --- # February 2025 Release Notes _Section: Product Documentation › Release Notes › Documentation Release Notes • Source: https://docs.automox.com/product/Content/Product%20Documentation/Release%20Notes/Documentation%20Release%20Notes/February%202025%20Release%20Notes.htm_ ## February 28, 2025 Updated: - Added note to the [Security](../../Settings/Security.htm) and [User Accounts](../../Settings/User_Accounts.htm) documentation about resetting 2FA for Global Administrators. - Updated the [Automox Script Signing](../../Script Signing/Automox_Script_Signing.htm) documentation to show the ability to download the certificate for manual installation. - We updated the [Device Details](../../Device Management/Device_Details.htm) documentation to reflect the correct behavior for the Run on This Device button. Added: - New third-party title support: - TeamViewer Host (Windows, macOS) - Camtasia 2024 (Windows, macOS) Bugfixes: - We fixed an issue where the installer for Skype 64-bit 8.136.0.203 was not removing the previous version. - We fixed an issue where the Software page was taking too long to load. ## February 21, 2025 Added: - [Agent 2.0.29 Release Notes](../Agent Release Notes/Agent 2.0.29 Release Notes.htm) Updated: - Updated [Creating Reports](../../Automox Reports/Creating_Reports.htm) documentation to add Group column & filter to the Activity Log. Bugfixes: - We fixed an issue where the [/users](https://developer.automox.com/openapi/axconsole/operation/getUsers/) API was showing information for other zones, for MSPs. - We fixed an issue where a "Failed to update zone" error was shown when adding users to a zone. - We fixed an issue where the Overview report was showing a device count mismatch. - We fixed an issue where the incorrect policy name was showing in the Policy Results Report. ## February 14, 2025 Updated: - The redesigned Worklet Catalog is described in [Using the Worklet Catalog](../../Worklet Catalog/Using_the_Worklet_Catalog.htm) - We recently revised our Agent Firewall Allowlisting Rules. For the latest, see [Agent Firewall Allowlisting Rules](../../Agents/Agent Requirements/Agent_Firewall_Allowlisting_Rules.htm). ## February 7, 2025 Updated: - We now provide CVE severity scoring for all operating systems that we support, see [Supported Operating Systems](../../Agents/Agent Requirements/Supported_Operating_Systems.htm) and [Understanding Automox Severity Data](../../Patching/Understanding_Automox_Severity_Data.htm). - For consistency throughout the console, we updated various actions or status descriptions that now refer to **Needs Restart**. See, for example, the Device status table in [What the Statuses Found in the Automox Console Mean](../../Console Overview/What_the_Statuses_Found_in_the_Automox_Console_Mean.htm). --- # February 2026 Release Notes _Section: Product Documentation › Release Notes › Documentation Release Notes • Source: https://docs.automox.com/product/Content/Product%20Documentation/Release%20Notes/Documentation%20Release%20Notes/February%202026%20Release%20Notes.htm_ ## February 27, 2026 Updated: - Our Developer and API Documentation have a new home! See [Developer Documentation](../../../Developer/Developer LP.htm) for all of our developer content and API reference guide. - Third-Party Support - Name change: **Microsoft Visual C++ Redistributable (2015-2022)** is now known as **Microsoft Visual C++ Redistributable v14 (2015-2026)**. - We've updated our [Platform Firewall Allowlisting Rules](../../Agents/Agent Requirements/Agent_Firewall_Allowlisting_Rules.htm) to account for service migrations. - [Agent Versioning and Support](../../Maintenance Policy and Agent Update Policy/Agent_Versioning_and_Support.htm) has been updated for better clarity. Bugfixes: - We fixed an issue where policies were not showing as Pending until they were updated. - We fixed an issue where reboots were not executing on policies when they should have. - We fixed an issue where policies could run early if another policy's notification was actioned. - We fixed an issue where deleted devices would still appear in Device Explorer, but not on the Devices page. - We fixed a formatting error in the warning on Ask Otto. ## February 20, 2026 Updated: - Automox Agent 2.5.64 is now in Beta! See [Agent 2.5.64 Release Notes](../Agent Release Notes/Agent 2.5.x Release Notes.htm) for details. - We updated the disk space requirements for the Automox Agent. See [Automox Agent Requirements](../../Agents/Agent Requirements/Automox Agent Requirements.htm) for details. - We updated the [Profile](../../Settings/Profile.htm) documentation to reflect the updated Automox Slack integration. ## February 6, 2026 Updated: - We updated [Third-Party Software Support](../../Third-Party Software/Third_Party_Software_Support.htm) to reflect the following changes: - Poly Lens has been renamed to Poly Studio (Lens). - Autodesk Desktop Connector has been renamed to Autodesk Desktop Connector 16. - [Platform Firewall Allowlisting Rules](../../Agents/Agent Requirements/Agent_Firewall_Allowlisting_Rules.htm) was updated with the following changes: - We renamed the article to more accurately reflect that the requirements are for the platform as a whole, not just the Automox Agent. - We added [app.launchdarkly.com](https://app.launchdarkly.com/) back to the allowlisting requirements, as platform functionality is impacted if this domain is blocked. --- # January 2025 Release Notes _Section: Product Documentation › Release Notes › Documentation Release Notes • Source: https://docs.automox.com/product/Content/Product%20Documentation/Release%20Notes/Documentation%20Release%20Notes/January%202025%20Release%20Notes.htm_ ## January 31, 2025 Updated: - We improved the performance of our `/servers` API. See [Automox Servers API is now Fast By Default](https://developer.automox.com/developer-portal/servers-fast-by-default/) for details. ## January 24, 2025 Updated: - We updated the Overview Report documentation. See [Creating Reports](../../Automox Reports/Creating_Reports.htm) for details. - We released Automox Agent 2.0.28 GA. See [Agent 2.0.28 Release Notes](../Agent Release Notes/Agent 2.0.28 Release Notes.htm) for details. - We updated [Location of Files Required By Automox](../../Agents/Agent Requirements/Location_of_Files_Required_By_Automox.htm) to include `osqueryi` Added: - New Third-Party Titles: - **RubyMine_2024.1** (Windows, macOS) - **Gitkraken** (macOS) ## January 17, 2025 Updated: - We clarified the [Create API Key](https://developer.automox.com/openapi/axconsole/operation/createUserApiKey/) API permission requirements. See [Managing Keys](../../Settings/Managing_Keys.htm) for more details. - We added Rocky Linux to the list of supported OSes for severity scoring. See [Understanding Automox Severity Data](../../Patching/Understanding_Automox_Severity_Data.htm) for more details. - We updated our [Maintenance Policy](../../Maintenance Policy and Agent Update Policy/Maintenance_Policy.htm) ## January 10, 2025 Updated: - We now show the full list of supported Linux distros in our supported OS doc! See [Supported Operating Systems](../../Agents/Agent Requirements/Supported_Operating_Systems.htm) - We updated [Configuring SAML for Microsoft Entra ID (Azure ID)](../../Console Overview/Configuring_SAML_for_Microsoft_Entra_ID__Azure_ID_.htm) to make the references to finding info in Automox more clear. - We removed an incorrect step from [Deploy the Latest Automox Agent using a PowerShell Script via Windows GPO Policy](../../Agents/Agent Installation/Bulk Agent Deployment/Deploy_the_Latest_Automox_Agent_using_a_Powershell_Script_via_Windows_GPO_Policy.htm) --- # January 2026 Release Notes _Section: Product Documentation › Release Notes › Documentation Release Notes • Source: https://docs.automox.com/product/Content/Product%20Documentation/Release%20Notes/Documentation%20Release%20Notes/January%202026%20Release%20Notes.htm_ ## January 30, 2026 Added: - Automox Agent 2.5 is Coming Soon! See [Agent 2.5.x Release Notes](../Agent Release Notes/Agent 2.5.x Release Notes.htm) for details. Updated: - We updated [Agent Firewall Allowlisting Rules](../../Agents/Agent Requirements/Agent_Firewall_Allowlisting_Rules.htm) to add [telemetry.automox.com](https://telemetry.automox.com/) to the URLs list, in preparation for Agent 2.5. - We updated [Third-Party Software Support](../../Third-Party Software/Third_Party_Software_Support.htm) to reflect that we only support Autodesk Desktop Connector 16. Bugfixes: - We fixed an issue where the Crowdstrike Agent Deployer script was failing on TLS negotiation. ## January 23, 2026 Updated: - New Third-Party title support: - Claude Desktop (Windows, macOS) - [Agent Firewall Allowlisting Rules](../../Agents/Agent Requirements/Agent_Firewall_Allowlisting_Rules.htm) have been updated to include [command-storage.prod.automox.com](https://command-storage.prod.automox.com/). ## January 16, 2026 Added: - Developer Portal: We added [new APIs](https://developer.automox.com/developer-portal/whats-new/#01142026) for Automox Resolve - Powered by Splashtop. - We added new documentation for the [TLS Configuration Requirements for Automox](../../Agents/Agent Requirements/TLS_Configuration_Requirements.htm) Updated: - Third-Party Support: - We no longer support **CCleaner for Windows**, as silent installation is no longer supported with current versions. Bugfixes: - We fixed an issue where bulk tags were not working fully as expected. - We fixed an issue where older versions of Google Chrome were showing as available on macOS devices. - We fixed an issue where the *Reset Windows Update Catalog* worklet was failing on Windows Server 2016 devices. - We fixed an issue where several EU customers were unable to log into the Automox console. - We fixed an issue preventing patching on Amazon Linux 2 devices. ## January 9, 2026 Added: - In preparation for our launch of Automox Resolve, powered by Splashtop on January 14, we have published new documentation: - [Automox Remote Control with Splashtop – Full User Guide](../../Remote Control Module/Splashtop User Guide.htm) - [Quick Start Guide - Using Remote Control with Splashtop](../../Remote Control Module/Splashtop QSG.htm) - [Remote Control with Splashtop – FAQ and Troubleshooting](../../Remote Control Module/Remote Control (Splashtop) – FAQ, Known Issues, and Troubleshooting.htm) - [macOS MDM Configurations for Splashtop](../../Remote Control Module/macOS MDM Splashtop.htm) - New Third-Party titles: - Splashtop RMM - Snagit 2025 - New Supported OS - We have added Fedora 43 to our list of [Supported Operating Systems](../../Agents/Agent Requirements/Supported_Operating_Systems.htm). Updates: - We have updated [Agent Firewall Allowlisting Rules](../../Agents/Agent Requirements/Agent_Firewall_Allowlisting_Rules.htm) to include recommendations for Splashtop. Bugfixes: - We fixed an issue where manual policy runs were failing with a 413 error due to being unable to retrieve the scheduled window. - We fixed an issue on the Device page that was causing 400 errors when searching too many devices. - We fixed an issue where the Policy Results Report was showing that a patch was Not Applicable instead of Not Included. - We fixed an issue where updating Google Chrome on Windows would fail with a 403 error. - We fixed an issue where an invalid PowerToys installer was causing updates for that package to fail silently. - We fixed an issue affecting display of last logged-in usernames in the console for Linux devices. --- # July 2025 Release Notes _Section: Product Documentation › Release Notes › Documentation Release Notes • Source: https://docs.automox.com/product/Content/Product%20Documentation/Release%20Notes/Documentation%20Release%20Notes/July%202025%20Release%20Notes.htm_ ## July 25, 2025 Added: - New supported third-party titles: - **Zoom VDI Client** (Windows) - **Adobe Acrobat SCA DC** (macOS) Updated: - We updated [Agent 2.3 Release Notes](../Agent Release Notes/Agent 2.3.x Release Notes.htm), which has started rolling out for Beta release. - We updated [Agent Firewall Allowlisting Rules](../../Agents/Agent Requirements/Agent_Firewall_Allowlisting_Rules.htm) to add [third-party-cdn.automox.com](https://third-party-cdn.automox.com/) to the Non-Wildcard URL list. - We added a note to [Device Details](../../Device Management/Device_Details.htm) explaining that there may be discrepancies in data between the Device Details page and the devices table, as we are using two separate data sources. - We updated [Supported Operating Systems](../../Agents/Agent Requirements/Supported_Operating_Systems.htm) to remove Windows Server 2012 R2 from the list of EoL Operating Systems, and re-added it to the supported Windows Server list. Bugfixes: - We fixed an issue that was causing Patch All policies on SuSE 15 to fail, due to an invalid application row being returned by GetSoftware. - We fixed an issue causing excessive load time on the Devices page. - We fixed an issue that caused secrets to not load on the Secrets & Keys page until the page was hard-refreshed after switching to it. - We fixed an issue that allowed globally ignored packages to be installed on devices. ## July 18, 2025 Added: - We added Windows Server Core 2025 to [Supported Operating Systems](../../Agents/Agent Requirements/Supported_Operating_Systems.htm). - Developer Portal: We added the new Device Inventory endpoints to the Automox Console API: - [GET /device-inventory](https://developer.automox.com/openapi/axconsole/operation/getDeviceInventory/) - [GET /device-inventory/categories](https://developer.automox.com/openapi/axconsole/operation/getDeviceInventory/getDeviceInventoryCategories) **Note:** These APIs are rate limited to 30 requests per minute, per organization. Updates: - The [Device Details](../../Device Management/Device_Details.htm) page now offers an organized inventory of data collected for individual devices. This redesigned experience introduces a new tabbed layout—Summary, Health, Hardware, Network, Security, Services, System, and Users—making it easier to find and act on device-specific information. Notable improvements include: - **New tabbed structure**: Quickly navigate detailed device information by category. - **Expanded data points**: Access a broader set of insights across all tabs. - **Device Snapshot**: View key system and network identifiers at a glance. - We updated the [Agent 2.3.26 Release Notes](../Agent Release Notes/Agent 2.3.x Release Notes.htm) in preparation for the Beta release. - Updated [Automox Console Dashboard](../../Console Overview/Automox Console Dashboard.htm) to note that dashboard data can be delayed by up to 15 minutes. Bugfixes: - We fixed an issue where the Automox Tray pop-up was off-screen or hidden. - We fixed an inconsistency wherein excluded patches were showing up when filtering the Pre-Patch Report by a group. - We fixed an issue where a single restart command was causing the device to restart multiple times. ## July 11, 2025 Added: - New [Analytics Board and Report Scheduling](../../Automox Reports/Analytics Board and Report Scheduling.htm) document. Updated: - A new board is available in Analytics: [Organizational Risk & Patch Trend](../../Automox Reports/Analytics.htm#Organiza4). In addition, 2 new filters are available for use for the Patch Impact & Performance board: - Package Source Type - Package Category - Updated [Agent 2.3 Release Notes](../Agent Release Notes/Agent 2.3.x Release Notes.htm) to reflect that the target release windows have changed and to reflect a bug that was found. - Updated the [Agent Firewall Allowlisting Rules](../../Agents/Agent Requirements/Agent_Firewall_Allowlisting_Rules.htm) to reflect the addition of more static IPs, and revised formatting to allow for expanding / collapsing tables. - Removed outdated notes about the switch from zones → organizations. Bugfixes: - We fixed an issue where the NeedsReboot flag was not cleared by a restart on Windows 11 devices. ## July 4, 2025 Added: - We added [Agent 2.3 Release Notes](../Agent Release Notes/Agent 2.3.x Release Notes.htm) for the upcoming agent release. Updated: - [Analytics](../../Automox Reports/Analytics.htm) has been updated to cover the new boards (Health and Device Status, Organization Insights, and Policy Execution) that have been added in the console. - [Otto AI FAQs](../../Otto AI/Otto_AI_FAQs.htm): We updated the description for who has access to Ask Otto. Bugfixes: - We fixed an issue where the OS version for AlmaLinux wasn't updating based on the GetOS value. - We fixed an issue where we were displaying the incorrect OS version for macOS 15.4.0. --- # June 2025 Release Notes _Section: Product Documentation › Release Notes › Documentation Release Notes • Source: https://docs.automox.com/product/Content/Product%20Documentation/Release%20Notes/Documentation%20Release%20Notes/June%202025%20Release%20Notes.htm_ ## June 27, 2025 Added: - New supported third-party titles: - **CLion 2024.1** (macOS, Windows) - **Dropbox** (macOS, ARM64) - Added RHEL 10 to [Supported Operating Systems](../../Agents/Agent Requirements/Supported_Operating_Systems.htm). - Added End of Life (EOL) section to [Supported Operating Systems](../../Agents/Agent Requirements/Supported_Operating_Systems.htm). - Added EOL date of October 15, 2025 for Automox Agent 1.x, in [Agent Versioning and Support](../../Maintenance Policy and Agent Update Policy/Agent_Versioning_and_Support.htm). Updated: - Updated [Agent Firewall Allowlisting Rules](../../Agents/Agent Requirements/Agent_Firewall_Allowlisting_Rules.htm) to include information about static IPs. - Removed set-connect-delay from agent commands, as this is no longer supported. - Corrected command to disable service account in [Install and Configure Automox Agent for Apple Silicon Devices](../../Agents/Agent Installation/Install_and_Configure_Automox_Agent_for_Apple_Silicon_Devices.htm). - Removed reference to agent 1.x requirements, as agent 1.x has now reached End of Support (EOS). ## June 20, 2025 Updated: - Developer Portal: We removed the non-functioning `GET /data-extracts/{id}/download` endpoint. The responses for `[GET /data-extracts](https://developer.automox.com/openapi/axconsole/operation/getDataExtracts/)` and `[GET /data-extracts/{id}](https://developer.automox.com/openapi/axconsole/operation/getDataExtractByID/)` now include the `download_url`, which can be used to download the CSV file for the data extract. - Developer Portal: Removed non-functional `/worklet-catalog` and `/worklet-catalog/{id}` endpoints, and replaced them with the new `[/wis/search](https://developer.automox.com/openapi/axconsole/operation/searchWorklets/)` and `[/wis/search/{id}](https://developer.automox.com/openapi/axconsole/operation/searchWorkletsById/)` endpoints. Bugfixes: - We fixed an issue where users were unable to export the complete software list. - We fixed an issue that was causing high CPU usage on devices running agent 2.1.44. - We mitigated an issue that was causing high CPU usage on devices using Automox Tray, where webview2 was not installed or not correctly installed. ## June 13, 2025 Added: - Developer Portal: Added [PUT](https://developer.automox.com/openapi/axconsole/operation/FullUpdateUserById/) and [PATCH](https://developer.automox.com/openapi/axconsole/operation/patchUserById/) operations to `api/users/{userId}` Updated: - Third-Party Software Support: Updated branding of Splashtop Business Access to Splashtop Remote Access. - Added a note to [Roles and Permissions Management](../../Global Access Management/Roles_and_Permissions.htm) and [Managing Keys](../../Settings/Managing_Keys.htm) to explain how permissions for API keys work. ## June 6, 2025 Added: - We added [Agent 2.2.26 Release Notes](../Agent Release Notes/Agent 2.2.26 Release Notes.htm) to support the agent hot-fix which is coming soon. - New supported third-party titles: - IntelliJ IDEA Community Edition 2024.2 Updated: - We updated [Agent Versioning and Support](../../Maintenance Policy and Agent Update Policy/Agent_Versioning_and_Support.htm) to reflect that agent 1.x will reach End of Support on June 15, 2025. See [Automox Agent 1.x End of Support - June 15, 2025](https://help.automox.com/hc/en-us/articles/37950277862548-Automox-Agent-1-x-End-of-Support-June-15-2025) for more information. - In [Analytics](../../Automox Reports/Analytics.htm), you can now change filter options and save your customized board views for future use. Bugfixes: - We fixed an issue where the agent upgrade script was attempting to use IPv6. - We fixed an issue where the agent log was being flooded with decryption messages. --- # June 2026 Release Notes _Section: Product Documentation › Release Notes › Documentation Release Notes • Source: https://docs.automox.com/product/Content/Product%20Documentation/Release%20Notes/Documentation%20Release%20Notes/June%202026%20Release%20Notes.htm_ ## June 5, 2026 Updated: - Developer Documentation: The old changelog has been deprecated and archived. Updates for developer documentation are added to the documentation release notes. - We updated [Supported Operating Systems](../../Agents/Agent Requirements/Supported_Operating_Systems.htm) to reflect OSes that are now EOL and no longer supported. - We fixed a bug that prevented [Agent 2.5.70 Release Notes](../Agent Release Notes/Agent 2.5.70 Release Notes.htm) from showing in the table of contents. - We generated `llms.txt` files for the documentation site, and did a round of editorial updates to bring the documentation into closer alignment with the Google Developers Style Guide. --- # March 2025 Release Notes _Section: Product Documentation › Release Notes › Documentation Release Notes • Source: https://docs.automox.com/product/Content/Product%20Documentation/Release%20Notes/Documentation%20Release%20Notes/March%202025%20Release%20Notes.htm_ ## March 21, 2025 Bugfixes: - We fixed an issue where the Next Patch Window date kept getting pushed back. ## March 14, 2025 Updated: - Fixed some data issues in our third-party software documentation. - Updated our [Automox Agent Update Policy](../../Maintenance Policy and Agent Update Policy/Automox_Agent_Update_Policy.htm). Bugfixes: - We fixed an issue where SUSE devices were not showing available packages. - We fixed an issue where the Install Adobe Acrobat Reader DC worklet for macOS was failing with an invalid path error. - We fixed an issue where policy runs were not showing in the Policy Results report. ## March 7, 2025 Added: - New third-party title support: - Commander One (macOS) - Microsoft Azure Storage Explorer (Windows, macOS) Updated: - Updated the default directory for script execution in the [Agent Command Line Guide](../../Agents/Agent Installation/Agent_Command_Line_Guide.htm). - Updated the information about the Automox Supported filter, and noted that the data is updated every 15 minutes for [Filtering and Searching on the Software Page](../../Software/Filtering_and_Searching_on_the_Software_Page.htm). Bugfixes: - We fixed a permissions issue preventing users from downloading a CSV from the Devices page. - We fixed an issue causing agent disconnection. - We fixed an issue where 1Password wasn't updating to the current version. - We fixed an issue with Agent 2.0 that was showing `command id was found in history and was prevented from being executed` and preventing patches from being installed. - We fixed an issue where removing a package targeting filter was clearing the value of the next filter. - We fixed an issue where a user was unable to invite other users to an account. - We fixed an issue where the agent received multiple unneeded remediations on agent 2.0.28+. --- # March 2026 Release Notes _Section: Product Documentation › Release Notes › Documentation Release Notes • Source: https://docs.automox.com/product/Content/Product%20Documentation/Release%20Notes/Documentation%20Release%20Notes/March%202026%20Release%20Notes.htm_ ## March 27, 2026 Added: - Automox Agent 2.5.68 is now in Beta. See [Agent 2.5.68 Release Notes](../Agent Release Notes/Agent 2.5.68 Release Notes.htm) for details. - New supported [Third-Party](../../Third-Party Software/Third_Party_Software_Support.htm) titles: - Altova XMLSpy Ent 2024 (**Windows**) - Altova XMLSpy Ent 2024_R2 (**Windows**) - Altova XMLSpy Ent 2025 (**Windows**) - Altova XMLSpy Ent 2025_R2 (**Windows**) - Altova XMLSpy Ent 2026 (**Windows**) - Altova XMLSpy Pro 2024 (**Windows**) - Altova XMLSpy Pro 2024_R2 (**Windows**) - Altova XMLSpy Pro 2025 (**Windows**) - Altova XMLSpy Pro 2025_R2 (**Windows**) - Altova XMLSpy Pro 2026 (**Windows**) - Altova MissionKit Ent 2024 (**Windows**) - Altova MissionKit Ent 2024_R2 (**Windows**) - Altova MissionKit Ent 2025 (**Windows**) - Altova MissionKit Ent 2025_R2 (**Windows**) - Altova MissionKit Ent 2026 (**Windows**) - Altova MissionKit Pro 2024 (**Windows**) - Altova MissionKit Pro 2024_R2 (**Windows**) - Altova MissionKit Pro 2025 (**Windows**) - Altova MissionKit Pro 2025_R2 (**Windows**) - Altova MissionKit Pro 2026 (**Windows**) - Foxit PDF Editor 13 (**Windows**) - Foxit PDF Editor 14 (**Windows**) - Foxit PDF Editor 2025 (**Windows**) - Snagit 2026 (**Windows, Mac**) - ActivePresenter 10 (**Windows, Mac**) - Amazon Corretto 21 (**Windows, Mac**) - Amazon Corretto 25 (**Windows, Mac**) - Microsoft OpenJDK 25 (**Windows, Mac**) - Zulu JDK 25 (**Windows, Mac**) - CLion 2025.1 (**Windows, Mac**) - CLion 2025.2 (**Windows, Mac**) - CLion 2025.3 (**Windows, Mac**) - DataGrip 2025.1 (**Windows, Mac**) - DataGrip 2025.2 (**Windows, Mac**) - DataGrip 2025.3 (**Windows, Mac**) - IntelliJ IDEA Community Edition 2025.1 (**Windows, Mac**) - IntelliJ IDEA Community Edition 2025.2 (**Windows, Mac**) - IntelliJ IDEA Ultimate 2025.1 (**Windows, Mac**) - IntelliJ IDEA Ultimate 2025.2 (**Windows, Mac**) - IntelliJ IDEA Ultimate 2025.3 (**Windows, Mac**) - PyCharm Community Edition 2025.1 (**Windows, Mac**) - PyCharm Community Edition 2025.2 (**Windows, Mac**) - PyCharm Professional 2025.1 (**Windows, Mac**) - PyCharm Professional 2025.2 (**Windows, Mac**) - PyCharm Professional 2025.3 (**Windows, Mac**) - RubyMine 2025.1 (**Windows, Mac**) - RubyMine 2025.2 (**Windows, Mac**) - RubyMine 2025.3 (**Windows, Mac**) - Signal Desktop (**Windows, Mac**) Updated: - We updated [Tray Customization Worklets](../../Notifications & Restarts/Tray Customization Worklets.htm) to add the new worklets for customizing the tray branding icon, tooltip text, and tray title text. - We increased the Patch Tuesday offset to 26 days, from 14. See [Setting a Patching Schedule](../../Policies/Setting_a_Patching_Schedule.htm) for details. Our [API documentation](../../../Developer/Automox API Reference.htm#tag/policies) was also updated to reflect this update. - We updated [Install and Configure Automox Agent for Apple Silicon Devices](../../Agents/Agent Installation/Install_and_Configure_Automox_Agent_for_Apple_Silicon_Devices.htm) to improve command line clarity. - We updated [Billing](../../Settings/Billing.htm) to show that we now show device usage for the past 2 years. - Developer docs: We updated [Policy and Device Filters, and Policy Scheduling](../../../Developer/policy_filters_schedule.htm) to correct a few dead links. ## March 20, 2026 Updated: - Automox Agent 2.5.67 is now in GA! See [Agent 2.5.67 Release Notes](../Agent Release Notes/Agent 2.5.x Release Notes.htm) for details. - Fixed typo in [Agent Command Line Guide](../../Agents/Agent Installation/Agent_Command_Line_Guide.htm) . - Updated the Scheduled Windows APIs to add: - [POST /policy-windows/org/{org_UUID}/search](https://docs.automox.com/product/Developer/Automox_API_Reference.htm#tag/scheduled-windows/POST/policy-windows/org/{org_UUID}/search) - [POST /policy-windows/org/{org_UUID}/groups/exclusion-status](https://docs.automox.com/product/Developer/Automox_API_Reference.htm#tag/scheduled-windows/POST/policy-windows/org/{org_UUID}/groups/exclusion-status) Bugfixes: - We fixed an issue where the Remove User button was not functioning properly. - We fixed an issue where updating a policy could cause the policy execution to ignore device targeting. - We fixed an issue where the Device Cleanup worklet for macOS was not working. ## March 13, 2026 Added: - We added documentation for the new [Policy Catalog](../../Policies/Policy Catalog.htm) . Updated: - We refreshed and updated our Remote Control documentation. See the following docs for updates: - [Quick Start Guide - Using Remote Control with Splashtop](../../Remote Control Module/Splashtop QSG.htm) - [Automox Remote Control with Splashtop – Full User Guide](../../Remote Control Module/Splashtop User Guide.htm) - [Remote Control with Splashtop – FAQ and Troubleshooting](../../Remote Control Module/Remote Control (Splashtop) – FAQ, Known Issues, and Troubleshooting.htm) - [macOS MDM Configurations for Splashtop](../../Remote Control Module/macOS MDM Splashtop.htm) - New Third-Party title support: - PDF Reader Pro (Windows, macOS) - We updated [Understanding Automox Severity Data](../../Patching/Understanding_Automox_Severity_Data.htm) to reflect that we now show severity data for all Automox-supported third-party software packages. - [Supported Operating Systems](../../Agents/Agent Requirements/Supported_Operating_Systems.htm) has been updated to reflect that we now support AlmaLinux OS 10 (x86-64, ARM64). - [Platform Firewall Allowlisting Rules](../../Agents/Agent Requirements/Agent_Firewall_Allowlisting_Rules.htm) has been updated to reflect that SSL Inspection must be bypassed for all agent traffic. - We updated [Device Details](../../Device Management/Device_Details.htm) and [Managing Devices](../../Device Management/Managing_Devices.htm) to show the new device statuses "Pending User Install" and "Pending User Restart", and explain more about their usage. - We also added a section to [Device Details](../../Device Management/Device_Details.htm) for Scheduled Windows. - Last, but not least, we updated [End-User Notifications](../../Notifications & Restarts/End_User_Notifications.htm) to reflect the usage of deadlines, as opposed to deferrals for agents >2.1.x. ## March 6, 2026 Updated: - We updated [Deploying the Automox Agent in Bulk for macOS with Jamf Pro](../../Agents/Agent Installation/Bulk Agent Deployment/Deploying_the_Automox_Agent_in_Bulk_for_macOS_with_Jamf_Pro.htm) to include a note about Apple Silicon device requirements. - We updated the policy template links in [What Are the Recommended Best Practices for Patching in Automox?](../../Patching/What_Are_the_Recommended_Best_Practices_for_Patching_in_Automox_.htm) . Bugfixes: - We fixed an issue where the incorrect download URL was being given in the response when using the Data Extracts API. - We fixed an issue where Device Explorer was not showing current device results. - We fixed an issue where Device Explorer was returning incorrect results when querying which devices do not have a specific version of an application installed. - We fixed an issue where the Remote Control Consent settings tooltip did not show the number of seconds for a response. --- # May 2025 Release Notes _Section: Product Documentation › Release Notes › Documentation Release Notes • Source: https://docs.automox.com/product/Content/Product%20Documentation/Release%20Notes/Documentation%20Release%20Notes/May%202025%20Release%20Notes.htm_ ## May 30, 2025 Updated: - We updated [Agent Firewall Allowlisting Rules](../../Agents/Agent Requirements/Agent_Firewall_Allowlisting_Rules.htm) to add [command-storage-cdn.prod.automox.com](https://command-storage-cdn.prod.automox.com/) to the allowlist. - We added more clarity around the timing of end-user notifications to [End-User Notifications](../../Notifications & Restarts/End_User_Notifications.htm). Bugfixes: - We fixed an issue where policies were not consistently triggering a restart sequence upon successful completion of the policy. - We fixed an issue where installed software was not being displayed for some devices. - We fixed an issue where Search All Logs on the Activity Log page was returning zero results. ## May 23, 2025 Added: - Added more information about the release process for Automox Agent. See [Agent Release Process: Beta + General Availability](../Agent Release Notes/Agent Release Process.htm) for details. Updates: - Updated [Setting a Patching Schedule](../../Policies/Setting_a_Patching_Schedule.htm) - You can select a custom schedule, which now allows you to select the occurrence of days instead of weeks. In addition, you can select a schedule specifically for Patch Tuesday, which can be configured with a delay. - Developer Portal: Updated the configuration objects for [Create a new policy](https://developer.automox.com/openapi/axconsole/operation/createPolicy/) and [Update a policy](https://developer.automox.com/openapi/axconsole/operation/updatePolicy/) to allow for setting `is_patch_tuesday` and `patch_tuesday_offset` when creating or updating policies using the API. Bugfixes: - We added `RunAtLoad` to the Agent plist file on macOS, to fix an issue where macOS devices were not reconnecting to Automox after waking from sleep. - We updated links to [cve.mitre.org](https://cve.mitre.org/) to reflect the domain change to [cve.org](https://cve.org/). ## May 16, 2025 Added: - We added Fedora 41 and 42 to [Supported Operating Systems](../../Agents/Agent Requirements/Supported_Operating_Systems.htm). Updated: - We updated the [Analytics](../../Automox Reports/Analytics.htm) documentation to include the new Patch Impact and Performance board. - We updated the [Secrets Management](../../Settings/Secrets_Management.htm) documentation and updated images. - We updated the [Agent 2.2.24 Release Notes](../Agent Release Notes/Agent 2.2.x Release Notes.htm) for clarity, and included a screenshot of the end-user notification received when the system is offline. - We consolidated the documentation regarding rolling back Windows patches into [How to Roll Back an Installed Patch on Devices](../../Miscellaneous/How_to_Roll_Back_an_Installed_Patch_on_Devices.htm), and removed a redundant article. - Third-Party Software Support - We have removed Tableau Reader from Third-Party Patching Support, as updates now require a website account to download. Bugfixes: - We fixed an issue wherein toggling *Automatic Agent Upgrades* in the console would apply the change to the next selected organization. - We fixed an issue where clicking on a saved query in Device Query would cause the error "*An unexpected error occurred. Please try again. If the issue persists, contact support.*" to be displayed. - We fixed an issue with third-party software support, where MS ODBC Driver 17 for SQL Server and MS ODBC Driver 18 for SQL Server were a version behind. ## May 9, 2025 Added: - Added CentOS Stream 9 to [Supported Operating Systems](../../Agents/Agent Requirements/Supported_Operating_Systems.htm). Updated: - Updated [Agent 2.2.24 Release Notes](../Agent Release Notes/Agent 2.2.x Release Notes.htm) to reflect that this version is now in General Availability (GA). - Updated [Install and Configure Automox Agent for Apple Silicon Devices](../../Agents/Agent Installation/Install_and_Configure_Automox_Agent_for_Apple_Silicon_Devices.htm) to reflect that we now use the native macOS prompt to configure the secure token, enhancing security. - Updated [Agent Firewall Allowlisting Rules](../../Agents/Agent Requirements/Agent_Firewall_Allowlisting_Rules.htm) to include recommendations for Analytics. - Updated [End-User Notifications](../../Notifications & Restarts/End_User_Notifications.htm) to reflect that you can now use custom messages in tray notifications. - Third-Party Software Support: We fixed detection and patching for GoTo Opener and GoTo Connect, and removed references to GoToMeeting, which is not currently supported. ## May 2, 2025 Added: - Custom Roles is being rolled out to General Availability. See [Roles and Permissions Management](../../Global Access Management/Roles_and_Permissions.htm) to learn more. - Agent Configurations is now GA. See [Managing Agent Configurations](../../Settings/Managing Agent Configurations.htm) to learn more. - Agent 2.2.24 is now in Beta. See [Agent 2.2.24 Release Notes](../Agent Release Notes/Agent 2.2.x Release Notes.htm) to learn more. Updated: - Third-party support: VMware Horizon Client 8 has been re-branded as Omnissa Horizon Client 8. - We've updated our [Automox Agent Update Policy](../../Maintenance Policy and Agent Update Policy/Automox_Agent_Update_Policy.htm) regarding deferred upgrades, as customers now have the ability to control that via Agent Settings. See [Managing Agent Configurations](../../Settings/Managing Agent Configurations.htm) for details. - We fixed a broken link in Agent 1.42 Release Notes. - We updated the [OCSF Class Events](https://developer.automox.com/developer-portal/ocsf-classes-events/) documentation on our Developer Portal to show Agent Configuration events, under Web Resource Activity Events, for Audit Trail API. Bugfixes: - We fixed an issue where agents were showing as disconnected while the logs showed successful check-ins. - We fixed an issue where device logs were causing the Device page to have a longer load time. --- # May 2026 Release Notes _Section: Product Documentation › Release Notes › Documentation Release Notes • Source: https://docs.automox.com/product/Content/Product%20Documentation/Release%20Notes/Documentation%20Release%20Notes/May%202026%20Release%20Notes.htm_ ## May 29, 2026 Updated: - We updated [Agent Versioning and Support](../../Maintenance Policy and Agent Update Policy/Agent_Versioning_and_Support.htm) to reflect End of Support & End of Life dates for agent versions 2.1 and older. - We updated [Roles and Permissions Management](../../Global Access Management/Roles_and_Permissions.htm) to reflect recent updates in the console, and show better grouping of permissions. - API Documentation Improvements: We updated the [Automox API Reference](../../../Developer/Automox API Reference.htm) for better consistency in path variables & parameters, to make things a little easier to use. ## May 22, 2026 Added: - We added [[Third-Party Software Support](../../Third-Party Software/Third_Party_Software_Support.htm)](../../Third-Party Software/Third_Party_Software_Support.htm) for **RemotePC Host** (Windows, macOS). Updated: - We updated the [Otto AI FAQs](../../Otto AI/Otto_AI_FAQs.htm) to reflect that we now use Anthropic's Claude on AWS Bedrock for Ask Otto. - We updated [End-User Notifications](../../Notifications & Restarts/End_User_Notifications.htm) to clarify behavior for silent policies. - We made some quality of life improvements to the documentation site, including improved glossary functionality and automatically opening cross-reference and external links in a new tab. Bugfixes: - We corrected an encoding issue affecting display of special characters on the documentation site. - We fixed an issue where policies in a Missed Patch Window can run out of order when actioned by a notification. - We fixed an issue where a policy with notifications sets the next check-in time incorrectly, which causes the policy to run before the deadline. ## May 15, 2026 Updated: - We updated [Supported Operating Systems](../../Agents/Agent Requirements/Supported_Operating_Systems.htm) to add Fedora 44 and Ubuntu 26.04 LTS. - We updated [Scheduled Windows FAQ](../../Device Management/Scheduled_Windows_FAQ.htm) to note the updated Activity Log behavior for policies blocked by an active exclusion window. Bugfixes: - We fixed an issue where Remote Control status and settings were not showing up correctly on macOS devices. ## May 8, 2026 Updated: - We updated [Platform Firewall Allowlisting Rules](../../Agents/Agent Requirements/Agent_Firewall_Allowlisting_Rules.htm) to include [cdn.automox.com](https://cdn.automox.com/). - API Updates: We removed some endpoints from the Server Groups APIs, as they were erroneously released. - We fixed a dead link in [Automox Plugin for Rapid7 InsightConnect](../../Automox Integrations/Automox_Plugin_for_Rapid7_InsightConnect.htm). ## May 1, 2026 Updated: - We updated the [Splashtop Remote Control documentation](../../Landing Pages/RC LP.htm) to reflect deployment updates. - We updated [POST /remotecontrol-st/initiate-connection](https://docs.automox.com/product/Developer/Automox_API_Reference.htm?tocpath=Developer%20Documentation%7C_____10#tag/initiate-connection) to reflect that we've added the `connection-type` field to the request body. - We added landing pages to the upper-level sections on the docs site, to make it easier to link to a specific section within the site. - We added a note regarding rate limiting to the [Device Details](../../Device Management/Device_Details.htm) documentation. --- # November 2025 Release Notes _Section: Product Documentation › Release Notes › Documentation Release Notes • Source: https://docs.automox.com/product/Content/Product%20Documentation/Release%20Notes/Documentation%20Release%20Notes/November%202025%20Release%20Notes.htm_ ## November 21, 2025 Added - Automox Agent 2.4.42 is now entering Beta. See [Agent 2.4.42 Release Notes](../Agent Release Notes/Agent 2.4.42 Release Notes.htm) for details about this hotfix. - We updated our documentation to reflect the recent consistency improvements made in the console related to UUID terminology. You will now see the standardized use of **Account UUID**, **Global Organization UUID**, **Organization UUID**, and **Organization ID** throughout our content. These terms are now applied consistently across all relevant pages. For details, see [Managing Organizations](../../Global Access Management/Managing_Organizations.htm) and [Managing Global Keys](../../Global Access Management/Managing Global Keys.htm). Bugfixes: - We fixed an issue where a policy installed Office updates, but notifications were not displayed. - Analytics: We fixed an issue where the data was delayed for the Policy filter, in Policy Executions. - We fixed an issue with SSO URL validation for SSO Configurations. ## November 14, 2025 Added: - Scheduled Windows is now in GA. See [Managing Exclusion Windows](../../Device Management/Exclusion_Windows.htm), [Scheduled Windows](../../Device Management/Scheduled_Windows.htm), and [Scheduled Windows FAQ](../../Device Management/Scheduled_Windows_FAQ.htm) for details. - Developer Portal: We have added [new endpoints](https://developer.automox.com/developer-portal/whats-new/#11102025) for Scheduled Windows, as well as a [supporting document](https://developer.automox.com/developer-portal/scheduled-windows/) to explain more about the syntax. - [Filtering and Searching on the Polices Page](../../Policies/Filtering_and_Searching_on_the_Polices_Page.htm), which documents the new filter panel with options to filter by **Policy Type**, **OS**, **Group**, and **Patch Policy Status**. We also updated corresponding articles to reflect the updated policies page. Bugfixes: - We fixed an issue where polices were not being cloned properly. ## November 7, 2025 Updated: - [Roles and Permissions Management](../../Global Access Management/Roles_and_Permissions.htm): Clarified global permissions for the account administrator and full administrator roles, distinguishing account-level management from global operational access. - [Device Details](../../Device Management/Device_Details.htm): Clarified that the Summary tab with it's high-level overview, is available on all Automox plans. Access to additional device information requires a higher-level plan. Refer to our [Automox pricing page](https://www.automox.com/pricing) for plan details. - Agent 2.4.33 is now in GA. See [Agent 2.4.33 Release Notes](../Agent Release Notes/Agent 2.4.33 Release Notes.htm) for details. Bugfixes: - We fixed an issue that was preventing policies from being cloned. --- # October 2025 Release Notes _Section: Product Documentation › Release Notes › Documentation Release Notes • Source: https://docs.automox.com/product/Content/Product%20Documentation/Release%20Notes/Documentation%20Release%20Notes/October%202025%20Release%20Notes.htm_ ## October 31, 2025 Updated: - Developer Portal: We added [Custom Roles events](https://developer.automox.com/developer-portal/ocsf-classes-events/) to Audit Trail, updated the [permissions](https://developer.automox.com/developer-portal/api-permission-scopes/) required for Audit Trail API, and added documentation on the [OCSF Field Mapping](https://developer.automox.com/developer-portal/ocsf-field-mapping-cr/), to explain how the OCSF fields are mapped to Automox fields. - Automox Agent 2.4.33 is now in Beta. See [Agent 2.4.33 Release Notes](../Agent Release Notes/Agent 2.4.33 Release Notes.htm) for details. Bugfixes: - We fixed an issue where the Reboot Now action was not immediately causing the device to restart. - We fixed an issue where downloading the Policy Results Report CSV was returning a 500 error. ## October 24, 2025 Updated - [Developer Portal](https://developer.automox.com/developer-portal/whats-new/#10242025): We updated the response bodies for policies to add `install_do_not_disturb_honored` and `reboot_do_not_disturb_honored` to support DND functionality in Agent 2.4.31. - We updated the badge on release notes for Agent 1.x to reflect that it is now at End of Life and no longer supported. See [Agent Versioning and Support](../../Maintenance Policy and Agent Update Policy/Agent_Versioning_and_Support.htm) for details. Bugfixes: - Fixed an issue where server groups could not be deleted if deleted devices remained associated with them. - We fixed an issue that caused GetSoftware commands to fail on certain Ubuntu and Debian devices during WDK processing. - We fixed an issue where the Automox Tray could appear off-screen or on the wrong monitor when using multiple displays with different scaling settings. ## October 17, 2025 Bugfixes: - We fixed an issue that was causing remediations to run multiple times, resulting in unnecessary restarts. ## October 10, 2025 Updated: - Agent 2.4 introduces **Do Not Disturb (DND)** functionality, allowing administrators to configure tray notifications to either bypass or honor local DND settings. The release also removes the prior worklet-specific restriction requiring users to restart from the tray. Restarts outside the tray are now fully recognized for all policy types. When multiple policies are scheduled on a device, the Automox Tray now displays notifications tied to the **earliest policy deadline**. This functionality is not currently supported on macOS Tahoe or Windows Servers. See [Automox Tray and End-User Notifications FAQ](../../Notifications & Restarts/Automox Tray FAQ.htm) for details. Bugfixes: - We resolved an issue where Debian devices were not scanning for 5+ days. - We resolved an issue where GetSoftware commands were failing on RHEL 8.1. ## October 3, 2025 Updated: - We revised the [Billing](../../Settings/Billing.htm) documentation to align with the current console. Sections have been reorganized and clarified, with updated details about plans, licenses, and modules. - Developer Portal: The [Policy History](https://developer.automox.com/developer-portal/whats-new/#10012025) endpoints have moved to Console API, and the endpoints that use https://policyreport.automox.com have been deprecated. - We updated [Agent 2.4.31 Release Notes](../Agent Release Notes/Agent 2.4 Release Notes.htm) to reflect that DND functionality is not currently supported on macOS Tahoe and Windows Servers. Bugfixes: - We fixed an issue that caused the installation script to be incorrectly generated after uploading the installer to a Required Software policy. --- # Documentation Release Notes _Section: Product Documentation › Release Notes › Documentation Release Notes • Source: https://docs.automox.com/product/Content/Product%20Documentation/Release%20Notes/Documentation%20Release%20Notes/ReleaseNotesLP.htm_ ## 2026 - Q2 2026 Release Notes - [June 2026 Release Notes](June 2026 Release Notes.htm) - [May 2026 Release Notes](May 2026 Release Notes.htm) - [April 2026 Release Notes](April 2026 Release Notes.htm) - Q1 2026 Release Notes - [March 2026 Release Notes](March 2026 Release Notes.htm) - [February 2026 Release Notes](February 2026 Release Notes.htm) - [January 2026 Release Notes](January 2026 Release Notes.htm) ## 2025 - Q4 2025 Release Notes - [December 2025 Release Notes](December 2025 Release Notes.htm) - [November 2025 Release Notes](November 2025 Release Notes.htm) - [October 2025 Release Notes](October 2025 Release Notes.htm) - Q3 2025 Release Notes - [September 2025 Release Notes](September 2025 Release Notes.htm) - [August 2025 Release Notes](August 2025 Release Notes.htm) - [July 2025 Release Notes](July 2025 Release Notes.htm) - Q2 2025 Release Notes - [June 2025 Release Notes](June 2025 Release Notes.htm) - [May 2025 Release Notes](May 2025 Release Notes.htm) - [April 2025 Release Notes](April 2025 Release Notes.htm) - Q1 2025 Release Notes - [March 2025 Release Notes](March 2025 Release Notes.htm) - [February 2025 Release Notes](February 2025 Release Notes.htm) - [January 2025 Release Notes](January 2025 Release Notes.htm) --- # September 2025 Release Notes _Section: Product Documentation › Release Notes › Documentation Release Notes • Source: https://docs.automox.com/product/Content/Product%20Documentation/Release%20Notes/Documentation%20Release%20Notes/September%202025%20Release%20Notes.htm_ ## September 26, 2025 Added: - New third-party title support: - **Splashtop Streamer** (Windows, macOS) Updated: - Updated [Agent 2.4.31 Release Notes](../Agent Release Notes/Agent 2.4 Release Notes.htm) to reflect that Agent version 2.4.31 is now in Beta. Bugfixes: - Fixed an issue that prevented restart notifications from being sent when the policy option “Before an install that requires a restart” was enabled. ## September 19, 2025 Updated: - We updated [Supported Operating Systems](../../Agents/Agent Requirements/Supported_Operating_Systems.htm) to include macOS 26 (Tahoe), which requires agent version ≥ 2.3.35. Bugfixes: - We fixed a bug that caused the PowerShell Health Check to flag AllSigned as unhealthy. ## September 12, 2025 Added: - Developer Portal: We added new [endpoints](https://developer.automox.com/developer-portal/whats-new/#09122025) for managing Global API Keys, as well as supporting [documentation](https://developer.automox.com/developer-portal/api-permission-scopes/). - We have published [Agent 2.4 Release Notes](../Agent Release Notes/Agent 2.4 Release Notes.htm), which is coming soon. Updated: - Agent 2.3.35 is now GA, see [Agent 2.3.35 Release Notes](../Agent Release Notes/Agent 2.3.35 Release Notes Tahoe.htm) for details. - Updated [Understanding Global Access Management](../../Global Access Management/Understanding_Global_Access_Management.htm) overview to show new Keys tab and added link to [Managing Global Keys](../../Global Access Management/Managing Global Keys.htm). - Updated [Device Explorer](../../Device Management/Device_Explorer.htm) article to align with recent console design enhancements. No new features were introduced. - Updated [Agent Firewall Allowlisting Rules](../../Agents/Agent Requirements/Agent_Firewall_Allowlisting_Rules.htm) to reflect that the URL for the installation reporting service has changed. - Updated [Agent 2.3.34 Release Notes](../Agent Release Notes/Agent 2.3.x Release Notes.htm) to fix an incorrect path given for the Windows Tray log. - Worklet Catalog: The catalog now includes **Base worklets**, which are available to all users. A new **Access Level filter** (Base vs. Premium) has also been added to help distinguish worklets. There is no change for plans that already include Worklets. See [Using the Worklet Catalog](../../Worklet Catalog/Using_the_Worklet_Catalog.htm). ## September 5, 2025 Added: - Global API Keys: We added a new article, [Managing Global Keys](../../Global Access Management/Managing Global Keys.htm), that explains how to create and manage Global API Keys. This guide clarifies how keys work with Global roles, outlines permissions, and provides step-by-step instructions for viewing and managing keys in the Global View. - We added [Agent 2.3.35 Release Notes](../Agent Release Notes/Agent 2.3.35 Release Notes Tahoe.htm) which is currently in Beta. GA rollout is targeted to begin mid-September. Updated: - You can now view the Account ID and Global Organization ID from the Setup & Configuration → Organizations tab. These columns are hidden by default. See [Managing Organizations](../../Global Access Management/Managing_Organizations.htm). - We updated and renamed the Managing Keys doc to [Managing Organization Keys](../../Settings/Managing_Keys.htm) to reflect the use of organization-only API keys. --- # Remote Control with Splashtop – FAQ and Troubleshooting _Section: Product Documentation › Remote Control Module • Source: https://docs.automox.com/product/Content/Product%20Documentation/Remote%20Control%20Module/Remote%20Control%20(Splashtop)%20%E2%80%93%20FAQ%2C%20Known%20Issues%2C%20and%20Troubleshooting.htm_ ## Overview This page provides answers to common questions, known limitations, and troubleshooting guidance for Remote Control with Splashtop in Automox. Remote Control enables IT administrators to securely connect to devices directly from the Automox console for troubleshooting, maintenance, patching, and end-user support. All sessions are encrypted and audited at the session lifecycle level. ## What plans include Remote Control? **Remote Control (Core)** Included with Automate Enterprise. Provides: - Secure remote desktop access - Encrypted traffic - View-only and interactive control - Sound redirection - Ability to switch between monitors on multi-monitor remote devices **Automox Resolve, powered by Splashtop (Premium add-on)** Optional paid add-on that includes everything in Core plus: - File transfer (up to 64 GB) - Chat - Remote print - Multi-monitor support (including "All Monitors (One Window)" to view all monitors simultaneously) - Session recording (local) - Three concurrent sessions per device **How do I know which plan I have?** You can see which Remote Control plan is enabled by opening a device's Remote Control section in Device Details. The Remote Control section displays the current **Remote Control Tier**, indicating whether the device is using Remote Control (Core) or Automox Resolve powered by Splashtop. **What is the cost of Automox Resolve Powered by Splashtop (premium add-on)?** Pricing varies by organization. Contact your Account Manager for a quote. If you're unsure who your contact is, email [success@automox.com](mailto:success@automox.com?subject=Resolve by Splashtop Quote) . ## Platforms, Components, and Installation ### Which operating systems are supported? **Streamer (remote device):** - Windows 10–11 - Windows Server 2012–2022 - macOS 13 (Ventura) or later - Linux is not currently supported (planned for a future phase) **Splashtop RMM App (administrator device):** - Windows - macOS - Linux is not supported as a Splashtop RMM App platform ### What’s the difference between the Splashtop Streamer and Splashtop RMM App? **Splashtop Streamer** Installed on the remote device being controlled. **Splashtop RMM App ("Splashtop for RMM" App)** Installed on the administrator’s device to launch sessions. Both components are required to start a Remote Control session. The Splashtop RMM App is installed once per administrator device, while the Streamer must be installed and registered on every device you want to control. ### Do I need to install anything before starting a Remote Control session? Yes. A Remote Control session requires both components: - Splashtop RMM App installed on the administrator’s device - Splashtop Streamer installed and registered on the remote device **Important Details:** - The Streamer is not automatically installed at session launch It must be deployed ahead of time, either organization-wide from **Settings → Remote Control** or per device from **Device Details → Remote Control** If the Streamer is not installed or registered, the session will not start and the console will display the current Streamer status and next steps. - If the Splashtop Streamer is not installed or not registered, clicking **Remote Control** does not start a session. Instead, the console displays the **Splashtop Streamer Status** with details about the device’s current state and available actions to resolve the issue. ### How is the Splashtop Streamer installed? The Streamer is installed silently via the Automox agent. **Supported methods:** - **Organization-wide install** (Settings → Remote Control) - **Group-level install** (Settings → Remote Control → Install Streamer → By Groups) - **Ad hoc install** (Settings → Remote Control → select devices from the device table → Actions → Install Streamer) - **Per-device install** (Device Details → Remote Control) ### Can I install or uninstall the Streamer for specific groups? Yes. From **Settings → Remote Control**, click **Install Streamer** and select **By Groups**, or click **Uninstall** and select **Groups** in the confirmation modal. You can select one or more groups. The action applies to devices currently in the selected groups — it does not auto-install or auto-uninstall on future devices added to those groups. ### Can I install or uninstall the Streamer on specific devices from RC Settings? Yes. The device table on **Settings → Remote Control** supports row selection. Select one or more devices, click **Actions**, and choose **Install Streamer** or **Uninstall Streamer**. This is useful for targeted remediation — for example, retrying installation on specific devices that show a Failed status. ### Is the Splashtop Streamer installed system-wide or under a user profile on Windows? The Splashtop Streamer is installed system-wide on Windows — not under the currently logged-in user's profile. It runs as a **Windows service** executed by the SYSTEM account. This means the Streamer is available before any user logs in (including at the Windows login screen), requires no per-user configuration, and persists across reboots and user account changes. ### How long does installation take? Is a restart required? Installation typically takes **2–5 minutes per device**, depending on network speed and device performance. A system restart is **not required**. ### Is there a single installer for the Automox agent and Splashtop? No. The Automox agent and the Splashtop Streamer are installed separately. The Streamer install is triggered from the Automox console and executed by the agent. ### What happens during registration? After installation: - Automox registers the Streamer - The Splashtop device ID is linked to the Automox device - Streamer status updates appear in the Remote Control section Registration must complete before a session can begin. ### Can customers deploy the Streamer outside Automox? Yes. You may pre-install the Splashtop Streamer using tools like Intune, Jamf, or PDQ. However: - You must still run the Automox install action to register the device - Automox detects the existing Streamer and skips re-installation - Registration is required for Remote Control to function ### What agent version is required? Automox Agent 2.4.33 or later is required. ### How do I uninstall the Splashtop Streamer? Supported uninstall methods: - **Organization-wide uninstall** (Settings → Remote Control) - **Group-level uninstall** (Settings → Remote Control → Uninstall → select Groups → choose groups) - **Ad hoc uninstall** (Settings → Remote Control → select devices from the device table → Actions → Uninstall Streamer) - **Per-device uninstall** (Device Details → Remote Control) - **Worklet-based uninstall** (Software Lifecycle Worklet Catalog) All methods uninstall silently and fully remove the Streamer. ### Can I cancel a Remote Control (Splashtop Streamer) install once it has started? No. Once a Streamer install command has been sent to a device, it cannot be canceled or stopped while it is in progress. Streamer installs are executed through Automox’s core command queue. Currently, no mechanism exists to interrupt or remove a command once it has been queued and dispatched. ### What happens if both install and uninstall are triggered? If an install and an uninstall are both requested for the same device, the commands run **in sequence**: 1. The install completes first 2. The uninstall runs immediately afterward No manual intervention is required. The device ends in an uninstalled state once both commands finish processing. No hierarchy exists between organization-level, group-level, and ad hoc actions — the most recent action executed against a device determines its final state. **Important notes:** - No “cancel” or “stop” button exists for in-progress Streamer installs - This applies to all action scopes (org-wide, group-wide, ad hoc, and per-device) - Large environments may take time for all queued commands to complete ### What happens to Linux devices when I run an org-wide Streamer install? Linux devices are ignored when running an org-wide or group-wide Streamer install. Remote Control powered by Splashtop is supported on **Windows and macOS** only. When an org-wide or group-wide install action is initiated, Automox targets only supported operating systems. Linux devices are not eligible for Streamer installation and should not be affected by the action. #### What this means for mixed OS environments - You can safely run org-wide or group-wide install actions even if Linux devices exist in your organization. - Streamer installation is attempted only on supported platforms. - Linux devices remain unchanged. - Linux devices appear as Not Installed in the deployment health summary and device table. ### Where do I manage Remote Control settings for my organization? Automox includes a dedicated **Remote Control** section under **Settings → Remote Control**. This section is used to manage organization-wide Remote Control behavior, including: - Viewing the **deployment health summary** (Ready, Failed, and Not Installed device counts) - Reviewing the **device table** showing per-device Streamer status, with filtering by OS, Group, and Streamer Status - Installing or uninstalling the Splashtop Streamer across all devices, by group, or in specific devices selected from the table - Controlling default installation behavior for new devices (Auto-Install) Device-specific status and actions are managed from the **Remote Control** section on the Device Details page. **Note:** Data displayed on the RC Settings page may be up to 15 minutes old. ### What is the Deployment Health Summary? The deployment health summary is displayed at the top of the **Settings → Remote Control** page. It shows three status cards — Ready, Failed, and Not Installed — each with a device count and percentage relative to the total device count. This provides a quick at-a-glance view of Remote Control readiness across the organization and helps administrators identify deployment gaps. ### What is the device table on RC Settings? The device table on **Settings → Remote Control** lists all devices with their current Streamer deployment state. Columns include Device Name, Operating System, Group, Streamer Status, Last Install Attempt, and Last Result Returned. The table supports filtering by OS, Group, and Streamer Status, as well as search by Device Name. Admins can sort columns, customize column visibility, and select rows for bulk install or uninstall actions. The table is paginated (default 25, up to 500 devices). ### What’s the difference between Settings → Remote Control and the Remote Control section on a device? - **Settings → Remote Control** provides a centralized view of deployment health across the organization. It includes the deployment health summary, a filterable device table, and supports organization-wide, group-level, and ad hoc install / uninstall actions. It is the primary surface for managing Streamer deployment at scale. - **Device Details → Remote Control** is used to view Streamer status, troubleshoot issues, and take action on individual devices. Within Device Details, the Remote Control section is structured to group information into Tier, Status, Actions, and Settings to make it easier to understand readiness, take action, and manage configuration. ## Existing Splashtop Installations ### What if I already have Splashtop installed on my devices? In many cases, no additional action is required. Splashtop’s commercial offerings — including **Splashtop Business**, **Splashtop Personal**, **Splashtop Classroom**, and **Splashtop On-Prem** — use the same underlying Streamer application as Splashtop for RMM. These installations are compatible with Automox Remote Control. If one of these applications is already installed on a device: - Automox does not reinstall the Streamer - The existing Splashtop installation is reused - Remote Control can function normally once the device is registered ### How does this work technically? When you initiate a Streamer install from Automox: - Automox still runs the installation script on the target device - If Splashtop is already installed, the script skips re-installation - Automox extracts the existing **Splashtop device UUID** - This UUID is sent to the Automox cloud to map the Automox device to Splashtop This mapping step is required for Remote Control to function correctly, even when Splashtop is already present. ### Are there any limitations or caveats? This behavior has not been extensively tested across all customer environments and configurations. In some cases, behavior may vary depending on how Splashtop was originally installed or configured. If you encounter unexpected behavior when using an existing Splashtop installation, please [contact Automox Support](https://help.automox.com/hc/en-us/requests/new) so the issue can be investigated. ## Permissions, Consent, and Access ### How are Remote Control actions authorized in Automox? Remote Control actions are governed by role-based permissions. Your Automox role determines whether you can start sessions, manage consent, or perform Streamer deployment actions. | Permission | What It Controls | Default Roles | | --- | --- | --- | | Device: Control | Start Remote Control sessions, clear connections, firewall check | Full Administrator, Helpdesk Operator, Organization Operator | | Remote Control Actions: Manage (device) | Install or uninstall the Streamer on a single device from Device Details | Full Administrator, Helpdesk Operator, Organization Operator | | Remote Control Consent: Manage | Change end-user consent options | Full Administrator | | Remote Control Deployment: Read | View RC Settings page (health summary, device table, Auto-Install toggle), view RC section on Device Details | Full Administrator, Helpdesk Operator, Organization Operator | | Remote Control Deployment: Manage | Org-wide install / uninstall, group-wide install / uninstall, ad hoc install / uninstall from device table, toggle Auto-Install | Full Administrator | ### Who can start a Remote Control session? Users with **Device: Control** permission. Default roles: - Full Administrator - Helpdesk Operator - Organization Operator ### Who can manage end-user consent? Only users with **Remote Control Consent: Manage** permission. Default role: - Full Administrator This controls the **End-user Consent** setting on in the Settings area of the Remote Control section on a device. ### Who can install or uninstall the Splashtop Streamer? Per-device actions (from Device Details) require **Remote Control Actions: manage (device)** permission or **Device: Control** permission. Default roles: - Full Administrator - Organization Operator - Helpdesk Operator **Organization-wide, group-wide, and ad hoc actions** (from Settings → Remote Control) require **Remote Control Deployment: Manage** permission. Default role: - Full Administrator These users can install or uninstall the Streamer org-wide or by group, perform ad hoc actions from the device table, and enable or disable Auto-Install for new devices. ### Who can view deployment settings without making changes? Users with **Remote Control Deployment: Read** permission. Default roles: - Full Administrator - Organization Operator - Helpdesk Operator Read-only users can view the deployment health summary, device table, and Auto-Install toggle state but cannot take action. ### How does end-user consent work? End-user consent controls whether a user at the device must approve a Remote Control session before it starts — and what happens if the user does not respond. Consent is configured per device from the Settings area of the Remote Control section. End-user consent can also be updated in bulk using **Devices → Actions → Configure Remote Control**, allowing administrators to apply consistent consent behavior across multiple devices at once. ### What end-user consent options are available? Administrators can choose from the following End-user consent options: - Required (attended) The user must approve the session before it begins. - Not required (unattended) The session starts immediately with no end-user prompt. - Required — if user doesn't respond, deny If the user does not click Allow within 30 seconds, the session fails. - Required — if user doesn't respond, allow If the user does not respond within 30 seconds, the session starts automatically. The default setting is Required (attended). ### What happens if a user doesn't respond to a consent prompt? The outcome depends on the configured End-user consent setting: - If set to **Required (attended)**, the session does not start until the user approves. - If set to **Required — if user doesn't respond, deny**, the session fails after 30 seconds. - If set to **Required — if user doesn't respond, allow**, the session starts automatically after 30 seconds. ### What happens if "Required — if user doesn't respond, allow" is selected and no user is logged in? If no user is actively logged in to the device, the remote control session connects automatically. Because there is no end user present to receive or respond to a consent prompt, Automox does not wait for the consent timeout period. The session starts immediately. **Expected behavior:** - No consent prompt is shown - The 30-second response window does not apply - The connection is established automatically This behavior ensures unattended devices—such as servers or systems without an active user session—remain accessible, while still enforcing consent when a user *is* logged in. ### Can admins connect to locked or signed-out devices? Yes — only when unattended access is enabled. If End-user consent is set to an unattended option or to **"Required — if user doesn't respond, allow,"** sessions can start when a device is locked, at the login screen, or signed out. **Requirements:** - Streamer installed and registered - Agent online - macOS permissions granted (if applicable) ### Why is the Remote Control button missing or disabled? Common reasons include missing Device: Control permission, plan limitations, unsupported admin OS (Linux Splashtop RMM App not supported), or the device being offline. ### Can I use the Automox version of Splashtop to launch sessions outside the Automox console? No. Remote Control sessions must be launched **from within the Automox console**. To start a Remote Control session: - The target device must be **managed by Automox** - The device must belong to the **same organization** as the administrator - The session must be initiated from the **Device Details → Remote Control** section in the Automox console Launching sessions directly from the Splashtop app outside the Automox console is not supported. ## macOS Permissions, Consent, and Common Issues ### Do macOS users need to be administrators? No. Permissions apply to the currently logged-in user. The user must enter their password to approve permissions, but administrator privileges are not required. ### What permissions are required on macOS? Required: - Screen Recording (screen visibility) - For macOS 14.2 Sonoma and later, use the Remote Desktop permission. - Accessibility (keyboard and mouse control) Optional (feature-dependent): - Microphone (audio) - Full Disk Access (advanced file operations) IT can pre-approve Accessibility and Full Disk Access using MDM tools. Screen Recording and Microphone always require user approval due to Apple security policies. For step-by-step instructions with screenshots and macOS version–specific guidance, see Splashtop’s documentation: [How to allow remote access on macOS](https://support-splashtopbusiness.splashtop.com/hc/en-us/articles/29381364146459-How-to-allow-remote-access-on-macOS) ### Why does macOS show a black screen? A black screen almost always means Screen Recording permission is missing. Have the user open **System Settings → Privacy and Security**, enable **Screen Recording & Accessibility** for Splashtop, and restart the Splashtop Streamer if prompted. This is expected macOS behavior, not a bug. ### Which macOS permissions can IT pre-configure, and which require user approval? IT administrators can pre-approve the following permissions using MDM tools: - Accessibility - Full Disk Access The following permissions always require user approval due to Apple security policies: - Screen Recording / Remote Desktop - Microphone (when audio features are used) These permissions cannot be enabled silently. ### What happens if a user switches accounts on a Mac? Permissions are granted per user. Switching users may disconnect the Remote Control session and require reconnection under the new user context. ### (Windows) Can I connect with admin rights? How does UAC work? Yes. If no user is logged in, you can authenticate using administrator credentials. UAC prompts behave as if you were physically present at the device. ## Features & Limits Feature availability depends on your Remote Control plan. | Feature | Remote Control (Core) | Automox Resolve, powered by Splashtop (Premium) | | --- | --- | --- | | Secure remote desktop | ✓ | ✓ | | Encrypted connections | ✓ | ✓ | | View-only mode | ✓ | ✓ | | Interactive control | ✓ | ✓ | | Sound redirection | ✓ | ✓ | | Switch between monitors | ✓ | ✓ | | View all monitors simultaneously (All Monitors / One Window) | NA | ✓ | | File transfer (up to 64 GB) | NA | ✓ | | Chat | NA | ✓ | | Remote print | NA | ✓ | | Session recording (local) | NA | ✓ | | Concurrent sessions per device | 1 | 3 | ### Can I switch between monitors during a remote session? Is this a Premium-only feature? No — monitor switching is available with both Core and Resolve. With Core, you can switch between individual monitors on the remote device one at a time. With Resolve (Premium), you get that same capability plus the option to view all monitors simultaneously using "All Monitors (One Window).” ### Where are session recordings saved? Session recordings are stored locally and never uploaded. - macOS: `~/Documents/Splashtop for RMM` - Windows: `C:\Users\{USERNAME}\Documents\Splashtop for RMM` ### Can administrators disable session recording in Splashtop? No. If your organization is using **Automox Resolve powered by Splashtop**, session recording is always available to technicians and cannot be disabled at the organization level. Session recordings are initiated manually by the technician and are stored locally on the technician's machine. ### What’s the file transfer size limit? Up to 64 GB per transfer. ### Is Wake-on-LAN (WoL) supported? Wake-on-LAN is not supported through the Automox–Splashtop integration. While Splashtop supports WoL in some of its standalone products, this capability is not exposed or configurable through Automox. ### Is there a limit on how many devices an administrator can connect to at the same time? No. Automox does not impose a hard limit on the number of simultaneous remote connections a technician can initiate. Practical limits may still be influenced by local system performance and network conditions. ## Updates & Lifecycle ### How are the Streamer and Splashtop RMM App updated? Both appear in the [Automox Third-Party Software Catalog](../Third-Party Software/Third_Party_Software_Support.htm) and can be updated using standard patch policies. The Streamer may also prompt for updates independently. This behavior is expected. ## Reporting, Audit, and Compliance ### Is Remote Control activity audited? Yes. Automox records key Remote Control activity in the audit trail for security and compliance purposes. #### What actions are captured? The audit trail includes: - Remote Control session start, end, and failure events - Organization-wide Streamer install and uninstall actions - Group-wide Streamer install and uninstall actions - Ad hoc Streamer install and uninstall actions - Auto-Install for new devices enabled or disabled Each record includes the organization, initiating user, timestamp, and action type, and action scope (organization, group, or ad hoc). #### What is not captured? To protect privacy: - Screen content is not recorded - Keystrokes and mouse activity are not logged - Files accessed or transferred during a session are not audited Only session lifecycle metadata and administrative actions are captured. ## Auto-Install & Deployment Behavior ### What happens when Auto-Install for new devices is enabled? When enabled, Automox automatically installs the Splashtop Streamer on newly added devices that meet eligibility requirements. Existing devices are not affected. Auto-Install only applies to devices added **after** the setting is enabled. Existing devices must be installed manually using an organization-wide or per-device install action. ### What happens if a device is offline during an install or uninstall? Offline devices automatically process the action the next time they check in. ## Legacy Remote Control ### What happened to Automox’s legacy Remote Control? Remote Control with Splashtop replaces Automox’s legacy Remote Control solution and provides improved performance, security, and feature support. ### Will Automox automatically remove legacy Remote Control components from my environment? No. Automox does not automatically remove legacy Remote Control components. However, Automox provides supported worklets to remove legacy Automox Remote Control components if you choose to clean them up. Available worklets: - Windows – [Software Lifecycle: Remove Automox Remote Control Application](https://console.automox.com/manage/worklet-catalog/a130ed07-c12b-4fe1-b7c3-dc604b24c81b) - macOS – [Software Lifecycle: Remove Automox Remote Control Application](https://console.automox.com/manage/worklet-catalog/9e61bc87-63e8-4ffd-92ef-3eb50bfabf6e) These worklets remove legacy binaries and services and can be run safely alongside Splashtop. ## Architecture and Execution Flow ### How does a Remote Control session work behind the scenes? Remote Control sessions are orchestrated by Automox and securely brokered through Splashtop. The high-level flow is: 1. An administrator initiates Remote Control from the Automox console. 2. Automox performs authentication and role-based access control (RBAC) checks. 3. Automox requests one-time credentials from the Splashtop API. 4. Automox generates an additional one-time token for session validation. 5. Automox sends a command through the Automox Agent to the Splashtop Streamer on the endpoint, including: - The one-time credentials - The consent configuration (attended or unattended) 6. The Splashtop Streamer establishes a secure connection to Splashtop's servers. 7. Automox returns a launch link (containing the one-time credentials) to the initiating client. 8. The Splashtop RMM App opens the link and communicates with Splashtop's servers to start the session. 9. Desktop data is relayed securely through Splashtop relay servers for the duration of the session. All connections are encrypted, and credentials are single-use. ## Troubleshooting & Error Checks ### If a Remote Control session won't start **Step 1: Confirm basic requirements** - The **Splashtop RMM App** is installed on the administrator's device - The **Automox Agent version is 2.4.33 or newer** - **macOS permissions** are approved (if applicable) - The **Splashtop Streamer is installed and registered** - The **device is online** If any of these requirements are not met, Remote Control sessions do not start. **Step 2: Check connectivity for Remote Control** If the basic requirements are met and the session still fails to connect, run the **Check Firewall** action from the Remote Control section on the Device Details page. This check verifies outbound connectivity to all required services, including: - **Splashtop API servers** (authentication and session setup) - **Splashtop relay servers** (screen, input, and session data) - **Automox command storage** (required for component downloads and management) If any of these checks fail, Remote Control sessions may not start even if the Streamer is installed and registered. If a check fails: - Review firewall or proxy allowlists - Compare results against the [Platform Firewall Allowlisting Rules](../Agents/Agent Requirements/Agent_Firewall_Allowlisting_Rules.htm) - Re-run the connectivity check after changes are applied **Step 3: Use RC Settings to identify patterns** If multiple devices are failing, use the **Settings → Remote Control** page to identify the scope of the issue. Filter the device table by Streamer Status = Failed to see all affected devices, check whether failures are concentrated in specific groups or OS types, and use the Actions menu to retry installation on selected devices. ### Why doesn’t Remote Control start when I click the button? Remote Control requires the Splashtop Streamer to be both **installed and registered**. If the device is not ready, clicking **Remote Control** opens the **Splashtop Streamer Status** instead of starting a session. This view shows whether the Streamer is missing, unregistered, or failed during a previous attempt, along with available actions to resolve the issue. ### What does the “Install” button do in the Splashtop Streamer Status? The **Install** button is used for both first-time installation and retry scenarios. When selected, Automox attempts to: - Install the Splashtop Streamer if it is not already installed - Register the device once installation is complete You do not need to distinguish between installation and registration issues—the Install action always attempts both steps. ### Where can I see why a Remote Control session failed? When a Remote Control session fails: - The **Audit Trail** records the failure, including the returned error code and error message - **Agent logs** confirm that a session attempt occurred - **Splashtop Streamer logs** on the device provide low-level connection and environment details Each source provides different information and can be used together for troubleshooting. ### Where are Splashtop Streamer logs located? On Windows devices, Splashtop Streamer logs are located at: `C:\Program Files (x86)\Splashtop\Splashtop Remote\Server\log` On Mac devices, Splashtop streamer logs are located in a zip file. Unzip and look for SPLOG.txt. `~/Library/Application Support/Splashtop Streamer/Logs` These logs include installation, registration, and connection-level details. ## Troubleshooting Tools ### When should I use the Restart Splashtop Streamer Service worklet? Use this worklet when the Splashtop Streamer is installed and registered but is no longer running as expected. This can occur when local environmental factors—such as endpoint security tools or OS-level events—stop or disrupt the service. This worklet restarts the service but does not reinstall or re-register the Streamer. ### What does the Collect Splashtop Streamer Logs worklet do? This worklet collects detailed, system-level Splashtop Streamer logs directly from the device. It is most useful when installation, registration, or connection issues persist after retrying or restarting the Streamer service. ## Security, Privacy, and Compliance Sessions are encrypted end-to-end. Only session lifecycle metadata is logged. No screen content, keystrokes, or file actions are recorded. Splashtop maintains its own security and compliance certifications. For the most up-to-date information, see: [Splashtop Security & Compliance](https://www.splashtop.com/security/compliance) ### Are new firewall rules required? Yes. Splashtop introduces new outbound requirements beyond legacy Automox Remote Control. These requirements are additive and do not replace existing Automox [Platform Firewall Allowlisting Rules](../Agents/Agent Requirements/Agent_Firewall_Allowlisting_Rules.htm). ## Related Topics - [Automox Remote Control with Splashtop – Full User Guide](Splashtop User Guide.htm) - [Quick Start Guide - Using Remote Control with Splashtop](Splashtop QSG.htm) - [Additional Recommendations for Automox Resolve, powered by Splashtop](../Agents/Agent Requirements/Agent_Firewall_Allowlisting_Rules.htm#Addition) ## Additional Resources - [How to allow remote access on macOS (Splashtop)](https://support-splashtopbusiness.splashtop.com/hc/en-us/articles/29381364146459-How-to-allow-remote-access-on-macOS) - [Splashtop Compliance: GDPR, HIPAA, FERPA, SOC 2, ISO & More](https://www.splashtop.com/security/compliance) - [Splashtop FIPS Compliance (external)](https://support-splashtopbusiness.splashtop.com/hc/en-us/articles/360029040431-Splashtop-FIPS-Compliance-How-do-I-enable-it) **Note:** FIPS mode is configured within Splashtop and managed outside the Automox console. --- # Quick Start Guide - Using Remote Control with Splashtop _Section: Product Documentation › Remote Control Module • Source: https://docs.automox.com/product/Content/Product%20Documentation/Remote%20Control%20Module/Splashtop%20QSG.htm_ This Quick Start Guide explains how **Remote Control with Splashtop works end‑to‑end**, including **how the Splashtop Streamer is installed, what macOS permissions are required**, and **exactly what end users will see during and after installation.** For advanced configuration, troubleshooting, and UI reference, see the [Automox Remote Control with Splashtop – Full User Guide](Splashtop User Guide.htm) . ## Overview Remote Control allows IT administrators to securely connect to devices directly from the Automox console. Sessions are encrypted and can be used for troubleshooting, patching, maintenance, or end‑user support. On the Device Details page, the Remote Control section is organized to separate entitlement, deployment status, actions, and settings related to Remote Control. Automox integrates with Splashtop using two components: - **Splashtop RMM App**– Installed on the *administrator’s* computer - **Splashtop Streamer** – Installed on the *remote device* being controlled Both components must be installed, with permissions properly configured, before a session can begin. ## Prerequisites ### Subscription & Permissions To access Splashtop’s capabilities, your organization must be on one of the following plans. - **Remote Control Core** – Included with Automate Enterprise - **Automox Resolve, powered by Splashtop** – Optional add‑on that enables premium features (file transfer, chat, remote print, multiple concurrent sessions) If you are interested in a plan upgrade to access Splashtop, please contact your Automox Account Manager, or reach out to [expansion-sales@automox.com](mailto:expansion-sales@automox.com). ### Role-Based Permissions Your Automox role determines what Remote Control actions you can perform: **Remote Control – Session Access** - To start a Remote Control session, you must have one of the following permissions: - Full Administrator - Organization Operator - Helpdesk Operator - Custom roles with **Devices: Control** **Remote Control – Consent Management** - Change attended vs. unattended access: - Full Administrator - Custom roles with **Remote Control Consent: Manage** **Remote Control – Deployment (Install / Uninstall)** - **View Remote Control deployment settings**(read-only): - Full Administrator - Organization Operator - Helpdesk Operator - Custom roles with **Remote Control Deployment: Read** - **Install or uninstall the Splashtop Streamer (organization-wide, group-wide, or ad hoc from the RC Settings device table):** - Full Administrator - Custom roles with **Remote Control Deployment: Manage** - **Install or uninstall the Splashtop Streamer (per device from Device Details):** - Full Administrator - Organization Operator - Helpdesk Operator - Custom roles with **Remote Control Actions: manage (device)** or **Devices: Control** Bulk actions (organization-wide, group-wide, and ad hoc installs and uninstalls) are restricted to roles with explicit **Remote Control Deployment: Manage** permission. ### Agent & OS Requirements All devices with the Splashtop streamer need to be on Agent 2.4.33 or newer in order for Splashtop to work. **Administrator device (Splashtop RMM App):** - Windows - macOS **Remote device (Streamer):** - Windows 10–11 - Windows Server 2012–2022 - macOS 13 (Ventura) or later Linux is not currently supported for the Splashtop Streamer. ### Network Requirements Outbound traffic to required Splashtop services must be allowed. See [Additional recommendations for Automox Remote Control](../Agents/Agent Requirements/Agent_Firewall_Allowlisting_Rules.htm#Addition). ### Install the Splashtop RMM App The **Splashtop RMM App** must be installed before you can start a remote session. 1. Navigate to the Device Details page of the remote device and select **Remote Control**. 2. The first time you attempt to use Remote Control—and on every attempt until you confirm—the console will display a prompt asking whether you have already installed the Splashtop RMM App. - Select **No** to open a window with download links for Windows and macOS. - Install the app, then return to the console. 3. Once the Splashtop RMM App is installed, click **Remote Control** again and select **Yes** when prompted. - After you click **Yes**, Automox records that confirmation and you will **not** see the prompt again on future Remote Control attempts from that same administrator device. **The Splashtop RMM App only needs to be installed once per administrator device.** ![](../../Resources/Images/splashtop-required.png) ## How the Splashtop Streamer Is Installed (Remote Devices) ### Installation Options Administrators can install the Streamer in two ways: **Option 1: Organization‑Wide Install** - Navigate to **Settings → Remote Control** - Click **Install Streamer** and select **By Organization** - A confirmation modal displays the organization name and total number of devices. Click **Install to Organization** to confirm. - Automox sends a silent install command to all supported devices in the organization. On Windows, nothing is required for the end-user. **Option 2: Group‑Level Install** - Navigate to **Settings → Remote Control** - Click **Install Streamer** and select **By Groups** - Select one or more groups from the group picker and click **Install to (N) Groups** - Automox sends a silent install command to all supported devices in the selected groups Group-level install is a one-time action applied to devices currently in the selected groups. It does not auto-install on future devices added to those groups. **Option 3: Ad Hoc Install from RC Settings** - Navigate to **Settings → Remote Control** - Use filters or search to locate target devices in the device table - Select one or more devices using the row checkboxes - Click **Actions** and select **Install Streamer** This is useful for targeted remediation, such as retrying installation on specific devices that previously failed. **Option 4: Per‑Device Install** - Open the **Device Details** page - Expand the **Remote Control** accordion - Select **Install Splashtop Streamer** ### Installation Behavior - Installation is silent on Windows - On macOS, the app installs silently but **user interaction is required for permissions** - After install: - The Streamer registers with the Automox–Splashtop backend - Device status updates appear in the Remote Control accordion If installation or registration fails, Automox displays a **Streamer Status modal** with error details and a retry option. No hierarchy exists between organization-level, group-level, and ad hoc actions. The most recent action executed against a device determines its final state. ### How Is the Splashtop Streamer Installed on Windows? On Windows, the Splashtop Streamer is installed **system-wide** — not under the currently logged-in user's profile. It runs as a **Windows service** executed by the SYSTEM account, which means: - It is available before any user logs in, including at the Windows login screen - No per-user installation or configuration is required - The service starts automatically and persists across reboots and user account changes ## Remote Control Settings Page The **Settings → Remote Control** page provides centralized visibility and control over Remote Control deployment across the organization. ### Deployment Health Summary The top of the page displays deployment health cards showing how many devices are in each status: - **Ready** — Streamer installed and registered; eligible for sessions - **Failed** — A previous install or registration attempt did not complete successfully - **Not Installed** — Streamer is not installed; no install attempt has been made Counts are shown relative to total device count. ### Device Table Below the health summary, a device table lists all devices with their Streamer deployment state. The table includes columns for Device Name, Operating System, Group, Streamer Status, Last Install Attempt, and Last Result Returned. Admins can filter by OS, Group, and Streamer Status, and search by Device Name. The table supports sorting, column customization, pagination (default 25, up to 500 devices), and row selection for bulk actions. **Note:** Data displayed in the device table may be up to 15 minutes old. ## macOS Permissions – What’s Required and Why For Splashtop-maintained, step-by-step macOS permission instructions (including screenshots and OS-specific variations), see [How to allow remote access on macOS](https://support-splashtopbusiness.splashtop.com/hc/en-us/articles/29381364146459-How-to-allow-remote-access-on-macOS). macOS enforces strict privacy controls. Even when the Streamer is installed by IT, **Apple requires the end user to approve certain permissions manually**. ### Required Permissions The Splashtop Streamer requires: - **Accessibility** – Allows keyboard and mouse control - **Screen Recording / Remote Desktop** *macOS may show either **Screen Recording** or **Remote Desktop** depending on your OS version. These labels refer to the same screen-visibility permission. – Allows screen viewing ### Optional (Feature‑Dependent) Permissions - **Microphone** – Required for audio during remote sessions - **Full Disk Access** – Required for advanced file operations ### What IT Can Pre‑Configure Using MDM tools (Jamf, Intune, etc.), IT can: - Pre‑approve **Accessibility** - Pre‑approve **Full Disk Access** - Configure Screen Recording to allow **standard users** to approve without admin rights Apple does not allow Screen Recording or Microphone access to be granted silently. ### What End Users Will See After installation, macOS prompts the user to approve permissions: 1. **Screen Recording prompt** appears 2. User selects **Allow** 3. User may be directed to **System Settings → Privacy & Security** 4. User enables Splashtop for Screen Recording 5. A restart of the Splashtop Streamer may be required If the Microphone is used, a separate prompt appears when audio is first requested. If a prompt is dismissed, permissions can be enabled manually: **System Settings → Privacy & Security → Screen Recording / Microphone / Accessibility** Until Screen Recording and Accessibility are approved: - Sessions may launch - The Splashtop RMM App may appear **blank or non-interactive** ## Starting a Remote Control Session 1. Open the **Device Details** page 2. Select **Remote Control** Session behavior (prompted or unprompted) depends on the configured **End-user consent** setting. If all requirements are met: - Splashtop RMM App launches immediately - Session begins If something is missing: - The **Streamer Status modal** explains what failed - Install or retry options are provided ### If your session doesn't connect If the Splashtop Streamer is installed and registered but the session fails to start, use Check Firewall from the Remote Control section on the Device Details page. Check firewall verifies that the device can reach required Splashtop and Automox services and is the fastest way to identify firewall or network-related issues. ## Understanding the Remote Control Section The Remote Control section on the Device Details page is organized into four areas to make it easier to understand readiness, available actions, and configuration. - **Tier** – Indicates which Remote Control tier is enabled for the device (Core or Automox Resolve powered by Splashtop). - **Status** – Shows whether the Splashtop Streamer is installed and registered. - **Actions** – One-time operations such as installing or uninstalling the Streamer, ending active sessions, running a firewall check, or viewing the Splashtop RMM App links. - **Settings** – Persistent configuration options that control Remote Control behavior, including end-user consent. ## End-User Consent Behavior Remote Control consent is controlled by the **End-user Consent** setting, in the Settings area of the Remote Control section, on the **Device Details** page. Only **full administrators** or custom roles with the**Remote Control Consent: Manage** permission can modify consent behavior. The End-user consent setting allows administrators to control whether a user must approve a remote session — and what happens if the user does not respond. ### Available End-User Consent Options - Required (attended) The user must approve the session before it begins. - Not required (unattended) The session starts immediately with no end-user prompt. - Required — if user doesn't respond, deny If the user does not click Allow within 30 seconds, the session fails. - Required — if user doesn't respond, allow If the user does not respond within 30 seconds, the session starts automatically. The default setting is **Required (attended)**. Remote Control behavior may vary depending on how End-user consent is configured. Administrators can choose between attended, unattended, or timeout-based approval behavior to balance security, compliance, and operational flexibility. ### Change Consent Behavior 1. Open **Device Details** 2. Open the **Remote Control** section 3. In **Settings**, select the desired **End-user consent** option 4. Click **Save settings** to apply the change Changes are not applied until Save is clicked. Bulk updates are available via **Devices → Actions → Configure Remote Control**. ## Using the Remote Session in the Splashtop RMM App When the session begins, the **Splashtop RMM App** displays the remote desktop and a navigation bar with session controls. ### Splashtop Session Controls (Quick Reference) **Note:** You can hover over the icons to identify the control. --- # Automox Remote Control with Splashtop – Full User Guide _Section: Product Documentation › Remote Control Module • Source: https://docs.automox.com/product/Content/Product%20Documentation/Remote%20Control%20Module/Splashtop%20User%20Guide.htm_ ## Remote Control Overview Automox Remote Control with Splashtop enables IT teams to securely connect to managed devices directly from the Automox console . Remote Control can be used for troubleshooting, maintenance, patching support, and real-time assistance, without requiring separate logins or external tools. All remote sessions: - Are initiated from within Automox - Use encrypted connections - Respect Automox role‑based permissions - Generate audit trail events for accountability and compliance Remote Control with Splashtop replaces Automox’s legacy Remote Control solution and introduces improved performance, reliability, and enterprise-grade security. The Remote Control section on a device is organized to separate entitlement, device readiness, available actions, and configuration settings related to Remote Control. ### Available Versions Automox offers Remote Control in two tiers: **Remote Control (Core)** Included with Automate Enterprise. Provides secure remote desktop access, interactive control, view‑only mode, sound redirection, and the ability to switch between monitors on multi-monitor remote devices. **Automox Resolve, powered by Splashtop (Premium)** An optional add-on that extends Core functionality with advanced features such as file transfer, chat, multi-monitor support (including viewing all monitors simultaneously in a single window), session recording, remote print, and concurrent technician sessions. **Prerequisites:** Before you begin, confirm the following prerequisites are met: - **Required permissions:** You have one of the following roles to adjust end-user consent behavior: full administrator or a custom role with the **Remote Control Consent: Manage** permission. You must also have the **Device: Control** permission to conduct sessions. **Note:** The **Device: Control** permission is required, not only to start Remote Control sessions, but also to install the Splashtop Streamer on individual devices from the Device Details page. - **Automox agent version:** The device has agent version **2.4.33 or later** installed. - **Supported operating systems for the Splashtop RMM App (administrator device):** Windows and macOS. - **Supported OS for Streamer (remote device):** **Windows** (10–11, Server 2012–2022) and **macOS** 13 (Ventura) or later. **Note:** Linux Streamer support is planned for a future release. - For allowlisting and firewall requirements, see [Platform Firewall Allowlisting Rules](../Agents/Agent Requirements/Agent_Firewall_Allowlisting_Rules.htm) . ## How Remote Control Works Remote Control relies on a **viewer–agent architecture** built on Splashtop’s secure remote access technology and integrated directly into Automox. Two components are always involved in a session: ### Splashtop For RMM App The **Splashtop RMM App** is installed on the **administrator’s computer**. It is responsible for: - Launching remote sessions - Rendering the remote desktop - Providing session controls and advanced actions The Splashtop RMM App is installed **once per administrator device** and reused for all sessions. ### Splashtop Streamer The Streamer is installed on each **remote device** you control. It: - Registers the device with the Automox–Splashtop backend - Accepts incoming remote control requests - Enforces OS-level permissions on macOS A remote session cannot start unless **both the Splashtop RMM App and the Streamer are installed and registered.** ## Roles, Permissions, and Access Control Remote Control actions are governed by Automox’s role-based permission model. ### Starting Remote Sessions To initiate a remote session, a user must have **Device: Control** permission. Default roles with access: - Full Administrator - Helpdesk Operator - Organization Operator ### Managing End-User Consent Changing end-user consent behavior requires the **Remote Control Consent: Manage** permission. Default role: - Full Administrator ### Streamer Deployment Permissions Deployment actions are intentionally more restricted. - **Remote Control Deployment: Manage** Allows org‑wide install / uninstall, group‑wide install / uninstall, ad hoc install / uninstall of selected devices from the RC Settings device table, and Auto‑Install configuration. Default role: Full Administrator. - **Remote Control Actions: Manage (device)** Allows installing or uninstalling the Splashtop Streamer on a single device from the Device Details page. Default roles: Full Administrator, Helpdesk Operator, Organization Operator. - **Remote Control Deployment: Read** Allows viewing Remote Control Settings, including the deployment health summary, device table, Auto‑Install toggle state, and the Remote Control section on Device Details. Default roles: Full Administrator, Helpdesk Operator, Organization Operator. ### Remote Control Settings (Organization-Level) Automox includes a dedicated **Remote Control** section in the organization-level **Settings** menu. This section centralizes configuration and deployment controls related to Remote Control with Splashtop. The **Settings → Remote Control** page serves as both a **monitoring surface** for Remote Control deployment health and an **action surface** for managing Remote Control availability across the organization. ### Deployment Health Summary The top of the RC Settings page displays high-level deployment metrics that represent current Remote Control readiness across the organization. Each device belongs to exactly one of the following statuses: - **Ready** — Streamer is installed and successfully registered. The device is eligible for Remote Control sessions. - **Failed** — A previous install or registration attempt did not complete successfully. Remote Control is unavailable until remediation. - **Not Installed** — Streamer is not installed or registered. No install attempt has been made. Status counts show the number of devices in each category relative to the total device count. Note: Linux devices always appear in the Not Installed status until Linux support is introduced. Org‑wide or group‑wide actions that include Linux devices do not execute commands on those devices. ### Device Table The RC Settings page includes a device table that provides device-level visibility into Streamer deployment state. The table is consistent with device tables elsewhere in the Automox console. **Columns:** - Device Name (click to navigate to Device Details) - Operating System - Group - Streamer Status (Ready, Failed, Not Installed) - Last Install Attempt (timestamp) - Last Result Returned (timestamp) **Table behavior:** - Paginated results (default 25 devices, up to 500) - Sorting on all columns - Column visibility and ordering customization - Row selection for bulk actions (ad hoc install / uninstall) **Note:** Data displayed in the device table may be up to 15 minutes old. ### Filtering and Search Admins can filter the device table by: - Operating System - Group - Streamer Status Admins can also search by Device Name. ### What You Can Manage from Settings → Remote Control The Remote Control settings page includes the following capabilities: - **Deployment health monitoring** - View Ready, Failed, and Not Installed device counts at a glance - Drill into the device table to identify specific devices - **Organization-wide Splashtop Streamer installation and uninstallation** - Install the Streamer across all eligible devices in the organization - Uninstall the Streamer from all devices - **Group-level Splashtop Streamer installation and uninstallation** - Install or uninstall the Streamer for devices in specific groups - **Ad hoc Streamer installation and uninstallation** - Select individual devices from the device table and install or uninstall the Streamer on those devices - **Default behavior for new devices** - Enable or disable **Auto-Install for New Devices** - Define whether newly added devices automatically receive the Streamer - **Visibility and governance** - Centralized location for Remote Control–related bulk actions - Controlled by dedicated Remote Control Deployment permissions Actions taken from this page are recorded in the audit trail. ## Understanding the Remote Control Section (Device Details) The **Remote Control** section on the Device Details page is designed to separate entitlement, device readiness, available actions, and configuration settings related to Remote Control with Splashtop. This section is organized into four areas: **Tier** Indicates which Remote Control tier is enabled for the device: - **Core** - **Automox Resolve powered by Splashtop** The tier determines which Remote Control features are available during a session. **Status** Shows whether the device is ready for Remote Control by indicating: - Whether the Splashtop Streamer is installed - Whether the Streamer is registered with Automox A device must be both installed and registered before a Remote Control session can begin. **Actions** Provides one-time operations that take effect immediately, such as: - Installing or uninstalling the Splashtop Streamer - Ending active Remote Control sessions - Running a firewall connectivity check - Accessing Splashtop RMM App download links **Settings** Contains persistent configuration options that control Remote Control behavior for the device, including end-user consent requirements. ## Installing the "Splashtop For RMM" App Before starting a remote session, administrators must install the "Splashtop For RMM" App (Splashtop RMM App). ### Installation Flow 1. Navigate to a device’s **Device Details** page in Automox 2. Select **Remote Control** 3. The first time you attempt to use Remote Control—and on every attempt until you confirm—the console will display a prompt asking whether you have already installed the Splashtop RMM App. - Select **No** to open a window with download links for Windows and macOS. - Install the app, then return to the console. 4. Once the **Splashtop RMM App** is installed, click **Remote Control** again and select **Yes** when prompted. - After you click **Yes**, Automox records that confirmation, and you do not see the prompt again on future Remote Control attempts from that same administrator device. The Splashtop RMM App only needs to be installed once per administrator device. ## Installing the Splashtop Streamer on Devices Unlike the **Splashtop RMM App**, the Streamer must be installed on **every device you want to control**. The Streamer is **not installed automatically when you click Remote Control.** Administrators can install the Streamer using any of the following methods depending on the desired scope. ### Organization‑Wide Installation Administrators with the **Remote Control Deployment: Manage** permission can install the Streamer across the entire organization. 1. Navigate to **Settings → Remote Control** 2. Select **Install Streamer** and select **By Organization** 3. A confirmation modal displays the organization name and total number of devices. Click **Install to Organization** to confirm. What happens next: - Online devices begin installing immediately - Offline devices install automatically when they next check in ### Group‑Level Installation Administrators with the **Remote Control Deployment: Manage** permission can scope Streamer installation to specific groups. 1. Navigate to **Settings → Remote Control** 2. Click **Install Streamer** and select **By Groups** 3. Select one or more groups from the group picker 4. Click **Install to (N) Groups** to confirm What happens next: - Automox sends a silent install command to all supported devices in the selected groups - Online devices begin installing immediately - Offline devices install automatically when they next check in **Note:** Group-level install is a one-time action applied to devices currently in the selected groups. It does not auto-install on future devices added to those groups. ### Ad Hoc Installation from RC Settings Administrators with the **Remote Control Deployment: Manage** permission can install the Streamer on specific devices selected from the device table. 1. Navigate to **Settings → Remote Control** 2. Use filters or search to locate target devices in the device table 3. Select one or more devices using the row checkboxes 4. Click **Actions** and select **Install Streamer** This method is useful for targeted remediation — for example, retrying installation on specific devices that previously failed. ### Per‑Device Installation For targeted deployment or troubleshooting. **Permission requirement:** Per-device Streamer installation requires the Remote Control Actions: manage (device) permission (or **Device: Control**). Users without this permission can view status but cannot install the Streamer. 1. Open **Device Details** for a specific device 2. Expand the **Remote Control** section 3. Select **Install Splashtop Streamer** ### Installation Behavior by OS - **Windows:** Fully silent - **macOS:** Application installs silently, but user approval is required for permissions If installation or registration fails, Automox displays a **Streamer Status** modal with error details and retry options. #### How Is the Splashtop Streamer Installed on Windows? The Splashtop Streamer is installed **system-wide** on Windows devices — not under the currently logged-in user's profile. It runs as a **Windows service** executed by the SYSTEM account. This means: - The Streamer is available before any user logs in (including the Windows login screen) - No per-user installation or configuration is required - The service starts automatically and persists across reboots and user account changes ### Action Ordering No hierarchy exists between organization-level, group-level, and ad hoc actions. The most recent action executed against a device determines its final state. If multiple actions are queued, they run in the order received. ### Splashtop Streamer Status: Installation and Registration Visibility When a device does not have the Splashtop Streamer **installed**, **registered**, or **successfully configured**, Automox provides clear visibility through the **Splashtop Streamer Status** modal and the **Remote Control** section on the Device Details page. These views help administrators understand *why* a remote session cannot start and what actions are available to resolve the issue. ### When the Splashtop Streamer Status Modal Appears The **Splashtop Streamer Status** modal opens automatically when you click **Remote Control** and the device is not ready for a session. This can occur when: - The Splashtop Streamer has **not been installed** - The Streamer is installed but **not registered** - A previous install or registration attempt **failed** - The device has not yet completed a pending install or registration In these cases, Automox blocks session launch and surfaces the Streamer Status instead. ### What the Streamer Status Modal Shows The modal provides real-time status for the device, including: - Whether the Splashtop Streamer is **installed** - Whether the Streamer is **registered** with Automox - Any **errors or failures** returned during installation or registration - Detailed error output when an installation attempt fails This information allows administrators to quickly distinguish between a device that has never had the Streamer installed and one that failed during a previous attempt. ### Actions Available from the Streamer Status Modal From the Splashtop Streamer Status modal, administrators can take action to bring the device into a state where Remote Control can be initiated. The modal includes a single **Install** action, which is used in all cases where the device is not yet ready for Remote Control. This includes first-time installs as well as situations where a previous install or registration attempt did not complete successfully. When selected, Automox attempts to ensure the device is fully prepared for Remote Control by: - Installing the Splashtop Streamer if it is not already present on the device - Registering the device with the Automox–Splashtop backend once the Streamer is installed Selecting **Install** always attempts to move the device into a fully installed and registered state. If the attempt fails, the modal displays detailed error information to help diagnose the issue before trying again. Once a Remote Control install or uninstall action has been sent to a device, it cannot be canceled. If multiple actions are queued, they run in the order received. ### Remote Control Section on the Device Details Page The Remote Control section on the Device Details page provides a real-time view of a device's readiness and the actions available based on its current state. Administrators can use this section to troubleshoot, deploy, or manage Remote Control without attempting to start a session. #### Device Not Ready When a device is not ready for Remote Control, the section indicates whether: - The Splashtop Streamer is not installed, or - The Streamer is installed but not registered In this state, Remote Control sessions cannot be initiated. Available actions may include: - **Install Splashtop Streamer** - **Splashtop RMM App links** - **Check Firewall Connectivity** Selecting **Install** always attempts to move the device into a fully installed and registered state. This applies to first-time installs as well as retrying failed installation or registration attempts. #### Device Ready When both installation and registration are complete, the device is marked as ready for Remote Control. In this state, administrators can: - Start a Remote Control session - End active sessions - Uninstall the Splashtop Streamer - Check Firewall Connectivity - Access Splashtop RMM App links - Adjust Remote Control settings, such as end-user consent This section provides a persistent way to review readiness, take corrective action, and manage Remote Control behavior without launching a session. ### Auto-Install for New Devices Automox provides an organization-level setting that controls whether the Splashtop Streamer is **automatically installed on newly added devices.** This setting is managed from **Settings → Remote Control** and defines the **default installation behavior for new devices.** **Default State** - **OFF by default** for all new customers - Newly added devices **do not** receive the Splashtop Streamer automatically This default ensures administrators maintain explicit control over where Remote Control is enabled. ### What the Auto-Install Toggle Controls When **Auto-Install for New Devices** is turned **ON**, Automox automatically installs the Splashtop Streamer on any *newly added* device that meets **all** the following conditions: - The device belongs to the organization - The organization has Remote Control entitlement - The device is not blocked by organization-level preferences **Important:** This setting applies **only to devices added after the toggle is enabled**. Existing devices are not affected. ### Enabling Auto-Install for New Devices To enable automatic installation for future devices: 1. Navigate to **Settings → Remote Control** 2. Locate **Auto-Install for New Devices** 3. Toggle the setting to **ON** Once enabled, this setting remains in effect until it is turned off. ### Installing the Streamer on Existing Devices Auto-Install does not retroactively install the Splashtop Streamer on devices that already exist in the organization. To install the Streamer on existing devices, administrators must use one of the supported manual methods: - **Organization-wide installation** from **Settings → Remote Control→ Install Streamer → By Organization** - **Group-level installation** from **Settings → Remote Control → Install Streamer → By Groups** - **Ad hoc installation** by selecting devices from the device table on **Settings → Remote Control** and choosing Install Streamer from the Actions menu - **Per-device installation** from the **Remote Control** section on the Device Details page These installation options are described earlier in this guide. ## macOS Permissions and End‑User Experience Before a Remote Control session can display or control the screen for macOS end devices, the end user must grant macOS permissions when the Splashtop Streamer is first installed. Remote Control permissions on macOS are granted **per logged-in user**, not per device. End users must enter their password to approve required permissions, but **administrator privileges are not required**. The user sees a Getting Started prompt asking them to enable the following permissions in **System Settings → Privacy & Security**: | Permission | Purpose | | --- | --- | | Accessibility | Allows remote input and control. | | Remote Desktop | Reduces repeated prompts and improves session behavior. | | Screen Recording | Allows the administrator to view the screen. | | Microphone | Required when audio features are used. (Optional) | | Full Disk Access | Full Disk Access is required to transfer files from the remote device back to the Splashtop RMM App. Full Disk Access is not required to transfer files from the Splashtop RMM App to the remote device. | ![](../../Resources/Images/Group 428.png) ![](../../Resources/Images/macos-permissions-2%20(1).png) ### How the End User Grants Permissions (macOS) 1. On the end-user Mac, open **System Settings → Privacy & Security**. 2. Select each category: - Accessibility - Screen Recording / Remote Desktop * macOS may show either Screen Recording Remote Desktop depending on your OS version. These labels refer to the same screen-visibility permission. **If you see "Remote Desktop," always enable that option**. If you do not see Remote Desktop, enable **Screen Recording** instead. - Microphone (Optional) - Full Disk Access (Optional) 3. Locate Splashtop Streamer and toggle permissions on. 4. Restart the Splashtop Streamer when prompted. - When all required permissions are enabled, the device is ready for Remote Control. - If any permission is denied initially, macOS continues prompting until the user updates the setting. **Tip:** End users can reopen the Getting Started prompt at any time by clicking the orange info (i) icon in the Streamer window. ### What IT Can Pre‑Configure Using MDM tools such as Jamf or Intune, IT administrators can: - Pre‑approve Accessibility - Pre‑approve Full Disk Access - Configure Screen Recording / Remote Desktop so standard users can approve without admin rights Apple does not allow Screen Recording or Microphone access to be granted silently. ## Starting and Managing Remote Sessions When the Splashtop RMM App and Streamer are installed and registered, you can connect instantly. ### Starting a session 1. In the Automox console, select the Device Details page of the device you want to start a session for. 2. Click **Remote Control**. 3. If all requirements are met, the Splashtop **Splashtop RMM App** launches automatically. Session behavior depends on the configured End-user consent setting. ### During the session - You’ll have full keyboard, mouse, and display control (once permissions are granted). - Session traffic is fully encrypted. - If the user moves their mouse or interacts during the session, control is shared. ### Ending a session - To end a session, close the session window. - You can also select Disconnect in the navigation bar. **Note:** If a session crashes or disconnects unexpectedly, Automox automatically clears the lock within 24 hours. You can also manually clear session locks by clicking **Clear Session** in the Splashtop Status modal. ## Managing End-User Consent End-user consent controls whether a user at the device must approve a Remote Control session before it starts — and what happens if the user does not respond. Consent is configured per device from the **Settings** area of the Remote Control section on the Device Details page. **Prerequisites:** Only full administrators and custom roles with **Remote Control Consent: Manage** can change these settings. ### End-User Consent Options Administrators can choose from the following End-user consent options: - Required (attended) – User must approve before the session starts. - Not required (unattended) – Session starts immediately with no user prompt. - Required — if user doesn't respond, deny – Session fails after 30 seconds. - Required — if user doesn't respond, allow – Session starts after 30 seconds * If no user is logged in to the device, consent prompts are not shown and the session starts automatically. . The default setting is **Required (attended)**. ### Choosing the Right End-User Consent Setting - **Required (attended)** Best for environments where transparency is required or devices are user-owned. Ensures the end user is aware of and approves every session. - **Not required (unattended)** Recommended for servers, kiosks, or shared devices where no user is expected to be present. Enables faster remediation but should be restricted to trusted admin roles. - **Required — if user doesn't respond, deny** Useful in high-security environments where unattended access is not permitted under any circumstances. - **Required — if user doesn't respond, allow** Common in IT support scenarios where users may be temporarily away, but assistance is still required without manual follow-up. ### Changing End-User Consent for a Single Device 1. Open **Device Details**. 2. Expand **Remote Control**. 3. In **Settings**, select the desired **End-user consent** option. 4. Click **Save** settings to apply the change. ### Bulk Updating End-User Consent End-user consent can also be updated across multiple devices. 1. Navigate to **Devices**. 2. Select one or more devices. 3. Select **Actions → Configure Remote Control**. 4. Choose the desired **End-user consent** option and apply the setting. End-User Consent Options Summary | Consent Option | User Prompt | Session Behavior | Common use cases | | --- | --- | --- | --- | | Required (attended) | User must actively approve the session before it starts. | Session does not start until the user clicks Approve. | End-user devices, BYOD environments, regulated industries, or any scenario where user awareness and approval are required. | | Not required (unattended) | No prompt is shown to the user. | Session starts immediately. | Servers, kiosks, shared devices, or environments where no user is expected to be present. Often used for remediation and maintenance workflows. | | Required — if user doesn't respond, deny | User is prompted to approve the session. | If the user does not respond within 30 seconds, the session fails. | High-security environments where unattended access is never allowed and explicit approval is mandatory. | | Required — if user doesn't respond, allow | User is prompted to approve the session. | If the user does not respond within 30 seconds, the session starts automatically. | IT support scenarios where users may be temporarily away but assistance is still required without manual rescheduling. | ## Remote Session Controls This table provides an overview of the controls available in the Splashtop navigation bar. **Note:** You can hover over the icons to identify the control. --- # macOS MDM Configurations for Splashtop _Section: Product Documentation › Remote Control Module • Source: https://docs.automox.com/product/Content/Product%20Documentation/Remote%20Control%20Module/macOS%20MDM%20Splashtop.htm_ Use this documentation to create configuration profiles for your Jamf Pro or Intune MDMs to work with Splashtop Remote Control. **Prerequisites:** The following files are required to configure Intune or Jamf for Splashtop: Intune: [XML configuration](https://github.com/AutomoxCommunity/se-utilities-public/tree/main/integrations/Splashtop-MDM-Allowlisting-Automox/xml) Jamf: [.mobileconfig](https://github.com/AutomoxCommunity/se-utilities-public/tree/main/integrations/Splashtop-MDM-Allowlisting-Automox/mobileconfig) files - Jamf Pro - Intune ## macOS: Creating the Splashtop Configuration Profile for Jamf Pro This document provides guidance for how-to create the macOS `.mobileconfig` Configuration Profile for use in Jamf Pro. The profile configuration maintains required settings by 'locking' configurations from user manipulation. Once deployed, you may scope the profile globally to your Jamf-managed fleet without concerns of configuration drift. **Prerequisites:** - **Jamf Pro Full Admin** access - Or an account with **Mobile Devices** and **Mobile Device Configuration Profiles** privileges. ### Splashtop Remote Configuration Profile Setup **Note: If you wish you create the Profile manually, select "New" and input the following steps manually.** 1. Login in your Jamf Pro instance and navigate to **Computers → Content Management → Configuration Profiles** and select **Upload**. 2. In the window that appears, select **Choose File** and then select the downloaded [.mobileconfig](https://github.com/AutomoxCommunity/se-utilities-public/tree/main/integrations/Splashtop-MDM-Allowlisting-Automox) file. 3. Next, select **Upload**. Navigate to the **General Tab** and update the **Name, Description, or Category** as needed. **Do not change Level or Distribution Method.** ![](../../Resources/Images/ST-Jamf-1.png) 4. Navigate to the **Privacy Preferences Policy Control** tab and verify the fields are correct: - **Identifier:** com.splashtop.Splashtop-Streamer - **Code Requirement:** identifier "com.splashtop.Splashtop-Streamer" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = CPQQ3AW49Y - **Accessibility:** Allow - **SystemPolicySysAdminFiles:** Allow - **ScreenCapture:** Allow standard users to allow access - **SystemPolicyAllFiles:** Allow 5. Under **Scope** assign relevant Groups. ![](../../Resources/Images/ST-Jamf-3.png) 6. Click **Save**. ## macOS: Creating the Splashtop Configuration Profile for Intune MDM This document provides guidance for how to create the macOS `.mobileconfig` Configuration Profile for use in the Microsoft Intune MDM. The profile configuration maintains client required settings by 'locking' configurations from user manipulation. Once deployed, you may scope the profile globally to your Intune-managed fleet without concerns of configuration drift. **Prerequisites:** - **Intune Pro Full Admin** access - Or an account with **macOS** and **Configuration Profiles write-ability** privileges. ### Importing the Splashtop Remote Configuration Profile into Microsoft Intune Import the [necessary profile](https://github.com/AutomoxCommunity/se-utilities-public/tree/main/integrations/Splashtop-MDM-Allowlisting-Automox) via .XML configuration, `.mobileconfig`, for Automox's remote control capabilities with Splashtop. **To create new / import the configuration:** 1. Go to Microsoft Endpoint Manager admin center and navigate to **Devices → MacOS → Configuration** under **Manage Devices**. 2. Click on **Create →** click **New policy**: ![](../../Resources/Images/ST-Intune-1.png) 3. As a **profile type**, select **Templates**. ![](../../Resources/Images/ST-Intune-2.png) 4. For the **template name**, select **Custom**. ![](../../Resources/Images/ST-Intune-3.png) 5. After clicking **Create**, you see the following **Custom** profile creation window. ![](../../Resources/Images/ST-Intune-4.png) 6. Enter the name **Automox - Splashtop Mobile Config (Full Disk Access)** with a description of **The Automox Remote Control feature requires Full Disk Access to function properly. If not deployed, the user must manually allow permissions.** **Note: Deploy these settings as tamper-protection controls.** ![](../../Resources/Images/ST-Intune-5.png) Click **Next** to proceed to the configuration profile file upload. 7. Under custom configuration profile name type in the Name of the profile as before, **Automox - Splashtop Mobile Config (Full Disk Access)** ![](../../Resources/Images/ST-Intune-config.png) Using the xml profile **Automox - Splashtop Mobile Config - (Full Disk Access)** click **Next** to finalize ingestion of the configuration. ![](../../Resources/Images/ST-Intune-6.png) 8. Navigate to the imported profile body and verify the fields are correct: - **Identifier:** com.splashtop.Splashtop-Streamer - **Code Requirement:** identifier "com.splashtop.Splashtop-Streamer" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = CPQQ3AW49Y - **Accessibility:** Allow - **SystemPolicySysAdminFiles:** Allow - **ScreenCapture:** Allow standard users to allow access - **SystemPolicyAllFiles:** Allow 9. To deploy, set Group assignment to include macOS **users** and macOS **device groups**, → click **Next** to finalize and to go-live with the released configuration. ![](../../Resources/Images/ST-Intune-7.png) 10. Once you click **Create**, the profile will be **saved** to Intune. - Additionally, if you have previously saved the profile and are reaching deployment, you click **Review + Save**. --- # Automox Script Signing _Section: Product Documentation › Script Signing • Source: https://docs.automox.com/product/Content/Product%20Documentation/Script%20Signing/Automox_Script_Signing.htm_ Automox Automox Script Signing currently works with PowerShell scripts (Worklets) and Automox system scripts. --- # Script Signing FAQs _Section: Product Documentation › Script Signing • Source: https://docs.automox.com/product/Content/Product%20Documentation/Script%20Signing/Script_Signing_FAQs.htm_ ### Basics | Question | Answer | | --- | --- | | Who can opt in to Script Signing? | Global Administrators and Organization Administrators can opt-in to Script Signing. | | What plans include Script Signing? | All Automox pricing plans include Script Signing. | ### Certificate Management, Distribution, and Auditing | Question | Answer | | --- | --- | | How are the signing certificates managed? | Automox manages certificate creation, history, and roll back (if needed). | | What are the specifications of the signing certificates? | Certificates are self-signed, with RSA 2048 bit encryption and SHA 256 hash key. The private key is stored encrypted. | | How often are the certificates renewed and rotated? | Automox renews and rotates the certificates annually. | | How are the certificates distributed to my Automox devices? | Once you have opted-in and set the signing policy for your organizations, the certificates are distributed to the devices via a system script that is triggered by device scan. | | Is there an audit trail? | There is internal auditing data, to track who did what, where and when. | | What should I do if a certificate has been compromised? | Contact Automox Support if you are having trouble manually installing the certificate, resigning scripts, and removing the old certificate. | | What should I do if a certificate has been tampered with or removed? | The certificate can be uninstalled by an end user, script, or other service. If the device is using an elevated execution policy when this happens, scripts might not execute on the compromised device. If the device is in Default (Bypass): No impact to script execution.The certificate will be reinstalled during the next device scan, with no impact to running scripts. If the device is in AllSigned or RemoteSigned: Script execution will be impacted.Manually revert the device to Default (Bypass), wait for the scan to reinstall the certificate, then return device to RemoteSigned or AllSigned execution policy.Or, you can leave the device in an elevated state, copy the certificate from another device, and manually install the certificate on the affected device. | If the Automox --- # Billing _Section: Product Documentation › Settings • Source: https://docs.automox.com/product/Content/Product%20Documentation/Settings/Billing.htm_ You can view and manage your Automox subscription from the **Settings → Billing** tab. From here, you can select or update a plan, review contract terms, adjust the number of licenses, and manage billing information. ## Billing Details From the **Settings → Billing** tab, you can manage the billing for your organization. You can access the Settings menu at the top of your console. ## Device Usage **Note:** Up to 2 years of Device Usage data is shown. Contact [Invoices](mailto:invoices@automox.com?subject=Device Usage / Invoice Question) with any questions or concerns about device usage or invoices. You can view and track your device usage. This reflects the number of currently installed devices. Add or remove the Automox agent from devices to adjust your total device count. Your total device count is updated hourly and any changes are summarized in the Device Usage table at the end of each day. If your installed device count reaches or exceeds your available device licenses, an alert is displayed so that you can take action, if necessary. To learn more about how device usage affects billing, refer to the [https://help.automox.com/hc/en-us/articles/13539137262996-Simplified-Billing-Process-FAQ](https://help.automox.com/hc/en-us/articles/13539137262996-Simplified-Billing-Process-FAQ)[Customer Billing FAQ](https://help.automox.com/hc/en-us/articles/31573564826516-Customer-Billing-FAQ-Page). ![](../../Resources/Images/Endpoint_Usage_large.png) ## Billing History You can view invoice history. The following information is shown: - **Invoice**: The invoice name. - **Date**: The date the invoice was billed. - **Paid**: The payment status. - **Total**: The invoice total. - **Download**: Download a PDF copy of the invoice. ![](../../Resources/Images/billing-history.png) ## Your Automox Plan and Payment This section shows details about your plan, contract term, number of licenses, and related options. Use these settings to confirm what is active for your organization. ### Plan Information The Select a plan section shows which plan your organization is currently using and displays the other available plan options next to it. You can change your plan. - If you have questions about upgrading your plan or available modules, contact Automox at [sales@automox.com](mailto:support@automox.com). - To save any changes, click **Update Billing**. ### Contract Term This section shows whether your plan is set to Annual or Monthly. The selected option is highlighted here. ### Number of Licenses You can view and change the number of devices licensed under your plan. The following information applies to **annual** contracts: - **Number of licenses**: The total device licenses purchased for your organization. - **Billing**: Your monthly bills during the term are based on your licensed device count. - **Increase licenses**: If you increase your license count, the added licenses are included in your remaining monthly bills for the contract term. - **Overages**: An overage is when the installed quantity of devices exceeds the number of licenses in your subscription. If you don’t increase your license count, any overages are billed at an overage rate for that month. - **Reducing licenses**: Reducing license count during the contract is not available. Contact [sales@automox.com](mailto:sales@automox.com) with any questions. ![](../../Resources/Images/License-Count.png) If your subscription is on a **monthly** contract, your subscription allows you to install the Automox agent on a specific number of devices. Automox uses the installed device count to bill you for the usage for the month. ### Feature Information The following are some of the features available. These depend on your selection of plan or customization. See also [Automox Pricing](https://www.automox.com/pricing). **Note**: To take advantage of Automox Worklets™, you must ensure that you are on a plan that includes Worklets. | Feature | Description | | --- | --- | | Multi-OS Patching | Automated patching for Windows, macOS, and Linux simplifies IT workflows and consolidates tools. | | Third-Party Software Patching | Automated patching–from detection to packaging to deployment–for 560+ third-party titles, including Adobe and Google Chrome. | | Software Management | Automatically install, update, or remove software across Windows, macOS, and Linux. | | Advanced Automation Features | Increase your control over high- availability devices with patch-level approval workflows before they're installed. | | Device Configuration | Automatically apply and enforce configurations to enforce consistent settings, meet corporate standards, and avoid drift. | | API Access | Generate customizable reports and take action on devices and policies with industry-standard documented APIs - all without accessing the console. | | Automox Worklet™ Automation Scripts | Choose from a catalog of over 360 automation scripts built and maintained by Automox for Windows, macOS, and Linux. | | Multi-Organization Management | Multi-tenant control to split your devices or customers to segregate responsibility and adopt least privilege. | | FixNow (RunNow) | Push automation scripts to Windows, macOS, and Linux at scale in seconds. Monitor your change with real-time progress reporting and drill-down. | | Reporting | Gain full device and software visibility and policy history with pre-configured and customizable reports to drive better decisions. | | Role-based Access Controls | Eliminate operational inefficiencies, mismanaged devices, and security gaps by defining appropriate user roles for your administrators. | | Two-factor Authentication | Leverage email or mobile two-factor authentication to validate identities and protect user credentials and your environment | | Single sign-on | Centralize identity controls, reduce password mismanagement, and simplify your team's login with SAML-based single sign-on. | ### Modules The **Learn more about available modules** section lists any add-on modules that are available. As an administrator, you can decide whether to enable these options. Contact Automox Sales with questions. ## Billing Information You can view and manage your company details. The following information is required: - Company Name - Country (If your country is not listed, contact [sales@automox.com](mailto:support@automox.com)) - Address - City - State (only required for US addresses) - Zip/Postal Code ## Payment Methods You can manage your credit card payment method from this page. You can only use one payment method at a time for your plan. Other options for payment, such as electronic transfer, are available as well. Please contact us about setting that up for you at [sales@automox.com](mailto:support@automox.com). 1. Select **Update** to edit your credit card information. 2. Select **Update Billing**. ## Related Topics - [Settings Overview](Settings_Overview.htm) - [Billing Policy for Agents on Virtual Instances](../Miscellaneous/Billing_Policy_for_Agents_on_Virtual_Instances.htm) - [Customer Billing FAQ](https://help.automox.com/hc/en-us/articles/31573564826516-Customer-Billing-FAQ-Page) --- # Managing Agent Configurations _Section: Product Documentation › Settings • Source: https://docs.automox.com/product/Content/Product%20Documentation/Settings/Managing%20Agent%20Configurations.htm_ You can configure and manage agent behavior directly within the Automox console. Go to **Settings → Agent** to view **Agent Configurations**. ![](../../Resources/Images/settings-agent-option.png) ## Agent Configurations From the **Agent Configurations** tab, you can view the number of devices in the organization and see which **agent release channel** is selected. You can enable automatic updates and choose whether devices should install the **Beta** or **Stable** agent release. ![](../../Resources/Images/settings-agent-tab.png) ### Agent Updates By default, agent updates install automatically. Use the **Automatic agent updates** toggle to enabled or disabled this behavior. - **On**: When enabled, the agent automatically installs the latest version available **based on the selected release channel** on all devices in this organization. (Default) - **Off**: When disabled, the agent remains on its current installed version and does not update automatically. ### Agent Release Channel Select the **agent release channel** your organization uses to control which version of the agent installs automatically when a new release becomes available. This setting applies to all devices in the organization. - **Beta**: Installs the **latest beta version** of the agent. Select this option for early access to new features and the opportunity to give feedback. **Note**: Beta releases also include the potential for minor issues. - **Stable**: Installs the **latest fully tested** version of the agent. (Default) ## Related Topics - [Settings Overview](Settings_Overview.htm) --- # Managing Organization Keys _Section: Product Documentation › Settings • Source: https://docs.automox.com/product/Content/Product%20Documentation/Settings/Managing_Keys.htm_ From the **Settings → Secrets & Keys** tab, you can view the **Account ID**, **Agent Access Key**, and manage **Organization API keys**. Organization API keys differ from global API keys in scope: - **Organization API keys**: Provide access only within a single organization. They are managed at the organization level and are useful when access should remain limited to one organization. - **Global API keys**: Provide access across all organizations in an account. They are managed at the global level and are useful for automation or integrations that need to span multiple organizations. **Prerequisites**: You must meet the following requirements before you can create or manage organization API keys: - You are a **Full Administrator** or have a custom role with **Organization**: **Read** and **Manage** permissions. - You have **Personal API Key: Manage** permission to create and manage your own keys. ![](../../Resources/Images/managing-keys.png) **Keep API Keys Secure!** API keys should be kept secure and not shared to prevent unforeseen changes or potential security issues. Never email or write down your API key. **API Keys and Permissions** API keys inherit the same permissions that the user has. For example, an API key belonging to a Full Administrator has the same permissions as in the console, and allows them to perform functions using the API that require Full Administrator permissions. ## Viewing Keys Go to **Settings → Secrets & Keys** to access the **Secrets Management** page. The following information is available on this page: - **Account ID**: The UUID for the account. The account name is listed with this ID. - **Agent Access Key**: Used to add devices to your Automox account. - **Organization API Keys**: The list of all API keys created for the current organization. This section appears further down the **Secrets Management** page. If multiple secrets are listed above it, you may need to scroll to see the **Add** button. How you view or interact with these keys depends on your permissions. See *[Organization API Key Permissions and Actions](#Organiza)* for details. Use the organization API key to access the [Automox API](https://developer.automox.com/). **Note**: Organization API keys are not automatically generated for new users or new organizations. See [Adding Organization API Keys](#AddingOrg). When you use API keys, follow best practices such as: - Do not embed API keys directly in code. - Do not store API keys in files inside your application’s source tree. ## Organization API Key Permissions and Actions Organization API keys inherit the creator’s role-based permissions **for this organization only**. They never grant access to other organizations, even if the user has roles elsewhere. What you can do with organization API keys depends on your assigned role and permissions. ![](../../Resources/Images/show-API-key.png) The following interactions are available from the Organization API Keys table, subject to your permissions: - To view (decrypt) an API key, click the **Show** button to the right of the hidden characters. The key automatically hides again after 10 seconds. - To copy an API key, click the **Copy** button (clipboard). The key is automatically decrypted when copied. ### Listing Organization API Keys You can list or view organization API keys if you have the correct permissions. - To list all organization API keys, you must have **All API Keys: Read** permission. - To view (decrypt) your own API key, you must have **Personal API Key: Manage** permission. ### Adding Organization API Keys You can create up to 10 organization API keys per user account. - To add an organization API key for yourself, you must have **Personal API Key: Manage** permission. Steps to add an organization API key: 1. Select **Add**. 2. Enter a unique name for the key. 3. (Optional) Select an expiration date. 4. Select **Create**. ### Enabling and Disabling Organization API Keys You can enable or disable organization API keys if you have the correct permissions. - To enable or disable API keys for **any listed user**, you must have **All API Keys: Modify** permission. - To enable or disable your own API key, you must have **Personal API Key: Manage** permission. **Note**: When an API key is disabled, the key is rejected and returns an error. Disabled keys can be re-enabled. ### Deleting Organization API Keys You can permanently delete organization API keys. - To delete API keys for **any listed user**, you must have **All API Keys: Delete** permission. - To delete your own API keys, you must have **Personal API Key: Manage** permission. **Note**: When an API key is deleted, all API requests using that key are rejected and return an error. ## Example Scenarios This table provides examples of what actions are available in the **Organization API Keys** table based on user role and assigned permissions. | Scenario | Permission | Decrypt | Enable/Disable | Delete | | --- | --- | --- | --- | --- | | User on their own key | Personal API Key: Manage | Yes | Yes | Yes | | Admin on another user’s key (Modify only) | All API Keys: Modify | No | Yes | No | | Admin on another user’s key (Delete only) | All API Keys: Delete | No | No | Yes | | Admin on another user’s key (Modify and Delete) | All API Keys: Modify and All API Keys: Delete | No | Yes | Yes | **Note**: Decrypt is always limited to the key owner. Administrators cannot decrypt another user’s key, even with All API Keys permissions. ## Related Topics - [Settings Overview](Settings_Overview.htm) - [Secrets Management](Secrets_Management.htm) - [Managing Global Keys](../Global Access Management/Managing Global Keys.htm) --- # Profile _Section: Product Documentation › Settings • Source: https://docs.automox.com/product/Content/Product%20Documentation/Settings/Profile.htm_ You can manage your profile and Slack notification settings from the Profile page. Select the **Settings → Profile** tab to manage the following details: - Make changes to your profile information, such as first and last name. - Change your password. - Manage email notifications. You can select to receive email notifications for the following: - Devices Added to Automox - Devices Removed from Automox - Devices Successfully Patched - Devices Failed to Patch - Weekly Digest of Automox Activity - Add Slack notifications. ### Slack app integration You can add a Slack integration to your workspace from the Automox console Profile page. This integration supports multiple organizations and must be configured within each respective organization. 1. Click the **Add to Slack** button. 2. Allow Automox permission to access your Slack workspace. 3. You can now manage the notifications from the Profile page. You can select to receive Slack notifications for the following: - Devices Added to Automox - Devices Removed from Automox - Devices Successfully Patched - Devices Failed to Patch 4. You can disable Slack directly from the Profile page. Select Disable Slack and click **Update Profile**. #### Slack slash commands Users can now leverage **slash commands** in Slack to interact with the Automox platform. The following commands are supported once the **@automox** bot is added to the desired channel: | Command | Description | Authentication Required? | Organization Required? | | --- | --- | --- | --- | | /automox help | Shows a help message with the available commands. | No | No | | /automox connect | Opens a new window to configure the Automox connection. | No | No | | /automox status | Checks connection health and notification status for an organization. | No | Yes | | /automox test | Sends a test notification in Slack. | No | Yes | | /automox stats | Shows Automox organization stats (for example, Device Count) | No | Yes | | /automox disconnect | Removes the Automox connection in Slack. | Yes | Yes | | /automox reconnect | Reconnects with Automox after potential Slack errors. | Yes | Yes | | /automox config | Displays current configuration details (Organization, Status, Enabled Alerts, Notification Channel) | Yes | Yes | **Note**: - Permissions for reading notifications in Slack are managed by Slack and not Automox. To add the Slack app you must have **Organization: Manage permissions**. - All users in your associated Slack channel receive notifications for the selected alerts, regardless of their permissions. ## Related Topics - [Settings Overview](Settings_Overview.htm) --- # Secrets Management _Section: Product Documentation › Settings • Source: https://docs.automox.com/product/Content/Product%20Documentation/Settings/Secrets_Management.htm_ With Automox Secrets Storage, you can securely store and retrieve secrets (passwords, API keys, etc.) so that you can use them to execute Worklet policies without them being stored or exposed in plain text to any user. Learn how to add, edit, and remove secrets, and associate them with Worklet policies. **Prerequisites**: - You must have the required permissions to perform this action. See [Roles and Permissions Management](../Global Access Management/Roles_and_Permissions.htm). - Your organization is under a plan that includes Worklets. **Note**: - Secrets are currently compatible with the worklet policies. - You can use secrets in both PowerShell and Bash scripts. ## Accessing Secrets Management You can add, edit, and delete secrets from the Secrets & Keys page. In the Automox console, go to **Settings** at the top of the console and select **Secrets & Keys**. For details about keys, refer to [Managing Keys](Managing_Keys.htm). ![](../../Resources/Images/secrets-overview.png) ## Adding a Secret You can add secrets to each of your organization **Note**: - The Secret Name must be unique. - The character limit is 255 characters. - The maximum number of secrets within an organization is 1000. - You can add a maximum of 8 secrets at the same time. A maximum of 10 secrets can be associated with a single policy. ![](../../Resources/Images/add-zone-secret.png) To add secrets, follow these steps: 1. From the Secrets Management page, click **Add Secret**. 2. Add an organization secret by entering a **Secret Name** and **Value** for the secret. These are required fields. - To check the value you entered, click the eye icon. 3. Optionally, you can add a description. 4. To add more secrets, click **+ Add Secret**and repeat the previous steps. 5. Click**Save Secrets**. ## Updating a Secret You can update secrets in any organization you have access to. **Note**: You cannot change the Secret Name after it is created. 1. From the Secrets Management page, find the secret you want to update. 2. Click **Edit**. 3. You can only modify the Description or the Value. 4. Click **Save**. ## Viewing Secrets The following information is available from the **Secrets Management** page. | Table Column | Column Description | | --- | --- | | Secret Name | The unique name for the secret you created. The character limit is 255. | | Description | Enter a description for the secret, but do not use the actual value of the secret. | | Date Updated | Date and time any changes to the description or value were last made. | | Associated Policies | Shows the number of associated policies. Click a number to view a list of associated policies, which allows you to link to a policy itself. | | Actions | You can select from these options: Edit: Click to edit the description or value. Delete: You can only delete the secret if it is not associated with a policy | ## Deleting a Secret Follow these steps to remove a secret from an organization. 1. From the Secrets Management page, find the secret you want to remove. 2. Click **Delete** to remove the secret. 3. If the secret has no associated policies, you can delete the secret in the dialog window that appears and it is removed from the list. 4. If the secret is associated with a policy, see [Deleting Secrets Associated With a Worklet Policy](#Deleting). ## Deleting Secrets Associated With a Worklet Policy This section describes how to delete a secret when it is referenced within a worklet policy. On the Secrets Management page, when a number is listed in the Associated Policies column, then the secret is associated with a worklet policy. This means that a worklet exists that uses an environmental variable in its code that references the secret. Refer to [Using Secrets in a Worklet Policy](#Using). ![](../../Resources/Images/secrets-assoc-policy.png) In this scenario, there are two options to delete a secret from the Secrets Management page. - Delete any variables from all policies that reference the secret. The policies remain intact. - Delete any policies that reference the secret, then delete the secret. 1. From the Secrets Management page, find the secret you want to remove. 2. Click **Delete** to remove the secret. 3. If the secret is associated with a worklet, a list of associated policies appears. ![](../../Resources/Images/policies-assoc.png) 4. You must remove any association with policies before you can delete the secret. Click the name of the policy to open the policy page. 5. Go to the list of **Inputs** where variables reference secrets within the policy. 6. Find the variable that references the secret that you want to remove and click delete (x). **Note**: Make sure to update any code that uses the variable. 7. Save the policy. 8. Repeat for each policy that the secret is associated with. 9. Return to the Secrets Management page. When there are no more policies associated with the secret, the number in the Associated Policies column shows 0. 10. Click **Delete** to remove the secret from the organization. ## Using Secrets in a Worklet Policy To securely use a secret within a worklet policy, you must add an environment variable that references the secret. This is done from the worklet policy page. Go to **Automate → Policies** to create or edit a worklet policy. ### Adding a Variable to a Worklet Policy This describes how to add variables to a worklet policy. ![](../../Resources/Images/worklet-inputs.png) 1. From the Create Worklet or Edit Worklet page, go to **Inputs**. 2. Click **Add Input**. 3. Enter a name in the **Variable Name** field to associate the secret with. - The variable name must contain at least 3 characters, must start with a letter, and only use alphanumeric characters or underscores (for example, api_key_1). 4. Click the **Select Organization Secret** drop-down menu to select an appropriate secret that you previously created on the Secrets Management page. 5. To add more variables, click **Add Input**. 6. Use the variable names in the code of your worklet. This variable references the secret, but never reveals the contents. 7. Make any other required changes to the worklet and save the policy. ### Editing Variables This describes how to edit variables that are part of a worklet policy. ![](../../Resources/Images/edit-variable.png) 1. From **Automate → Policies**, go to the worklet that you want to edit variables for. 2. From the list of **Inputs**, find the variable that you want to edit. 3. You can edit the Variable Name, as needed. - If you edit the variable name, ensure that the use of the variable in the code matches any changes that were made. 4. You can change the secret from the **Select Organization Secret**drop-down menu. - If you do not see the secret you want to use, you must create it from the Secrets Management page in the same organization where the worklet policy is. 5. After making any changes, save the policy. ### Mapping Variables to the Worklet Policy The following examples show how variables can be directly or indirectly mapped in a worklet policy. You can map variables into the code in two ways: **Mapping Variables Method 1:** You can reference input variables the same as any other Bash/Powershell variables by using the **$** sign. For example: **$CUSTOM_TOKEN** **Input selection:** ![](../../Resources/Images/example-var1.png) **Explicitly calling variables into the code using the $ sign:** ![](../../Resources/Images/var1-remcode.png) **Mapping Variables Method 2:** You can also use environment variables indirectly. For example, the AWS cli expects environment variables with credentials to already exist. The variables will be exported to Powershell/Bash without the need to reference them directly in the script by using the **$** sign. For example: **$VARIABLE_NAME**. **Input selection:** ![](../../Resources/Images/input-vars-example.png) **Explicitly calling variables into the code using the $ sign:** ![](../../Resources/Images/vars-remcode2.png) **Indirect call to the variables:** ![](../../Resources/Images/export-vars.png) ### Deleting Variables You can remove any variables from the worklet policy list of Inputs by clicking **x** to delete it. **Note**: If you delete a variable, ensure that it is not referenced in any script that is part of the worklet policy. ## Related Topics - [Settings Overview](Settings_Overview.htm) - [Managing Keys](Managing_Keys.htm) - [Automox University: Secrets Management](https://university.automox.com/secrets-management) --- # Security _Section: Product Documentation › Settings • Source: https://docs.automox.com/product/Content/Product%20Documentation/Settings/Security.htm_ You can manage security-related tasks for accounts and organizations from the **Settings → Security** page. ![](../../Resources/Images/security.png) ## Account The account refers to the individual user account. From the **Settings → Security** tab, you can configure authentication for your account. To access the account details, go to the Settings menu (**⋮**) in the console. **Note**: Email two-factor authentication is required by default. To access the console, you must use a form of two-factor authentication (email or mobile) or single sign-on. ### Two-factor Authentication: Email or Mobile Email two-factor authentication (2FA) is enabled by default. When you log in to the Automox console using your email address and password, you will also need to enter the verification code sent to your email address. You can select between email or mobile authentication from the **Account → Two-factor Authentication** section. - When you select **Mobile** from the Two-factor Authentication section, the next time you log in to the Automox console using your email address and password, you will also need to enter the verification code from the mobile app you are using. See the next section for details about setting up authentication using a mobile method. ### Enabling Mobile Two-factor Authentication You can enable mobile two-factor authentication (2FA) using Google Authenticator, Authy, or other mobile app. 1. Download a 2FA mobile app such as Google Authenticator or Authy. 2. Install the app and open it. 3. From the Automox console, go to Settings → Security and select **Mobile** from the Two-factor Authentication section. 4. From the Mobile Two-factor Authentication window, you must scan the QR code with your mobile device to pair it with the Automox console. 5. Enter the code that appears. Depending on the mobile app you are using, you might need to enter a second code. #### Resetting mobile two-factor authentication If you lose access to the mobile authentication method, contact your administrator to regain access to the user account. **Note**: Global Administrators cannot reset 2FA for other Global Administrators. For help, [submit a request](https://help.automox.com/hc/en-us/requests/new) in the Automox help center. ## Organizations Only Organization Administrators have permission to configure the following organization security settings: - Login Attempt Settings - SAML (single sign-on) ### Login Attempt Settings You can set the number of login attempts to the Automox platform that a user can make within a time frame before the account is locked. 1. Click **Update** to open the Login Attempts Configuration dialog box. 2. You can set the following: a. Enter the maximum number of login attempts a user can make within a set time frame. b. Enter a time frame in minutes. If the user exceeds the allowed number of login attempts during this time frame, the account is locked. 3. Click **Update.** In this example, the user can attempt to login 5 times within a time frame of 5 minutes. If the user exceeds the number of attempts within the 5-minute time frame, the account is locked. ![](../../Resources/Images/settings-security-loginattempts.png) --- # Settings Overview _Section: Product Documentation › Settings • Source: https://docs.automox.com/product/Content/Product%20Documentation/Settings/Settings_Overview.htm_ You can manage your profile, billing, email notifications, user accounts, secrets and keys (including your API key), script signing, and security settings from the Settings page. To access **Settings**, go to the menu in the upper right of the console. --- # User Accounts _Section: Product Documentation › Settings • Source: https://docs.automox.com/product/Content/Product%20Documentation/Settings/User_Accounts.htm_ Learn about managing all aspects of user accounts including managing two-factor authentication. This does not include global access management. For details about managing users and their organization **Note**: The default session timeout before a user must login again is 30 minutes. See also [Global Session Expiration Settings](../Global Access Management/Global_Session_Settings.htm). ## Accessing the User Accounts page To access **User Accounts**, open the **Settings** menu in the upper-right corner of the console. Click **Users**. The following options are available: - Add users to the organization - View details about a user account. - Export a CSV file containing details about the chosen users. - Remove existing users from an organization - Manage two-factor authentication settings for users. **Note**: If SSO is enabled, this option is not available. **Note**: If SSO is enabled, this option is not available. ![](../../Resources/Images/settings-user-accounts.png) ## Adding a User Account You can add a new user from the **User Accounts** page. **Prerequisites**: You must have **Users: Invite** permissions to add a user to an account. 1. Click **Add User**. 2. In the Add User window, enter the email address for the new user. 3. Select a role for the new user. Both default and custom roles appear in the list of available roles. **Note:**Full administrators or global roles assigned from here only have permissions within this organization 4. Click **Send Invitation**. **Note**: - A user who is new to the account receives an email invitation from Automox support that includes a link to create the account. - An existing user to the account does not receive an email. ## Viewing User Accounts The following information is available from the **User Accounts** page. The columns are not necessarily all shown by default. The columns are sortable. - Email address - First name - Last name - RBAC role - 2FA - Status - User ID (hidden by default) ### Showing All Columns of Data The default setting of the User Accounts table does not show all available columns. You can show more data or rearrange how the columns are presented. - Click the **Columns** button and select the checkboxes to show or hide columns. - You can rearrange the order of the data by dragging the columns to the desired position. ## Viewing Details for a User Account You can view user account information for each user and modify the user role. ![](../../Resources/Images/user-acct-info.png) 1. From the **User Accounts** page, click the email address of the user you want to view account information for. - In the dialog window, you can view information such as user name, email address, status, notification details. From here you can modify the role assignment. 2. Under **Roles**, you can assign a new user role from the **Assign Organization Roles** drop-down menu. These roles are only associated with the organization 3. Click the **x** next to the role name to remove any roles from the list. Updates are immediate. **Note**: You can **remove a user from all roles**. The user is then directed to a notification page alerting them to this. They will then need to contact their administrator to be assigned a new role. 4. Click **Update Account** to save any changes. ## Viewing Actions Click the **Actions** button to select from the following options. The following sections describe them. - Export User - Remove Users - Reset 2FA ### Exporting User Account Details You can export a CSV list of account details for a user or multiple users in your organization ![](../../Resources/Images/settings-export-users.png) 1. ‭From the **User Account**s page, select the users you want to export information for.‬ 2. Click‬‭ **Actions → Export Use**r.‬ 3. In the **Export Users** dialog box, select the data to export or clear the checkbox‬‭ to not include that information. The following data can be exported:‬ - ID‬ - ‬‭Email Address‬ - ‬‭First Name - Last Name‬ - RBAC Role‬ - 2FA‬ 4. Click‬‭ **Export User**‬‭. This action downloads a CSV file with the information you have selected. ### Removing a User Account You can remove a user from your organization **Note**: You **cannot** remove an **Account Administrator**or**Global (All Organizations) Administrator** role. 1. From the **User Accounts** page, select the checkbox for the user you want to remove. 2. Click **Actions → Remove User**. 3. In the Remove User window, click **Remove** to confirm. ### Resetting Two-factor Authentication (2FA) You can reset two-factor authentication for a user or multiple users. This could be necessary in the case that 2FA for mobile was enabled and the mobile device used for verification was lost. **Note**: This option is not available when SAML single sign-on (SSO) is **enabled**. SSO must be disabled for the organization to be able to reset 2FA. Resetting 2FA for a user defaults them to verification through email. See [Security](Security.htm) for more information. 1. From the **User Accounts** page, select the checkbox for the users you want to reset 2FA for. 2. Click **Actions → Reset 2FA**. 3. Click **Reset User**. ## Related Topics - [Settings Overview](Settings_Overview.htm) - [Roles and Permissions Management](../Global Access Management/Roles_and_Permissions.htm) - [Understanding Global Access Management](../Global Access Management/Understanding_Global_Access_Management.htm) - [Guidelines for Single Organization RBAC Management](../Global Access Management/Single_Org_RBAC_Guidelines.htm) --- # Filtering and Searching on the Software Page _Section: Product Documentation › Software • Source: https://docs.automox.com/product/Content/Product%20Documentation/Software/Filtering_and_Searching_on_the_Software_Page.htm_ From the **Automate → Software** page, you can view a complete list of all the software titles in your organization. Use the **Software filter panel** on the left to filter and display only those software titles that you are interested in seeing. The enhanced software search at the top allows you to narrow down that filtered data even more using a generalized search across multiple software fields. ![](../../Resources/Images/software-overview.png) **Note**: The search parameters you select are now stored in the page URL. The back button in your browser functions as expected and filter searches can now be bookmarked and shared. Data shown is refreshed every 15 minutes. ## Software Filter Panel The filter panel includes options to fine-tune your search. When you select any of the individual filters, a number in parentheses shows how many are selected. You can clear selections individually, or select **Clear All**. The panel can also be collapsed. These settings are saved in the URL. When you navigate to other pages and return to the page, your settings are maintained. ![](../../Resources/Images/software-filter.png) ## Automox Supported The **Automox Supported** filter is automatically selected by default. This shows software titles that Automox can patch. If you want to view a list of all software titles for your devices, clear the checkbox. You can also show only supported or only unsupported software titles. ![](../../Resources/Images/ax-supported-filter.png) ## OS You can set a filter to search for software by OS. All OS families are selected by default. 1. Select the **OS** drop-down menu. 2. Use the scroll bar on the right to find individual OS names. 3. To search only for certain OS types, click either the OS family checkbox, or individual OS types. 4. Use the search field to narrow down your search. ## Severity You can filter the list of software by severity. All severity levels are selected by default. See also [Understanding Automox Severity Data](../Patching/Understanding_Automox_Severity_Data.htm). 1. Select the **Severity** drop-down menu. 2. Click the severity type to narrow the search results. 3. The number at the top indicates how many filters are selected. ## Status The software **Status** filter allows you search for only ignored software packages. These packages are marked to ignore any updates available. ## Impacted You can filter the list to only show a software package when devices are impacted by this available patch. Click the highlighted number in the **Impacted** column to view a list of devices impacted by a specific software package. ## Days Exposed You can filter the software list by the number of days a package was made available in the Automox customer base. Multiple selections are allowed. ## Vulnerability or CVE ID You can filter the list of software by vulnerability or CVE ID. 1. Enter the exact term or ID you want search results for in the **Vulnerability or CVE ID** field. 2. You can enter multiple search items, which show results for anything they match. 3. To change your search, click **x** to remove the selected search term. 4. From the Severity column you can hover over the results and find links to details about the severity. ## Software Info You can filter the list of software by software title. This is a partial search of the **Software Name** column. You can enter multiple items or detailed items to fine-tune your search. ## Enhanced Software Search You can quickly narrow down data from the already filtered search by using the search bar at the top of the Software page. This enhanced search allows multiple queries and partial matching. **Note**: This search does not show results outside of the data obtained from the software filter panel. This searches across multiple fields: - Software Name - Version - OS (Family) - OS Version - Severity - CVE When you enter search criteria in the search bar, each entry appears as a tag below the search bar. To remove a query, click x. You can add as many search items as you want. The results will include data matching any of the search criteria. The following is an example of a multiple query, partial match search. ![](../../Resources/Images/software-search-bar.png) **Note**: For best results, use concise search terms. ## Related Topics - [Viewing Software Inventory](Viewing_Software_Inventory.htm) --- # Viewing Software Inventory _Section: Product Documentation › Software • Source: https://docs.automox.com/product/Content/Product%20Documentation/Software/Viewing_Software_Inventory.htm_ From the **Automate → Software** page, you can view and export details about the software associated with your devices. ![](../../Resources/Images/software-overview.png) The following information is available: | Software Table | Description | | --- | --- | | Software Name | Name of the available software. | | Version | Shows the current version of software installed. | | OS | Shows which operating system (Windows, macOS, Linux) this software is for. | | OS Version | This is the exact OS version the software is installed on. (Click highlighted number in the Impacted or Updated column to view the corresponding devices.) | | Severity | Shows the CVSS severity level for the software patch. Click to see the CVE link. If the field shows grey text, this refers to the agent severity and there is no CVE link. | | Days Exposed | Shows the days based on the first time the package is available in the Automox customer base. Note: Click the column heading to switch between Days Exposed and Date Detected. | | Date Detected | Shows the date the package was detected. See Days Exposed and Date Detected Column. | | Ignored | This shows if the package is marked as ignored, which means that the next scheduled patch is not installed. Note: When a software package is marked as Ignored, the patch is not included in the outstanding patch count on the Dashboard page. | | Impacted | Shows if the software patch is available. Click the number to view a list of impacted devices on the Devices page. | | Updated | Shows if the software patch has been installed. Click the number to view a list of updated devices. | | Actions | This drop-down menu allows you to take actions on the selected software.Possible actions: Patch Now: Select this to update to the available version. Ignore: This prevents the next scheduled patch from being installed. Unignore: Allow the software patch to be installed as scheduled. | | Needs Restart | This shows if a device must be restarted to complete this software update. | ## Export CSV You can export a complete list of all software on your devices. Click **Export CSV**. ## Columns Use the **Column** drop-down menu to select which table columns you want to include or exclude from view. - Select or clear any checkboxes to control the Software page view. - You can change the order of the columns by dragging the selected column name to the desired position. ![](../../Resources/Images/software-columns.png) ## Days Exposed and Date Detected Column By default, the Software table shows the Days Exposed. The days are based on the first time the software package was made available in the Automox customer base. To view the date the package was detected, click on the column heading to switch from **Days Exposed** to **Date Detected**. ![](../../Resources/Images/software-days-exposed.png) ## Related Topics - [Filtering and Searching on the Software Page](Filtering_and_Searching_on_the_Software_Page.htm) - [Use API to Get a Hardware Inventory of Your Organization](https://community.automox.com/automox-labs-8/use-api-to-get-a-hardware-inventory-of-your-organization-1399) --- # Apple Silicon (M1) Support _Section: Product Documentation › Third-Party Software • Source: https://docs.automox.com/product/Content/Product%20Documentation/Third-Party%20Software/Apple_Silicon__M1__Support.htm_ Find out how Automox supports third-party applications on devices with Apple Silicon. ## Automox Agent The Automox agent is a universal binary and runs natively on Macs with Apple Silicon (M1). ## Required Software and Custom Policies All required software and custom policies should continue to work as expected. ## Apple macOS Updates Beginning with the Agent 33 release, Automox fully supports macOS updates on Apple Silicon devices. Follow [Install and Configure Automox Agent for Apple Silicon Devices](../Agents/Agent Installation/Install_and_Configure_Automox_Agent_for_Apple_Silicon_Devices.htm) to ensure the Automox agent has the appropriate permissions on Apple Silicon devices. ## Third-Party Software Updates Native support for Mac M1 architecture is dependent on the software vendor. While many vendors are still working to make their product compatible with the M1 CPU, Apple has provided support for Intel-based apps on M1 devices using the Rosetta 2 Translation Environment. ## Related Topics - [Mac computers with Apple Silicon](https://support.apple.com/en-us/HT211814) - [Third-Party Software Support](Third_Party_Software_Support.htm) --- # Naming Scheme for Third-Party Software Packages _Section: Product Documentation › Third-Party Software • Source: https://docs.automox.com/product/Content/Product%20Documentation/Third-Party%20Software/Naming_Scheme_for_Third_Party_Software_Packages.htm_ Automox uses an internal naming scheme for supported third-party software packages. The package names are cached and used when [Creating a Required Software Policy](../Policies/Creating_a_Required_Software_Policy.htm). When creating a Required Software Policy, the display name and the internally cached name for third-party software packages differ. To ensure that the policy runs correctly, use the cached name in the Package Name field. The Bundle Name is a separate identifier for macOS software packages, and is required when creating patching override policies for macOS (see [Third-Party Patching Best Practices](Third_Party_Patching_Best_Practices.htm) for details about overrides options). **Note**: The Bundle Name is **case-sensitive**, so be sure to copy/paste from this list when creating overrides. | Software Title | Cached Package Name | macOS Bundle Name | | --- | --- | --- | | 1Password 8 | 1Password | com.1password.1password | | 3Dconnexion 3DxWare | 3Dconnexion_3DxWare | | | 7-Zip | 7-Zip | | | 8x8 Work | 8x8 | com.electron.8x8---virtual-office | | AbaClient | AbaClient | ch.abacus.abaclient | | ActivePresenter (v6-v10) | ActivePresenter_10ActivePresenter_6ActivePresenter_7ActivePresenter_8ActivePresenter_9 | ActivePresenter_6ActivePresenter_7ActivePresenter_8ActivePresenter_9com.atomi.activepresenter.10 | | Adobe Acrobat Pro DC | adobe_acrobat_dc_update | Adobe_Acrobat_DC_OSX | | Adobe Acrobat Reader 2020 Classic (MUI) | Acrobat_Reader_2020_Classic | Acrobat_Reader_2020_Classic_OSX | | Adobe Acrobat Reader DC | adobe_acrobat_reader_dc_fulladobe_acrobat_reader_dc_update | Adobe_Acrobat_Reader_OSX | | Adobe Acrobat Reader DC MUI | Acrobat_Reader_DC_MUI_FullAcrobat_Reader_DC_MUI_UpdateAcrobat_Reader_DC_MUI_Update | | | Adobe Acrobat SCA DC | Adobe_Acrobat_SCA_DC | com.adobe.Acrobat.Pro.SCA | | Adobe Air (Harman) | Adobe_Air | com.adobe.air.Installer | | Adobe Digital Editions | Digital_Editions | com.adobe.adobedigitaleditions.app | | Advanced IP Scanner | Advanced_IP_Scanner | | | Affinity Photo 2 | Affinity_Photo_2 | com.seriflabs.affinityphoto2 | | Agent Ransack | AgentRansack | | | Ai2 Starter | Ai2_Starter | | | Aircall | Aircall | io.aircall.phone | | AirServer | AirServer | com.pratikkumar.airserver-mac | | Airtame | Airtame | com.airtame.airtame-application | | Algodoo | Algodoo | se.algoryx.algodoo-regular | | Alice 3 | Alice_3 | | | Altova MapForce Enterprise (2020, 2020R2, 2021R2, 2023) | MapForce_Ent_2020MapForce_Ent_2020_R2MapForce_Ent_2021_R2MapForce_Ent_2023 | | | Altova MapForce Professional (2020, 2020R2, 2021R2, 2023) | MapForce_Pro_2020MapForce_Pro_2020_R2MapForce_Pro_2021_R2MapForce_Pro_2023 | | | Altova MissionKit Enterprise (2020, 2020R2, 2021R2, 2023, 2024, 2024R2, 2025, 2025R2, 2026) | MK_Ent_2020MK_Ent_2020_R2MK_Ent_2021_R2MK_Ent_2023MK_Ent_2024MK_Ent_2024_R2MK_Ent_2025MK_Ent_2025_R2MK_Ent_2026 | | | Altova MissionKit Professional (2020, 2020R2, 2021R2, 2023, 2024, 2024R2, 2025, 2025R2, 2026) | MK_Pro_2020MK_Pro_2020_R2MK_Pro_2021_R2MK_Pro_2023MK_Pro_2024MK_Pro_2024_R2MK_Pro_2025MK_Pro_2025_R2MK_Pro_2026 | | | Altova XMLSpy Enterprise (2020, 2020R2, 2021R2, 2023, 2024, 2024R2, 2025, 2025R2, 2026) | XMLSpy_Ent_2020XMLSpy_Ent_2020_R2XMLSpy_Ent_2021_R2XMLSpy_Ent_2023XMLSpy_Ent_2024XMLSpy_Ent_2024_R2XMLSpy_Ent_2025XMLSpy_Ent_2025_R2XMLSpy_Ent_2026 | | | Altova XMLSpy Professional (2020, 2020R2, 2021R2, 2023, 2024, 2024R2, 2025, 2025R2, 2026) | XMLSpy_Pro_2020XMLSpy_Pro_2020_R2XMLSpy_Pro_2021_R2XMLSpy_Pro_2023XMLSpy_Pro_2024XMLSpy_Pro_2024_R2XMLSpy_Pro_2025XMLSpy_Pro_2025_R2XMLSpy_Pro_2026 | | | Amazon AWS VPN Client | AWS_VPN_Client | com.amazonaws.acvc.osx | | Amazon Chime | Amazon_Chime | com.amazon.Amazon-Chime | | Amazon Corretto (8, 11, 17, 18, 19, 21, 25) | Amazon_Corretto_17Corretto_11Corretto_18Corretto_19Corretto_21Corretto_25Corretto_8 | com.amazon.corretto.11com.amazon.corretto.17com.amazon.corretto.18com.amazon.corretto.19com.amazon.corretto.21com.amazon.corretto.25com.amazon.corretto.8 | | Amazon Corretto 8 JRE | Corretto8_JRECorretto8_JRE | | | Amazon WorkSpaces | Amazon_Workspaces | com.amazon.workspaces | | Android Studio | Android_Studio | com.google.android.studio | | AnyDesk | AnyDeskAnyDesk_MSI | com.philandro.anydesk | | Archi | Archi | com.archimatetool.editor | | Arduino IDE | Arduino_IDE | cc.arduino.IDE2 | | Artweaver Free | Artweaver_Free | | | Artweaver Plus 7 | Artweaver_Plus_7 | | | Asana | Asana | com.electron.asana | | ASAP Utilities | ASAP_Utilities | | | Atlassian Companion | Atlassian_Companion | com.electron.companion | | Atom | Atom | com.github.atom | | Attendant Pro | Attendant_Pro | | | Audacity | Audacity | org.audacityteam.audacity | | Authy Desktop | Authy_Desktop | com.authy.authy-mac | | Auto Dark Mode | Auto_Dark_Mode | | | Autodesk Design Review 2018 | Design_Review_2018 | | | Autodesk Desktop Connector 16 | Autodesk_Desktop_Connector_16 | | | AutoIt | AutoIt | | | AutoText Master | AutoText_Master | | | AWS CLI v2 | AWS_Command_Line_Interface_v2 | AWS_Command_Line_Interface_v2 | | Azure Data Studio | azure_data_studio | com.azuredatastudio.oss | | Bandicam | Bandicam | | | Bandicut | Bandicut | | | Beeftext | Beeftext | | | Beyond Compare (v4, v5) | Beyond_CompareBeyond_Compare_5 | com.ScooterSoftware.BeyondComparecom.ScooterSoftware.BeyondCompare.5 | | BIMcollab ZOOM | BIMcollab_ZOOM | | | BIMvision | BIM_Vision | | | Bitvise | Bitvise | | | Bitwarden | Bitwarden | com.bitwarden.desktop | | Blender | Blender | org.blenderfoundation.blender | | Bloomberg Terminal | Bloomberg_Terminal | | | Bluebeam OCR 20, 21 | Bluebeam_OCR_20Bluebeam_OCR_21 | | | Bluebeam Revu 20, 21 | Bluebeam_Revu_20Bluebeam_Revu_21 | | | BlueGriffon | BlueGriffon | com.disruptive-innovations.bluegriffon2 | | BlueJ | BlueJ | org.bluej.BlueJ | | BlueJeans | BlueJeans | com.bluejeansnet.Blue | | Box Drive | BoxDrive | com.box.desktop | | Boxcryptor | Boxcryptor | com.boxcryptor.osx | | Brackets | Brackets | io.brackets.appshell | | Brave | Brave | com.brave.Browser | | Breevy | Breevy | | | Bulk Rename Utility | Bulk_Rename_Utility | | | Bullzip PDF Printer | Bullzip_PDF_Printer | | | Bytello Share | Bytello_Share | com.cvte.ScreenShare.mac | | Caffeine | Caffeine | com.intelliscapesolutions.caffeine | | CalDavSynchronizer | CalDavSynchronizer | | | Calibre | Calibre | net.kovidgoyal.calibre | | Camtasia (2018-2024) | Camtasia_2020Camtasia_2023Camtasia_2024Camtasia2018Camtasia2019Camtasia2021Camtasia2022 | com.techsmith.camtasia2018com.techsmith.camtasia2019com.techsmith.camtasia2020com.techsmith.camtasia2021com.techsmith.camtasia2022com.techsmith.camtasia2023com.techsmith.camtasia2024 | | Canva | Canva | com.canva.CanvaDesktop | | CCleaner | CCleaner | com.piriform.ccleaner | | CDBurnerXP | CDBurnerXP | | | Charles | Charles | com.xk72.Charles | | ChatGPT | ChatGPT | com.openai.chat | | Cisco Duo Device Health | Device_Health | com.duosecurity.duo-device-health | | Cisco Jabber | Jabber | com.cisco.Jabber | | Cisco Jabber VDI Client | Cisco_JVDI_Client | com.cisco.JabberVDI | | Cisco Webex | Webex | Cisco-Systems.Spark | | Citrix Workspace | Citrix_Workspace | com.citrix.receiver.nomas | | Claude Desktop App | Claude_Desktop | com.anthropic.claudefordesktop | | ClickShare Desktop App | ClickShare | com.barco.clickshare.updater | | ClickUp | ClickUp | com.clickup.desktop-app | | CLion (2024.1, 2025.1, 2025.2, 2025.3) | CLion_2024.1CLion_2025.1CLion_2025.2CLion_2025.3 | com.jetbrains.clion.2024.1com.jetbrains.clion.2025.1com.jetbrains.clion.2025.2com.jetbrains.clion.2025.3 | | Clip2Net | Clip2Net | | | Clockify | Clockify | coing.ClockifyDesktop | | Cloudflare Warp Client | Cloudflare_WARP | com.cloudflare.1dot1dot1dot1.macos | | Cloudya with CRM | CloudyaCloudya_CRM_Connect | X26F74J8TH.net.nfon.app.cloudyaX26F74J8TH.net.nfon.app.cloudya_crm | | CMake | CMake | org.cmake.cmake | | Cold Turkey Blocker | Cold_Turkey_Blocker | com.getcoldturkey.blocker | | Commander One | Commander_One | com.eltima.cmd1 | | ConEmu | ConEmu | | | CPUID CPU-Z Classic | CPUID_CPU-Z | | | CPUID HWMonitor | HWMonitor | | | CPUID Perfmonitor-2 | Perfmonitor2 | | | Creality Slicer | Creality_Slicer | com.creality.crealityslicer | | Creo View Express | Creo_View_Express | | | CryptoPrevent | CryptoPrevent | | | CrystalDiskInfo | CrystalDiskInfo | | | Cursor | Cursor | com.todesktop.230313mzl4w4u92 | | Cyberduck | CyberDuck | ch.sudo.cyberduck | | Datadog Agent | Datadog | | | DataGrip (2023.3, 2024.1, 2025.1, 2025.2, 2025.3) | DataGrip_2023.3DataGrip_2024.1DataGrip_2025.1DataGrip_2025.2DataGrip_2025.3 | com.jetbrains.datagrip.2023.3com.jetbrains.datagrip.2024.1com.jetbrains.datagrip.2025.1com.jetbrains.datagrip.2025.2com.jetbrains.datagrip.2025.3 | | DAX Studio | DAX_Studio | | | DB Browser for SQLite | DB4S | net.sourceforge.sqlitebrowser | | DBeaver Community Edition | DBeaver | org.jkiss.dbeaver.core.product | | DbVis | DbVis | com.dbvis.DbVisualizer | | Deezer | Deezer | com.deezer.deezer-desktop | | Dell Command Update - Windows Universal | Dell_Command_Update_WU | | | Dell Display Manager 2.x | Dell_Display_Manager | | | Dependency Agent | Dependency_Agent | | | Devolutions Remote Desktop Manager - Enterprise Edition | Remote_Desktop_Manager | com.devolutions.remotedesktopmanager | | Dialpad | Dialpad | com.electron.dialpad | | DisplayFusion | DisplayFusion_EXEDisplayFusion_MSI | | | DisplayLink Graphics | DisplayLink_Graphics | com.displaylink.DisplayLinkUserAgent | | Docker Desktop | Docker_Desktop | com.docker.docker | | Double Commander | Double_Commander | com.company.doublecmd | | Draw.io | Draw.io | com.jgraph.drawio.desktop | | Dropbox | Dropbox | com.getdropbox.dropbox | | Dropbox Capture | Dropbox_Capture | com.electron.dropbox-capture | | Druva inSync | Druva_inSync | com.druva.inSync | | DYMO Label | DYMO_Label | com.dymo.dls | | Egnyte Desktop App | Egnyte_Desktop_App | com.egnyte.Egnyte-Drive | | Ekahau AI Pro | Ekahau_AI_Pro | com.ekahau.wifidesign.ess | | ePlayerPro | ePlayerPro | com.exacq.ePlayerPro | | Epson Easy Interactive Tools | Easy_Interactive_Tools | com.epson.EasyInteractiveTools | | Evernote | Evernote | com.evernote.Evernote | | Everything | Everything | | | Exacqvision VMS Client | exacqVision_Client | com.exacq.edvrclient | | ezCheckPrinting 9 | ezCheckPrinting_9 | | | FileZilla Client | FileZilla | org.filezilla-project.filezilla | | FileZilla Server | Filezilla_Server | org.filezilla-project.filezilla-server | | Foxit PDF Editor (11, 12, 13, 14, 2025) | FoxitEditor_11FoxitEditor_11_0FoxitEditor_12FoxitEditor_13FoxitEditor_14FoxitEditor_2025 | | | Foxit PDF Reader | FoxitReader | com.foxit-software.Foxit.PDF.Reader | | GameMaker Studio | GameMaker_Studio | com.yoyogames.gms2 | | Garmin Express | Garmin_Express | com.garmin.renu.client | | GCompris Educational Software | GCompris | net.gcompris | | Genesys Cloud | GenesysCloud | com.inin.purecloud.directory | | GIMP | GIMP | | | Git | Git | | | Git Extensions | Git_Extensions | | | Github Desktop | Github_Desktop | com.github.GitHubClient | | GitKraken | GitKraken | com.axosoft.gitkraken | | GlassWire | GlassWire | | | GNU Emacs | Emacs | org.gnu.Emacs | | Go Connect | Go_Connect | Go-Connect | | GoodSync | GoodSync | | | Google Chrome | google_chrome | com.google.Chrome | | Google Drive | GoogleDrive | com.google.drivefs | | Google Earth Pro | GoogleEarthPro | com.Google.GoogleEarthPro | | GoTo Connect | GoTo_Connect | com.logmein.goto | | GoTo Opener | GoToOpener | | | Gpg4win | Gpg4win | | | Grammarly Desktop | Grammarly_Desktop | | | Graphmatica | Graphmatica | | | Greenfoot | Greenfoot | org.greenfoot.Greenfoot | | Greenshot | Greenshot | | | grepWin | grepWin | | | HandBrake | HandBrake | fr.handbrake.HandBrake | | HeidiSQL | HeidiSQL | | | Hot Potatoes | Hot_Potatoes | | | Hubstaff | Hubstaff | com.netsoft.Hubstaff | | IcyScreen | IcyScreen | | | ideaMaker | ideaMaker | com.raise3d.ideaMaker | | ImgBurn | ImgBurn | | | Inkscape | Inkscape | | | IntelliJ IDEA Community Edition (2021.1, 2021.2, 2021.3, 2022.1, 2022.2, 2022.3, 2023.1, 2024.1, 2024.2, 2024.3, 2025.1, 2025.2) | IntelliJ_IDEA_CE_2021.1IntelliJ_IDEA_CE_2021.2IntelliJ_IDEA_CE_2021.3IntelliJ_IDEA_CE_2022.1IntelliJ_IDEA_CE_2022.2IntelliJ_IDEA_CE_2022.3IntelliJ_IDEA_CE_2023.1IntelliJ_IDEA_CE_2024.1IntelliJ_IDEA_CE_2024.2IntelliJ_IDEA_CE_2024.3IntelliJ_IDEA_CE_2025.1IntelliJ_IDEA_CE_2025.2 | com.jetbrains.intellij.ce.2021.1com.jetbrains.intellij.ce.2021.2com.jetbrains.intellij.ce.2021.3com.jetbrains.intellij.ce.2022.1com.jetbrains.intellij.ce.2022.2com.jetbrains.intellij.ce.2022.3com.jetbrains.intellij.ce.2023.1com.jetbrains.intellij.ce.2024.1com.jetbrains.intellij.ce.2024.2com.jetbrains.intellij.ce.2024.3com.jetbrains.intellij.ce.2025.1com.jetbrains.intellij.ce.2025.2 | | IntelliJ IDEA Ultimate (2021.1, 2021.2, 2021.3, 2022.1, 2022.2, 2022.3, 2023.1, 2024.1, 2024.3, 2025.1, 2025.2, 2025.3) | IntelliJ_IDEA_Ult_2021.1IntelliJ_IDEA_Ult_2021.2IntelliJ_IDEA_Ult_2021.3IntelliJ_IDEA_Ult_2022.1IntelliJ_IDEA_Ult_2022.2IntelliJ_IDEA_Ult_2022.3IntelliJ_IDEA_Ult_2023.1IntelliJ_IDEA_Ult_2024.1IntelliJ_IDEA_Ult_2024.3IntelliJ_IDEA_Ult_2025.1IntelliJ_IDEA_Ult_2025.2IntelliJ_IDEA_Ult_2025.3 | com.jetbrains.intellij.2021.1com.jetbrains.intellij.2021.2com.jetbrains.intellij.2021.3com.jetbrains.intellij.2022.1com.jetbrains.intellij.2022.2com.jetbrains.intellij.2022.3com.jetbrains.intellij.2023.1com.jetbrains.intellij.2024.1com.jetbrains.intellij.2024.3com.jetbrains.intellij.2025.1com.jetbrains.intellij.2025.2com.jetbrains.intellij.2025.3 | | iTerm2 | iTerm2 | com.googlecode.iterm2 | | iTunes | iTunes | | | Jabra Direct | JabraDirect | | | JAWS 2022 | JAWS_2022 | | | KeePass 1.x | KeePass_Password_Safe | | | KeePass 2.x | KeePass | | | KeePassXC | KeePassXC | org.keepassx.keepassxc | | Keeper | Keeper | com.keepersecurity.passwordmanager | | Leaklog | Leaklog | com.szchkt.Leaklog | | LEGO Education SPIKE | LEGO_Education_SPIKE | com.lego.education.spikenext | | LibreOffice | LibreOffice | org.libreoffice.script | | Logitech Bolt | Logi_Bolt | | | Logitech Options Plus | Options_Plus | | | Logitech SetPoint | Logitech_SetPoint | | | Logitech Unifying Software | Unifying | | | Microsoft Azure CLI | Azure_CLI | | | Microsoft Azure Storage Explorer | Azure_StorageExplorer | com.microsoft.StorageExplorer | | Microsoft Edge | Microsoft_Edge | com.microsoft.edgemac | | Microsoft Office (2016, 2019, 2021, O365) | not cached | | | Microsoft OneDrive | MicrosoftOnedrive | com.microsoft.OneDrive | | Microsoft OpenJDK (21, 25) | MicrosoftJDK21MicrosoftJDK25 | net.java.openjdk.jdk.21net.java.openjdk.jdk.25 | | Microsoft PowerBI Desktop | PowerBI_Desktop | | | Microsoft PowerToys | PowerToys | | | Microsoft Project | not cached | | | Microsoft Remote Desktop | MicrosoftRemoteDesktop | com.microsoft.rdc.macos | | Microsoft Skype | Skype | com.skype.skype | | Microsoft SQL OLE DB Driver 18 and 19 | MS_OLEDB_SQL_18MS_OLEDB_SQL_19 | | | Microsoft SQL Server Management Studio 18, 19, 20 | SQL_Server_Management_Studio_18SQL_Server_Management_Studio_19SQL_Server_Management_Studio_20 | | | Microsoft Teams | Microsoft_Teams | com.microsoft.teams | | Microsoft Teams Machine-Wide Installer | Microsoft_Teams | | | Microsoft Teams New | Microsoft_Teams_New | com.microsoft.teams2 | | Microsoft Visio | not cached | | | Microsoft Visual C++ Redistributable v14 (2015-2026) | VC_2015-2022_Redist | | | Microsoft Visual Studio Build Tools 2019, 2022 (Current, Spring 2023, 2022 LTSC & Fall 2022 LTSC) | VS_BT_2019VS_BT_2022_CurrentVS_BT_2022_Fall_2022_LTSCVS_BT_2022_Spring_2022_LTSCVS_BT_2022_Spring_2023_LTSC | | | Microsoft Visual Studio Code | Visual_Studio_Code | com.microsoft.VSCode | | Microsoft Visual Studio Community 2022 | VS_Community_2022 | | | Microsoft Visual Studio Enterprise 2019, 2022 (Current, Spring 2023, 2022 LTSC & Fall 2022 LTSC) | VS_Ent_2019VS_Ent_2022_CurrentVS_Ent_2022_Fall_2022_LTSCVS_Ent_2022_Spring_2022_LTSCVS_Ent_2022_Spring_2023_LTSC | | | Microsoft Visual Studio Professional 2019, 2022 (Current, Spring 2023, 2022 LTSC & Fall 2022 LTSC) | VS_Pro_2019VS_Pro_2022_CurrentVS_Pro_2022_Fall_2022_LTSCVS_Pro_2022_Spring_2022_LTSCVS_Pro_2022_Spring_2023_LTSC | | | Mozilla Firefox | Firefox | org.mozilla.firefox | | Mozilla Firefox Developer | Firefox_Developer | org.mozilla.firefoxdeveloperedition | | Mozilla Firefox ESR | FirefoxESR | FirefoxESR_OSX | | Mozilla SeaMonkey | SeaMonkey | SeaMonkey_OSX | | Mozilla Thunderbird | Thunderbird | org.mozilla.thunderbird | | MTPuTTY | MTPuTTY | | | MySQL Workbench CE | MySQL_Workbench_CE | com.oracle.workbench.MySQLWorkbench | | Node.js Current | NodeJS | | | Node.js LTS | NodeJS_LTS | | | NoMachine Enterprise Client | NoMachine_Enterprise_Client | com.nomachine.nxdock | | Notepad++ | NotepadPlusPlus | | | Notion | Notion | notion.id | | Nudge | Nudge | com.github.macadmins.Nudge | | OBS Studio | OBS_Studio | com.obsproject.obs-studio | | Obsidian | Obsidian | md.obsidian | | Octave | Octave | org.octave-app.Octave | | ODBC Driver for SQL Server (17, 18) | MS_ODBC_SQL_17MS_ODBC_SQL_18 | | | Omnissa Horizon Client 8 | Omnissa_Horizon_Client_8 | com.omnissa.horizon.client.mac.8 | | OpenVPN Connect | OpenVPN_Connect | org.openvpn.client.app | | Opera | Opera | com.operasoftware.Opera | | Oracle Java (JRE) 6, 7, 8 | Java_6Java_7Java_8 | java6java7java8 | | Oracle Java SE 17, 18, 19, 20, 21, 25, 26 | Oracle_Java_17Oracle_Java_18Oracle_Java_19Oracle_Java_20Oracle_Java_21Oracle_Java_25Oracle_Java_26 | com.oracle.java.jdk.17com.oracle.java.jdk.18com.oracle.java.jdk.19com.oracle.java.jdk.20com.oracle.java.jdk.21com.oracle.java.jdk.25com.oracle.java.jdk.26 | | Paint.NET | PaintDotNet | | | Pale Moon | Pale_Moon | org.mozilla.pale moon | | Parallels RAS | Parallels_Remote_Application_Server | com.2X.Client.Mac | | Parallels Toolbox | Parallels_Toolbox | | | PDF Reader Pro | PDF_Reader_Pro | com.brother.pdfreaderprofree.mac | | PDF-XChange Editor | PDF-XChange_Editor | | | PDF24 Creator | PDF24_Creator | | | Perimeter 81 VPN | Perimeter81 | com.safervpn.osx.smb | | pgAdmin 4 | pgAdmin_4 | org.pgadmin.pgadmin4 | | PictoBlox | Stempedia | com.stempedia.pictoblox | | Pidgin | Pidgin | | | Plantronics Hub | Plantronics_Hub | Plantronics-Inc..Plantronics-Hub | | Poly Studio (Lens) | Poly_Studio | com.poly.lens.client.app | | Postman | Postman | com.postmanlabs.mac | | Proton VPN | ProtonVPN | ch.protonvpn.mac | | PuTTY | Putty | | | PyCharm Community Edition (2024.1, 2025.1, 2025.2) | PyCharm_CE_2024.1PyCharm_CE_2025.1PyCharm_CE_2025.2 | com.jetbrains.pycharm.ce.2024.1com.jetbrains.pycharm.ce.2025.1com.jetbrains.pycharm.ce.2025.2 | | PyCharm Professional (2024.1, 2025.1, 2025.2, 2025.3) | PyCharm_Pro_2024.1PyCharm_Pro_2025.1PyCharm_Pro_2025.2PyCharm_Pro_2025.3 | com.jetbrains.pycharm.pro.2024.1com.jetbrains.pycharm.pro.2025.1com.jetbrains.pycharm.pro.2025.2com.jetbrains.pycharm.pro.2025.3 | | QZ Tray | QZ_Tray | | | Recoverit | Recoverit | | | RemotePC Host | RemotePC_Host | com.prosoftnet.remotepcSuite | | RingCentral | RingCentral | com.ringcentral.glip | | Royal TS 6 | Royal_TS | com.lemonmojo.RoyalTSX.App | | Royal TS 7 | Royal_TS_7 | | | RStudio Desktop | RStudio_Desktop | com.rstudio.desktop | | RubyMine (2024.1, 2025.1, 2025.2, 2025.3) | RubyMine_2024.1RubyMine_2025.1RubyMine_2025.2RubyMine_2025.3 | com.jetbrains.rubymine.2024.1com.jetbrains.rubymine.2025.1com.jetbrains.rubymine.2025.2com.jetbrains.rubymine.2025.3 | | Seagull Scientific BarTender 2022 | BarTender_2022 | | | Sequel Pro | SequelPro | com.sequelpro.SequelPro | | Signal Desktop | SignalDesktop | org.whispersystems.signal-desktop | | SigWeb | SigWeb | | | SizeUp | SizeUp | com.irradiatedsoftware.SizeUp | | Slack | Slack | com.tinyspeck.slackmacgap | | Snagit (2018-2026) | SnagIt2018SnagIt2019SnagIt2020SnagIt2021SnagIt2022SnagIt2023SnagIt2024SnagIt2025SnagIt2026 | com.TechSmith.Snagit2018com.TechSmith.Snagit2019com.TechSmith.Snagit2020com.TechSmith.Snagit2021com.TechSmith.Snagit2022com.TechSmith.Snagit2023com.TechSmith.Snagit2024com.TechSmith.Snagit2025com.TechSmith.Snagit2026 | | SoapUI | SoapUI | com.install4j.5517-2803-0637-4585.64 | | Sourcetree | Sourcetree | com.torusknot.SourceTreeNotMAS | | Splashtop Remote Access | Splashtop_Business | com.splashtop.stb.macosx | | Splashtop RMM | Splashtop_RMM | com.splashtop.stbrm.macosx | | Splashtop Streamer | Splashtop_Streamer | com.splashtop.Splashtop-Streamer | | Steam | Steam | com.valvesoftware.steam | | Sublime Text (v3 and v4) | SublimeText3SublimeText4 | com.sublimetext.3com.sublimetext.4 | | Talkdesk Atlas | Talkdesk_Atlas | com.talkdesk.atlas | | TeamViewer | TeamViewer | | | TeamViewer Host | TeamViewer_Host | com.teamviewer.TeamViewerHost | | The Unarchiver | TheUnarchiver | com.macpaw.site.theunarchiver | | TigerVNC | TigerVNC | | | TightVNC | TightVNC | | | TortoiseSVN | TortoiseSVN | | | Transmit | Transmit | com.panic.Transmit | | Tunnelblick | Tunnelblick | net.tunnelblick.tunnelblick | | Twingate | Twingate | | | UltiMaker Cura | UltiMaker_Cura | nl.ultimaker.cura_UltiMaker_Cura | | VirtualBox | VirtualBox | org.virtualbox.app.VirtualBox | | Viscosity | Viscosity | com.viscosityvpn.Viscosity | | Vivaldi | Vivaldi | com.vivaldi.Vivaldi | | VLC Media Player | VLC_media_player | org.videolan.vlc | | VMware Horizon Client 7 | Horizon_Client_7 | Horizon_Client_7 | | VMware Workstation Player | Workstation_Player | | | VNC Server | VNC_Server | | | VNC Viewer | VNC_Viewer | com.realvnc.vncviewer | | WinMerge | WinMerge | | | WinRAR (EN & FR) | WinRarWinRAR_FR | | | WinSCP | WinSCP | | | Wireshark | Wireshark | org.wireshark.Wireshark | | Wondershare Anireel | Wondershare_Anireel | | | Wondershare Creative Center | Creative_Center | | | Wondershare DVD Creator | DVD_Creator | com.wondershare.DVDCreate | | Wondershare Filmora | Filmora | com.wondershare.filmoramac | | Wondershare PDFelement | PDFelement | com.wondershare.PDFelement | | Wondershare UBackit | UBackit | | | Wondershare UniConverter (13, 14) | UniConverter13UniConverter14 | com.Wondershare.UniConvertercom.Wondershare.UniConverter14 | | X-Mouse Button Control | X-Mouse_Button_Control | | | XnView MP | XnViewMP | com.xnview.XnView | | Yubico Authenticator | Yubico_Authenticator | com.yubico.yubioath | | YubiKey Manager | YubiKey_Manager | com.yubico.ykman | | Zoom | Zoom | us.zoom.xos | | Zoom Outlook Plugin | ZoomOutlookPlugin | us.zoom.olpluginlauncher | | Zoom Rooms (ZoomPresence on macOS) | Zoom_Rooms | us.zoom.ZoomPresence | | Zoom VDI Client | Zoom_VDI_Client | | | Zoom VDI Plugin | Zoom_VDI_Plugin | us.zoom.ZoomVDI | | Zulu JDK (8, 11, 16, 17, 18, 19, 20, 21, 22, 25) | ZuluJDK11ZuluJDK16ZuluJDK17ZuluJDK18ZuluJDK19ZuluJDK20ZuluJDK21ZuluJDK22ZuluJDK25ZuluJDK8 | com.azul.zulu.jdk.11com.azul.zulu.jdk.16com.azul.zulu.jdk.17com.azul.zulu.jdk.18com.azul.zulu.jdk.19com.azul.zulu.jdk.20com.azul.zulu.jdk.21com.azul.zulu.jdk.22com.azul.zulu.jdk.25com.azul.zulu.jdk.8 | ## Related Topics - [Third-Party Software Support](Third_Party_Software_Support.htm) - [Third-Party Patching Best Practices](Third_Party_Patching_Best_Practices.htm) --- # Patching Third-Party Applications - Tips & Tricks _Section: Product Documentation › Third-Party Software • Source: https://docs.automox.com/product/Content/Product%20Documentation/Third-Party%20Software/Patching_Third_Party_Applications___Tips___Tricks.htm_ ## Patching Cyberduck on Windows Cyberduck has a version limitation on 32-bit installs. The latest 32-bit version is 7.0.2. Automox patches to that version if a 32-bit install exists. Automox will not install newer 32-bit versions because of a vendor behavior that we cannot change or control. 64-bit versions will be updated to the latest available version of Cyberduck. ## Patching File Sync Applications on Automox (Box Drive, Dropbox) This describes the behavior when patching file sync applications, such as Dropbox and Box Drive, through Automox. Even if a file sync app has been shutdown, it might relaunch after an update. This is a vendor behavior that we cannot control or change. If the app is open during the patch, Automox will relaunch it. The behavior described here applies to the following file sync apps supported by Automox: - Dropbox - Box Drive **Note:** If a file sync application is open when patching begins, Automox always relaunches it after patching. ## Oracle SE Java 8 Support Shift and How It Impacts Automox Users Effective immediately, Automox is no longer able to support patching for Oracle SE Java 8. Many third-party software providers have EULAs (End User License Agreements) that prevent patching solutions from directly redistributing patches or software updates. Recently, Oracle’s Java SE 8 went through the “End of Public Updates” process for legacy releases. Patches can vary by system architecture and platform, but the fundamentals remain the same. What this means for Automox users is that Automox can no longer enable third-party application patching for Oracle SE Java 8 without violating the EULA from Oracle. Customers currently reliant on Automox to help automate this process will need to adopt a new approach to patch Java 8 moving forward. This process is detailed here as well as in a community post on the Automox Alive Community. Automox can still help to automate patching of third-party applications like Java 8 on your terms through Automox Worklets. ### How to Update Oracle SE Java 8 Software Oracle SE Java 8 requires a login to the Oracle support portal and the acceptance of the Oracle EULA. The patch is then available for download and can be uploaded to the Automox console for distribution. The key actions for adding third-party patches into the Automox console are as follows: ### Obtain the patch through manual download of the “offline” install file or through a Worklet ![](../../Resources/Images/java-downloads.png) Review all required third-party EULA terms and conditions ensuring alignment with your company policies and legal charter. Manually download the patch or leverage Automox Worklets to automate the process altogether. ### Upload the patch to the Automox console **Note:**You must create a Required Software Policy to be able to upload the patch. See [Creating a Required Software Policy.](../Policies/Creating_a_Required_Software_Policy.htm) By uploading the file to the Automox console, the patch is added to the ecosystem for your organizational use. This step ensures that devices are able to obtain the required patch from the Automox console. Make adjustments to policies (if necessary). Make any necessary adjustments to policies in applying the patch to devices in scope. This might mean altering the installation syntax if command line parameters have changed. If no existing required software policy exists for the patch, create a new one and add the name, version, and installation script syntax. ## Patching Skype on Windows and macOS Automox patches the Skype application only when it is not in use. You might see that a patch for Skype fails if the application is being used during the patch window for Skype. Automox will show that a patch is available pending. The patch will be updated the next time the policy runs if the application is not in use. Because updates to the Skype application require a restart, the operation can only be successful when Skype is closed and does not appear in the system tray. ### Patching Skype from the Software page To view a scheduled patch, you can go to the Software Page and search for Skype. When a version of Skype listed has a patch available, it will list a number under **Impacted Devices**. If you are not using the application, you can immediately patch by clicking **Actions** → **Patch Now**. Confirm your selection. ![](../../Resources/Images/patching-skype.png) ### Patching Skype from the Device Details page You can also view scheduled patches from the Software section of the Device Details page. The patch for Skype will show as Update Available. If you are not using the Skype application, from here you can decide to immediately apply the patch. From the Bulk Actions menu, select **Patch**. Additionally, you can navigate to the Overview Report and it will reflect the pending patch in the list of Available. ![](../../Resources/Images/patching-skype-devicedetails.png) ### Creating a Patch Policy for Skype You can decide to patch Skype with a separate policy that focuses on the patch schedule. Your workflow and use of Skype will determine how you schedule the update and how you notify users. You can set up a Patch Only policy, filter for the appropriate patch, and schedule it to be applied outside of working hours. For the basics of creating a policy, see the following articles: - [Creating a Patch Policy](../Policies/Creating_a_Patch_Policy.htm) - [Setting a Patching Schedule](../Policies/Setting_a_Patching_Schedule.htm) - [Managing End-User Notifications](../Notifications & Restarts/Managing_End_User_Notifications.htm) When you schedule this policy as desired, you can create a message to inform your users that Skype updates only occur outside of the use of the application and therefore it is possible the patch could occur upon restarting the device. --- # Third-Party Patching Best Practices _Section: Product Documentation › Third-Party Software • Source: https://docs.automox.com/product/Content/Product%20Documentation/Third-Party%20Software/Third_Party_Patching_Best_Practices.htm_ Recommended best practices for managing third-party applications in Automox. ## Patch Application Behavior Table The following table lists the types of behavior for third-party software patching in Automox so that you can take actions, such as configuring groups and policies accordingly, if necessary. See also details about overrides in the section after this table. | Software Title | App is NOT shut down in order to patch | App will NOT patch when running | App is shut down by vendor in order to patch | App is shut down by Automox in order to patch | | --- | --- | --- | --- | --- | | 1Password 8 | | | ✔ (macOS) | ✔ (Windows) | | 3Dconnexion 3DxWare | | | ✔ | | | 7-Zip | ✔ | | | | | 8x8 Work | | ✔ | | | | AbaClient | ✔ | | | | | ActivePresenter (v6-v10) | | ✔ | | | | Adobe Acrobat Pro DC | | | ✔ | | | Adobe Acrobat Reader 2020 Classic (MUI) | | | ✔ (macOS) | ✔ (Windows) | | Adobe Acrobat Reader DC | | | ✔ | | | Adobe Acrobat Reader DC MUI | | | ✔ | | | Adobe Acrobat SCA DC | | | ✔ | | | Adobe Air (Harman) | ✔ (Windows) | | ✔ (macOS) | | | Adobe Digital Editions | | | ✔ | | | Advanced IP Scanner | ✔ | | | | | Affinity Photo 2 | | ✔ | | | | Agent Ransack | | ✔ | | | | Ai2 Starter | | ✔ | | | | Aircall | | ✔ | | | | AirServer | | ✔ (macOS) | | ✔ (Windows) | | Airtame | | ✔ (macOS) | | ✔ (Windows) | | Algodoo | ✔ (macOS) | | | ✔ (Windows) | | Alice 3 | | | | ✔ | | Altova MapForce Enterprise (2020, 2020R2, 2021R2, 2023) | ✔ | | | | | Altova MapForce Professional (2020, 2020R2, 2021R2, 2023) | ✔ | | | | | Altova MissionKit Enterprise (2020, 2020R2, 2021R2, 2023, 2024, 2024R2, 2025, 2025R2, 2026) | ✔ | | | | | Altova MissionKit Professional (2020, 2020R2, 2021R2, 2023, 2024, 2024R2, 2025, 2025R2, 2026) | ✔ | | | | | Altova XMLSpy Enterprise (2020, 2020R2, 2021R2, 2023, 2024, 2024R2, 2025, 2025R2, 2026) | ✔ | | | | | Altova XMLSpy Professional (2020, 2020R2, 2021R2, 2023, 2024, 2024R2, 2025, 2025R2, 2026) | ✔ | | | | | Amazon AWS VPN Client | | ✔ | | | | Amazon Chime | | ✔ | | | | Amazon Corretto (8, 11, 17, 18, 19, 21, 25) | ✔ | | | | | Amazon Corretto 8 JRE | ✔ | | | | | Amazon WorkSpaces | ✔ (macOS) | | ✔ (Windows) | | | Android Studio | ✔ (macOS) | ✔ (Windows) | | | | AnyDesk | | ✔ (macOS) | | ✔ (Windows) | | Archi | | ✔ | | | | Arduino IDE | | ✔ | | | | Artweaver Free | | ✔ | | | | Artweaver Plus 7 | | ✔ | | | | Asana | | ✔ | | | | ASAP Utilities | | ✔ | | | | Atlassian Companion | ✔ (macOS) | | ✔ (Windows) | | | Atom | | ✔ | | | | Attendant Pro | ✔ | | | | | Audacity | ✔ (macOS) | ✔ (Windows) | | | | Authy Desktop | | ✔ | | | | Auto Dark Mode | | | | ✔ | | Autodesk Design Review 2018 | | | | ✔ | | Autodesk Desktop Connector 16 | | | | ✔ | | AutoIt | ✔ | | | | | AutoText Master | | ✔ | | | | AWS CLI v2 | | ✔ | | | | Azure Data Studio | | ✔ | | | | Bandicam | | | ✔ | | | Bandicut | | ✔ | | | | Beeftext | | | | ✔ | | Beyond Compare (v4, v5) | ✔ (macOS) | | | ✔ (Windows) | | BIMcollab ZOOM | ✔ | | | | | BIMvision | | ✔ | | | | Bitvise | | | ✔ | | | Bitwarden | | ✔ (macOS) | ✔ (Windows) | | | Blender | | ✔ | | | | Bloomberg Terminal | | ✔ | | | | Bluebeam OCR 20, 21 | | ✔ | | | | Bluebeam Revu 20, 21 | | ✔ | | | | BlueGriffon | | ✔ | | | | BlueJ | | ✔ | | | | BlueJeans | ✔ | | | | | Box Drive | | | ✔ (macOS) | ✔ (Windows) | | Boxcryptor | ✔ (Windows) | ✔ (macOS) | | | | Brackets | | ✔ | | | | Brave | | ✔ (macOS) | | ✔ (Windows) | | Breevy | | | | ✔ | | Bulk Rename Utility | | ✔ | | | | Bullzip PDF Printer | | ✔ | | | | Bytello Share | ✔ (Windows) | ✔ (macOS) | | | | Caffeine | | ✔ | | | | CalDavSynchronizer | ✔ | | | | | Calibre | ✔ (macOS) | ✔ (Windows) | | | | Camtasia (2018-2024) | | ✔ | | | | Canva | ✔ (Windows) | ✔ (macOS) | | | | CCleaner | ✔ (macOS) | | | ✔ (Windows) | | CDBurnerXP | | ✔ | | | | Charles | | ✔ | | | | ChatGPT | | ✔ | | | | Cisco Duo Device Health | | | ✔ (macOS) | ✔ (Windows) | | Cisco Jabber | | ✔ | | | | Cisco Jabber VDI Client | ✔ | | | | | Cisco Webex | | ✔ | | | | Citrix Workspace | | ✔ (Windows) | ✔ (macOS) | | | Claude Desktop App | ✔ (macOS) | | ✔ (Windows) | | | ClickShare Desktop App | | ✔ | | | | ClickUp | | ✔ | | | | CLion (2024.1, 2025.1, 2025.2, 2025.3) | | ✔ | | | | Clip2Net | | | | ✔ | | Clockify | | ✔ (macOS) | ✔ (Windows) | | | Cloudflare Warp Client | | ✔ | | | | Cloudya with CRM | ✔ (macOS) | ✔ (Windows) | | | | CMake | ✔ (Windows) | ✔ (macOS) | | | | Cold Turkey Blocker | ✔ | | | | | Commander One | | ✔ | | | | ConEmu | | ✔ | | | | CPUID CPU-Z Classic | | ✔ | | | | CPUID HWMonitor | | | | ✔ | | CPUID Perfmonitor-2 | | ✔ | | | | Creality Slicer | | ✔ | | | | Creo View Express | | | | ✔ | | CryptoPrevent | | ✔ | | | | CrystalDiskInfo | | ✔ | | | | Cursor | | ✔ | | | | Cyberduck | | ✔ | | | | Datadog Agent | | | ✔ | | | DataGrip (2023.3, 2024.1, 2025.1, 2025.2, 2025.3) | | ✔ | | | | DAX Studio | | ✔ | | | | DB Browser for SQLite | | | ✔ | | | DBeaver Community Edition | | ✔ | | | | DbVis | | ✔ | | | | Deezer | | ✔ | | | | Dell Command Update - Windows Universal | ✔ | | | | | Dell Display Manager 2.x | | | ✔ | | | Dependency Agent | ✔ | | | | | Devolutions Remote Desktop Manager - Enterprise Edition | ✔ | | | | | Dialpad | ✔ (macOS) | ✔ (Windows) | | | | DisplayFusion | | | ✔ | | | DisplayLink Graphics | | | ✔ | | | Docker Desktop | ✔ (macOS) | ✔ (Windows) | | | | Double Commander | ✔ | | | | | Draw.io | | ✔ | | | | Dropbox | ✔ (Windows) | | ✔ (macOS) | | | Dropbox Capture | ✔ | | | | | Druva inSync | | | ✔ | | | DYMO Label | ✔ | | | | | Egnyte Desktop App | ✔ (Windows) | | ✔ (macOS) | | | Ekahau AI Pro | ✔ (macOS) | ✔ (Windows) | | | | ePlayerPro | | ✔ | | | | Epson Easy Interactive Tools | | ✔ | | | | Evernote | | ✔ (Windows) | ✔ (macOS) | | | Everything | | | | ✔ | | Exacqvision VMS Client | | ✔ (macOS) | ✔ (Windows) | | | ezCheckPrinting 9 | ✔ | | | | | FileZilla Client | | ✔ | | | | FileZilla Server | ✔ (macOS) | | | ✔ (Windows) | | Foxit PDF Editor (11, 12, 13, 14, 2025) | | ✔ | | | | Foxit PDF Reader | | ✔ (macOS) | | ✔ (Windows) | | GameMaker Studio | ✔ (macOS) | ✔ (Windows) | | | | Garmin Express | | ✔ (macOS) | ✔ (Windows) | | | GCompris Educational Software | | ✔ | | | | Genesys Cloud | | ✔ (macOS) | ✔ (Windows) | | | GIMP | | | | ✔ | | Git | | | | ✔ | | Git Extensions | | ✔ | | | | Github Desktop | | ✔ | | | | GitKraken | | ✔ | | | | GlassWire | | | ✔ | | | GNU Emacs | ✔ | | | | | Go Connect | ✔ | | | | | GoodSync | | ✔ | | | | Google Chrome | ✔ (Windows) | ✔ (macOS) | | | | Google Drive | ✔ (Windows) | | ✔ (macOS) | | | Google Earth Pro | | | ✔ (macOS) | ✔ (Windows) | | GoTo Connect | | ✔ | | | | GoTo Opener | | ✔ | | | | Gpg4win | ✔ | | | | | Grammarly Desktop | | ✔ | | | | Graphmatica | ✔ | | | | | Greenfoot | ✔ (macOS) | ✔ (Windows) | | | | Greenshot | | | | ✔ | | grepWin | | ✔ | | | | HandBrake | ✔ | | | | | HeidiSQL | | ✔ | | | | Hot Potatoes | | ✔ | | | | Hubstaff | | ✔ | | | | IcyScreen | | | | ✔ | | ideaMaker | | ✔ | | | | ImgBurn | | ✔ | | | | Inkscape | | ✔ | | | | IntelliJ IDEA Community Edition (2021.1, 2021.2, 2021.3, 2022.1, 2022.2, 2022.3, 2023.1, 2024.1, 2024.2, 2024.3, 2025.1, 2025.2) | | ✔ | | | | IntelliJ IDEA Ultimate (2021.1, 2021.2, 2021.3, 2022.1, 2022.2, 2022.3, 2023.1, 2024.1, 2024.3, 2025.1, 2025.2, 2025.3) | | ✔ | | | | iTerm2 | ✔ | | | | | iTunes | | | | ✔ | | Jabra Direct | ✔ | | | | | JAWS 2022 | | | ✔ | | | KeePass 1.x | | | | ✔ | | KeePass 2.x | | | | ✔ | | KeePassXC | ✔ | | | | | Keeper | | ✔ | | | | Leaklog | | ✔ | | | | LEGO Education SPIKE | ✔ | | | | | LibreOffice | | ✔ | | | | Logitech Bolt | | | ✔ | | | Logitech Options Plus | | ✔ | | | | Logitech SetPoint | | | ✔ | | | Logitech Unifying Software | | | | ✔ | | Microsoft Azure CLI | ✔ | | | | | Microsoft Azure Storage Explorer | | ✔ | | | | Microsoft Edge | ✔ | | | | | Microsoft Office (2016, 2019, 2021, O365) | | | ✔ | | | Microsoft OneDrive | | | ✔ (macOS) | ✔ (Windows) | | Microsoft OpenJDK (21, 25) | ✔ | | | | | Microsoft PowerBI Desktop | | | | ✔ | | Microsoft PowerToys | | | ✔ | | | Microsoft Project | ✔ | | | | | Microsoft Remote Desktop | | ✔ (macOS) | ✔ (Windows) | | | Microsoft Skype | | ✔ | | | | Microsoft SQL OLE DB Driver 18 and 19 | ✔ | | | | | Microsoft SQL Server Management Studio 18, 19, 20 | | ✔ | | | | Microsoft Teams | | ✔ | | | | Microsoft Teams Machine-Wide Installer | ✔ | | | | | Microsoft Teams New | ✔ | | | | | Microsoft Visio | ✔ | | | | | Microsoft Visual C++ Redistributable v14 (2015-2026) | ✔ | | | | | Microsoft Visual Studio Build Tools 2019, 2022 (Current, Spring 2023, 2022 LTSC & Fall 2022 LTSC) | | ✔ | | | | Microsoft Visual Studio Code | ✔ (macOS) | ✔ (Windows) | | | | Microsoft Visual Studio Community 2022 | | ✔ | | | | Microsoft Visual Studio Enterprise 2019, 2022 (Current, Spring 2023, 2022 LTSC & Fall 2022 LTSC) | | ✔ | | | | Microsoft Visual Studio Professional 2019, 2022 (Current, Spring 2023, 2022 LTSC & Fall 2022 LTSC) | | ✔ | | | | Mozilla Firefox | ✔ | | | | | Mozilla Firefox Developer | | | ✔ | | | Mozilla Firefox ESR | ✔ | | | | | Mozilla SeaMonkey | ✔ | | | | | Mozilla Thunderbird | ✔ | | | | | MTPuTTY | | ✔ | | | | MySQL Workbench CE | ✔ | | | | | Node.js Current | | ✔ | | | | Node.js LTS | | ✔ | | | | NoMachine Enterprise Client | | ✔ | | | | Notepad++ | | ✔ | | | | Notion | | ✔ | | | | Nudge | | | ✔ | | | OBS Studio | ✔ (macOS) | ✔ (Windows) | | | | Obsidian | | ✔ | | | | Octave | ✔ | | | | | ODBC Driver for SQL Server (17, 18) | ✔ | | | | | Omnissa Horizon Client 8 | ✔ (macOS) | ✔ (Windows) | | | | OpenVPN Connect | | ✔ | | | | Opera | ✔ | | | | | Oracle Java (JRE) 6, 7, 8 | ✔ | | | | | Oracle Java SE 17, 18, 19, 20, 21, 25, 26 | ✔ | | | | | Paint.NET | | ✔ | | | | Pale Moon | ✔ (Windows) | ✔ (macOS) | | | | Parallels RAS | ✔ (macOS) | | ✔ (Windows) | | | Parallels Toolbox | | | ✔ | | | PDF Reader Pro | | ✔ | | | | PDF-XChange Editor | | ✔ | | | | PDF24 Creator | | ✔ | | | | Perimeter 81 VPN | | ✔ | | | | pgAdmin 4 | | ✔ | | | | PictoBlox | ✔ | | | | | Pidgin | | ✔ | | | | Plantronics Hub | | | ✔ | | | Poly Studio (Lens) | | | ✔ | | | Postman | | ✔ | | | | Proton VPN | | ✔ | | | | PuTTY | | ✔ | | | | PyCharm Community Edition (2024.1, 2025.1, 2025.2) | | ✔ | | | | PyCharm Professional (2024.1, 2025.1, 2025.2, 2025.3) | | ✔ | | | | QZ Tray | | | ✔ | | | Recoverit | | ✔ | | | | RemotePC Host | ✔ (macOS) | ✔ (Windows) | | | | RingCentral | | | ✔ | | | Royal TS 6 | | ✔ (macOS) | | ✔ (Windows) | | Royal TS 7 | | | | ✔ | | RStudio Desktop | | ✔ | | | | RubyMine (2024.1, 2025.1, 2025.2, 2025.3) | | ✔ | | | | Seagull Scientific BarTender 2022 | | ✔ | | | | Sequel Pro | | ✔ | | | | Signal Desktop | ✔ (macOS) | ✔ (Windows) | | | | SigWeb | | | ✔ | | | SizeUp | | | ✔ | | | Slack | | ✔ (Windows) | ✔ (macOS) | | | Snagit (2018-2026) | | ✔ | | | | SoapUI | | ✔ | | | | Sourcetree | | ✔ | | | | Splashtop Remote Access | | ✔ | | | | Splashtop RMM | ✔ | | | | | Splashtop Streamer | | | ✔ | | | Steam | | ✔ (Windows) | ✔ (macOS) | | | Sublime Text (v3 and v4) | | ✔ | | | | Talkdesk Atlas | | ✔ | | | | TeamViewer | | ✔ | | | | TeamViewer Host | | | ✔ | | | The Unarchiver | ✔ | | | | | TigerVNC | | | | ✔ | | TightVNC | | | | ✔ | | TortoiseSVN | | ✔ | | | | Transmit | | ✔ | | | | Tunnelblick | | | ✔ | | | Twingate | | ✔ | | | | UltiMaker Cura | ✔ | | | | | VirtualBox | | ✔ | | | | Viscosity | | ✔ | | | | Vivaldi | | ✔ (macOS) | ✔ (Windows) | | | VLC Media Player | | ✔ | | | | VMware Horizon Client 7 | | ✔ | | | | VMware Workstation Player | | | | ✔ | | VNC Server | | | ✔ | | | VNC Viewer | | ✔ | | | | WinMerge | | | | ✔ | | WinRAR (EN & FR) | | ✔ | | | | WinSCP | | ✔ | | | | Wireshark | | ✔ | | | | Wondershare Anireel | | ✔ | | | | Wondershare Creative Center | | | ✔ | | | Wondershare DVD Creator | ✔ (macOS) | | ✔ (Windows) | | | Wondershare Filmora | | ✔ | | | | Wondershare PDFelement | ✔ (macOS) | ✔ (Windows) | | | | Wondershare UBackit | | ✔ | | | | Wondershare UniConverter (13, 14) | ✔ (macOS) | | ✔ (Windows) | | | X-Mouse Button Control | | | | ✔ | | XnView MP | | ✔ | | | | Yubico Authenticator | | ✔ | | | | YubiKey Manager | ✔ (macOS) | | | ✔ (Windows) | | Zoom | ✔ (macOS) | ✔ (Windows) | | | | Zoom Outlook Plugin | ✔ | | | | | Zoom Rooms (ZoomPresence on macOS) | | ✔ (macOS) | ✔ (Windows) | | | Zoom VDI Client | | ✔ | | | | Zoom VDI Plugin | ✔ | | | | | Zulu JDK (8, 11, 16, 17, 18, 19, 20, 21, 22, 25) | ✔ | | | | ## Third-Party Overrides Options The defined default patching behavior listed in the **App will NOT patch when running** column is intended to prevent patching of applications that are currently running. When this behavior is not appropriate for a given environment, you can choose to use a worklet to generate a local override file. After the overrides file is implemented, subsequent patch runs will honor the desired update behavior and force close the selected software titles. This is described in our Automox Worklets for Third-Party Overrides. **Note**: - Google Chrome for Windows (Product Name: “google_chrome”) can be configured for overrides even though it WILL patch when running. Setting this override will cause Automox to force close Chrome before patching so the new version is effective immediately. You can access the Automox-approved Third-Party Override Worklets from the Worklets Catalog in the console: - [MacOS - Software Lifecycle - Manage Third Party Override Options](https://console.automox.com/manage/worklet-catalog/cad79382-22db-51ba-9cae-23ba3caffc2c) - [Windows - Software Lifecycle - Manage Third Party Override Options](https://console.automox.com/manage/worklet-catalog/2f8c30c8-643a-5b79-82a6-62a2fea7b5ef) **Prerequisites**: - Your account plan must include Worklets. - You must have proper administrative privileges to access and manage Worklets. ## Related Topics - [Third-Party Software Support](Third_Party_Software_Support.htm) - [Naming Scheme for Third-Party Software Packages](Naming_Scheme_for_Third_Party_Software_Packages.htm) - [Roles and Permissions](../Global Access Management/Roles_and_Permissions.htm) - [Automox Pricing Plans](https://www.automox.com/pricing) --- # Third-Party Software Support _Section: Product Documentation › Third-Party Software • Source: https://docs.automox.com/product/Content/Product%20Documentation/Third-Party%20Software/Third_Party_Software_Support.htm_ In addition to patching the device operating system, Automox natively patches a catalog of third-party software. ## Supported and Patch Types | Software Title | Vendor | Windows | macOS | | --- | --- | --- | --- | | 1Password 8 | 1Password | ✔ (MSI) | ✔ (PKG) | | 3Dconnexion 3DxWare | 3Dconnexion UK | ✔ (EXE) | | | 7-Zip | 7-Zip | ✔ (EXE) | | | 8x8 Work | 8x8 Inc | ✔ (MSI) | ✔ (DMG) | | AbaClient | Abacus Research AG | ✔ (MSI) | ✔ (DMG) | | ActivePresenter (v6-v10) | Atomi Systems, Inc. | ✔ (EXE) | ✔ (DMG) | | Adobe Acrobat Pro DC | Adobe | ✔ (MSP) | ✔ (PKGinDMG) | | Adobe Acrobat Reader 2020 Classic (MUI) | Adobe | ✔ (MSP) | ✔ (PKGinDMG) | | Adobe Acrobat Reader DC | Adobe | ✔ (EXE,MSP) | ✔ (PKGinDMG) | | Adobe Acrobat Reader DC MUI | Adobe | ✔ (EXE,MSP) | | | Adobe Acrobat SCA DC | Adobe | | ✔ (PKGinDMG) | | Adobe Air (Harman) | Harman | ✔ (EXE) | ✔ (DMG) | | Adobe Digital Editions | Adobe | | ✔ (PKGinDMG) | | Advanced IP Scanner | Famatech Corp | ✔ (EXE) | | | Affinity Photo 2 | Affinity Photo | | ✔ (DMG) | | Agent Ransack | Mythicsoft | ✔ (MSI) | | | Ai2 Starter | Yutthana Meanphon | ✔ (EXE) | | | Aircall | Aircall | | ✔ (DMG) | | AirServer | App Dynamic | ✔ (MSI) | ✔ (DMG) | | Airtame | Airtame Inc. | ✔ (MSI) | ✔ (DMG) | | Algodoo | Algoryx | ✔ (EXE) | ✔ (DMG) | | Alice 3 | Carnegie Mellon University | ✔ (EXE) | | | Altova MapForce Enterprise (2020, 2020R2, 2021R2, 2023) | Altova | ✔ (EXE) | | | Altova MapForce Professional (2020, 2020R2, 2021R2, 2023) | Altova | ✔ (EXE) | | | Altova MissionKit Enterprise (2020, 2020R2, 2021R2, 2023, 2024, 2024R2, 2025, 2025R2, 2026) | Altova | ✔ (EXE) | | | Altova MissionKit Professional (2020, 2020R2, 2021R2, 2023, 2024, 2024R2, 2025, 2025R2, 2026) | Altova | ✔ (EXE) | | | Altova XMLSpy Enterprise (2020, 2020R2, 2021R2, 2023, 2024, 2024R2, 2025, 2025R2, 2026) | Altova | ✔ (EXE) | | | Altova XMLSpy Professional (2020, 2020R2, 2021R2, 2023, 2024, 2024R2, 2025, 2025R2, 2026) | Altova | ✔ (EXE) | | | Amazon AWS VPN Client | Amazon | ✔ (MSI) | ✔ (PKG) | | Amazon Chime | Amazon | | ✔ (DMG) | | Amazon Corretto (8, 11, 17, 18, 19, 21, 25) | Amazon | ✔ (MSI) | ✔ (PKG) | | Amazon Corretto 8 JRE | Amazon | ✔ (MSI) | | | Amazon WorkSpaces | Amazon | ✔ (MSI) | ✔ (PKG) | | Android Studio | Google | ✔ (EXE) | ✔ (DMG) | | AnyDesk | AnyDesk Software | ✔ (EXE,MSI) | ✔ (DMG) | | Archi | Archi | ✔ (EXE) | ✔ (DMG) | | Arduino IDE | Arduino | | ✔ (DMG) | | Artweaver Free | Boris Eyrich Software | ✔ (EXE) | | | Artweaver Plus 7 | Boris Eyrich Software | ✔ (EXE) | | | Asana | Asana, Inc. | | ✔ (DMG) | | ASAP Utilities | ASAP Utilities | ✔ (EXE) | | | Atlassian Companion | Atlassian | ✔ (MSI) | ✔ (DMG) | | Atom | Atom | | ✔ (ZIP) | | Attendant Pro | Landis Technologies LLC | ✔ (MSI) | | | Audacity | Audacity | ✔ (EXE) | ✔ (DMG) | | Authy Desktop | Twilio, Inc | | ✔ (DMG) | | Auto Dark Mode | Spiritreader | ✔ (EXE) | | | Autodesk Design Review 2018 | Autodesk | ✔ (MSP) | | | Autodesk Desktop Connector 16 | Autodesk | ✔ (EXE) | | | AutoIt | AutoIt Consulting Ltd | ✔ (EXE) | | | AutoText Master | Gillmeister Software | ✔ (EXE) | | | AWS CLI v2 | Amazon | ✔ (MSI) | ✔ (PKG) | | Azure Data Studio | Microsoft | ✔ (EXE) | ✔ (ZIP) | | Bandicam | Bandicam Company | ✔ (EXE) | | | Bandicut | Bandicam Company | ✔ (EXE) | | | Beeftext | Xavier Michelon | ✔ (EXE) | | | Beyond Compare (v4, v5) | Scooter Software, Inc. | ✔ (EXE,MSI) | ✔ (ZIP) | | BIMcollab ZOOM | KUBUS BV | ✔ (EXE) | | | BIMvision | Datacomp | ✔ (EXE) | | | Bitvise | Bitvise Limited | ✔ (EXE) | | | Bitwarden | Bitwarden, Inc. | ✔ (EXE) | ✔ (DMG) | | Blender | Blender | | ✔ (DMG) | | Bloomberg Terminal | Bloomberg Finance L.P. | ✔ (EXE) | | | Bluebeam OCR 20, 21 | Bluebeam | ✔ (MSI) | | | Bluebeam Revu 20, 21 | Bluebeam | ✔ (MSI) | | | BlueGriffon | Disruptive Innovations SAS | ✔ (EXE) | ✔ (DMG) | | BlueJ | BlueJ | ✔ (MSI) | ✔ (DMG) | | BlueJeans | BlueJeans by Verizon | ✔ (MSI) | ✔ (PKG) | | Box Drive | BoxDrive | ✔ (MSI) | ✔ (PKG) | | Boxcryptor | Secomba GmbH i.L. | ✔ (MSI) | ✔ (DMG) | | Brackets | Brackets.io | ✔ (EXE) | ✔ (DMG) | | Brave | Brave Software | ✔ (EXE) | ✔ (DMG) | | Breevy | 16 Software | ✔ (EXE) | | | Bulk Rename Utility | TGRMN Software | ✔ (EXE) | | | Bullzip PDF Printer | Bullzip | ✔ (EXE) | | | Bytello Share | Bytello | ✔ (MSI) | ✔ (DMG) | | Caffeine | Intelliscape Solutions | | ✔ (DMG) | | CalDavSynchronizer | Gerhard Zehetbauer | ✔ (MSI) | | | Calibre | KOVID GOYAL | ✔ (MSI) | ✔ (DMG) | | Camtasia (2018-2024) | TechSmith | ✔ (EXE) | ✔ (DMG) | | Canva | Canva | ✔ (MSIX) | ✔ (DMG) | | CCleaner | Piriform Software Ltd | | ✔ (PKGinDMG) | | CDBurnerXP | Impressum | ✔ (EXE) | | | Charles | XK72 | | ✔ (DMG) | | ChatGPT | OpenAI | | ✔ (DMG) | | Cisco Duo Device Health | Cisco | ✔ (MSI) | ✔ (PKG) | | Cisco Jabber | Cisco | ✔ (MSI) | ✔ (PKG) | | Cisco Jabber VDI Client | Cisco | ✔ (MSI) | ✔ (PKG) | | Cisco Webex | Cisco | ✔ (MSI) | ✔ (DMG) | | Citrix Workspace | Citrix | ✔ (EXE) | ✔ (PKGinDMG) | | Claude Desktop App | Anthropic | ✔ (MSIX) | ✔ (PKG) | | ClickShare Desktop App | Barco | | ✔ (DMG) | | ClickUp | ClickUp | | ✔ (DMG) | | CLion (2024.1, 2025.1, 2025.2, 2025.3) | JetBrains | ✔ (EXE) | ✔ (DMG) | | Clip2Net | Clip2Net | ✔ (EXE) | | | Clockify | Clockify | ✔ (MSI) | ✔ (ZIP) | | Cloudflare Warp Client | Cloudflare, Inc. | ✔ (MSI) | ✔ (PKG) | | Cloudya with CRM | NFON | ✔ (MSI) | ✔ (DMG,PKG) | | CMake | CMake | ✔ (MSI) | ✔ (DMG) | | Cold Turkey Blocker | Cold Turkey Software Inc. | ✔ (EXE) | ✔ (PKG) | | Commander One | Electronic Team Inc | | ✔ (DMG) | | ConEmu | ConEmu | ✔ (EXE) | | | CPUID CPU-Z Classic | CPUID | ✔ (EXE) | | | CPUID HWMonitor | CPUID | ✔ (EXE) | | | CPUID Perfmonitor-2 | CPUID | ✔ (EXE) | | | Creality Slicer | Creality Cloud | ✔ (EXE) | ✔ (DMG) | | Creo View Express | PTC | ✔ (EXE) | | | CryptoPrevent | Foolish IT LLC | ✔ (EXE) | | | CrystalDiskInfo | Crystal Dew World | ✔ (EXE) | | | Cursor | Anysphere Inc | ✔ (EXE) | ✔ (DMG) | | Cyberduck | CyberDuck | ✔ (EXE) | ✔ (ZIP) | | Datadog Agent | Datadog | ✔ (MSI) | | | DataGrip (2023.3, 2024.1, 2025.1, 2025.2, 2025.3) | JetBrains | ✔ (EXE) | ✔ (DMG) | | DAX Studio | DAX Studio | ✔ (EXE) | | | DB Browser for SQLite | DB4S | ✔ (MSI) | ✔ (DMG) | | DBeaver Community Edition | DBeaver Corp | ✔ (EXE) | ✔ (DMG) | | DbVis | DbVis Software AB | ✔ (EXE) | ✔ (DMG) | | Deezer | Deezer | | ✔ (DMG) | | Dell Command Update - Windows Universal | Dell | ✔ (EXE) | | | Dell Display Manager 2.x | Dell | ✔ (EXE) | | | Dependency Agent | Microsoft | ✔ (EXE) | | | Devolutions Remote Desktop Manager - Enterprise Edition | Devolutions | ✔ (EXE) | ✔ (DMG) | | Dialpad | Dialpad | ✔ (MSI) | ✔ (PKG) | | DisplayFusion | Binary Fortress Software | ✔ (EXE,MSI) | | | DisplayLink Graphics | Synaptics Incorporated | ✔ (EXE) | ✔ (PKG) | | Docker Desktop | Docker | ✔ (EXE) | ✔ (DMG) | | Double Commander | alexx2000 | | ✔ (DMG) | | Draw.io | draw.io | | ✔ (DMG) | | Dropbox | Dropbox | ✔ (EXE) | ✔ (DMG) | | Dropbox Capture | Dropbox | | ✔ (DMG) | | Druva inSync | Druva | ✔ (MSI) | ✔ (PKGinDMG) | | DYMO Label | DYMO, Inc. | ✔ (MSI) | ✔ (PKGinDMG) | | Egnyte Desktop App | Egnyte | ✔ (MSI) | ✔ (PKG) | | Ekahau AI Pro | Ekahau | ✔ (EXE) | ✔ (DMG) | | ePlayerPro | Johnson Controls | | ✔ (DMG) | | Epson Easy Interactive Tools | Epson America, Inc. | ✔ (MSI) | ✔ (PKGinDMG) | | Evernote | Evernote Corporation | ✔ (EXE) | ✔ (DMG) | | Everything | Voidtools | ✔ (EXE) | | | Exacqvision VMS Client | Johnson Controls | ✔ (MSI) | ✔ (DMG) | | ezCheckPrinting 9 | halfpricesoft | ✔ (MSI) | | | FileZilla Client | FileZilla | ✔ (EXE) | ✔ (TAR.BZ2) | | FileZilla Server | FileZilla | ✔ (EXE) | ✔ (PKG) | | Foxit PDF Editor (11, 12, 13, 14, 2025) | Foxit Software | ✔ (MSP) | | | Foxit PDF Reader | Foxit Software | ✔ (EXE) | ✔ (PKG) | | GameMaker Studio | YoYo Games Ltd. | ✔ (EXE) | ✔ (PKG) | | Garmin Express | Garmin Ltd | ✔ (EXE) | ✔ (PKGinDMG) | | GCompris Educational Software | Timothee Giet et al | ✔ (EXE) | ✔ (DMG) | | Genesys Cloud | Genesys | ✔ (EXE) | ✔ (DMG) | | GIMP | GIMP | ✔ (EXE) | | | Git | Git | ✔ (EXE) | | | Git Extensions | GitHub, Inc. | ✔ (MSI) | | | Github Desktop | GitHub, Inc. | | ✔ (ZIP) | | GitKraken | Axosoft, LLC | | ✔ (DMG) | | GlassWire | GlassWire | ✔ (EXE) | | | GNU Emacs | GNU | | ✔ (DMG) | | Go Connect | Go Connect | | ✔ (DMG) | | GoodSync | Siber Systems, Inc. | ✔ (EXE) | | | Google Chrome | Google | ✔ (MSI) | ✔ (DMG) | | Google Drive | Google | ✔ (EXE) | ✔ (PKGinDMG) | | Google Earth Pro | Google | ✔ (EXE) | ✔ (PKGinDMG) | | GoTo Connect | GoTo | ✔ (MSI) | ✔ (DMG) | | GoTo Opener | GoTo | ✔ (MSI) | | | Gpg4win | Gpg4win Initiative | ✔ (EXE) | | | Grammarly Desktop | Grammarly Inc. | ✔ (EXE) | | | Graphmatica | kSoft, Inc. | ✔ (MSI) | | | Greenfoot | Greenfoot | ✔ (MSI) | ✔ (DMG) | | Greenshot | Greenshot | ✔ (EXE) | | | grepWin | Stefan Kueng | ✔ (MSI) | | | HandBrake | HandBrake | ✔ (EXE) | ✔ (DMG) | | HeidiSQL | HeidiSQL | ✔ (EXE) | | | Hot Potatoes | Half-Baked Software | ✔ (EXE) | | | Hubstaff | Netsoft Holdings LLC | ✔ (EXE) | ✔ (DMG) | | IcyScreen | 16 Software | ✔ (EXE) | | | ideaMaker | Raise 3D Technologies, Inc. | | ✔ (DMG) | | ImgBurn | Lightning UK | ✔ (EXE) | | | Inkscape | Inkscape | ✔ (MSI) | | | IntelliJ IDEA Community Edition (2021.1, 2021.2, 2021.3, 2022.1, 2022.2, 2022.3, 2023.1, 2024.1, 2024.2, 2024.3, 2025.1, 2025.2) | JetBrains | ✔ (EXE) | ✔ (DMG) | | IntelliJ IDEA Ultimate (2021.1, 2021.2, 2021.3, 2022.1, 2022.2, 2022.3, 2023.1, 2024.1, 2024.3, 2025.1, 2025.2, 2025.3) | JetBrains | ✔ (EXE) | ✔ (DMG) | | iTerm2 | iTerm2 | | ✔ (ZIP) | | iTunes | Apple | ✔ (EXE) | | | Jabra Direct | Jabra | ✔ (EXE) | | | JAWS 2022 | Freedom Scientific | ✔ (EXE) | | | KeePass 1.x | Dominik Reichl | ✔ (EXE) | | | KeePass 2.x | KeePass | ✔ (EXE) | | | KeePassXC | KeePassXC | ✔ (MSI) | ✔ (DMG) | | Keeper | Keeper Security | ✔ (MSI) | ✔ (DMG) | | Leaklog | Slovak Association | ✔ (EXE) | ✔ (ZIP) | | LEGO Education SPIKE | The LEGO Group | ✔ (MSI) | ✔ (DMG) | | LibreOffice | LibreOffice | ✔ (MSI) | ✔ (DMG) | | Logitech Bolt | Logitech | ✔ (EXE) | | | Logitech Options Plus | Logitech | ✔ (EXE) | | | Logitech SetPoint | Logitech | ✔ (EXE) | | | Logitech Unifying Software | Logitech | ✔ (EXE) | | | Microsoft Azure CLI | Microsoft | ✔ (MSI) | | | Microsoft Azure Storage Explorer | Microsoft | ✔ (EXE) | ✔ (ZIP) | | Microsoft Edge | Microsoft | ✔ (MSI) | ✔ (PKG) | | Microsoft Office (2016, 2019, 2021, O365) | Microsoft | ✔ (OfficeC2R) | ✔ (msupdate) | | Microsoft OneDrive | Microsoft | ✔ (EXE) | ✔ (PKG) | | Microsoft OpenJDK (21, 25) | Microsoft | ✔ (MSI) | ✔ (PKG) | | Microsoft PowerBI Desktop | Microsoft | ✔ (EXE) | | | Microsoft PowerToys | Microsoft | ✔ (EXE) | | | Microsoft Project | Microsoft | ✔ (OfficeC2R) | | | Microsoft Remote Desktop | Microsoft | ✔ (MSI) | ✔ (PKG) | | Microsoft Skype | Microsoft | ✔ (MSI) | ✔ (DMG) | | Microsoft SQL OLE DB Driver 18 and 19 | Microsoft | ✔ (MSI) | | | Microsoft SQL Server Management Studio 18, 19, 20 | Microsoft | ✔ (EXE) | | | Microsoft Teams | Microsoft | | ✔ (PKG) | | Microsoft Teams Machine-Wide Installer | Microsoft | ✔ (MSI) | | | Microsoft Teams New | Microsoft | | ✔ (PKG) | | Microsoft Visio | Microsoft | ✔ (OfficeC2R) | | | Microsoft Visual C++ Redistributable v14 (2015-2026) | Microsoft | ✔ (EXE) | | | Microsoft Visual Studio Build Tools 2019, 2022 (Current, Spring 2023, 2022 LTSC & Fall 2022 LTSC) | Microsoft | ✔ (EXE) | | | Microsoft Visual Studio Code | Microsoft | ✔ (EXE) | ✔ (ZIP) | | Microsoft Visual Studio Community 2022 | Microsoft | ✔ (EXE) | | | Microsoft Visual Studio Enterprise 2019, 2022 (Current, Spring 2023, 2022 LTSC & Fall 2022 LTSC) | Microsoft | ✔ (EXE) | | | Microsoft Visual Studio Professional 2019, 2022 (Current, Spring 2023, 2022 LTSC & Fall 2022 LTSC) | Microsoft | ✔ (EXE) | | | Mozilla Firefox | Mozilla | ✔ (EXE) | ✔ (DMG) | | Mozilla Firefox Developer | Mozilla | ✔ (EXE) | ✔ (DMG) | | Mozilla Firefox ESR | Mozilla | ✔ (EXE) | ✔ (DMG) | | Mozilla SeaMonkey | Mozilla | ✔ (EXE) | ✔ (DMG) | | Mozilla Thunderbird | Mozilla | ✔ (EXE) | ✔ (DMG) | | MTPuTTY | TTY Plus | ✔ (EXE) | | | MySQL Workbench CE | Oracle | ✔ (MSI) | ✔ (DMG) | | Node.js Current | OpenJS | ✔ (MSI) | | | Node.js LTS | OpenJS | ✔ (MSI) | | | NoMachine Enterprise Client | NoMachine | ✔ (EXE) | ✔ (PKGinDMG) | | Notepad++ | NotepadPlusPlus | ✔ (EXE) | | | Notion | Notion Labs, Inc | ✔ (EXE) | ✔ (DMG) | | Nudge | Thoughtful Systems | | ✔ (PKG) | | OBS Studio | OBS Project | ✔ (EXE) | ✔ (DMG) | | Obsidian | Obsidian | | ✔ (DMG) | | Octave | John W. Eaton | ✔ (EXE) | ✔ (DMG) | | ODBC Driver for SQL Server (17, 18) | Microsoft | ✔ (MSI) | | | Omnissa Horizon Client 8 | Omnissa | ✔ (EXE) | ✔ (PKGinDMG) | | OpenVPN Connect | OpenVPN Inc. | ✔ (MSI) | ✔ (PKG) | | Opera | Opera | ✔ (EXE) | ✔ (DMG) | | Oracle Java (JRE) 6, 7, 8 | Oracle | ✔ (EXE) | ✔ (PKGinDMG) | | Oracle Java SE 17, 18, 19, 20, 21, 25, 26 | Oracle | ✔ (MSI) | ✔ (PKGinDMG) | | Paint.NET | dotPDN LLC | ✔ (MSI) | | | Pale Moon | Moonchild Productions | ✔ (EXE) | ✔ (DMG) | | Parallels RAS | Parallels International GmbH | ✔ (MSI) | ✔ (PKG) | | Parallels Toolbox | Parallels | ✔ (EXE) | | | PDF Reader Pro | PDF Technologies | ✔ (EXE) | ✔ (DMG) | | PDF-XChange Editor | Tracker Software | ✔ (MSI) | | | PDF24 Creator | geek software GmbH | ✔ (MSI) | | | Perimeter 81 VPN | Perimeter 81 | ✔ (MSI) | ✔ (PKG) | | pgAdmin 4 | pgAdmin | ✔ (EXE) | ✔ (DMG) | | PictoBlox | Agilo Research Pvt. Ltd. | | ✔ (DMG) | | Pidgin | Pidgin | ✔ (EXE) | | | Plantronics Hub | Plantronics, Inc. | ✔ (EXE) | ✔ (PKGinDMG) | | Poly Studio (Lens) | HP, Inc. | ✔ (MSI) | ✔ (PKGinDMG) | | Postman | Postman | ✔ (EXE) | ✔ (ZIP) | | Proton VPN | ProtonVPN | ✔ (EXE) | ✔ (DMG) | | PuTTY | Putty | ✔ (MSI) | | | PyCharm Community Edition (2024.1, 2025.1, 2025.2) | JetBrains | ✔ (EXE) | ✔ (DMG) | | PyCharm Professional (2024.1, 2025.1, 2025.2, 2025.3) | JetBrains | ✔ (EXE) | ✔ (DMG) | | QZ Tray | QZ | ✔ (EXE) | | | Recoverit | Wondershare | ✔ (EXE) | | | RemotePC Host | IDrive Inc | ✔ (EXE) | ✔ (PKGinDMG) | | RingCentral | RingCentral | ✔ (MSI) | ✔ (PKG) | | Royal TS 6 | Royal Apps | ✔ (MSI) | ✔ (DMG) | | Royal TS 7 | Royal Apps | ✔ (MSI) | | | RStudio Desktop | Posit Software | ✔ (EXE) | ✔ (DMG) | | RubyMine (2024.1, 2025.1, 2025.2, 2025.3) | JetBrains | ✔ (EXE) | ✔ (DMG) | | Seagull Scientific BarTender 2022 | Seagull Scientific, LLC | ✔ (EXE) | | | Sequel Pro | SequelPro | | ✔ (DMG) | | Signal Desktop | Signal Messenger | ✔ (EXE) | ✔ (DMG) | | SigWeb | Topaz Systems, Inc. | ✔ (EXE) | | | SizeUp | SizeUp | | ✔ (ZIP) | | Slack | Slack | ✔ (MSI) | ✔ (DMG) | | Snagit (2018-2026) | TechSmith | ✔ (EXE) | ✔ (DMG) | | SoapUI | SmartBear | ✔ (EXE) | | | Sourcetree | Atlassian | | ✔ (ZIP) | | Splashtop Remote Access | Splashtop | ✔ (MSI) | ✔ (PKGinDMG) | | Splashtop RMM | Splashtop | ✔ (MSI) | ✔ (PKGinDMG) | | Splashtop Streamer | Splashtop | ✔ (EXE) | ✔ (PKGinDMG) | | Steam | Valve Corporation | ✔ (EXE) | ✔ (DMG) | | Sublime Text (v3 and v4) | Sublime HQ | ✔ (EXE) | ✔ (DMG,ZIP) | | Talkdesk Atlas | Talkdesk | ✔ (MSI) | ✔ (DMG) | | TeamViewer | TeamViewer | ✔ (EXE) | | | TeamViewer Host | TeamViewer | ✔ (EXE) | ✔ (PKGinDMG) | | The Unarchiver | TheUnarchiver | | ✔ (ZIP) | | TigerVNC | TigerVNC | ✔ (EXE) | | | TightVNC | GlavSoft | ✔ (MSI) | | | TortoiseSVN | tortoisesvn | ✔ (MSI) | | | Transmit | Transmit | | ✔ (ZIP) | | Tunnelblick | Tunnelblick | | ✔ (DMG) | | Twingate | Twingate | ✔ (MSI) | | | UltiMaker Cura | UltiMaker | ✔ (EXE) | ✔ (DMG) | | VirtualBox | Oracle | ✔ (EXE) | ✔ (PKGinDMG) | | Viscosity | Viscosity | ✔ (EXE) | ✔ (DMG) | | Vivaldi | Vivaldi | ✔ (EXE) | ✔ (DMG) | | VLC Media Player | VideoLAN | ✔ (EXE) | ✔ (DMG) | | VMware Horizon Client 7 | Broadcom Inc. | ✔ (EXE) | ✔ (DMG) | | VMware Workstation Player | Broadcom Inc. | ✔ (EXE) | | | VNC Server | RealVNC Limited | ✔ (EXE) | | | VNC Viewer | RealVNC Limited | ✔ (EXE) | ✔ (DMG) | | WinMerge | WinMerge | ✔ (EXE) | | | WinRAR (EN & FR) | WinRAR | ✔ (EXE) | | | WinSCP | WinSCP | ✔ (EXE) | | | Wireshark | Wireshark | ✔ (EXE) | ✔ (DMG) | | Wondershare Anireel | Wondershare | ✔ (EXE) | | | Wondershare Creative Center | Wondershare | ✔ (EXE) | | | Wondershare DVD Creator | Wondershare | ✔ (EXE) | ✔ (DMG) | | Wondershare Filmora | Wondershare | | ✔ (DMG) | | Wondershare PDFelement | Wondershare | ✔ (EXE) | ✔ (DMG) | | Wondershare UBackit | Wondershare | ✔ (EXE) | | | Wondershare UniConverter (13, 14) | Wondershare | ✔ (EXE) | ✔ (ZIP) | | X-Mouse Button Control | Phillip Gibbons | ✔ (EXE) | | | XnView MP | XnViewMP | ✔ (EXE) | ✔ (DMG) | | Yubico Authenticator | yubico | ✔ (MSI) | ✔ (DMG) | | YubiKey Manager | Yubico AB | ✔ (EXE) | ✔ (PKG) | | Zoom | Zoom | ✔ (MSI) | ✔ (PKG) | | Zoom Outlook Plugin | Zoom | ✔ (MSI) | ✔ (PKG) | | Zoom Rooms (ZoomPresence on macOS) | Zoom | ✔ (MSI) | ✔ (PKG) | | Zoom VDI Client | Zoom | ✔ (MSI) | | | Zoom VDI Plugin | Zoom | ✔ (MSI) | ✔ (PKG) | | Zulu JDK (8, 11, 16, 17, 18, 19, 20, 21, 22, 25) | Azul Systems | ✔ (MSI) | ✔ (PKGinDMG) | ## Linux third-party patching Automox does not cache packages for Linux operating systems. Third-party patching is supported for any software installed using the device’s package manager or a repository. Repositories must remain active, and in the system's repo directory, to ensure successful patching. ## Intel-based applications on M1 devices Native support for Mac M1 architecture is dependent on the software vendor. While many vendors are still working to make their product compatible with the M1 CPU, Apple has provided support for Intel-based apps on M1 devices using the Rosetta 2 Translation Environment. ## Foxit PDF Editor 11 If you have a version of [Foxit PDF 11](https://www.foxit.com/pdf-editor/) before v11.2.2 and want to use required software policies (see [Creating a Required Software Policy](../Policies/Creating_a_Required_Software_Policy.htm)) for updates, you need to take note of the two package names that Automox lists in our [Naming Scheme for Third-Party Software Packages](Naming_Scheme_for_Third_Party_Software_Packages.htm). Devices enrolled in a third-party patching policy automatically receive both updates, if required, during the patch process. ## Mozilla Firefox Automox supports all language packs from Firefox that are supported on Windows and macOS. Access to the following URLs is required: - http://download.mozilla.org - https://download.mozilla.org **Note:** Language detection only works for Firefox ESR versions 91 and later, Dev editions 80 and later, and public releases 80 and later. Installing older versions of Firefox will result in the installed language being changed to English (en-US) at time of patching. ## Google Chrome requirements (updated) As of August 29, 2024, Google Chrome for Windows is now patched directly by Automox and no longer uses Google’s built-in updater (GoogleUpdate.exe). ## MS Office 365 requirements MS Office 365 requires access to the following URLs: - *.microsoft.com - *.msocdn.com - *.office.com - *.office.net - *.onmicrosoft.com - officecdn.microsoft.com - officecdn.microsoft.com.edgesuite.net. See also [Microsoft 365 Common and Office Online](https://docs.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges#microsoft-365-common-and-office-online) **Note**: Automox only supports Microsoft 365 apps on Mac devices that were downloaded directly from Microsoft. ## Microsoft Teams Machine-Wide Installer (Windows) The [Microsoft Teams Machine-Wide Installer](https://learn.microsoft.com/en-us/microsoftteams/msi-deployment) must be installed with the “ALLUSERS=1” option, to enable patching on Windows. The “.exe” installation is not supported. msiexec /i Teams_windows_x64.msi ALLUSERS=1 ## Bitwarden (Windows) Bitwarden ([EXE download](https://vault.bitwarden.com/download/?app=desktop&platform=windows&variant=exe)) must be installed with the “/allusers” option, to enable patching on Windows. Bitwarden-Installer-2024.5.0.exe /allusers ## Canva (Windows) Automox supports patching for the [MSIX Desktop App installer](https://www.canva.com/help/msix-installer/) of Canva on Windows. The software must be installed “per-machine via provisioning”, as detailed in the Canva install instructions. Add-AppxProvisionedPackage -Online -SkipLicense -PackagePath "C:\path\to\installer.msix" ## PuTTY (Windows) Automox supports patching for PuTTY ONLY when installed using the MSI package with the “ALLUSERS=1” option. The current MSI can be found [here](https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html). The correct installation is as follows: msiexec /i putty-64bit-0.81-installer.msi ALLUSERS=1 ## Talkdesk Atlas (Windows) Automox supports patching for Talkdesk ONLY when installed using the MSI package, which installs for all users. The current MSI can be found [here](https://www.mytalkdesk.com/atlas/download) (use the drop-down menus to select **Windows MSI** and the latest version). ## Related Topics - [Third-Party Patching Best Practices](Third_Party_Patching_Best_Practices.htm) - [Naming Scheme for Third-Party Software Packages](Naming_Scheme_for_Third_Party_Software_Packages.htm) - [Adobe Flash Player EOL General Information Page](https://www.adobe.com/products/flashplayer/end-of-life.html) - [Workaround To Patch Adobe Acrobat Reader DC 32-bit in Windows](https://community.automox.com/automox-q-a-9/workaround-to-patch-adobe-acrobat-reader-dc-32-bit-in-windows-915) - [Apple Silicon (M1) Support](Apple_Silicon__M1__Support.htm) - [End of Life for Adobe Shockwave](https://helpx.adobe.com/shockwave/shockwave-end-of-life-faq.html) - [Vendor-Supported Patching Program](https://patch.automox.com/rs/923-VQX-349/images/vendor-supported-patching-program.pdf) - [Cannot See a CVE That is for Office or Other Third-Party Supported Software](https://help.automox.com/hc/en-us/articles/15807470972180) --- # How to Get a List of Devices with a Specific Patch Installed _Section: Product Documentation › Troubleshooting • Source: https://docs.automox.com/product/Content/Product%20Documentation/Troubleshooting/How_to_Get_a_List_of_Devices_with_a_Specific_Patch_Installed.htm_ Follow these instructions to get a list of devices with a specific patch installed. 1. Navigate to Automate **Software** page in the Automox console and locate the package you want to query against: ![](../../Resources/Images/software.png) - If you are unable to find the package you are looking for, try using the filter panel and search bar to better narrow down the result set. - You can also clear the **Automox Supported** checkbox to include packages that Automox has detected but does not support patching for. - For details about using the search functionality, see [Filtering and Searching on the Software Page](../Software/Filtering_and_Searching_on_the_Software_Page.htm). 2. After you locate your target package, click the number in the **Updated** column. This link opens the **Devices** page and queries against your list of devices using the selected package ID. ![](../../Resources/Images/listofdevices.png) ## Related Topics - [Filtering and Searching on the Software Page](../Software/Filtering_and_Searching_on_the_Software_Page.htm) - See also the [API documentation](https://developer.automox.com/developer-portal/) --- # Troubleshooting the Automox Agent Installation on macOS _Section: Product Documentation › Troubleshooting • Source: https://docs.automox.com/product/Content/Product%20Documentation/Troubleshooting/Troubleshooting_the_Automox_Agent_Installation_on_macOS.htm_ To install, restart, and remove the Automox agent on macOS devices, refer to the commands listed here. ## Install the Automox agent To install the Automox agent on macOS, run this command. (This requires your access key. See [Managing Keys](../Settings/Managing_Keys.htm).) curl -sS "https://console.automox.com/downloadInstaller?accesskey=YOUR_ORGANIZATION_KEY_HERE" | sudo bash && sudo launchctl load /Library/LaunchDaemons/com.automox.agent.plist ## Inspect the process Determine if the Automox agent is running: ps aux | grep amagent ## Restart the agent ### Unload the agent: sudo launchctl bootout system/com.automox.agent ### Load the agent: sudo launchctl bootstrap system /Library/LaunchDaemons/com.automox.agent.plist ## Uninstall agent: sudo launchctl bootout system/com.automox.agent || true sudo /usr/local/bin/amagent --deregister sudo rm -f /usr/local/bin/amagent* sudo rm -rf "/Library/Application Support/Automox/" sudo rm -f /Library/LaunchDaemons/com.automox.agent* sudo rm -rf /var/tmp/automox/ || true sudo rm -f /var/tmp/amagent* || true sudo /usr/bin/dscl . -delete /Users/_automoxserviceaccount ## Related Topics - [Automox Agent Installation Overview](../Agents/Agent Installation/Automox_Agent_Installation_Overview.htm) --- # About Automox Vulnerability Sync _Section: Product Documentation › Vulnerability Sync • Source: https://docs.automox.com/product/Content/Product%20Documentation/Vulnerability%20Sync/About_Automox_Vulnerability_Sync.htm_ Automox Vulnerability Sync enables you to upload reports from a vulnerability scanner and organize vulnerabilities into tasks. A vulnerability scan (a CSV vulnerability report from your preferred vulnerability scanner) must identify CVE IDs (common vulnerability enumerators) and hostnames. When a .CSV file is successfully synced, Automox creates remediations grouped by the patch that applies to CVEs and devices in the file. The CVE and severity data mapping is based on our internal vulnerability mapping (see [Understanding Automox Severity Data](../Patching/Understanding_Automox_Severity_Data.htm)). This task service also shows when hostnames are not found (due to a missing Automox agent), when duplicate hostnames are listed, and when CVEs are uploaded from the CSV file that Automox is not aware of. This can be because either Automox has not yet synced the threat data, or the CVE is associated with a third-party application or a macOS device that Automox does not yet have vulnerability mapping for. In addition, you can review real-time task execution statistics including device-level details about success, failure, and other remediation processes/results. Summaries of execution statistics for individual tasks are also available to review. Limitations: - Remediation is currently for Windows and Linux OS only - The Automox agent must be installed on the devices - You cannot defer tasks - If devices require a restart to finish the process, the remediation does not happen automatically - Notifications and patch deferrals are not currently available - You cannot stop a task after it has started - The upload file requirements: CSV format, less than 1 GB in size, must include hostname and CVE number --- # Exporting Vulnerability Scanner Reports _Section: Product Documentation › Vulnerability Sync • Source: https://docs.automox.com/product/Content/Product%20Documentation/Vulnerability%20Sync/Exporting_Vulnerability_Scanner_Reports.htm_ To use the vulnerability sync feature, you must generate a report using your third-party vulnerability scanner. This document lists the types of vendor reports that are currently supported. **Requirements for the CSV import**: - The first line in each CSV must contain the required data, depending on your CSV provider. For example: `hostname, cve id`. Follow the format requirements as noted in the console (**Add New Task** dialog window). - Hostnames are not case-sensitive. - Hostnames should not be wrapped in any quotes, parenthesis, brackets, or single tics. - The CVE field should not contain any special characters. You can include dashes, for example: CVE-2021-1234, or commas for a list of CVEs. - Severity is an optional field. - Severities must use one of the following keywords unless otherwise indicated: **Critical**, **High**, **Medium**, **Low** - The CSV report must be less than 1 GB. - The CSV row maximum is 1 million rows. Example CSV file: Hostname, CVE ID, Severity finance-laptop,cve-2021-1234,high finance-laptop,cve-2021-6789 finance-laptop,cve-2021-5522,critical sales_laptop,cve-2021-9944,medium **Note**: Using Notepad++ to open and save vulnerability scanner exports introduces hidden characters and can cause the manual import to fail. Automox recommends using a different source code editor. ## Crowdstrike Falcon Spotlight - Vulnerability Report Follow these instructions to download a vulnerability report from the Crowdstrike Falcon Spotlight platform. - From the Crowdstrike dashboard, ensure that the report identifies hostnames and CVE IDs. - Be sure to include relevant filters as there is a file size limit for the ingest of 1 GB. - Additionally, be aware that more CVE IDs mean more tasks for Automox to create. Example of CrowdStrike’s Spotlight Vulnerability Dashboard. **Note**: You can filter on relevant vulnerabilities for the export. ![](../../Resources/Images/CS-spotlight-example.png) - Select the file format CSV and export the report. ![](../../Resources/Images/CS-spotlight-export.png) ## Rapid7 - Vulnerability Report Export Follow these instructions to manually create and export a vulnerability report from Rapid7 InsightVM/Nexpose. **Note:** If you are using the **Rapid7 InsightConnect**, you do not need to manually export a vulnerability report from Rapid7 InsightVM/Nexpose. The vulnerability sync workflow bypasses the manual need to export and upload the report to Automox. When the synced imported report is ready, you can continue with the vulnerability process from the point of observing the mapping process until it is complete and take actions as required. Follow the description in the Vulnerability Sync documentation: [Using Automox Vulnerability Sync](Using_Automox_Vulnerability_Sync.htm) → Syncing the Imported Report. See also [Automox Plugin for Rapid7 InsightConnect](../Automox Integrations/Automox_Plugin_for_Rapid7_InsightConnect.htm). **Requirements**: You must use the on-premise console to generate the report. ### Creating a Rapid7 vulnerability report To export vulnerability findings from Rapid7 InsightVM/Nexpose in a format that is quickly imported into Automox, we recommend creating a Custom SQL Report. This can be done within the InsightVM console by following these steps: 1. Navigate to **Reports**. 2. On the Create a Report page, select **Export**. 3. Select **SQL Query Export** from the list of templates. 4. Add the query for the custom report and validate. 5. Save and run the report. As new scans are performed, your Vulnerability Management team can regenerate reports and scope them to the groups, sites, and categories they are hoping to target. If the SQL query is modified for your environment needs, ensure the **hostname** and **cve id** fields are headers within the report export. ### Query for custom SQL report In the InsightVM/Nexpose Console, create a custom SQL Report using the following query: select favf.asset_id, favf.vulnerability_id, da.host_name as hostname, dvf.reference as "cve id" FROM fact_asset_vulnerability_finding favf JOIN dim_vulnerability_reference dvf ON dvf.vulnerability_id = favf.vulnerability_id JOIN dim_asset da ON da.asset_id = favf.asset_id WHERE dvf.source = 'CVE' That query yields a result something like the following: asset_id, vulnerability_id, hostname, cve id 18, 200, hostname-1, CVE-2017-8682 Make sure that you save it in CSV format and use that file to upload into the console. Feel free to apply other filters to the SQL report. See also the following example queries for Rapid7 vulnerability reports: ### Query for vulnerabilities with severity of Critical This query creates a report for CVEs with a severity level of "critical". select favf.asset_id, favf.vulnerability_id, da.host_name as hostname, dvf.reference as "cve id" FROM fact_asset_vulnerability_finding favf JOIN dim_vulnerability_reference dvf ON dvf.vulnerability_id = favf.vulnerability_id JOIN dim_vulnerability dv ON favf.vulnerability_id = dv.vulnerability_id JOIN dim_asset da ON da.asset_id = favf.asset_id WHERE dvf.source = 'CVE' and dv.severity = 'Critical' ### Query for vulnerabilities by specific CVEs This query creates a report for a specific CVE. select favf.asset_id, favf.vulnerability_id, da.host_name as hostname, dvf.reference as "cve id" FROM fact_asset_vulnerability_finding favf JOIN dim_vulnerability_reference dvf ON dvf.vulnerability_id = favf.vulnerability_id JOIN dim_asset da ON da.asset_id = favf.asset_id WHERE dvf.reference = 'CVE-1234' If you need additional assistance or want to modify the query, use the Rapid7 documentation located here: [Creating reports based on SQL queries](https://docs.rapid7.com/insightvm/creating-reports-based-on-sql-queries/) ## Tenable.io - CSV Vulnerability Export To download a vulnerability report from [Tenable.io](http://tenable.io/), follow the documentation as described here: [Tenable Documentation: Export Vulnerability Data](https://docs.tenable.com/security-center/Content/ExportVulnerabilityData.htm) When exporting vulnerability data, you must include the following fields in the report: - Host - CVE - Risk After exporting the data, you generally do not need to modify the report to upload it to Automox as long as you select **Tenable Vulnerability Management** for the CSV Provider. **Note**: It is recommended that you always verify that the headers are in the expected format. ![](../../Resources/Images/import-csv-tenable.png) ## Qualys - Scan Report By exporting a Qualys New Scan Report, you can upload vulnerability details from Qualys scans to remediate devices. To generate a scan report, navigate to **Reports → Templates → New Scan Template** When Creating the Report Template, select **Vulnerability Details** to ensure that CVE information is included in the report. The Qualys report includes IP addresses and a list of CVE IDs for correlating with Automox. No modifications to the report are necessary in order to upload to Automox as long as you select **Qualys** for the CSV Provider: ![](../../Resources/Images/import-csv-qualys.png) ## Related Topics - [Using Automox Vulnerability Sync](Using_Automox_Vulnerability_Sync.htm) - [About Automox Vulnerability Sync](About_Automox_Vulnerability_Sync.htm) - [Upload a CSV file to Automox through API](https://developer.automox.com/openapi/axconsole/operation/uploadRemediationCSV/) --- # Using Automox Vulnerability Sync _Section: Product Documentation › Vulnerability Sync • Source: https://docs.automox.com/product/Content/Product%20Documentation/Vulnerability%20Sync/Using_Automox_Vulnerability_Sync.htm_ From the **Automate → Remediations** page, you can organize vulnerabilities into Automox ## Download a CSV-formatted Vulnerability Report Follow the instructions in [Exporting Vulnerability Scanner Reports](Exporting_Vulnerability_Scanner_Reports.htm) to download a CSV-formatted vulnerability report from your third-party vulnerability scanner. ## Viewing Remediations Click the **Automate** tab and select **Remediations → Manual**. ![](../../Resources/Images/remediations-manual.png) ## Uploading a Vulnerability Report to Create Tasks You can upload a CSV-formatted vulnerability report from a variety of different CSV providers and start adding tasks. **Note:** - The maximum file size for CSV uploads is 1 million rows. - **If you are accessing the Remediations page for the first time**, you may see the options manual import or partner integration. Select the **Get Started** button for manual import and follow the steps here. - Using Notepad++ to open and save vulnerability scanner exports introduces hidden characters and can cause the manual import to fail. Automox 1. From the **Remediations → Manual**tab, click **Import.** ![](../../Resources/Images/add-new-task.png) 2. Select the CSV provider format for the report that you want to upload. ![](../../Resources/Images/add-task-csvprovider.png) **Note**: The format required for the report is listed in the Expected Format field. Refer to that to ensure that the uploaded file meets the requirements (see also [Exporting Vulnerability Scanner Reports](Exporting_Vulnerability_Scanner_Reports.htm)). 3. Click **Upload File** and select the CSV file you downloaded from the vulnerability scanner. 4. If Automox determines the size of the file is acceptable, a confirmation shows that the file is accepted without errors and prompts you to click **Next**. 5. A message then shows that it is processing the CSV. Click **Finish**. ## Syncing the Imported Report The mapping process is asynchronous. Therefore, it takes time to discover hostnames and any CVEs that they are impacted by. A sync is complete once it shows as **Ready**. Each CSV file has its own row and when the file completes processing it is highlighted. The remediations page consists of the following information: ![](../../Resources/Images/remediations-manual-table.png) | Table Column | Description | | --- | --- | | Name | Name of the CSV file that was uploaded | | CSV Provider | Indicates the CSV provider source | | Uploaded By | Email address of the user who uploaded the file | | Status | Possible values: Ready Building Error | | Patchable Vulnerabilities | Number of vulnerabilities and affected devices that Automox can remediate | | Unmatched Vulnerabilities | Number of vulnerabilities and affected devices in your environment | | Unknown Devices | Number of devices that do not currently exist in your Automox organization | | Updated | The date the file was uploaded | | Actions | Options: View Report Delete | ## Remediating Vulnerabilities You can view the **Remediation Details** page of any imported CSV file. This provides a detailed view of the specific vulnerabilities affecting your environment and options to remediate them. - From the **Manual** page, click the name of the CSV file to open the details page. ![](../../Resources/Images/manual-remediation-details.png) Identified vulnerabilities are automatically parsed into three categories: - Patchable Vulnerabilities - Unmatched Vulnerabilities - Unknown Devices ## Patchable Vulnerabilities The **Patchable Vulnerabilities** tab lists vulnerabilities in packages that are grouped by severity. The package includes the CVEs and affected devices. **Note:** This includes third-party vulnerabilities. Refer to [Understanding Automox Severity Data](../Patching/Understanding_Automox_Severity_Data.htm) for a list of software packages Automox supports updates for. ![](../../Resources/Images/manual-patchable-vuln.png) Each package includes a list of CVEs to remediate and a list of devices to patch. You can view the details by opening the drop-down menus. | Devices Table Column | Description | | --- | --- | | Device | Name of the device | | Status | This shows the status of the device: For example, connected or disconnected. | | OS | This is the OS type of the device: macOS, Windows, Linux | | OS Version | OS build number | | IP Address | IP address of the device | | Remediation Status | Status of the vulnerability remediation for the specific device. Remediation statuses include: Not Started In Progress Success Failed Timed Out Canceled | - Click **Remediate** to install and patch the devices without a schedule. - After you click Remediate, the remediation status of each device updates as the policies are run. Open the Devices details for a visual depiction of the progress. ## Unmatched Vulnerabilities The **Unmatched Vulnerabilities** tab lists vulnerabilities and affected devices in your environment. These vulnerabilities require you to specify a worklet policy (see [Creating a Worklet](../Policies/Creating_a_Worklet.htm)) in order to remediate the affected devices. You can view the detailed list of devices by opening the drop-down menu. ![](../../Resources/Images/unmatched-vuln.png) | Devices Table Column | Description | | --- | --- | | Device | Name of the device | | Hostname | Permanent device name | | Private IP | IP address of the device | | Remediation Status | Status of the vulnerability remediation for the specific device | - Click **Remediate With Worklet** to view a list of your existing worklet policies to remediate with. ![](../../Resources/Images/remediate-w-worklet.png) | Table Column | Description | | --- | --- | | Worklet Name | Name of the Worklet policy | | OS | Supported operating systems by the policy | | Notes | Click this icon to expand a section with notes about the policy | | View Details | Click this link to open the Edit Worklet page for this policy in a new tab | - You can use the search bar in the Remediate with Worklet window to find a specific worklet. - Click **Remediate** to schedule the worklet. ## Unknown Devices The **Unknown Devices** tab lists devices that do not currently exist in your Automox organization. This information can be used to identify gaps in your environment where the Automox agent is not already installed. The list of device hostnames can be exported and used in a tool like [Automox Agent Deployer](../Automox Integrations/Automox_Agent_Deployer.htm), which supports automatic deployment to CrowdStrike-managed devices. ![](../../Resources/Images/vuln-sync-unknowndevices.png) - Click **Export CSV** for a list of all unknown devices. ## Related Topics - [About Automox Vulnerability Sync](About_Automox_Vulnerability_Sync.htm) - [Exporting Vulnerability Scanner Reports](Exporting_Vulnerability_Scanner_Reports.htm) - [Vulnerability Sync Action Sets APIs](https://developer.automox.com/openapi/axconsole/tag/Vulnerability-Sync-Action-Sets/) - [Upload a Remediations CSV file to Automox using API](https://developer.automox.com/openapi/axconsole/operation/uploadRemediationCSV/) --- # Run Worklet Now _Section: Product Documentation › Worklet Catalog • Source: https://docs.automox.com/product/Content/Product%20Documentation/Worklet%20Catalog/Run_Worklet_Now.htm_ You can run and test a worklet from the Automox Worklet Catalog on devices and receive near real-time results on the same screen. As part of Automox FixNow™, this Run Now option is available for specific worklets and is useful for fixing an issue quickly, testing, debugging, and troubleshooting purposes. --- # Using the Worklet Catalog _Section: Product Documentation › Worklet Catalog • Source: https://docs.automox.com/product/Content/Product%20Documentation/Worklet%20Catalog/Using_the_Worklet_Catalog.htm_ The Worklet Catalog allows you to immediately use a verified Worklet for your purposes. You can also create a new policy based on an existing worklet. ## Access levels and visibility Worklets in the catalog have an access level. A subset of worklets is available to all users as Base worklets. The full catalog is available with Premium access. - **Base**: A subset of worklets available to all users. These worklets are tagged as **Base** in the catalog. - **Premium**: The full catalog available to users with catalog access. If your account does not have a plan that includes worklets, the catalog page automatically shows only Base worklets. ## Accessing the Worklet Catalog You can access the catalog from the **Automate → Worklet Catalog** page. ![](../../Resources/Images/worklet-catalog-actions.png) | Worklet Catalog Table | Description | | --- | --- | | Worklet Name | Name assigned by Automox | | Type | This can be a workstation or server | | OS | This is the operating system that the worklet is intended for | | Categories | Worklets are organized into categories: Data Collection & Auditing, Maintenance Tasks, Peripherals, Personalization, Security, Software Lifecycle, System Preference | | Access Level | Select from either Base or Premium | | Last Updated | The time and date when the worklet was last updated | | Actions | Possible actions: Select View Details to find out what the verified worklet does. Select Create Policy to customize the existing worklet for your own purposes. | ## Search the Worklet Catalog From the Workout Catalog page, you can use the search bar to search for a worklet by a variety of terms. ### Using the filter panel The filter panel includes options to fine-tune your search. When you select any of the individual filters, a number in parentheses shows how many are selected. You can clear selections individually, or select **Clear All**. The panel can also be collapsed. These settings are saved in the URL. When you navigate to other pages and return to the page, your settings are maintained. You can select from the following options: - **OS**: Filter by supported operating system. - **Type**: Filter by environment, such as workstation or server. - **Categories**: Filter by worklet category. - **Access Level**: Filter by **Base** or **Premium** worklets. - **What’s New**: Filter to show newly added or recently updated worklets. ### Using the search bar You can enter the partial names and multiple search items to refine results. You can search by the following: - **Name** - **Description** - **Operating system** - **Keyword** ![](../../Resources/Images/search-catalog.png) Additional behavior: - **Fuzzy search for Name**: Searching by Name supports fuzzy search and takes misspellings into consideration. - **Wildcard match for other fields**: Searching by description, OS, or keyword uses a wildcard match. - **Sorting**: Select a column heading to sort by that column. If you select a sorted column a third time, sorting turns off and results revert to relevance order. - **Relevance**: Results include matching data and close matches and are returned by relevance to the search terms. You can also browse the growing list of worklets on the Automox website ([Browse Worklets](https://www.automox.com/worklets)). ## Viewing Details You can view the details of a verified Automox worklet in either of the following ways: - Select the worklet name in the table to open the details view. - Open the **Actions** menu for the worklet and select **View Details**. In the Worklet Details window, select **Code Preview** to open the evaluation and remediation code details for the selected worklet. You can scroll through the code to view the details. ![](../../Resources/Images/worklet-details.png) To edit the code presented in a worklet from the catalog, you must first add it to a policy. Click **Create Policy.**The **Create Worklet** page opens and you can make the desired changes, such as: - **Configure device targeting**: Use filters to target a collection of devices. - **Edit code**: Modify evaluation or remediation code. - **Set a schedule**: Define when the policy runs. - **Configure user notifications**: Set the message and behavior shown to device users. --- # About Worklets _Section: Product Documentation › Worklets & Required Software • Source: https://docs.automox.com/product/Content/Product%20Documentation/Worklets%20%26%20Required%20Software/About_Worklets.htm_ Use the Worklet™ option to perform any scriptable action on devices, including disabling a vulnerable process, managing native OS controls, mass rollback of patches, and moving unwanted applications. Refer to [Creating a Worklet](../Policies/Creating_a_Worklet.htm) for details: ## **Related Topics** - [Automox Worklets 101](https://www.automox.com/resources/ebooks-and-guides/worklets-101-guide) - See the[Community discussions](https://community.automox.com/community-worklets-12) around worklet. --- # Enforce BitLocker Encryption Worklet _Section: Product Documentation › Worklets & Required Software • Source: https://docs.automox.com/product/Content/Product%20Documentation/Worklets%20%26%20Required%20Software/Enforce_BitLocker_Encryption_Worklet.htm_ This worklet describes how to keep your drives encrypted with ongoing evaluation and remediation (Windows 8 and Windows 10). For detailed steps on creating and scheduling a worklet, refer to: [Creating a Worklet](../Policies/Creating_a_Worklet.htm) For an overview about Worklets, see this article: [How to Use Worklets](How_to_Use_Worklets.htm) ## The Worklets You can use the following evaluation and remediation worklets to enforce BitLocker encryption. **Evaluation Code** # PowerShell 4.0 and Above # Windows 8 and later #Get BitLocker status for All Drives try { $encryption = Get-BitLockerVolume -ErrorAction Stop } catch { Write-Output "Unable to determine BitLocker status" } # Count Drives and initialize lists for later output $numDrives = $encryption.Count $encCount = 0 $encrypted = @() $unencrypted = @() # Loop through each drive and see if it is Protected or Note # Add to the appropriate list, Encrypted or Unencrypted foreach ($drive in $encryption) { $encStatus = $drive.ProtectionStatus $encInProgress = $drive.VolumeStatus if ( ($encStatus -match 'On') -or ($encInProgress -match "EncryptionInProgress") ) { $encrypted += $drive.MountPoint $encCount++ } else { $unencrypted += $drive.MountPoint } } # Output drive statuses so the can be seen in the Activity Log Write-Output "Encrypted Drives: $encrypted`n" Write-Output "Unencrypted Drives: $unencrypted`n" # Determine Compliant based on if the number of Encrypted # Drives matches the number of Total Drives if ($encCount -eq $numDrives) { Write-Output "Compliant" exit 0 } else { Write-Output "Non-Compliant" exit 1 } This evaluation requests BitLocker status for all physical disk drives on the target device. It then compares the count of encrypted drives to the total number present. If all drives are encrypted then it returns Compliant (`exit 0`), otherwise, it returns Non-Compliant (`exit 1`). **Remediation Code** # PowerShell 4.0 and Above # Windows 8 and later # Define where you want your Recovery Key to be exported # Note that this needs to be a local (non-network) drive. $keyPath = 'C:\temp' $toEncrypt = Get-BitLockerVolume | Where-Object { $_.VolumeStatus -match 'Decrypted' } # Loop through each Unencrypted Drives # Enable Bitlocker and Export their Recovery Keys foreach ( $drive in $toEncrypt ) { $driveLetter = $drive.MountPoint.Replace(':','') try { #Enable Bitlocker Enable-BitLocker -MountPoint $driveLetter -EncryptionMethod Aes128 -RecoveryPasswordProtector | Out-Null #Export Key and Key ID to a File $recID = (Get-BitLockerVolume -MountPoint $driveLetter).KeyProtector.KeyProtectorID $recKey = (Get-BitLockerVolume -MountPoint $driveLetter).KeyProtector.RecoveryPassword Set-Content -Path "$keyPath\BitlockerRecoveryKey_$driveLetter.txt" -Force -Value "Recovery Key ID: $recID" Add-Content -Path "$keyPath\BitlockerRecoveryKey_$driveLetter.txt" -Value "Recovery Key: $recKey" } catch { Write-Output "Unable to Encrypt $($drive.MountPoint)" } } The remediation code has one editable variable (`$keyPath`). Use this to define where to store the recovery key. The recovery key is necessary to decrypt the drive should that become necessary in the future. This worklet initially runs a similar check as the evaluation code to enumerate each physical drive that is not encrypted. Using this information, it starts encryption on each of these drives and exports the recovery key to a text file in the previously specified location. --- # Enforce Windows Registry Settings Worklet _Section: Product Documentation › Worklets & Required Software • Source: https://docs.automox.com/product/Content/Product%20Documentation/Worklets%20%26%20Required%20Software/Enforce_Windows_Registry_Settings_Worklet.htm_ This worklet describes how to manage device configurations through various registry settings, including 64-bit vs 32-bit registry access. It is often valuable to change or enforce the behavior of a device by defining a particular registry value. The following is an example that can be extended to just about any setting that is useful to your situation. ## Evaluate Current Setting Before changing a setting, evaluate its current state. Additionally, this allows the worklet to report Compliance to the desired state. In this example, all you need to edit are the three variables you want to monitor/change. Set the path to the property, the name of the property, and the desired value. Use this as your evaluation code in your worklet: # Define Registry Key and sub-value to evaluate ############################################# $regPath = "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server" $regProperty = "fDenyTSConnections" $desiredValue = '1' ############################################# # Retrieve current value for comparison $currentValue = (Get-ItemProperty -Path $regPath -Name $regProperty -ErrorAction SilentlyContinue).$regProperty # Compare current with desired and exit accordingly. # 0 for Compliant, 1 for Non-Compliant if ($currentValue -eq $desiredValue) { Exit 0 } else { Exit 1 } The policy is marked as compliant/non-compliant based on the exit code. A simple IF statement that exits accordingly is all that is needed to determine that state of the policy. ## Remediating the Setting After determining compliance, now it's time to act on that information. A non-compliant evaluation flags the device as needing remediation. So when the worklet's scheduled time arrives the device runs the remediation code. Here's the example that goes along with the evaluation above. Use this as your remediation code: # Define Registry Key and sub-value to modify ############################################# $regPath = "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server" $regProperty = "fDenyTSConnections" $desiredValue = '1' ############################################# try { Set-ItemProperty -Path $regPath -Name $regProperty -Value $desiredValue -ErrorAction Stop Exit 0 } catch { Write-Output "Unable to update $regProperty" Exit 1 } Again, just set the 3 variables to match the evaluation code. This sets the property to your desired value. Success/failure here is determined again by the exit code. So a try/catch block is well suited to this scenario. ## 64-Bit Registry Workaround Automox runs as a 32-bit process and looks at the 32-bit registry keys by default on a 64-bit device. This doesn't affect the current example, as it isn't looking in an affected registry locations, but this is worth noting for other scenarios. For instance, all registry keys with a WOW6432Node counterpart (most commonly *HKLM:\SOFTWARE)* the 32-bit WOW6432Node counterpart will be read unless using the following workaround. *HKLM:\SOFTWARE* is interpreted as *HKLM:\*SOFTWARE\WOW6432Node if it is run as previously defined. To get around this behavior, use the *sysnative* PowerShell.exe on the device. The following example uses a ScriptBlock to accomplish this. Note that some variables need to be defined inside the ScriptBlock as that code is run in its own context. ### Evaluation #### Check Registry with ScriptBlock $scriptBlock = { # Define Registry Key and sub-value to evaluate ############################################# $regPath = "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server" $regProperty = "fDenyTSConnections" ############################################# # Retrieve current value for comparison $currentValue = (Get-ItemProperty -Path $regPath -Name $regProperty).$regProperty return $currentValue } # Define Desired Value here $desiredValue = '1' # Execute the ScriptBlock in a 64-bit shell, # No need to assign to a variable if you don't # have a return value. In most cases, you will. $currentValue = & "$env:SystemRoot\sysnative\WindowsPowerShell\v1.0\powershell.exe" -ExecutionPolicy Bypass -WindowStyle Hidden -NoProfile -NonInteractive -Command $scriptBlock # Compare current with desired and exit accordingly. # 0 for Compliant, 1 for Non-Compliant if ($currentValue -eq $desiredValue) { Exit 0 } else { Exit 1 } ### Remediation #### Remediate Registry with Scriptblock $scriptBlock = { # Define Registry Key and sub-value to modify ############################################# $regPath = "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server" $regProperty = "fDenyTSConnections" $desiredValue = '1' ############################################# try { Set-ItemProperty -Path $regPath -Name $regProperty -Value $desiredValue return 0 } catch { return 1 } } # Execute the ScriptBlock in a 64-bit shell, ## Since this block returns 0 for success and 1 for fail ## Use that value for exit code to determine success $returnCode = & "$env:SystemRoot\sysnative\WindowsPowerShell\v1.0\powershell.exe" -ExecutionPolicy Bypass -WindowStyle Hidden -NoProfile -NonInteractive -Command $scriptBlock Exit $returnCode **Note**: The remediation examples included here assume that the registry key in question already exists. In the case where it does not, additional logic could be added to create the key/value as needed. --- # How to Find Application Names and Versions for Required Software Policies _Section: Product Documentation › Worklets & Required Software • Source: https://docs.automox.com/product/Content/Product%20Documentation/Worklets%20%26%20Required%20Software/How_to_Find_Application_Names_and_Versions_for_Required_Software_Policies.htm_ With these instructions you can obtain the information you need to set up required software policies for your operating system: ## Windows - Install the desired software on a test machine. - Navigate to the Control Panel and select **Programs and Features. ![](../../Resources/Images/win-programs-features.png)** - Use the example here to find the values from your machine and fill in the **Package Name** and **Version** in the Automox console. ## macOS - Install the desired software on a test machine. - Navigate to the Applications folder and find the application you installed. - Right click on the application and select **Get Info.** ![](../../Resources/Images/macos-app-getinfo.png) - Use the values circled below to fill in the **Package Name** and **Version** field. ![](../../Resources/Images/macos-package-version.png) ## Linux - Install the desired software on a test machine - Based on your version of Linux, use the respective command listed here to show your installed software: - **Debian**: `aptitude search ~i --disable-columns -V -F "%p|%v"` - **CentOS**: `repoquery --plugins --pkgnarrow=installed -a --qf "%{name}.%{arch}|%{version}-%{release}"` - **Fedora**: `dnf repoquery --installed --qf "%{name}.%{arch}|%{version}-%{release}"` - **RedHat**: `repoquery --plugins --pkgnarrow=installed -a --qf "%{name}.%{arch}|%{version}-%{release}”` - **Amazon**: `repoquery --pkgnarrow=installed -a --qf "%{name}.%{arch}|%{version}-%{release}"` - **SUSE**: `zypper se -is | egrep "^. | " | grep -v "S | Name" | awk '{OFS = "|"; ORS = "\n"; NAME=$3"."$9; VERSION=$7; print NAME,VERSION;}'` - Use the values circled in this example to fill in the **Package Name**and **Version** in the Automox console. ![](../../Resources/Images/linux-package-version.png) ## Related Topics - [Creating a Required Software Policy](../Policies/Creating_a_Required_Software_Policy.htm) --- # How to Use Worklets _Section: Product Documentation › Worklets & Required Software • Source: https://docs.automox.com/product/Content/Product%20Documentation/Worklets%20%26%20Required%20Software/How_to_Use_Worklets.htm_ This describes how you can use worklets to manage devices. In the console, Worklets are an option under **Automate → Policies**. A **Worklet**is highly flexible. It allows you to evaluate and enforce just about anything you can script. You can also upload files that can be used on the targeted device. ## Script Languages The Evaluation and Remediation code languages are specific to the OS and run in the version currently installed on the target machine. **Windows:** PowerShell **Linux and macOS:** Bash You can launch and run a script file in a different language in the remediation code by invoking the file from the native language script. This assumes that your target device is capable of running the uploaded script file. **Note**: On 64-bit Windows, this runs in a 32-bit PowerShell session. You may need to plan around this for accessing 64-bit registry locations and filesystems. This is caused by 32-bit processes being redirected to `Wow6432Node` or `SysWoW64` in place of the native locations. ### Evaluation Code The evaluation code is intended to test a condition, and return an exit code based on that condition. The evaluation runs each time a device runs a scan and flags the device for remediation according to the exit code. If the exit code is 0, the evaluation is seen as successful and no remediation will take place. Any non-zero exit code flags the device for remediation. The remediation code will run when the worklet’s scheduled time arrives. **Note**: When you manually execute the worklet, it triggers the Remediation code regardless of the flagged exit code. ### Remediation Code The remediation code section is open-ended and can do basically anything you can script. For example, you can enforce a configuration setting, install an application or certificate, etc. Any files you uploaded to the worklet are downloaded when the remediation code runs, and can then be called/invoked by your worklet. ### Uploading Files You can upload any files you may need to reference in your remediation script as part of the policy. These files will download when the remediation runs and will be available in the current working directory of the script. As such, they can usually just be referred to by their file name, although some situations may require that you use the relative path. (`./filename` in Bash or `.\filename`in PowerShell). **Note**: The current file size limit is 10 GB. ## Executing Worklets ### Scheduled Execution As with all the other policy types, worklets can run according to a patching schedule. See [Setting a Patching Schedule](../Policies/Setting_a_Patching_Schedule.htm). Use this to customize the schedule on which the remediation script will run non-compliant devices. ### Manual Execution You can handle Manual Execution in two ways: per device and per worklet. On the **Device Details** page for every device in a Group that is associated with the worklet, there is an Associated Policies section where you can see the worklet name and a **Run On This Device** button. This button triggers the worklet to run immediately on the selected device. On the **Automate → Policies**page, find the worklet from the list of Policies. From the Actions menu, select Run Policy. This triggers the worklet to run immediately on all devices in the associated groups. **Note**: These methods trigger the remediation script regardless of the compliance status of the device. *Use these methods with caution.* ## Related Topics - [Creating a Worklet](../Policies/Creating_a_Worklet.htm) - [What are Automox Worklets?](https://www.automox.com/worklets) --- # Using the Required Software Policy _Section: Product Documentation › Worklets & Required Software • Source: https://docs.automox.com/product/Content/Product%20Documentation/Worklets%20%26%20Required%20Software/Using_the_Required_Software_Policy.htm_ The required software policy enables you to distribute and install software across your organization’s devices. You can deploy to an unlimited number of devices by uploading an installation binary and specifying the package name, installation command, and schedule. ## Policy attachments You can attach files to a required software policy to install software, run scripts, or perform other actions on devices. **Note:**The maximum file size for a policy attachment is now**10 GB**—an increase from the previous 1 GB limit. This larger size allows you to include bigger installers, scripts, or other necessary files directly in your policies. This limit applies to all new and updated policies. ## Package name, package version, and installation command The policy requires the following information to execute properly: - **Package name:** Used to identify if the software is already installed on a device (for example, in Windows this can map to the registry GUID or the program name listed in Add/Remove Programs). For third-party software, see [Naming Scheme for Third-Party Software Packages](../Third-Party Software/Naming_Scheme_for_Third_Party_Software_Packages.htm) to understand how Automox identifies software. - **Package version:** Used to identify if the exact version of the package is installed on the device. - **Installation command:** The complete command that installs the software, typically using a silent or unattended installation option. Currently, you must enter these values manually for all file types. ## Optional commands for common installer types Previously, the policy automatically filled in the **installation command** for certain installer types when you uploaded a file. At the moment, this does not occur. You can use the following example commands to run installers manually. Replace `your-file` with the actual file name. ### Window MSI exit (Start-Process -FilePath 'msiexec.exe' -ArgumentList ('/qn', '/i', 'your-file.msi') -Wait -Passthru).ExitCode ### Linux RPM yum install -y your-file.rpm ### Linux DEB dpkg -i your-file.deb You can use these commands on a test device to confirm the correct syntax and behavior before adding them to your policy. ## Adding installer files to a policy The required software policy supports a variety of installer formats, including but not limited to `.msi`, `.rpm`, `.deb`, `.exe`, and `.pkg`. For any file type, follow these steps: 1. Install the software on an Automox-managed device. 2. Refresh the device so that Automox can detect the software and display the package name or identifier. 3. When creating the policy, enter the **package name**, **package version**, and **installation command** manually. For instructions to create this type of policy, see [Creating a Required Software Policy](../Policies/Creating_a_Required_Software_Policy.htm). --- # Windows Patch Rollback Worklet _Section: Product Documentation › Worklets & Required Software • Source: https://docs.automox.com/product/Content/Product%20Documentation/Worklets%20%26%20Required%20Software/Windows_Patch_Rollback_Worklet.htm_ Uninstall a specific Windows patch across multiple devices, Worklet example. The Automox console allows you to uninstall patches using the Rollback Action from the Device Details page. Unfortunately, this method might be cumbersome for a large number of devices. For this scenario, you can apply a Worklet that detects the presence of, and subsequently removes, the unwanted patch. **Note**: Not all patches are uninstallable. Refer to the [Microsoft Update Catalog](https://www.catalog.update.microsoft.com/Home.aspx) for details for your particular patch. ## Evaluation Code To evaluate this, you need to determine whether the patch is present. This is straightforward with the PowerShell command` Get-HotFix`. Based on the response of that command for the patch we're concerned with, we use the appropriate Exit Code to indicate its compliance status. #### EVALUATION CODE #### # If you want to have an ongoing evaluation use this script # to see if the patch is present. # If you just want to manually execute this policy, this can be as # simple as "Exit 1" # Change this KB number to match what you want to check for # Be certain to use the same KB number in both Evaluation and Remediation $kb = '4503308' # Check for presence and assign to variable $installed = Get-HotFix -Id "KB$kb" -ErrorAction SilentlyContinue # Check the variable and exit accordingly if ( $installed ) { #Installed is Non-Conmpliant, so Exit 1 Exit 1 #Otherwise Exit 0 for Compliance } else { Exit 0 } ## Remediation Code ### Method 1 - Windows 7 and Newer Remediation is more complex in this case. Since Windows 10 removed the option to uninstall patches silently with wusa.exe, you must dig through packages another way, format the output, and use dism.exe to uninstall the patch. #### REMEDIATION CODE #### # Uninstall the specified patch using dism.exe # Compatible with Windows 7 and Newer # Change this KB number to match what you want to check for # Be certain to use the same KB number in both Evaluation and Remediation $kb = '4503308' # Retrieve the package information from dism.exe filtered for our patch. # Then convert the response to a string, and remove the excess label text $package = & dism.exe /online /get-packages | Select-String $kb Try { $packageName = $package.ToString().replace("Package Identity : ", "") } Catch { Write-Output "Package Not Found, device is compliant"; Exit 0 } # Use the package name we just retrieved to trigger the uninstall $process = Start-Process -FilePath 'dism.exe' -ArgumentList "/Online /Remove-Package /PackageName:$packageName /quiet /norestart" -Wait -PassThru $process.ExitCode ### Method 2 - Windows 8 and Older For example, here is the simpler version for devices using older operating systems (Windows 8 and older). The one complication here lies in the need to use the 'sysnative' path to wusa.exe when running on a 64-bit operating system. So we add a check for that and act accordingly. **Note**: This is necessary because Automox runs as a 32-bit process even on 64-bit versions of Windows. #### REMEDIATION CODE #### # Uninstall the specified patch using wusa.exe # Compatible with Windows 8 and Older # Change this KB number to match what you want to check for # Be certain to use the same KB number in both Evaluation and Remediation $kb = '4503308' # Determine OS Architecture to set path for wusa.exe $osArch = (Get-WmiObject -Class Win32_OperatingSystem).OSArchitecture # Define the FilePath to wusa.exe based on OS Architecture if ( $osArch -match '64-bit' ) { $filePath = 'C:\Windows\sysnative\wusa.exe' } else { $filePath = 'C:\Windows\System32\wusa.exe' } # Uninstall and save the exit code to determine success/failure $process = Start-Process -FilePath $filePath -ArgumentList "/uninstall /KB:$kb /quiet /norestart" -Wait -PassThru Exit $process.ExitCode ![](../../Resources/Images/rollback-worklet-code.png) ## Related Topics - [How to Use Worklets](How_to_Use_Worklets.htm) - Browse [Automox Worklets](https://www.automox.com/worklets) ---