OVERVIEW / PURPOSE

The purpose of this wiki is to provide guidance on how to troubleshoot export problems. The main focus here will be exporting to Active Directory where Microsoft Exchange 2007 / 2010 is involved. However, you can put these practices to use to help troubleshoot exporting to other connected data sources.

TROUBLESHOOTING EXPORT ISSUES

We need to understand if we have provisioning enabled for Microsoft Exchange 2007 or Microsoft Exchange 2010 when exporting to Active Directory. This is important because of the steps involved in exporting to Microsoft Exchange 2007 and/or Microsoft Exchange 2010.

Microsoft Exchange 2007 and Microsoft Exchange 2010 no longer utilize the Recipient Update Services (RUS) that previous versions of Microsoft Exchange utilized. Microsoft Exchange 2007 and Microsoft Exchange 2010 utilize a Microsoft Exchange PowerShell CMDLET called Update-Recipient ( 2007 / 2010 ). How we call Update-Recipient ( 2007 / 2010 ) varies between the two Microsoft Exchange Servers.

Microsoft Exchange 2007 we call Update-Recipient locally on the Synchronization Service Server. This is the reason that the Microsoft Exchange 2007 Management Tools SP1 or later (preferred SP3) is installed on the Synchronization Service Server.

Microsoft Exchange 2010, we make a remote call from the Synchronization Service Server to the Microsoft Exchange 2010 Server using WinRM.

TYPES OF EXPORT ERRORS

GALSYNC SOLUTION (New GalSync Solution - Successful Export): You have developed a new GalSync Solution and when exporting, you receive 0 records exported and it is a successful export without errors. While Microsoft Exchange is involved, this is not normally associated with the version of Microsoft Exchange. This is a known issue, and documented here.
GALSYNC SOLUTION (New GalSync Solution - Export Fails stopped-dll-exception): This is an indication that you are exporting to either Microsoft Exchange 2007 and/or Microsoft Exchange 2010. If this is a brand new solution, then the first thing to check is to ensure that you have all of the prerequisites setup to be able to export to Microsoft Exchange 2007 and/or Microsoft Exchange 2010. You can find information surrounding the prerequisites for exporting to these Microsoft Exchange Servers.
1. Provisioning to Microsoft Exchange 2007
2. Provisioning to Microsoft Exchange 2010
GALSYNC RELATED EXPORT ISSUES:
2. Export Errors: permission-issue: Insufficient access rights to perform the operation
EXPORT ERROR ( timeout error ): A timeout error can happen a couple different ways. We have seen a timeout error occur when exporting to Microsoft Exchange 2010. In most cases, this has been seen as an issue with the Exchange 2010 URI. If this type of timeout error occurs, it will most likely have nothing exported. You could see a user with a timeout error as well.
EXPORT ERROR ( stopped-dll-exception ): For an export error with "stopped-dll-exception" you can find more detailed information by viewing the Application Event Log. There we could see a Bail Error, or other set of errors. Pending the type of error, could be different resolutions.

TROUBLESHOOTING THE EXPORT ERRORS

