Cause: SQL Server introduces Secure Sockets Layer (SSL) encryption through the use of certificates. If SQL Server finds certificates on the local computer, SQL Server attempts to use the certificates. If the certificate is not issued to the fully qualified domain name of the computer, SQL Server considers the certificate invalid. If multiple certificates are on the computer, there is no way to pick which certificate SQL Server must use.

Solution: Remove the existing personal certificates.

To remove the certificates:

1. Click Start, click Run, type mmc, and then click OK.

2. Click File, click Add/Remove Snap-in, click the Standalone tab, and then click Add.

3. Select Certificates, and then click Add.

4. Select Computer account, click Next, select Local computer, click Finish, click Close, and then click OK.

5. Expand Certificates (Local computer), and then click Personal.

6. Delete all certificates.

See also: Article 309398, "SQL Server 2008 Installation or Local Connections Fail with "SSL Security error :ConnectionOpen (SECDoClientHandshake())" Error Message," in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkID=8809).

Cause: In cases where the distinguished name (also known as DN) and the selected anchor attribute are the same, SQL Server attempts to build the distinguished name first. If the anchor attribute is missing, or SQL Server is unable to read the anchor attribute, then it fails to build the distinguished name and generates the error message "Missing anchor component."

Solution: Verify that the anchor attribute exists and is valid in the file.

Cause: Some connected data sources might have policies that affect the values that an attribute can have. For example, Active Directory might have a policy that affects the userAccountControl attribute. You can export the value 0x202, but Active Directory writes the value 0x222. On the next import, the confirmation of the value fails with the error "exported-change-not-reimported."

Solution: Modify the rules extension code so that the exported value matches the requirements of the connected data source.

Cause: When Lightweight Directory Access Protocol (LDAP)-based directories, such as Active Directory, receive an empty string in an attribute change operation, they typically delete the attribute, causing the error message "exported-change-not-reimported."

Solution: This is expected behavior for LDAP-based directories, such as Active Directory. You can also create a scripted attribute flow with a rules extension to determine when to flow attribute with empty strings. For more information, see Attribute Flow Rules.

Cause: The server running FIM might have been renamed, and the new computer name does not match the existing name in the database.

Solution: Synchronize the database with the computer name by running the Miisactivate.exe tool. For more information, see MIISactivate: Server Activation Tool.

Cause: If you trying to connect to a server running Sun ONE Directory Server or Windows Server® 2008 operating system using Secure Sockets Layer (SSL), then the target server does not have SSL configured.

Solution: Configure the target server for SSL.

Cause: The FIM Synchronization Service service account does not have the CA Certificate installed. Even though your SSL bind may be successful, the management agent runs in the context of the FIM Synchronization Service service account, and may fail without the CA Certificate installed.

Solution: Install the CA Certificate on the FIM Synchronization Service service account.

Cause: If you are synchronizing between two Windows 2000 forests, then the DNS forwarder is not configured correctly.

Solution: Configure the DNS forwarder as described in the GAL Synchronization scenario documentation.

Cause: Most management agents (the management agent for Active Directory is the exception) do not retain their deletion watermarks after the full import process.

Solution: Run a full import to completion on the management agent.

Cause: The "Enable Non-Standard Client Scheme Compatible Mode" flag was not enabled in eDirectory so FIM could not import the schema from eDirectory.

	Note
	This is the default setting in eDirectory

Solution: On the properties page of the LDAP server in eDirectory, ensure that the check box labeled "Enable old ADSI and Netscape schema output" under the "Searches" tab is enabled.

	Note
	The text can differ depending on the version of eDirectory.

Cause: Certain synchronization activities result in the creation of temporary error conditions that are eventually resolved once the synchronization has had the opportunity finish running. In environments where extremely large numbers of objects are being processed the number of these errors may exceed the default error limit of 5000 causing the synchronization process to terminate before it has finished processing all objects.

Solution: Increase the error limit to a sufficient value so that synchronization can finish processing all objects before the error limit is reached. Given the opportunity to finish, the synchronization process will eventually resolve the temporary error conditions. The error limit is configured by adding the ErrorLimit (REG_DWORD) entry to the following registry subkey:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\FIMSynchronizationServices\Parameters

The value is an integer in the range of 0-100000.

• Value set to 0 = Error limit set to 100000
  
  
• Value in the range of 1-99999 = Error limit set to value
  
  
• Value set to 100000 = Error limit set to 100000
  
  
• Value set greater than 100000 = Error limit set to 100000
  
  
• No key present = Default error limit set to 5000
  
  

	Note
	The FIMSynchronizationService service must be restarted after modifying this registry key.