Saleem Beg
asked on
OutlookAnywhere - MAPI Mail Store endpoint - attemped to ping failed
Hi,
I have a DC (Server 2012 R2) setup, with RDS and EXCHANGE (with MS Exchange 2013 SP1) as virtual servers.
RDS is facing the internet (mail.domain.com @ Port 443), and is using ARR with URL Rewrite for OWA, EWS, Autodiscover, ActiveSync and ECP, rewriting all requests to EXCHANGE.
When I run tests on https://testconnectivity.microsoft.com for Outlook connectivity, it fails saying:
Telnet from DC or RDS into EXCHANGE on port 6001 works fine.
However, I am concerned that there may be two things preventing this from working:
1) 86b551b0-c6d5-4ec4-8f1b-66
2) Even if there is nothing wrong with the above, I would assume it is using RDS's standard 443 port, and trying to ping 6001 on RDS itself, since as far as I know, URL Rewrite has no rules to forward port requests on to exchange.
Am I right in my assumptions?
I have a DC (Server 2012 R2) setup, with RDS and EXCHANGE (with MS Exchange 2013 SP1) as virtual servers.
RDS is facing the internet (mail.domain.com @ Port 443), and is using ARR with URL Rewrite for OWA, EWS, Autodiscover, ActiveSync and ECP, rewriting all requests to EXCHANGE.
When I run tests on https://testconnectivity.microsoft.com for Outlook connectivity, it fails saying:
Attempting to ping the MAPI Mail Store endpoint with identity: 86b551b0-c6d5-4ec4-8f1b-66e01b29beeb @domain.co m:6001.
The attempt to ping the endpoint failed.
Tell me more about this issue and how to resolve it
Additional Details
The RPC_S_SERVER_UNAVAILABLE error (0x6ba) was thrown by the RPC Runtime process.
Elapsed Time: 3310 ms.
Telnet from DC or RDS into EXCHANGE on port 6001 works fine.
However, I am concerned that there may be two things preventing this from working:
1) 86b551b0-c6d5-4ec4-8f1b-66
2) Even if there is nothing wrong with the above, I would assume it is using RDS's standard 443 port, and trying to ping 6001 on RDS itself, since as far as I know, URL Rewrite has no rules to forward port requests on to exchange.
Am I right in my assumptions?
ASKER
Hi Simon,
Thanks for the response.
ARR may explain the issue with Outlook Connectivity from the internet. But it should surely connect internally directly to 'exchange' as this is what I specified as it's internal name?
Thanks for the response.
ARR may explain the issue with Outlook Connectivity from the internet. But it should surely connect internally directly to 'exchange' as this is what I specified as it's internal name?
No.
The behaviour is the same both internally and externally. Everything connects to the unique end point.
The server name isn't used by any of the clients. They have the unique end point and then FQDN configured for Outlook Anywhere.
Simon.
The behaviour is the same both internally and externally. Everything connects to the unique end point.
The server name isn't used by any of the clients. They have the unique end point and then FQDN configured for Outlook Anywhere.
Simon.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Because it worked
Hi Saleem Beg,
Can you share your rewrite rule for RPC? I'm having same issue.
Can you share your rewrite rule for RPC? I'm having same issue.
86b551b0-c6d5-4ec4-8f1b-66
is normal on Exchange 2013. All end users have a unique end point, so that is what you will see for the mailbox. Not the real name of the server, or the SSL name.
As for the second point - you are probably not getting answers because no one has done it.
ARR is still a new technology, I haven't deployed it anywhere myself. Regular RDS and Exchange OWA will paly well, but I don't know if that applies with ARR.
if it is affecting users, then one of them will have to go to get connectivity back.
Or you will have to call Microsoft support.
Simon.