This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

LegacyExchangeDN and X500 - adding random numbers to LegacyExchangeDN attribute - random x500 addresses on resource mailboxes

I have a problem with some resource mailboxes I want to migrate. The issue is once those mailboxes got migrated and a full syn runs, qmm changes legacyexchangedn values adding random digits to the and of the value. 

for example: X500:/o=MY Org/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=somemailnickname35131471,

Then, the uttered value does not match the primary X500 address and the legacyexchangedn value got changed again. At the end, proxyAddresses attribute contains 400 different/random x500 addresses.

I thought the issue is related to the fact the mailnicknames contain hyphens (some-mail-nickname). I changed them by removing the hyphens but that didn't fixed the problem. 

Anyone knows how to fix this ?

Also, I would like to know how to prevent qmm from changing legacyexchangedn values. Since there is no such option in qmm settings there must be a way to do that change in the registry or lds database.

Important note: Source exchange is 2013 and Target is 2010 SP3

 Also I noticed that mailnickname doesn't get synced and has no value in the target domain. (resource mailboxes only)

Regards,

Slav

  • Slav,

    The X:500 is for reply ability for existing emails.  Is this causing you an issue?

  • Slav,

    Until Exchange 2010 SP1 Rollup 6 the legacyExchangeDN value was predictable, but as of this Rollup (and Exchange 2013), 3 random hex characters are added for uniqueness.

    While SMTP addressing is the e-mail addressing standard, Exchange internally still uses an X.500 addressing scheme. Using X.500 implies that an X.500 is required, which is why mail objects in an Exchange organization such as mailboxes, require a properly populated legacyExchangeDN.

    Personally I do not see how this is causing you an issue.

    There is a really nice gentlemen on this site by the name of Jeff, that could definitely explain much better then I could.  Hopefully he will chime in.

    Cheers,

    Enrico

  • Sort of. LegacyDN doen't match  any X500 addresses in proxyaddresses attribute. 

    For example the LEDN is X500:/o=MY Org/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=somemailnickname35131471

    But the X500 is X500:/o=MY Org/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=somemailnickname35131472

    LEDN technically should be copied to proxyaddresses attribute as a x500 address.

    I'm also trying to figure out why there is no value under mailnickname in the Target AD.

    User and group objects have been successfully staged/migrated in the Target AD and I hadn't have that issue before.

  • The source LegacyExchangeDN should match a target proxyaddresses value.  What the value is in the target for the LegacyExchnageDn only needs to be forest unique. It does not need to match anything 

  • having the same value in the LegacyExchnageDN and proxyaddresses would create a duplication of addressing 

  • I know it should but it doesn't. After qmm figures out the values don't match, it generates another value which again doesn't match. That happens over and over again. Once, I have over 600 entries (of x500 addresses) under proxyaddress attribute

  • also I have done some testing. 

    I have created two resource mailboxes:

    one called test-resource-one: mailnickname: test-resource-one: mail: test-resource-one@topsecret.com

    and the second one called testresourcetwo: mailnickname :testresourcetwo, mail testresourcetwo@topsecret.com

    After migration the first had the issue discribed in the post but the second didn't.

    Then, I changed the affected test mbx to  mailnickname: testresourceone: mail: testresourceone@topsecret.com, resynced it and the problem disappeared.

    I would like to know why the hyphens in the account name caused the described problem.

  • "User and group objects have been successfully staged/migrated in the Target AD and I hadn't have that issue before."

    Did you use QMM to perform the staging?

    Did you enable the Exchange options in the QMM DSA? - I could be wrong but I don't believe mailnickname will be brought over as part of the default "AD only" attribute set.

  • I would really like to understand the process you are going through and what you are seeing at each check point?

  • You are correct. MailNickname is only handled by the MBReDir and the Exchange tab has to be enabled for that.