So, yes, I spend most of my time writing about Exchange 2007, but most of my clients are still on Exchange 2003.
I ran into an interesting problem today. It took me about an hour to figure out what was going on, but then it was a “duh, of course” moment on my part.
The real issue? Too many cooks in the kitchen. This problem was caused by a client administrator making a change I wasn’t aware of, just because he thought it made things “cleaner”. If I had been aware of the change before it happened, I would’ve said “no, that’s gonna hurt, don’t do it!” After the case, I would’ve said “let’s change it back.”
Anyway, the problem started with a report of a user who just got a Treo and couldn’t sync with EAS and couldn’t log into OMA. This is why:
When Exchange is first installed on a server, either Exchange 2000 or Exchange 2003, it creates something called ExIFS – the Exchange Installable File System. The purpose behind ExIFS is to allow an application to access Exchange mailboxes as if they were a file system – each folder representing a directory, each mail message or calendar item being a file, etc.
In Exchange 2000, this was visible by default, as the “M: Drive”. That caused huge numbers of heartaches. Many anti-virus solutions would scan M: and end up corrupting items. (Note that this was not necessarily the fault of the anti-virus vendors, as Microsoft guidance was quite clear about configuring the a/v solutions to NOT do this.)
In Exchange 2003, the M: drive was still present – but hidden. To access it, you must use a special syntax of NTFS, often called “the volume syntax”, as it can also be used to see your normal disk drives and mount-points, if you know their system names (which contain a 128-bit value known as a GUID). You access it by using this syntax \\.\BackOfficeStorage\. If you do a “dir \\.\BackOfficeStorage\” from a command prompt on an Exchange Server, another directory will be visible. This directory will be the DEFAULT SMTP domain in the Default Recipient Policy.
Now, when you first install Exchange, the default SMTP domain is the same as your Active Directory domain. So, if your Active Directory is named test.local, then your default SMTP domain is also test.local. As you create users with mailboxes, that Default Recipient Policy will stamp your users with test.local as their primary SMTP domain.
That is generally not what they want. J Most people have a different Internet domain than their AD domain. To solve this, you have two options:
1] Change the default policy, or
2] Create a newer, higher priority policy.
Option [2] is the correct choice.
If you choose option [1], then you will change the default SMTP domain. OMA and EAS depend on the default SMTP domain, and they were setup when you installed Exchange. Now, if you change the default policy, and leave it so that the default policy still generates the original email address, just not as the primary, OMA and EAS will still work. If you change the default policy and eliminate the original email address, then users created without that original email address will not be able to use OMA and EAS.
This is especially critical in SBS 2003 servers and in servers where KB 817379 has been applied (which has automatically been done on all SBS 2003 servers).
This is because the directory gets updated in the Exchange virtual directory of the Default Web Site automatically by the DS2MB process of Exchange’s System Attendant. However, the Exchange-OMA directory is not updated.
If you run into this problem, you can update the Exchange-OMA virtual directory, you can update the Default Policy, or you can update individual users with the other email address; whichever works out best for your organization or your security standards.
This problem disappears on Exchange 2007, since it no longer has OMA or the ExIFS. EAS on Exchange 2007 uses Exchange Web Services (EWS).
Until next time…
As always, if there are items you would like me to talk about, please drop me a line and let me know!
Follow me on twitter: @EssentialExch