This is community preview of a new document type called “How Do I Guides”. The objective of these guides is to assist you in your deployments with best practice recommendations for common scenarios. Please take advantage of the preview and provide feedback. Happy Reading, MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

One basic requirement for an identity management system is the ability to import and process identity data from an external system. This guide walks you through the main building blocks that are involved in the process of populating Microsoft Forefront™ Identity Manager (FIM) 2010 with group data from Active Directory® Domain Services (AD DS), outlines how you can verify whether your scenario works as expected, provides suggestions for managing Active Directory groups by using FIM, and lists additional sources for information. Before You Begin In this section, you will find information about the scope of this document. In general, "How Do I" guides are targeted at readers who already have basic experience with the process of synchronizing objects with FIM as covered in the related Getting Started Guides. Audience This guide is intended for information technology (IT) professionals who already have a basic understanding of how the FIM synchronization process works and are interested in getting hands-on experience and more conceptual information about specific scenarios. Prerequisite knowledge This document assumes that you have access to a running instance of FIM 2010 and that you have experience in configuring simple synchronization scenarios as outlined in the following documents: Introduction to Inbound Synchronization Introduction to Outbound Synchronization The content in this document is scoped to function as an extension to these introductory documents. Scope The scenario outlined in this document has been simplified to address the requirements of a basic lab environment. The focus is to give you an understanding of the concepts and technologies discussed. This document helps you develop a solution that involves managing groups in AD DS by using FIM. Time requirements The procedures in this document require 120 to 150 minutes to complete. These time estimates assume that the testing environment is already configured and does not include the time required to set up the test environment. Getting support If you have questions regarding the content of this document or if you have general feedback you would like to discuss, feel free to post a message to the Forefront Identity Manager 2010 forum. Scenario Description Fabrikam, a fictitious company, is planning to use FIM to manage the group accounts in the corporation’s AD DS by using FIM. As part of this process, Fabrikam needs to synchronize group data to FIM. To start with the initial testing, Fabrikam has installed a basic lab environment that consists of FIM and AD DS. In this lab environment, Fabrikam is testing a scenario that consists of a security group that was manually created in AD DS. The objective of this scenario is to synchronize the group to FIM. Scenario Design To use this guide, you need three architectural components: Active Directory domain controller FIM Synchronization Server FIM Portal Server The following illustration outlines the required environment: You can run all components on one computer. Note For more information about how to set up FIM, see the FIM Installation Guide Scenario Components List The following table lists the components that are part of this scenario in this guide. Organizational unit: FIM Objects - Organizational unit that is used as a target for the provisioned group. User accounts: ADMA - Active Directory user account with sufficient rights to connect to AD DS. FIMMA - Active Directory user account with sufficient rights to connect to FIM. Britta Simon - Sample account in AD DS that is synchronized to FIM. Security Groups: Test Security Group – Active Directory security group used to test the synchronization logic to FIM. Management agents and run profiles: Fabrikam ADMA - Management agent that exchanges data with AD DS. Fabrikam FIMMA - Management agent that exchanges data with FIM. Synchronization Rules: AG Group Inbound Synchronization Rule - Inbound Synchronization Rule that synchronizes groups from AD DS to FIM. Scenario Steps The scenario outlined in this guide consists of the following building blocks: Configuring the External Systems In this section, you will find instructions for the resources that you need to create that are outside of your FIM environment. Creating the organizational unit You need the organizational unit as a container for the sample objects. Step 1 Create an organizational unit called FIMObjects in your AD DS. Note For more information about creating organizational units, see Create a new organizational unit. Creating the Active Directory user accounts For the scenario in this guide, you need two Active Directory user accounts: Adma - User account used by the Active Directory management agent. Fimma – User account used by the FIM Service management agent. In both cases, it is sufficient to create regular user accounts. More information about the specific requirements of both accounts is found later in this document. Note The third account (Britta Simon) is not required at this point. You will get instructions for creating this account later in this document. Step 2 Create two Active Directory user accounts based on the previous description. Note For more information about creating organizational units, see Create a new user account. Configuring the FIM Synchronization Service For the configuration steps in this section, you need to start the FIM Synchronization Service Manager. Creating the management agents For the scenario in this guide, you need to create two management agents: Fabrikam ADMA - management agent for AD DS. Fabrikam FIMMA – management agent for FIM Service Management Agent. Note Some elementary configuration settings in this section include user related configurations; however, the first test cycle is only for group objects. You will add more specifics about user objects after you have successfully synchronized the group object. Configuring the Fabrikam ADMA When you configure a management agent for AD DS, you need to specify an account that is used by the management agent in the data exchange with AD DS. You should use a regular user account. However, to import data from AD DS, the account must have the right to poll changes from the DirSync control. If you want your management agent to export data to AD DS, you need to grant the account sufficient rights on the target organizational units. For more information about this topic, see Configuring the ADMA Account. When you import group data from AD DS, you should at least select the following attributes: cn or display name - Use to make your groups recognizable. In AD DS, display name is often not set. To make sure that the display name in FIM had a value, you can use the CN. groupType - To get the information about the group type and scope. managedBy - Use to show the owner of the group in FIM member - To track the members of a group sAMAccountName - the NetBIOS name of a security group Caution You should examine your AD DS data carefully before configuring imports. Some group management related attributes such as managedBy and display name do often not have a value! The following table lists the most important scenario specific settings you need to configure: Management Agent Designer Page Configuration Create Management Agent Management agent for: Active Directory Domain Service Name: Fabrikam ADMA Connect to Active Directory Forest Select directory partitions: “DC=Fabrikam,DC=com” Click Containers to open the Select Containers dialog and make sure that FIMObjects is the only organizational unit (OU) that is selected. Select Object Types In addition to the already selected Object types, select group. Select Attributes Click Show All. Select the following attributes: displayName groupType managedBy member sAMAccountName Configuring the Fabrikam FIMMA When you configure a FIM Service management agent, you need to specify an account that is used by the management agent in the data exchange with the FIM Service.You should use a regular user account. The account must be the same account as the one you specified during the installation of FIM. Using Windows PowerShell to Do a FIM MA Account Configuration Quick Test contains a script that you can use to determine the name of the FIMMA account name that you specified during setup and to test whether this account is still valid. The following table lists the most important scenario specific settings you need to configure.: Management Agent Designer Page Configuration Create Management Agent Management agent for: FIM Service Management Agent Name: Fabrikam FIMMA Connect to Database Use the following settings: Server: localhost Database: FIMService FIM Service base address: http://localhost:5725 Provide the information about the account you created for this management agent. Select Object Types In addition to the already selected Object types, select Group and Person. Configure Object Type Mappings In addition to the already existing object type mappings, add the following mappings: Data Source Object Type Metaverse Object Type Group group Person person Configure Attribute Flow In addition to the already existing attribute flow mappings, add the following attribute flow mappings: Step 3 Create two management agents based on the previous description.To create a management agent, you need to switch first to the Management Agents view by clicking Management Agents on the Tools menu.To start the Create Management Agent wizard, on the Actions menu, click Create. Note For more information, see the following topics in Help: Create a Management Agent Connect to an Active Directory Forest Using the Management Agent for Active Directory Configure Directory Partitions Creating the run profiles The following table lists the run profiles you need to create for the scenario in this guide: Management agent Run profile Fabrikam ADMA Full Import Full Synchronization Delta Import Delta Synchronization Export Fabrikam FIMMA Full Import Full Synchronization Delta Import Delta Synchronization Export Step 4 Create for each management agent run profiles according to the previous table. To create run profiles for a management agent, select the management agent, and on the Actions menu, click Configure Run Profiles. Note For more information, see the Create a Management Agent Run Profile in FIM Help Important Verify that provisioning is enabled in your environment. You can do this by running the script: Using Windows PowerShell to Enable Provisioning.

