Plan the migration from your test environment to your production environment.
- Proper setup of Microsoft® Forefront Identity
Manager (FIM) 2010 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 Technical Library on the Microsoft Web
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
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 service account. For more information,
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.
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
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 Technical Library on the Microsoft Web
Test your back up and restore procedures for Microsoft Forefront Identity Manager.
- Regular backup procedures are essential for
protecting your data from accidental loss. It is also strongly
recommended that you test your backup and restore procedures before
an emergency occurs. To back up and restore FIM, use the backup
tools provided with Windows Server® 2008 operating system
and SQL Server. For more information, see Backing up Forefront
Identity Manager and Restoring Forefront
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
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
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
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 Managerand Restoring Forefront
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
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
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
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
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
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.
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
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
- 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