What happened to my targetAddress attributes????

Like many things I learn in IT, I learned a new lesson "the hard way". We are migrating from an old forest to a new forest using Quest. The Quest mailbox migration, once it completes the migration of a mailbox, puts on the user's targetAddress attribute the SMTP of the new location. For example, the mailbox's new SMTP address is Luke@newdomain.com, so it puts in the old mailbox's targetAddress attribute SMTP:Luke@newdomain.com.

The Exchange "move mailbox" wizard actually CLEARS this attribute if you move the mailbox from one database to another in the same organization. We needed to shutdown some old mailbox servers, so we ExMerged all of the data out of the mailboxes that had been migrated, then moved the empty mailboxes to a single Exchange server.

Forwarding immediately stopped working. After some frenzied investigation, we found that the targetAddress for the moved mailboxes had been cleared. A call to our Quest consultants confirmed this. So, keep this in mind if you have to move mailboxes that have a targetAddress set on them!!!!

Mastering Microsoft Exchange Server 2010: Best Practices for Deployments and Upgrades

David Elfassy and I are presenting a pre-conference session at TechEd 2010 in New Orleans this year. Hope to see some of my blog readers there!
_______________________________
A stable and well defined deployment strategy will provide a problem-free implementation of Exchange Server 2010. Administrators can have peace of mind when managing e-mail systems and can therefore go deeper; and explore the new features provided with this latest version of Microsoft′s premiere messaging solution.

Written and presented by co-authors of the book "Mastering Microsoft Exchange Server 2010", this pre-conference seminar brings years of Exchange Server deployment expertise to Tech⋅Ed attendees. This 300-350 level seminar focuses on the deployment technologies and best practices for deploying Exchange Server 2010. Content and demonstrations concentrate on the following Exchange server technologies:

• Continuous Availability and Site Resilience for Mailbox servers
• Deploying and configuring Client Access Arrays
• Implementing redundancy for message routing
• Best practices for upgrading an organization to Exchange Server 2010

Walk away from this seminar with the tools necessary to implement a new Exchange deployment, upgrade your existing messaging environment or stabilize your existing deployment. This seminar is designed for IT professionals who manage messaging environments and consultants who deploy messaging solutions.

Exchange Server 2010 SP1 archiving features and Outlook 2007

The Exchange team blog contained a great post today about the future of the Exchange archiving features. This includes the much requested ability to move the archive mailbox to a different database. However, they also announced that there will be an update Outlook 2007 that will allow the user to access the personal archive. This is big news for organizations that are still in the middle of an Office 2007 upgrade!!!

Thanks to the Exchange and Outlook teams for listening to the customers!

No route was found for the recipient server.

I saw a very weird problem this past week on a system running Exchange Server 2003. The organization has 2 separate Exchange organizations/forests. They are in the middle of migration from OldDomain.com to NewDomain.com and are using the Quest Migration tools.

Many of the users had mailboxes in the new domain, but their new domain mailbox had an alternate recipient that forwarded all mail to a contact in olddomain.com.

When Quest first sync'ed the "old" mailboxes with the "new" mailboxes, it removed the alternate recipient and added to the new mailbox a targetAddress of UserDomain@source.olddomain.com.

The problem is that for ONE user out of hundreds, anytime that someone sent him a message, they got back HUNDREDS of NDR messages. The user had not yet been migrated to the new domain, so the targetAddress attribute was checked and it was correct. NDR message was:

No route was found for the recipient server. Please contact your system administrator.
servername.newdomain.com #5.4.4

The message was originating from the sender's mailbox server. After lots of examining logs and message tracking, we found that the message WAS actually getting to the intended recipient, but the NDRs just kept coming in.

Ultimately for this one user, in the new domain on the alternate recipient forward, the checkbox to send to both the mailbox AND the alternate recipient was checked. But, the alternate recipient address was now blank. We had to enable a forwarder temporarily, clear that checkbox, and then remove the forwarder.