none
Added new Outbound attribute flow for userPrincipalName to one target ADMA and getting error on source ADMA RRS feed

  • Question

  • {MIM NEWBIE}

    I have a working multi-forest declarative DirSync solution driven from one source forest to over 60+ target forests.  In general, I synchronize source forest accounts to target forests with passwords for Single Sign On.

    I needed to add the creation and setting of userPrincipalName to one target forest.   Being a newbie,  I initially just added an Outbound Attribute Flow to my existing “EDGECLOUD User Outbound Sync Rule”

    accountName+”@edgetgcloud.com”=>userPrincipalName

    On the initial run, it was successful and create a new UPN for each existing target account, which had been previously provisioned.   Then on testing a new user account to synchronize I started seeing failures to provision and started investigating.

    According to FIM docs I needed to add the userPrincipalName attribute to the target ADMA and manually create it in the Metaverse and add to the MIMMA. I created the attribute as a non-indexed string.

    Why am I seeing the below Error on the Source ADMA: Microsoft.MetadirectoryServices.ProvisioningBySyncRuleException: The DN must be set before calling CSEntry.CommitNewConnector

    Thanks, Stu

    Monday, July 10, 2017 2:04 PM

Answers

  • Yesterday I opened a support case with MS and was assisted by Glenn Zuckerman. Within a few minutes he found the root cause.

    About 3 weeks prior I had modified my Outbound Sync Rule to enable a CustomExpression with nested IFF's to create the DN to  allow a user object to move between target OU's.   I had removed the Initial Run Only flag.  

    The end result was that I need two identical CustomExpression with one set for Initial Run Only.

    The assistance was well worth the $$.

    Thanks for all your assistance.

    -Stu

    Wednesday, July 12, 2017 11:24 AM

