none
LAB: MIM2016 ADMA's failing to Refresh Schema against forests after the Exchange 2013 schema was applied RRS feed

  • Question

  • I have a production replica MIM integration lab with my source forest being Windows 2012 R2 \ Exchange 2013. My target forests where I am only using Outbound Sync Rules to push accounts are Windows 2012 and I just applied the Exchange 2013 schema update without having actual exchange servers in the target forests.

    MY Target ADMA's do not have all the Exchange attributes available and Refresh Schema command is failing:

    Retrieving the management agent data ...
    Retrieving the management agent data complete
    Retrieving the new schema ...
    An error was encountered during the schema refresh. Please try again later.

    I saw one post that recommended that the ADMA would need deletion and re-creation? Wouldn't that break all my Sync rules, workflows, sets, etc

    any ideas?

    -Stu

    Tuesday, October 6, 2015 4:16 PM

Answers

  • As Nosh already said, yes that is the Attribute.

    Regarding the accounts, since this is a completely new MA you need to import and join all objects again, so that it has the state of the current MA.

    Check MV deletion rule also before, so that disconnecting objects from the old MA does not accidentially delete objects from MV.

    Its a little more work but with that you have a completly "fresh" MA.

    /Peter


    Peter Stapf - ExpertCircle GmbH - My blog: JustIDM.wordpress.com

    Wednesday, October 7, 2015 2:37 PM

All replies

  • Recreating the MA would break the rules. You can try to create a new MA and export it, then update current MA with the new one.

    so, lets say your MA is called "AD-MA1"

    1. Create new called "AD-MA2"

    2. Export "AD-MA2"

    3. Run update on "AD-MA1" using export xml of "AD-MA2"

    What you will loose is the run profiles, but those are quickly created.


    Nosh Mernacaj, Identity Management Specialist

    Tuesday, October 6, 2015 4:34 PM
  • Created a new ADMA to the target successfully with the new attributes selected.  Exported and ran update on original ADMA resulting in failure.  See below:

    Begin processing the management agent update information...

                    Management agent file version checking starting...

                    Management agent file version checking successfully completed.

                    Management agent version checking starting...

                    Management agent version checking successfully completed.

                    Merging import configuration from file starting...

                                    Matching the management agent partitions.

                                    Migrating the management agent partitions.

                                    Management agent schema compare starting...

                                    The management agent schema has been changed.

                                    Custom validation starting...

                                    Custom validation successfully completed.

                    Merging import configuration from file completed.

                    Rules validation for management agent 'HFIB1-ADMA' starting...

                                    Validation of the attribute inclusion FAILED.

                                                    The Attribute 'mailNickname' could not be located in the schema.

                                                    The Attribute 'targetAddress' could not be located in the schema.

                    Management agent rules validation FAILED.

    Management agent update processing FAILED.

    Update management agent from file FAILED.

    Tuesday, October 6, 2015 5:18 PM
  • On the current 'HFIB1-ADMA' , can you click the "select attributes" and check the mailNickName and targetAddress please.  Then repeat the task again.

    Nosh Mernacaj, Identity Management Specialist


    Tuesday, October 6, 2015 6:28 PM
  • The original problem still exists after the failed import. Those two attributes (mailNickName and targetAddress)don't exist on the existing ADMA.

    -Stu

    Tuesday, October 6, 2015 6:31 PM
  • Looks like you may have to recreate the MA.


    Nosh Mernacaj, Identity Management Specialist

    Tuesday, October 6, 2015 6:34 PM
  • Hi,

    you can also try to create a new MA, then switch the sync rules in portal to that new MA.
    You must search for the GUID of the MA in portal and set that on the sync rule.

    After doing that and testing you can securely remove the old MA.

    I've done this 2 times and not only in a lab ;-)

    /Peter


    Peter Stapf - ExpertCircle GmbH - My blog: JustIDM.wordpress.com

    Tuesday, October 6, 2015 7:06 PM
  • Peter,

    Is it the value highlighted below that is the GUID for the MA that would be modified?  How would changing the MA affect the outbound synced accounts in the lab?

    Thanks, Stu

    Wednesday, October 7, 2015 11:34 AM
  • That's the one.

    Nosh Mernacaj, Identity Management Specialist

    Wednesday, October 7, 2015 1:19 PM
  • As Nosh already said, yes that is the Attribute.

    Regarding the accounts, since this is a completely new MA you need to import and join all objects again, so that it has the state of the current MA.

    Check MV deletion rule also before, so that disconnecting objects from the old MA does not accidentially delete objects from MV.

    Its a little more work but with that you have a completly "fresh" MA.

    /Peter


    Peter Stapf - ExpertCircle GmbH - My blog: JustIDM.wordpress.com

    Wednesday, October 7, 2015 2:37 PM
  • I created the new ADMA for target 1, and retrieved the GUID by creating a temp sync rule.  I put the new ADMA GUID on the existing \ working rules and it really saved me a bunch of time.

    I am doing a one way sync of users (w password) to the target ADMA.  After the changing of the ADMA I wound up manually deleting my synced users into the target to have them repopulated by the new ADMA on the next sync.

    It's working like a champ!

    Thanks very much, Stu

    Wednesday, October 7, 2015 4:56 PM