This post assumes you already have FIM installed, and have created the FIM Management Agent.

Create the HR Management Agent

The aim is to create a management agent for your HR data source. In this example I’m using a SQL database, but it could equally be CSV, SAP, Oracle or something else. The product Help tells you how to configure the prerequisites for each of these MA types.
We’re going to use a codeless sync rule to import data, so we don’t need a join or projection rule here.If you’re not using the Portal,you will need to configure this tab – see Creating and Management Agent
If using codeless sync you can also leave the flow rules blank for now, though you may find you need to revisit this tab if you want to created Advnaced flow rules that aren’t currently possible with codeless. Note that it’s fine to use a combination of codeless and coded rules. See Advance Attribute Flow Rules.

Create the Import Sync Rule

Now go into the Portal and open the Synchronization Rules page from under the Administration menu.Create a new Inbound Sync Rule.
The rule matches an external object type with a Metaverse object type, via the selected MA.
On this page we specify how to identify that an object in the external system matches an object in the Metaverse. In this case we’ll use the employeeID, which we will also be flowing from this source.Note I’ve also ticked “Create resource in FIM” which will cause an object to be automatically provisioned into the connector space of the FIM MA, ready to export to the FIM Portal.
Finally we specify our import flow rules, which should be pretty self-explanatory. It’s a good idea to make use of functions such as Trim and ProperCase to make sure that your data comes into the Metaverse in a fairly consistent state. Also be very sure to flow in the identifying attribute you specified in the form above!
If you need extra Metaverse attributes to import your data to then you will have to go back to the Synchronization Service GUI and modify the Metaverse schema.

Configure the Metaverse -> Portal Flows

This is where it gets a bit odd. We’ve created HR -> Metaverse flow rules using a codeless Sync Rule created in the Portal, but to get the data from the Metaverse into the Portal iteslf we actually have to use old-style MA rules.In The Synchronization Service GUI, open the properties of the FIM MA and open the Configure Attribute Flow page.
Add the Export flow rules that will copy data from the Metaverse to the Portal.If you need extra attributes in the Portal for your HR data then see then see this document on the Portal schema. You will need to refresh the schema on the MA, and select the new attributes in the Attributes tab before they will be available for the flow rules.
To avoid permissions problems when your export data to the Portal, check the MPR “Synchronization: Synchronization controls users it synchronizes” and make sure that the account used by the Sync Service has the rights to update all required attributes. It’s easy to just give the Sync Service rights to all user attributes in this MPR, but it depends on your requirements and security rules whether you’d do this.

Create the Run Profiles

Create Import and Sync run profiles for the HR MA. Here I’ve created a single-step “Full Import and Full Sync” run profile.
For the FIM MA I need Import/Sync and Export run profiles.

Finally – Make something happen!

The first job you need to run is the Import/Sync on the FIM MA. In a freshly installed system you should see three objects being projected into the Metaverse. Inspecting these objects shows them to be the Administrator user, the Built-In Synchronization user, and the HR Import Sync Rule we created above.
Now you can Import/Sync the HR MA. You should see objects being projected into the metaverse, and also provisioned as Adds into the FIM MA. If you inspect some of these objects in the Metaverse you should see them populated with attributes from the HR data source.
Finally you are ready to export your HR data to the Portal.Various errors can happen here, and they will mostly be connected to Portal schema (particularly check the Validation tabs in both attribute and binding definitions) or Portal permissions (check MPRs that apply to the Built-In Synchronization accout). But if you see nice “Adds” counting up here then things are good, and you’ll find users defined in the Portal. It may not be quick though – the first load of data into the Portal is not the most performant part of this platform.

