Moving from ILM to FIM, general architecture question
What are your experiences or thoughts on upgrading from ILM to FIM? Did you build a new design in FIM and then turn off ILM, or did you swing the database over and upgrade it, installing FIM on top of it? I have begun playing with FIM 2010 in my lab/R&D environment, and successfully tested the procedure to upgrade the existing ILM database. All of my provisioning and rules extensions came over and thus far seem to work okay without having been recompiled to x64, with the one notable exception of Windows Live ID MAv2 which isn't supported on that platform. As I have begun playing with some of the new features in FIM, such as creating a group in the portal, I realize there are going to be a lot of conflicts with my existing provisioning code. The old design only created security groups, and when I created a distribution group in the portal I got it to project into the metaverse and then of course it was actually created as a security group. I know how to fix it, but it occurs to me there are a lot of other custom rules and provisioning code pieces that are not going to play nice with FIM without a lot of tweaking and redesign. I haven't even gotten to the sync rules created within the portal and all the other codeless provisioning stuff. I can only assume at this point there will be more collisions with the "classic" rules and code. Rebuilding my design from scratch in an unfamiliar environment seems daunting, however. Anyway, I thought I'd post and get some high-level feedback from others who faced the same decision of an "upgrade" versus a "build from scratch" approach. I felt I had a pretty good handle on most of the nuances of ILM, but outside of the sync engine parts that work as they always have, FIM is still unfamiliar and I don't have a good feel for how the new parts interoperate with the old.
November 18th, 2010 12:00pm

Hi Chris. I'm not surprised that you've not had a reply to this thread before now, and I believe that is mainly because there is very little anecdotal evidence supporting either of the 2 options you suggest. However I will start with my own personal opinion - not based on experience with such an upgrade, but experience in working extensively with MIIS/ILM, and almost exclusively on FIM 2010 in the last 18 months. Before doing so I must point out that my opinion is based on relatively recent experience of scenarios where the FIM Sync Service does NOT behave the same way as the ILM 2007 FP1 service (or MIIS before that ... but I will refer to both as simply ILM). These include: Unlike ILM where a good design (one built on best practice principles such as breadcrumbing, and NEVER selecting the "do not recall values from metaverse" checkbox!!!) would allow you to confidently delete the entire metaverse and reload it from each connected directory, the same cannot be said of FIM (i.e. with FIM the metaverse is almost guaranteed to contain information that cannot be recovered in the same way, especially where the FIM MA has contributed values); Equal Precedence ... a concept introduced with FIM, and definitely not to be confused with the ILM idea of manual precedence ... is something that you will MORE THAN LIKELY be unable to avoid incorporating into your design in SOME WAY ONCE YOU INTRODUCE THE FIM PORTAL in order to import existing account/group data into the FIM portal. By doing so you will come across many of the nuances that have been discussed recently at length on this forum ... and thereby forcing changes to the original ILM2007 design. Full Import / Full Sync ... unlike ILM where the order for running these to "re-baseline" the metaverse with each CS was largely irrelevant (i.e. reloading with all MAs is followed by a full reload in reverse sequence would have no net affect), the same cannot be said of FIM. There are more considerations, but the above would be enough (I would suggest) to advise the most expedient option would be to Determine exactly what value you want to add to your environment by implementing FIM (group management, pwd self service, etc.) and devise a phased implementation approach Design an initial FIM installation to complement what you already have, without changing the current design of your existing ILM implementation build a greenfields FIM 2010 implementation and run it in parallel with your existing ILM2007 service upgrade your existing ILM service to the FIM2010 sync service = but DO NOT ADD THE FIM MA ... then fully regression test to ensure the above considerations do not adversely impact your design ... then do not plan to change this your "legacy" FIM sync service in any significant way look to progressively migrate each MA from your legacy instance to your new one ... on an AS NEEDED basis (e.g. to take advantage of declarative provisioning) either ultimately retire your legacy solution ... or maintain it where there is no value in migrating some functionality The above cannot be supported by anecdotal evidence at this point, but should provide some food for further discussion.Bob Bradley, www.unifysolutions.net (FIMBob?)
Free Windows Admin Tool Kit Click here and download it now
December 25th, 2010 11:52pm

