lör 2012-02-04 klockan 15:22 +1300 skrev Amos Jeffries: > Sigh. Exchange is VERY sensitive to the nature of requests it receives. > I suspect very much that this URL re-writing is part of the problem. Yes. You can not rewrite URLs in any manner when reverse proxying - Exchange - Most WebDAV servers - Or many other "non-browser things" Not even port numbers in most cases. And if doing https offload then you MUST enable proper support for negotiating this to the web server. I.e. front-end-https cache_peer option when talking to Microsoft IIS/OWA, or special configuration at the web server telling it that the requested URLs are really https:// even if received unencrypted by the web server.. > Start with re-considering *why* your Exchange server and Outlook clients > are not communicating the correct URLs between each other and what can > be done to their configuration to fix that. In most cases it's a matter of 1. Configure the reverse proxy with vhost option. Works for https_port as well. Or if you use defaultsite then this SHOULD be the actual requested hostname normally requested by the clients, not the backend server name. 2. Add the actual requested hostname as site name in the web server configuration. cache_peer takes care of routing the request to the right server so it's only a matter of making the web server recognize the requested host name as valid for it's content. > > A connection attempt through squid to the exchange server on a browser is logged in access.log as follows > > https://<squid's IP>/testuser@<exchange server>/ Don't test using IP. Set up a proper hostname in DNS for the access. Or in your local hosts file for testing only before updating DNS. Regards Henrik
