When I'm trying to run a full/delta sync on the FIMMA I'm getting the following error: Microsoft.MetadirectoryServices.ProvisioningBySyncRuleException: DN "+("CN=",displayName,",OU=Users,OU=FABRIKAM Users,DC=fabrikam,DC=com")" is not valid. The distinguished name is configured in my sync rule as a constant string as above and is set for initial flow only (which this is). Sync rule provisioning is enabled. Am I missing something? Is the syntax correct for the dn attribute? (I have changed some of the text from my domain information but the format is the same).

hello peter, PLease verify the OU structure , for example, if your OU "Users" Contain OU "FABRIKAM Users" then the systax must be Destination Source dn +("CN=",displayName,",OU=FABRIKAM Users,OU=Users,DC=fabrikam,DC=com") please check and let me know if this solves your issue. Cheers, Mohit Goyal

I copied and pasted from the dn attribute of the OU I am using so I'm pretty sure it's correct.

Does your displayName have a value in the metaverse? Cheers, MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

Are you referring to my sync rule? Yes, it does. The user isn't in the metaverse - it is failing when trying to run a synchronization on the FIMMA so I guess it is only in the Connector Space as the export from FIM had no errors.

"ProvisioningBySyncRuleException" means there is a problem applying your synchronization rule to an object in the metaverse. You should check, which object it is and whether the object has a populated displayName. You can find more details on this error here. Cheers, MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

OK that makes sense but isn't the error referring to the distinguished name, a component being the displayName?

That's true - if your displayName doesn't have a value, the distinguished name can't have a valid format. A missing displayName is just an option (it is the most common error) - there could be something else wrong. This is why you should identify one of the affected object. This will help you to figure out what the problem is. Cheers, Markus Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation

I can see that the object - the test user, has a DisplayName value in the Connector Space. Where will the DN get created? When it is projected into the Metaverse or when it's in the CS?

To calculate the DN, the value from the metaverse is used. Is displayName available on the object in the metaverse? Cheers, Markus Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation

Ok now I'm confused! The object isn't in the metaverse yet as it's failing to project when running the full synchronization run profile.

Synchronization is implemented as one transaction per object. If there is an error during the transaction, it is rolled back. Switch provisioning off, run a sync an check the attribute values in the metaverse. Cheers, Markus Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation

I've done that and it's in the metaverse and it has a displayname. When I look in the Metaverse Search columns there's no option to view the DN, is that right? Surely I should be see that column even if it's not populated? Just to check as well in case this is causing the problem, the attribute flows in my FIMMA are set up like this for the dn: Data Source Attribute - Metaverse Attribute - Type dn <-- (nothing) - sync-rule-mapping - expression <dn> --> csObjectID - Direct As instructed in the guide.

You don't track the DN attribute in the metaverse. The attribute is calculated during provisioning and set in the AD connector space. So, yes, what you see is correct. It would help to see your synchronization rule. You can post your configuration by using the FIM Object Visualizer. Also, are your sure, you AD has this sturucture: "OU=Users,OU=FABRIKAM Users,DC=fabrikam,DC=com"? Cheers, Markus Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation

I pulled the structure of the OU directly from AD so I'm sure it's right. I've just gotten round to looking at the FIM Object Visualizer: the expression I have for the dn is: Constant: +("CN=",displayName,",OU=Users,OU=FABRIKAM Users,DC=fabrikam,DC=com") Whereas the example is: +("CN=",displayName,",OU=FIMObjects,DC=fabrikam,DC=com") I'm guessing I shouldn't have set it as a constant? What should it be?

Good to have the Object Visualizer :o) You have mentioned this in your initial post and nobody has notices it... +("CN=",displayName,",OU=FIMObjects,DC=fabrikam,DC=com") as not a string constant - it is a function. "+" means that you have to concatenate the string "CN=" with the attribute displayName and the string "OU=FIMObjects,DC=fabrikam,DC=com". Cheers, MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

Yep, that was it! It's now projecting into the Metaverse but not projecting into the AD DS Connector Space. I guess I'll open another thread on that once I've found the error.

I'd disabled synchronization rule provisioning and forgotten to re-enable it so ignore the above. I'm now getting: Microsoft.MetadirectoryServices.ProvisioningBySyncRuleException: The partition filter criteria for management agent "FABRIKAM ADMA" do not include an object with DN "CN=Test User"OU=OffUsers\,OU=FABRIKAM Users\,DC=fabrikam\,DC=com"" and object classes user. When trying to run a synchronization.

The error is related to you current container selection on your ADMA: If I read this correctly, there is a comma in your DN missing. In your DN concatenation formula, the container information must start with a comma: ",OU=FIMObjects,DC=fabrikam,DC=com" Cheers, MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

You need to make sure that what you have in your DN matches the container selection in your ADMA. Have you already done a full import on your ADMA? Is OU=OffUsers,OU=FABRIKAM Users,DC=fabrikam,DC=com in the connector space of your ADMA? Cheers, Markus Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation

That was it, that and the extra set of quotation marks! Thanks very much, it's going through now, just need to wait for some permissions to replicate across our domain and I can export to AD!

Awesome! If you can think of things ("lessons learned"), that would made made your life easier, please post them. If we should add something we should add to the docs, let us know. Cheers, MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation