Ideas
Identity Broker for FIM/ILM default run profiles to be deprecated by Microsoft due to stopped-server errors
The default run profiles installed when you deploy an instance of any Identity Broker 3.* MA for FIM include combined "single step" run profiles as has been "best practice" dating back to MIIS days (see http://social.technet.microsoft.com/wiki/contents/articles/1147.aspx#Single_step_vs_multistep).
However, advice from Jeff Nelson recently after explaining anecdotal evidence of "stopped-server" problems experienced @ DEEWR, is that the Microsoft FIM Product Group is planning to deprecate support for this model entirely in favour of combined "multi step" run profiles. I spoke directly to Andreas Kjellman (MS Sync engine product lead) last month and he backed this up ... the bugs that they are now aware of with this style of run profile are "too much to even try fixing", and so they're going to remove support for them. They claim that they are the main cause of the stopped-server errors @ DEEWR, and I can vouch for this with my own experience, particularly with the FIM MA.
While the above sounds very much like a cop-out, there is certainly pros and cons of both approaches. The very BIG downside of losing the single step model entirely is the corresponding additional overhead that will be incurred in any CS where there is a large number of disconnectors (since a single step model was the only way until now of avoiding repeated reprocessing of these disconnectors with every DI/DS). Now we have to live with this overhead, it will become beholdent on FIM solution designers to minimise the number of disconnectors, which in itself is already an established best practice anyhow.
Needless to say, with this in mind, and the increasing likelihood of UNIFY PS staff running into the same error themselves, it would be a good idea to change the default run profile definitions installed by the Identity Broker MA wizard assp.
On the subject of this same error, there are many potential causes, and this is only one of them. Another is trying to run ANY OTHER RUN PROFILE while a FIM MA run profile is already executing - this will almost always cause the FIM MA run profile to fail!
In the meantime I have already ensured that I have manually changed all FIM run profiles to adapt to this new multi-step standard.
Customer support service by UserEcho
Hi Bob,
Thank you for the heads up. I've spoken with Matt and Adam and the current expectation is as follows:
Does that sound reasonable?
Fine with me thanks Patrick
Matthew Clark could you please comment on the importance and difficulty of this change?
I haven't seen a proper roadmap for FIM but if it is being deprecated at some point then we'll need to account for it - http://technet.microsoft.com/en-us/library/jj879229(v=ws.10).aspx says that these will be deprecated (but then also says that the combined run profiles should be kept in large enviornments, so...). As of 4.1.3451.1, combined run profiles are still present.
What needs to happen is the XML for the packaged MA needs to be updated to contain run profile definitions that contain two step profiles - full import/full sync, delta import/delta sync. Add these to a management agent manually then Export the management agent to see what this XML should look like.
What also needs to be noted as this significantly ups the processing time of the import process. A combined run profile runs a full import and applies full synchronization rules to each object in the import as it comes in, but a two step runs an import to bring the objects in, and then applies a full sync to all objects. The delta import/delta sync is where the biggest hit happens, as you may only pull in one new object in your delta import, but a delta sync will then apply to all disconnected or changed objects in the connector space (could be multiple thousand).
Best diplomatic way forward would be to retain the combined run profiles but to also add "Two Step" run profiles to the packed MA definition.
If we don't add these to the defaults, what can still be done is that people can manually add the two step run profiles as they do with all other non-IdB management agent types (AD, Lotus, SQL Server etc.) - IdB's packaged MA includes these as a convenience.
Matthew Clark - word from the MS product group is that there are "too many problems to fix" with the combined run profiles, so rather than continue to try to fix them they are deprecating them![]()
. This has to do with the CS processing algorithm having changed significantly in recent years, presumably with the advent of declarative rules (extra processing cycles required per sync). I would vote for the idea of having both combined and separate ones due to the potential performance hit you speak of (I am seeing this right now at CSODBB where I have already over-ridden most of the defaults) - because this puts the onus back on the implementer and doesn't give them a reason to blame Event Broker for encouraging the use of "legacy" methods. The main problem seems to be running combined run profiles for the FIM MA or ECMAs - the AD MA doesn't seem to be as flaky for example.
Resolved. Tony Sheehy, could you please confirm that it works for you also?
Thanks.