Skip to main content

​
How it works

Neo manages on-premises Active Directory and Exchange Server by executing PowerShell scripts through your RMM platform. This enables the same operations available in cloud environments — password resets, user provisioning, group management, mailbox delegation, and more. Neo uses two execution patterns depending on your environment:
  • Direct execution — The RMM agent is installed on the target server (e.g., the Domain Controller or Exchange server). Neo runs scripts directly on it.
  • Remote execution — The target server doesn’t have an RMM agent. Neo runs scripts on a “runner” VM that does have RMM, and uses PowerShell Remoting to reach the target server.
Identity Provider (AD) and Mailbox Provider (Exchange) are configured independently per company — you can mix and match. For example, on-prem AD with Exchange Online, or Entra ID with on-prem Exchange Server. What routes where:
OperationWhere it runs
AD changes (create user, reset password, groups, etc.)On the AD Runner via RSAT — either the DC or a runner VM
AD Connect syncOn the AD Connect server (remotely from the runner if the AD Connect server isn’t in RMM)
Exchange Online / Exchange Hybrid standard ops (forwarding, delegation, shared mailbox, etc.)Cloud — via Microsoft Graph
Exchange on-prem cmdlets (e.g., Enable-RemoteMailbox)On the Exchange server (remotely from the runner if the Exchange server isn’t in RMM)

​
Setup

​
1. Configure Company Settings

For each client with on-prem infrastructure, configure their identity provider and mailbox provider settings in the Companies tab.

​
Identity Provider Settings

FieldDescription
Identity Provider TypeSelect “On-prem AD”, “Hybrid”, or “Entra ID (Cloud)“
AD Runner Hostname(On-prem AD and Hybrid only) Hostname of the machine where AD scripts run — either the DC itself or a runner VM with RSAT AD tools. Must match the device name in RMM.
AD Connect Server Hostname(Hybrid only) Hostname of the server running Azure AD Connect. Neo triggers a directory sync on this server after making AD changes, so updates propagate to Entra ID. If this server differs from the AD Runner, Neo uses remote execution to reach it.

​
Mailbox Provider Settings

FieldDescription
Mailbox Provider TypeSelect “Exchange Server” (on-prem), “Exchange Hybrid”, or “Exchange Online” (cloud)
Exchange Server Hostname(Exchange Server and Exchange Hybrid only) Hostname of the Exchange server
Exchange Runner Hostname(Exchange Server and Exchange Hybrid, optional) Set this if the Exchange server doesn’t have an RMM agent. Neo runs scripts on this runner VM and uses remote execution to reach the Exchange server. Must match a device name in RMM.
All hostnames must match exactly how the devices appear in your RMM platform.
Bulk configuration: Use the CSV import feature in the Companies tab to configure multiple clients at once.

​
2. Upload the Neo Script to Your RMM

Neo needs a wrapper script installed in your RMM to execute PowerShell commands.
  1. Download the Neo PowerShell component:

Neo Script Run Powershell.cpt

Datto RMM component for executing Neo PowerShell scripts
  1. Import the component into Datto RMM by following Datto’s import instructions.
  2. Trigger an RMM sync in Neo by going to Integrations → RMM and clicking the sync button. This allows Neo to discover the newly imported script.

​
3. Set Up a Runner Machine

Required if: any server Neo manages (DC, Exchange server, AD Connect server) does not have an RMM agent installed. Common scenarios:
  • You don’t want to install RMM on the Domain Controller
  • The Exchange server doesn’t have an RMM agent
  • The AD Connect server doesn’t have an RMM agent
A runner machine is any domain-joined server with an RMM agent that Neo uses to execute scripts on behalf of servers that don’t have RMM. The runner can be any domain-joined Windows server — a dedicated management VM, an existing utility server, etc. A single machine can serve as both the AD Runner and Exchange Runner.

​
3a. Install RSAT AD Tools

Required if: the DC doesn’t have an RMM agent (i.e., the runner performs AD operations on its behalf).
The runner needs the AD PowerShell module to execute Active Directory commands:
Open PowerShell as Administrator and run:
Install-WindowsFeature -Name RSAT-AD-PowerShell
Or via Server Manager: Add Roles and Features → Features → Remote Server Administration Tools → AD DS Tools → AD DS Snap-Ins and Command-Line Tools
Verify installation by running Import-Module ActiveDirectory in PowerShell — it should complete without errors.

