Compartilhar via

Forefront Identity Manager 2010 R2 Best Practices General

  • Artigo

Plan the migration from your test environment to your production environment.

  • Proper setup of Microsoft® Forefront® Identity Manager (FIM) 2010 R2 in your test lab and careful planning of your migration from test lab to production is essential to minimizing deployment problems. It is recommended that you use a small test environment, in order to not waste time processing thousands of objects when you test new rules. For detailed documentation, refer to the FIM 2010 R2 Technical Library on the Microsoft Web site.

Back up your initial test environment.

  • After installing FIM and creating your management agents, back up the FIM SQL Server database. Then, you can recreate a fresh test environment at any time by loading the backup database.

Important

If you have made any modifications to any of the management agent rules or the metaverse rules since the last backup, those modifications are not saved. Back up the FIM SQL Server database every time you modify your rules

Back up your encryption keys.

  • After installing FIM, make a backup copy of the encryption keys. You need a copy of the encryption keys to restore from a back up, or to change the Microsoft Forefront Identity Manager 2010 R2 service account. For more information, see MIISkmu: Encryption Key Management Tool.

Install Microsoft Forefront Identity Manager and SQL Server in the same domain.

  • During FIM Setup, the remote database access depends on the access rights of the current logon account that you are using to run Setup. Ensure that the server running Windows Server® 2008 operating system that hosts FIM and the server that hosts SQL Server are in the same domain and that the account that you are using to run Setup has access rights to the server that hosts SQL Server.

Set access rights if SQL Server is installed on a remote server.

  • If you install SQL Server on a remote computer, that is, on a different computer than the one running FIM, be sure that the policy for the SQL Server service account allows users access to that computer from the network. If access is not allowed, FIM setup will fail.

Important

If you install SQL Server on a remote computer and allow network access to the remote computer, you will receive a security warning from FIM setup. For this scenario, the warning can be ignored

Specify the TCP/IP port for a remote server running SQL Server.

  • If the SQL Server instance that you specify during FIM Setup is on a remote computer, FIM Setup uses the default TCP/IP port. If you want to specify a different port, you must use the SQL Server Client Network Utility and the Server Network Utility tools provided with SQL Server. For more information, see the SQL Server Books Online.

Configure the Microsoft Forefront Identity Manager database to use the Full recovery model.

  • If recovery of the SQL Server database to the time of failure is required, then the recovery mode on the FIM 2010 R2 Synchronization Service database needs to be set to Full. By doing this, you can completely recover the database to the point of failure or to a specific point in time. For detailed documentation, refer to the FIM 2010 R2 Technical Library on the Microsoft Web site.

Test your back up and restore procedures for Microsoft Forefront Identity Manager.

Use Export Management Agent to backup management agents whenever you change management agent rules.

  • After you use Export Management Agent, you can then use the Import Management Agent command to import a specific version of the individual management agent. You can also export and import management agents by using the Export Server Configuration and Import Server Configuration commands, but doing so imports all management agents in addition to the metaverse schema. For more information, see Configuring Management Agents and Importing and Exporting a Server Configuration.

Populate the displayName attribute in the metaverse to make search results easier to identify.

  • When listing objects by using Metaverse Search, FIM returns results identified by the displayName attribute. If the displayName attribute is not populated, the search results are identified by the globally unique identifier (GUID). For more information, see Using Metaverse Search.

Design your flow rules to act upon the state of an object.

  • Use the state of an object to determine the next step in synchronizing the object rather than using the event that caused the object state. Do not rely on declarative rules or rules in a rules extension to be evaluated in a specified order when synchronizing an object. Rules are evaluated in an unordered fashion.

Disable provisioning when you migrate connected data sources to the metaverse for the first time.

  • When you deploy FIM for the first time, it is recommended that you migrate and join all connected data sources before you enable provisioning. After you have verified that everything has been successfully migrated and joined, you can enable provisioning and run a Full Synchronization of the management agents to apply the provisioning rules to all connected objects. For more information about provisioning, see Provisioning Rules.

