Setting up Synchronization

The Setup Wizard installs Synchronization Service Key Management on the server; this is launched on completing the installation and used to manage the encryption keys on the server. You will also find the Synchronization Service Manager on the machine; this is the main admin tool for dealing with synchronization.

The functions are selected via buttons at the top. In addition to the Joiner , which allows you control what happens with objects in the connector space that are no longer linked, you can browse the metaverse or even edit the metaverse schema with the Metaverse Designer .

The Operations feature tells you the status of the synchronization at a glance (Figure 2). Additionally, you can manage the MAs via the same button. All settings for the connected data source and synchronizing the two AD domains with Metaverse are defined here. The Create command starts a new definition; this requires a fair amount of input. After some experimenting, things start to make sense and the elementary principles are quickly revealed.

Figure 2: The Operation view in Synchronization Manager.

The Configure Join and Projection Rule and Attribute Flow steps are especially important here. Projection in MIM-speak simply means creating new system objects, whereas Join refers to changing an existing object. The idea that the new system (projection) would need to be configured at the MA for the KBDEST domain seems obvious – but this is not the case. Because the New process relates to objects in the metaverse, which is handled by the MA for KBCORP, the setup also occurs here. Accordingly, only a Join occurs for the MA in the KBDEST domain at this point.

The administrator sets the mappings of the individual attributes in the Attribute Flow . The attributes previously defined for the MA from the data source are mapped with specific attributes in the metaverse. Using the Flow Direction option, you then specify whether this is an import or export, as can be seen from the direction of the arrow (in the MA for KBCORP from left to right on importing into the metaverse). The handful of attributes from this example are only for illustration purposes. In practice, far more attributes are likely to be necessary. The important thing here is that the attributes have correct mappings from the data source to a metaverse object. The arrows in the MA for the KBDEST domain again point from right to left, reflecting an export with the same attribute mappings.

The settings for the MA are quite complex, which can cause frustration – especially at the beginning – if synchronization is not working as it should. At this point, you might like to check out the help function, which you can launch bottom right in each dialog. Relative to the context, it explains in detail the aspects that are now offered in the dialog. This is quite useful, especially when you are just getting started. Now that both MAs are completed, you need the run profiles for the two agents. They control the flow of data between the directories. The import and the synchronization should exist for both MAs, the Export step only exists in the Run Profiles for the KBDEST MA.

Provisioning Users

One process controlled by the portal – unless you use the synchronization service via the portal – is that of creating or deleting user objects, that is, provisioning. Because you're not using the portal, but just the synchronization service, you'll need to find an alternative. MIM has an interface named Rule Extension for this. This is a way to embed custom code in C# or Visual Basic (VB) that lets you intervene with the data flow of program logic. In the Synchronization Service Manager, you will find this under Tools | Options . At this point, you can also create a code template for C# or VB, which is, however, a one-off measure; you can find many how-tos for the implementation online. Not every administrator wants to be a developer, however, and this is ultimately also a matter of time.

For a simpler approach, you can turn to the Codeless Provisioning Framework [6]. The setup consists of only two files: a DLL, which you need to integrate with Synchronization Service Manager, and an XML file that contains the ruleset. The author includes various provisioning rules in the form of XML files; you therefore have a fair amount of reference material for quickly familiarizing yourself with the subject matter – and without using Visual Studio.

Scheduling Run Profiles

If you navigate in Synchronization Service Manager to Run Profiles , you can press the Script button to create a VBScript, which – when wrapped in a batch file and handed over to the scheduling service – ensures that regular synchronization runs [7]. This is quite convenient, but you will find an even better option in the form of the FIM/MIM MARunScheduler [8], which you might want to consider.

The scheduler comprises two files: MARunScheduler.exe and an XML file that contains all the parameters. You can thus create a plethora of Schedules and, for example, restrict the time frame for each run profile, or you can stipulate that the synchronization cycle run permanently and that changes are only written from the source to the destination in case of changes:

<C>(parameter:) LoopIndefinitely<C>

In this way, the two domains from the example would be permanently synchronized in real time, which offers a variety of opportunities.