​
3b. Create a Dedicated Service Account

Create a service account in Active Directory (e.g., DOMAIN\neo_automation) and grant it the permissions needed for the operations you want Neo to perform.
You control what Neo can do. Grant only the permissions your team is comfortable with. Best practice: Delegate permissions on specific OUs rather than domain-wide.
PermissionNeo capabilities
Create/delete user objectsUser onboarding and offboarding
Reset passwordPassword resets, unlock accounts, force password change at logon
Read/write all user propertiesUpdate name, job title, department, manager, phone, office, company, employee ID, etc.
Enable/disable accountsEnable/disable user accounts during onboarding/offboarding
Read/write group membershipAdd/remove users from security and distribution groups
Read computer objectsView computer accounts and their properties
Enable/disable computer objectsEnable/disable computer accounts
Assign the Recipient Management role to the service account, or delegate equivalent permissions:
PermissionNeo capabilities
Mailbox managementConvert user mailboxes to shared, delete mailboxes
Mail forwardingSet up and remove email forwarding
Mailbox permissionsGrant/revoke Full Access to mailboxes
Recipient permissionsGrant/revoke Send As and Send on Behalf permissions
Address list visibilityHide/unhide mailboxes from the Global Address List
Distribution group managementCreate, delete, and manage distribution group membership
Mail contact managementCreate and manage external mail contacts
Auto-reply configurationConfigure out-of-office messages
Mobile device managementView and wipe mobile devices (for offboarding)
Message trackingTrace email delivery for troubleshooting
Transport rulesCreate and manage mail flow rules
Public folder managementCreate and manage public folders
Quarantine managementRelease or delete quarantined messages
Inbox rulesView and manage user inbox rules
Calendar/resource managementConfigure room and equipment booking policies
Retention policiesConfigure message retention settings
Address list managementManage GAL, OAB, and address book policies
If the Exchange server is not in RMM (i.e., Neo uses remote execution from a runner), the service account also needs WinRM remoting access to the Exchange server.
To trigger AD Connect syncs, the service account must be a member of the ADSyncOperators group on the AD Connect server.If the AD Connect server is not the same machine as the AD Runner (i.e., the AD Connect server is not in RMM), the service account also needs WinRM remoting access to the AD Connect server. Neo will use Invoke-Command from the runner to trigger the sync remotely.
Neo can also perform these Active Directory operations if you grant the necessary permissions:
PermissionNeo capabilities
Create/delete computer objectsComputer account lifecycle management
Create/delete/modify OUsOrganizational unit management
Manage service accountsManaged Service Account (MSA/gMSA) operations
Fine-grained password policiesView and modify password policies
Move/rename AD objectsReorganize objects between OUs

​
3c. Configure RMM Component Credentials

By default, Datto RMM scripts run under LocalSystem, which has no AD or Exchange permissions on non-DC machines. To run scripts under your service account, configure Component Credentials for each site that uses a runner machine.
Component Credentials are configured per site (end-client). For sites without credentials configured, scripts run under LocalSystem — which only works if the RMM agent is installed directly on the DC or Exchange server.
Step 1: Enable Component Credentials on the Neo script First, configure the Neo script to use Component Credentials when available:
  1. Go to Automation → Components and open the [Neo Script] Run Powershell component
  2. Toggle Requires Component Credentials to ON
  3. Click Save to apply the change
Don’t forget to save the component after toggling the credential setting. The toggle won’t take effect until the component is saved.
Datto RMM component with Requires Component Credentials enabled
Step 2: Create credentials for each site For each client that uses a runner machine:
  1. In Datto RMM, go to Setup → Credentials → Create Credential
  2. Enter a Name (e.g., “Neo Agent Service Account”)
  3. Set Scope to Site and select the client’s site
  4. Set Type to Component
  5. Enter the service account credentials:
    • Username: DOMAIN\neo_ad_automation
    • Password: (the service account password)
  6. Click Create Credential
Creating a Component Credential for a site in Datto RMM
Repeat for each site where Neo uses a runner machine.

​
4. Enable Remote Execution

Required if: a target server doesn’t have an RMM agent and Neo reaches it remotely from the runner. This applies when:
  • The AD Connect server doesn’t have an RMM agent (AD Connect Server Hostname differs from AD Runner Hostname)
  • The Exchange server doesn’t have an RMM agent (an Exchange Runner Hostname is configured)