Configuring the FIM Service For the scenario in this guide, you only need to configure an inbound synchronization rule. The following section provides information about the configuration of the synchronization rule. Creating the synchronization rule When you create the inbound synchronization rule for your Active Directory groups, you need to add a flow mapping for the domain attribute. Populating the domain attribute is a challenge because "domain" is not an attribute of a group. When this attribute is required in AD DS, the directory service has to look up the value from the configuration container. The following illustration shows an example of a domain partition in the configuration container: One method used to populate the domain attribute is to implement a lookup table that determines the attribute value based on the current SID of an object. The SID attribute is a good attribute for this purpose because the value of this attribute only changes when the domain membership of an object changes. The SID attribute of an object in AD DS consists of the domain SID plus an extension called relative identifier (RID), the unique identifier of an object within the domain database. If you know what the value of the domain SID is, you can use this value in comparison with the SID value of an object to determine the value of the domain attribute as a custom expression. FIM provides a built-in function you can use to translate a binary SID into a string representation. The name of this function is ConvertSidToString. This function returns the string representation of a SID as domain SID + RID. For an equality comparison (Eq) of a user's SID and the domain SID, you need to remove the RID part from the user's SID.Because you know the value of the domain SID, you also know the domain SID length.You can use the length of the domain SID to calculate the part of a user's SID that you need for an equality comparison. The following example outlines how you can use the domain SID and the user's SID to calculate the domain value with a custom expression in FIM. A lookup of Fabrikam's SID returns a value of "S-1-5-21-4220550486-1538840966-3184992408". The SID string has a length of 41. The first step in your custom expression is to translate the object's SID into a string representation by using the ConvertSidToString method: ConvertSidToString(objectSid) From this string, you only need the first 41 characters from the left:: Left(ConvertSidToString(objectSid), 41) The question is whether this string is equal to the domain SID: Eq(Left(ConvertSidToString(objectSid), 41) The FIM ScriptBox provides a script that automatically calculates the required custom expression string for the domain attribute value calculation.You can find this script here: Using PowerShell To Generate The Custom Expression For The Domain Attribute FlowThe script requests the required information from a target domain controller, translates the domain information into a CustomExpression and stores the result in the clipboard. In AD DS, each group has a type and a scope. The group type is either security or distribution. Each group type can have three different scopes: Domain local Global Universal The following illustration shows the related configuration dialog for groups in AD DS: The FIM schema defines two separate attributes to track the type and the scope information of a group. However, in AD DS, only one attribute, groupType, is used to track this information. When you configure an outbound synchronization rule for AD DS, you need to configure an outbound attribute flow mapping that merges the values for the type and the scope into one attribute value. To calculate the required groupType value, you can use the following table: Type Scope GroupType Distribution Global 2 Domain Local 4 Universal 8 Security Global - 2147483646 Domain Local - 2147483644 Universal - 2147483640 In FIM, the type and the scope of a group are tracked in separate attributes. When you synchronize a group from AD DS to FIM, you need to calculate the FIM attribute values from the groupType attribute in AD DS. The groupType attribute in AD DS is a bit vector, which means that the same bits are used in the security and the distribution group to define the scope of a group. When you need to determine the scope of a group, you can simply do this by applying a BitAnd operation to the groupType attribute.The following table lists the calculation results of a BitAnd, the groupType, and a value X. BitAnd(X, groupType) Scope 2 Global 4 Domain Local 8 Universal Because the bits 2, 4, and 8 are used in security groups and distribution groups to define the scope, you can use the bit mask of 2 + 4 + 8 to calculate the type of a group. If a BitOr operation of the groupType and the mask value 14 returns a 14, the processed object is a distribution group. When you import unmanaged group information from AD DS into FIM, you need to initialize the membershipLocked attribute.The best practice recommendation is to set this attribute to false. The next attribute that, you need to initialize is the membershipAddWorkflow attribute that should be set to Owner Approval. The following table shows the configuration of the related outbound synchronization rule: Step 5 Create a synchronization rule according to the data in the previous table. Important Verify, that you have selected Initial Flow Only for the attribute flow that has the DN as the destination. Initializing Your Environment The objective of the initialization phase is to bring your: Enable the required MPRs for group synchronization Synchronization rule into the metaverse. Active Directory structure into the Active Directory connector space. To synchronize group objects in your environment, you need to enable the following management policy rules: Display Name Synchronization: Synchronization account can read group resources it synchronizes Synchronization: Synchronization account controls group resources it synchronizes Step 6 Enable the MPRs listed in the previous table. The following table lists the run profiles that are part of the initialization phase. Run Management agen Run profile 1 Fabrikam FIMMA Full Import 2 Full Synchronization 3 Export 4 Delta Import 5 Fabrikam ADMA Full Import 6 Full Synchronization Step 7 Run the run profiles according to the previous table. Note You should verify that your outbound synchronization rule has been successfully projected into the metaverse. Testing the Configuration The objective of this section is to test your actual configuration. To test the configuration, you: Create a sample security group in AD DS. Synchronize the Active Directory group into FIM. Creating a sample security group in AD DS The following table lists the properties of the sample security group: Attribute Value Group Name Test Security Group Group name (pre-Windows 2000) Test SG Group Scope Universal Group Type Security Step 8 Create a sample security group according the data in the previous table. Synchronizing the Active Directory group into FIM Before you start a first synchronization cycle for a test object, you should track the expected state of your object after each run profile that you run in a test plan. Your test plan should include next to the general state of your object (created, updated, or deleted) also the attribute values that you expect. Use your test plan to verify your test plan expectations. If a step does not return the expected results, do not proceed with to the next step until you have resolved the discrepancy between your expected result and the actual result. To verify your expectations, you can use the synchronization statistics as a first indicator. For example, if you expect new objects to be staged in a connector space, but the import statistics returns no "Adds", there is obviously something in your environment that does not work as expected. While the synchronization statistics can give you a first indication of whether your scenario works as expected, you should use the Search Connector Space and the Metaverse Search feature of the Synchronization Service Manager to verify the expected attribute values. To synchronize the group to FIM, follow the steps below: Import the security group into the AD MA connector space. Project the security group into the metaverse. Provision the security group to the FIM connector space. Export the security group to FIM. Confirm the creation of the security group. To accomplish these tasks, you run the following run profiles.: Management agent Run profile Fabrikam ADMA Delta Import Delta Synchronization Fabrikam FIMMA Export Delta Import After the delta import from AD DS, the synchronization statistics report one new object: The objective of the delta synchronization run on your Fabrikam FIMMA is to perform several operations: Projection – The new security group object is projected into the metaverse. Provisioning – The newly projected group object is provisioned into the connector space of the FIM MA. Export Attribute Flows – The newly provisioned exbject is initialized with the the attribute values according to the configuration. Step 9 Run the run profiles according to the previous table. Caution Each run profile run must succeed without an error. Verify the provisioned security group in FIM To verify that your sample user has been synchronized to FIM, open the related object in the FIM Portal. Step 10 Verify that your sample user exists in the FIM Portal. Extending Your Group Synchronization Logic Because you have successfully synchronized a group object from AD DS to FIM, you are now ready to add more components to your synchronization logic. As a first step, you should add group members to your security group. The membership in a group is tracked in an attribute called a member, a multi-valued reference attribute. When you synchronize reference attributes in FIM, you need to ensure that both objects, the referencing attribute as well as the referenced attribute, are available in all layers of the synchronization service. The FIM Synchronization Service preserves existing reference relationships and also enforces referential integrity. This means that the FIM Synchronization Service ensures that the references of referencing objects are pointing to valid objects. The following illustration outlines this process for the member attribute of a group. Keeping references intact across the various data layers (connector space, metaverse, and external system) involves the transformation of the reference value into a format that is used by each layer. For example, in FIM, references are expressed as GUID values. However, in AD DS, reference values are implemented as 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, also known as group nesting, a group can also contain users as members.To preserve the references that point to user objects, you need to extend your synchronization logic to the components that are required to synchronize user objects. For the required deployment instructions for synchronizing user objects in your environment, see How Do I Synchronize Users from Active Directory to FIM. 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. After a synchronization cycle to FIM, Brita Simon becomes a member of the group in FIM: For more information about reference attributes, see Design Concepts for Managing Reference Attributes When you synchronize group objects from AD DS to FIM, there are two more attributes that require your attention in the FIM Service: DisplayedOwner Owner While you can synchronize group objects from AD DS to FIM without populating values for these attributes, they are technically required by FIM so that the group is manageable within FIM , specifically: An Owner-approval group needs an owner so that they can manage membership in the group. FIM requires that the Displayed Owner is a member of the Owner group. One option that you have is to populate both attributes based on the managedBy attribute in AD DS. However, this method may require additional updates to your AD DS because managedBy is often not populated in AD DS. Another method is the configuration of workflows in FIM to initialize the attributes when a new group object has been imported from AD DS into FIM. Using workflows to initialize attribute values can have an impact on your environment when a large amount of objects has been imported from AD DS. You should keep this in mind when you perform bulk imports of new objects from AD DS. The third method to initialize these values is a scripted approach based on the FIM Windows PowerShell™ cmdlets. By using the scripted method, you can retrieve a list of the affected objects, set the values that you want, and import them back into your FIM Service data store. The tradeoff of the scripted method is the required manual interaction that can be time consuming. Summary Synchronizing group objects from AD DS into FIM is a relatively simple task from a configuration perspective. The only bigger challenge is the population of the domain attribute because this attribute is not directly associated with an object in AD DS and needs to be calculated. In this document, you have been introduced to a method that uses an object's SID attribute value and a lookup table for the calculation of the value. When using this method, keep in mind that a change to your domain infrastructure such as renaming existing domains or adding new domains requires an update to the calculation logic in your inbound synchronization rule. Updates to synchronization rules require full synchronization runs that can be time consuming to process in your environment. An alternative to populating the domain attribute in a synchronization rule is the implementation of workflows to do this task. However, initializing attribute values by using workflows has an impact on the performance of your system. The performance impact of bulk imports from AD DS can be significant. In general, when implementing inbound synchronization rules in your environment, you need to differentiate between two scenarios: Initialization of objects from AD DS Regular imports from Active Directory objects The initialization phase requires special care in your planning. In this phase, FIM is populated by a bulk import with existing objects from AD DS. This scenario can have a significant impact on both the servers in your external systems and your servers running FIM. If you have a large number of objects that you need to synchronize from AD DS into FIM, you should investigate options that can limit this process such as: Limiting the number of objects that are processed during one import run from AD DS. This option is a recommended best practice. Modifying the partitions and container filters to decrease the number of objects that are processed in one run. Exporting your AD DS objects by using, for example, LDIF and importing them into FIM by using the FIM Windows PowerShell cmdlets. Each method has pros and cons. You need to determine the method that works best for you in your test environment. Another aspect of handling the initialization phase is the subject of attribute flow precedence. During the initialization phase, you may need to make AD DS authoritative for attributes for which you want FIM to be authoritative after the initialization phase. This means that you need to configure the attribute flow precedence in a way that enables your Active Directory management agent to flow attribute values into FIM that, later in your deployment, will be controlled by FIM. In general, you should develop a plan that includes a solution for the initialization phase for your environment. For the scenario in this document, the samAccountName attribute is used to join related identity objects. However, in many scenarios, this attribute is not the optimal solution because the samAccountName attribute is only required to be unique on a per domain basis. The best attribute to implement robust joins is a unique identifier called Correlation ID. There are several options to implement a Correlation ID in a production environment. You can find more information about this topic in Design Concepts for Correlating Digital Identities. When you are in the process of planning your deployment, you should investigate an option to extend the Active Directory schema with an attribute that stores a Correlation ID. If you want FIM to eventually be authoritative for the object management in your environment, you can use the already existing GUIDs of the FIM objects as the source for your Correlation ID. In addition to implanting a method for robust joins in your environment, a Correlation ID is helpful to detect managed objects in your AD DS. If an object has a value for this attribute, you know that this object is managed by FIM. Recommended Reading Design Concepts: Using FIM to enable or disable accounts in Active Directory Design Concepts for Correlating Digital Identities 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

Markus this is another great addition to the documentation. It might be useful to add a note on how to use the populated groups in dynamic sets, as it's not obvious in the GUI or the existing documentation http://social.technet.microsoft.com/Forums/en-US/ilm2/thread/e6661c08-3747-4c99-bb1a-cbba75b89726

Thanks, Capriole, you are right, this is a good idea! Cheers, Markus Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation

With regards to the inbound flow definitinon in the sync rule, constants are being flowed to the membershipAddWorkflow and the membershipLocked attributes. Let's say I want to manage groups within FIM and I set up a complementary outbound flow on the sync rule. What will happen with groups which are designated within fim as criteria based groups (membershipAddWorkflow=None and membershipLocked=true) when doing a full synchronization from AD? Will those attributes be overwritten by the set constants, changing the group back to being manually-managed?

Awesome question, Mark! The idea of these two flows is primarily to say "you need to initialize these attributes in your environment".Using a synchronization rule that is tied to the ADMA only makes sense, if you don't want to change the values moving forward.If these settings may change, you need to look into a different way to set them. One option is to use workflows to initialize these attributes. Another option is to script this.The mileage may vary... Cheers,MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

Thanks for your response Markus, I have looked into different ways of setting the values of those attributes. Here's what I've found, please correct me if I'm wrong. Since those two attributes (membershipAddWorkflow, membershipLocked) are required on the group object in FIM, in order for an Export from the metaverse to FIM to work, they need to be populated with values, and therefore using workflows to initialize those values wouldn't be an option, since the workflow wouldn't be able to be executed until after the object has been exported to FIM. So, since AD doesn't have corresponding attributes, the values of those attributes must be set using sync rule constants, or an AD rule extension. However, as you had mentioned, using sync rule constants to do this only makes sense if you don't want to change the values moving forward. Since I do want to be able to change these values going forward, that leaves me with the only option being to use an AD rule extension, and defining an import flow within sync manager from another AD attribute (say, 'samAccountName', it doesn't really matter) into membershipAddWorkflow and membershipLocked, and using code in the rule extension something like the following to set the default values if there are no values present: if (!mvEntry["membershipAddWorkflow"].IsPresent) mvEntry["membershipAddWorkflow"].Value = "Owner Approval"; if (!mvEntry["membershipLocked"].IsPresent) mvEntry["membershipLocked"].Value = "false"; So, the way I understand it, if you want FIM to be able to manage groups which were created in AD and synchronize the FIM changes back to AD, it is necessary to create an AD rules extension to flow these initial values in. The only other way I can think it would work is by changing the bindings in FIM of those two attributes on the group object to set them to not be required, so that the groups can be created in FIM without those attributes being set, and then creating an MPR which would be triggered by the creation of groups, and would initialize a workflow that would set those initial values. However, I haven't tried this, and I don't know if there would be any unintended consequences of removing the requirement on the bindings. It seems to me that there must be an easier (codeless?) way to achieve the goal of being able to manage AD created groups with FIM other than having to create an AD rules extension. Am I missing something? Thanks, Mark

