[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
?
Solved

Exchange Server Name Does Not Resolve Externally

Posted on 2012-08-24
24
Medium Priority
?
1,703 Views
Last Modified: 2012-09-30
Hi Guys,

Our Exchange server does not resolve externally when setting up a new client.

When a client is setup internally, the name resolves and all external functions, RPC, OWA, etc works fine, even when accessing remotely over the internet.

So the problem comes in when a new client is initially configured EXTERNALLY.
We ran several connectivity tests, including the REMOTE CONNECTIVITY ANALYZER, and all tests passed apart from the following:

Testing the NSPI failed.
An error occurred while testing the NSPI RPC end point.
Attempting to ping RPC endpoing 6004 (NSPI proxy interface) CIEX.CIPSZA.LOCAL
The RPC_S_SERVER_UNAVAILABLE
Error (0x6ba) was thrown by the RPC runtime process


I gathered that RPC uses some ports for DNS translation, 6001, 6002, 6004
These are not currently part of our router's NAT rules, and not sure if these ports are required?

We have an internal name for our Exchange server, EXCHANGE.DOMAIN.LOCAL
Which will obviously not resolve externally.

All the TMG rules have been added for Exchange OWA, ACTIVE-SYNC, RPC, etc.
All works, but I realised that RPC works over port 443 and I don't see any provision for ports 6001, 6002 and 6004 in TMG.

Any help in the right direction will be appreciated;

Regards
Rupert
0
Comment
Question by:Rupert Eghardt
  • 11
  • 6
  • 5
  • +2
24 Comments
 
LVL 52

Expert Comment

by:Manpreet SIngh Khatra
ID: 38328738
Hope this can help

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

- Rancy
0
 

Author Comment

by:Rupert Eghardt
ID: 38328777
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.
0
 
LVL 35

Expert Comment

by:Ernie Beek
ID: 38328783
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/
0
Granular recovery for Microsoft Exchange

With Veeam Explorer for Microsoft Exchange you can choose the Exchange Servers and restore points you’re interested in, and Veeam Explorer will present the contents of those mailbox stores for browsing, searching and exporting.

 

Author Comment

by:Rupert Eghardt
ID: 38328821
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?
0
 
LVL 7

Expert Comment

by:djStraTTos
ID: 38328832
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?
0
 

Author Comment

by:Rupert Eghardt
ID: 38328848
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.
0
 
LVL 35

Expert Comment

by:Ernie Beek
ID: 38328851
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.
0
 
LVL 35

Expert Comment

by:Ernie Beek
ID: 38328857
Did you check the (open) ports on your router/firewall?
0
 
LVL 52

Expert Comment

by:Manpreet SIngh Khatra
ID: 38328871
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
0
 

Author Comment

by:Rupert Eghardt
ID: 38328888
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?
0
 

Author Comment

by:Rupert Eghardt
ID: 38328899
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?
0
 
LVL 35

Expert Comment

by:Ernie Beek
ID: 38328902
Might be worth to give that a try.....
0
 

Author Comment

by:Rupert Eghardt
ID: 38328991
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.
0
 
LVL 35

Expert Comment

by:Ernie Beek
ID: 38329032
As I read that, I agree. So no need for opening those ports on the router/firewall.
Though TMG might be another story.....
0
 
LVL 41

Expert Comment

by:footech
ID: 38331065
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.
0
 

Accepted Solution

by:
Rupert Eghardt earned 0 total points
ID: 38335968
While troubleshooting this particular problem;

We are in the process of migrating users to Exchange 2010;

Interestingly, we've moved a remote user mailbox to Exchange 2010, and now his Outlook is able to resolve our Exchange server name without difficulty.

This is without changing any firewall rules in TMG, nor router nat rules.
Our SSL certificate is still loaded on the Exchange 2007 server;
TMG also still points to Exchange 2007.

I guess Exchange 2007 acts as the client access server,

The only change is the user mailbox being migrated to Exchange 2010.
The problem seems to have been in Exchange 2007?
0
 
LVL 52

Expert Comment

by:Manpreet SIngh Khatra
ID: 38336003
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
0
 

Author Comment

by:Rupert Eghardt
ID: 38336026
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)
0
 
LVL 52

Expert Comment

by:Manpreet SIngh Khatra
ID: 38336044
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
0
 

Author Comment

by:Rupert Eghardt
ID: 38336122
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?
0
 
LVL 52

Expert Comment

by:Manpreet SIngh Khatra
ID: 38336160
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
0
 

Author Comment

by:Rupert Eghardt
ID: 38336247
Thanks,

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

Regards
0
 
LVL 52

Expert Comment

by:Manpreet SIngh Khatra
ID: 38336331
Perfect !! So this is the CAS server that your clients will work with.

- Rancy
0
 

Author Closing Comment

by:Rupert Eghardt
ID: 38448390
Exchange 2007 still does not resolve externally, but upgrading to Exchange 2010 resolved the problem;
0

Featured Post

 [eBook] Windows Nano Server

Download this FREE eBook and learn all you need to get started with Windows Nano Server, including deployment options, remote management
and troubleshooting tips and tricks

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Want to know how to use Exchange Server Eseutil command? Go through this article as it gives you the know-how.
With so many activities to perform, Exchange administrators are always busy in organizations. If everything, including Exchange Servers, Outlook clients, and Office 365 accounts work without any issues, they can sit and relax. But unfortunately, it…
The basic steps you have just learned will be implemented in this video. The basic steps are shown to configure an Exchange DAG in a live working Exchange Server Environment and manage the same (Exchange Server 2010 Software is used in a Windows Ser…
There are cases when e.g. an IT administrator wants to have full access and view into selected mailboxes on Exchange server, directly from his own email account in Outlook or Outlook Web Access. This proves useful when for example administrator want…
Suggested Courses
Course of the Month18 days, 10 hours left to enroll

834 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question