This week, I am going to look at the advantages and dis-advantages of each of these types of provisioning within FIM 2010.
What is declarative provisioning?
Declarative provisioning was introduced in FIM 2010 to allow users who would have come from a systems background, implement a code-less provisioning solution. The new concepts within FIM made it easy for anyone with a non-coding background to implement a IDM solution. These involved creating FIM objects called “Synchronization Rules” which sat on top of a Management Agent. Once you required a new user to be created in a connected system, you applied a pre-defined synchronization rule to their user object and this was then used by the Management Agent to create that user in that connected system. No code is required with this approach.
What is Classic provisioning?
Classic provisioning came from FIM 2010’s predecessor, ILM 2007. This type of provisioning required the FIM consultant to be able to write .NET code. This limited and caused problems for consultants who came from a systems/AD background. Provisioning code sat in the Synchronization service and was applied to each object each time a data synchronization was run against that object. The code sat in the Metaverse extension, and classic provisioning did just work in general.
The problems (with declarative provisioning)
Initially when implementing FIM 2010, like most people, we tried our hand at the new “Declarative Provisioning” using synchronization rules. At first in a simple system, this method worked well. It took away the need to write code to carry out provisioning, and we thought, “WOW, Microsoft have just made FIM 100 times easier to implement”. This thought was short lived.
After a few projects, we realized that declarative provisioning did not live up to making life easy. System performance is hugely affected when using declarative provisioning.
Take 100,000 users in FIM connected to 5 systems.
Classic Provisioning we have 100,000 objects in FIM
Declarative provisioning we need at least 600,000 objects in FIM (100,000 users and 500,000 EREs)
An “ERE” is an expected rule entry. These are created when using declarative provisioning to tell the synchronization service that this exact user needs to go to this system. Each user has 1 ERE per system. This is a massive data overload if you have a big FIM implementation.
Another FIM feature you might use in the declarative world are DREs . Detected Rules entries confirm that a user/group/whatever has been created on the end system that the ERE has asked it to be created on. Add another 500,000 DREs in there if you turn this feature on. Again this brings our declarative solution up to 1,100,000 objects to be synchronized every time you run a full sync of the system.
I can only ever see problems with Declarative provisioning. Everything is so much slower, and cleaning down the system, initially loading the system is so much more pain, making sure the correct synchronization rules are applied to all current users who should get them, and you EREs all over the place. If the user objects are deleted within FIM you could be left with thousands of “orphan” EREs which will sit in error state. In my eyes they make larger FIM installations Unclean.
I am currently facing a problem with an old installation where a connector space has become corrupted. Instead of creating a new management agent, and re syncing the system, I have to create the new MA, create a new sync rule, remove all EREs for the corrupted MA sync, reapply EREs for new MA sync rule, the thought of doing this is a nightmare! (although I might just implement a coded solution to make things easier going forward)
The difference, the problems (with Classic provisioning)
With classic provisioning there are no problems.What you code is what you get. I am a coder, so yes its easy for me. BUT, what if I was not a coder? Now there are problems and to be honest, these are the only problems.
Basically, if you have the ability to write code, use classic provisioning. If not, then declarative will work, don’t get me wrong, it does work and it is simple to implement with basic training. You will just come across scenarios where it will become messy and will make your life hard, but learning to code will also make your life hard.
So the outcome on this argument depends on who you are and what your skillset is 🙂
Forefront Identity Manager 2010 Consultants Ireland 