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
  • Bump.

    Did this get resolved? I'm having the same issue with a simple CSV MA using a basic provisioning extension.

    Cheers,

    Dave

    Monday, July 21, 2014 1:39 PM
  • Dave,

    Is this an ECMA you are creating or the OOB delimitted text file MA? If it is the latter, why set the DN at all? Just sent the anchor attribute and that shoud be enough.

    Tuesday, July 22, 2014 2:39 AM
  • It's a simple OOB delimited text file MA. I tried setting the anchor, but was having an issue with the provisioning code not seeing the subsequent connector as such and re-provisioning each sync. So then I tried actually setting a DN and hit the issue above.

    Any ideas why setting the my provisioning code isn't seeing the connectors?

    I set the anchor in the MA

    I use the following provisioning code (via an MVRouter)

    void createNewPerson(MVEntry mventry)
      {
        ConnectedMA ma = mventry.ConnectedMAs["Sports Booking"];
        CSEntry csentry = ma.Connectors.StartNewConnector("person");
    
        csentry["Scuba No"].Value = mventry["aruUserID"].Value;
    
        Int32 numConnectors = ma.Connectors.Count;
    
        if (numConnectors == 0)
           {
               csentry.CommitNewConnector();
           }
    
      }
     

    The objects get provisioned to my MA CS, as expected

    But next full sync the MA ignores the connectors and provisions them all over again :(

    Any ideas, have I missed something obvious?

    Cheers,

    Dave

    Tuesday, July 22, 2014 9:08 AM
  • Oh daah! I can see my schoolboy error from here. I'll leave it up to be instructive for others *blush*

    First one to point it out and rub my nose in it wins a prize or something...

    Herp derp.

    Dave

    Tuesday, July 22, 2014 1:36 PM
  • You actually have to perform export on the target MA for these objects to be commited, in this case a file. If you never run export and run sync again, then the objects being de-constructed and re-constructed is expected.

    Wednesday, July 23, 2014 1:23 AM
  • The objects are being re-provisioned even after an export, Glenn. If I run a confirming import from the file, then all is well, but the code doesn't seem them as a connector when they are exported-awaiting-confirmation. The ma.connector.count shows 0, but if you look closer into the m_connectors collection you can see the connector then.
    Wednesday, July 23, 2014 8:51 AM