AD Group sync, AD MA export throws cd-existing-object error
-
Wednesday, March 06, 2013 9:05 PM
I created a group, GROUP_A in AD, assigned two users as members, and ran a sync to FIM. I saw the group with members sync correctly into FIM. Then, I created a new user, added the user to GROUP_A, then performed the provisioning steps.
On the AD MA export step. I got a Sync step I got a cd-existing-object error stating 'The specified group already exists.'
Oddly enough the provisioning step still seems to have worked, even with the error msg. Going to retest that, but any thoughts as to why I might be getting that error msg?
- Edited by Osho27 Wednesday, March 06, 2013 9:06 PM
All Replies
-
Thursday, March 07, 2013 2:30 AM
if your provisioning uses classic provisioning (ie, provisioning rules extensions written in .NET), I'd say that you need to include a check to see if the object already exists in the Target MA. Ie, check mventry.ConnectedMAs["ADMAName"].Connectors.Count is 0.
If you're using declarative provisioning (ie, provisioning configured as a sync rule in the FIM Portal), then the above probably doesn't make much sense to you.
In this case, things I would check:
- Confirm that you've done a delta import/delta sync after exporting the new group to AD
- Search the Requests to see what happens when you add a user to the group. Are there new ERE's created?
- See what happens when you add another user.
- Ross Currie
FIMSpecialist.com | MCTS: FIM 2010 | Now Offering ECMA1->ECMA2 Upgrade Services
-
Thursday, March 07, 2013 5:28 AM
When you get a CD-error stating that specific object already exists for AD MA, it typically means there is another object in AD that has the same sAMAccountName value as the object you are attempting to provision. This often happens when there is object in AD out of scope that represents somebody who we are attempting to provision.
It could also just be similar name(i.e. JSmith). This applies to groups as well as users as security groups are security principals and therefore have sAMAccountName values.
-
Thursday, March 07, 2013 9:47 AM
As far as i Can understand
When you create a Group in AD and import it to FIM, it is created in FIM.
Now further more, you MUST be having an MPR that says that when a new group is created in FIM, create it in AD as well (through the outbound Sync Rule, by selecting Create Resource in the External System), that's what is happening. FIM is trying to recreate the Group in AD.
I would suggest you check the Relationship tab in the Sync Rule and verify that the Relationship Criteria is correct and values exist in both the systems (FIM and AD) for those attributes defined in the criteria.
Regards Furqan Asghar
-
Thursday, March 07, 2013 1:23 PM
Thanks...
just to be clear, the use case here is that FIM can import all existing groups and members within an OU, and can from that point on FIM will be used to manage those users and groups. So, first step is to sync AD to FIM, hence I have a Synchronization Rule for AD Groups with:
Criteria --> accountName = sAMAccountName
Create Resource in FIM -checked-
Create Resource in Ext System - checked -
Enable Deprovisioning -checked-
Not that for Create Resource In Fim or External System it states in small print: If no resource in the system satisfies the Relationship Criteria, a new resource will be created. I better double check that my attributes for accountname are mapping and matching like I expect they should.
either way, the use case I present is a valid one, right?
-
Thursday, March 07, 2013 2:23 PM
So as i Understand, import of Groups and Members is ONE time only? if that is the case i would suggest to uncheck the 'Create resource in External System', until all the Groups are in FIM and then Uncheck the 'Create Resource in FIM' and Check the 'Create Resource in External System'.
There is no such term as an invalid use-case :), use-cases are mapped to customer requirements which can lead to infinite scenarios.
On the other hand, if you have two way sync scenario (AD <=> FIM), it is a hassle but doable. You'll have to play with attribute precedence a lot and in most cases make them equal-precedence and that would lead you to sticking to specific run profile order.
Regards Furqan Asghar

