Active Directory
With a site connector installed, Entrosity Axis can mirror the computer objects of an Active Directory domain and push the agent to them. Everything here needs the tenant admin role.
Create a sync configuration
Under Active Directory, choose New configuration:
| Field | Meaning |
|---|---|
| Name | A label, e.g. the domain name. |
| Connector | The site connector that talks to this domain. |
| Site for new devices | The site computers found by this sync are put in. |
| Domain controller | DNS name of a DC (e.g. dc1.corp.example.com). Use the name, not an IP address, so the certificate matches. |
| Port | 636 for LDAPS, 389 for StartTLS or plain LDAP. |
| Encryption | LDAPS or StartTLS (recommended); plain LDAP only in labs. |
| CA certificate (optional) | PEM of the CA that issued the DC certificate, when the connector server does not trust it. |
| Skip certificate verification | For tests only. |
| Bind account | A read-only domain account (UPN or DN) and its password. The password is stored encrypted and only sent to the connector when a job runs. |
| Base DN | e.g. DC=corp,DC=example,DC=com. |
| OUs | Pick OUs to include or exclude from the tree (loaded live from the DC). |
| Extra LDAP filter (optional) | ANDed with (objectCategory=computer), e.g. (operatingSystem=Windows*). |
| Sync interval | 5 minutes to 7 days; default 60 minutes. |
| Push account (optional) | A domain account that is local administrator on the PCs; needed for agent push. |
| Auto-push | Push the agent to newly discovered, enabled computers after each sync. |
Test and sync
- Test connection asks the connector to connect and bind, and shows the result: the number of computers found and the DC's naming context, or an error code (see LDAP errors).
- Sync now starts a run immediately. Only one run per configuration
can be active (
run_in_progress).
Each configuration shows its run history: trigger (manual or scheduled), status, and the counts of computers seen, created, updated, matched and gone.
Scheduling and failures
The server owns the schedule. After a failed run the next attempt is delayed exponentially (interval × 2^failures, at most 24 hours), and the AD sync failing alert opens.
AD computers
AD computers (in the sidebar for everyone who can see devices) lists every computer object the syncs found: whether it runs the agent, its push status, OS, OU, whether its account is enabled, its last logon, and whether it is still in AD.
Agent coverage and why pushes failed
The top of the page answers "which computers have the agent, and why do the others not?" for the selected OU (and every OU below it), or for all computers:
-
N of M computers run the agent, with a progress bar.
-
Five figures, each of which filters the list when clicked (click it again to clear the filter):
- With agent;
- Without agent;
- Being pushed (queued or in progress);
- Push failed;
- Never pushed.
The push figures count computers that are still in AD and still have no agent.
-
Why pushes failed lists the error codes of the failed pushes with how many computers each has, what it means and what to do. Click one to list those computers. Details are in Troubleshooting.
In the list:
- Agent is Managed (the agent runs; the link opens the device) or No agent.
- Push shows the last push:
- Never pushed;
- its state and when it happened;
- for a failure, the reason and the fix. Hover to see the full error message.
The counts refresh by themselves while pushes run.
Browse by organizational unit
The OU tree beside the list works like the one on Devices. It shows the domain, its OUs and containers with their computer counts. Selecting an OU filters the list and the figures to that OU and everything below it. Hide it with the button in its header, and bring it back with Show OUs. On small screens, use the OU filter, which lists the same tree.
Other filters:
- Agent (with or without);
- Account (enabled or disabled);
- In AD (present or gone);
- Push (never pushed, being pushed, failed, succeeded);
- the domain, when there are several.
How AD computers and agents are matched
When a computer is synced or an agent enrolls, the server looks for an existing device in this order:
- machine SID = AD
objectSid; - FQDN = AD
dNSHostName(case-insensitive); - hostname = AD
nameand the same domain.
A match makes one device with source both. Otherwise a new device is created: AD-only devices have status never connected. If a match is missed, merge the two records.
Computers that disappear from AD
A computer that is no longer found is marked gone (and un-marked if it
comes back). AD-only devices whose object has been gone for more than 30
days get the custom field ad_missing = true. They are never deleted
automatically.
Push the agent
- Set the push account on the configuration.
- On AD computers, select computers (or filter, e.g. by OU) and choose Push agent.
- Each row shows the push status as it moves through queued,
connecting, copying and installing, and ends as success or an
error code such as
winrm_disabledoraccess_denied.
The connector pushes to 5 computers at a time per job (two jobs in parallel), with a 10-minute timeout per computer.
How a push works:
- Resolve the name and connect over SMB (port 445) with the push
account, the way PsExec or PDQ Deploy do. If the
RMMAgentservice already exists, the result is success (already_installed). - Copy the agent MSI to
\\host\ADMIN$\Tempand startmsiexecthrough a temporary service, with a push enrollment token and the server URL. The connector follows the installer log, so a failed install shows its exit code and log lines within seconds. - When port 445 is closed or the
ADMIN$share is not usable, the connector uses WinRM instead (HTTPS 5986, else HTTP 5985 with message encryption): it copies the MSI in chunks, checks its checksum and runsmsiexec.
The MSI is the newest published stable agent release.
A failed row shows the connector's message, which names the channel (SMB or WinRM) and the step that failed, and a suggested fix below it.
Error codes and fixes are in Troubleshooting → Pushing the agent fails.
Make the push account a local administrator with a GPO (Restricted Groups), and allow File and Printer Sharing (TCP 445) from the connector server in the domain firewall profile. WinRM (Allow remote server management through WinRM, plus the firewall rule) is only needed where SMB is blocked. The connector server must resolve the files host of this portal: if its DNS server hosts a zone for the portal's domain, add the record there.