Intune vs RMM Reconciliation

Category: Devices & Infrastructure · View source ↗

Runs as: Skill Run it in Super Magic and confirm each write. A Flow can also fire a shared skill through the Run Skill action (beta), though this one is written for a person to run rather than a ticket event. Connectors: NinjaOneConnectWise RMMLiongardIT GlueHudu Role: Service & Ops Manager Outcome: Risk & Compliance When to use: “Do all of <client>‘s Intune devices have the RMM agent?”, a machine in Intune but invisible to monitoring (or vice versa), or before rolling out a policy that assumes one tool covers the whole fleet. Run it: across a client’s whole fleet, on demand (not a Flow — it’s a reconciliation pass, not a per-ticket event).

Prompt

Cross-check the Intune enrollment list against the RMM agent inventory for one client and produce three actionable buckets: missing RMM agent, missing Intune enrollment, and double-managed conflict candidates. Read-only.

Resolve the client organization in the RMM and pull its full device list (whichever RMM is connected — NinjaOne or ConnectWise RMM). If a listing may have capped, report the count as "at least N".
Get the Intune side. There is no direct Intune tool: read Intune device data from the environment's posture in Liongard when enabled — first verify the M365/Azure/Intune inspector exists and last ran successfully, then read the device list, stating the dataprint age. If the inspector is absent or its last run failed, ask the requester to export the Intune device list (Devices -> All devices -> Export) and paste/attach it. Never guess the Intune population.
Normalize before matching: lowercase hostnames, strip domain suffixes, match on serial number where both sides expose it — hostname alone misses renamed machines. Flag rows matched on hostname only as lower confidence.
Bucket results: (a) in Intune, not in RMM -> missing agent (agent-deployment candidate); (b) in RMM, not in Intune -> enrollment gap (MDM-enrollment candidate, or a server/appliance where Intune is not expected — separate those out); (c) in both -> check for double-management conflicts (both tools owning patching or pushing conflicting policies). Note which tool is intended source of truth per function if the documentation (IT Glue / Hudu) says.
Age-filter noise: a device last seen by either side >~30 days ago is likely retired, not a gap. List stale devices separately as "verify then retire".
Output a reconciliation table per bucket (device, last seen in each tool, match confidence, recommended action). Deploying agents or enrolling devices is not something this skill can do — hand off with the exact device list and, for RMM-side work, the device's RMM context. Offer to open a remediation ticket per bucket or leave a plain-text summary note (no markdown/emojis).

Guardrails: never claim the Intune list is complete unless it came from Liongard or a user-supplied export; say which source you used and its as-of time. Serial-number matches are authoritative; hostname-only matches are stated as probable, never certain. Do not recommend removing either management agent from a double-managed device without the client's documented management model — flag the conflict, do not resolve it unilaterally. Read-only — no agent installs, enrollments, or policy pushes (this integration cannot run scripts or deploy software). If neither Liongard nor an export is available, stop after the RMM inventory and say the Intune side could not be verified.

​Prompt

Prompt