Asked by:
Test

General discussion
-
Extending Your Group Synchronization Logic
Because you have successfully synchronized a group object to AD DS, you are now ready to add more components to your synchronization logic.
This includes the:- Owner of a group
- Members of a group
The owner of a group and the member of a group have one thing in common—both attributes are reference attributes.
When you synchronize reference attributes in FIM, you need to ensure that both objects, the referencing attribute and the referenced attribute, are available in all layers of the synchronization service.
The synchronization service preserves existing reference relationships and also enforces referential integrity.
This means that the synchronization service ensures that the references of referencing objects are pointing to valid objects.The following illustration outlines this process using the member attribute of a group:
Keeping references intact across the various data layers (connector space, metaverse, external system) involves a transformation of the reference value into a format that is used by each layer.
For example, in FIM, references are expressed in form of GUID values.
However, in AD DS, reference values are implemented in form of DNs.
During a synchronization run and also during an import from and an export to a data source, the synchronization engine applies the necessary transformation of the reference values.While groups can contain groups as members, which is also known as group nesting, a group can also have users as members.
To preserve the references that point to user objects, you need to extend your synchronization logic with the components that are required to synchronize user objects.
In How Do I Provision Users to Active Directory Domain Services, you find the required deployment instructions for synchronizing user objects in your environment.
You should extend your group synchronization scenario with the user synchronization logic that is outlined in this document.After implementing the synchronization logic for users, you should add the sample user Britta Simon as a member to the security group, add Britta to the owners of the groups, and make her the displayed owner.
After a synchronization cycle to AD DS, you find that Britta Simon is the new owner of the group:In addition, you also find that Britta is a member of your sample security group:
For more information about reference attributes, see Design Concepts for Managing Reference Attributes.
Summary
The objective of this document is to introduce you to the main building blocks for synchronizing a group in FIM to AD DS.
In your initial testing, you should first start with the minimum of attributes that are required to complete a task and add more attributes to your scenario when the general steps work as expected.
Keeping the complexity to a minimal level simplifies the process of troubleshooting.When you test your configuration, it is very likely that you delete and recreate new test objects.
For objects with a populated ExpectedRulesList attribute, this can result in orphaned ERE objects.
The article called "A method to remove orphaned ExpectedRuleEntry objects from your environment", describes how you can remove these objects from your test environment.For a production environment, when you manage Active Directory groups by using FIM, you should consider including the following attributes into your synchronization logic:
FIM Attribute Active Directory Attribute Description - dn Attribute that is used in AD DS to store the location of an object displayName displayName User-friendly name to identify an object in the user interface accountName sAMAccountName NetBIOS name of the object in AD DS displayedOwner managedBy Single-valued attribute to store the owner of a group in AD DS scope and type groupType Attribute used to store the scope and the type of a group in AD DS member member Multivalued attribute alias Alias Mail nickname for a mail-enabled group Recommended Reading
- Design Concepts: Using FIM to enable or disable accounts in Active Directory
- Design Concepts: About Reference Attributes
- How can I manage my FIM MA account?
- Detecting Non-authoritative Accounts – Part 1: Envisioning
- Design Concepts: The poor man’s version of a connector detection mechanism
- Design Concepts: Configuring the ADMA Account
- A method to remove orphaned ExpectedRuleEntry objects from your environment
- About Attribute Flow Precedence
- About Exports
- Split by Markus VilcinskasMicrosoft employee Sunday, March 28, 2010 5:46 PM test
- Split by Markus VilcinskasMicrosoft employee Sunday, March 28, 2010 5:49 PM Test
- Changed type Ahmad Abdel-wahed Wednesday, March 31, 2010 5:30 PM Test
Sunday, March 28, 2010 5:07 PM