As already announced in Part 1, we will now look at the Outlook Anywhere connection (RPCoverHTTPS) itself and why the certificates play a decisive role.
As shown in the first part, the Outlook profile was updated and the Outlook Anywhere settings were transferred to the client:
My test computer is no longer connected to the local network but via UMTS and wants to use Outlook Anywhere. Outlook is started and after a short time a window appears prompting me to enter my user name and password.
The background is as follows: In part 1 it was set that standard authentication should be used, and standard authentication requires the user name and password to be entered. The user can of course click on "Save login data". It is therefore quite normal behavior that the user name and password are requested at this point.
In part 1, the certificate was also not adjusted, which is why this certificate error occurs directly after logging in:
If you look closely, you will recognize that there are 2 errors: The upper message indicates that a certificate was issued by a trusted CA, but the name "autodiscover.frankysweb.org" was not found on the certificate. The upper message could still be confirmed, but the lower message indicates that there is now a serious problem with the certificate. In the first screenshot you can see that the check mark for "Only connect to proxy servers whose certificate contains the following principal name" means: No connection as long as "oa.frankysweb.org" is not on the certificate. Now you could remove the tick manually, but Autodiscover reconfigures this anyway, see part 1. In this case, a SAN (Subject Alternate Name) or UC certificate is required. How such a Windows CA certificate can be issued is explained here:
https://www.frankysweb.de/exchange-2010-san-zertifikat-und-interne-zertifizierungsstelle-ca/
To avoid warnings or errors, the following names must appear on the certificate:
- autodiscover.frankysweb.org
- oa.frankysweb.org
- EX1.frankysweb.local
- autodiscover.frankysweb.local (optional, only if no SRV record has been configured internally, but a HOST-A entry)
- EX1 (optional, but helpful if users get the idea to type in https://EX1/owa)
The name of the CAS array does not have to be on the certificate, but it can't hurt to include it if the name of the CAS array is also used for OWA etc. The name autodiscover.frankysweb.org does not necessarily have to be on the certificate either, but then SRV records must be configured for the frankysweb.org domain. Not every provider supports this (Strato does). A certificate with at least 2 names is therefore required: Outlook Anywhere DNS name and internal FQDN.
After I configured a suitable certificate, the Outlook Anywhere connection now also works. In the screenshot you can see that Outlook now establishes a connection via the proxy server oa.frankysweb.org to the server outlook.frankysweb.local.
But what exactly is happening? When Outlook is started, Outlook first tries to reach Autodiscover. different ways off. Only then does Outlook establish a connection to the proxy. In this case, the proxy is the Exchange Server itself. The connection therefore arrives at the IIS in the /RPC directory. The connection therefore appears in the IIS log files, for example here is an excerpt if the UMTS connection is anything but stable (C:\Windows\System32\LogFiles\HTTPERR):
2014-02-06 19:56:33 80.187.104.58 5326 192.168.100.251 443 HTTP/1.1 RPC_OUT_DATA /rpc/rpcproxy.dll?outlook.frankysweb.local:6001 - 1 Timer_MinBytesPerSecond DefaultAppPool 2014-02-06 19:56:48 80.187.104.58 2669 192.168.100.251 443 HTTP/1.1 RPC_OUT_DATA /rpc/rpcproxy.dll?outlook.frankysweb.local:6001 - 1 Timer_MinBytesPerSecond DefaultAppPool 2014-02-06 19:57:33 80.187.104.58 3845 192.168.100.251 443 HTTP/1.1 RPC_IN_DATA /rpc/rpcproxy.dll?outlook.frankysweb.local:6001 - 1 Timer_MinBytesPerSecond DefaultAppPool 2014-02-06 19:57:48 80.187.104.58 18916 192.168.100.251 443 HTTP/1.1 RPC_IN_DATA /rpc/rpcproxy.dll?outlook.frankysweb.local:6001 - 1 Timer_MinBytesPerSecond DefaultAppPool
And here is an example of calling Autodisover (c:\inetpub\logs\LogFiles\W3SVC1)
2014-02-06 19:54:39 192.168.100.251 POST /autodiscover/autodiscover.xml - 443 - 80.187.104.58 Microsoft+Office/14.0+(Windows+NT+6.1;+Microsoft+Outlook+14.0.6129;+Pro) 401 0 0 1343 2014-02-06 19:54:56 192.168.100.251 POST /autodiscover/autodiscover.xml - 443 - 80.187.104.58 Microsoft+Office/14.0+(Windows+NT+6.1;+Microsoft+Outlook+14.0.6129;+Pro) 401 0 0 4404 2014-02-06 19:55:02 192.168.100.251 POST /autodiscover/autodiscover.xml - 443 - 80.187.104.58 Microsoft+Office/14.0+(Windows+NT+6.1;+Microsoft+Outlook+14.0.6129;+Pro) 401 1 2148074254 5826 2014-02-06 19:55:05 192.168.100.251 POST /autodiscover/autodiscover.xml - 443 FRANKYSWEB\frank 80.187.104.58 Microsoft+Office/14.0+(Windows+NT+6.1;+Microsoft+Outlook+14.0.6129;+Pro) 200 0 0 2327
As already described in Part 1, the "RPC over HTTP Proxy" service tunnels the Outlook connection to the "Microsoft Exchange RPC Client Access Service" service. The CAS log then contains, for example, a logon event (C:\Program Files\Microsoft\Exchange Server\V14\Logging\RPC Client Access)
2014-02-06T19:56:12.477Z,9,8,/o=FrankysWeb/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=usercf007cf3,,OUTLOOK.EXE,14.0.6131.5002,Cached,,,ncacn_http,,OwnerLogon,0,00:00:00.0156200, "Logon: Owner, /o=FrankysWeb/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=usercf007cf3 in database MBDB01 last mounted on EX1.frankysweb.local at 06.02.2014 19:48:05, currently Mounted; LogonId: 2",
The "RPC over HTTP proxy" feature is not actually a service, but an ISAPI module in IIS. Therefore, the feature is not directly recognizable as a process in the task manager, because it is loaded with the IIS w3wp.exe process. This can be checked with :
tasklist /m rpcproxy.dll
Normally, the output should look something like this:
And for the sake of completeness, the DLL can be found here: c:\Windows\System32\RpcProxy and there is a configuration for it in the registry, which in turn is also overwritten by RpcHttpConfigurator every 15 minutes, so changing it here doesn't help much either.
Pretty much everything relevant is logged in the log files mentioned above, so it is a good starting point for error analysis.
Part 3 then deals with the client side.