On each target server (the one without RMM), complete these steps:
  1. Enable PowerShell Remoting: 
    Enable-PSRemoting -Force
    This configures WinRM and opens the necessary firewall rules. See Microsoft’s documentation for details and troubleshooting.
  2. Grant the service account remoting access. The service account configured in Component Credentials must be able to establish remote PowerShell sessions to the target server. If the service account is not a Domain Admin, add it to the Remote Management Users group on the target server, or grant it WinRM access via Group Policy.
  3. Verify network connectivity from the runner to the target server on port 5985 (HTTP) or 5986 (HTTPS).

​
5. Configure Kerberos Constrained Delegation

Required if: the Exchange server doesn’t have an RMM agent and Neo reaches it remotely from the runner. This means:
  • You configured an Exchange Runner Hostname in Mailbox Provider Settings
  • The runner and Exchange server are different machines
When the runner remotes into the Exchange server, Exchange cmdlets need to reach Active Directory to perform operations like provisioning mailboxes or modifying user attributes. By default, Windows blocks the service account’s credentials from being forwarded beyond that first remote connection — a known limitation called the Kerberos “double-hop” problem. The fix is Resource-based Kerberos Constrained Delegation — Microsoft’s recommended and most secure solution. It tells your Domain Controllers to accept delegated credentials from the Exchange server. Without this, Exchange commands like Enable-RemoteMailbox will fail with credential errors — see Troubleshooting. Step 1: Configure delegation on all Domain Controllers. On a Domain Controller, run this as a Domain Admin. It configures every DC in the domain — this is needed because Exchange may contact any DC to perform AD operations. Replace EXCHANGE-SERVER with your Exchange server hostname. No SPN configuration is needed. 
$ExchangeServer = Get-ADComputer -Identity "EXCHANGE-SERVER"
Get-ADDomainController -Filter * | ForEach-Object {
    Set-ADComputer -Identity $_.Name -PrincipalsAllowedToDelegateToAccount $ExchangeServer
    Write-Host "Configured delegation on DC: $($_.Name)"
}
Step 2: Clear the Kerberos cache on the runner. On the runner machine, run as admin to flush any stale denied-access entries: 
klist purge -li 0x3e7
Or restart the runner machine, or wait 15 minutes for the cache to expire. Step 3: Verify delegation is working. You must run the test as the service account (not your personal admin account) — that’s the identity Neo uses via RMM Component Credentials. On the runner, open a PowerShell prompt as the service account: 
runas /user:DOMAIN\your_service_account powershell
Then in that new window, run: 
Invoke-Command -ComputerName "EXCHANGE-SERVER" -ScriptBlock {
    Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn
    Get-ExchangeServer | Select-Object Name
}
This tests the full delegation chain: Runner → Exchange → Active Directory. Get-ExchangeServer requires Exchange to query AD, so if it returns the server name, delegation is working end-to-end.
  • If it succeeds — delegation is configured correctly.
  • If it fails with “The supplied credential is invalid” — the DC-side delegation is not configured. Verify that Step 1 was run with the correct Exchange server hostname, and that klist purge was run on the runner afterwards.
  • If it fails with a permissions error — delegation is working, but the service account may lack Exchange permissions.

​
6. Verify Connectivity

After completing setup, run these checks from the runner machine (or the DC if using direct execution) to confirm everything is working.

​
Neo API connectivity

The machine running scripts must be able to reach the Neo API. Run: 
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Invoke-WebRequest -Uri "https://engine.neoagent.io" -UseBasicParsing
Expected result: 401 Unauthorized — this confirms the server can reach Neo over HTTPS. If you see an SSL error or timeout, see Troubleshooting.

​
AD tools (if using on-prem AD)

Verify the runner has the AD PowerShell module and can query the domain: 
Import-Module ActiveDirectory
Get-ADUser -Filter * -ResultSetSize 1
Both commands should complete without errors.

​
Remote execution (if applicable)

If the AD Connect server or Exchange server is reached via remote execution, verify connectivity from the runner under the service account: 
# Test AD Connect server
Invoke-Command -ComputerName "AD-CONNECT-SERVER" -ScriptBlock { hostname }

# Test Exchange server
Invoke-Command -ComputerName "EXCHANGE-SERVER" -ScriptBlock { hostname }
Each command should return the target server’s hostname. If it fails, check:
  • PowerShell Remoting is enabled on the target (Enable-PSRemoting -Force)
  • The service account is in the Remote Management Users group on the target
  • Port 5985 or 5986 is open between the runner and the target

