Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In my organization, we have a corporate domain ( and child domains ( Our child domains have their own exchange servers. This server happens to be Exchange 2003.

One of them has an annoying problem. Most accounts are created by script (and work fine), but when we create an account manually (via AD Users & Computers) the email address is entered incorrectly. Rather than giving the new mailbox '', it assigns them ''.

When creating a user with a mailbox there is a 1 to 3 minute delay, which is normal. However, this makes it a royal pain to create accounts properly, as you have to wait the minute or three before you can go in and fix the email address (as simple as renaming it under the E-mail Addresses tab).

Where is the setting for the server that determines the default domain for a new email address? Somewhere we messed it up, and though it is not a serious issue (since mail delivery works, and most accounts are created via script), it's a frustration that grates on me, especially when I forget to check back and a user is upset a week later because they still can't get email.

share|improve this question

What you're looking to do is edit the recipient policy. Find it in ESM under Recipients/Recipient Policies. Edit the Default Policy and change the Email-Addresses Policy to reflect the address scheming that your company has standardized on. Here is the appropriate Technet documentation for you:

share|improve this answer
The domain in the policy for this subdomain is correct, which implies that the Filter rule is probably improperly formed, and thus not matching, or perhaps at the wrong priority (allowing the less specific main server rule to match first). Would this seem like a likely avenue to pursue? – Myrddin Emrys Jun 15 '11 at 21:21
You're absolutely on the right track. You want to make sure that your filters match in the correct priority. Have a default rule that's just for left overs. Make this policy have the lowest priority. Then make more specific policies at a higher priority than your default rule. – Jason Berg Jun 15 '11 at 21:25
Just a note that you can't manually change the priority of the Default Policy. It will always have the lowest priority, followed by all other policies in the order they were created. You can change the priority of policies that you create. – joeqwerty Jun 21 '11 at 2:08

I also suspect the Recipient Policy filter as the culprit. Recipient Policies are applied based on priority (highest to lowest) and the first one that matches is the one that is applied and all others are ignored. Only one Recipient Policy is applied per object so my guess is that your default RP (filter = (mailnickname=*)) is being applied to all objects. You need to create a Recipient Policy for the subdomains with a filter that's specific to those subdomains. That will put them at a higher priority than the default RP and should then appropriately "stamp" the subdomain objects with the correct email addresses when you apply the RP.

Here are links to 2 good articles on the subject of RP's and the RUS:

share|improve this answer
Most of our subdomains are creating emails properly; it's just this one that is incorrect. And it is not placed 'oddly' on the priority compared to the other subdomains. I suspect its filter is not matching for some reason, though the syntax for the filters we use is arcane to me; once I figure out why it fails to match, I'm sure the problem will be solved. – Myrddin Emrys Jun 16 '11 at 12:33
And I'm still in the dark. I realized you could test the patterns, and as far as I can tell the subdomain pattern properly matches new accounts, and no higher priority pattern matches. The filtering is primarily based on Message Store. – Myrddin Emrys Jun 16 '11 at 13:04
The filters use LDAP Search Filter syntax, which takes a little getting used to. The thing to note is whether or not an RP with a higher priority is matching the recipients in question. If so, then that RP will be applied instead of your intended RP. The other thing to note is the filter itself. Is it actually valid? If not, then it won't match and another RP that does match will be applied. – joeqwerty Jun 16 '11 at 14:15
Aye, but that's the problem... higher priority filters don't match, and the correct policy does match (tested by clicking the search button while viewing the policies, after an account was just created). Any other ideas? – Myrddin Emrys Jun 17 '11 at 12:03
The only thing I can think to do at this point is to set the diagnostic logging for the following component to maximum and see if any events are logged that give you a clue: MSExchangeSA – Proxy Generation – joeqwerty Jun 21 '11 at 3:27

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.