You can use your ProxySG in a reverse-proxy deployment for "Outlook Anywhere" but there are currently no caching or acceleration benefits in doing so.

The main reason this might want to be achieved is if you are already performing reverse-proxy for "Outlook Web Access" (OWA) and would also like "Outlook Anywhere" to be used through the same reverse-proxy deployment.

For future reference in this FAQ,  "Outlook Anywhere" will be referred to as "OA"

To verify how your Outlook client is currently connecting to your Exchange server (either using Native RPC or HTTP/S ) hold down your 'CTRL' key and right click on the Outlook tray-icon (next to the clock) then select "Connection status..."

TCP/IP indicates Outlook is using native RPC calls (OA is not working)

HTTP/S indicates Outlook is using RPC over HTTP/s (OA is working)

Outlook does not provide any error messages or debugging information as to why OA might be failing to connect, it will simply manifest itself in either constantly trying to establish a connection, or falling through to native RPC (assuming the client can reach the exchange server over native RPC calls)

However there are some known issues in trying to get OA to work in a reverse-proxy deployment:

1) The client (running Outlook) must have the CA or self-signed certificate of the ProxySG reverse-proxy keyring trusted in the local browsers "Trusted Root Certification Authorities".  You can download your reverse-proxy keyring from the ProxySG and install it as a CA on the client from the below URL:

https://x.x.x.x:8082/SSL/Download_ca

2) ‘Basic’ authentication must be used on the Outlook client. (This will automatically force all Outlook Anywhere traffic to https)

3) On the client, un-tick ‘Only connect to proxy servers that have this principle name in their certificate:’  This is to prevent any problems with the certificate CN from the ProxySG keyring (certificate trust between the client and the ProxySG). Once connectivity has been established and OA is working, this can be re-enabled but the CN of the certificate must match this setting.

4) The https:// URL in the "Exchange Proxy Settings" must match the CN of the keyring being used on the ProxySG for SSL termination, For example I am using 'proxy-exchange':

OA settings:

Certificate installed on the ProxySG being used for SSL termination for the reverse-proxy service:

You will see both the CN and the URL match "proxy-exchange".  This is the same principle as accessing a normal HTTPS website (if the CN doesn't match the URL, then SSL handshake will fail)

5) On the ProxySG in the forwarding configuration, make sure you un-tick ‘Verify SSL server certificate’ (Configuration --> Forwarding --> Forwarding Hosts --> Edit)

6) Disable all proxy authentication (let the Exchange server perform the client authentication).

7) Bypass all ICAP scanning for the Exchange server.  The ProxySG must not be performing any ICAP scanning for OA. The reason ICAP does not work here is most likely due to how the OA server returns a content-length of 1GB to all RPC request calls. This causes ICAP to time-out and OA to never complete the connection attempt. For example:

----------------------

RPC request:

RPC_OUT_DATA https://proxy-exchange/rpc/rpcproxy.dll?UK-Exchange.emea.lab.com:6002 HTTP/1.1
Host: proxy-exchange
User-Agent: MSRPC

RPC response:

HTTP/1.1 200 Success
Content-Type:application/rpc
Content-Length:1073741824
----------------------
 

This completes the list of known issues currently associated with OA reverse-proxy based on internal lab testing.