The problem first manifested itself as a 5.4.0 NDR (The destination server for this recipient could not be found in Domain Name Service) when replying to messages of users on the newly updated Exchange server.  After further investigation of the original email, the reply to address looked like this: Joe User IMCEAEX-_O=LocalDomain_OU=EXCHANGE+20ADMINISTRATIVE+20GROUP+20+

28FYDIBOHF45SPDLT+29_CN=RECIPIENTS_CN=joeuser@localdomain.local.  Well, it doesn’t take a genius to know that “this ain’t gonna work”.  I’ll save you the boring troubleshooting details, but I eventually found this article from Microsoft which outlines the issues I was having, and then stumbled upon this little jewel where a certain Ananth Ramanathan from Microsoft states that this is a known issue, and will be fixed in the next Update Rollup (note that as of the writing of this article, the Microsoft KB 969690 linked above has no fix associated with it).  Uhhhh… huh?  It won’t be fixed until the next UR (supposedly to be released in the middle of May)?

    All is not lost.  In the same forum linked above, Andy Grogan from telnetport25.com posted this article on a possible work around.  For all you Exchange 2007 administrators, give this a shot and let him know what you think.  Unfortunately for my case though, we’re talking about a hosted solution and Andy’s fix won’t work for our environment.  I’m never too happy about uninstalling patches to fix a problem created by the patch, but in this instance it was a must.  It has been suggested though that adding the CAS and HUB servers to the “Windows-based Hosting Service Accounts” group (remember we’re talking about hosted Exchange here, normal Exchange environments need not apply) would also resolve the issue.  I’ll give this a shot and report back when I have an appropriate maintenance window to test (curiously it didn’t happen in the dev environment), until then… Happy Uninstalling! =)

– Dan Thompson

   The problem shows up as a pretty generic sounding “The connection to Microsoft Exchange is unavailable.  Outlook must be online or connected to complete this action.” error when you fire up Outlook for the first time.  After some lengthy digging I found Microsoft’s KB969519 article which

describes the issue I’m having, but relates it to a Pre-SP2 performance update in KB961752… this particular performance enhancement patch, as it turns out, is also rolled up into SP2 so the fix is actually the same.

   The KB article describes 4 different methods for dealing with the issue; method 2 was the one I chose to implement, but needs a little clarification in my opinion.  So far, 5 of the 7 servers I’ve done this to did not have the No RFR Service key mentioned present in the registry (all were Server 2008 servers running Exchange 2007 SP1), and the 2 remaining servers did not have the key exactly worded as mentioned.  These two had a key Do Not Refer HTTP to DSProxy with a value of 1 as mentioned in the article and as part of the fix should be reconfigured to 0.  For all 7 servers I then manually created the Refer TCPIP to DsProxy key with a value of 1.  From here I was a little disappointed as the article mentions you should only have to restart the Exchange System Attendant and its dependent services, however in all 7 cases I found that the server actually needed to be rebooted and the Outlook client restarted before it would actually connect as intended.  Another exception I’ve found through testing with the KB article is that this particular behavior does not appear to affect Exchange 2003 servers as the article leads one to believe; not that I’m disappointed or anything.

   Now, why Microsoft couldn’t have just built in the DsProxy changes into Exchange 2007 from the very beginning… or at least implemented them through SP1 for Exchange 2007 saving administrators this headache is beyond me; but none the less, I hope this helps.

– Dan Thompson

    Let me run this down for you.  You’ve got several hundred mailboxes, of which a large majority of the users use webmail at some point in their email experience.  Each of those users has conveniently bookmarked your company’s webmail address and it probably looks something like yourdomain.com/exchange… right?  By now you’ve read that Exchange 2007 treats the “exchange” virtual directory as a legacy directory and is using “owa” instead for Outlook Web Access.  Now we don’t want to have to go through and somehow convince all those users to update their bookmarks after you’ve migrated their mailbox over to the new servers (more importantly field the phone calls from users who didn’t listen the first 6 times you told them).  You’ve done your homework and decided that the easiest migration path is to implement a client access server (CAS) separate from the mailbox server so you can take advantage of the auto redirecting (read: users with 2007 mailboxes can still browse to /exchange and CAS will automatically redirect their session to /owa… it’s seamless to them) among other things.  Great idea… but it doesn’t work if you follow the directions given by Microsoft.  Why?  They don’t mention the need to add ASP.net to the web server role on the mailbox server.

    So what happens without it?  Users with a mailbox on the Exchange 2003 servers can login just fine.  Users who have their mailboxes on the Exchange 2007 server and browse directly to the /owa address can login just fine.  However, users who have a mailbox on the Exchange 2007 servers and browse /exchange get told their username and password is incorrect.  Sound familiar?  Oh, and wait a minute… lets not forget about our beloved MAC users.  You migrated their mailboxes and now they don’t work either (this, after you spent hours trying to get the certificate installed correctly… don’t worry, I’ll discuss that in an upcoming article).  Entourage fires up, appears to connect but never downloads any messages or displays the default (or any other) folders.  Turns out that Entourage 2004 and 2008 are both hardcoded to send traffic to that /exchange virtual directory… no matter how you configure the client… and Exchange needs ASP.net to properly handle the DAV request.  Neat huh?

    Already have Exchange installed?  All is not lost.  Just simply fire up the Server Manager and add the role service to your web server role… or better yet, from the command prompt type ServerManagerCMD -i Web-ASP-net and hit enter (it’s okay guys… the black screen with white letters won’t hurt you).  Reboot the server for good luck (in reality an iisreset will do the job), and you’re off to the races.

Happy Messaging!

– Dan Thompson

]]> http://techblogogy.net/index.php/2008/12/aspnet-and-the-mailbox-server-role-in-exchange-2007/feed/ 0