I have some criteria-based security group that were created in FIM. When viewed in FIM the group has all the members it should have, based on the criteria. However when I view the members list for the group in AD, there are no members in the group. The connectors look fine. There is a FIM connector and an AD connector. I don't see any errors related to this problem. Does anyone know what could cause this and how I should go about troubleshooting this problem?

Bjorn, Do you fill in the members attribute of the group in the AD Groups synchronization rule? On the other hand you must check if you may update multivalued attributes, in the AD Groups Management Policy Rule. Greets, Stefan

Please use this as guidline.The document describes your scenario.Cheers,MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

Hi StefanYes the members attribute flows to AD as per the Synchronization Rule. In the MPR however only the option to Create resource is checked. I will try checking the Add a value to a multivalued attribute an see if that works. I'll post back thank you.

Markus, this FIM system is up and running and was deployed by Microsoft. The provisioning of groups works fine if it is NOT criteria based groups.

Stefan,I tryed checking the option to allow updating multivalue attributes in the MPR, but that did not work. I think you might be on the right track though. Creating manual security groups works fine, i.e. they get provisiond to AD. But criteria based groups do not. I also tryed creating a manual security group in FIM and adding multiple users to the group, but that group did not get provisiond to AD either. So the problem seems to be that security groups that are created in FIM with multiple members do not get provisiond to AD. Is there anything els that might play a part in this, other than allowing adding value to a multivalued attribute in the MPR?

Bjorn, the document describes how to create criteria-based groups in FIM and provision them to AD. Ultimately, there seems to be an issue in your environment with the member attribute flow of a group since you can get the group object from FIM to AD. In FIM, the group has the right members but not in AD. Member is a reference attribute and FIM enforces referential integrity – like AD does. This means the reference attribute member has to point to existing objects. The first thing, you can check is whether the objects that are members of your group in FIM do exist in AD. If they don’t exist in AD, member can’t point to anything. In other words, to synchronize the member attribute, you also need to synchronize the members. Are you also synchronizing the users and do they exists in AD? If the members do exist, you need to check at what point the values the member attribute points to is blocked. What you can check is whether the member attribute points to the right objects in all segments of a synchronization phase. Here is how this looks like: If the group looks good in the metaverse, do you have an outbound synchronization rule to AD that flows the member attribute? If yes, does the member attribute flow from FIM has the right precedence? If that doesn’t help you, you should post your configuration. You can find more information about this here. Cheers, MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

I tryed checking the option to allow updating multivalue attributes in the MPR, but that did not work. I think you might be on the right track though. Nope - the sole purpose of the MPR is to bring a resource - in this case the group - into the scope of a synchronization rule.Attribute updates have nothing to do with this.Please take a look at the link I have included above.Beginning with Update 3, synchronization rules are not handled by request based MPRs anymore.Cheers,MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

Thank you Markus for your explenations.All the users in FIM are connected to AD users. Looking at the Metavers object properties of the group, every thing looks ok. There is an ERL and there are two connectors, one for FIM and on for AD. Someone pointed out to me that an error I thougt was not connected to my problem might acctually be the reason for the problem. There is an Event error regarding a user object.I didn't think these problems could be related because user objects and group objects with no members get provisiond to AD. Just seems that groups with multiple members ar NOT provisiond. This is the error:Log Name: ApplicationSource: FIMSynchronizationServiceDate: 12.2.2010 09:43:50Event ID: 6301Task Category: ServerLevel: ErrorKeywords: ClassicUser: N/AComputer: Description:The server encountered an unexpected error in the synchronization engine: "ERR: MMS(2288): hobl.cpp(2939): CHobl::AddValue: object has DN (CN=[user] - VI_RDH,OU=Users,OU=[company],DC=domain,DC=net), trying to add with different anchor BAIL: MMS(2288): hobl.cpp(2940): 0x80004005 (Unspecified error) BAIL: MMS(2288): hobl.cpp(3878): 0x80004005 (Unspecified error) BAIL: MMS(2288): tripleholo.cpp(7881): 0x80004005 (Unspecified error) BAIL: MMS(2288): tripleholo.cpp(7363): 0x80004005 (Unspecified error) BAIL: MMS(2288): tower.cpp(6077): 0x80004005 (Unspecified error) BAIL: MMS(2288): csobj.cpp(4042): 0x80004005 (Unspecified error) BAIL: MMS(2288): csobj.cpp(1469): 0x80004005 (Unspecified error) BAIL: MMS(2288): nscsimp.cpp(5014): 0x80004005 (Unspecified error) BAIL: MMS(2288): mvobj.cpp(1872): 0x80004005 (Unspecified error) BAIL: MMS(2288): synccoreimp.cpp(11103): 0x80004005 (Unspecified error) BAIL: MMS(2288): synccoreimp.cpp(10997): 0x80004005 (Unspecified error) BAIL: MMS(2288): synccoreimp.cpp(11288): 0x80004005 (Unspecified error) BAIL: MMS(2288): synccoreimp.cpp(3098): 0x80004005 (Unspecified error) BAIL: MMS(2288): synccoreimp.cpp(2432): 0x80004005 (Unspecified error)ERR: MMS(2288): synccoreimp.cpp(6298): 0x80004005 - MV to CS synchronization failed 0x80004005: [{65CD1DB9-8983-41AA-96A0-6A06EA35DA0A}]BAIL: MMS(2288): synccoreimp.cpp(6301): 0x80004005 (Unspecified error)ERR: MMS(2288): syncmonitor.cpp(2512): SE: Rollback SQL transaction for: 0x80004005MMS(2288): SE: CS image beginMMS(2288): SE: CS image endForefront Identity Manager 4.0.2570.0"

