Tex-MX

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.

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

Access Denied on Tracking Logs

Oh my God, this was hard to find!

Ok, so I started this new job as an Exchange 2003 admin at a new company.  The previous admin had done all sorts of tweaking to the permissions in the Org (manually editing registry keys, dis-allowing permissions inheritance in ESM, etc).  Of course, he left no documentation.

So I'm looking at the properties of the server in my office and notice that in the field for where the Message Tracking Log File directory is located I see:

Access is denied  Facility: Win32  ID no: c0070005 Microsoft Exchange Management

I looked all over the net before I finally found the answer:  LOCAL SERVICE must have Read permissions on the following registry key:

HKLM\SYSTEM\CurrentControlSet\Control\SecurePipeServers\WinReg

I even tested removing this permission on a lab server and sure enough it's easily replicated.  I present this information so that perhaps you won't get as frustrated as I did.