Active Directory · MECM ⇄ Intune

From on-premises to the cloud, without losing the thread.

Meti reads your four consoles into one database — Active Directory, Entra ID, MECM, Intune — and your CMDB on top. It runs the four migration tracks from the same table, and measures progress from what it collected rather than from what it is told.

4Consoles read, plus the CMDB
4Migration tracks
2Health checks, MECM and Intune
3Hand-over formats
The problem

Migrating an estate is not migrating applications

An on-premises estate lives across three consoles that cannot see each other, and each keeps what matters in its own detail. Migrations rarely fail on an application: they bog down on everything nobody thought to count.

The estate is spread across three consoles

Active Directory holds the objects and the group policies, MECM the applications and the collections, Intune whatever has already moved. None of the three sees the other two: « how far along are we » has nowhere to be asked.

What matters is in the detail, not in the list

Replaying an application needs its command line, its detection, its sources and its requirements, scattered across its deployment types. For a GPO it is worse: LDAP holds its identity, only SYSVOL holds its settings.

After the migration, nothing links the two

A fixed version on the MECM side never reaches Intune. The two estates drift apart silently, and the drift only shows when it costs something.

Progress is something you have to ask someone

A percentage of the estate migrated gets negotiated in a meeting and changes with whoever is asked. Until it is measured against the objects themselves, it is an impression.

The sources

Four consoles, one database

Objects are collected into a local database, and the pages read from it rather than querying the consoles live — which is what lets one dashboard span all three. Switch on only the ones you are allowed to read: a console switched off is never asked, its pages leave the menu, and scans skip it instead of failing.

Directory

Active Directory

Computer objects as the directory itself holds them — which is not the same list as MECM discovery, filtered by its own scopes. And the group policies, with what LDAP knows about them: where they are linked, whether each link is enabled or enforced, and whether either half is switched off.

  • computer objects, replicated last logon
  • group policy objects and their links
  • GPO settings, read from SYSVOL
On-premises

MECM / SCCM

Read through the AdminService or, on a domain-joined host, straight through WMI. Applications and deployment types, packages, collections, discovered devices — and the delegation, meaning who can change what on which machines.

  • applications, deployment types, packages
  • collections and discovered devices
  • site health check
  • delegation: security scopes and collections
Cloud

Entra ID

The cloud directory, read in its own right: the devices it holds, the groups that act as assignment targets, and each machine's join — hybrid or native. It is also what authenticates the people who open Meti.

  • devices and join type
  • groups, the targets of assignments
  • accounts, and Meti's own sign-in
Cloud

Microsoft Intune

Read and write through Microsoft Graph. This is the only side Meti writes to — and it writes as you, bounded by your own roles.

  • applications and assignments
  • configuration policies and their settings
  • compliance policies, managed devices
  • tenant health check
  • delegation: scope tags and scope groups
Reference

Your CMDB

Imported from a CSV export — a file handed over by the asset manager needs no service account, no API key and no firewall rule — or read through its API. Twelve products are recognised out of the box, from ServiceNow to GLPI, each with its own status words.

  • columns guessed, in French as in English
  • every distinct status shown and mapped
  • the serial number, the join the directory never offers
The tracks

The four migrations

Four separate tracks, run from the same table: the group policies, the applications, their assignments, and the machines themselves. None of the four is a matter of retyping.

Migration

GPO → CSP

Where every GPO setting stands against Intune, one setting per row and across every GPO — read from SYSVOL, since LDAP holds a GPO's identity and never its settings. The migration writes one Settings Catalog policy per GPO. Preferences, the other half of a GPO, go to their native Intune form where one exists, become a detection and remediation pair where none does, and are put to you as a decision where neither would be honest. Planning walks SYSVOL: nothing happens until you ask.

Migration

Applications MECM → Intune

Every application both consoles hold, and what has been done with each: a MECM application and its Intune counterpart share a row, and an application Intune holds alone says so. An advisor recommends the right Intune type with its reasoning, a tabbed wizard carries the MECM data over, the .intunewin is generated from the sources by Microsoft's Content Prep tool, then the content is uploaded.

Migration

Assignments MECM → Intune

Each MECM deployment of an application becomes an Intune assignment: the application it was migrated to, assigned to the Entra group — or the Intune built-in target — that stands for its collection. Each one reproduced counts towards progress, so migrating an application without deploying it cannot pass for finished work.

Migration

Hybrid Join → Full Entra

Take a machine out of the domain and join it to Entra ID, device by device and in waves. A recovery account is created and its password shown once — it is the only way in if the migration stops between the two. A bulk join package saves asking the user to join their own machine. Machines report their progress live; those off the network do so through an Azure relay Meti opens itself, outbound on 443, with nothing coming in.

Beyond the migration

The analyses, and the steering

Migrating means reading first, and what you read on the way is often worth the trip on its own. Each of these analyses opens on its last reading rather than querying the console again on every display.

Diagnostics

MECM health check

The state of the site and a security audit in one page: roles and servers, disk space tightest first, client health, deployments by failure rate, collection evaluation past the guidance ceiling, automatic deployment rules failing silently. Server hardening is collected by a read-only script that prints facts only, never verdicts — the grading stays in Meti, in one tested rule set. A fourth status sits beside pass, warn and fail: nobody could take this reading, which never rounds down to « fine ».

