I often receive questions about problems with Outlook Anywhere (RPCoverHTTPS) by email or here in the blog. However, the reasons why Outlook Anywhere does not want to work or does not work as expected can be very different. That's why I'm going to take a closer look at the configuration and error analysis of Outlook Anywhere. I have installed a demo environment, which is often found in smaller installations:
Es gibt einen Domain Controller (DC1) und einen Exchange Server (EX1) auf dem alle Exchange Rollen installiert sind. Im Netzwerk gibt es einen Router für den Internetzugang und irgendwo im Home Office gibt es einen PC der sich via Outlook Anywhere mit Exchange verbinden soll. Das Active Directory hört auf den Namen „frankysweb.local“. Soweit zur internen Netzwerkstruktur.
Jetzt zur Öffentlichen Struktur: Ich benutze für diesen Artikel die Domain „frankysweb.org“. Die bei einem Webhoster (in meinem Fall Strato) gehostet wird. Bei bem Home Office PC handelt es sich um ein Notebook welches für diesen Artikel per UMTS Internetzugriff erhält. Das Notebook ist Mitglied der Domain „frankysweb.local“.
No Outlook Anywhere is configured on my Exchange 2010 Server EX1 so far, so I describe the setup and deliberately cause errors to show what effects it has.
As Outlook Anywhere is not yet activated, my Outlook profile currently only contains the internal server name:
Outlook Anywhere is deactivated in the profile:
To be able to use Outlook Anywhere, it must be activated, but a few preliminary steps are necessary:
- Create DNS entries with the provider
- Set up Portforward
- Renew certificate
Let's start by setting up the DNS entries. I want to publish Outlook Anywhere on the Internet under the name oa.frankysweb.org. I therefore have to create two subdomains with my provider, both of which point to my public IP:
oa.frankysweb.org
autodiscover.frankysweb.org
A test with NSLOOKUP should then return the public IP for both entries:
We continue with the port forward. Only port 443 (HTTPS) is used for Outlook Anywhere. This means that only port 443 or the HTTPS protocol needs to be forwarded from the router/firewall to the Exchange server. Here is an example using Sophos UTM:
Depending on the router, a DNAT rule is therefore required that forwards all connections arriving at the WAN connection on port 443 (HTTPS) to the Exchange server (in my case EX1 192.168.100.251).
Here comes the first trapdoor: Although HTTPS is used as the basis of the connection for Outlook Anywhere, this is not the HTTP protocol, which is secured via SSL. In principle, Outlook Anywhere only uses the HTTPS protocol or port 443 and tunnels the RPC protocol via this connection. Some firewalls and reverse proxies have a problem with this because they expect the standardized HTTPS protocol and cannot handle RPC tunneled via HTTPS.
I should actually adjust the certificate now, but I'm deliberately skipping this step to avoid one of the most common errors: Certificate warnings!
So now I activate Outlook Anywhere
The next message already indicates that it may take up to 15 minutes for Outlook Anywhere to be activated.
After a while, you should be able to find events with the ID 30XX in the application log
Since Outlook Anywhere uses an HTTPS connection, IIS accepts the connections. Outlook Anywhere uses the RPC directory in IIS for this purpose:
Über die HTTPS Verbindung wird dann das RPC Protokoll getunnelt, diese Aufgabe übernimmt das Feature „RPC-über-HTTP-Proxy“ welches Bestandteil des Betriebssystems ist
Die Konfiguration zu Outlook Anywhere wird durch den „RpcHttpConfigurator“ durchgeführt, dieser Prozess ist Teil des Dienstes „Microsoft Exchange-Diensthost“. Dieser Prozess läuft in der Standardeinstellung alle 15 Minuten. Daher kann es auch bis zu 15 Minuten dauern, bis Outlook Anywhere aktiviert oder Konfigurationsänderungen übernommen werden. Das Intervall kann in der Registry angepasst werden
Der Dienst „RpcHttpConfigurator“ schreibt dann die Outlook Anywhere Einstellungen aus dem Active Directory in die IIS Konfiguration, dabei werden vorherige Werte im IIS überschrieben. Daher bringt es nichts Einstellungen zu Authentifizierung oder SSL im IIS zu ändern. Diese Werte werden nach 15 Minuten überschrieben. Hier ein Screenshot der Einstellungen aus dem Active Directory:
So far so good, but in the third screenshot above you can see that Outlook Anywhere is not yet activated on the client. The Outlook profile must therefore still be adjusted so that Outlook Anywhere can be used. Autodiscover is responsible for adjusting the settings.
Here is the second trapdoor. Even after Outlook Anywhere has been activated, the Outlook profile is not updated. In the next screenshot it becomes clear, the same Outlook profile, Outlook Anywhere was subsequently activated, but Outlook does not adopt the settings:
For comparison, the same user, but with a newly created Outlook profile after Outlook Anywhere was activated:
New Outlook profiles receive the current settings immediately, but existing profiles do not. The same behavior also occurs when a CAS array is subsequently set up. However, this behavior has been greatly improved with the latest service packs for Office and with the update rollups for Exchange 2010. A current Outlook in conjunction with a current Exchange 2010 server normally adopts the settings within 2 hours. This small trapdoor can therefore be circumvented by ensuring that Outlook and Exchange are up to date with the latest patches.
Brief summary:
- Outlook Anywhere Einstellungen werden durch den Dienst „Microsoft Exchange-Diensthost“ aus dem Active Directory an den IIS übertragen
- Autodiscover distributes the changed settings to the Outlook clients
- Outlook Anywhere connections are tunneled to the Exchange Server via an HTTPS connection
In part 2, we go into a little more depth and look at why the certificate is so important.