Hey all, I've implemented a new extensible MA that exports data to a SQL database. We're using an extensible MA as the data is relational and beyond the abilities of the stock SQL MA. Export is working fine, so when you create an object in the FIM Portal, it provisions to the database as expected, but when importing, the DN for the new object comes into FIM as "CN=". I think I've got the DN and/or the anchor configuration wrong somehow. The MA is configured to use an attribute called DBID as the anchor, which is a value generated by the database. This means for the export sync rule, we use csObjectId=>DN on initial flow only. My expectation is that for portal created entities, the csObjectId is the DN to start with, and then when the database entry is created, the DN gets updated with the DBID attribute value, and for data created in the database, the DN is the DBID attribute value from the start. Is this reasonable? Is there a better way to do this? I've gone over the MS documentation and guides for inbound provisioning but don't see anything amiss. Can anyone help? Outbound sync rule: Interestingly, if I directly map csObjectID to DN, I get an error in the sync manager. I forget what it was now, but I know that prepending it with CN= made it work. Inbound sync rule: oops, can't show it as there's a two image max per post restriction!

Inbound sync rule:

Hi Amethi, I have a few quick questions that I need some info on to help me understand the structure of the XMA. When you bring values in from the MA, what are you writing in to the GenerateImportFile Function. Are you merely passing the values as presented in the SQL call. How are you building yours datastructure, are you interrogating the View/Table/SP schema for the header name and type, or are building a fixed headers with a pure string type. What join criteria have you specified in the sync rule. What type (string, etc) are you writing the Anchor out and what type are you bringing it in as Is the anchor you are passing also the primary key of the database. What is preventing you from specifying CN=+ CSObjectID => DN One more point, if the object is removed and re-added, the CSObjectID will change, hence you can get duplicates using this method for ensuring uniqueness in your data. Kind regards Jacques Visit My Blog: http://theidentityguy.blogspot.com/

Hi Jssting, Thanks for the reply... We're producing a DSML document. Yes We call stored procedures on a database and convert the output to DSML. The join attribute is a correlation id we have within the organisaiton, though I'm thinking now I should try and make it the anchor attribute as this makes more sense for this system. The anchor is a string, i looks like "MPRegion-1". The end part of the anchor is the primary key, i.e. the number. Our stored procedures return it in the textual format above to make it unique across the db. Nothing, we have this mapping for our outbound sync rule

This is normal. XMAs need LDAP style DNs (even for a non-LDAP data source). This is fixed in the new ECMA 2.0 framework that is in the pipeline.My Book - Active Directory, 4th Edition My Blog - www.briandesmond.com

Hi Amehi, Based on the information I would guess that the primary key is a autogenerating number. This leaves you with a few options: You can pass the the value with a CN= as you have been doing, but not to actually write the anchor out when you export. When you then import; the connector will come in with a new anchor as created by the combination of "MRPegion-" and the key value as and long as your join criteria is correct will join up correctly with the existing MVEntry for the record when you run a sync and FIM will delete the old connector You can create a seperate class in the MV where you can store all used Achor ID's and query this for the highest value used in the export, and generate a new "anchor" that would match the outgoing values (very risky as users don't export in the same order they are processed by the synchronization step). You can also look at using a value that is more conventional as an anchor. Here comes the bad news ... when FIM exports to an extensible MA, it usually enforces the CN= prefix for anchor values (as is the case with the Galsync2010 MA which is an XMA built for synchronizing ad users to Hosted exchange mailboxes which incidentally follows option 1). This should have little impact if you implement option1 , but if you want to look at other options, you could potentially prefix the CN= value in code for imports. Kind regards Jacques Swanepoel Visit My Blog: http://theidentityguy.blogspot.com/

Thanks Jacques for your explanation. What I'm struggling with is understanding how the DN is constructed for an extensible management agent on import. I don't see a way to specify this in the management agent properties and can find no documentation to explain it. Entities imported with a DN of "CN=" is not acceptable as it doesn't identify the entity and I'm sure that once we add more than one record to the database, we'll end up with two "CN=" dn's and that's going to cause no end of trouble. Do we have to set the DN in the DSML file we generate on import, or in a rules extension? Stumped here.

This is all fixed now. We realised that the DN was set by our management agent when genering the DSML document for import. We set the right DN and all is good now. Thanks all!

Hi Amethi, I am happy you were able to resolve the issue and that we could be of assistance. Kind regards JacquesVisit My Blog: http://theidentityguy.blogspot.com/