NinjaOne Integration

Connect NinjaOne (NinjaRMM) to Atlas AVD: device inventory linked to your session hosts, organizations and locations, and alerts you can reset.

Before you begin

  • An Enterprise plan or above. The Integrations hub is locked below Enterprise
  • The Administrator role in Atlas to connect, configure or disconnect a connector. Integrations appears under Administration only for administrators
  • A tenant selected in the tenant picker. Credentials are stored encrypted per tenant, so each tenant you manage connects its own account
  • A NinjaOne API client app using the client-credentials grant, created by a NinjaOne administrator

What you can do

  • See every NinjaOne device with its organization, class, status and last contact, and jump from a device to the matching session host in Atlas.
  • Track online and offline devices and alerts at a glance.
  • Browse your organizations and the locations under each one, with addresses.
  • Reset NinjaOne alerts from Atlas.
  • Read and reset NinjaOne alerts from your own automation with an Atlas API key.

Step 1: Create an API client app in NinjaOne

  1. In NinjaOne, go to Administration → Apps → API and add a client app.
  2. Choose API Services (machine-to-machine) as the application platform and give it a name such as Atlas AVD.
  3. Allow the Monitoring scope (to read devices, alerts, organizations and locations) and the Management scope (to reset alerts).
  4. Allow the Client Credentials grant type and save.
  5. Copy the Client ID and Client Secret. The secret is shown only once.

Step 2: Connect in Atlas

Once connected, the card shows Manage, which opens the NinjaOne page, and Disconnect. The client ID and secret are both stored encrypted.

  1. Select the tenant in the tenant picker.
  2. Go to Administration → Integrations and click Connect on the NinjaOne card.
  3. Enter the Instance URL for your NinjaOne region, starting with https://: for example https://app.ninjarmm.com (US), https://us2.ninjarmm.com, https://eu.ninjarmm.com, https://ca.ninjarmm.com or https://oc.ninjarmm.com.
  4. Paste the Client ID and Client Secret and click Connect. Atlas signs in and lists your organizations before saving anything; if NinjaOne rejects the client, nothing is stored.

What you see

  • Overview: Total Devices, Online, Offline and Active Alerts, the device online ratio, and how many organizations and locations you have.
  • Devices: name, organization, class, status and last contact. Search by name, class or organization, sort any column, and click the AVD link to open the matching session host. A device links when its name matches a VM name exactly, or when its short name matches exactly one VM.
  • Alerts: device ID, severity, message and when it was raised. Search, and filter by Critical, Major, Moderate, Minor or None.
  • Organizations & Locations: each organization with its locations and their addresses.

Atlas reads NinjaOne live each time you open a tab or click Refresh; it does not copy your RMM data into Atlas or sync it in the background.

Reset alerts

Each alert row has a Reset action, which resets the alert in NinjaOne straight away, with no confirmation step. NinjaOne's API has no separate acknowledge, so there is no Acknowledge button.

Use it from your own tools

An Atlas API key with the integration.ninjaone.read scope can list alerts at GET /api/integration/ninjaone/alerts, and one with integration.ninjaone.write can reset an alert at POST /api/integration/ninjaone/alerts/{uid}/reset. See API Access for how keys are issued.

What the integration does not do

  • It does not run scripts, open a remote session, reboot, patch or install software through NinjaOne. Use NinjaOne for those, or Atlas Reach.
  • It does not create tickets.
  • Its only change in NinjaOne is resetting alerts.
  • The Alerts tab reads up to 1,000 alerts and shows the device by its NinjaOne device ID rather than its name.
  • It connects one NinjaOne instance per Atlas tenant.
  • Credentials cannot be edited in place: disconnect and connect again with the new client.
  • Atlas Advisor can tell you whether NinjaOne is connected, but does not answer questions about devices or alerts.

GCC High tenants

On a tenant or deployment in Azure Government (GCC High), calls to NinjaOne are blocked by default, because they can carry VM, host-pool and tenant names to a service outside the Government boundary. Connect fails with an Azure Government (GCC High) egress boundary message and nothing is stored, and pages that read from NinjaOne stay empty. The operator who runs your Atlas deployment can approve NinjaOne as a destination that is allowed to receive that data; once approved, the connector works normally. Running in Azure Government does not by itself make a third-party integration GCC High or CMMC compliant.

Disconnecting

Click Disconnect on the card and confirm. Atlas deletes its stored copy of the client ID and secret; nothing changes in NinjaOne. Delete the client app in NinjaOne too if you no longer need it. You can reconnect at any time.

Troubleshooting

  • NinjaOne rejected the supplied credentials: the client ID or secret is wrong, the client app does not allow the client-credentials grant, or the Instance URL is for a different region than your account.
  • Could not connect to NinjaOne — verify the server URL and credentials: check the Instance URL is your region's address.
  • instanceUrl must be a valid https:// URL: include https://.
  • NinjaOne is temporarily rate limiting requests: wait a minute and try again.
  • Something went wrong on the Devices or Organizations tab: click Retry. If it keeps failing, check the client app still exists and has the Monitoring scope.
  • Reset fails: the client app needs the Management scope.

Next steps