RMM

Everything one managed Windows machine shows you: the tabs across the top, what each one holds, the switches and the policy in force, and the tray menu those devices display.

The two lists on RMM > Devices that decide where a tech looks first: the card of installs that never joined, and the roster's own needs-attention order, with the sort, the bulk picks and the ten filters behind the Filters button.

A tour of the Policies area that set-up-a-policy does not cover: defaults, per-client assignment, tag exceptions, and the General, Patching, Maintenance, and Permissions tabs.

The other pages under RMM besides Policies - devices, the agent's own self-update channel, the shared third-party patch catalog, the script library, alerts, and device approval - each shown once, on an instance that has one policy and zero enrolled devices.

ezCyber does not build screen control of its own, and the reason has not changed. A Splashtop Business integration is built in: one Enable card under Integrations, no credentials and no API key. On a device running the Splashtop streamer, the Actions menu gets a Splashtop row that opens the session in your own Splashtop Business app. ezCyber is looking for a ScreenConnect partner to build the same one-click launch.

Walk RMM > Policies as it stands today: the four default policies every instance ships with, one new policy of your own built end to end (monitoring threshold, patch approvals, the install schedule, both restart choices, the repair ladder, third-party apps, agent settings and one armed command), giving that policy to one client for one device type, reading the assignment back on the client's own record, and the two places a real machine picks it up.

Every machine you know about sits in one list, whether our agent is on it or another system told us about it, and the two columns on the right are how you tell which is which and what you can do about it.