Join the club, I haven't resolved it yet. At one time it seemed to work (didn't do anything in particular) then I had a user tell me that it still didn't work. Right now I am waiting to have some time to upgrade ISA 2004 to the 2006 flavor and see it that helps...
Make sure the clients have the CA certificate installed on them, and that the naming conventions are correct on the ISA Firewall's Web site cert and the Exchange Server's cert.
I have the same problem, when i go to https://mydomain.nl/rpc/rpcproxy.dll i got the same error, i have looking for 24 ours to the problem but nothing wil work.
The only difference i have is a real certificate from GTE cybertrust,
i am facing the same issue with ISA2006 /Exchange 2003 SP2 on Windows 2003 R2.
The direct connection on the LAN works fine and i run all the tests i know. When i connect from the ISA server the connection is good as well (certificate trused, empty webpage when i browse to ../rpc/rpcproxy.dll). But when i try to connect from outside the connections fails. The only thing i found has been in the HTTPERR directory: 007-02-14 17:44:34 <IP of the ISA internal interface> 32620 <IP of the FE server> 443 HTTP/1.1 RPC_IN_DATA /rpc/rpcproxy.dll?<BE server name>:6004 400 1 BadRequest DefaultAppPool 2007-02-14 17:45:34 <IP of the ISA internal interface>32620 <IP of the FE server> 443 HTTP/1.1 RPC_IN_DATA /rpc/rpcproxy.dll??<BE server name>6004 400 1 Connection_Dropped DefaultAppPool 2
Must be something easy to fix, but i cannot find it....
Read my article on RPC/HTTP publishing and try to understand the underlying concepts as I explain them. There are a lot of moving parts and you'll not be able to find the broken part if you just try to follow the steps, esp. if you're not mirroring my lab environment exactly and try to make small but significant deviations from what I've done.
I just spent all day on the phone with MS over this one. Here is what I found out starting with what my problem was.
Environment: ISA Server 2006, tri-homed (WAN,DMZ,LAN) Exchange 2003 Frontend server in DMZ (single homed) Exchange 2003 Backend server on LAN (single homed)
Solution: In addition to the usual set of firewall rules for the Frontend to talk to the Backend and the DCs and the GCs there are three additional ports for RPC over HTTP aka RPC Proxy. TCP Ports 6001,6002,6004. You can verify this in the registry on the Frontend server (assuming that your Frontend server can talk to the Backend already and that Exchange System Attendant is running) HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\RpcProxy\ValidPorts
Create custom protocal(s) for 6001-6002, 6004 or 6001-6004 if you are lazy like me and allow them from the Frontend to the Backend.
Other things I learned. 1) Error 64 when connecting through the ISA box to https://mail.company.com/rpc/rpcproxy.dll via a web browser is NORMAL and is the CORRECT behavior. What error 64 means in this regard is that the wrong client agent was used to access the url. In this case a web browser was used instead of Outlook/MSPRC.
2) ISA Server 2006 is not currently (May 31, 2007) fully compatible with Windows Server 2003 SP2. You need to make the following registry changes and reboot. (please go verify this somewhere, I am going off of what MS told me) [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters] "EnableTCPA"=dword:00000000 "EnableRSS"=dword:00000000 "EnableTCPChimney"=dword:00000000 **and perhaps: "EnableSecurityFilters"=dword:00000000
3) To restart IIS from and command prompt even faster type: iisrest
4) The ISA Best Practices Tool has the Debug tools in it that MS will need to assist you so be sure to keep your Best Practices Tool up to date
5) When using "outlook.exe /rpcdiag" HTTPS means RPC over HTTP and TCP/IP means straight RPC.
6) To troubleshoot RPC over HTTP you may have to disable Outlook's ability to revert back to using straight RPC. [HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\RPC] "DisableRpcTcpFallback"=dword:00000001
7) ISA Server 2006 has all kinds of nefty monitoring filters, don't be afraid to add columns so that you can see more and create filters that filter applied rules. For example, a filter like Rule Equals "Inbound Exchange Services" can come in hand when troubleshooting.
9) A lot of people have seen this problem, I’m not sure if “my” fix will help everyone but I am going to do my best to post it everywhere I looked that didn’t have the solution posted.
Posts: 271
Joined: 5.May2001
From: Redmond, WA
Status: offline
While this posting is absolutely chock full of interesting tidbits, there are some "non-facts" 1) Error 64 when connecting through the ISA box to https://mail.company.com/rpc/rpcproxy.dll via a web browser is NORMAL and is the CORRECT behavior. What error 64 means in this regard is that the wrong client agent was used to access the url. In this case a web browser was used instead of Outlook/MSPRC. ** this is incorrect. the user-agent is not validated at all. In fact, an "error 64" is expected does not indicate a problem with your RPC/HTTP traffic at all. This tells you only that the connection was terminated sooner than ISA expected. You'll see this with RPC/HTTP traffic from OL clients as well.
2) ISA Server 2006 is not currently (May 31, 2007) fully compatible with Windows Server 2003 SP2. You need to make the following registry changes and reboot. (please go verify this somewhere, I am going off of what MS told me) ** this is incorrect. These changes affect any NAT process on Windows 2003 SP2 and some Broadcom NICs regardless of NAT. Also, when you factor in the temproral differences between ISA and WS03 SP2, the "incompatabililty" belongs to Windows; not ISA.
Other than that, you gathered some neato techniques. Look to the isablog soon for some other options for testing your RPC/HTTP path with or without ISA.
BTW, I'd be very interested in your case # - there seems to be an ISA support engineer that needs some "updating"...
Thanks for stepping in to help teach the boys! The troubleshooting process for RPC/HTTP has always been a holy grail around here. From my expereince, the ISA logging isn't a whole lot of help in troubleshooting RPC/HTTP issues so it's often a hit or miss issue 'round here.
1) No, no.. what he said was that since the wrong agent is used (IE instead of MSRPC) the connection is dropped. This is the correct behavior because you are using IE instead of Outlook to test. As a result... "Don't use IE to test RPC over HTTP with ISA", Least that is what he was getting at.
2) Your right, your right.. SP2 did come AFTER ISA 2006, and those are general TCP/IP settings so it is accurate to say, SP2 is not compatible with ISA 2006. Thanks.. :)
If you are at MS do a search for case# 600901. (I'm leaving off the leading numbers in the SRX)
< Message edited by awurthmann -- 4.Jun.2007 3:41:17 PM >
Posts: 271
Joined: 5.May2001
From: Redmond, WA
Status: offline
1) - The user-agent is irrelevant, since the RPCProxy is not evaluating this at all. IE fails as an RPC/HTTP test method, not because of the user-agent, but because IE can't generate the required HTTP method (see the latest isablog for the latest RPC/HTTP entry)
we too are now having this error when users use our ISA server for OWA. We have been on phone with Microsoft support all night and no luck so far. Did anyone every come up with at fix?
Hi guys, I had exactly the same problems as many of you describe, exactly the same issue as the OP, no matter what I did to the ISA box nothing worked to get rpc/https working, until finally I went back to the Exchange server.
In the end what worked was an uninstall/reinstall of the RPC Proxy serverice on the exchange box followed by a re creation of the listening ports. The following is taken from the ISA 200 lab manual and worked a treat for me.
Open a Command Prompt window. b. At the command prompt, type cd \tools\reskit, and then press Enter. The Reskit folder contains a configuration tool (rpccfg.exe) from the Windows Server 2003 Resource Kit. At each of the steps below, press Enter after the command. c. Type rpccfg /hd. The output of the command displays which ports on which computer the RPC Proxy service is allowed to create an RPC connection to. The default setting is: Denver 100-5000. d. Type rpccfg /hr Denver. This removes the current port range settings for Denver. The next commands add the required port ranges for both the NetBIOS name, and the fully qualified domain name (FQDN) of the (back-end) Exchange Server and Global Catalog server. The RPC connections to the Exchange Server are done at port 6001 (Store), 6002 (DSReferral) and 6004 (DSProxy). e. Type rpccfg /ha Denver 6001 6002 6004. f. Type rpccfg /ha denver.contoso.com 6001 6002 6004. g. Type rpccfg /hd.
I just had the problem reoccur. Single NIC ISA in a Vlan/DMZ with a single Exchange server sitting in another Domain from the ISA.
Nothing has changed in the configuration from when we fixed this last time, but suddenly the outlook clients are getting the exact same error message.
I reinstalled the RPC proxy service and used the above to reconfigure the ports and users started to work again.
The only thing thats different is that the CP firewall the ISA sits behind is "flapping" at the moment and randomly going up and down. I dont know why this would cause the observed fault.
I inherited the current system and one good thing is I now know a hell of a lot about Reverse Proxying and exchange :)
|
My Subscription |
My Forums |
Address Book |
Member List |
Search |
FAQ |
Ticket List |
Log Out
Printable Version
All Forums >> [ISA Server 2004 General ] >> Exchange Publishing >> RE: RPC over HTTPS status code 64 
RE: RPC over HTTPS status code 64 - 
New Messages
No New Messages
Hot Topic w/ New Messages
Hot Topic w/o New Messages
Locked w/ New Messages
Locked w/o New Messages
Post New Thread