EV7.0SP3 - Provisioning task - Failed to resolve duplicate legacyDN for mbx

[GertjanA]

Hello all,

Running EV7.0SP3, Exchange2003SP1 on Windows2003SP1

In the eventviewer of the server running the provisioning task I see some entries like the one below:

==================

Error: Failed to resolve duplicate legacyDN for mbx [/o=xxx/ou=First Administrative

Group/cn=Recipients/cn=XXXXXXX]: The EnterpriseVault.DirectoryConnection object reported an error.

The Exchange mailbox provisioning task failed during processing of a mailbox. The task is continuing.

Task: Exchange Provisioning Task for XXXXXX.XX

User: CN=XXXXXX,OU=Service,OU=Accounts,DC=XXXXXX,DC=XX

Mailbox: /o=MOD/ou=First Administrative Group/cn=Recipients/cn=XXXXXX

Provisioning group: Whole Exchange Organization

Group member: Whole Exchange Organization

Error: Failed to resolve duplicate legacyDN for mbx [/o=XXX/ou=First Administrative

Group/cn=Recipients/cn=XXXXXX]: The EnterpriseVault.DirectoryConnection object reported an error.

=======================

How do I resolve this? I assume I need to find the duplicate legacyDN, but is this in AD, or in EV-directory DB?

Any hints will be appreciated!

Thank you,

Gertjan

[Mojorsn]

Hi Gertjan,

These entries can be found in the EnterpriseVaultDirectory Database in the ExchangeMailboxEntry Table.  You can do a query on the LegacyMbxDN field with a Like '%xxxx%' and you should find the offending entries. 

I have found invalid and duplicate entries in there and deleted the ones that were incorrect.

Hope this helps.

[MarkBarefoot]

Take a look at this technote, http://seer.entsupport.symantec.com/docs/286977.htm. It does talk about PST migration but you can use the SQL query to find the duplicate entries, normally '%marked%' will do the job. Remove them and then re-run the Prov task and re-sync , these errors should be gone.

The registry key will basically make EV link a LegacyMbxDN to an exisiting archive rather than creating a duplicate as it has done before.

Also, the ExchangeMailboxEntry table can actually be emptied out and on the next run of the Provisioning Task this will re-populate it.

If you follow processes when moving people around on Exchange servers properly etc you shouldn't see these kinds of errors. If they are persistent it would be worth logging a case with support.

Thx,

Mark

[GertjanA]

Hello Mark,

Thanks for the link to the document. I do NOT see the value Marked anywhere in that table mentioned.

I tested in an Demo environment. Unfortunately, we do not have these errors there, but here is what I did.

I removed one row from that table, than ran the Provisioning task. I noticed that the user is re-added to the table. I also noticed that the ExchangeMailboxEntryId was different.

Is that as expected?

Is there any information available on what happens behind the scenes when the provisioning task run? How do I determine which row to remove? Or can I remove both rows for the account concerned?

Please let me know if more information is required.

Gertjan

[GertjanA]

Working with support, we managed to resolve the issue.

The Technician (Ross) advised the following

Enterprise Vault should only have one entry for each user in the ExchangeMailBoxEntry table. Therefore if you have two entries that correspond to two different Exchange Servers (ExchserverIdentity column, which relates to ExchangeServerEntry table) then the one that references the incorrect Exchange Server requires removing.

For two entries, there was indeed a difference for the ExchangeServerIdentity. I removed the wrong entries. For the other two, they were the same. However, some columns had a NULL value. I decided to remove the 2 entries having the value NULL instead of a number, and that has worked out ok.

Thanks for support

Gertjan

[MarkBarefoot]

Gertjan,

Sorry for not replying sooner. That technote would be correct IF your user was pointing to the same Exchange server.

My colleague Ross informed you correctly and at some point there must have been a change that EV picked up.

The Provisioning task is norm set, by default, to run twice a day. Any changes or additions to Mailbox enabled AD users will be reflected in the ExchangeMailboxEntry table. You can purge the entire table if you have many issues, and the next time the Provisioning Task is run it will re-populate.

If in doubt call us at support:)

Regards,

Mark