Can someone confirm what I've only just realised (And isn't entirely clear from the doco)Attribute flows in inbound sync rules only flow attributes from thesource CS to the MV. The attributes won'tflow on from the MV to the FIM/ILMSDB unless the same attribute flows are configured on the FIM MA.Scenario:MAsfor AD and FIM with no additional attributeflows specified.Inbound sync ruleapplying to AD MA user objects, with the "Object creation in ILM" box checked and attribute flows defined.Run FIM Full Import, FIM Full Sync, FIM Export, FIM Delta Imp, AD Full Import, AD Full Sync, FIM ExportResult:All AD Users exist in Metaverse, with all attributes set as specified in inbound sync rule attribute flow All AD Users exist in FIM,but with no attributes set(If you added the same attribute flows to the FIM MA, then the users in FIM would also have the attributes set)

You're right; the FIM Synchronization Engine handles each Connector Space separately. The configuration of an MA defines always the behavior between that Connector Space and the Metaverse, it never has influence of flows etc. from the Metaverse to other MAs. As you discovered in your scenario you have to configure an import attribute flow rule from AD CS to MV that will be applied during the inbound synchronization step of the AD MA run. Once the MV is populated with attributes the export attribute flow of your FIM MA will be executed during the outbound synchronization step of your FIM MA run. /Matthias

Have you looked at Introduction to outbound synchronization yet?"To bring an object from a conventional connector space into the connector space of the ILMSDB if it has been brought into the metaverse, you just need to set the Create object in ILM flag in the related inbound synchronization rule. The following illustration shows an example for this setting from an inbound synchronization rule...Setting this flag eliminates the need for a separate outbound synchronization rule. Although, there is no need for an inbound or outbound synchronization rule in case of an ILM management agent, you still might want to fine-tune the data exchange between the connector space of this management agent and the metaverse. You can do this by configuring the legacy rules such as inbound and outbound attribute flow rules that still exist in the configuration of this management agent."Do you have a suggestion for making this clearer?Cheers,MarkusMarkus Vilcinskas, Technical Content Developer, Microsoft Corporation

I thinkthewords that are confusing are eliminatesandfine-tune.Eliminates implies that the flag does everything an outbound sync rule does (join, provision + attribute flow) when it only takes care of the join + provision. fine-tune implies that the flag causes attributesto flow from the MV to the ILM CS, but thatsome changes might be required. I can't see many real-world cases where you would want the object created but for no attributes to flow.It might be clearer withsomething like "Setting this flag provisions objects into ILMwithout requiringan outbound synchronization rule. Although you will still need to create legacy attribute flow rules to exchange data between the connector space of the ILM management agent and the metaverse."Regards,Graham

You still have to manually create old style outbound synchronization rules from the Metaverse to the ILM database. I don't know if this is the intention for the releaesd product or not, but if it is the documentation should be more clear about this.

OK, understood :o) - will think about the wording...What you need to configure are the attribute flow rules and this won't change.So, it is not about synchronization rules in general.The FIM database is from the metaverse side supposed to be a mirror - so metaverse data is supposed to be replicated to FIM but not vice versa. However, the system has no idea what it actually is you need to replicate.There is a default schema; however, the out of the box schema is just available for convenience.If you make it right, you would whipe everything you don't need.It is also not that there is no attribute flow configured.The minimum the system needs to function is out of the box configured.Everything, that is beyond this is based on your needs.For example, there is even no technical need to flow a displayName...I have used the term "fine-tune" because I don't know how to be more specific.It is supposed to read "configure the flows you think you need".The system already functions with what is configured out of the box.Cheers,MarkusMarkus Vilcinskas, Technical Content Developer, Microsoft Corporation

Great - thanks Markus"configure the flows you think you need" wording is much better.It might be useful somewhere to have a list of whatattributes users in FIMDBmust havefor specificportal functions, so we'll have some idea of what attributes we need to flow to get the portalexamples (Password reset etc)to work.For instance users in FIM DB can'tauthenticate to the portal using their AD account unless their accountname is populated in FIM DB.

The system already functions with what is configured out of the box. If by function you mean that "object relationships are maintained" then this statement is true. If you mean that "the system does anything useful" then this is not true. Out of the box only the connector space and metaverse object ids are configured to flow. No schema attribute flows are pre-configured. I don't have a problem with this, but it does need to be documented better. What specifically needs to be documented is the minimum set of attributes and flow direction(s) needed for each object type you intend to use (user, group, etc.) As of RC0, if certain attributes are not included in the synchronization (like domain or user objects), the ILM service will become unstable and crash. Granted that this will likely be corrected prior to release, but it would certainly help if what the internal requirements of what the ILM Service expects in terms of attribute values where documented, it would help. In a perfect world for me, all the attribute flows would be preconfigured for all objects shared between the portal and the metaverse schemas. My rationale for this statement is: Since there is a default schema defined in the portal and there is a default schema in the metaverse, these two schemas should be configured to work together out of the box. The portal and the metaverse are supposed to be viewed as one, so any necessary (internal) synchronization configuration should make this so out of the box. Any real implementation would involve tailoring the schemas to the specific business needs and such tailoring would include updating the portal schema, the metaverse schema, and the internal synchronization rules between the two. I argue that the synchronization rules for the initial state should be consistent with the provided schemas. Note that not only the synchronization rules need to be configured (or at least documented), in addition, the object deletion rules and attribute flow precedence also should have proper initial settings (or at least documentation around it.)