First up, we don't change staff or accounts much where I work, so this problem may have started any time in the last 3 or 4 months.

We're running an AD domain using Server 2003R2 and Exchange 2003. The Exchange server is also a DC and a GC server.

Yesterday I create 3 new AD accounts, complete with mailboxes. Or so I thought. When I tried to send test messages to those accounts I discovered that the mailboxes were not created at all.

Using ADSIedit to compare one of the new accounts to an existing one I found that the msExchUserAccountControl setting was "". Setting that value to 0, as the existing account has, resulted in the corresponding mailbox being created. The only other settings that I could see which were not set in the new accounts but set in the existing one related to the address books. I expected those to be updated automatically. However, The GAL is not updating either and attempting to enter those address book settings directly with ADSIedit resulted in a "User not found".

Perhaps coincidentally, although I suspect not, starting yesterday using Message Tracking Center on my XP workstation is now ending with an "Access denied" error, ID 80070005. There is nothing in the event logs on either workstation or server to shed any light on this. The Message Tracking Center on the server works just fine with the same user logon account. All this leads me to suspect something security related is broken, but what?

Googling has turned up very little. The only entries I could find with similar descriptions all related to moving mailboxes between versions. We have never moved a mailbox and this is in fact the company's first and only Exchange server.

Right now we can use those new accounts with OWA but cannot use them with Outlook (2002/XP, sorry to say) as the names will not resolve because they are not in the address book. Any suggestions I can check out before resorting to a full server rebuild?


The msExchUserAccountControl attribute should be set automatically by the Recipient Update Service (RUS). It is also responsible for setting the necessary attributes on the mailbox to make it appear in the GAL. Probably the reason those new mailboxes aren't appearing in the GAL (and thus not MAPi-accessible) is that the showInAddressBook either isn't set or is set incorrectly. Trying comparing that attribute on a good user to one of the new ones. The other possibility is that the permissions issue you described is somehow also preventing the RUS from modifying these new mailboxes. The RUS is complicated and I can't do much troubleshooting this way but it's at least a lead for you. Review the application logs on the Exchange server in detail and take a look at this as a start: http://msexchangeteam.com/archive/2004/07/07/175444.aspx. Good luck.


Problem sorted

After much investigation using information in the link supplied by icky2000, as well as a bunch of similar articles, I discovered that the Recipient Update Service was running fine but searching in the wrong place.

The LDAP queries should have started with something like

Searching directory exchange.OURDOMAIN.LOCAL at base 'DC=OURDOMAIN,DC=LOCAL' using filter

but were in fact starting with

Searching directory exchange.OURDOMAIN.LOCAL at base 'CN=Configuration,DC=OURDOMAIN,DC=LOCAL' using filter.

Using ADSIedit I removed the CN=Configuration, part and it suddenly started to work.

It appears the Message Tracking Centre issue is unrelated and requires further investigation. I suspect I'll never find the actual cause of these problems and that worries me. Still, for now at least it's working.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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