When you first run the Synchronization Service you will see pretty much exactly the same thing that users of ILM 2007 and MIIS 2003 will be very familiar with. In fact, to learn about this interface the ILM and MIIS documentation will still be accurate.
One of your first tasks here is to create the FIM Management Agent.On the Management Agent tab click Create and then select the “FIM Service Management Agent” type from the dropdown.
This was pretty easy for me because everything was on the localhost. Otherwise the “Server” is the SQL server name, and the “FIM Service base address” should reference the sharepoint server.The service account is a regular domain account with no special permissions.
I’m planning on managing users so I also select the “Person” object type here. You can come back to this screen any time later to select other object types, including new ones you create in the Portal.
By default all attributes are selected so there’s nothing to do here. Again, you will revisit this page later if you need to synchronize new attributes that you’ve added to the Portal schema.
Here you can block certain objects from being synchronized by the Sync Service. In this example I am blocking the two built-in Portal accounts.
On this page you map the Portal object type to an object type in the Metaverse. See the Metaverse Designer tab in the Sync Service GUI for the configuration of the metaverse schema.
Initially just accept the default attribute flows here. You will be back to this page before long, selecting the attributes you want to appear in the Portal.
Accept the default for now.
Again there should be nothing to configure on this page – just click Finish.
The MA is now created. Your final step is to create Run Profiles, which will actually make the MA do something.My typical list is pictured here – Import, Sync, Full Import and Full Sync, Delta Import and Delta Sync, and Export. Note I also have “Export 1″ which is a restricted export that is useful while testing. For more info about Run Profiles see this post.

What next? We need to get some data into the system – and my next post will cover importing HR data into the Portal.

Update 15/06/2011

Recently I had some trouble modifying the FIM MA on version 4.0.3573.2. The error was “Failed to connect to the specified database with the given credentials”. For some reason it was trying to connect to the FIMService database using the Sync service account instead of the FIM MA service account. We gave the Sync service account db_owner rights to the FIMService database and the problem went away.

I also had some problems trying to use a remote portal address in place of localhost. The error was “Failed to retrieve the schema. Failed to connect to the specified database or Forefront Identity Management Service. Please check the specified database location, service host address, and acount information.” This turned out to be due to proxy settings. We had to login to the server using the FIM Sync account (again FIM Sync, not FIM MA) and disable the proxy in IE.

To kick things off by starting at the beginning – Installation.

Planning

FIM Components

When you first run the FIM setup program, you will see a screen with a number of different components to install. For an initial identity management installation you will want to install the Synchronization Service and the Service and Portal.

Following are the major requirements for these components. For a full list see Technet: Hardware and Software Requirements.

1. Synchronization Service
   • Windows Server 2008/2008r2 Standard x64
   • SQL Server 2008 SP1
     • Database Engine
2. Service and Portal (which includes Workflows, Codeless Sync Rules and Password Reset)
   • Windows Server 2008/2008r2 Standard x64
   • SQL Server 2008 SP1
     • Database Engine
     • Full-text Indexing
   • Windows Sharepoint Service 3.0
   • Exchange 2007/2010 (see Brad Turner’s post on the subject if you don’t have Exchange, or mine if you have BPOS.)

Servers

If you’re just planning a test environment then the simplest thing is to install everything on the one server. I wouldn’t do it with any less than 4GB of RAM, though 8GB is better. I have run FIM 2010 on virtual machines, both ESX and Hyper-V.

The Preinstallation and Topoloy Configuration document will give you more information if you want to install some components on different servers, or use load-balancing or redundancy features.

Installation

In this example I’m going to show you how to install The Sync Service and the Portal on a single server. For detailed instructions see the official documentation.

Server Config

The server is called “FIM”, has 4GB of RAM and is a member of the domain “mydomain.local” which also includes an Exchange 2007 server. I’ve installed the following:

• Windows 2008 Standard x64
• SQL 2008 SP1
• WSS 3.0 (and I’ve run the Sharepoint Products and Technologies Configuration Wizard from the Administrative Tools menu)
• Exchange 2007 management tools

Service Accounts

First, create the service accounts in the domain. All accounts are regular users in the domain, and on the FIM server. Account for the FIM service Mail-enabled Account for the Sync Service Account for the FIM Management Agent, which will connect the Sync Service to the Portal.

Install the Sync Service

Now we’re ready to start installing. From the setup splash screen click Install Synchronization Service.
I’ve skipped the initial screens, which are click-Next types. The first one you have to think about is specifying your SQL server. Sometimes you’ll get an error here about the SQL server not being found. This is usually either because your SQL server is the wrong version (minimum 2008 SP1) or because you haven’t properly specified the named instance.
Specify the service account you created for the Sync Service.
The installation creates these local groups for you.It will make it easier to move the Sync Service to another server if you use domin groups.  To do this, create the equivalent domain groups yourself, and then specify them here in the format “domain\group”.
If you have the Windows Firewall enabled then you will need to tick this option.
You will now be prompted to save the keyset for the database. This is needed if you want to transfer to database to another server (it doesn’t actually encryt the database). You should save it somewhere you can find it again, though if the FIM server is available you can export the keyset again any time using miiskmu.exe. (Found in the Microsoft Forestfront Identity Manager/2010/Synchronization Service/bin folder.)The Sync Service should then install.