Diagnostics

Intune health check

The same reading on the cloud side, run with every collection that reads Intune: what is in place, what is not, and what is in place without serving anyone. It opens on its last analysis rather than querying the tenant again on every display.

Analysis

Intune CSP analyzer

Whether two policies fight over the same setting, whether one applies to nobody, and whether an exclusion has quietly cancelled an include. Settings and assignments read together: a policy is not a thing, it is a claim about a population. One setting per row and across every policy, so that « who sets this, and to what » becomes a filter rather than a tour of every policy.

Analysis

RBAC Analyzer

Who can change what, over which machines, in both consoles. Two answers, because there are two mechanics: Intune bounds with scope tags and scope groups, MECM with security scopes and collections — and the two fail differently, Intune by omission, MECM by leaving a default in place that looks like a boundary and is not. Every finding is written out in words: a role held by a named individual rather than a group, a custom role nobody holds, a scope nothing references.

Analysis

Intune rings

How far a change has reached from one ring to the next — the sentence Intune has never been able to say, listing policies and listing assignments without ever stating that production is two changes behind the pilot. Settings are grouped by the pattern of their disagreement, meaning which rings hold which value, rather than blended into one diff that would mix every change in flight.

Denominator

Source of authority

A compliance report at 75% whose missing quarter is half machines that no longer exist teaches nothing: they are still in the directory, so still in the denominator. Name the list you trust — Active Directory, Entra ID, Intune, MECM or the CMDB — and the estate is read against it, in four standings: held, retired, unknown, out of scope. The raw rate stays printed beside the adjusted one, without which an authority would just be a filter that improves everything.

Steering

Migration progress

How much of the on-premises estate has moved to Intune, measured from what was collected, and how that figure has changed since the first measurement. Every migrated object counts towards it — an application created but never deployed cannot pass for finished work. Beside it, tiles of your own: counts, charts and tables built on any collected property, with conditional formatting and value mapping.

Hand-over

Reports & logs

A catalogue of about three documents per page, and one engine that renders them in three formats, chosen at the moment of export: a self-contained HTML that opens on a double-click on a machine with no network, a PDF, and a PowerPoint with native charts — so a client can restyle it and read its data. Plus CSV for a spreadsheet. The logs keep every collection and every synchronisation: a read that failed is a fact about Meti, not about the estate, and belongs there rather than as a banner across the page that happened to notice it.

Flagship feature

Linking & synchronisation

This is what sets Meti apart from a migration wizard: once an object has moved to the cloud, the pair stays alive.

A link ties one MECM application to one Intune application: neither side can be linked to two counterparts. It remembers whether it came from a migration or from a manual match, and carries its own synchronisation policy.

To take over an estate that has already been migrated, bulk linking proposes candidate pairs with a confidence score computed from the name, the publisher and the version; the best are pre-selected and you confirm the batch in one go. The link survives the loss of the local database: a marker is written into the Intune application's notes field, and a rebuild reads those markers back to restore the pairs.

auto

Differences are applied with no intervention.

manual — the default

You review the comparison and choose what goes across.

none

Nothing propagates; the divergence is deliberate.

When a pair drifts apart

A « Drift » badge appears in the table. One click opens the comparison, grouped by kind: metadata, installation, uninstallation, detection.

FieldIntune nowMECM incoming
displayName7-Zip 23.017-Zip 24.09 (x64)
displayVersion23.0124.09
publisherCloud Managed InstallationIgor Pavlov
installCommandLinemsiexec /i 7z2301-x64.msi /qnmsiexec /i 7z2409-x64.msi /qn

You apply whichever groups you want, field by field. MECM is the reference: it holds the truth about the package, and Intune follows. Intune's filler values are treated as empty — they never overwrite real MECM data. Every comparison and every applied change is logged.

Running it

Technical foundation & prerequisites

One process to install, a local database, and rights that stay yours.

A single process

A React interface and a Node server in one process, nothing to host beside it; Node 20 or later. MECM access assumes a domain-joined Windows host, or one with network line of sight to the site; packaging assumes Microsoft's Content Prep tool and the source shares.

A local database

SQLite in WebAssembly, with no build tooling: installable on heterogeneous Windows VMs. The whole configuration — counts, charts, columns, dashboards, naming — exports as a single JSON to set up another install identically, never including the credentials.

The agent, signed

The migration plan becomes one signed PowerShell file: everything the agent will run is in it, and the state beside it is data it reads and never executes. It crosses the restart, resumes at the step it stopped on, and refuses to run on a machine it was not written for.

Nightly collections, read-only

The progress curve advances every night rather than on the days somebody remembers, and a night missed is made up once at restart. At night there is nobody: Intune is then read by an application identity whose every token capable of writing is refused before its first call.

Your rights stay yours

Meti acts as you, not as itself: what it can do in Intune is bounded by your own roles and scope tags, and every change carries your name in the audit log.

Access to Meti itself

Who opens Meti, and what they see in it, is set by roles and by attributes, with an access policy able to name an Entra group rather than accounts one by one. The database backs itself up: a week of daily backups, without being asked.

An estate to move to the cloud?

Ask for a demonstration and describe your context — which MECM version, how large the estate, what is already in Intune, and which track worries you most. We answer within two working days.

Request a demo
← → or Space to move · P for the presenter view · Esc to leave