Stage objects to the connector space before applying changes to the metaverse.

  • When you run a full import with a file-based management agent and you use an incorrect custom data input file, it can result in a large number of unwanted deletions in the metaverse, which requires a full restore of the server running FIM. When you run a full import with a file-based management agent, it is strongly recommended that you configure the management agent to use the following two run profiles: the first run profile is configured as a Full import (Stage Only) and the second run profile is configured as a Delta Synchronization. By using this configuration, you can verify that the correct data is being imported before it is written to the metaverse. You should run the second run profile only after you have verified the staged data in the connector space. For more information about creating a run profile, see Create a Management Agent Run Profile. For more information about backing up and restoring the server running FIM, see Backing up Forefront Identity Manager 2010 R2and Restoring Forefront Identity Manager 2010 R2.

Set a deletion threshold in your run profile steps to limit the number of accidental deletions.

  • Use the deletion threshold setting to limit the number of accidental deletions that can occur during import or export. The deletion threshold will stop the management agent, or prevent it from starting, when the threshold limit is reached. For more information, see Configuring Management Agents. Alternately, you can use a Visual Basic Scripting Edition (VBScript) script to calculate the delete ratios during a management agent run. For more information, see the FIM Developer Reference.

Use Search Connector Space to examine objects.

  • With Search Connector Space, you can search for objects in the connector space for a management agent. You can locate objects by name or error status, or by the state of the object (that is, whether it is connected, disconnected, or waiting to be imported or exported). For more information, see Configuring Management Agents.

Use Preview to test synchronizations and troubleshoot errors.

  • With Preview, you can run test synchronizations and view the results without committing the changes to the metaverse. You can also use Preview to test new rules extensions and to troubleshoot synchronization errors due to join failures or schema violations. For more information, see Using Preview.

Schedule your management agents.

  • You can run management agents automatically by using a Windows Management Instrumentation (WMI) script. For more information about writing WMI scripts for FIM, see the FIM Developer Reference.

Schedule a recurring run profile using the Delta Synchronization step to process disconnectors automatically.

  • Objects that fail to join are not reevaluated by the Delta Import and Delta Synchronization run profile step and might remain as disconnectors. Running a Delta Synchronization step on a regular basis will reevaluates and processes these disconnectors. For more information about run profile steps, see Configuring Management Agents.

Save and clear the management agent run history in Operations regularly.

  • Operations records a history of every management agent run. Each management agent run history is saved in the SQL Server database, and can cause the database to grow over time, affecting performance. The run history can be saved using Operations or a WMI script. For more information, see Using Operations and the FIM Developer Reference.

    Important

    Deleting very large numbers of runs at once make take considerable time. it is recommended that you delete no more than 100 runs at a time.

Use multiple partitions in a management agent to control synchronization of single object types.

  • To control synchronization of single object types in a file-based management agent, create a partition for each object type. For example, to synchronize the object types mailbox and group, create two partitions in the management agent, and assign mailbox to one partition and group to the other. Then, create a management agent run profile for each partition. With this configuration, you have one management agent with the flexibility to synchronize one or both of the selected object types. For more information about using partitions, see The Metaverse and the Connector Space.

Create alternate object types in the metaverse to avoid attribute precedence conflicts where connected data sources are using the same object types, and have both import and export attribute flow rules on the same attributes.

  • In the case where connected data sources are synchronizing object types by way of the same connector space and metaverse object type, one connected data source has precedence for attribute flow, thus limiting synchronization between the connected data sources. It is recommended that you create new object types in the metaverse to solve these conflicts.

  • For example, you might have a situation where two connected data sources, A and B, both synchronize contact object types. Without alternate object types, they would both have rules configured to flow attributes from each data source object type to a single metaverse object type for import and export. Because one data source needs to have highest precedence, all export attribute flows on these objects do not occur if changes are received from the lower precedence data source. To resolve this, you can create the object types contact_a and contact_b in the metaverse. Use contact_a to synchronize the contact objects from the one connected data source, and use contact_b to synchronize the contact objects from the other connected data source. Each object would be managed primarily from their originating connected data source. For more information about creating object types in the metaverse, see Create an Object Type. For more information about attribute precedence, see Attribute Flow Rules.

  • You can also configure manual precedence on all attribute flows instead of creating alternate object types. In this case all precedence must be handled within rules extensions. For more information about manual precedence, see Attribute Flow Rules.