Random Undeliverable Emails

None of their NK2 files were moved over since it was an inter-forest domain move and moving the NK2 files results in problems similar to what we are having.

Are the emails that are being bounced, replies to existing emails?

If you send a new email to a user from the GAL - does that error?

If you reply to an old message in a mailbox pre-move, does that error?

That's the weird thing.  It is for new messages, and for old replys.  But the old reply issue I think is a separate issue completely.  If in an old reply they simply delete and retype the recipients it works with an equal chance of being able to send.  If they leave the old recipients it never goes through.  People will create new messages, try to send them and they'll fail.  Then they'll try and send them again and it'll work no problem.  Things sent from the OWA client are totally fine, no problems leading me to believe its an issue with the GAL or OAB yet internal users get bounce-backs trying to send to internal and external users.

Can you force a Full Download of the OAB on a machine and then try to send a new message to a user that would normally fail please.

If we disable cached mode this removes the OAB from the equation, no?

We are having trouble sending to each other even though we (the test subjects) are using non-cached mode and therefore pulling directly off of the GAL.

Yes - disabling cached mode will remove the OAB from the equation.

Have you rebuilt the GAL since moving all the users?

Open up Exchange System Manager and Expand Recipients> Offline Address Book.

Right click on the default Offline Address List and choose Rebuild.

Wait for the rebuild to complete - which may take some time depending on the size of your organization.

IDK, if we have.

So we're supposed to rebulid the GAL and OAB on the New Domain that we've moved to?  Is that correct?  Just verifying that you don't want us to rebuild the old domain's GAL or OAB as that domain is now dead.

Also, should I set the maintenance interval to 100% of the day to make sure this rebuilds quickly?  I've got users freaking out here as they can't do anything with their old calendar items or meetings.

Yes - please rebuild the GAL for the new domain.

Are existing users (ones that were not moved) able to email existing users on the domain (ones that were not moved) without any problems?

Yes - you can increase the maintenance interval to encourage it to rebuild faster / without delay.

All users were moved and we're all on a new domain.  The old domain is dead - no DCs no Exchange servers and no users or computers that are a member of it any longer.  I've updated the interval to be continuous and set both the RUS service and the OAB to rebuild themselves.

Ah - okay.  No problems.

Will wait for feedback once the update has completed.

How many users on the domain?  I know you had quite a few!

about 150ish users.

Question:  How is updating the OAB/GAL going to affect these old emails?  When I go into the properties of the older emails and calendar items for the users that ARE working an SMTP address, an x500 and an x400 address are in the recipient policies of the email BUT for users that old email and calendar replies AREN'T working these fields are blank... Since this information appears to be what is causing the problem and isn't pulled from the GAL/OAB I'm curious how doing anything with either the OAB or GAL is going to do anything....?

In addition, what are the default Recipient Polices that should exist for an out-of-box install of Exchange 2003?  We have an SMTP @companyname.com policy and a X400 policy that is reads "c=US;a= ; p=First Organizati;o=Exchange;".  Should it have a X500 default policy as well?

The GAL rebuild should resolve issues for new emails bouncing.

To resolve the replies to existing emails issue you will have to add the old x400 address from the old domain to all the accounts to mirror the old x400 addresses, which is where the issue is coming from for replies to existing mail / calendar entries.

Another tidbit of info, I've learned that our Exchange Organization is in "Mixed Mode (can support pre-Exchange 2000 Servers)".  We have only had Exchange 2003 servers on our network for about 1300 years.  

I also just read this:  http://support.microsoft.com/kb/249299

Showing that only the default recipient policy is in effect....  As part of our move to upgrade to Exchange 2010 they say "turn the operation mode to Native".  If you don't think they'll be any other problems related to doing this I'm eager to get this turned on to Native Mode.

?

For info on the X400 / X500 issue:

http://support.microsoft.com/kb/313324

So if I add the format of the old x400 address to the Recipient Policy AND change it its Operation Mode to Native.  It should push out the old formatted X400 addresses to all the clients?

No problems doing that at all - you can switch the mode happily without any issues / ill effects.

