Architecture for an Offline GAL Sync process using FIM 2010 (plus Opalis and Windows Azure!)

Offline “GAL Sync” using FIM 2010

For one of our enterprise customers we developed a solution for what I will call an Offline GAL Sync, meaning we are sharing Exchange address book information across multiple disconnected organizations. We were not able to use the standard Forefront Identity Manager (FIM) Galsync management agent because this requires a live connection to both source and target systems from a single FIM instance.

The capability this solution provides is to:

• Export all or selected address book information from the Source organization
• Import that information to one or more Target organizations
• A one-way sync process, note that the data at the Target is to be treated as read-only; some solutions may require 2-way synchronizations

The basic architecture is shown here:

Now while this is a workable solution there are a few potential problems:

• Sequencing of updates across multiple FIM instances – if a delta update is missed on the Target side it could affect processing of future updates. What’s might help a lot here is some type of runbook automation which can span across 2 or more organizations. With System Center Opalis this could be done, although the current product may hit some stress points in working across organizations. 
• Ensuring file transfer is working – this must use an Internet connection
• automating the end to end process – the FIM portions are relatively straight forward to automate on their own, but now we need to introduce an event driven trigger to kick off processing on the Target side.

Now lets talk about some improvements that could be made.

Runbook Automation

I would like to see this overall process surrounded by a runbook automation process. With a tool such as Opalis in place, we could watch for files to drop in a particular folder and then trigger the FIM “Delta Load” process on the target. The runbook automation could also handle error conditions, provide notifications, and many other useful tasks to make the overall process more manageable. Our revised architecture would look like the following:

Opalis provides a rich set of workflow objects for file handling as shown in the figure below (this is from the Opalis Workflow Object List document).

File transfer over the Internet – Windows Azure to the rescue !

Now how about that kludgy file transfer process? While there are 3rd party products available which do this type of thing and provide scripting interfaces, that seems an inelegant solution. Since pretty much everything has to work over the Internet these days I believe secure file transfers will become a free built-in service (at some point!). As to how this might be designed I’ll get some feedback from my Azure expert friends and post an update soon. I would imagine this has already been built for some projects, perhaps using the Azure Blob Storage service as described in this Walkthrough.

Assuming we have this Azure-based file transfer as a generic capability, our runbook process would now look something like:

Opalis Notification Workflow built-in objects are shown here:

…..

I’m convinced that Azure cloud features will bring a wealth of great new capabilities to Microsoft’s server-side infrastructure products such as Forefront Identity Manager and Opalis. Every day we will be challenged to think outside the box about these new architectural models.