2. Exchange 2010 setup

If you are requesting Freebusy for a user of a remote domain named, Exchange will make a DNS request for

To forward the requests to the Cloudiway platform, the DNS query must resolve to the IP address of Cloudiway.
Therefore, in every Exchange 2010 server, you will have to edit the host file and point 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

For Cloudiway to answer properly, Cloudiway needs to own a valid certificate for 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, 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 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 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

			usesystemdefault = "false"
			proxyaddress = "http://proxyserver:port/"
			bypassonlocal = "true"
			<add address="http://[a-z]+/.contoso/.com$" />
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:

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


For the *.* you might add:


For the *.* you might add