At first, let me apologize if I'm asking about obvious things! I'm trying to recreate a rule we used to have in our old identity integration solution and I'm stumped. We have an HR (well, sort of) database, in SQL 2005. We also have a single AD, the DC's are all Win 2008 or 2008R2. We're a corporation, about 15 companies with about 120 departments in total. We use a lot of AD security groups to control access to various resources. There's a group naming structure like this (simplified): <employeetype> (corporation level, one group for all managers in the entire corporation, one for all clerks etc.) <employeetype n1 + n2 + ...> (corporation level, these are groups that contains members from several employee types, like "administrative employees", containing users with the employee type "manager", "clerk", "administrator" and so forth> <company>_<employeetype> (company level) <company>_<employeetype n1 + n2 + ...> <company>_<department>_<employeetype> (department level) <company>_<department>_<employeetype n1 + n2 + ...> So if you're a manager in company x, department y, you'd be in the managers and in the administrative employees groups at both the corporation, company and department level. The AD is structured like this: <corporation> (=domain) <company a> <department a> <employees> <department b> <employees> <company b> <department a> <employees> <department b> <employees> In our old HR->AD integration solution (non MS) this was all dealt with in just one rule (with a few steps). The rule first looked at a user's company, department and employee type in the HR database. It also had a list of the "n1 + n2 + .." group types (not the actual groups). Using simple concatenation, it then decided the name and OU for each group for that user. It then checked if each group existed. If so, it added the user as a member. If not, it first created the group in AD, then added the user as a member, moving on to the next group. I'm simplifying a lot, but this was basically it. At first, sets with attribute calculated memberships seemed like the FIM way to do it, but we're talking about almost a thousand groups here and having to create that many sets manually seems daunting. And if I'd need just as many MPR's and workflows, well, phew! Hopefully, I'm overlooking something obvious? Or will I have to resort to ILM style coding for these groups? Thanks! /Jonas

I would be tempted to do that with a regular SQL multivalue MA. You could probably come up with a fairly straightforward SQL query to generate the tables. This would definitely work for your AD groups. I'm not sure if Sets can be exported to the Portal... haven't tried that yet but it may work. http://www.wapshere.com/missmiis

I would be tempted to do that with a regular SQL multivalue MA. You could probably come up with a fairly straightforward SQL query to generate the tables. This would definitely work for your AD groups. I'm not sure if Sets can be exported to the Portal... haven't tried that yet but it may work. http://www.wapshere.com/missmiis Thanks a lot Carol! Yes, it would be easy to use SQL to produce a multivalued table to handle this. (I've read your very informative blog posts about this BTW, very good stuff, thank you!) But as a developer, I really don't like to implement business rules in the data layer. It's messy even when it's easy. Like whenever I add datasources (which I will in just a few weeks), I'm gonna have to implement the same rules again for them. Now if - more like when! - the rules change, I'm gonna have to change the implementation in several places. It also seems pretty clear that the "FIM way" is to keep your business rules firmly in the portal, so I was hoping there would be another way. To be blunt, FIM does seem to be a bit immature though, so unless anyone else comes up with a clean, simple and "fimmy" method, I'll take your advice.

Back when it was still ILM "2" I saw a demo of a custom workflow that would generate groups for new departments. As I remember it, the workflow triggered everytime the Department attribute was newly populated for a person, checked to see if a group already existed for that department, and went ahead and created it if not. Unfortunately I don't believe the code was ever posted anywhere public. Something like that is probably the "FIM way" but, like you say, the portal is brand new and these sorts of things are still difficult to achieve.http://www.wapshere.com/missmiis