Awesome discussion! MembershipAddWorkflow and membershipLocked are actually perfect examples for attributes you should initialize by using a workflow."...since the workflow wouldn't be able to be executed until after the object has been exported to FIM..." - but that's OK, since these attributes only apply to FIM objects - right?From the configuration perspective, it is very easy to setup a TMPR that invokes a workflow to initialize both attributes when, for example, a group transitions into an All Groups set. The only reason to initialize these attributes in a synchronization rule is the "bulk import" scenario. If you have, for example, already "tons" of groups in AD, and you want to use FIM to manage them, importing all groups in one "full import + full synchronization + export to FIM" sequence can be pretty time consuming and can stress your FIM server quiet a bit if there are too many workflows active. You are good using a workflow to initialize these attributes by using a workflow - even in case of the "bulk import" scenario if you can throttle your import.This means, if you implement a process that brings your groups step-by-step (in batches) from AD to FIM. You are right, there is right now no option in FIM to do an "MVEntry-IsPresent" check and using a rules extension is right now the only alternative to address this.However, as mentioned before, I would rather look into an option to throttle the bulk imports and initialize these attributes by using workflows instead of using a rules extension.The rules extension solution should be sort of a "plan B" if it is not possible to control the number of objects that are processed in the "bulk import" scenario. Cheers,MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

