Why would cached mode Outlook clients NDR messages for foreign connectors that Outlook online clients do not?

mblant — Mon, 08 Sep 2008 21:07:33 GMT

First, just a little background about address types and foreign connectors.
Address Types are ,as the name implies, the types of addresses that Exchange has knowledge of and that can be used for message transport.
There are several that are included with Exchange by default. You will see these stamped on each mail enabled user as proxyAddresses.
SMTP: (SMTP:mblanton@tailspintoys.com)
X400: (X400:c=US;a= ;p=TailspinToys;o=Exchange;s=Blanton;g=Michael;)
and EX: (Internal address type, not stamped on users)

You have always been able to add external address types to Exchange via gateway connectors. Fax connectors are a good example of this. Most of the time installing the a 3rd party connector will created the address type for you. Generally it will also create a gateway or connector mailbox on your server to handle those messages types. This is all based on EDK gateways which is outlined in the Exchange SDK.

Exchange 2007 will still let you install 3rd party connectors. These are now classified as foreign connectors.
These are installed with the "New-ForeignConnector" cmdlet.

Now on to the real question. When I install a new gateway or connector, why does Outlook work in online mode but not in cached mode?

In online mode when you send a message from Outlook, the message is submitted to the Outbox folder of your mailbox directly on the Exchange server. From there Exchange picks up the message and hands it over to transport for delivery.

With cached mode, Outlook tries to be a little smarter. Outlook will basically attempt to submit the message directly to transport queue for you. Outlook does this by requested and storing a list of available address types. If the address type you are attempting to send to is not on the list, Outlook will NDR the message before it ever attempts to connect to the Exchange server.
You can confirm which types are available by looking that registry keys for the cached mode profile:

Name:            01026687
Type:            REG_BINARY
Data:
00000000   03 00 0d 00 45 58 00 58 - 34 30 30 00 53 4d 54 50 ....EX.X400.SMTP
00000010   00

When the Information Store service starts, Exchange 2007 loads a list of address types which is stores in an array in memory. The key here is, when the Information Store starts...
When Outlook requests the list of available types, this array is what is returned.

Our problem comes about when a foreign connector is installed and the Information Store is not restarted. This array in memory has not been updated. Thus, as in my sample above, our Outlook cached mode client does not know about the FAX address type and Outlook will NDR any message addressed for FAX.

Simply restart the Information Store on the affected Mailbox server roles. This will update the array in memory. Then have each client log off and log back on to request the updated list from the Information Store.
You should now see the FAX address type stored for this profile and messages for address type FAX should work.

Name:            01026687
Type:            REG_BINARY
Data:
00000000   45 00 13 00 45 58 00 58 - 34 30 30 00 53 4d 54 50 ....EX.X400.SMTP.FAX
00000010   00

Exchange 2007 OWAAppPool crash on Windows 2008

mblant — Fri, 29 Aug 2008 20:29:00 GMT

Over the past week or so we've had several cases pop up where the Exchange 2007 OWAAppPool is crashing. After looking over a few of these cases we found one thing they had in common, they were all running on Windows 2008.

A little debugging and we found the culprit. We were receiving an HTTP response that we didn't recognize. That causes an exception and crashes the application pool. That response was a redirect. So, how does a redirect response crash the application pool?

Let's review our current documentation on TechNet:

How to Simplify the Outlook Web Access URL
http://technet.microsoft.com/en-us/library/aa998359.aspx

You have the option to set our response to a file or a URL.

Using the URL redirect works fine for a relative URL to the site root, this doesn't help much if you want to also redirect from HTTP to HTTPS. So, most configurations use the FILE option for the redirect.
Now, this works great with Exchange 2007 running on Windows 2003\IIS6.
Just as outlined in the TechNet article, the file can then handle the redirect to HTTPS, But the response code is still "FILE".

What happens when you install Exchange 2007 SP1 on Windows 2008?
Welcome to IIS7.

IIS7 has a new feature that was not present in IIS6 and thus was not present when Exchange 2007 was released.
We know Exchange 2007 was clearly designed with IIS6 in mind. Just note the message when installing on a straight IIS7 install:

Unable to read data from the Metabase. Ensure that Microsoft Internet Information Services is installed.
The 'IIS 6 Metabase Compatibility' component is not installed. Install the
component via Server Manager.

That feature is the Redirect response. This will allow an absolute URL as opposed to a relative URL like IIS6. The response code here is REDIRECT, not FILE or URL.

As stated before, REDIRECT is not a response type we expect. We check for FILE and URL. So, when we receive REDIRECT, we fail our test case and force an exception, thinking something bad must have happened.

You can also find this in the ApplicationHost.config file:
C:\windows\System32\inetsrv\config\applicationHost.config

If you are using this feature, anytime someone\something attempts to access the "/exchange" virtual directory we will crash the OWAAppPool. This could either be in DAVEX or EXPROX depending on if you CAS server has only the CAS role installed or CAS and MBX installed together.

Log Name:      Application
Source:        Application Error
Date:          8/28/2008 2:17:37 AM
Event ID:      1000
Task Category: (100)
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      WEBMAIL.TAILSPINTOYS.COM
Description:
Faulting application w3wp.exe, version 7.0.6001.18000, time stamp 0x47919ed8, faulting module davex.dll, version 8.1.240.5, time stamp 0x47427a90, exception code 0xc0000005, fault offset 0x00000000000d3ac1, process id 0x1078, application start time 0x01c908d5c27835da.

Our current solution is to continue using the same practice outlined in the TechNet article for IIS6 by setting a FILE response and let that handle the redirect for you.

Thanks to Brad Hughes for helping me track this down.
Check out his blog as well.
http://blogs.msdn.com/brad_hughes/

Update:
RU5 for Exchange 2007 SP1 includes an update to enabled the use of this new feature in IIS.
With RU5 installed you can now use the "REDIRECT" option of IIS7 instead of the more complex FILE option to redirect users to an absolute URL.

Description of Update Rollup 5 for Exchange Server 2007 Service Pack 1
http://support.microsoft.com/?kbid=953467

Update Rollup 5 for Exchange Server 2007 Service Pack 1 (KB953467)
http://www.microsoft.com/downloads/details.aspx?FamilyId=652ED33A-11A1-459C-8FFE-90B9CBFE7903&displaylang=en

I've been Exchanged

Why would cached mode Outlook clients NDR messages for foreign connectors that Outlook online clients do not?

Exchange 2007 OWAAppPool crash on Windows 2008