Re: rpc/https connectivity problem
- From: "Jared Cheney" <jcheney@xxxxxxxxxxxxxxx>
- Date: Thu, 10 Aug 2006 09:05:31 -0600
I checked an Exchange install I did in a lab env. and confirmed that the
UploadReadAheadSize property is set to zero on a build of an Exchange server
with RPCProxy enabled - so somewhere along the line it must get set to zero,
I'm guessing when you install the rpcproxy component.
"Jared Cheney" <jcheney@xxxxxxxxxxxxxxx> wrote in message
news:ubaAEUIvGHA.3936@xxxxxxxxxxxxxxxxxxxxxxx
FYI - this has been resolved. I Found the following post that seemed to
accurately describe the fix:
http://www.mcse.ms/archive76-2005-1-1340025.html, but I still didn't
understand exactly what was going on. So I did some more digging to try to
understand what was happening and found these:
http://www.motobit.com/help/asp-upload/pa83.htm
http://asp-upload.motobit.com/help/pureupload/pa35.htm
http://www.issociate.de/board/post/199958/Failure_posting_files_to_iis6.0_using_ssl_client_authentication.html
I examined UploadReadAheadSize property in the IIS Metabase for the Rpc
virtual directory on the three servers, and found that the two that worked
had the property set to 0, while the broken one had it set to the default,
49152 (48 KB). For some reason, the broken server was set to the default
value, while the other two were set to 0 - I'm assuming maybe a patch or
reinstalling IIS somewhere along the way must have reset this to the
default (I'd like to understand the trigger if anyone has any ideas).
Then again, I'm not sure how it got set to zero initially on the working
two - perhaps Exchange does it when you mark a box as an Rpc Proxy?
If I understand correctly, the UploadReadAheadSize value determines how
much data the IIS process is going to 'read ahead' and respond to the
client for before it hands the stream off to an ISAPI application (such as
rpcproxy.dll). The problem is that the IIS process tells the client 'ok
to continue' after reading the first 48 KB and then hands it off to
rpcproxy.dll. Then rpcproxy.dll must be requesting further information
from the client, but the client is confused because it already got the go
ahead to continue, so it's trying to send more data. This leads to a
deadlock of sorts and the RpcProxy server eventually severs the
connection, resulting in the message in the Outlook client that the
Exchange server is unavailable. By setting the UploadReadAheadSize value
to zero, you cause IIS to hand the stream off to rpcproxy.dll immediately,
so that it can correctly handle the requests going back and forth from the
beginning.
At any rate I went ahead and modified it to match the other two (zero) and
it began working flawlessly.
Thanks,
Jared
"Jared Cheney" <jcheney@xxxxxxxxxxxxxxx> wrote in message
news:uQw57t9uGHA.5092@xxxxxxxxxxxxxxxxxxxxxxx
Hi,
I have three identically configured RPCProxy servers that we utilize for
rpc over https connectivity from Outlook users from the Internet. Two of
the servers are working fine, but the third is not working right now -
trying to connect to a mailbox when using it as the proxy server results
in a long delay in the startup of Outlook, and eventually a message
stating that 'your Exchange server is unavailable'. I'm able to connect
to the same mailbox using the same Outlook client via a different proxy
server, however.
I don't see any entries at all in my W3SVC logs, but I do get the
following in my HTTPErr logs (names and IPs changed to protect the
innocent ;):
2006-08-09 17:26:35 1.2.3.4 45769 10.1.1.3 443 HTTP/1.1 RPC_IN_DATA
/rpc/rpcproxy.dll?mailserver01.mydomain.com:6002 400 1 BadRequest
DefaultAppPool
2006-08-09 17:27:33 1.2.3.4 45769 10.1.1.3 443 HTTP/1.1 RPC_IN_DATA
/rpc/rpcproxy.dll?mailserver01.mydomain.com:6002 400 1 Connection_Dropped
DefaultAppPool
2006-08-09 17:27:33 1.2.3.4 45772 10.1.1.3 443 HTTP/1.1 RPC_OUT_DATA
/rpc/rpcproxy.dll?mailserver01.mydomain.com:6002 - 1 Connection_Dropped
DefaultAppPool
I've found very little to explain what the Connection_Dropped code means.
Anyone have any ideas?
Thanks,
Jared
.
- References:
- rpc/https connectivity problem
- From: Jared Cheney
- Re: rpc/https connectivity problem
- From: Jared Cheney
- rpc/https connectivity problem
- Prev by Date: Re: rpc/https connectivity problem
- Next by Date: Routing incoming mail messages to one of two mail systems by ID or individual address...
- Previous by thread: Re: rpc/https connectivity problem
- Next by thread: OWA POP3 IMAP slow failure on internet connection
- Index(es):
Relevant Pages
|