FIM

HRESULT: 0x8023063D when attempting to run multiple Sync Run Profiles in MIM/FIM after applying rollup build 4.3.2124.0

A new hotfix rollup was released on the 11th of March Microsoft Identity Manager contains a number of fixes and some new functionality.

It appears that it also contains a new bug. Information about this came to my attention from Ryan Newington

The bug kicks in if you’re trying to run sync sequences on multiple MA’s simultaneously. It throws the error; “Unable to run the management agent.” Exception from HRESULT: 0x8023063D

The screenshot below shows the error when attempting to run a Full Synchronization on an MA when another MA is already running a Full Synchronization.

Note: You CAN still run Stage (Full Import) sequences on multiple MA’s simultaneously.

After rolling back my MIM Sync Server (to 4.3.2064.0, the snapshot prior to applying the 4.3.2124.0 rollup) I can again run multiple sync sequences across multiple management agents simultaneously.

Summary

If your run sequences include running multiple sync jobs running simultaneously don’t update your MIM/FIM Synchronisation Server to 4.3.2124.0.

Microsoft, can we have a fix please.

Follow Darren on Twitter @darrenjrobinson

Darren Robinson

Bespoke learnings from a Microsoft Identity and Access Management Architect using lots of Microsoft Identity Manager, Azure Active Directory, PowerShell, SailPoint IdentityNow and Lithnet products and services.

View Comments

  • I don't believe this is a bug, but rather preventing you from doing what shouldn't be done, i.e. running synchronization run profiles concurrently. That can easily lead to deadlocks, and possibly data corruptions, given two synchronization runs running at the same time may try to synchronize the same object at the same time.

    They are addressing this in the hotfix, i.e. issue 4. Running more than one run profile with a synchronization task at the same time may cause data corruption. Note A message box is displayed with a 0x8023063D error code.

    That's exactly the behaviour you're seeing.

    Cheers,

    Marc

    • I understand your viewpoint Marc if you're using FIM/MIM to managed a single object type.
      Many of my implementations are managing many different object types across multiple MA's. This is where is makes perfect sense to run them in parallel.
      Decisions to run them like this should be up to the implementer not a constraint in the product.

      DR

  • Do we know if there is a workaround to this issue?

    We have many MAs so now having to run in parralell is taking days rather than hours. Is this logged formally with Microsoft?

    • Microsoft are aware this is an issue for some implementations. I previously just hadn't applied that hotfix. Now for the one implementation that needs this that is on the latest patch level I've split the Import from the Sync. It's multiple Syncs that throw the exception. You can still run multiple Imports Only in parallel.

Recent Posts

Visualising your IP Address using PowerShell and AI

A few weeks back the Microsoft AI Tour was in Sydney Australia. There was a…

2 months ago

Where the heck is the PowerShell Module loading from?

If you're anything like me you always have PowerShell open, and often both PowerShell and…

5 months ago

Express Verified ID Setup

Decentralised Identity is a technology I'm passionate about and have written many posts and tools…

6 months ago

Orchestrating 1Password with PowerShell

Over two years ago I authored a PowerShell Module that enabled the automation of 1Password.…

9 months ago

Entra ID Tenant ID & Custom Domains PowerShell Module

Buried in my PowerShell Snippets Vol 4 post from 2021 is the PowerShell script and…

9 months ago

Windows Subsystem for Linux instance has terminated

Short post on how to recovery from "The Windows Subsystem for Linux instance has terminated"…

10 months ago

This website uses cookies.