Install the FIM Service and Portal

Now go back to the splash screen and choose Install Service and Portal.You need to be a bit careful about the acount you use to do this part with, as it will become the builtin Administrator account in the Portal. One idea is to create a “FIM Administrator” account in the domain, make it a local and SQL administrator, and install using that. Click through the first screens. Typically you would just leave this as default settings, unless you were doing an installation split across different servers.
Enter the name of the SQL Server and “FIMService” for the database name. Now I’m just using the local server here, and this screen pre-configures itself with the netbios name of the server rather than “localhost”, so I just leave it that way. If you were using a remote SQL server you would enter the fqdn, or fqdn/NamedInstance.
Enter the name of your email server. Ideally this will be a self-hosted Exchange 2007/2010 server, though you can also use non-Exchange or MSOnline.
It should be fine to use the default here. The certificate is used for internal, and not client, communications.
Now specify the (mail-enabled) account you created for the FIM Service.
Next you specify the account you created for the FIM Management Agent.
Here I’m just using the server name again, but in a production environment I’d probably be specifying some sort of publically acceptable CName, like “identity.mydomain.local”. You can change it later or add extra names, though you have to be careful with the Kerberos stuff.
With the FIM Service running on the WSS server you just reference localhost.
You need to select the first option if you have Windows Firewall enabled. And you definitely need options two and three, otherwise you’ll just be configuring it manually later.
The installation should now complete. To check that it’s working browse http://fimserver/identitymanagement.

Here’s why I don’t like codeless sync rules (aka “Declarative Provisioning”):

• They don’t do everything you need,
• The whole Sync Rule – Workflow – MPR combination will get overly complex once you have a few different scenarios on the go,
• It’s difficult to troubleshoot,
• It adds extra objects (EREs and DREs) to slow down the sync – and the FIMMA is slow enough already,
• It requires CALs, which will put it out of the price range for a lot of people anyway.

There are already plenty of questions on the forum along the lines of ”How can I do x with codeless?” And more often than not the answer is “You can’t – but you can do it with a coded sync rule”. The fact is, to get the most out of this product you must, must, must learn about the ILM/MIIS ways of programming the Sync Service. And you may even find that it’s enough for your needs, and you can do without the CALs for now.

If you’d like to learn some more about traditional ILM methods then these posts are a good place to start: http://www.wapshere.com/missmiis/new-to-ilm-start-here

A Recap

So far on my list I had:

1. Use MVRouter to separate provisioning for different MAs.
2. A simple, and consistent, outline for the provisioning code.
3. Shift data generation away from advanced attribute flows and into SQL.
4. Remove complex join rules.

And now some more…

5. Minimise Metaverse Object Types

Organisations will commonly have different types of people – users, perhaps split into internal and external, customers, contractors… It may initially seem to be a good idea to create different metaverse object types for each one. Sometimes there are good and unavoidable reasons for using seperate metaverse object types, but I maintain that in the majority of cases it is better to call them all person, and then use their attributes to differentiate between them.

Newbie clarification: Just because they’re all one object type in the metaverse does not mean they have to be the the same object type in the connected directories. There is no problem with, for example, creating some as users and some as contacts, depending on their attributes.

There are all sorts of advantages to this approach:

• Metaverse searches are simpler (and remember, “simpler” means “easier to explain to other people so they can find what they need themselves and quit bugging you”).
• You can move more quickly when a new application comes along that needs a different combination of person types, perhaps even everyone in the system – one object type means one provisioning instruction and one set of flow rules.
• If there is any possibility of people switching from one type to another it will be very straight forward, with no need to delete and recreate objects.

6. Match Metaverse Attribute Names to CDS Attribute Names

When I first started with MIIS, it took me a while to figure out that it’s ok to delete the default metaverse attributes. Now I will habitually try to name metaverse attributes to match their primary source or primary destination attribute. A flow rule like this: staffnum -> staffnum -> employeeid is easier to remember than staffnum -> uid -> employeeid Once you have hundreds of flows like this you will be glad you went for some level of consistency (and so will the person who has to pick through the system after you’ve moved on).

7. Don’t use the default advanced flow rule names

I hate the default rule names and I always change them. The convention I use is “import_” or “export_” followed by the name of the attribute at the end of that import or export flow. import_displayName export_proxyAddresses These names are much easier to remember and to pick out in your code. It’s also pretty obvious what they’re for, and I like obvious!

