HTTP 401.5 errors with the Duet 1.5 Request Handler

Problem:

When sending large (>25k) control messages, these messages do not get sent to the clients, and they become orphaned in the Request Handler’s “Drafts” folder.  Reviewing the IIS logs on the Exchange server shows a corresponding series of PROPPATCH attempts resulting in 401.5 errors.

Below is what you might see in the IIS logs from the Exchange server:

2009-01-15 06:54:28 10.3.13.56 PROPPATCH /Exchange/DuetRH/Drafts/abea3f82f455447285ce821d66d7e3a4.EML - 80 - 10.16.0.95 - 401 2 2148074254

2009-01-15 06:54:30 10.3.13.56 PROPPATCH /Exchange/DuetRH/Drafts/abea3f82f455447285ce821d66d7e3a4.EML - 80 DE\DS91FE 10.16.0.95 - 401 5 0

The first 401 error is expected as we try to access the server with Anonymous access, while the second 401 is our error.  Our error corresponds to “401.5 - Authorization failed by ISAPI/CGI application”  For more information on HTTP status codes:

Description of Microsoft Internet Information Services (IIS) 5.0 and 6.0 status codes

Cause:

When we reach a certain limit of data in the WEBDav request, IIS needs to create temp files to work with these large WEBDav requests and therefore the w3wp process tries to write these temp files out to a folder that is listed in the system TMP environment variable.  If the account that the request handler is impersonating does not have access to that folder these errors will be returned to the RH.

Resolution:

There are two approaches that we can use to resolve this (To be completed on the Exchange server that is home to the Request Handler mailbox):

1> Change the permissions for the temp directory that is indicated in the system environment variable TMP to allow those users that we are running the request handler to have Read/Execute, Write, and Modify permissions or add “authenticated users”

2> Change the directory that the “TMP” variable is pointing to a directory that the user that the request handler is impersonating has Read/Execute, Write, and Modify permissions also.