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
Received on Sat Feb 04 2012 - 21:53:39 MST
This archive was generated by hypermail 2.2.0 : Sun Feb 05 2012 - 12:00:02 MST