Default Recipient Policy and OWA access

Earlier I posted some info regarding a bug in Exchange 2003 when updating the Recipient Policies.  There’s one other little gotcha I discovered this morning.

 
 

During the install of Exchange 2003, the default SMTP domain for the Exchange virtual directory in IIS is set to equal the default SMTP address in the “Default Policy” recipient policy.  If a user does not have an SMTP address with this domain, you cannot open their OWA explicitly using just their alias, you must use one of their SMTP addresses.

 
 

i.e.  http://exchangeserver/exchange/first.last@domain.com works but http://exchangeserver/exchange/FLast won’t work.

 
 

It’s hard to catch this because most users who use OWA will just open http://exchangeserver/exchange and it will work for them.  You can also still access another user’s mailbox via MAPI just fine.  This issue only shows up when opening another user’s mailbox in OWA explicitly.

 
 

So, the fix?  Either change the default SMTP address in the Default Policy to match a domain that all mailboxes have, or make sure all mailboxes have an smtp address in the domain of the default SMTP address in the Default Policy.

 
 

You can find more information in the following Microsoft KB article. http://support.microsoft.com/kb/293386

 
 

Don’t forget that changing this stuff can lead to the bug found in my earlier post.

PowerShell Podcast

In preparing for any Exchange 2007 installation, PowerShell is going to be a necessity for today’s administrator.  I’ve found a PowerShell Podcast I’m gonna try out to help me learn the ins and outs.  Knowing your way around PowerShell will set you apart from other Exchange Administrators.

 
 

Here’s the link if you’re interested or search for it in iTunes.

http://powerscripting.wordpress.com

 
 

Update (3/14/08): The new URL is http://powerscripting.net

Confusing options in PFDAVAdmin

So, I used PFDAVAdmin yesterday to make some changes to the replicas of some huge public folder trees.  I used the Custom Bulk Operation to perform a Replica List Operation type and selected the Merge action.  It asked me for the list of stores I wanted to add to the replica list and then it asked me for a list of stores i would like to remove from the replica list.

Doesn’t really tell you that this does both functions independently and is not a Search & Replace feature. 

For instance, say you have a folder tree like the one listed below.  The RootFolder has a replica only on  ServerA but SubFolder3 has additional replicas on ServerB.  You want to move those replicas from ServerB to ServerC.

RootFolder
     SubFolder1
     SubFolder2
     SubFolder3
          SubSub1
          SubSub2

If you use the Merge action against RootFolder to add ServerC and remove ServerB, the tool will add ServerC to the replicas of the RootFolder and all subfolders and you’ll end up replicating the ENTIRE RootFolder structure to ServerC, not just the folders where the ServerB replicas were removed.

This could be very un-fun if the RootFolder is very large.  You’ll probably get a call from one of your WAN guys asking why you’re hogging all the bandwidth.  🙂

Instead, in SP2 for Exchange2003, they’ve added a context-menup for moving replicas.  More info on that can be found here.

You’ve been forewarned.

Bug in Exchange2003 when updating Recipient Policies

So yesterday afternoon I updated all of our Recipient Policies to make them more organized as well as to make some corrections.  I did this at about 4:30pm.  Around 9:00pm I got a call from another admin that he was getting the following error in ESM when he tried to expand the Public Folder hierarchy:

The HTTP service used by Public Folders is not available, possible causes are that Public stores are not mounted and the Information Store service is not running. ID no: c1030af3 Exchange System Manager

 
 

Turns out this is an unfixed bug in Exchange2003 only.  See this article: http://support.microsoft.com/kb/938610