Runbooks/Mim Migration

MIM migration

This runbook is for the consultant or operator moving a Microsoft Identity Manager (MIM) estate onto IdentityMesh. It covers what the analyzer reads, the three ways to run it, how to read the Service policy translation and its summary, how to resolve a set that needs input, and the order to do the work in.

For what the analyzer produces and what each verdict means, see the MIM migration page.

What the analyzer reads

The analyzer reads an exported MIM configuration. It never connects to MIM and writes nothing back to it. Give it one folder that holds:

FolderWhat goes in itNeeded for
SyncConfigThe Sync Engine server configuration export: the metaverse file and one file per management agent.Everything. Without it there is nothing to analyze.
ServiceConfigThe MIM Service export: policy.xml (sets, policy rules, workflows) and schema.xml.The Service policy translation.

When ServiceConfig is missing or empty, the analysis still runs on the Sync Engine export and reports that the Service export was not supplied. The Service policy translation is then empty. If the Sync Engine export shows the MIM Service is in use, the report says the Service export step was skipped.

The export holds account names, server names and your policy. Treat the folder, and every file the analyzer writes, with the same care as the export itself.

Three ways to run it

All three read the same export and compute the same translation.

WhereWhen to use it
Admin Portal, Migration pageYou will apply the result. Upload the export, work through Assess, Resolve, Service policy and Preview, then press Create in the mesh. Your choices are saved on a migration project.
Desktop analyzerA read-only assessment on a workstation, with no IdentityMesh server. Installed by the MIM Analyzer installer.
Command lineScripted or repeated runs, or a report to send. Installed by the same installer as imanalyze.

Desktop analyzer

Start the desktop analyzer, choose the folder that contains SyncConfig, and step through the wizard. Step 4, Service policy, is read-only. It shows a summary line, the Sets (proposed Composer rules) grid with Readiness and Depends on columns, the Attributes to migrate first grid, and the Policy rules (proposed mesh workflows) grid.

Command line

imanalyze analyze <export-dir> --out <analysis.json> --policy

<export-dir> is the folder that contains SyncConfig. The report is written to the --out path.

With --policy, the analyzer also writes a second file, policy-translation.json, beside the report. It holds the Service policy translation and the summary: the attributes to migrate first and each set’s readiness and dependencies. The command prints the path of each file it writes.

If the translation fails, the command prints a line starting with WARN: policy translation failed and carries on. The report is still written and the exit code does not change.

Exit codeMeaning
0Analyzed, no errors in the findings.
1The command line was wrong. The usage text is printed.
2The export could not be read. The reasons are printed and nothing is written.
3The report was written, but the analysis found errors. Read them before you trust the report.

The desktop analyzer and the command line work from the export alone. They do not know your selection, your filled values or your live mesh, so their readiness can differ from the portal’s. The portal’s readiness is the one that decides what Create in the mesh does.

Reading the translation

The chain behind each criterion

A set filter names attributes in the MIM Service. Their data arrives from your source systems through the Sync Engine. For every set criterion the translation records the chain it was resolved through:

  1. The attribute in the MIM Service.
  2. The import flow on the MIM Service management agent.
  3. The metaverse attribute that flow lands on.
  4. The import flows from your source systems that fill that metaverse attribute.
  5. The mesh attribute it becomes, after any object-type mapping.

In the portal, expand a set. Each criterion, and each unresolved item, shows this as a line starting with via, for example:

via Department (Service) → FIM Service MA import → person.department ← HR SQL → person.department

When a hop fails, the line stops there and says why:

The line ends withWhat it meansWhat the step offers
(no flow)No import flow on the MIM Service agent mentions the attribute. It exists only in the MIM Service.A suggested create: the attribute is added to the mesh type and the mesh owns its values.
(scripted flow)A flow carries it, but through a script that cannot be followed.Nothing is suggested. Fill the mesh attribute yourself.
(not proposed)A direct flow lands on a metaverse attribute that is not in the proposed mesh schema.Nothing is suggested. Fill the mesh attribute yourself.

The desktop grids and policy-translation.json carry the same chain.

The summary: attributes to migrate first

In the portal this is the Migration plan panel at the top of the Service policy step. It counts how the set criteria resolved:

CounterMeaning
resolvedThe chain reaches a mesh attribute.
Service onlyNo flow. A suggested create is offered.
ambiguousMore than one flow could be meant. Pick the mesh attribute yourself.
scripted flowThe flow cannot be followed.
not in the proposed schemaThe metaverse attribute is not proposed.
sets with no mesh typeThe set’s object type cannot be resolved to a mesh type.

Open the panel to see Attributes to migrate first. Each row is a metaverse attribute, the mesh attribute it becomes, the source systems that fill it, and how many sets depend on it. The list is ranked by that count, most first.

The ranking answers which source flows to bring across first. A set’s criteria can only be evaluated once the attributes they read hold data in the mesh, and that data comes from the source systems, not from the MIM Service. Sets that lean on the same attribute become ready together once its source system flows into the mesh. So the attribute at the top unblocks the most sets.

Show sets on a row filters the Sets tab to the sets that depend on that attribute. Show all sets clears the filter.

Readiness

Every set not yet translated carries a readiness badge beside its verdict. The Any readiness filter next to the verdict filter narrows the Sets tab to one value.

ReadinessMeaning
readyNothing is left for you to do.
needs inputA value is still to be filled in, a suggested create has not been accepted, or a criterion names an attribute your live mesh does not have yet.
blockedThe set waits for the proposed schema to be created first, or its object type has no mesh type.
not applicableYou dismissed the set.

An expanded set also shows Depends on, the attributes it reads with their source systems, and creates, the attributes it will add.

Readiness and the ranking are worked out when the step reads the proposals. After you fill a value, accept a create or dismiss a set, the badges change the next time the step reads the proposals, such as when you open the step again.

Resolving a set that needs input

You need the schema.write permission to change anything on the step. Every change is saved on the migration project as you make it. Nothing is created until Create in the mesh.

A mesh-owned attribute starts empty. Its values come later, from a workflow’s Set attributes step or from an assignment.

Order of work

  1. Schema first. On Resolve, decide what of the proposed schema you are migrating, and map MIM object types onto mesh types you already have. Create in the mesh creates the schema before anything else, and sets marked blocked wait for it.
  2. Then the attributes. Work down Attributes to migrate first. Bring each source system across and let it fill the attribute, starting at the top of the list. Accept the suggested creates for the Service-only attributes. Fill what is scripted or not proposed.
  3. Then the sets. Filter by ready, Include those sets, check Preview, and press Create in the mesh. Composer rules and workflows are created disabled. Evaluate each new group once before you enable the workflows that trigger on it.

Repeat steps 2 and 3 as more sets become ready. A second run of Create in the mesh skips what the first one created.