Right now our issue has been reduced (to my knowledge) of just pre-migration emails and calendar items.  Some users had NK2 file problems that leeched over causing new emails to be an issue but that has since been resolved.  So the GAL rebuild might not do anything for us.  I'll await your answer regarding if/how we can push out the X500 address using RUS.

I know that you can add an X500 through use of the "Custom Address" but how can I format this input to address multiple users and save myself the hassle of having to add each of these manually?
RUS---where-s-the-x500-option.png
x500.png

Yes - create a new Recipient policy for the X400 / X500 address and that should roll those out to each user.  It needs to match the old format exactly so that the addresses stored in existing mails can resolve back to a user.  if the org is different you need to add the old org name.

The GAL rebuild won't hurt and might improve the situation as you mentioned problems sending new emails to users.

What do I type in this field to have the RUS update all my users?  Do I put in everything but the user info?

The user that works is formatted like this: /o=olddomainname/ou=First Administrative Group/cn=Recipients/cn=Firstname Lastname

So should just put /o=olddomainname/ou=First Administrative Group/cn=Recipients as the policy for RUS to push out?
what-now.png

In this case when I tried to create a RUS policy for the GAL/OAB with or without including the username of a user that works it doesn't work and gives me an error message:
error-message-x500.png
Event-Log-ID-Error.png

I have the captions for the above screen-shots reverse labeled properly.  

Please download Admodify.net (attached) and run this to bulk create the X500 addresses (I don't think it will work with a policy as the individual address needs to be created and you can't do that in a policy.

Then read this article for details of how to Add the X500 address in bulk:

http://support.microsoft.com/kb/909271
ADModify.zip

Even for individual users that I've added the X500 addresses for to match the users that are working and it doesn't make any difference.  Old emails/calendar items still show as blank on these users.  I added an email address in a "username@fakedomain.com" format in the GAL and then checked to see if that updated on the old emails for users that ARE working and it does.  Simply put, it looks like the problem here is that certain emails aren't registering or recognizing the approriate user in the GAL/OAB to authenticate with when you reply to them or try to update the calendar item.  For this reason adding any amount of addresses to the "blank users" won't do anything, somewhere there is a setting or value that is preventing these emails from recognizing the approriate recipients.

It's like certain user's were corrupted in the migration process and unidentifable from the perspective of Exchange/Outlook.  In past migrated emails certain users are universally recognized as legitimate users now and others are complete unknowns, the system doesn't know how to reference back to the appropriate entry in the GAL or OAB.

I'm having one hell of a time finishing this off and putting a nail in the coffin of this problem once and for all.

I have a user that is having issues.  1 user.  Frequently but seemingly at random users send emails to this user, we'll call her "Bobbi" and they bounce back.  All other users are fine to send and receive new emails to each other and most emails to this person go through but occasionally they don't.  These emails all have 1 thing in common, when you look at them in the Sent Items list they show her name in single quote marks (as in one of these ') while all other names are showing normally.  You 2x click on this 'Name' and it takes you to a phony GAL entry that doesn't have a SMTP/X400/X500 address for this user in it.  All other users in the list, if it is an email to multiple recipients, show up fine.  

I go to their desk and (so far) they've been unable to recreate it.  They do (supposedly) exactly what they tried and it works fine and doesn't create a 'quoted' recipient with a blank email address.  It isn't a cached name (NK2) problem, and their GAL/OAB is up-to-date.

I'm completely at a loss here and if anyone can figure this out I'll email you some brownies.

Eventually had to delete the troubled user account and reattach their mailbox unto a new AD account with the same name (created it under a different name and then changed it to the OG name).  Even this didn't appear to fix all our problems.  The user got a new computer with this user account setup and the day after it started disconnecting and only updating mail items if she would hit "F9" for a manual refresh.  Even though the user's account name is "bsmith" it is showing it in Exchange System Manager as "bobbinew" as the last user that connected to the mailbox in question.  Looked through ASDIEdit for any link of why AD would be confused about what the name of an account is and the only thing we found on this user object was the "mailNickname" attribute which seems rather inconsequential.  Used REPADMIN to verify that the DCs were happily syncing back and forth.  The 'fix' for this is that we set the Outlook client to manually sync once every minute until we move to Exchange 2010.

Unfortunately for both these issues the fix is that there is no fix.