次の方法で共有

[SUPPORT TROUBLESHOOTING] Duplicated Contact Objects

  • [アーティクル]

All! Hello again! Tim Macaulay here, SR. Support Escalation Engineer with the Microsoft Identity Support Team here at Microsoft. Today, I would like to discuss a topic that we see a lot in support dealing with a Global Address List Synchronization (GalSync) solution.

In support we have worked several issues around "duplicated contact objects" appearing in Active Directory and/or Exchange. The questions of "How do I fix this and have the Synchronization Service Engine stop exporting duplicates? " and "Why is the Synchronization Service Engine creating duplicates and exporting them? "

Before I answer the questions, let me explain a bit how a default GalSync solution works.

How a GalSync Solution works in the Synchronization Service Engine

A Global Address List Synchronization (GalSync) solution is exactly what it's title states. It is utilized to synchronize multiple Microsoft Exchange Forests together. Since the purpose of GalSync is to synchronize multiple Microsoft Exchange Forests, than this means that GalSync only works with Exchange related objects. If the object is not an Exchange object than GalSync does not care about it. What does this mean? It simply means that if you are importing non-exchange related objects into the connector space, during a synchronization GalSync will filter these objects.

In a GalSync solution, we take a source object (mailbox-Enabled User, mail-enabled contact) and synchronize it to the target data source as a mail-enabled contact object. Let's look at an example one-way flow from a high level.

  1. Import (Full or Delta) on Source Management Agent
  2. Synchronization (Full or Delta) on Source Management Agent
  3. Export on Target Management Agent
  4. Import on Target Management Agent

Why is the Synchronization Service Engine creating duplicates and exporting them?

Now that we have a basic understanding of how GalSync works from a high level, let's address the question "Why is the Synchronization Service Engine creating duplicates and exporting them into the target data source?"

There may be many reasons that this happens, but the most common reason that you get a duplicate mail-enabled contact object is because the originally provisioned target contact object has been filtered making it a "filtered-connector" object living in the target connector space.

Ok, but why does this happen? In most cases, this happens because the Microsoft Exchange related attribute legacyExchangeDN does not contain a value. A default GalSync solution will filter a target mail-enabled contact object if it does not have a legacyExchangeDN value. This is expressed in the GalSync Management Agent (galma.vb) Extension code.

                *NOTE: If you have a default GalSync solution, you can review the GalSync Extension code yourself. It is located in %programfiles%\Microsoft Forefront Identity Manager\2010\Synchronization Service\SourceCode\GalSync.

The attribute legacyExchangeDN is a Microsoft Exchange System Attribute. Its value is controlled by Microsoft Exchange and should be set by Microsoft Exchange. In a GalSync Solution where Exchange Provisioning has been enabled, this is handled by the Microsoft Exchange PowerShell CMDLET called Update-Recipient.   Here is how it works essentially.

  1. Export on the Target Management Agent
    1. The Synchronization Service Engine first creates the Active Directory Contact Object in the Target OrganizationalUnit with the necessary attributes for Microsoft Exchange to detect it is going to be a mail-enabled object.
    2. Then the Synchronization Service Engine executes the Microsoft Exchange PowerShell CMDLET Update-Recipient to stamp that object and make it mail-enabled.

    *NOTE: The version of Exchange dictates the Security Group and where the script is executed.

  • Exchange 2007 = Execute Exchange PowerShell CMDLET locally on the Synchronization Service Engine box.
  • Exchange 2010 = Execute Exchange PowerShell CMDLET remotely on the Exchange CAS Server
  • Exchange 2013 = Execute Exchange PowerShell CMDLET remotely on the Exchange CAS Server

If the Microsoft Exchange PowerShell CMDLET Update-Recipient fails execution, then you will see Export Errors appear in the Synchronization Service Engine console. In most cases, there is not a lot of information in the actual Export error. To understand why the Export failed with a ma-extension-error we need to review the Application Event Log.

If the Microsoft Exchange PowerShell CMDLET Update-Recipient fails execution, then this means that legacyExchangeDN did not receive a value. On your next Import and Synchronization, you will notice that you now have a duplicated object in the Target Connector Space. Let's look at the run steps:

  1. Export on the Target Management Agent
    1. The Synchronization Service Engine first creates the Active Directory Contact Object in the Target OrganizationalUnit with the necessary attributes for Microsoft Exchange to detect it is going to be a mail-enabled object.
    2. Then the Synchronization Service Engine executes the Microsoft Exchange PowerShell CMDLET Update-Recipient to stamp that object and make it mail-enabled. Update-Recipient fails or throws an exception.
  2. Import on the Target Management Agent
  3. Synchronization on the Target Management Agent
    1. Now do a Search on the Connector Space (Search Connector Space) on the Target Management Agent.
    2. If Update-Recipient failed, than you should see 2 objects for those objects that do not have a legacyExchangeDN

A good example would be something like:

  • Original Object: CN=Object, OU=GalSync, DC=ALPINESKI, DC=COM
  • Duplicated Object: CN=Object(1), OU=GalSync, DC=ALPINESKI, DC=COM or CN=Object(Department), OU=GalSync, DC=ALPINESKI, DC=COM
  1. In this scenario, if you review the Original Object, you will see that the object does not have a legacyExchangeDN. If this is true, than you could have a couple possible scenarios:
    1. Update-Recipient failed to execute and threw an Exception
    2. The Target Management Agent does not have Exchange Provisioning enabled and nothing was run on the Microsoft Exchange server to update the object to become mail-enabled.

We now have an understanding of why duplicated contact objects are appearing. The resolution for this issue is to ensure that legacyExchangeDN receives a value.

Now the next large question here. How does one clean up after experiencing this issue?

There are a few ways to clean up from this issue. The key thing to remember here, is that you need to fix the actual issue of legacyExchangeDN not getting populated. Once you correct the issue, then proceed with the cleanup.

  1. You could delete all of the target mail-enabled contacts and re-provision all of the mail-enable contact after correcting the issue

                     *NOTE: If this is a production environment, than this may not be the best solution for you. If you delete a mail-enabled contact object that is being utilized in email, than deleting the mail-enabled contact object will affect the end-user Outlook Cache and could very possibly cause a NDR when sending email. If this does happen, you will have to clear the end-user Outlook Cache.

  1. You could manually delete all of the duplicated mail-enabled contact objects, then run a script to update all of the original mail-enabled contact objects
    1. Manually delete all of the duplicated mail-enabled contact objects
    2. Run a Script to update all of the original mail-enabled contact objects
    3. Execute a Full Import (Stage Only) on the Target Management Agent
      1. This will tell the Synchronization Service Engine that the duplicated objects were deleted and clean up the Target Management Agent Connector Space
    4. Execute a Full Synchronization on the Source Management Agent

                      *NOTE: If you are familiar with working with Preview, then you may want to utilize Preview on a few objects to help speed your testing.

  1. Execute Export on the Target Management Agent

                       *NOTE: You may take a look at the following blog to assist with troubleshooting the export. This will provide more control over the export to help ensure that you resolve the issue prior to exporting everything.

                          How to Troubleshoot and Test the Export Process:
http://blogs.msdn.com/b/ms-identity-support/archive/2012/05/04/how-to-troubleshoot-and-test-the-export-process.aspx

Troubleshooting Resources Mentioned

Additional Resources