The connector's local guard

Vertex's settings live on the Entrosity server. The local guard is what an administrator of the domain controller agreed to: which OUs Vertex may change, which kinds of change, and how many per minute. The Axis connector refuses every Vertex change that the guard does not allow, whatever the server sends. Nothing over the network changes the guard: only the rmm-connector vertex guard commands, run on the domain controller from an elevated prompt.

Reads (sync, live reads, reports, the test, backups) do not need the guard.

What the guard holds

Field	Meaning
State	pending (never accepted), accepted, or mismatch (Vertex now sends different managed OUs; they wait for acceptance).
Managed OUs	The OUs that were accepted (lower-cased and sorted).
Pending OUs	A newer list from Vertex, waiting for accept.
Allowed classes	Which kinds of change are switched on locally: user, group, ou, gpo, pso. A new guard allows users, groups and OUs; GPOs and password policies are off.
Deletes	Whether deletes are allowed. Off in a new guard.
Max writes per minute	The local write cap, default 1,000, from 1 to 2,000.

The guard is the file vertex-guard.json in the connector's data directory (%ProgramData%\RMM Connector). It is owned by Administrators and only SYSTEM and Administrators may read or change it. A file that anyone else can change is not trusted: every change is refused with guard_pending and the guard commands fail, until its permissions are corrected or the file is deleted (the guard then starts again as pending). The connector reads it for every job, so a change takes effect without a restart.

Commands

Run them on the domain controller, from an elevated command prompt (only administrators can read the guard file):

cd "C:\Program Files\RMM Connector"
rmm-connector vertex guard show
rmm-connector vertex guard accept [--ou "<DN>" ...] [--yes]
rmm-connector vertex guard set [--user on|off] [--group on|off] [--ou on|off] [--gpo on|off] [--pso on|off] [--deletes on|off] [--max-writes-per-minute N]
rmm-connector vertex guard reset

Command	What it does
show	Prints the state, the managed OUs, the pending OUs, the allowed classes, deletes and the cap. Before the first Vertex change it says No Vertex job seen yet.
accept	Lists the OUs to accept, asks you to type yes (--yes skips the question), and accepts them. With --ou (one per managed OU) it accepts exactly those OUs, also before Vertex sent any job. Without --ou it accepts the OUs Vertex sent: a pending list replaces the accepted one.
set	Switches classes, deletes and the cap. Only the flags you give change.
reset	Withdraws the acceptance: every Vertex change is refused until the next accept.

Before Vertex sent any job there is no guard yet. accept --ou creates it; set and accept without --ou answer no Vertex job seen yet until then. Otherwise the connector creates the guard, as pending, when the first Vertex change reaches it (that change is refused with guard_pending), and accept without --ou accepts the OUs it carried.

The OUs given with --ou must be exactly the managed OUs in Vertex's settings: all of them and no others (case and spaces after commas do not matter). If Vertex later sends a different list, its changes are refused with guard_pending and the list waits as pending OUs (Changed managed OUs).

Typical setups

The recommended order: configure Vertex's settings (with the managed OUs), then accept the guard and switch on what you need on the domain controller, then run the test and the sync, and only then make changes.

rem Users, groups and OUs only (the defaults), no deletes, before any job:
rmm-connector vertex guard accept --ou "OU=Students,OU=School,DC=school,DC=local" --ou "OU=Staff,OU=School,DC=school,DC=local"

rem Everything, including GPOs, password policies and deletes:
rmm-connector vertex guard set --gpo on --pso on --deletes on

rem Read-only for Group Policy again:
rmm-connector vertex guard set --gpo off

How a change is checked

For every Vertex change the connector:

1. refuses it if it arrived after its expiry (expired);
2. records the managed OUs it carries; if they differ from the accepted ones the state becomes mismatch;
3. refuses it unless the state is accepted (guard_pending);
4. refuses it unless its class is allowed and, for a delete, deletes are allowed (guard_denied);
5. counts its writes against the cap (rate_limited).

Only then does it ask for the job's secrets and run the script, which checks the managed OUs, protected objects and denied attributes once more before it writes.

The class of a change follows its object: user, group or OU changes (attributes, move, rename, delete), group membership (group), Group Policy (gpo), password policies (pso). A bulk import is user.

Changed managed OUs

When a tenant admin changes the managed OUs in Vertex, the next change the connector receives carries the new list. The guard keeps the accepted list, records the new one as pending, and refuses changes (guard_pending, the managed OUs changed) until a local administrator runs rmm-connector vertex guard accept again (without --ou it accepts the pending list; with --ou it accepts the OUs given). Check the list that accept shows before typing yes.

The write cap

The connector allows at most max writes per minute Vertex writes (default 1,000, from 1 to 2,000). Each change counts one write, except:

Change	Counts
Group membership	One per member added or removed (up to 500 of each).
Registry settings of a GPO	One per value set or removed.
A bulk import batch	One per row (up to 200).

A change that would exceed the cap is refused as a whole with rate_limited. The default fits a whole import batch (200 rows) or a membership change (500 members added and 500 removed); several such jobs within a minute can still reach it. Lower the cap to slow Vertex down, or raise it up to 2,000:

rmm-connector vertex guard set --max-writes-per-minute 2000

The cap is in addition to Vertex's own limits of 600 changes per user and 2,000 per tenant per minute (which do not count import batches).