I'm a FIM newbie. I've been working with a consultant to get FIM working on our campus. The consultant is now gone. We are trying to populate AD with groups and members from data in our ERP system. The groups and members have been imported into the Metaverse. We have an outbound sync rule defined for AD which flows members from the MV to members in AD. When I run the AD export the groups are created in AD but the members of the groups are not updated. No errors are reported. Any ideas what I might be doing wrong? Thanks.

Can you give us some more information? If you look at the group object in the Metaverse and look in the members attribute, do you see the list of users that should be members of the group? If you search the connector space for the group in question there should be a pending export tab for that group. If you look on the pending export tab for the members attribute, do you see the same list of members being exported to Active directory? We need to determine if this is a problem importing the members from ERP, exporting them to the AD connector space, or exporting them to AD. -jeremy

Although Jeremy is completely right and you do need to follow his advice, I would like to add one more issue to look at. I ran into similar issue in the past where group get created but group members are not updated in Active Directory. After some investigation, I found the issue which was related to Attribute Precedence. When you bring attributes from multiple systems you can define attribute precedence to determine attribute flow. If your member attribute precedence is not set correctly, such attribute may not get updated correctly. Look into the MV, highlight the member attribute under groups, and then check precedence. To allow attribute flow, your active Directory connector must have lower or equal precedence your ERP MA. In FIM they introduce something called equal precedence, for fast validation set your member attribute precedence to equal precedence then change group membership in your ERP to validate flow. Hope that help Issam Andoni http://www.zevainc.com

The members show in the MV and in the CS. Nothing shows in the Pending Export when I do a CS search. Jerry

I checked the Attribute Precedence and Equal Precedence is already set. The FIM MA is set at a higher precedence than the ERP MA, but that should not matter if Equal Precedence is set, right? Thanks Jerry

When you say the members show in the CS - which CS do you mean? The CS for ERP or the CS for AD? Let's try this: -Do a full import for AD MA -Do a full sync for ERP MA Search AD connector space for the group Are the members present in the group? Is there a pending export tab? Are the members present on the pending export tab? Another thing you can try, is to remove the outbound sync rule and create a direct attribute flow in the GUI for the Sync Engine to flow mv:group.members to cs:group.members Another good tool is to run a preview on the object in the Sync engine. Search the ERP MA for the object, open the object and choose preview, and then do a full synchronization preview. In the preview window there will be an inbound attribute flow section and also a connector updates section. You can use this to view the flow of the member attribute inbound and outbound. The status field is particularly helpful here. -Jeremy

The members show in the CS of the ERP not AD. I ran the AD full import then ERP full sync. The group members do not show in the AD CS. They do show in MV Object Properties. There is no Pending Exports tab. The groups do not show in the Pending Exports search in the AD MA. I ran the preview on the group object in the ERP MA. I did a full sync preview. The status of the attributes in the ERP Inbound Flow all say Applied. When I look under Connector Updates > Export Attribute Flow > Outbound Sync Rules > AD Outbound-Group the status = Skipped: Flow Null Denied for the MV member attribute. The other attributes status = Applied. What does Skipped: Flow Null Denied mean? Thanks, Jerry

Please make sure that you have the architecture outlined under "Extending Your Group Synchronization Logic" in "How do I Provision Groups to Active Directory Domain Services" in place. Member is a reference attribute and FIM enforces referential integrity. This means, to keep the member reference in tact, you need to also synchronize the members to AD: Given your description, my hunch is that you don't have the group members in the AD CS. This might also explain the error you see ("null flow denied"). The calculated value for the AD CS member attribute is in your case null - no members. You need to enable an MA to flow null values on the outbound side since this is in most cases - like in your case - an undesired value. Cheers, Markus Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation

I made the change to the member attribute of the AD Outbound Group sync rule and checked the "Allow null value to flow to destination" checkbox. I then saved the change and ran a FIMma Full Import and Full Sync. BTW, the Flow Scope = user, group. I can't find any doc to explain how to set this. This is how our consultant set it. I then ran thru a complete cycle (Note: our groups and members come from our ERP not from the FIM portal). I did an ERP Full Import and Full Sync. Then a FIMma Export, Full Import and Full Sync. Then an ADma Export and Delta Import. Then a FIMma Export and Delta Import. I no longer get the status = Skipped: Flow Null Denied when doing a Preview under Connector Updates > Export Attribute Flow > Outbound Sync Rules > AD Outbound-Group. It now says "Applied". However, I still do not see members in th AD CS. They do exist in the ERP CS, MV and FIM CS. Any other suggestions on what I am missing or doing wrong? Thanks, Jerry

As Markus explained, your AD management agent connector space must contain all of the users who need to be in the group and those users must be joined to the corresponding users in the metaverse. If you search the metaverse for a group and then open that group object and then expand the member attribute you should obtain a list of the people in that group. If you select one of the members, you will get the metaverse object that corresponds to the member (a person). Once you have the metaverse object for the person, open up the details for that person and choose the connectors tab. Do you see a connector to the AD MA? If not, you need to join your users in the AD MA to the person objects in the metaverse. This can be done by creating a join rule in the synchronization engine or by creating a new synchronization rule that creates a relationshup between person objects in the metaverse and user objects in AD. -Jeremy

When I look at the connectors tab for person that is a member of a group in the MV I do not see the AD MA. We do have AD Outbound Sync Rules defined in the FIM portal to flow MV person attributes to AD user attributes. Is there some other join rule that needs to be created besides this? I am not familiar with creating such. If so is there some place in the TechNet docs that describes this? Thanks, Jerry

How Do I Guides Cheers, MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

I have read thru the How To Guides but they don't seem to provide any detail on join rules. They describe setting up sync rules which we have done. Jerry

"Joins" are included in synchronization rules. In a synchronization rule, a "join" is called "Relationship Criteria". "When I look at the connectors tab for person that is a member of a group in the MV I do not see the AD MA." "We have an outbound sync rule defined for AD which flows members from the MV to members in AD. When I run the AD export the groups are created in AD but the members of the groups are not updated. " According to your description, you can get group objects from the metaverse to AD; however, you can't get users from the metaverse to AD. What you need is an outbound synchronization rule that brings users from the metaverse to AD. "How Do I Provision Users to Active Directory outlines how this works. "Understanding Data Synchronization with External Systems" provides a detailed description about the process. Cheers, MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

I had a problem getting many different attributes to flow to AD, but when I finally changed the Flow Scope option to it's default of nothing, the information finally flowed. I don't understand it, but the Flow Scope option in the Portal Synch Rules overrides what your attribute precendence rules are set to in the Metaverse. Once i changed the setting from what our contractor set, everything worked.

The External System Scoping Filter is an object level filter. This means, when filtered, an objects remains a disconnector. So, the filter is not related to attribute flow precedence since you need a connector to flow something. Cheers, MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation