Evan Dodds - Microsoft Exchange Server Blog

Exchange, Exchange administration stuff, and other assorted ramblings


Exchange Tidbits

  • Comments 6
  • Likes

Couple of Exchange tidbits I’ve been saving up for a while. None of them are on my usual topics (Exchange clustering, site consolidations, etc) and they are not large enough individually to warrant their own post, but hopefully they’ll help you out.

1) You can force the Exchange 2003 SP1 RUS to stamp secondary email proxy addresses onto an existing user account without having to do “apply now” on the recipient policy. This is principally for cross-forest migrations, but may also work for users who haven’t been moved cross forest. KB.820381 covers the cross-forest scenario, but you can also set the GUID manually on the user’s msExchPoliciesIncluded attribute: {23668AD4-4FA1-4EE8-B2BB-F94640E8FBA0}.

2) NTDSNoMatch doesn’t have to be set on Custom-Attribute-10. Everyone refers to extensionAttribute10 when discussing NTDSNoMatch (see KB.274173, for instance). Little-known fact is that it doesn’t have to be attribute #10. If you’re using attribute #10 for something else, just put the “NTDSNoMatch” value into any of the 15 extensionAttributes and the ADC will pick this up transparently. Thanks to Alex Seigler for this find.

3) LegacyExchangeDN may add a random 8 digit number to ensure uniqueness. You may notice that sometimes the LegacyExchangeDN value associated with a user is of the format /o=org/ou=site/cn=recipients/cn=username######## rather than the expected /o=org/ou=site/cn=recipients/cn=username. This happens because the LegacyExchangeDN serves as the unique X500 identifier in the Exchange 5.5 directory, and as such, has to be unique. If there is any collision of LegacyExchangeDN values when the user is being mailbox enabled, eight random numeric digits are appended to the proposed LegacyExchangeDN and it’s checked again for uniqueness. Note that it really doesn’t matter what your LegacyExchangeDN is, so long as it’s properly associated with the user and is unique (ie - don’t bother trying to go back and “change” these unique-ified values)

  • Thanks for the tips... I had heard about NTDSNoMatch being able to be in any of the extensionAttributes back at MEC in 2002, but couldn't find any documentation to support it.

  • Two further tips for NTDSNoMatch which have caught me in the past....

    1. If you want to use one of the attributes from 11-15 you must ensure you enable those attributes to be replicated inter-site in your 5.5 Org - by default they are not. Which will catch you if you are using the SRS in your hub site as the target for any CA's. You go make the change on the site/configuration/DS Site Configuration Object, on the Attributes tab.

    2. The Exchange 2003 version of NTDSNoMatch DOES pick up hidden objects. This was a real find! Run it from the exdeploy folder by using the command line 'exdeploy.exe /s:servername /t:NTDSNoMatch'


  • Great adds, Greg! Thanks for posting!