Someone pointed out to me that an error I thougt was not connected to my problem might acctually be the reason for the problem. There is an Event error regarding a user object.I didn't think these problems could be related because user objects and group objects with no members get provisiond to AD. Just seems that groups with multiple members ar NOT provisiond. Your "someone" was absolutley right - this is the reason.However, it has nothing to do with provisioining. Provisioning already happned since you have the connector to AD. The server encountered an unexpected error in the synchronization engine: "ERR: MMS(2288): hobl.cpp(2939): CHobl::AddValue: object has DN (CN=[user] - VI_RDH,OU=Users,OU=[company],DC=domain,DC=net), trying to add with different anchor This is a bad one that could be totally unrelated to FIM since you have a crash in the tower.Your synchronization rule bails when trying to add a member.You should already see exceptions reported in the synchronization statistics when you run synchronization.The only thing you can try is to delete the content of your connector spaces and to re-initialize your environment: ADMA - Full Import ADMA - Full Synchronization FIMMA - Full Import ADMA - Full Synchronization ADMA - Export ADMA - Delta Import If you can't get rid of the error that way, you need contact PSS since you would have a bigger problem that can't be solved here.Cheers,Markus Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation

We will raise a support call to Microsoft because of this. Still I realy want to understand this better :) Just to be clear, this error event is only related to this user and the user is not a member of any of the security groups that I tryed to creat, and that failed. So how is this error responsible for only one type of security groups not being synchronized to AD? As I stated before I can create users and security groups (with no members in them) and these objects show up in AD?

Makes sense and is a good approach!However, please do also understand that a good answer would actually require access to your system to take a look at it.I could give you now a lot of instructions for I what I would do if I would sit in front of your system; however, there are just so much you can do on a forum.While your approach is basically good, it is possible that it doesn't take us anywhere.You have a tower crash.On the outbound side, when the sync engine tries to flow out the member attribute, sync bails.The operation is an AddValue - an attempt to update member.What "trying to add with different anchor" means, is something, someone who knows the related code can tell you since this is pretty deep.I hope this makes sense.At least, I haven't seen this yet and I wonder how the nachor comes into the game in this scenario since the DN is not the anchor in case of AD.What I'm trying to get at is that - unless someone hda the "plesasure" to run into exact the same error, you will be pretty much out of luck.your error seems to me on a level that requires PSS involvement.Cheers,MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

The main problem we were having was that a Security Group in AD was deleted and in stead of just deleting the object from FIM (or at least the connector), FIM kept the connection to the AD object so it was connecting to an object in Deleted Objects OU in AD. Stange behaviour and apparently not very common. Even though I found the AD object using ldp.exe it was decided not to delete the object from Deleted Objects OU but delete the content of the connector space in stead.So the fix was to delete every thing from AD connector space and import every thing again. If you do this make sure you have a join rule in the AD MA for Group objects. We don't as we do not import groups from AD to the connector space.I would have liked to delete the object from Deleted Objects OU, just to see if it would have worked, but any way things are back to normal again.