COEXISTENCE FREEBUSY FOR EXCHANGE 2010
1. Free-busy for Exchange 2010 introduction
Cloudiway FreeBusy tool allows querying FreeBusy between G Suite, Office 365 and Exchange on-premises environments.
Unlike other systems Exchange 2010 On-Premises requires extra tasks to configure the FreeBusy. This document explains how Cloudiway FreeBusy works with Exchange 2010 On Premises.
Exchange has a native functionality to forward Free Busy requests to external systems. The configuration is done using PowerShell.
The administrator needs to run the Add-AvailabilityAddressSpace command to configure Exchange to forward FreeBusy request for given SMTP Domains to a remote server.
Recent implementations of Exchange (2013 and later) have a parameter called “TargetAutodiscoverEpr” that tells where to forward the requests. This parameter has been introduced since Exchange 2013.
The Exchange 2010 Add-AvailabilityAddressSpace doesn’t have this parameter and Exchange 2010 relies on DNS requests.
If you are requesting FreeBusy for a user of a remote domain named remotedomain.com, Exchange will make a DNS request for Autodiscover.remotedomain.com and connect to the server.
The next chapter explains how to bypass that system and configure Exchange to forward the requests to the Cloudiway platform.
2. Exchange 2010 setup
If you are requesting Freebusy for a user of a remote domain named remotedomain.com, Exchange will make a DNS request for autodiscover.remotedomain.com.
To forward the requests to the Cloudiway platform, the DNS query Autodiscover.remotedomain.com must resolve to the IP address of Cloudiway.
Therefore, in every Exchange 2010 server, you will have to edit the host file and point Autodiscover.remotedomain.com to the IP provided by Cloudiway.
Requests will then be forwarded to Cloudiway.
However, traffic is encapsulated into SSL / TLS connections.
Exchange will send an HTTPS request to the server named Autodiscover.remotedomain.com.
For Cloudiway to answer properly, Cloudiway needs to own a valid certificate for Autodiscover.remotedomain.com with its associated private key.
There is also a technical limitation where there can be only one SSL certificate installed per server.
Indeed, when Exchange (acting as a client) will open an SSL connection to Cloudiway, Cloudiway doesn’t know which server name Exchange is trying to connect to and cannot select among different certificates.
Therefore, only one certificate per server in the farm can be installed and when Exchange will connect to the server pointed by Autodiscover.remotedomain.com, Cloudiway will return the certificate for this server name.
This is the reason why plugging an Exchange 2010 server requires a dedicated server on Cloudiway side (a server that “hosts” the relevant certificate).
If you have several domains that you want to be able to query the Freebusy, you will need as many certificates and as many dedicated servers as you have domains.
This might become quickly costly and if you are in this scenario, you may want to envisage an upgrade to Exchange 2013 or later to bypass this limitation and costs.
3. Freebusy proxy server configuration
This article explains how to configure Exchange On-Premises to use your proxy server when querying free/busy.
3.1 Background
The Microsoft Exchange Availability service provides free/busy information to clients that are running Outlook or OWA. Free/busy requests are sent to the CAS server of the user which forwards the request to its Availability Service.
This service is hosted in IIS (Internet Information Server).
3.2 Problem
By default, the Availability Service doesn’t use the proxy settings of the system (IE settings).
Therefore, free/busy requests sent to external systems are not forwarded to the proxy and do not reach the internet targets (ie the Cloudiway server).
3.3 Resolution
Both Exchange 2013 and Exchange 2010 require specific system.net proxy configuration if the EWS URLs are only available on the Internet through a proxy.
The only way to configure it is to edit the web.config file used by the application.
Although the easiest approach would be to make the change in the Exchange web.config file, your changes might be overwritten by patches, cumulative updates or service packs. One way to avoid this is to configure the system.net proxy settings in the root web.config instead of the Exchange Backend EWS web config.
The System.Net XML node is not in the file by default and will need to be added at the same level as <system.web> as shown on the next page.
Example of syntax for Exchange file.
Location: C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\exchweb\ews\web.config
</system.web> <system.net> <defaultProxy> <proxy usesystemdefault = "false" proxyaddress = "http://proxyserver:port/" bypassonlocal = "true" /> <bypasslist> <add address="http://[a-z]+/.contoso/.com$" /> </bypasslist> </defaultProxy> </system.net>
Example of syntax for Root web.config
Location: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\web.config
<location path="Exchange Back End/EWS"> <system.net> <defaultProxy> <proxy bypassonlocal="True" proxyaddress="http://proxyserver:port" usesystemdefault="false" /> <bypasslist> <add address="http://[a-z]+/.contoso/.com$" /> </bypasslist> </defaultProxy> </system.net> </location>
Following the changes in the web.config file, you should perform an IISRESET.
Technical reference: https://blogs.technet.microsoft.com/appssrv/2009/08/11/proxying-cas-http-cross-forest-availability-requests/
3.4 Note on the Bypasslist node
Once you have made this change, every call processed by the Availability Service will be sent to the proxy.
You can use the bypasslist node to define which requests should be sent directly (and not through the proxy).
Local servers must be represented by using regex syntaxes. See:
https://msdn.microsoft.com/en-us/library/aa903323(v=vs.71).aspx
Based on the MSDN article, we need to add the domain in regex format too. Some samples are below:
Syntax: <bypasslist> Element
That means for all the servers in company.com:
[a-z,0-9]+\.company\.com
For the *.*.company.com you might add:
[a-z,0-9]+\.[a-z,0-9]+\.xxx\.com
For the *.*.company.com:444 you might add
[a-z,0-9]+\.[a-z,0-9]+\.xxx\.com.[0-9]+