​
Exchange Hybrid

Use Exchange Hybrid when a client has both on-prem Exchange and Exchange Online — typically during a migration or in long-term coexistence. How Neo routes operations:
  • Standard mailbox operations (forwarding, delegation, shared mailbox conversion, permissions, etc.) route to Exchange Online via Microsoft Graph — the same as pure Exchange Online clients.
  • On-prem Exchange cmdlets (e.g., Enable-RemoteMailbox for hybrid mailbox provisioning) are executed on the on-prem Exchange server when Neo’s agent determines they’re needed.
Setup:
  1. Set Mailbox Provider Type to “Exchange Hybrid” in Company Settings
  2. Set the Exchange Server Hostname to the on-prem Exchange server
  3. (Optional) Set the Exchange Runner Hostname if the Exchange server doesn’t have an RMM agent — then complete Step 3, Step 4, and Step 5
If you already have a runner VM for AD operations, you can reuse it as the Exchange Runner — just set the Exchange Runner Hostname to the same machine and ensure the service account has the necessary Exchange permissions.

​
Troubleshooting

​
”The supplied credential is invalid” on Exchange Runner

Symptom: Exchange operations (e.g., Enable-RemoteMailbox) fail with: 
Active Directory operation failed on . The supplied credential for 'DOMAIN\service_account' is invalid.
Cause: This is the Kerberos “double-hop” problem. When Neo remotes from the runner to the Exchange server, Windows blocks the service account’s credential from being forwarded to Active Directory. The credential itself is valid — Windows is blocking the delegation. How to tell: If the same service account works for AD operations (password resets, user creation, group changes) but fails only for Exchange commands via a runner, this is the double-hop issue. Fix: Configure Resource-based Kerberos Constrained Delegation on your Domain Controllers. See Step 5 for instructions. Still failing after configuring? Check these common issues:
  • Kerberos cache: Did you run klist purge -li 0x3e7 on the runner (or restart it) after configuring delegation? Stale denied-access entries are cached for 15 minutes.
  • Wrong identity in test: When verifying with Invoke-Command, make sure you’re running as the service account (via runas /user:DOMAIN\service_account powershell), not your personal admin account. Check the whoami output.

​
SSL/TLS Certificate Trust Error

Symptom: RMM scripts fail with an error like: 
The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
Cause: The server running Neo scripts cannot establish SSL trust with engine.neoagent.io. This typically happens on older Windows servers with outdated root certificates. Diagnose: Run this on the affected server: 
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Invoke-WebRequest -Uri "https://engine.neoagent.io" -UseBasicParsing
  • Expected result: 401 Unauthorized (confirms SSL/TLS is working)
  • If you see an SSL error: The server’s certificate store needs updating
Fix:
  1. Update Windows root certificates — Install the latest Windows updates, or manually update certificates: 
    certutil -generateSSTFromWU roots.sst
certutil -addstore -f Root roots.sst
  2. Check TLS 1.2 is enabled — Verify in registry: 
    HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2
  3. Check server clock — Certificate validation fails if the system time is significantly off
  4. Check for proxy/firewall interference — Some security appliances intercept HTTPS traffic and can break certificate chains

​
No Internet Access / Firewall Blocking

Symptom: RMM scripts fail with connection errors, timeouts, or “Unable to connect to the remote server.” Cause: The server running Neo scripts cannot reach the Neo API endpoint due to no internet access or firewall restrictions. Fix: Ensure the server can reach https://engine.neoagent.io. Add a firewall rule to allow outbound HTTPS (port 443) to this endpoint. Diagnose: Run this on the affected server: 
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Invoke-WebRequest -Uri "https://engine.neoagent.io" -UseBasicParsing
  • Expected result: 401 Unauthorized (confirms connectivity is working)
  • If you see a connection/timeout error: The server cannot reach the endpoint — check firewall rules and proxy settings

​
Other RMM Platforms

Neo supports on-prem execution through any RMM platform that can run PowerShell scripts, including:
  • NinjaOne
  • N-Able N-Sight RMM
  • N-Able N-Central
  • ConnectWise Automate
  • ConnectWise RMM (Asio)
Using an RMM other than Datto? Reach out to us in Teams and we’ll help you get set up.