Here’s my scenario:
The groups at my work are currently all populated manually in AD. We did discuss the steps needed to move some of the groups into a SQL table where they could be populated using query statements, but we never did get around to it. So I know that the group management capabilities of the ILM 2 Portal are going to be very well received.
ILM MA Export flow rules
I posted last week about doing an intial import of AD groups into ILM, and I’m going to continue on from that point now.
The following table shows the flow rules I set up in my ILM MA that allowed me to import all the information I needed about my groups (both Security and Distribution) into the ILM database. Note that they are all EXPORT flow rules because I’m exporting out of the metaverse.
I had to fabricate values for some of the attributes. While you can actually do the import without such attributes as Owner and MembershipAddWorkflow, you find that you are expected to set values for them when you first edit the group in the Portal. It seemed simpler to flow some sort of intial value into these fields.
| Data Source Attribute | Metaverse Attribute | Comments |
| Description | description | From description in AD |
| DisplayName | displayName | From displayName in AD |
| From mail in AD | ||
| Type | type | Calculated from groupType – see here |
| Scope | scope | Calculated from groupType – see here |
| Domain | domain | NETBIOS domain name flowed in as a constant from AD MA |
| MembershipAddWorkflow | membershipAddWorkflow | “Owner Approval” or “None” – flow constant value from AD MA (None) |
| MembershipLocked | membershipLocked | “true” or “false” – flow constant value from AD MA (false) |
| Member | member | From member in AD |
| MailNickname | mailNickname | From mailNickname in AD |
| Owner | owner-stringDN | I created this metaverse attribute and then flowed the GUID of ILM Portal’s Administrator account as a constant value from the AD MA. You can find this by searching the metaverse for “Administrator” and then using the csObjectID value. |
| DisplayedOwner | owner-stringDN | As above |
Changing a group to Calculated Membership
What I am most interested in at this point is reconfiguring a number of our Distribution Lists that should have a calculated, rather than a manually assigned, membership. As an example I’ll use the group that represents all engineers in the Geneva office.
I should add that I have already imported all the information about my users into Person objects in the ILM db.
The first thing I do is to locate the group under Distribution Lists in the Portal, and change the member selection from “Named” to “Calculated”. This is going to delete the existing members – but only from the ILM db so far.
Â
Next I set the membership select rule. This is nicely intuitive and I think a picture will suffice as explanation.
Â
I can click on the View Members button to see a list of the members inserted by this rule. If it all looks good then I save and submit my changes.
Note that if you set the MembershipAddWorkflow attribute to “Owner Approval” you will need to go through an extra step here to approve the change. See the “Approve Requests” page in the Portal.
Making ILM Authoritative
When I get round to implementing this in production, I will do a one-time import of group data from AD and then switch the master data source to being the ILM Portal. To achieve this I will reverse the direction of the flow rules I created in the ILM MA above, and I will also set the attribute flow precendence in the Metaverse Designer to ensure that changes made in the ILM Portal will make their way through to AD.
What if a group needs to be calculated and manually updated?
This is an old question – what do you do if you want to put all the engineers in a group, but you also want to manually add a couple of other people who wish to see the same emails? And actually ILM2 doesn’t change what the answer to this has been all along: Use nested groups.
So I make my DL Engineer GE group contain two groups: DL Engineer GE Calculated and DL Engineer GE Manual. I can then managed the memberships of these two subgroups through the portal, with the first being “Calculated” and the second being “Named”.