8. Be consistent with your Run Profile names

I must admit it kind of bugs me when I see one MA with “Full Import and Full Syncchronization”, while another has “Full Imp/Full sync” and a third has “FIFS”. I don’t care what names you use – just make them the same across all MAs! Again it’s easier for others to understand, easier for you to remember, and much easier when automating your run profiles with scripts or using my ILM Scheduler service.

Always Keep It Simple, Stupid

That should really be my Rule Number One, but I’m still short one here. Once I think of something else I’ll make this list into a proper top ten.

Set up the ILM server

In addition to the usual ILM requirements, you will need to install the following on your ILM server:

1. Powershell
2. Exchange 2007 management tools

Configure the Exchange MA

Exchange mailboxes are provisioned using the regular AD management agent, with a couple of specific configurations.

1. You must tick Enable Exchange 2007 provisioning on the Extensions tab, and
2. You must have the following attributes selected on the Select Attributes tab:
   • homeMDB
   • mail
   • mailNickname
   • mDBUseDefaults
   • msExchMailboxSecurityDescriptor

Source Data

You must flow the mail address and the mail alias (the bit before the “@”) into the metaverse from somewhere.

I also find it simplest to flow in a value for homeMDB as well (and the provisioning code below assumes this to be the case).

The homeMDB is where you set the mail server and mail database for the user’s mailbox. It will look something like this:

CN=mail_db,CN=First Storage Group,CN=InformationStore,CN=server,CN=Servers,
CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,
CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=mydomain,DC=com

If you only  have one server and mail database then populating this attribute will be a simple matter of flowing in a constant value.

If you have multiple MDBs then you will have to decide how to populate homeMDB for different users. You might have a simple rule based on surname or employee number, or perhaps you could encorporate something like this powershell script to locate the smallest MDB.

Provisioning Code

The provisioning code is actually no different to Exchange 2003. Here is a code sample which creates the user and mailbox together.

Dim CSEntry As CSEntry = ExchangeUtils.CreateMailbox(MA, DN, _
                           mventry("mail").Value.Split(chr("@"))(0), _
                           mventry("homeMDB").Value)
CSEntry("unicodepwd").Values.Add(mventry("userPassword").Value)
CSEntry("description").Value = "Account created " + Today.ToString("d")
CSEntry("userAccountControl").IntegerValue = ADS_UF_NORMAL_ACCOUNT
CSEntry.CommitNewConnector()

Troubleshooting

Not exhaustive by any means - but here are a couple of errors I encountered during testing.

Export error 1

Error stopped-dll-exception on Export step, and
MIIServer event 6801 in the Application Event Log with the message:

"System.IO.FileNotFoundException: Could not load file or assembly
'System.Management.Automation, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The
system cannot find the file specified."

This happened when I deliberately tried an export before installing powershell and the Exchange management tools.

Export error 2

Error completed-export-error with ma-extension-error on the Export step, and
MIIServer event 6801 in the Application Event Log with the message:

 "Microsoft.MetadirectoryServices.ExtensionException: Unable to find
'192.168.126.150' computer information in domain controller '192.168.126.150:389'
to perform the suitability check. Verify the fully qualified domain name."

I was provisioning Exchange mailboxes to a different domain and, depsite having a secondary DNS domain configured in the local domain, ILM was defaulting to using the ip address of the foreign DC. I changed the MA configuration to force it to hardcode the DNS name of the DC (Configure Directory Partitions, Domain controller connection settings) and then it was fine.

I think this error has something to do with the Update-Recipient powershell component. I am guessing it gets the DC information from the MA and if, for some reason, the ip address is there instead of the domain name, the cmdlet fails.

Older versions of ILM/MIIS

Only ILM 2007 FP1 has the Exchange 2007 support, so if you’re on an older version you need to upgrade. It is a very straight-forward operation – I have now done three in-place upgrades of production MIIS/ILM installations and they have all gone without a hitch – so what are you waiting for?

Just make sure you backup your MIIS database first!

My mantra in all things IT is Keep It Simple, Stupid (well, that and Go Home And Sleep On It, though GHASOI doesn’t have such a nice acronym). Whatever complicated messy solution presents itself first, there is almost always a far more simplistically elegant one lurking in the wings, and though you might have to tidy up some of your earlier patch jobs to get to it, simplicity is always a worthwhile goal in itself, contributing to the long-term maintainability and transparency of your system.

