API & Integrations

Hello! Thought I would share this API script I wrote that exports all applied patches on all machines to a CSV. UseCase: For audits this allows an easy way to export every single patch on a machine to prove that machines have been patched during a time period. Notes: This is meant to be run on a machine NOT through a worklet. Make sure to add in your own API Key for this to work. For a full list of objects you can pull from the API see Automox API Documentation under “Response”. This script is not perfect. If run multiple times it will keep adding to the same CSV, so make sure to either clear the CSV and save or just delete it. Powershell Code: #Set Execution policy to allow for 3rd party modules Set-ExecutionPolicy Unrestricted -Force #Define API Key and URL to get initial Machine list $apiKey = "*INSERT YOUR API KEY HERE*" $apiUrl = "https://console.automox.com/api/servers/" $headers = New-Object "System.Collections.Generic.Dictionary[[String],[String]]" $headers.Add("Authorizatio

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\Windows\CurrentVersion\Uninstall" } if (-not $UninstallKeys) { Write-Verbose -Message 'No software registry keys found' } else { foreach ($UninstallKey in $Uninst

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=”: [https://console.automox.com/device-detail?s=99999&o=1234]. In this example the Server ID is 999

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 by their location in this above list - or using -. Also supported use -verbos

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?). There are two areas in the code you’ll need to update to get the script to function: $orgID = ‘YOUR_ORG_ID’ - put your Org ID, which can be found by looking at the URL of your console and selecting the value after the “?o=”: https://console.automox.com/dashboard?o=999999 1. In

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 been an established TCP connection by the ag

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. It was an interesting first experience using an API key and Get requests but I felt it was successful in collecting everything I needed. I’m sure others could do this type of work in their sleep but it’s another wrench in the toolbox for me. Anyon