FIM Sync Troubleshooting: stopped-dll-exception: The following error occurred while using Kerberos authentication

  • Article

 

  

Overview

The goal of this wiki is to share information concerning the "stopped-dll-exception" error when exporting to Microsoft Exchange 2010. This particular wiki will cover another exception that we encountered with the stopped-dll-exception and WinRM.

In this particular case, we were exporting to Microsoft Exchange 2010 from an Active Directory Management Agent (AD MA). You can also see this issue occur with the Active Directory Management Agent for GALs ( GalSync MA). In both cases you will be configuring the management agent to export to Microsoft Exchange 2010.

In most cases that we have seen this error, it is in a configuration where there is a Microsoft Exchange 2010 Client Access Server Array.

  

Problem Statement

Exporting to Microsoft Exchange 2010, you notice the status displays a stopped-dll-exception. You review the Application Event Log because there is no further information in the FIM Synchronization Service Manager Console. You discover the following text in an error with the source of FIMSynchronizationService:

  

Application Event Log

There is an error in Exch2010Extension BeginExportToCd() function.Type: System.Management.Automation.Remoting.PSRemotingTransportException

Message: Connecting to remote server failed with the following error message : WinRM cannot process the request. The following error occurred while using Kerberos authentication: The network path was not found.

Possible causes are:

  • The user name or password specified are invalid.
  • Kerberos is used when no authentication method and no user name are specified.
  • Kerberos accepts domain user names, but not local user names.
  • The Service Principal Name (SPN) for the remote computer name and port does not exist.
  • The client and remote computers are in different domains and there is no trust between the two domains.

After checking for the above issues, try the following:

Check the Event Viewer for events related to authentication.

Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.

Note that computers in the TrustedHosts list might not be authenticated.

For more information about WinRM configuration, run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic.

  

Cause

WinRM is experiencing a problem communicating with the Microsoft Exchange 2010 Client Access Server Array. The reason for this is because there is some sort of configuration problem either with SPNs, the URI, or permissions.

  

Resolution

To resolve this issue, you will need to ensure the following:

  1. The AD MA or GalSync MA User Account is part of the Exchange Organization Management Security Group or Organization Management Role in the Microsoft Exchange 2010 Console. 

    Review the Microsoft TechNet Wiki on the Permissions needed for a GalSync User.

  2. Ensure that the URI specified for the /PowerShell vdir on the Configure Extensions tab of the Management Agent properties window. 

    1. You can review the Microsoft TechNet Wiki on How to acquire the Microsoft Exchange 2010 CAS information.
    2. You may need to review the information on Microsoft TechNet for Get-ClientAccessArray to get the array information.

  3. Ensure that the Service Principle Name is setup correctly.  Recommendation is to follow the information in this blog called Setting up Kerberos with a Client Access Server Array Exchange 2010 SP1.

  

Additional Information