Exchange Server Name Does Not Resolve Externally

Hope this can help

How to Configure Exchange Server 2010 Outlook Anywhere
http://exchangeserverpro.com/how-to-configure-exchange-server-2010-outlook-anywhere

- Rancy

Thanks for the link, but I don't see any references to the ports in question.
As said, our "Outlook Anywhere" works 100%.
It is just the "internal Exchange server name" that does not resolve when setting up new clients externally.

TCP Port 6001: Microsoft Exchange Server Store Services

TCP Port 6002: Microsoft Exchange AddressBook Service

TCP Port 6004:
Port 6004 is one of the default ports used in Microsoft Exchange Server. There are two main servers attributed to this port, namely DSProxy and ncacn_http.
DSproxy uses port 6004 as a proxy port, mainly used by Microsoft Outlook Anywhere to synchronize with mailbox information found on a remote Exchange Server via HTTP.
A client terminal initiates several HTTP sessions on port 6004 on the Exchange server. One HTTP service for RPC requests to the server and another for RPC requests from the server.
The RPC proxy server extracts the RPC requests from the HTTP service on port 6004 and forwards it to the Exchange server using the same route. These functions allow remote users to access their email on the Exchange server via port 6004 using POP, IMAP, OWA, Active Sync, and RPC/HTTP for Outlook Anywhere applications.

Also see:
http://technet.microsoft.com/en-us/library/bb331973.aspx
http://www.pc-library.com/ports/tcp-udp-port/6004/

Thanks for this ...

A straight forward question I guess, which I am having difficulty finding an answer for;

Does the default "Outlook Anywhere Rules" in TMG for RPC, OWA, AS, include access via ports 6001, 6002, 6004?

Or are all traffic streamed in the SSL tunnel over port 443?

Can you confirm that you have all the proper DNS records for OWA in your registrar's DNS server.
Can you also confirm that your firewall lets all the 443 requests from Internet to reach your Exchange server?

Yes, our router nats 443 through to TMG,
All the default "Outlook Anywhere Rules" are setup in TMG

As said above, our exchange server local name is:  EXCHANGE.DOMAIN.LOCAL
This name is not resolvable or accessible from the internet;

However, we have a FQDN, part of the SSL certificate mail.internetdomain.com
This name resolves from the internet, points to our router -> TMG -> Exchange server.

It looks like it should, look at
Windows Firewall Rules Created by Exchange 2010 Setup in the link I posted: http://technet.microsoft.com/en-us/library/bb331973.aspx

Not sure if TMG picks it up though.

Did you check the (open) ports on your router/firewall?

internal Exchange server name - The name that resolves over Internet can never be internal but more of the Name you mention in the OWA  URL ...... makes no sense that how your internal name will resolve over internet as if that happens it means your Internal server is open for Internet :(

- Rancy

Yes, I have the router ports (natted)
The only port that we forward to TMG from the router side, is 443
Not sure if 6001, 6002 & 6004 should also be open from the internet to TMG?

Yes Rancy, as mentioned, the only name thats open on the internet is mail.internetdomain.com

I guess the question is whether ports 6001, 6002 and 6004 should be opened in our router, and natted through to the TMG server -> Exchange.

Or are these part of the SSL tunnel? on port 443?

Might be worth to give that a try.....

I found this article;  From what I gather Outlook via router to TMG only uses 443, until the packets are unwrapped into 6001, 6002 & 6004.  This happens in Exchange RPC proxy?

Does anyone agree?

Outlook 2003 clients support direct connectivity to Exchange servers by using RPC. However, these clients can also communicate with Exchange 2003 servers that are hosted on Windows Server 2003-based computers on the Internet. The use of RPC over HTTP communication between Outlook and Exchange server eliminates the need to expose unauthenticated RPC traffic across the Internet. Instead, traffic between the Outlook 2003 client and the Exchange Server 2003 computer is tunneled within HTTPS packets over TCP port 443 (HTTPS).

RPC over HTTPS requires that port TCP 443 (HTTPS) be available between the Outlook 2003 client and the server that is functioning as the "RPCProxy" device.

The HTTPS packets are terminated at the RPCProxy server and the unwrapped RPC packets are then passed to the Exchange server on three ports, in similar fashion to the direct RPC traffic described above.

These RPC over HTTPS ports on the Exchange server are statically mapped to TCP 6001 (the Information Store), TCP 6002 (Directory Referral), and TCP 6004 (DSProxy/NSPI).

No endpoint mapper must be exposed when using RPC over HTTPS communication between Outlook 2003 and Exchange 2003, since Outlook 2003 knows to use these statically mapped endpoint ports. In addition, no global catalog needs to be exposed to the Outlook 2003 client because the DSProxy/NSPI interface on the Exchange 2003 server will provide this functionality.

As I read that, I agree. So no need for opening those ports on the router/firewall.
Though TMG might be another story.....

Only 443 needs to be allowed through the TMG.  The Exchange Web Client publishing rules will take care of this.
Is your Exchange 2007 fully updated?  You could get the error about "Testing the NSPI failed" if not using SP1 Update Rollup 4 or later due to an issue with IPv6.
http://clintboessen.blogspot.com/2010/07/error-occurred-while-testing-nspi-rpc.html
http://dani3lr.wordpress.com/2009/06/02/outlook-anywhere-client-connectivity-issue-because-of-tcpipv6/
When running through testexchangeconnectivity.com, it shows my internal server name for the NSPI test and the ping returns fine.  It's not directly trying to ping it from the outside.  As I understand it the communication on those ports is between the mailbox server and the CAS.

This is without changing any firewall rules in TMG, nor router nat rules. - So as said you havent opened port 6004 or others on the Firewall (am i Right) ?

So no certs on the Exchange 2010 server as of now ?
Check properties of the Exchange 2010 Mailbox database to check which CAS is it pointing to ?

- Rancy

Confirmed - without changing any firewall rules or open any additional ports
No certs on Exchange 2010, still on Exchange 2007

Are you referring to:
Organisation Configuration, Mailbox Database, Client Settings:
Default public folder database = Exchange 2007\Second Storage Group\BES

I have noticed that while RPC works and resolves fine for users migrated to 2010,
OWA does not work for migrated users.  I guess it is because our cert and OWA rule still points to 2007?

I checked the internal & external URL for the client access rule of OWA (FQDN of SSL)

Nopes properties of the Mailbox database and what is the RPC\CAS server ?
OWA should work internally with ServerName\owa .... you can check the internal URL in EMC on OWA properties in Server->ClientAccess.

- Rancy

Yes, OWA works internally with local IP\owa or ServerName\owa
But not externally;

Strange that RPC works externally for 2010 users while cert is on 2007.

On Organisation Configuration, Mailbox, Mailbox Database
Right-click properties, it only shows the mailbox server?
* No RPC\CAS server?

Externally it would work with Cert information thats currently pointing to E2k7.

Please run the below comand with your E2k10 MailboxDatabase name and check what is "RpcClientAccessServer".

Get-MailboxDatabase "Database Name" |fl *RPC*

- Rancy

Thanks,

The RPCClientAccessServer is "NewServer.Domain.LOCAL"
Thus, it points to the 2010 server.

Regards

Perfect !! So this is the CAS server that your clients will work with.

- Rancy

Exchange 2007 still does not resolve externally, but upgrading to Exchange 2010 resolved the problem;