FIM supports both declarative (i.e. based on synchronization rules) and non-declarative (ILM-style) provisioning.Having never worked with ILM, the role of non-declarativeprovisioning is not very clear to me; I would like to use this discussion thread to gather questions and remarks about the topic.In particular:- With the exception of the FIM Management Agent, where it is necessary, is non-declarative provisioning present in FIM only for backward compatibility/configuration migration reasons?- Does non-declarative provisioning offer some advantages over declarative provisioning, like higher performance, higher flexibility? Paolo Tedesco - http://cern.ch/idm

I’m starting with two reasons for non-declarative provisioning: Backward compatibility - A deployed ILM environment is an investment and migrating a non-declarative into declarative implementation is a cost factor Declarative Provisioning Limitations - Declarative Provisioning is a V1 implementation. There are scenarios that are difficult (if not impossible) to handled with declarative provisioning The rule of a thumb recommendation is in my opinion to use a declarative implementation whenever possible.At the beginning, declarative provisioning was known as "codeless provisioning".While this is true, just the fact that you don't have to write code to manage the lifecycle of your objects is like calling a Porsche a car... The declarative way has much more to offer. First of all, declarative provisioning is a complete different approach.You don't tie your object and attribute management based decisions just on the values of your attributes anymore. Especially, the outbound part is integrated into the (management) policy based approach to manage your environment.This means, you define a provisioning policy that consists of a Set, a workflow, the management policy rule and the synchronization rule.As such, provisioning is just "one piece of the puzzle". Another positive side effect is readability and managebility.If you look at the FIM ScriptBox, you find scripts to document your configuration and also scripts to troubleshoot it.This is with non-declarative provisioning pretty much impossible.In case of a problem, you had to share your provisioning code with others to get help.The readability of an implementation is directly tied to the ability of the programmer to write structured code... The concept of DRLs and ERLs enables you to track the state of your environment throughout an object's lifecycle - there is non need to parse through custom log files.Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation