API & Integrations

If trying to use the InstallUpdate command to “Issue a Command to a Device”, you’ll see that it wants a GUID for the update: https://docs.automox.com/api/endpoints/issue-a-command-to-a-device So that you don’t have to comb through the registry trying to find it, you can run this script on a device that has the update installed to find the GUID so that you can use it to install it on other devices with API: $UninstallKeys = "HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall", "HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall" $null = New-PSDrive -Name HKU -PSProvider Registry -Root Registry::HKEY_USERS $UninstallKeys += Get-ChildItem HKU: -ErrorAction SilentlyContinue | Where-Object { $_.Name -match 'S-\d-\d+-(\d+-){1,14}\d+$' } | ForEach-Object { "HKU:\$($_.PSChildName)\Software\Microsoft\Win

This script will apply multiple policies from your organization to a system. Say you always apply the same five policies to a newly built system, you could use this to apply those policies with one click to your new system. This will install any policy available in your organization regardless of whether it is attached to the group the system is in or not. Make sure you’re not attempting to apply a macOS/Linux worklet or required software to a Windows device. Just set the following: $apiKey = 'YOUR_API_KEY' - in your console, go to Settings->API and select the API key. Note that the API key is per admin user, so you and another admin in your console will have different API keys. $orgID = 'YOUR_ORG_ID' & $serverID = 'YOUR_SERVER_ID' - put your Org ID & Server ID which can be found by looking at the URL on the device page and selecting the value after the “?s=” & “?o=”: [

To execute - run .\CleanAutomoxDevices.psl (includes help on required paremeters) Example run MVP run: .\Clean-AutomoxDevices.ps1 Params: orgID (required) - Your Automox Org ID apiKey (required) - Your Automox API Key maxDays (optional) - Defaults to 120 days. Override with any reasonable number. apiEndpoint (optional) - What is the API endpoint to communicate with Automox? logFolder (optional) - Override log folder. Defaults to popping out a log where script is run apiTable (optional) - Override location in URI servers are found. This probably will never be used weaponize (optional) - must be set to $true if you want anything other than a test run. -verbose: All meaningful output not in the log can be brought to screen using this command. Most screen output is hidden without this param. Destrictive run: .\Clean-AutomoxDevices.ps1 -weaponize $true All parameters are position and will be acceppepted either

Have you ever needed to run a scan from the client side? There are times when you may want to trigger a scan from the device as part of an automation rather than from the console (or waiting for the next scheduled scan to run). One example is to automatically update the Automox inventory when a Windows 10 in-place upgrade successfully completes. Luckily, @Nic recently published a topic to clean up inactive devices (Powershell script to remove devices that have been disconnected longer than X days) that I was able to repurpose to manage this task. Thank you @Nic! This script leverages the API to identify the local device, and then sends a secondary API call to schedule a scan for itself (Pretty handy, right?).

Hello there, Recently we discovered that we had numerous agents going offline randomly in Automox and we wanted to find a way to try to revive those endpoints remotely without having the team on the ground go to each endpoint individually. We have another service running on our endpoints that could also run Powershell/Bash scripts depending on OS and would run similarly as SYSTEM/Root user. We made use of this and came up with a script so that endpoints that were still online via this service and not in Automox could be fixed remotely. We’ve seen it work pretty successful thus far and wanted to share in case you might have need of it too. You could also run this script locally too to revive if you don’t have another service. All you need to change in the script is the cURL (with Access Key) which you can retrieve from Automox console. UPDATE: 15th Feb 2020. Added 2 additional functions to check if the service is running and whether there has

Disclaimer: I’ve never really utilized API keys for data requests until now. My API Use Case: Collect all server OS details including policies, users, and groups. This is a great tool if you want detailed data from your Automox environment! After reviewing the API Documentation for Automox I learned the types of API commands I could run and quickly realized I needed a way easily understand what’s in a .json file and how to read it. I haven’t work with a .json file before, but after some research I found Postman which allowed me to run API requests from and easily download a .json - which ended up converting to an excel spreadsheet. The spreadsheet is so well organized and now I can easily vlookup what I need on a smaller separate work task.