Exchange RPC over HTTP problem with TMG
When you try to setup your Outlook with Exchange account, you get the below issue.
- In this scenario I'm using windows signed certificate for exchange but I have the CA installed on Client side.
- Client is not joined to the domain.
- Client is not on VPN.
Outlook 2010/2013 keeps prompting you for credentials even though you entered them correctly several times.
And when cancelling you receive that "The action couldn't be completed. The connection to Exchange is unavailable".
Now testing Autodiscover have resulted positively.
There's no need to test RPC over HTTP when using a windows/self-signed certificate as it won't result positive anyway
Next let's check TMG's configuration.
Every rule that involves RPC should be checked in order to make sure that your Publishing configuration is correct.
RPC Server should be pointing internally to your Exchange server and externally to your mail.domain.com External IP Address.
Although when you use TMG's wizard to publish Exchange TMG does everything for you but still you need to check if it's the right configuration.
This is my autodiscover rule configuration's paths and RPC is also included there.
Testing rule seems to result positive for all the published paths.
Let's try testing the following link and see if it authenticate. The RPCproxy is required for outlook clients to be configured properly
Outlook client tries to connect to the below link after finding the autodiscover settings
If you type your credentials, it most likely won't connect and will keep prompting or will probably say that request is invalid!
What if we changed the RPC path from autodiscover to mail.demotesas.com? The authentication method might be the problem in this case as I am using a total different authentication methods for the mail and for autodiscover rules.
Once we publish the rule, we will have to check the result of the following link
The site will mostly be accessed without any issues.
Now we can test our Outlook client setup and see if it will go well without any issues!
The problem was related to the RPCproxy.dll was not being set on the right rule and on the appropriate domain.
It should be on the mail.domain.com with the same authentication delegation.