VERSION OF EXCHANGE: Are you provisioning to Microsoft Exchange 2007 or Microsoft Exchange 2010?
1. If yes, then ensure that you have the prerequisites installed. ( Provisioning to Microsoft Exchange 2007 / Provisioning to Microsoft Exchange 2010 )
WAS IT WORKING: If this was working, and then stopped, did anything change in the Microsoft Exchange environment recently?
1. If yes, then check to see what that change was, and see if you need to make any changes in the Synchronization Service Engine and then test your export process again.
PERMISSION ISSUE: A permission issue is exactly that! It is an indication that the Active Directory Management Agent account does not have permission to write to the specified object, or the location where the object resides. You will need to go to that OrganizationalUnit and/or Object to ensure that the permissions are set correctly.
1. If this is a GalSync Scenario, you may want to check the Permissions of the GalSync User.
TEST EXPORT - (Export to Drop File): Find information about Exporting to a Drop File here.
1. Exporting to a drop file is a way to test the actual exporting of data. If exporting to a drop file is successful, this tells us that the problem is in the export process to the Active Directory ( The Connected Data Source ) or the PowerShell CMDlet being fired to update Microsoft Exchange Information.
2. If the Export to a Drop File fails, then your problem could be data within the Connector Space.
TEST EXPORT - (Export via Threshold- Provisioning Disabled): Test the Export by Exporting using a Threshold with Provisioning Disabled. Find more information about Exporting using a Threshold here.
1. We want to disable provisioning for this test to rule out our connectivity to Active Directory, and the ability to create/update the object in Active Directory.
2. Steps:
  1. Open the Management Agent Properties by double clicking on the Management Agent in question
  2. Select Configure Extensions Tab
  3. Change the provisioning drop down to No Provisioning.
    1. No Provisioning will export the object (create/update) to Active Directory, but will not call the Update-Recipient ( 2007 / 2010 )PowerShell CMDLET.
  4. When configuring the Export using Threshold Run Profile, set your threshold to between 5 to 15 objects. If we are going to get a timeout, we should be able to get the timeout when exporting a small number of objects.
  5. Test the Export
  6. If the Export using a Threshold with Provisioning Disabled works successfully with no timeout, this is an indication that we can export from the Synchronization Service Engine to the Active Directory (Connected Data Source) and that most likely the problem is the communication with the Microsoft Exchange PowerShell CMDLET.
TEST EXPORT - (Export via Threshold- Provisioning Enabled): Test the Export by Exporting using a Threshold with Provisioning Disabled. Find more information about Exporting using a Threshold here.
1. We want to disable provisioning for this test to rule out our connectivity to Active Directory, and the ability to create/update the object in Active Directory.
2. Steps:
  1. Open the Management Agent Properties by double clicking on the Management Agent in question
  2. Select Configure Extensions Tab
  3. Change the provisioning drop down to (Set to the Exchange Server that you are exporting too)
  4. No Provisioning will export the object (create/update) to Active Directory, but will not call the Update-Recipient ( 2007 / 2010 )PowerShell CMDLET.
  5. When configuring the Export using Threshold Run Profile, set your threshold to between 5 to 15 objects. If we are going to get a timeout, we should be able to get the timeout when exporting a small number of objects.
  6. Test the Export
  7. If the Export using a Threshold with Provisioning Enabled displays the issue, then we know the problem is with the Update-Recipient ( 2007 / 2010 ) PowerShell CMDLET.
  8. If the Export using a Threshold with Provisioning Enabled displays the issue, download a network monitoring tool such as Network Monitor 3.4 and do a network capture while executing the export.
UPDATE-RECIPIENT TESTING:
1. If you are using Microsoft Exchange 2007 then you will want to test Update-Recipient from the Synchronization Service Server.
2. If you are using Microsoft Exchange 2010 then you will want to use WinRM to test from the Synchronization Service Server
3. Doing a network trace while testing Update-Recipient is a great as well.
EXPORT TO EXCHANGE 2010: We have seen cases to where we have had timeouts, exporting is slow, or export does not work at all when exporting to Microsoft Exchange 2010. If you go through the above, and Test the Export with Provisioning Disabled and it works, then it is very possible that the problem is the CAS server information. Review the How to gather the Client Access Server (CAS) information from Exchange 2010 wiki information.

POSSIBLE RESOLUTIONS

Not in every case, but in cases where the data in the connector space may be the problem, you may look into manually executing a Full Import (Stage Only) followed by a Full Synchronization.
Database Maintenance:
1. Stop all processes and rebuild the indexes ( How to reindex the backend Synchronization Service Server Database )
2. Once you reindex, test your export
FIREWALLS: if you have firewalls between the Synchronization Service Server, and the Active Directory and/or Exchange Server, then you will need to ensure that you are allowing the traffic to get through.