NOTE: This post – drafted, composed, written, and published by me – originally appeared on https://blogs.technet.microsoft.com/johnbai and is potentially (c) Microsoft.
Often times, it may be necessary to test the RpcProxy URL to verify connectivity to your servers. There are various reasons for doing this but the primary is to verify if the connectivity problem isn’t limited to a problem with Exchange in O365.
RpcProxy is a compound URL, meaning it comprises different parts to make the whole. Let’s use this example URL and I’ll break down what I mean:
So, the easiest one is the ‘mail.contoso.com’ as it’s the vanity name for external access to the Exchange environment. We follow that with the rpcproxy path in IIS, ‘/rpc/rpcproxy.dll’. We use a delimiter ‘?’ between the vanity name and the server and this is to pass the server we want to hit in the backend (in 2007, this will be your node name). Then, we have the server name ‘MailboxServer.contoso.com’, followed by one of the Outlook Anywhere ports: 6001, 6002, or 6004.
How do we test it? Easy! Use your favorite web browser and browse to the target destination. IIS should require you to authenticate (use your on-premises credentials you use for the migration) and you should get a blank page.
How do we know it fails? Well, the first sign would be a HTTP 400 error. If you have ISA or a TMG, you might get 503 or 500 errors; you may also get “The server denied the specified Uniform Resource Locator (URL). Contact the server administrator.” The key here is: is the error reproducible from other sources and what is the error returned, if any?