Hi Chris. I'm not surprised that you've not had a reply to this thread before now, and I believe that is mainly because there is very little anecdotal evidence supporting either of the 2 options you suggest. However I will start with my own personal opinion - not based on experience with such an upgrade, but experience in working extensively with MIIS/ILM, and almost exclusively on FIM 2010 in the last 18 months. Before doing so I must point out that my opinion is based on relatively recent experience of scenarios where the FIM Sync Service does NOT behave the same way as the ILM 2007 FP1 service (or MIIS before that ... but I will refer to both as simply ILM). These include: Unlike ILM where a good design (one built on best practice principles such as breadcrumbing, and NEVER selecting the "do not recall values from metaverse" checkbox!!!) would allow you to confidently delete the entire metaverse and reload it from each connected directory, the same cannot be said of FIM (i.e. with FIM the metaverse is almost guaranteed to contain information that cannot be recovered in the same way, especially where the FIM MA has contributed values); Equal Precedence ... a concept introduced with FIM, and definitely not to be confused with the ILM idea of manual precedence ... is something that you will MORE THAN LIKELY be unable to avoid incorporating into your design in SOME WAY ONCE YOU INTRODUCE THE FIM PORTAL in order to import existing account/group data into the FIM portal. By doing so you will come across many of the nuances that have been discussed recently at length on this forum (most of which are being addressed where necessary in successive hotfixes) ... and thereby forcing changes to the original ILM2007 design. Full Import / Full Sync ... unlike ILM where the order for running these to "re-baseline" the metaverse with each CS was largely irrelevant (i.e. reloading with all MAs is followed by a full reload in reverse sequence would have no net affect), the same cannot be said of FIM. There are more considerations, but the above would be enough (I would suggest) to advise the most expedient option would be to Determine exactly what value you want to add to your environment by implementing FIM (group management, pwd self service, etc.) and devise a phased implementation approach Design an initial FIM installation to complement what you already have, without changing the current design of your existing ILM implementation build a greenfields FIM 2010 implementation and run it in parallel with your existing ILM2007 service upgrade your existing ILM service to the FIM2010 sync service = but DO NOT ADD THE FIM MA ... then fully regression test to ensure the above considerations do not adversely impact your design ... then do not plan to change this your "legacy" FIM sync service in any significant way - except perhaps to take advantage of a feature such as this for managing OUs look to progressively migrate each MA from your legacy instance to your new one ... on an AS NEEDED basis (e.g. to take advantage of declarative provisioning) either ultimately retire your legacy solution ... or maintain it where there is no value in migrating some functionality The above cannot be supported by anecdotal evidence at this point, but should provide some food for further discussion. Bob Bradley, www.unifysolutions.net (FIMBob?)
December 25th, 2010 11:53pm

Hi Chris. I'm not surprised that you've not had a reply to this thread before now, and I believe that is mainly because there is very little anecdotal evidence supporting either of the 2 options you suggest. However I will start with my own personal opinion - not based on experience with such an upgrade, but experience in working extensively with MIIS/ILM, and almost exclusively on FIM 2010 in the last 18 months. Before doing so I must point out that my opinion is based on relatively recent experience of scenarios where the FIM Sync Service does NOT behave the same way as the ILM 2007 FP1 service (or MIIS before that ... but I will refer to both as simply ILM). These include: Unlike ILM where a good design (one built on best practice principles such as breadcrumbing, and NEVER selecting the "do not recall values from metaverse" checkbox!!!) would allow you to confidently delete the entire metaverse and reload it from each connected directory, the same cannot be said of FIM (i.e. with FIM the metaverse is almost guaranteed to contain information that cannot be recovered in the same way, especially where the FIM MA has contributed values); Equal Precedence ... a concept introduced with FIM, and definitely not to be confused with the ILM idea of manual precedence ... is something that you will MORE THAN LIKELY be unable to avoid incorporating into your design in SOME WAY ONCE YOU INTRODUCE THE FIM PORTAL in order to import existing account/group data into the FIM portal. By doing so you will come across many of the nuances that have been discussed recently at length on this forum (most of which are being addressed where necessary in successive hotfixes) ... and thereby forcing changes to the original ILM2007 design. Full Import / Full Sync ... unlike ILM where the order for running these to "re-baseline" the metaverse with each CS was largely irrelevant (i.e. reloading with all MAs is followed by a full reload in reverse sequence would have no net affect), the same cannot be said of FIM. There are more considerations, but the above would be enough (I would suggest) to advise the most expedient option would be to Determine exactly what value you want to add to your environment by implementing FIM (group management, pwd self service, etc.) and devise a phased implementation approach Design an initial FIM installation to complement what you already have, without changing the current design of your existing ILM implementation build a greenfields FIM 2010 implementation and run it in parallel with your existing ILM2007 service upgrade your existing ILM service to the FIM2010 sync service = but DO NOT ADD THE FIM MA ... then fully regression test to ensure the above considerations do not adversely impact your design ... then do not plan to change this your "legacy" FIM sync service in any significant way - except perhaps to take advantage of a feature such as this for managing OUs look to progressively migrate each MA from your legacy instance to your new one ... on an AS NEEDED basis (e.g. to take advantage of declarative provisioning) either ultimately retire your legacy solution ... or maintain it where there is no value in migrating some functionality The above cannot be supported by anecdotal evidence at this point, but should provide some food for further discussion. Bob Bradley, www.unifysolutions.net (FIMBob?)
Free Windows Admin Tool Kit Click here and download it now
December 25th, 2010 11:53pm

This is very good information, FIMBob. I belief, it is important to highlight that FIM is a bit more than just ILM + something. As Chris has already mentioned, "there are going to be a lot of conflicts with my existing provisioning code". Although, there is still the same synchronization engine, FIM implements a different approach to manage identity data. I belief, it might be helpful to take a look at Understanding Data Synchronization with External Systems and Designing Business Policy Rules. Personally, I belief, a redesign is in most cases better than an in-place upgrade. Cheers, MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation
January 11th, 2011 3:43pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics