Was this page helpful?
Additional feedback?
1500 characters remaining
Export (0) Print
Expand All

Enhancing and Simplifying Identity Management

How Microsoft Upgraded to Forefront Identity Manager 2010

Technical White Paper

Published: May 2010

The following content may no longer reflect Microsoft’s current position or infrastructure. This content should be viewed as reference documentation only, to inform IT business decisions within your own company or organization.


Download Technical White Paper 1.48 MB Microsoft Word file




Products & Technologies

The identity management infrastructure at Microsoft provided an integrated solution for managing digital identities across heterogeneous systems. However, the ongoing management and maintenance of the solution required a cost-inhibitive reliance on custom code and manual processes. In addition, there were limited reporting functions or self-service tools for end users. This lack of meaningful tools placed undue burdens and costs on IT departments, the Helpdesk, and end users.

Microsoft IT introduced Forefront Identity Manager 2010 into the identity management solution at Microsoft. Forefront Identity Manager provides tools that both enhance and simplify identity management.

  • The introduction of a SharePoint-based user portal provides self-service tools for group management, password reset, and profile management. These tools eliminated support and maintenance costs.
  • Enhanced automation significantly reduces costs associated with the maintenance of custom code.
  • Powerful .NET extensibility gives developers greater programming agility.
  • Microsoft Forefront Identity Manager 2010
  • Active Directory Domain Services
  • Microsoft SQL Server 2008
  • Windows Server 2008
  • Microsoft Identity Integration Server
  • Microsoft Identity Lifecycle Manager 2007
  • Microsoft System Center Configuration Manager
  • Windows SharePoint Services

Ff522824.arrow_px_down(en-us,TechNet.10).gif Executive Summary

Ff522824.arrow_px_down(en-us,TechNet.10).gif Introduction

Ff522824.arrow_px_down(en-us,TechNet.10).gif FIM 2010 Solution

Ff522824.arrow_px_down(en-us,TechNet.10).gif Deployment

Ff522824.arrow_px_down(en-us,TechNet.10).gif Lessons Learned and Best Practices

Ff522824.arrow_px_down(en-us,TechNet.10).gif Conclusion

Ff522824.arrow_px_down(en-us,TechNet.10).gif For More Information

Executive Summary

The purpose of this paper is to share the experiences of Microsoft Information Technology (IT) in upgrading to Microsoft® Forefront™ Identity Manager (FIM) 2010, including design considerations and the business value added through process improvements, automation, and cost efficiencies. This paper briefly discusses the identity management framework with the addition of FIM 2010, the evolution of the identity management strategy, lessons learned, and best practices.

This paper does not describe new certificate management features in FIM2010. For information about that topic, refer to the TechNet document "Installing and Configuring Microsoft Forefront Identity Manager Certificate Management on a Server " at http://technet.microsoft.com/en-us/library/ee534914(WS.10).aspx.

This paper assumes that readers are technical decision makers and IT professionals who are familiar with Active Directory® Domain Services (AD DS), Microsoft Identity Lifecycle Manager (ILM) 2007, Microsoft SQL Server® 2008 database software, and the Windows Server® 2008 operating system. This paper is for IT professionals who design, manage, and implement identity management systems. This paper provides guidance through best practices based on the early adopter experiences of Microsoft, though it is not an instructional guide. Each environment is unique, and each organization should consider its situation and needs before planning to deploy any product or solution.

Note: For security reasons, the sample names of forests, internal resources, and internal organizations used in this paper do not represent real resource names used within Microsoft and are for illustration purposes only.


The overarching goal of Microsoft IT's identity management strategy has stayed consistent: Provide a security-enhanced and cost-effective solution for managing the life cycle of digital identities. This is no small task. More than 175,000 users, located in 83 countries, access more than 2,300 corporate applications.

To achieve this goal, Microsoft IT, like many organizations, developed an identity management infrastructure for managing the complexities of a diverse set of systems, applications, and information stores deployed across its enterprise environment. However, as with many other organizations, the Microsoft IT identity management solution has new demands placed on it as the interoperability of systems becomes more complex, the business requires greater cost efficiencies, and the needs for regulatory compliance increase. The identity management infrastructure at Microsoft is evolving and improving as it keeps pace with these demands.

Identity Management Framework

The addition of FIM 2010 to the infrastructure created a framework that enables Microsoft IT to apply a customizable approach to its identity management solution while taking advantage of existing services. Figure 1 illustrates this framework.


Figure 1. Key components in new identity management framework

Provisioning. Also known as the life cycle of digital identities, provisioning defines how identities are created, modified, and retired. It takes advantage of user information contained in AD DS to accelerate the granting and revoking of user accounts and user rights for information resources such as e-mail messages, telephone services, intranet and extranet access, Helpdesk services, and applications.

Sync Engine. This is the core of the identity management system. It brings together multiple data stores (for example, directories, flat files, and databases) to provide a single mechanism for synchronizing identity data. Identity data includes security information and end-user profile information such as addresses, phone numbers, office space, and title or department.

Active Directory. As part of Microsoft Windows® 2000 Server and Windows Server 2003, the Active Directory directory service (AD DS in Windows Server 2008) is a distributed directory store that serves as the focal point for identity information.

Authentication. This is the act of proving an identity to a network, application, or resource. Authentication techniques range from user ID–based or password-based logons to mechanisms such as tokens, smart cards, and public-key certificates.

Authorization. This is the process of determining whether a digital identity can perform a requested action. Authorization occurs after authentication and uses attributes, or entitlements, associated with the digital identity to determine what resources the digital identity can access. For example, the entitlements associated with a user might authorize access to restricted information in a shared project file or e-mail message stored on a company server.

Privacy. Privacy-related technologies reduce the risk involved in extending access to the Microsoft enterprise system. Providing precise control of user rights and permissions helps secure digital information and protect privacy. The ability to modify rights or revoke access further enables flexibility and persistence of this protection. A growing number of legislative requirements add to the task of protecting digital information. For example, governmental standards such as the Health Insurance Portability and Accessibility Act (HIPAA), Sarbanes-Oxley Act (SOX), and Gramm-Leach-Bliley Act (GLBA) place additional restrictions on organizations.

Applications . These are the consumers of the digital identities and are the enforcers of the entitlements derived from an identity.

User Portal. The user portal in FIM 2010 provides self-service group management functions, password reset, and Microsoft Outlook® Add-in, in addition to Microsoft .NET extensibility.

Policy Management. This functionality in FIM 2010 provides Management Policy Rules (MPRs) that the portal follows when it takes an action. Through the application of configuration settings, organizations can modify MPRs to fit specific business rules and requirements.

Custom Activities. A policy determines custom-coded activities. For example, Microsoft IT created an MPR that ran a custom activity for reserving aliases before creating a new mail-enabled group. This activity prevented duplication within the Microsoft enterprise environment. Additionally, Microsoft IT used custom activities to maintain parity with the custom group management application.

Codeless Provisioning. This functionality provides a set of customizable rules that the Sync Engine follows when it synchronizes objects from connected data sources such as AD DS.

Identity Management Ecosystem

FIM 2010 is part of the overall identity management ecosystem that operates within the greater Microsoft enterprise environment. This ecosystem includes a complex network of applications, databases, and database servers that work together to provide a security-enhanced environment for managing and consuming identity data. Figure 2 provides a high-level illustration of the interrelationships and flow of data among key aspects of the identity management ecosystem.


Figure 2. Identity management ecosystem

Evolution of Identity Management at Microsoft

The Microsoft identity management system has evolved over the past decade to enhance security, provide business value, and keep pace with technological advancements. Figure 3 shows the primary improvements gained with each major identity management release.


Figure 3. Evolution of identity management

The following sections describe the role of the major improvements that Microsoft IT implemented with each major release.

Role of Active Directory

As part of Windows Server 2000, Active Directory (now AD DS) played a central role in the beginning stages of the identity management solution at Microsoft. It served as the focal point for the management and administration of user accounts; authentications; security principals and policies; and enterprise resources such as computers, printers, servers, contacts, and groups.

However, because the Microsoft enterprise contains nine Active Directory forests and every forest has its own instance of AD DS, Microsoft IT encountered difficulties providing consistency of information across all nine forests. Applications often could identify only data within the local Active Directory forest. These difficulties were alleviated with Microsoft IT's progression to the next release for identity management: Microsoft Identity Integration Server (MIIS).

Role of Initial MIIS Release

At the initial release of MIIS, the main concern was providing consistent information, especially for e-mail users, across all nine Active Directory forests. To address this concern, MIIS included GAL Sync, technology for synchronizing entries to the Microsoft Exchange global address list across multiple Active Directory forests. GAL Sync, along with other products in the MIIS release, used synchronization to create views of data across multiple Active Directory forests and to eliminate duplicate, inaccurate, or incomplete data.

Although the implementation of MIIS solved the initial data synchronization issues, it also required manual processing of daily changes and a weekly full synchronization across all forests. These daily and weekly tasks were expensive to sustain, and the cost of maintaining the identity management infrastructure became clear.

Role of MIIS 2003 Release

With its implementation of the MIIS 2003 release, Microsoft IT looked for ways to improve the current system. Microsoft IT was able to automate processes for data consistency, improve user creation and the consolidation of directory data, and streamline cross-forest data replication through the addition of the following enhancements:

  • Automated Consistency Manager. By fixing, disabling, or flagging for review data differences between the user account database and Active Directory, automated processes for maintaining data consistency with Active Directory.

  • First-Last. Provided end users with a Web-based self-service tool that prevented a user from using another user's name, and then gave a selection of possible options. After the user selected a name, it was added as a secondary Simple Mail Transfer Protocol (SMTP) address and synchronized via MIIS and GAL Sync.

  • Consolidated Metaverse Data Feed tool. The ILM metaverse data writes to a database as a consolidated data view or feed.

  • Sites and Subnets Manager. Using a front-end Web-based application for writing data to a database, automated the process of propagating sites and subnet data read by MIIS to Active Directory.

  • Printer Sync. By synchronizing printer information across all of the Active Directory forests, end users could search for and attach to any printer in their location.

With the follow-up release MIIS 2003 Feature Pack 1 (FP1), Microsoft IT began looking for ways to improve performance and enhance scalability. The next section describes how ILM 2007 implemented many of the changes initiated in MIIS 2003 FP1.

Role of ILM 2007

ILM 2007 provided an integrated solution built on the metadirectory and user-provisioning capabilities in MIIS 2003 with a single offering available with Windows-based systems and other heterogeneous systems: The offering included the following:

  • Identity synchronization. ILM 2007 synchronizes user accounts and attributes in connected systems, including synchronization of passwords. This synchronization saves time and money by automatically keeping data consistent and enforcing data ownership rules.

  • User provisioning. ILM 2007 automatically creates user accounts, mailboxes, and other identity information in target systems in real time, so new employees are productive immediately. It also ensures an instant revocation of access to corporate resources when employees leave an organization.

  • Certificate and smart card management. ILM 2007 includes a workflow and policy-based solution that enables organizations to manage the life cycle through digital certificates and smart cards.

Microsoft IT took advantage of the integrated solution of ILM 2007 to provide performance enhancements, system scalability with new architecture, and user and group functionality. Before ILM 2007, Microsoft IT used the same instance of MIIS to manage users and groups. This was not optimal increasing processing time through the management of both users and groups. Additionally, the data sources for group and user data were different, and many data feeds wrote to one system.

With ILM 2007, Microsoft IT separated user and group functionality into two separate systems and improved the flow of data from the data sources. The user management instance of ILM 2007 was a small system with low latency for quick updates that occurred within one day. For the group management instance of ILM 2007, the latency was higher, with data changes processed in one to three days. Figure 4 illustrates the separate systems with their respective data flows.


Figure 4. ILM 2007 user and group architecture

Role of FIM 2010 Release

Building on the system integration of ILM 2007, the implementation of features and functionality in FIM 2010 improved the identity management ecosystem. The next section provides detailed information about the Microsoft IT implementation of FIM 2010.

FIM 2010 Solution

Although ILM 2007 provided a more integrated and comprehensive approach to identity management than previous technologies, Microsoft wanted to increase the business value of its identity management solution through improved processes and cost efficiencies. With the addition of FIM 2010, Microsoft IT further streamlined identity management.

FIM User Portal

Before FIM 2010, end users did not have access to a centralized user interface. They often relied on Helpdesk or non-connected custom applications maintained by Microsoft IT for repeatable tasks such as approving group memberships and resetting passwords.

With the upgrade to FIM 2010, Microsoft IT consolidated group membership and password reset functionality under one Windows SharePoint® Services user portal. Figure 5 shows an example of the FIM 2010 user portal after Microsoft IT applied customization and configuration settings.


Figure 5. FIM 2010 user interface

Group Management

With ILM 2007, Microsoft IT provided a custom-coded group management application for managing distribution groups (often called dynamic groups) and security groups. Although this application provided self-service group management tools through a Web-based interface, the custom code was expensive to maintain and operate. In addition, special access was required for group approvals and dynamic group management. Dynamic group management is currently a separate set of systems—each for a specific purpose. This added soft costs around user productivity while employees waited for access and approvals.

With FIM 2010, Microsoft IT is addressing these issues through the implementation of self-service tools for managing distribution groups and security groups, Outlook integration with automated group approval and notification workflows, and development of custom activities for automatically calculating membership in distribution groups.

Self-Service Tools for Distribution Groups and Security Groups

Based on common business scenarios, processes that could take several days become simple tasks that end users complete from the FIM 2010 user portal. For example, new employees are frequently required to join distribution groups and security groups and manage their own project related distribution groups. With FIM 2010, new employees go directly to the FIM 2010 user portal to join, create, and manage both their distribution groups and their security groups.

Automated Group Approval with Microsoft Outlook Add-in

With ILM 2007, end users first needed access to a custom group management tool before they could ask to join distribution or security groups that required approval. The result was a time-consuming process that required administrative support and prevented employees from receiving access to groups in a timely manner.

With FIM 2010, the implementation of the Outlook Add-in feature eliminated the need for administrative intervention with group membership approvals. Now, whenever someone requests membership in a group that requires approval, FIM 2010 automatically sends the owner an Outlook e-mail notice requesting approval or rejection of the request. This functionality provides significant process improvements because end users no longer require Helpdesk or administrative support for simple tasks that involve distribution and security groups.

Custom Activities for Calculating Dynamic Groups

Before FIM 2010, dynamic group memberships identified by using calculated groups based on Active Directory attributes were not available to end users. As a result, administrators spent a great deal of time keeping team and department distribution groups up to date. Productivity losses also occurred when new employees did not receive group e-mail messages.

With the deployment of FIM 2010, Microsoft IT is developing custom activities to automate the upkeep of team and organization-based distribution groups. These custom activities will enable new employees to receive important e-mail messages on their first day of work without administrative support.

Password Reset

Before FIM 2010, if employees forgot their password, they called the Helpdesk to have it reset. With 175,000 employees and contractors and over 42,000 password resets a year, this service cost Microsoft approximately $1.4 million US a year.

As end users transition to the password reset functionality in FIM 2010, the costs associated with password resets will be nearly eliminated. A complete elimination of these costs is not feasible, because some end users will continue to require support due to remote access and connectivity issues.

Portal Management

The portal management functionality in FIM 2010 introduces a fundamental shift in Microsoft IT's overall approach to identity management. Before FIM 2010, Microsoft IT did not have the proper framework in place for reducing reliance on custom-coded applications and consolidating identity management tools. As a result, most business rule changes or data synchronization updates needed to go through a complete project cycle that included scope determination, design, and implementation. Such a cycle can be a costly process.

Through the .NET extensibility provided in the portal management functionality of FIM 2010, Microsoft IT now has the tools that it needs to move away from custom-coded applications. These tools include codeless provisioning, MPRs, and custom activities.

Codeless Provisioning

The core of all identity management solutions is the synchronization of identity data across all of the connected data sources, such as AD DS. In fact, preventing issues of data synchronization is no small task. Before FIM 2010, Microsoft IT refined synchronizations by using custom-code rule extensions. These rule extensions were expensive to maintain.

FIM 2010 enabled Microsoft IT to replace its reliance on custom code by configuring synchronization rules within the FIM portal. These rules, referred to as codeless provisioning, apply to the object and attribute flow between FIM 2010 and connected data sources. Microsoft IT eliminated many of the costs associated with custom-coded applications by migrating the business logic and functionality of those applications to FIM 2010 configuration.

The use of codeless provisioning also improved system performance through a change in the identity management architecture. With ILM 2007, changes to user and group data flowed from the custom group management application, to AD DS, to ILM 2007, and then back again to AD DS. With FIM 2010, data flows directly from the FIM user portal, to the FIM 2010 synchronization engine, to AD DS. Figure 6 illustrates the data-flow differences between ILM 2007 and FIM 2010.


Figure 6. Data-flow comparison


Before FIM 2010, no unified method and architecture existed for defining policies throughout the identity management infrastructure. FIM 2010 enabled Microsoft IT to use MPRs to define policies that take advantage of standard development tools such as Windows Workflow Foundation (WWF).

Microsoft IT uses MPRs to create policies expressed and enforced throughout the identity management infrastructure. For example, Microsoft IT might create a provisioning policy to ensure that new employees receive an AD DS account, receive an Exchange mailbox, become a member of a particular security group, and receive remote access.

Custom Activities

The .NET extensibility available in FIM 2010 enabled Microsoft IT to develop custom activities when it needed extra functionality because an MPR could not satisfy Microsoft-specific business rules. For example, Microsoft added a custom activity called FTE Groups to enforce a business rule that only full-time employees can create groups. Custom activities are reusable as needed.


In accordance with standard Microsoft software development practices, Microsoft IT deployed a pre-release version of FIM 2010. This practice served two important functions:

  • It provided a field test of FIM 2010 in a production environment.

  • It provided a field test of the migration of a large, custom group management application to FIM 2010 while maintaining business continuity and smoothly transitioning to the new system.

This approach helped Microsoft shape the final FIM 2010 configuration, identify best practices, and provide support staff with invaluable experience using FIM 2010 before it was generally available.

Note: The following sections describe the steps that Microsoft took during the pre-release phase of the deployment. The final deployment of FIM 2010 throughout the Microsoft enterprise will occur in the coming months.

Because the deployment of FIM 2010 was a major effort, the Microsoft IT deployment team included members from both Microsoft IT and the FIM product development group. The deployment team included software engineers, project managers, product managers, operational analysts, service managers, and technical writers. Each member of the deployment team played an important role and brought his or her unique viewpoint and understanding to the process.

The deployment team was very methodical in its planning, diligently accounting for every new feature and piece of functionality. Over the course of the deployment, the team revised the project plan more than 50 times.

Initially, the deployment team met three times a week to identify a specific set of milestones, defining functionality and goals for each milestone. After the team completed the majority of the planning, it was able to reduce its weekly meetings to two. This reduction allowed more time to execute the deployment plan.

Setting up Environments

Throughout the deployment, the deployment team tested changes to FIM 2010 software, as well as customizations and configuration settings, in lab and staging environments before migrating changes to the production environment. Generally, the team used the FIM 2010 Configuration Migration tool to migrate configuration changes and manual migration for environment changes such as custom activities.

Figure 7 illustrates the flow of software and customization changes through the server environments.


Figure 7. Deployment server environment

Lab Environments. The deployment team used the Microsoft IT lab environment to apply customization and configuration changes to FIM 2010 software. The FIM product group used the FIM lab environment for the initial development and testing of beta software builds.

Microsoft IT Staging Environment. The deployment team moved customization and configuration updates and new software builds from the lab environments to the Microsoft IT staging environment for acceptance testing. When the deployment team was satisfied with the results, it backed up the software, configuration settings, and database for migration to the Microsoft IT production environment.

Microsoft IT Production . All FIM 2010 software changes, customization, and configuration settings installed in the Microsoft IT production environment would be available to the end users who participated in the pre-release deployment. The deployment team backed up FIM 2010 changes in the production environment to the lab environment, replicating the most current production software.

Customizing FIM 2010 Software

An important aspect of the FIM 2010 deployment was the customization of FIM 2010 to satisfy Microsoft business rules and requirements, extend functionality, and automate existing processes. The following sections describe the highlights of the customization effort.

Alias Manager

Microsoft has specific business requirements for setting up group aliases. To satisfy these requirements, the deployment team created a custom activity that automatically reserved and released alias during new group creation. If a user tries to create a group by using an alias that is already in use, an error occurs with a message that asks the user to try again.

Dynamic Groups

With the deployment of FIM 2010, the deployment team is developing custom activities for managing dynamic groups. The team is deploying this new functionality is in a targeted way, focusing on "Reports To " and organization-based distribution groups. This approach will provide end users with a smooth transition from their current process to solution supported by Microsoft IT.

Group Life-Cycle Management

Before FIM 2010, keeping group memberships up to date was a manual process completed at the discretion of group owners. With FIM 2010, Microsoft IT automated the process using a custom activity called at group creation. The activity sets a group to expire after a certain amount of time and sends update notices at programmed intervals based on business requirements.

Hidden Groups

Microsoft IT created a custom activity to satisfy Microsoft business requirements for creating hidden distribution groups. For example, Human Resources needed hidden groups when working with salary information. The custom activity enabled end users to create two types of hidden groups: groups with visible names in the GAL but hidden members, and groups with hidden names and members. End users can create hidden groups from the FIM user portal using special check boxes available during the group creation process.

Password Reset

When implementing the FIM 2010 password reset feature, the deployment team configured 21 logon security questions for end users to answer when registering for password reset. Microsoft IT ensured user ID integrity through extensive research of industry standards provided by sources such as the Gartner Group.

Migrating Group Data to FIM 2010

One of the major tasks in the enterprise-wide deployment of FIM 2010 was the migration of a custom group management application to FIM 2010. This was a substantial task involving more than 400,000 distribution/security groups and approximately 175,000 end users.

Running Applications in Parallel

For the pre-release phase of the deployment, Microsoft IT set a migration goal of approximately 53,000 users and 90,000 groups. To accomplish this goal, Microsoft IT needed to make a fundamental decision about its migration approach: conduct a one-time migration from the custom group management application to FIM 2010, or conduct a phased migration and run both applications in parallel.

For business continuity, including keeping the Microsoft e-mail system running at all times, the deployment team decided to perform a phased migration and run the custom group management application and FIM 2010 in parallel. Figure 8 illustrates the architecture that Microsoft IT used during the migration of group data.


Figure 8: FIM 2010 migration architecture

When the group migration of data is completed, Microsoft IT will be able to retire the custom group management application and remove it from the identity management architecture. Figure 9 shows the FIM 2010 post-migration architecture.


Figure 9. FIM 2010 Post-Migration Architecture

There were several advantages in using a phased migration. Although this approach was more time-consuming than a one-time switch to FIM 2010, it was far less risky because the deployment team could always roll back to the custom group management application. Additionally, the phased approach made it easier to provide just-in-time training to new users, a key part of the deployment plan.

Although the decision to run parallel applications made the most sense to maintain business continuity, a phased, parallel migration was not necessarily the easiest solution. The deployment team learned that the custom group management application did not work well with other technologies, including FIM 2010. The deployment team faced another fundamental decision: Modify the custom group management application, which would have required several weeks of development time, or design a new, more cost-effective process. The team chose the cost-effective solution, devising a way to migrate groups without having to make extensive code changes.

Note: Any organization that already has a group management solution in place (whether a custom application, a third-party add-on, or a set of specialized scripts) will want to choose between a phased, parallel migration to maintain business continuity and a one-time migration. The best choice varies from one organization to another.

Using Phases for the Migration Process

The deployment team migrated group data in three phases, starting slowly but increasing speed as it moved to the next phase. At each phase, the deployment team significantly improved the migration process by increasing the number of groups migrated to FIM 2010.

In the first phase, the deployment team installed FIM 2010 in the Microsoft production environment, but it granted access to only a small number of individuals from the product development team. Because these individuals were already familiar with FIM 2010, they were a logical first choice that provided invaluable expertise as the deployment team learned from their successes and took care to minimize risks to the Microsoft production system.

The deployment team manually moved group data from the custom group management application to FIM 2010 during the first phase of migration. When the deployment team was satisfied with the results of the first phase, it moved to the second phase by using a semi-automated process. By the third phase, the deployment team fully automated the migration.

During the first phase, the manual stage of the group migration process, the deployment team used the Microsoft Active Directory Users and Computers (ADUC) snap-in to move groups from the custom group application organizational unit (OU) to the FIM OU. When the deployment team was satisfied with the results, it moved to the second phase. Here, the migration process was partially automated using scripts and an ILM-based tool. During the third phase of the migration, the process matured to a system where all groups are viewable in both applications and automatically moved to the FIM OU.

Using a Data-Driven Approach to Identify Migration Candidates

Using a strict data-driven and methodical process to identify the best migration candidates, users and groups were migrated in an orderly manner. Although this planning was time-consuming, it resulted in a seamless process that required little data cleanup after the migration.

Groups were migrated by identifying organizations, then users within each organization. This method filtered out any groups that were not being migrated at that time in the deployment. For example, groups with involvement in SOX were not migrated during the pre-release phase of the deployment. Security groups were also not migrated during the first and second phases. The deployment team filtered groups through an analysis of their metadata based on pre-defined criteria. The criteria included factors such as group associations with legislative control such as SOX or HIPAA, and type of group. Table 1 summarizes the group criteria.

Table 1. Sample Matrix for Identifying Group Migration Candidates

Group name

Type of group

Legislative association

Migration candidate


Security group




Distribution group



Important SOX group 1

Distribution group



Microsoft IT assigned a migration priority based on the results of the metadata analysis. This priority provided an orderly method for migrating data by organization. The deployment team moved through the organizations within Microsoft as follows:

  1. Communicate migration plans to the end users within the organization.

  2. Provide FIM 2010 training to end users.

  3. Complete the migration of group data from the custom group management application to FIM 2010.

  4. Evaluate migration results and correct any problems.

  5. Progress the next organization.

Migration Tools and the Notification Process

Migrating data from the custom group management application to FIM 2010 involved special tools and notification processes. Maintaining data integrity during the migration process was the deployment team's first consideration. To achieve this goal, the team had to devise a way for the group management application and FIM 2010 to coexist without compromising group data. In other words, users needed to be able to view groups in both applications, but edit from only one.

The deployment team accomplished this by using Active Directory OUs and read/write and read-only functionality. The group management application mastered pre-migration groups. FIM mastered post-migration groups. Briefly, the deployment team created one OU for the group management application and one OU for FIM 2010. It set each OU with permissions to allow only the application managing a group to write to the respective OU. AD DS was the master for both OUs. Figure 10 illustrates the approach that the deployment team used to maintain data integrity throughout the migration process.


Figure 10. Data integrity during migration

Using FIM2010 functionality, the deployment team automatically notified group owners when their group data had been migrated from the group management application to FIM2010. More specifically, the deployment team created an MPR that triggered an e-mail message that welcomed the owner to the FIM 2010 deployment.

Installing FIM 2010 Client Software by Using Configuration Manager

The deployment team installed the FIM Client software, including the Outlook Add-in feature, at the same time as the migration of group and user data. The goal was to design an installation program that provided a one-click user experience. To accomplish this goal, the deployment team designed and implemented the installation process in two stages. The first stage followed a self-hosting model in which end users started an installation program from the FIM 2010 user portal. This installation program was a script-enhanced version of the base installation that the FIM 2010 product group provided. Although this method worked during the beginning of the deployment process, it was not scalable for the entire Microsoft enterprise.

Therefore, in the second stage, the deployment team switched to Microsoft System Center Configuration Manager (SCCM) to solve two key issues:

  • Installing FIM 2010 client software on existing computers

  • Installing FIM 2010 client software on new computers added after the deployment

The deployment team decided to focus on the first issue and wait until after the completion of the pre-release phase of the deployment to solve the second issue. The team took advantage of the deployment time to develop a strategy for distributing the client to all of Microsoft and sustaining the effort in the future.

In the second stage, the deployment team defined the following dependencies of the installation program:

  • Verifying that someone from Microsoft is installing the software

  • Identifying whether Outlook is running, because it must be closed

  • Checking for minimum disk space to prevent the system from going to zero disk space during the installation

  • Checking for the Microsoft .NET Framework

  • Determining whether the user qualifies for the installation based on software and domain

The deployment team used the program dependencies, along with FIM binaries and installation scripts, to create a SCCM agent for deploying the FIM client software. The Configuration Manager agent included postponement notifications, pop-ups, and opt-out options, which are very helpful in the lightly managed environment at Microsoft. The deployment team targeted the Configuration Manager installation to specific users, based on the participants in the group migration. The team created a collection (association of end users to computers) in Configuration Manager. An advertisement based on the collection encouraged end users to install the FIM 2010 client software. Using SCCM provided an effective and easy method for deploying client software.

Determining Migration Scale and Load

Because the migration of group data was a very large undertaking, the deployment team estimated scale and load requirements of FIM 2010 to identify possible adverse impacts to performance. When determining scale requirements, the team considered the following elements:

  • Number of groups and users

  • Impact of the configuration, taking into account new functionality such as the dynamic group tool

  • Impact of policy objects

To determine load requirements, the main factors that the team considered and estimated included:

  • Usage for a particular number of users

  • Number of groups and users

  • Number of requests to join or leave groups

  • Number of static versus dynamic groups

  • Requests to register for password reset

The team also considered overall usage patterns at Microsoft. It created a load profile from all of the gathered information. For additional information about determining scale and load requirements for an organization, refer to the Capacity Planning guide at http://technet.microsoft.com/en-us/library/ff400279(WS.10).aspx.

Training and Supporting the User Base

An important aspect to the success and acceptance of FIM 2010 was making sure that Microsoft end users received the training that they needed to use the new system. Because of the number and location of users—approximately 175,000 in 83 countries—training needed to be available on a large scale in several different languages.

Live Training

In the first two phases of end-user deployment, a project manager and senior systems engineer delivered live training sessions to audiences of up to 50 people. They delivered two types of training: one for administrative users and one for general end users. The training used a train-the-trainer model, in which a select group of users learned how to provide instruction to their peers. Helpdesk staff was also engaged in the training.

To accommodate busy schedules that often made it difficult to schedule training, brown bag sessions provided training in an informal setting during non-peak work hours. The training focused on the "how-to," walking users through procedures such as creating distribution and security groups, adding and removing members, performing bulk deletion of members, and resetting passwords. Seeing the value of the new FIM 2010 user portal helped end users easily transition to the new tool.

Self-Teaching Approach

Because the user base for FIM 2010 was so large, providing live training for all employees was impossible. After the deployment team felt comfortable that it had received enough feedback for a solid understanding of what worked best during a training session, it progressed to a self-teaching approach. The team incorporated the feedback into a training session that it recorded and placed on the Microsoft intranet. In addition, a FAQ sheet and "how to " instructions were made available on the FIM 2010 user portal.


Along with providing training for end users, another important step in the deployment of FIM 2010 was to establish the appropriate levels of support. The deployment team followed a three-tier technical support model. Helpdesk would provide tier 1 support, triage engineers would provide tier 2 support, and the development engineers would provide tier 3 support.

Lessons Learned and Best Practices

Adding FIM 2010 to the identity management infrastructure at Microsoft required extensive coordination, planning, and administration on the part of Microsoft IT. The lessons learned from this experience included the following:

  • System architecture changes that improve the flow of user and group data can enhance overall performance.

  • Replacing earlier applications that are widely used in an enterprise can be difficult due to retraining and adjustments to work processes.

The following best practices come from Microsoft IT working closely with the product group through the effort to deploy a pre-release version of FIM 2010:

  • Understand the current system. Before beginning an upgrade project, an organization should take time to understand the current system. It is helpful to map the features in the current system to FIM 2010 features and functionality. Although this effort may take more time up front, it can save a great deal of time overall and help to ensure that end users are satisfied with the new system.

  • Define business rules and requirements before beginning the upgrade. By doing so, an organization can design, develop, and implement configuration and customization efforts to meet its specific needs.

  • Write a design document for FIM configuration. When developing the FIM configuration, an organization should document the design and approach of the configuration to maintain a record of decisions made.

  • Follow best practices for SQL Server configuration. The physical deployment of FIM 2010 components and the hardware on which they run are important factors in determining overall performance. An organization should configure them according to established best practices for high performance.

  • Plan the group migration process. Before migrating existing group data to FIM 2010, an organization should plan the process. It should consider the following points in the planning:

    • Determine the best migration scenario: a phased, incremental approach or a one-time switch to FIM 2010.

    • Incorporate existing methods for tracking groups into the migration process. For example, an organization could be using a custom group management application (such as the one used at Microsoft) or a spreadsheet.

    • Incorporate the database that contains group information. If such a database does not exist, the organization can create one by data mining AD DS.

  • Plan how data will co-existence before rollout. When using a phased approach for the migration of group data from a custom group management application to FIM 2010, an organization should consider how to manage the group data when more than one application has authority for data in a single data source. Co-existence of data allows each application to be the master of its own managed data.

  • Plan how to differentiate groups during migration. Before beginning the migration of group data, an organization should plan the approach that best suits its needs. An alternate approach to the OU method described in this document is to use an attribute value to differentiate groups. Moving groups to a different OU can affect small applications that are sensitive to the group OU location.

  • Start with a pilot deployment. An organization should consider piloting the group migration effort, even if it is using a one-time switch to FIM 2010. A pilotis an excellent means for working out bugs in the process and involving end users early on. End-user feedback gathered during the initial phase of a deployment can help to ensure end-user satisfaction with both the deployment experience and the FIM 2010 product.

  • Minimize re-synchronization. When implementing codeless provisioning, an organization should plan the implementation of configuration rule changes ahead of time to minimize the number of times that re-synchronization is required.

  • Train users before migrating groups. End-user training is an important component of most deployment projects. A successful migration of group data to FIM 2010 partially depends on making sure that end users know how to use the new product. Consider the numbers users when developing a training plan and determining the most appropriate training methods.

  • Use SCCM to deploy client software. SCCM is an easy way to notify end users of the FIM 2010 software upgrade during deployment of the client software.


Microsoft IT continually strives to enhance and simplify its identity management solution. The planning and deployment of FIM 2010 gave Microsoft an opportunity to implement new features and functionality that provide business value and streamline the overall identity management ecosystem.

Microsoft IT's next steps for identity management will include implementing automated, codeless user provisioning by using user management features and functionality in FIM 2010. This effort will streamline key business functions while consolidating several older tools in the process. Microsoft IT will be able to:

  • Integrate user management and self-service across enterprise applications. For example, empower users and improve data accuracy by allowing them to manage their own identity information, such as mobile phone numbers. This will also free IT staff time for other tasks and avoid the coding of business rules or recoding of the older systems.

  • Configure provisioning rather than write customized code, as was the case in previous releases of the Microsoft identity management solution. Using configured provisioning will automate many of the workflows associated with adding new users and providing access to applications.

FIM 2010 enabled Microsoft IT to improve processes and reduce costs through self-service tools, enhanced policy management, automated processes, and the elimination of custom-code applications that were expensive to maintain. Microsoft IT also worked closely with the product group that developed FIM 2010. Microsoft IT's deployment experience provided invaluable feedback that contributed to the final configuration of FIM 2010 and demonstrated its technical viability within the Microsoft enterprise environment.

For More Information

For more information about Microsoft products or services, call the Microsoft Sales Information Center at (800) 426-9400. In Canada, call the Microsoft Canada information Centre at (800) 563-9048. Outside the 50 United States and Canada, please contact your local Microsoft subsidiary. To access information through the World Wide Web, go to:



The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.


Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred.

© 2010 Microsoft Corporation. All rights reserved.

Microsoft, Active Directory, Forefront, Outlook, SharePoint, SQL Server, Windows, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

All other trademarks are property of their respective owners.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
© 2015 Microsoft