All replies

  • Ok, for users where you can see the issue, do you have:

    accountName in Metaverse?

    DN in pending export?

    Error says that you have not calculated/provided DN for those new accounts - do you have a flow of DN in Sync Rule as well or done by code?


    If you found my post helpful, please give it a Helpful vote. If it answered your question, remember to mark it as an Answer.

    Monday, July 10, 2017 3:00 PM
  • The accountName attribute is already in the Metaverse.

    The Source ADMA (EDGETG-ADMA) does not currently have the userPrincipalName enabled in "attributes" and only has an INBOUND Sync Rule which does not have any inbound attribute flows for userPrincipalName or DN.

    I only need to generate the userPrincipalName on one OUTBOUND Sync rule to the EDGECLOUD forest.

    I only calculate DN's on my OUTBOUND Sync rule of which I have 60+ ADMAs and User Sync rules.

    But, the DN error shows up on my EDGETG-ADMA which only has a INBOUND Sync rule as I only read from the SOURCE forest.

    Monday, July 10, 2017 3:35 PM
  • Seems your issue is with DN, not UPN. It also seems that you have not imported the DN from this AD, or you have but the OUs selected in the AD MA, do not contain the OU structure on your DN.

    1- Make sure the OUs are selected,

    2- Run a FULL Import and a FULL Sync on AD MA (Target)

    3- Try the provisioning again.


    Nosh Mernacaj, Identity Management Specialist

    Monday, July 10, 2017 5:20 PM
  • Seems your issue is with DN, not UPN. It also seems that you have not imported the DN from this AD, or you have but the OUs selected in the AD MA, do not contain the OU structure on your DN.

    1- Make sure the OUs are selected,

    2- Run a FULL Import and a FULL Sync on AD MA (Target)

    3- Try the provisioning again.


    Nosh Mernacaj, Identity Management Specialist

    This doesn't really match the error message. You'd have a different exception if you were missing a parent object.

    Stuart, can you paste the sync rule that sets the DN?


    Thanks,
    Brian

    Consulting | Blog | AD Book

    Monday, July 10, 2017 5:42 PM
    Moderator
  • That is true.  I have not imported the DN from my EDGETG-ADMA (source) ADMA as my current solution has not required it.  The Sync Rule is INBOUND only and does not write back to the source AD. The ADMA is restricted to reading from one base path "OU=Edge Users,DC=Edgetg,DC=com".  Why would it have a provisioning event against it? 

    The 60+ Target "User Sync Rules" do create provisioned user accounts in the target forests using a similar path with the OUTBOUND Attribute Flow having a "Initial Flow Only" string concatenation formula that currently works and successfully creates user accounts.

    This issue appeared after I tried adding the userPrincipalName to my Outbound flow to one specific forest.  I did have errors in the EDGETG-MIMMA that are gone after addition the custom attribute to the Metaverse.

    Is the problem between the EDGETG-ADMA and The EDGETG-MIMMA?

    Rerunning the full sync again, but I don't expect it to resolve anything.

    -Stu

    Monday, July 10, 2017 5:53 PM
  • On the EDGETG-MIMMA full sync results for one failing user:

    Monday, July 10, 2017 6:04 PM
  • I did find this off the above "CS to MV to CS sync error".

    https://social.technet.microsoft.com/Forums/en-US/1cda44a1-f4e3-400f-9896-9d015ca2f1e7/unexpectederror-cs-to-mv-to-cs-synchronization-failed-0x80040e14?forum=identitylifecyclemanager

    I did create my userPrincipalName attribute as a non-indexed String?

    Monday, July 10, 2017 6:07 PM
  • indexing should not matter.

    Based on one of your screen shots, the provisioniong is going to OU=Edge Users,DC=Edgetg,DC=com, thus you need this imported into MV.


    Nosh Mernacaj, Identity Management Specialist

    • Proposed as answer by Nosh Mernacaj Monday, July 10, 2017 6:50 PM
    Monday, July 10, 2017 6:48 PM
  • indexing should not matter.

    Based on one of your screen shots, the provisioniong is going to OU=Edge Users,DC=Edgetg,DC=com, thus you need this imported into MV.


    Nosh Mernacaj, Identity Management Specialist

    imported or calculated as "DN=[AccountName],OU=..." or something like that - then it will be just calculated by Sync Rule.

    If you found my post helpful, please give it a Helpful vote. If it answered your question, remember to mark it as an Answer.

    Monday, July 10, 2017 7:10 PM
  • I am really confused.   According to the above, this error on PROVSIONING is against my SOURCE ADMA which only has INBOUND workflows.  None of my sync rules write anything back to OU=Edge Users,DC=Edgetg,DC=com.   FIM only reads from the SOURCE.   

    This mess started when I tried to add the userPrincipalName to a OUTBOUND attribute flow to a single ADMA.

    Tuesday, July 11, 2017 2:24 PM
  • You need to check the Provisioning Settings, perhaps you have mistakenly selected the wrong MA on the dropdown list. That is definitely what is going on.


    Nosh Mernacaj, Identity Management Specialist

    Tuesday, July 11, 2017 6:36 PM
  • Yesterday I opened a support case with MS and was assisted by Glenn Zuckerman. Within a few minutes he found the root cause.

    About 3 weeks prior I had modified my Outbound Sync Rule to enable a CustomExpression with nested IFF's to create the DN to  allow a user object to move between target OU's.   I had removed the Initial Run Only flag.  

    The end result was that I need two identical CustomExpression with one set for Initial Run Only.

    The assistance was well worth the $$.

    Thanks for all your assistance.

    -Stu

    Wednesday, July 12, 2017 11:24 AM
  • Stu,

    That is precisely what I have told you.  "Initial Flow Only" means provision. 

    Glad it worked out for you.


    Nosh Mernacaj, Identity Management Specialist

    Wednesday, July 12, 2017 1:28 PM
  • Appreciate the guidance.  I just didn't understand the real process and terminology.  It makes it hard to ask and answer.

    Best, Stu

    Wednesday, July 12, 2017 2:09 PM