Hi Mark and Markus, Following your discussion, I recognize a similar case I 've done in my test. As I was using FIM RC1, it was not possible to use the TMPR as they where not present in the first RC1. I've faced the same problem to initialize these 2 attributes in FIM Portal. Since they must be present when you export an object form MV to FIM Portal, you can't use an Action workflow which requiered that the group must have been created in FIM Portal. Possible way in workflow can be an Authorization workflow running at group creation and modifying the request parameters, but I don't know if it is possible to do in a custom workflow. The way I've choosen, which is not the best and recommanded one, was to modify the 2 attributes to be not requiered for the group. This way, Action workflow at group creation can run and initialize attributes to a specified value at creation. As it can be time consuming if you have a lot of group to run the workflow repetidly, it can also be done externaly with a powershell script. This way, you may think :"but if I change the requiered value, this means that user can create a group without initialize these 2 attributes" - but that's not the case since the RCDC requiered these attribute to be set. Even if you pass by a powershell script to create the group without the attributes using the FIM Service, the Action workflow will initialize them. Modifying existing attribute in the FIM schema is not very correct, but FIM is great in this way that you can change a lot of things and, afterall the 2 attributes are not in the list of 13 core attributes http://technet.microsoft.com/en-us/library/ff608274(WS.10).aspx

MembershipAddWorkflow and membershipLocked are actually perfect examples for attributes you should initialize by using a workflow. "...since the workflow wouldn't be able to be executed until after the object has been exported to FIM... " - but that's OK, since these attributes only apply to FIM objects - right? From the configuration perspective, it is very easy to setup a TMPR that invokes a workflow to initialize both attributes when, for example, a group transitions into an All Groups set. But since these attributes are required, the export to FIM will fail for a group which doesn't already have these attributes set. If the export fails, the group object doesn't make it into FIM, and therefore no MPRs will be executed against it.

Great thread. I've just started thinking about the issue and had an idea (which I haven't thought all the way through yet). What about using some of the hidden AD extension attributes of the groups - say extensionattribute1 and extensionattribute2 and manually populating them in AD before the initial import. (For all existing AD groups use script or LDIFDE to set extensionattribute1=false and extensionattribute2 = OwnerApproval) ? The ISR attribute flows would flow extensionattribute1 -> membershipaddworkflow and extensionattribute2 -> membershiplocked. OSR attribute flows would do the reverse?