A Failed Inheritance
A few days ago, I went to mail enable a public folder for a customer and found that while it showed up great in the EMC, we couldn't deliver mail to it. Rather, the server would respond:
#< #5.2.0 smtp;554 5.2.0 STOREDRV.Deliver.Exception:ObjectNotFoundException; Failed to process message due to a permanent exception with message The Active Directory user wasn't found. ObjectNotFoundException: The Active Directory user wasn't found.> #SMTP#
Knowing that we're talking about the GAL and/or OAB at this point, I went to rebuild the OAB ahead of schedule. But the OAB fired back, "I can't generate!" It was configured to generate in public folders and for web-based distribution. Doing some thinking, I jumped into ADSIEdit and discovered that my public folder hierarchy was still pointing at the legacy server in the Exchange administrative group.
|
Ruh-roo, Shaggy! |
What's interesting is that the OAB generation was occurring on my new server and was targeting the public folders database on the new server. So what's wrong with this picture?
He's Responsible
Sure enough, my legacy server isn't in the DN, but I wasn't like I could turn it back on. The object was deleted from the Exchange administrative group and the physical hardware had been sent to the dump months ago.
Looking at the Folder Hierarchies in both administrative groups revealed that the hierarchy object was in the old administrative group, but not on the new one. That's right a server that didn't existing anymore was responsible for maintaining the MAPI PF tree for my new Exchange server.
So what to do? Ideally, my old box would be on, with public folder replication completed and nothing but system objects in the public folders. One right click and I could migrate this via the UI. Checking some properties and running an Exchange Best Practices Analyzer, I discover I have the following condition:
http://technet.microsoft.com/en-us/library/aa996485(EXCHG.80).aspx
Okay, so far so good. But now the MAPI tree doesn't yet exist on my new Exchange server. A little more digging and I discovered how my Configuration partition should look like this for a good migration:
http://social.technet.microsoft.com/Forums/ar/exchangesvrmigration/thread/c0634d0e-80aa-4988-9a0f-67f1b02b3b50
Who's On First?
Now that I've survived the above article and bounced my Information Store service, I've got 2 MAPI trees and fail the Exchange Best Practices Analyzer. Oh, and Public Folders won't show up in Outlook Web Access. Microsoft's got that covered:
http://technet.microsoft.com/en-us/library/dd535370(EXCHG.80).aspx
Once that's in place and I've confirmed I'm not getting NDR's things look great. Oh wait, Message Tracking shows that my message is received but never hits the mailbox store. A glance at the Queues, and my message is in the Unroutable Queue.
Remember our screenshot above? There's still a routing group connector on the legacy administrative group side, but not on the production site. Yes, that'll be a delete in ADSIEdit. You backed up all of this first, right?
Final Absolution
And now my public folders are managed by the new system and the old metadata is gone. Just one more email test. And:
#< #5.2.0 smtp;554 5.2.0 STOREDRV.Deliver.Exception:ObjectNotFoundException; Failed to process message due to a permanent exception with message The Active Directory user wasn't found. ObjectNotFoundException: The Active Directory user wasn't found.> #SMTP#
What? Still? Now we're back in familiar territory. This happens quite frequently in Exchange 2003 to Exchange 2010 migrations. It's a documented solution:
http://blogs.dirteam.com/blogs/davestork/archive/2010/03/16/mail-enabled-public-folder-recipient-not-found.aspx
And with that, upgrading the GALs to the new 2010 format and an OAB update and I can finally use mail-enabled public folders in Exchange 2010.
Remember, your mileage may vary! Backups are important, to the point of considering PST exports of the Public Folders as an additional failback. The best part is, this is documented, but there are several pieces we had to put together, but with a good understanding of the schema and using ADSIEdit and the issue became obvious and we had a path to resolution.