none
sync-rule-provisioning-failed: The DN cannot be set because it will be automatically computed when CSEntry.CommitNewConnector is called.

    Question

  • Hi,

    I'm trying to write a very basic ECMA 2.2 connector which creates a home folder for a user based on his surname and accountname.

    For instance, a user whose last name is smith and accountname is johnsmith should get a folder created in \\servername\homefolders\smith\johnsmith

    At the moment, I'm not interested in doing any imports, so this MA will just create the home folder. My sync rules are simple as follows (all outbound):

    accountName (FIM) > accountName (homefolder MA)

    "\\servername\homefolders\smith\" + accountname (FIM) > homeFolder (homefolder MA) 

    accountName (FIM) > dn (homefolder MA)

    Note: in the second flow the flow is a concatenated string, and the dn flow is marked as initial flow only.

    I have created the relevant sets/wf/mpr in the portal. The anchor attribute configuired in the MA is the accountName

    Now, when I create a user (Say John Smith with accountname johnsmith), I get the user into my set and the sync rule ERE is generated. However, when I do an import+sync on the FIM MA to bring this user from the portal into the MV, I get this error (as part of sync-rule-provisioning-failed)

    Microsoft.MetadirectoryServices.ProvisioningBySyncRuleException: The DN cannot be set because it will be automatically computed when CSEntry.CommitNewConnector is called.

    I'm getting this error on the Sync stage

    I know I need to pass something to the dn so I can't remove that, but I can;t find any info on the error. Any ideas?

    Thanks




    • Edited by kmittal82 Monday, November 04, 2013 8:04 AM
    Sunday, November 03, 2013 7:06 PM

All replies

  • http://msdn.microsoft.com/en-us/library/microsoft.metadirectoryservices.csentry.commitnewconnector(v=vs.100).aspx

    Do you get this same behavior if you try classic provisioning code, or only using Declarative Sync Rules?

    It sounds like your ECMA 2.2 is behaving like the XML type shown in the table below:

    Management agent type Distinguished name handling notes
    Database

    • The DN property is writable between the calls to StartNewConnector(String) andCommitNewConnector, and the process may set it.
    • If the DN property is set, then the DN is considered a temporary DN.
    • If the DN property is not set, then a DN is constructed from anchor attributes. All attributes that contribute to the anchor must have been added to the CSEntry before the call to CommitNewConnector. If any of those attributes were not set, anAttributeNotPresentException exception is thrown. The values of the anchor attributes are combined to create the DN for the object. For details, see EscapeDNComponent.
    • After CommitNewConnector is called, the DN property is read-only.
    XML

    • The DN property on the new connector is marked as read-only and thus cannot be set by your process.
    • The DN is constructed from the anchor attributes, and that behavior is exactly the same as the database case.
    • The DN property remains read-only after the call to CommitNewConnector.
    All other types

    • The DN property on the new connector is writable and must be set before the call toCommitNewConnector. If the DN property has not been set, CommitNewConnectorthrows an InvalidOperationException exception.
    • The DN property can be modified after the call to CommitNewConnector, in which case it is treated as a rename on the object.


    David Lundell, Get your copy of FIM Best Practices Volume 1 http://blog.ilmbestpractices.com/2010/08/book-is-here-fim-best-practices-volume.html

    Tuesday, January 07, 2014 5:53 PM