[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 731
  • Last Modified:

No internal email. Exchange 2010 Please help

Hello,
WE just failed over to DR site using Double Take full server failover. We changed MX records internally and externally. We get no internal emails, no errors, nothing. I can send mail out externally only. Cant receive from the outside also. Only Send Outside.

PLease help asap.
0
claudiamcse
Asked:
claudiamcse
  • 8
  • 7
1 Solution
 
NetfloCommented:
Have your MX records updated globally? Checked with MX Toolbox? Simple question, have you got port 25 open at your DR site? Can you telnet from externally to your WAN IP on port 25, does it answer with the Exchange banner?
0
 
NetfloCommented:
www.who.is/DNS/domain.com

Replace domain.com with your public domain. Are your MX records reporting the correct hostnames / IPs?
0
 
MASTechnical Department HeadCommented:
Firts you try sending emails internally.
If it does not work please create a send connector as per below
http://www.techiecomputersolutions.com/blog/28

Please make sure your 'MS Exchange transport' service is running
0
Fill in the form and get your FREE NFR key NOW!

Veeam is happy to provide a FREE NFR server license to certified engineers, trainers, and bloggers.  It allows for the non‑production use of Veeam Agent for Microsoft Windows. This license is valid for five workstations and two servers.

 
NetfloCommented:
abbasiftt he can already send emails out, send connector should be working as expected. The server at the DR site should be an exact replica of the original, including send connectors. I believe the basics need to be looked at in terms of is port 25 open? Are the global MX records reporting the correct IP?
0
 
claudiamcseAuthor Commented:
We know why there is no inbound emails externally. Netflo is absolutely correct. Thanks. We checked reverse DNS with MXT toolbox and it doesn't point to our dr exchange server. So we have to contact ISP for that. In addition, we have some kind of routing problem on the firewall. Because when we look at the email headers the external ip shows as firewall ip and NOT exchange server's IP that is on the MX records.

Regarding internal emails. Why there is no internal email? There is no error logs on the hub server and anywhere. Does anyone know why there is no internal emails?
0
 
NetfloCommented:
When you failed your Exchange over to the DR site, is your original Exchange server online or offline? Your emails may be sitting on your old server and delivered, however all the clients are looking at the new site?

Do you have different internal IP addresses for the two Exchange servers, one for the local and another for the DR site? If so, try to ping the Exchange server by name, see what responds as it may point out where your emails are going.
0
 
claudiamcseAuthor Commented:
We shut down our Production Excange server. So, no emails are going to the PROD exchange.

We do have different IP addresses for two Exchange servers. They are on different networks 192.168.0.0 and 192.168.1.1

We were able to ping Exchange server by name. It must be something with Sites.
Please help
0
 
claudiamcseAuthor Commented:
Here is the error that we are getting:
The recepient and the exchange server are in different active directory sites


0
 
NetfloCommented:
Have you setup Active Directory Sites and Services to reflect your DR site.

See the following link: http://technet.microsoft.com/en-us/library/aa996299.aspx
0
 
claudiamcseAuthor Commented:
No. Do we need to set it up?

I have the following:
Two sites: Prod and DR
Two subnets: 192.168.0.0/24 for PROD and 192.168.1.0/24 for DR


 I see there is a DefaultIPSiteLink under "InterSite-Transports>IP

But, there is no SMTP Site Link.

The production servers are off anyway, and everything should be working off the DR wich is on the 192.168.1.0 subnet

I transferred all FSMO roles to the DR DC wich is also GC on 192.168.1.0 subnet. Exchange DR should be able to get all info from DR DC wich now has all FSMO roles. Exchange DR is HUB,MB, and CA

But all clients workstations are of course still on 192.168.0 Prod subnet. The error I am getting is that the recepient and the Exchange server are in different active directory sites.

Please help to resolve this complicated issue. could you please let me know in details what the problem is and how to fix it.

Thank you
0
 
claudiamcseAuthor Commented:
OK. So, anyway. Exchange 2010 uses the routing path derived from IP site link information.
So we do have a Site link setup between PROD and DR. How come there is no internal email flow...
0
 
NetfloCommented:
If you could answer the following separately:

1. Is the Exchange server at your DR site the same name?

2. When Outlook is opened, does it successfully connect to Exchange in Online or Connected mode?

3. What is serving local DNS resolution to the clients at your remote site?

4. On the remote DC, when you open up CMD and type in NETDOM QUERY FSMO, does it report that its holding all FSMO roles?

5. Can run Exchange Mailflow Troubleshooter via EMC -> Toolbox and choose the appropriate symptom.
0
 
claudiamcseAuthor Commented:
1. Is the Exchange server at your DR site the same name?

YES.

2. When Outlook is opened, does it successfully connect to Exchange in Online or Connected mode?
Yes.

3. What is serving local DNS resolution to the clients at your remote site?
DR DC handles all DNS resolution.

4. On the remote DC, when you open up CMD and type in NETDOM QUERY FSMO, does it report that its holding all FSMO roles?
YES. ALL 5 FSMO roles have been transfered and confirmed at DR DC. We turned off PROD DCs

5. Can run Exchange Mailflow Troubleshooter via EMC -> Toolbox and choose the appropriate symptom.
Didn't show any problems.
0
 
NetfloCommented:
What service pack and rollup is you Exch 2010 box?
0
 
claudiamcseAuthor Commented:
Microsoft Exchange Server  2010 Standard SP1  Version  14.01.0218.015
0
 
claudiamcseAuthor Commented:
Partial solution
0

Featured Post

Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

  • 8
  • 7
Tackle projects and never again get stuck behind a technical roadblock.
Join Now