13 июня 2012 г. 20:27I have seen several post on group membership with FIM. Most of them that I have found reference using the Portal or ILM 2007. I can get the groups imported into FIM with no problem. I am trying to find a reference that gives ideas on how to do this with a C# rules extension and without the FIM Portal.
- Изменен тип mario.exe 14 июня 2012 г. 20:53
13 июня 2012 г. 22:56
Simple example of such solution is group populator - http://crosbysite.blogspot.com/2008/02/using-group-populator-application-with.html, http://social.technet.microsoft.com/Forums/en-US/ilm2/thread/0a7ae6d0-d15e-4e60-996d-d4b1f61896ab
Basically You need an external data source (DB for example) which will provide information on group membership to be used as references in attribute flows. What FIM portal is giving You is exactly this - a data source on group membership.
It is fairly easy to be configured in simple scenarios if You will play around with FIM synch a bit. Also You will have to replace FIM Synchronization rules with your custom provisioning code to handle group creation \ deletion.
I've just finished that kind of engagement, but actually ... customer has changed his mind for FIM Portal and using new FIM services. Maybe I just did a lousy job on implementing the first solution without it ;) (but I don't think so :) ).
14 июня 2012 г. 0:48What exactly are you trying to do in terms of group membership management? You should be able to just import/export the group membership as-is from AD -> metaverse etc, but playing with the 'members' attribute of groups through rules extensions from what I remember isn't possible with the current version of FIM. If you try, you'll get an error about "Defining a rules extension import attribute flow to a metaverse reference attribute is not allowed". We ended up using the Portal for this very reason, even though it adds a whole new layer of complexity to a FIM environment.
14 июня 2012 г. 4:12Yeah I was wanting add and remove users from the group based on an attribute. It appears the majority is doing this through the Portal, and some people are using the group populator. I really just wanted to s ee what most of you guys are using out there really.
14 июня 2012 г. 18:39
The impression I've gotten (mostly from what I've read in the forum over the past couple of years, but also based on what I've learned about the product and how it might be deployed in my own environment) is that those that have licensed and installed the FIM Service/Portal are primarily using the portal to do attribute-based group membership changes. This is especially true for those that were starting from scratch with FIM, since it doesn't need a lot of customization to make that part work decently.
Those that are doing a group-populator-style MA were probably using it with MIIS/ILM and the task of converting it to FIM Portal rules was too difficult or disruptive to be done during the upgrade/migration process. Either that or the customer didn't want to put up the money for the FIM Portal CALs.
In my own current FIM upgrade project, we are not planning on implementing the Portal initially and will only use the sync engine. Therefore, the group management solution I came up with (very limited and based on attribute data) for ILM will be transitioned directly to FIM 2010. What I came up with was heavily based on Carol Wapshere's blog, with some extra stored procedures I call from my provisioning script to actually create the group-member associations in the multivalue table. At some point we may convert to using the Portal, either because the logic is changing significantly or, more likely, because of a desire to have approval workflows for non-attribute-based-group membership changes which the current design does not allow for.
14 июня 2012 г. 20:55Thanks for all the input!!!