Users are provisioned from SQL Table1 source to Active directory destination. Inboud Sync 1 and Outbound Sync 1 are used to do the provisioning. After the user account is successfully created in the Active directory a flag needs to be set in SQL Table2. I created an Inboud Sync2 from Active directory and Outbound Sync2 to SQL Table2. The Outbound Sync2 rule is not applied. I dont know why. MPR for Outbound Sync2 is as follows: Specific Set of Requestors: All People Operation: Create resource, Read resource, Modify resource attribute Target Resource Definition before Request: All Objects Target Resource Definition after Request: All Employees Resource Attributes: All Attributes Action: The workflow with Outbound Sync2 Outbound Sync2 Relationship criteria: EmployeeID to EmployeeID in the Table2 Create object in connected system is not checked (I tried it checked but it didnt work either) Attribute Flow: c_ST_EmailFlag=>EmailFlag c_ST_PWDFlag=>PWDFlag employeeID=>CWID loginName=>NewNTDirectory Inbound Sync2 from AD Relationship criteria: accountName to cn (cn is unique account name in AD) Create object in ILM is not checked Attribute flow: userAccountControl=>c_ST_UAC employeeID=>employeeID sAMAccountName=>loginName

Hi Alexander, Maybe some more information could be helpful. Is Inbound Sync1 the rule that creates the objects in ILM? If so, are users falling in the "All Employees" category when you import them? i.e. are the criteria to apply the outbound flow satisfied? If you look at your users in the ILM portal, do you see some entries in the "Expected Rules List" tab? If it's empty, it means that the MPR is not triggered, and you should try to understand why. Otherwise, when you do an import from the ILM agent, what happens? Are the Expected Rule Entry actions created in the Metaverse? Cheers, Paolo

Alexander,this scenario is covered in Publishing Active Directory Users From Two Authoritative Data Sources.Cheers,MarkusMarkus Vilcinskas, Technical Content Developer, Microsoft Corporation

Thank you for your replies. Publishing Active Directory Users from Two Authoritative Data Sources scenario is working without problemsin the first part of the provisioning with SQL Table1 to Active directory, Inboud Sync 1 and Outbound Sync 1. The second part of the provisioning cycle is to set a flag in the SQL Table2. This flag is initially exported from Table1 (which is a view of Table2) to the custom Metaverse attribute c_ST_EmailFlag and the value is 0. Once the account is successfully created or updated in the active directory I need to set the flag to 1 in the Table2. So I created an Inbound Synch2 on Active Directory MA and the only attribute I am flowing is userAccountControl=>c_ST_UAC(custom Metaverse attribute). I have an Extension rule on the AD MA Import where Metaverse attribute c_ST_EmailFlag gets value 1. Outbound Sync 2 flows c_ST_EmailFlag => Table2.EmailFlag. By some reason the Import Extension rules dont get executed at all. I had an impression that if I run Synchronization on the MA the Import part of Extension rules should be executed. In which case would it not execute? When I click on the users in ILM, Provisioning tab has the Outbound Sync1 with status Applied and Outbound Sync2 with Status Pending. In the metaverse Rule Entry actions created but only Outbound Sync1 status is applied. What does that mean? As I understood from the request list in the ILM portal the MP for Outbound Sync 2 gets applied only on Create object request, not on update. What needs to happen in order to get MP to be applied on an Update?I am not sure if my run profile sequence is correct. After the accounts are exported to AD, It goes like this: AD Full ImportAD Delta SynchronizationILM ExportILM Full ImportILM Full SynchronizationSQL Table 2 ExportSQL Table 2 Full ImportSQL Table 2 Full Synchronization

Alexander, what do you mean by "Extension rule"? I assume, you have an inbound synchronization rule with an inbound attribute flow rule for an attribute - could you please confirm?In this case, you are right, inbound synchronization rules are applied on a connector space level.So, if you have an inbound synchronizationconfigured for your ADMA,during a synchronization run on that MA, this rule is applied.You shuold verify, wherther the rule has been successfully imported into the metaverse.If this is the case, check the attribute flow precedence configuration for the affected attribute (this is documented in "Publishing Active Directory Users from Two Authoritative Data Sources").Cheers,MarkusMarkus Vilcinskas, Technical Content Developer, Microsoft Corporation

Hello Markus,I meant inbound synchronization rule with an inbound attribute flow. It seems that the attribute precedence wasthe problem. The metaverse attribute is getting updated now. But I am still not able to export it to the destination table. When I click on a users Provisioning tab, I see that the outbound synchronization rule is in the expected rules list but the status is Pending. When I run Export profile on the destination MA, nothing gets exported. The flag attribute is the only attribute in the outbound synchronization rule. Since the flag attribute is custom Metaverse attribute, I dont have attribute flow in the ILM management agent for it. Do I need to have the flag attribute in the attribute flow of any of the management agents?

AlexanderPlease verify in the ILM MA if you have the EXpectedRuleList flow like:Data Source/Person/EXpectedRuleList --(Import)--> EXpectedRuleList/Person/Metaverse.regardsEric

Hello Eric,Thank you for your reply. ILM MA has both Import and Export for ExpectedRuleList.I would like to add that "Object Creation in connected system" checkbox is not set. I am not sure if that makes any difference.

For declarative/codeless provisioning to work properly you need to configure the correct synchronisation on your DRL and ERL attributes. For the person object, ensure you have an inbound flow for ERL and an outbound flow for DRL. This is configured in the ILM MA within the IdM UI (MIISClient.EXE). In addition, to ensure the DREs are created, you require at least one flow rule configured as "Existence check" for each OSR. Once you've done this you can trigger MPRs based on the DRL...