So here are my top tips for a KISSable MIIS installation.

Seperate Provisioning Extensions

Using the MVRouter approach, seperate your MVExtension code into a dll for each provisioning MA.

So if you are creating objects in MAs called AD, ADAM and Phonelist you would have three provisioning code projects: MVExtension_AD, MVExtension_ADAM and MVExtension_Phonelist.

Note that in this approach, each dll just focuses on the objects to be created in its own connector space. This is completely opposite to another common approach: organising provisioning by object type, which, frankly, can turn into quite a mess if there are many target MAs, and different rules concerning them all.

If you’re really clever you can modify MVRouter to use an XML control file where you can selectively switch off provisioning to individual MAs. This is really useful in complex environments with many MAs.

Just remember that MIIS still runs each provisioning extension against all metaverse objects so you need to include a check at the top of the Provision sub, such as:

If Not mventry.ObjectType = "user" Then
    Exit Sub
End If

A Simple Structure for the Provisioning Code

I have a basic format that I almost always use for the Provision sub.

Dim MA As ConnectedMA = mventry.ConnectedMAs(MA_NAME)
Dim ShouldExist as Boolean

' Logic to set ShouldExist based on whether the object
' should exist in the connector space

If ShouldExist And MA.Connectors.Count = 0 Then
    'Provision

ElseIf ShouldExist And MA.Connectors.Count = 1 Then
    'Check if rename needed

ElseIf Not ShouldExist And MA.Connectors.Count = 0 Then
    'Nothing to do

ElseIf Not ShouldExist And MA.Connectors.Count = 1 Then
    'Deprovision

Else
    'Error - too many connectors
    Throw New UnexpectedDataException("Metaverse object has too many connectors to " & MA_NAME)

End If

Minimise Advanced Attribute Flows

Obviously I am not saying you shouldn’t use Advanced attribute flow rules – they’re extremely useful and often the neatest solution.

BUT I do have a general philiosophy about generating data outside MIIS and then syncing it through MIIS.

A lot of this is due to straight forward troubleshooting. Let’s say a user’s email address is wrong in AD. If you were flowing the email direct it would be a simple matter to point to incorrect source data, or perhaps an incorrect join.

Now lets say you were using an advanced flow rule to construct the email address based on some combination of first name, surname and department. Troubleshooting now could include attaching a debugger and tracing through the code. Apart from being a pain in the neck, this is not a task that is easily delegated. Far better to generate the email address outside MIIS (for instance, by using SQL queries or SSIS packages) and then just sync it straight through.

There is also the simple argument of efficiency. The worst advanced flow rule I have ever seen was populating group members by running SQL queries against the metaverse. Some of the groups had thousands of members and to say this was slow was a complete understatement – it barely crawled. By exporting the member DNs, and populating the groups in a SQL table outside of MIIS, I was able to reduce a four hour sync to eight minutes.

Remove Complex Join Rules

Complex join rules, with multiple possibilities and join resolution logic, should only be used as a short term measure to sort out who is who. Once the joins have been made you should flow something uniquely identifying and unchangeable out to the the connected objects. Then you can replace your complexity with a simple, direct join rule.

If you absoluely cannot export an identifier to this data source then use an XMA with a SQL table to keep track of the matches – like here.  You’ll be glad you made the extra effort when you have to delete and reimport your connector space.

And the rest…

There are other things I could include – like simplifying your metaverse design, and being consistent with your attribute names… but the topics I have described here are areas where most installations I’ve seen could make improvements. Just keep it simple, and the rest should follow.

Some points to consider…

The identifier must be unique in the metaverse

There is no technical reason preventing you re-using an identifier,  but there are a lot of good design reasons. You should always be able to re-join to a metaverse object using the identifier, with no possibility of multiple matches.

I recommend not even re-using the same identifier across different object types.

Export the identifier into all your connected directories

Find a suitable attribute, set up an export flow rule, and get the identifier out. Then use the same attribute to join back (you should always have join rules, on every MA).

Very rarely there will be some application where you can’t find a suitable attribute to stick the identifier in. In my experience so far, these have always involved extensible MAs, and with XMAs I always maintain a SQL table where I can record extra info that will not go into the target system – such as a mapping between my unique identifier and whatever I’m being forced to use in the  external app.

Use something that won’t change

Usernames, email addresses and names are no good. They can change. Forget them.

