[INFO-SYNCSERVICE] Export with Exchange Provisioning Enabled

  • Article

Hello again!  Tim Macaulay, SR. Support Escalation Engineer here with the Identity Support team at Microsoft. Today, I wanted to discuss a topic that I spend a lot of time discussing on the phone and thought I would share with the community.  That topic is what happens when I run an Export on an Active Directory and/or GalSync Management Agent with Exchange Provisioning Enabled.

First, we must remember that an Export is always a delta.  We only export changes.  We can find more information on the Export Run Profile here. http://blogs.msdn.com/b/ms-identity-support/archive/2012/05/04/how-to-troubleshoot-and-test-the-export-process.aspx

How can I tell if Exchange Provisioning is enabled?

Exchange provisioning is found on the Configure Extensions Tab of the Active Directory and/or GalSync Management Agent.  The Provision for drop-down displays three(3) entries.

  1. No Provisioning: No Exchange Provisioning is enabled
  2. Exchange 2007: Use this if you are provisioning Exchange 2007 related objects
  3. Exchange 2010: Use this if you are provisioning Exchange 2010 and/or Exchange 2013 related objects

 

 

What happens if Exchange provisioning is enabled?

The first thing that happens, is that we create the Active Directory object (User or Contact) object.  In a GalSync Solution, this would be a mail-enabled contact object.  Once the Active Directory Object is created, we call the Exchange PowerShell CMDLET called Update-Recipient.  We do this differently depending on the version of Exchange that you are provisioning too.

Exchange 2007

*NOTE: If you are provisioning to Exchange 2007, you must have the Exchange 2007 Management Tools Service Pack 3 or later installed on the Synchronization Service machine.  

Provisioning to Exchange 2007, we call the Exchange PowerShell CMDLET Update-Recipient locally on the Synchronization Service machine.

Exchange 2010

We do the same for provisioning to Exchange 2010 and/or Exchange 2013.

 Provisioning to Exchange 2010 and/or Exchange 2013, we call the Exchange PowerShell CMDLET Update-Recipient remotely using WinRM.  The Exchange PowerShell CMDLET lives on the Exchange Client Access Server (CAS).  This is the reason that you need to enter a URI to reference the location of the Powershell vDir on the Exchange CAS server.

 

Prerequisites for Exchange Provisioning

Exchange 2007: Active Directory and/or GalSync Management Agent Account must be a part of the Exchange Recipient Administrators Security Group

Additional Information for Exchange 2007 Provisioning:

http://social.technet.microsoft.com/wiki/contents/articles/5319.fim-reference-configuring-exchange-2007-provisioning.aspx

Exchange 2010/2013: Active Directory and/or GalSync Management Agent Account must be a part of the Exchange Organization Management Security Group

Exchange 2010/2013: Must reference the correct URI to the Exchange CAS server

Validate URI :: http://social.technet.microsoft.com/wiki/contents/articles/3456.how-to-acquire-the-microsoft-exchange-server-2010-client-access-server-cas-server-information-for-microsoft-exchange-server-2010-provisioning.aspx

 Additional Information for Exchange 2010 Provisioning:

http://social.technet.microsoft.com/wiki/contents/articles/5318.fim-reference-configuring-exchange-2010-provisioning.aspx

 

Troubleshooting Exchange Provisioning

In most cases, if we fail with Exchange Provisioning enabled, we will see ma-extension-error or something similar when exporting.

  • Application Event Log: The first place you want to go is to the Application Event Log.  In the Application Event Log, you should see events that contain information on the failure. These event messages are normally very helpful in resolving the export issue.
  • Permissions: Validate Active Directory and/or GalSync Management Agent User Account Permissions
  • Exchange CAS: Validate the Exchange CAS URI information
  • DNS: Validate DNS Connectivity
    • We have seen issues to where the Active Directory and/or GalSync Management Agent has been configured to point to specific domain controllers in the target forest, but the DNS is configured to look at all of the domain controllers in the target forest.  This will cause export issues.

Additional Resources