Migrating from ILM 2007 to FIM 2010

This document describes the steps and processes that are involved in migrating a Microsoft® Identity Lifecycle Manager 2007 (ILM 2007) environment to Microsoft Forefront Identity® Manager (FIM 2010 R2) 2010.

For an overview of FIM 2010 documentation and guidance for using it, see the Documentation Roadmap.

Migrating from ILM 2007 to FIM 2010

The next release of ILM 2007, FIM 2010, extends the functionality of ILM 2007. New features empower end users with self-service tools integrated in the Microsoft Office system and in Windows®. Additional features allow information technology (IT) organizations more control through a robust delegation model and business process framework. New capabilities improve operational efficiency by automating common identity lifecycle management tasks and empowering end-users with self-help solutions. For organizations that want or need a more customized approach, Microsoft is implementing FIM 2010 on common sets of services that includes workflow, delegation, Web services application programming interfaces (APIs), and logging. These services can be used by customers and vendors to customize and extend the functionality of FIM 2010 to meet their specific needs.

While FIM 2010 introduces a broad variety of new features, the architecture is designed to create a simple and straight-forward migration experience. Because FIM 2010 completely supports all features of ILM 2007, the first migration step consists of a platform upgrade. This means, at the end of the first phase, your upgraded FIM 2010 environment functions the same way that your ILM 2007 environment functioned.

FIM 2010 is based on a 64-bit architecture. This includes the database backend that is used to store the related data. The objective of the first migration phase is to move your existing database to the 64-bit version of Microsoft SQL Server® 2008 and to extend the existing ILM 2007 database schema to FIM 2010.

As soon as the platform migration has been completed, you are ready to migrate your identity scenario to FIM 2010 R2. This includes a migration of your nondeclarative provisioning implementation to declarative provisioning.

Performing a Platform Migration

The objective of the first migration phase is to perform a platform upgrade of your ILM 2007 environment to FIM 2010.

The following list outlines the steps that are involved in this process:

1. Save your encryption keys from Microsoft Identity Integration Server (MIIS) and ILM.

2. Copy your existing SQL Server database to a server running SQL Server 2008.

3. Configure the existing database that is to be managed by your server running SQL 2008.

4. Rename the database to FIMSynchronizationService

5. On the database FIMSynchronizationService, make sure the database Compatibility level is set to either SQL Server 2005 (90) or SQL Server 2008 (100).

6. Install FIM 2010 and choose to reuse the migrated database.

7. Provide the encryption keys to the installer wizard.

At this point, from a technical perspective your environment is ready. While FIM 2010 can operate with the 32-bit versions of your metaverse and rules extensions, it is recommended that you to recompile your extensions to 64-bit for performance reasons if you did not originally compile them to be platform independent. To migrate your metaverse and rules extensions to 64-bit, you copy the source code to your server running FIM 2010, modify the references to point to the new FIM 2010 libraries, and then recompile your extensions.

It is also a good practice to initialize your environment by running a full import and a full synchronization.

FIM 2010 R2 introduces a new management agent that is used to exchange identity data between the FIM 2010 R2 Synchronization Service and the FIM 2010 R2 Service database. When you configure the FIM 2010 R2 management agent, the system automatically upgrades the database schema to FIM 2010. This process includes adding new objects that are used by declarative provisioning.

Performing a Scenario Migration

While FIM 2010 R2 is completely compatible with ILM 2007, a migration from nondeclarative to declarative provisioning may require some changes to your current scenario. The objective of this section is to introduce you to potential changes based on a typical scenario.

For a complete overview of how declarative provisioning works, see Understanding Data Synchronization with External Systems.

One significant difference between ILM 2007 and FIM 2010 R2 is the new declarative provisioning model. In this model, managed objects have a new attribute called an ExpectedRulesList that is used to establish a link relationship between an object and the related outbound synchronization rules. The required schema extensions are automatically deployed as soon as you configure a FIM 2010 R2 management agent.

The declarative provisioning model does not support multiple connectors from the same connector space to a single metaverse object. As part of your migration process, you need to address this difference in your solution design.

FIM 2010 R2 introduces the concept of Sets to group objects either manually or based on shared criteria automatically. If your current solution includes the Group Populator, you need to implement manual steps to perform a Group Populator Set conversion.

The following sections outline the steps that are part of typical scenario migrations.

Migrating a scenario that includes Group Populator

In this section, you will find instructions for migrating a scenario that includes the Group Populator.

This scenario consists of a human resources (HR) system that is authoritative for employee data and Group Populator to automate the process of managing groups.

The goal of this scenario is to make FIM 2010 R2 authoritative for the management of groups and to manage all resources by using declarative provisioning. The following illustration outlines this scenario:

Migrating this scenario to FIM 2010 involves the following steps:

1. Exporting the encryption keys from your ILM 2007 system.

2. Backing up the ILM 2007 database.

3. Importing the database on your server running FIM 2010.

4. Installing FIM 2010 on your FIM 2010 R2 server by reusing the ILM 2007 database.

5. Configuring a FIM 2010 R2 management agent to extend the schema with the new objects and attributes.

6. Running a delta import, delta synchronization, and an export sequence on the FIM 2010 R2 management agent.

   Note

   FIM 2010 R2 is, at this point, the main system with an identical configuration as ILM 2007.

7. Configuring a declarative inbound synchronization rule to import data from the HR system.

8. Configuring two declarative outbound synchronization rules to manage objects in Active Directory Domain Services (AD DS) and in Group Populator.

9. Removing your nondeclarative metaverse and rules extension logic.

After completing these steps, your scenario has the logical outline shown in the following illustration.

To finalize the migration, you follow the steps below:

1. Create a declarative inbound synchronization rule to import all groups to FIM 2010 R2.

2. Add the required filter to your groups in FIM 2010 R2 to make the membership calculation dynamic.

3. Create a declarative outbound synchronization rule to manage the group objects.

4. Configure the attribute flow precedence to give the FIM 2010 R2 management agent a higher priority than the Group Populator management agent.

5. Run a full synchronization cycle on your management agents.

6. Remove the outbound synchronization rule from the Group Populator management agent.

7. Remove the Group Populator management agent.

At this point, you have completely migrated your scenario from using nondeclarative provisioning to declarative provisioning.

In this final state, your environment has the logical structure shown in the following illustration.

Migrating a scenario that uses an external application to manage group membership

This scenario is based on an external application that currently manages group information in AD DS. This deployment scenario is limited because the ownership cannot be moved for all group objects at the same time. The actual transition needs to be implemented on a step-by-step basis.

The following illustration outlines the initial configuration of this environment.

Migrating this environment involves the following steps:

1. Exporting the encryption keys from your ILM 2007 system.

2. Backing up the ILM 2007 database.

3. Importing the database on your server running FIM 2010.

4. Installing FIM 2010 on your FIM 2010 R2 server by reusing the ILM 2007 database.

5. Configuring a FIM 2010 R2 management agent to extend the schema with the new objects and attributes.

6. Creating an inbound synchronization rule to import from data from the HR MA.

7. Creating two outbound synchronization rules to manage objects in AD DS and the Mainframe.

8. Configuring an attribute on the group object that you use to track the management status of a group object by either using an existing attribute or by extending the schema.

9. Populating this attribute by using the following schema:

   • No value. AD DS is authoritative for all attributes.

   • 1. AD DS and FIM 2010 R2 are equally authoritative for the attribute values.

   • 2. FIM 2010 R2 is authoritative for all attributes.

10. Creating three outbound synchronization rules that use the attribute to determine the required attribute flow direction.

11. Adding an outbound flow mapping to each synchronization rule that sets the attribute to the required value.

12. Configuring your attribute flows to use equal precedence.

Because the attribute initially has no value, all groups and the group members are imported into FIM 2010 R2. Create a Set for all groups that are managed by AD DS only. You should also create a management policy rule that prevents FIM 2010 R2 from adding members to the group.

The following illustration outlines the state of your environment after applying the first set of migration steps.

To finalize the scenario, follow the steps below:

1. Select the number of groups in AD DS that you intend to be managed by FIM 2010 R2 and AD DS.

2. Set the attribute that indicates the management type on those groups to 1.

3. Establish a process that informs the affected users that FIM 2010 R2 will be used to manage these groups moving forward.

4. Update the management attribute of the groups that are ready for being managed by FIM 2010 R2.

5. Repeat the steps that are required to transfer the ownership until all groups are managed by FIM 2010 R2.

As soon as you have migrated the ownership for all groups to FIM 2010 R2, you can retire the external group management application.

At this point, you can also remove the inbound synchronization rule for the group management application and switch off the usage of equal precedence setting.

In the final state, your scenario now has the following configuration.

Summary

A typical migration from ILM 2007 to FIM 2010 R2 consists of two discrete phases:

1. Infrastructure migration

2. Deployment scenario migration

FIM 2010 R2 provides a convenient mechanism to migrate your current scenario to the FIM 2010 R2 platform. Depending on the size and complexity of your current environment, the deployment scenario migration might, after thorough planning, require a phased approach to eventually get to a FIM 2010 R2 from an infrastructure and scenario perspective. In equal importance, FIM 2010 R2 provides an easy-to-use mechanism that allows shared ownership for attributes in a scenario transition.