• State Not Answered
  • Locked Locked
  • Replies 16 replies
  • Subscribers 20 subscribers
  • Views 23413 views
  • Users 0 members are here
Options
Related
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

slav
over 5 years ago

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

Parents
  • 0 over 5 years ago

    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

Reply
  • 0 over 5 years ago

    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

Children
  • 0 over 5 years ago in reply to Enrico Mancini

    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.

  • 0 over 5 years ago in reply to slav

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

  • 0 over 5 years ago in reply to Jeff Shahan

    It looks like removing spaces and hyphens from mail,mailnickname attributes fixed the problem. Still baffles me though why the staging didn't work with "-" sign in the affected attributes. I have always migrated Exchange from lower to higher version. This one is different since we're moving backwards (2013->2010)