Ideally use something that comes out of a database system which will already be enforcing a unique ID, such as an HR system.

Ensuring uniqueness

Many organisations are suffering under multiple import systems – perhaps company mergers mean multiple HR systems to encorporate, or different user types being generated in different systems. If there is any risk of a conflict, use an import flow rule to insert a prefix, or stage via a database where you can manipulate the identifier and assure uniqueness.

Don’t use the metaverse GUID

I was, I confess, somewhat horrified when I realised people do this. Just don’t! You never know when you will need to clear out and re-import. You should always plan for this possibility!

Don’t use something system specific

I also have concerns when I hear of the AD SID being used as a unique identifier. I feel that a person (or group, or other object) should be uniquely identifiable whether it is currently in AD or not. Sometimes accounts get deleted and re-created, but that doesn’t stop the person being themself.

I would only consider this a defensible design if AD was your primary, and most trustworthy, data source.

So remember:-

the unique identifier is unique, it doesn’t change, you get it everywhere, and you can rely on it in join rules. Perfect KISS philiosophy.

Group population is not the simplest thing to automate, however it is often a time-consuming manual task, and something high up on the priority list for an ILM project. Here are a few points which may help you on your way.

Members are Reference DN values

Groups are populated with links to the member objects, not a text list of names. To manage group memberships in ILM all involved objects must be present in ILM.

So, to put this plainly, if you’re trying to manage a particular group in AD then ILM must know about all its members. It is not possibly to partially manage a group.

You can only populate member and not memberOf

You can’t write to the “memberOf” attribute on user objects. It is something called a “backlinked” attribute, and AD is in charge of maintaining it.

You can, however, write to the “member” attribute of group objects, and this is the way you have to do it.

So it is not possible to manage group memberships by only considering the person (or user or contact) object – you need to manage the group objects as well.

You can’t modify reference DN attributes in extension code

ILM won’t let you write advanced flow rules for reference DN attributes – all you can do is flow them direct from one connector space, via the metaverse, to another.

(Actually I’ve never quite understood why this is, but there you go, we have to live with it.)

To emphasise the point: you must generate your membership lists outside of ILM, and then sync them directly through ILM.

When Dynamic Groups are not enough

Dynamic groups are those ones you want to change based on members’ attributes. Perhaps the group should contain everyone in a particular department, or a building, or with the same manager.

Exchange 2003 brought us dynamic groups – but only for distribution lists, and not security. Pathetic.

Besides, you’re most likely going to need some manually populated groups as well – not everything can be worked out from attribute values. You may also want some groups where most of the members are dynamic, and a couple which are static.

If you’re using SunOne LDAP you can do all this natively… but with AD the membership of all security groups are static, and you need something else to help automate things.

Generate the members in SQL

Here’s how you might generate the membership lists in SQL:

1. Generate dynamic group memberships in a view by directly querying the mms_metaverse table (sample queries to follow in another post).
2. Maintain another table for manually added group memberships (perhaps with a web front-end to manage them; groups can appear in both tables).
3. Concatenate the table and view together.
4. Import using the multivalue function of the SQL MA.

For more explanation on how to configure the tables to import group memberships see this post.

Use Delta tables

You may quickly find that full imports from multivalued tables are too slow – for this reason it is essential that you use delta imports, ie., only import changes.

The basic method is as follows:

1. Snapshot your import table/view;
2. Do a Full import;
3. Next time, take a new snapshot and compare it to the last one to make a Delta Table;
4. Do a Delta Import;
5. Once the Delta Import has completed successfully, clear out the Delta Table;
6. Repeat steps 3-5 ad nauseum.

There is (naturally) a fair bit more to it when you start bringing multivalued attributes into the mix. I’ve written a few posts on the subject in the past, and the best place to start is with this one.

In Summary

I once set up a system that had 6,000 groups and 40,000 users. The group memberships changed continuously – particularly the self-subscriber ones that were updated through the user portal. For efficiency, I separated the multivalued and single valued attributes into seperate MAs, and the multivalued Full Import still took about 5 hours. But by running regular delta imports (every 15 minutes) the list of changes each time was short, and the imports took only a matter of moments.

So while group population and synchronisation with ILM is fiddly, and does use a number of advanced techniques, it is certainly possible to achieve a result that is both effective and efficient.

Multiple Join Rules

You can have multiple join rules, which you may (or may not) combine into Mapping Groups.

