MIM — Cleanup orphaned Expected Rule Entries (ERE’s)
Microsoft Identity Manager offers several ways to control provisioning and deprovisioning to target systems. The following is a brief overview of the possibilities with the main advantages and disadvantages.
Metaverse Provisioning Rules Extension
- Requires code
- Does not require MIM Service/Portal
Synchronization Rule via Policy
- Codeless
- Requires MIM Service/Portal
- Creates Expected Rule Entries (EREs)
- High number of objects due to EREs, problematic in environments >20k identities. The value is only an indicator, it is also strongly dependent on the number of target systems which cannot be handled with scope based synchronization rules.
- If you do not need to deprovision target systems before MV object deletion you should not use policy based synchronization rules. And even if needed, scope based synchronization rules can be combined with a small piece of code [MVExtension]. Thanks to Kent Nordström for his post on this topic.
- Should no longer be used, but in a few exceptional cases are the only way to remain 100% codeless.
Synchronization Rule via Scoping Filter
- Codeless
- Requires MIM Service/Portal
- Not able to deprovision from target systems before metaverse deletion
- Can be combined with a MVExtension for deprovisioning from target systems before metaverse deletion
Codeless sync with community tools
So you chose Synchronization Rule via Policy, huh?
But you may not be aware that when deleting identities, Expected Rule Entries (ERE’s) orphan in the system and unnecessarily increase the number of objects.
Depending on the system specific configuration, this may not necessarily be the case, but it is easy to check with the following search
MIM Portal → Administration → All Resources → Expected Rule Entry
Resource Parent is the reference attribute that should contain the object for which the ERE was created. If this attribute is empty, the object for which the ERE was intended no longer exists and can therefore be deleted.
Let’s clean it up!
Since EREs can become orphaned again and again during operation, a one-off clean-up is not sufficient. So we need a permanent process.
Set
Workflow [MIMWAL]
Management Policy Rule
Type: Transition In
Transition Set: See above
Workflow: See above
You have so much to clean up?
If you have a certain number of objects, it can take a long time if we would start the above process via “Run on Policy Update”. I recommend to do the initial deletions with LithnetRMA.
I haven’t found a perfect way to perform the deletion yet, the following code has to be executed multiple times to perform the deletion for 250 objects per request.
$totalObjects = Get-ResourceCount "/ExpectedRuleEntry[not(ResourceParent=/*)]"Write-Host "TASK: Remove ExpectedRuleEntry"
Write-Host "Total items: " $totalObjects$pager = Search-ResourcesPaged -XPath "/ExpectedRuleEntry[not(ResourceParent=/*)]"
$pager.PageSize = 250while($pager.HasMoreItems){$resultSet = $pager.GetNextPage()Remove-Resource -ResourceObjects $resultSetWrite-Host "SAVED PAGE: Current index: " $pager.CurrentIndex " of $totalObjects"}
