Today it's about the client side and what possibilities there are to examine the RPCoverHTTPS connection.
One of the best and easiest places to go is the Remote Connectivity Analyzer from Microsoft. The RCA provides an initial quick overview of whether Outlook Anywhere is working or where there are problems. Unfortunately, the RCA does not like self-created certificates, even if they come from an internal CA:
This works better with a certificate from a public CA:
Exchange also has a CMDlet with which the connection can be fundamentally tested
Test-OutlookConnectivity -Protocol TCP
In addition, the Switch on debug modeOutlook then creates log files in the following directory:
c:\Users\%username%\AppData\Local\Temp
Unfortunately, the probably most important log file is not readable: OLKRPCLOG_Datum_Zeit.etl
You can open the log file with the event viewer or convert it to a CSV file using Tracedmp.exe, but this does not make it readable:
Connection problems from the client to the Exchange server can also be solved quite well with the Microsoft Network Monitor investigate. Here is a small example.
In the screenshot above you can see that the source (172.20.10.2) wants to establish a connection to the destination 79.197.156.15. This is an Outlook Anywhere connection setup. However, 10 seconds later a completely different IP suddenly responds to the requests (81.169.145.164). This problem usually occurs when Outlook Anywhere is operated via DynDNS services. In this case, the IP address for the DNS entry was not up to date.
A successful connection looks something like this:
As you can see, troubleshooting from the client side is difficult. That's why I always try to make all Exchange web services accessible at the same address if possible. In this example, OWA can also be reached at the address oa.frankysweb.org. This makes it a little easier to diagnose errors. Especially in the following points:
in the browser returns a certificate warning? Then Outlook Anywhere also has a problem with the certificate, in which case it is quickly clear where to look. Or does not show anything at all, then perhaps the DNS entry does not match, or a firewall is blocking the connection.
If you are sure that no firewall is blocking the connection, you can try RPCPing from the client:
rpcping.exe -t ncacn_http -o RpcProxy=oa.frankysweb.org -u 9 -a connect -v 3 -P "Benutzername,DomainName,Passwort" -H 1 -F 3
Here is a successful connection:
And here with the wrong password:
A documentary on RPCPing can be found here:
http://support.microsoft.com/kb/831051/en-us