• The components within a mapping group have AND relationships: eg., where “sn = sn” AND “department = department”.
• Between the mapping groups we have an OR relationship – so we are looking for an object that satisfies one of them.
• The mapping groups are evaluated top-down. If you are not resolving the search (more on that below) ILM will join the first match, so the order you put them in is significant.

Advanced Join Rules

As well as Direct join rules, we can use .NET to write Advanced rules for when we want to match a single metaverse attribute to a calculated value based on a number of CDS attributes.

For example: Take the first inital and surname from the CDS and try and match it to the uid in the metaverse, using a couple of different capitalisations.

Configuring an Advanced join rule in the MA is very similar to an Advanced flow rule – select the input and output attributes, and give the join rule a name (you do not have to accept the default one).

You now need to write the code for the join rule. And you do that in the MA Extension, under the Sub MapAttributesForJoin.

One of the arguments of this sub is a collection called values. You put your calculated values into here – one of which will hopefully match to a metaverse object.

Continuing on with our uid example, the code might look like this:

Public Sub MapAttributesForJoin(ByVal FlowRuleName As String, ByVal csentry As CSEntry, ByRef values As ValueCollection) Implements IMASynchronization.MapAttributesForJoin

  Select Case FlowRuleName

    Case "joinUid"

      Dim initial as String = csentry("givenName").Value.Substring(0,1)

      values.Add(initial.ToUpper & csentry("sn").Value)

      values.Add(initial.ToUpper & csentry("sn").Value.ToUpper)

    Case Else

      Throw New EntryPointNotImplementedException

  End Select

End Sub

So all we’ve done is derive a string, returned it to ILM in the values collection, so that ILM can try to match it against the uid’s it has in the metaverse.

Note that it’s a good idea to leave that “Case Else” in there, just in case someone configures a join rule name without also writing the code.

Resolving Multiple Matches

There are some situations where you want to check through a group of possible matches, and select the most likely one.

I had an experience with trying to match student home directories against usernames. The usernames included the course code, but the home directories just used the first past of the username – ie without the course code. The only way you could tell for sure who’s directory it was was by looking at the folder path, which did include the course code somewhere in the parent heirarchy. Exactly where was not predicatable as it differed from department to department.

The solution was as follows:

1. Create a new metaverse attribute called “uidSimple”,
2. Add a seperate flow rule on the importing MA that cropped the course code from student IDs and populated uidSimple,
3. Add a Direct join rule for the home folders: “folderName = uidSimple”,
4. Use a Resolve rule to figure out which folder is the right one.

Configuring a Resolve Rule

In your join rule, tick the box saying you wish to use a rules extension to resolve multiple matches, and then enter a name. Once again you are under no obligation to accept the default (I never do) – just make sure you name check it correctly in your code.

Then modify the Function ResolveJoinSearch in the MA Extension.

This function passes you rgmventry – a collection of metaverse objects which have satisfied your join rule – and a single csentry. Your job is to return a TRUE (match found) or FALSE (match not found), and the index of the found object as imventry.

Public Function ResolveJoinSearch(ByVal joinCriteriaName As String, ByVal csentry As CSEntry, ByVal rgmventry() As MVEntry, ByRef imventry As Integer, ByRef MVObjectType As String) As Boolean Implements IMASynchronization.ResolveJoinSearch

  ResolveJoinSearch = False
  imventry = -1
  index = 0

  Dim mventry As MVEntry

  Select Case joinCriteriaName

    Case "resolveFolder"
      For Each mventry In rgmventry
        If mventry.ConnectedMAs(MAName).Connectors.Count = 0 Then

        'Only considering metaverse obejcts that are not yet connected in this MA
          If csentry("Path").Value.IndexOf(mventry("CourseCode").Value) > 0 Then
            ResolveJoinSearch = True
            imventry = index
            Exit Function
          End If

        End If

        index = index + 1

      Next

    Case Else

      Throw New EntryPointNotImplementedException()

   End Select

End Function

Once you’ve got these hard-won joins in place, make sure you keep ‘em!

There’s lots of creative stuff you can do to help you get a messy CDS joined up. It would, however, be nice if all these complex join rules can be retired once the CDS is being properly managed.

If at all possible export a “breadcrumb” value out to some attribute in the CDS that will enable a simple, 100% certain join to take place in the future if, for any reason, you have to re-import the entire connector space. If you plan for it it won’t hurt a bit when it happens!