Solved

Configuring Additional Exchange 2010 in a Different AD Site

Posted on 2011-02-22
38
1,546 Views
Last Modified: 2012-05-11
Current Environment:
1 Domain - domain.com
2 AD Sites - A(192.168.0.0) & B(167.141.88.0)
1 Exchange 2010 Std SP1 with CAS and HUB (servername vowvh02)
1 Exchange 2010 Std SP1 with MB (servername vowvh005)
both vowvh002 and vowvh005 are located in AD site A
Autodiscover, OWA, activesync, etc are configured on vowvh002, and I would like it to remain the same.
Now, I have just installed an Exchange 2010 Std SP1 with CAS, HUB and MB in AD site B - servername is vowpd002.  All of the users' mailboxes in this AD site B is currently still in the vowvh005 server.  I would like to eventually move these users to this new Exchange server, vowpd002.  Before doing that, though, I would like to configure this new Exchange server to send/receive all external emails through the existing CAS/HUB server - vowvh002.  (I am assuming that internal emails should be processed automatically and no configuration is necessary, correct?) Similar to how Exchange 2003 used to be with Front End and Back End server.  I think in Exchange 2010 they call it Proxying and/or Redirection.  So basically, the only reason for this new Exchange 2010 server, vowpd002, is to store mailboxes of those users located in that particular AD site, which will improve Outlook email access performance due to WAN point to point limitation (T1), as well as conserving space on the existing MB server.  Would someone please point me to the right direction on this?

Thanks,
0
Comment
Question by:Wilmette
  • 23
  • 15
38 Comments
 
LVL 12

Expert Comment

by:Nenadic
ID: 34951730
Below are the various items you need to consider:

1. Email Routing

Email will be routed based on Send Connectors you have configured.  If the current email works correctly, installation of Hub Server components on the new server in another site will refer to that Send Connector automatically and the email will be routed exactly as you expect.

2. OWA/ECP/EAS/EWS Proxying

Since you don't have Internet access to Site B, the default installation will again accomplish exactly what you want, as long as your current configuration works correctly. Basically, the new server will install with only the Internal URLs defined for various services. That means that the CAS in Site A will proxy all external requests to the Internal URL - defined with the internal FQDN of the new server. All you need to ensure is that the Authentication method on each of these virtual directories is set to Integrated Windows.
0
 

Author Comment

by:Wilmette
ID: 34951939
Nenadic:  Thanks for the respond.  REgarding the authentication method for all fo the virtual directories, where do I go to check if it is indeed Windows Integrated?  Web Server (IIS) or within EMC?  Also, do I have to do anything with certificate?  The previous CAS/HUB has an existing UCC certificate that is working perfectly fine.  Since this is not Internet-facing, I would assume no certificate is required, correct?

Thanks
0
 
LVL 12

Expert Comment

by:Nenadic
ID: 34952033
Wilmette, you are right about the Certificate. As long as it works correctly now, the new server will be proxied to, so users won't see a change.

Run the following:

Get-OwaVirtualDirectory vowpd002\* | select server,internalurl,externalurl,internalauth*,formsauth*,basicauth*,windowsauth*
Get-OABVirtualDirectory vowpd002\* | select server,internalurl,externalurl,internalauth*,basicauth*,windowsauth*
Get-ECPVirtualDirectory vowpd002\* | select server,internalurl,externalurl,internalauth*,formsauth*,basicauth*,windowsauth*
Get-WebServicesVirtualDirectory vowpd002\* | select server,internalurl,internalnlb*,externalurl,internalauth*,basicauth*,windowsauth*

Get-AutodiscoverVirtualDirectory *\* | select server,internalauth*,basicauth*,windowsauth* | ft -a
0
 

Author Comment

by:Wilmette
ID: 34952296
Here's what I got:

[PS] C:\Windows\system32>Get-OwaVirtualDirectory vowpd002\* | select server,internalurl,externalurl,internalauth*,formsa
uth*,basicauth*,windowsauth*


Server                        : VOWPD002
InternalUrl                   : https://vowpd002.wilmette.com/owa
ExternalUrl                   :
InternalAuthenticationMethods : {Basic, Fba}
FormsAuthentication           : True
BasicAuthentication           : True
WindowsAuthentication         : False



[PS] C:\Windows\system32>Get-OABVirtualDirectory vowpd002\* | select server,internalurl,externalurl,internalauth*,basica
uth*,windowsauth*


Server                        : VOWPD002
InternalUrl                   : http://vowpd002.wilmette.com/OAB
ExternalUrl                   :
InternalAuthenticationMethods : {WindowsIntegrated}
BasicAuthentication           : False
WindowsAuthentication         : True



[PS] C:\Windows\system32>Get-ECPVirtualDirectory vowpd002\* | select server,internalurl,externalurl,internalauth*,formsa
uth*,basicauth*,windowsauth*


Server                        : VOWPD002
InternalUrl                   : https://vowpd002.wilmette.com/ecp
ExternalUrl                   :
InternalAuthenticationMethods : {Basic, Fba}
FormsAuthentication           : True
BasicAuthentication           : True
WindowsAuthentication         : False



[PS] C:\Windows\system32>Get-WebServicesVirtualDirectory vowpd002\* | select server,internalurl,internalnlb*,externalurl
,internalauth*,basicauth*,windowsauth*


Server                        : VOWPD002
InternalUrl                   : https://vowpd002.wilmette.com/EWS/Exchange.asmx
InternalNLBBypassUrl          : https://vowpd002.wilmette.com/ews/exchange.asmx
ExternalUrl                   :
InternalAuthenticationMethods : {Ntlm, WindowsIntegrated, WSSecurity}
BasicAuthentication           : False
WindowsAuthentication         : True



[PS] C:\Windows\system32>Get-AutodiscoverVirtualDirectory *\* | select server,internalauth*,basicauth*,windowsauth* | ft
 -a

Server   InternalAuthenticationMethods                BasicAuthentication WindowsAuthentication
------   -----------------------------                ------------------- ---------------------
VOWVH002 {Basic, Ntlm, WindowsIntegrated, WSSecurity}                True                  True
VOWPD002 {Basic, Ntlm, WindowsIntegrated, WSSecurity}                True                  True
0
 
LVL 12

Expert Comment

by:Nenadic
ID: 34952472
OK, so you need to run the following commands.  They will enable Windows Integrated authentication on OWA and ECP virtual directories, which will allow for seamless proxying from Site A CAS to Site B CAS for both of those types of traffic.

Set-OWAVirtualDirectory vowpd002\* -BasicAuthentication $false -WindowsAuthentication $true -FormsAuthentication $false

Set-ECPVirtualDirectory vowpd002\* -BasicAuthentication $false -WindowsAuthentication $true -FormsAuthentication $false

Once done, could you please rerun the previous commands to obtain the settings again and repost, to confirm the change went through correctly.
0
 

Author Comment

by:Wilmette
ID: 34952536
Nenadic,
Thanks again for your help.  I probably have to wait a bit to run the commands above.  It looks like replication between A and B are not fully complete.  (I created a test user/mailbox on site B, but haven't seen it appear in site A, yet).  Not to mention, I just completed installing this new Exchange server, vowpd002, about 1.5hrs ago.  I will post the result ASAP.

Thanks
0
 
LVL 12

Expert Comment

by:Nenadic
ID: 34952597
Your AD replication would be responsible for when the user appears in EMC on a server in a different AD Site.

One last thing is to reset the IIS when you make the change.  A simple iisreset on the server's Command Prompt will suffice.
0
 

Author Comment

by:Wilmette
ID: 34952960
OK, we're almost there.  Looks like replication is complete.  I ran the commmands you provided, and here are the new results of the original commands you wanted me to run.

[PS] C:\Windows\system32>Get-OwaVirtualDirectory vowpd002\* | select server,internalurl,externalurl,internalauth*,formsa
uth*,basicauth*,windowsauth*
Creating a new session for implicit remoting of "Get-OwaVirtualDirectory" command...


Server                        : VOWPD002
InternalUrl                   : https://vowpd002.wilmette.com/owa
ExternalUrl                   :
InternalAuthenticationMethods : {Ntlm, WindowsIntegrated}
FormsAuthentication           : False
BasicAuthentication           : False
WindowsAuthentication         : True



[PS] C:\Windows\system32>Get-OABVirtualDirectory vowpd002\* | select server,internalurl,externalurl,internalauth*,basica
uth*,windowsauth*


Server                        : VOWPD002
InternalUrl                   : http://vowpd002.wilmette.com/OAB
ExternalUrl                   :
InternalAuthenticationMethods : {WindowsIntegrated}
BasicAuthentication           : False
WindowsAuthentication         : True



[PS] C:\Windows\system32>Get-ECPVirtualDirectory vowpd002\* | select server,internalurl,externalurl,internalauth*,formsa
uth*,basicauth*,windowsauth*


Server                        : VOWPD002
InternalUrl                   : https://vowpd002.wilmette.com/ecp
ExternalUrl                   :
InternalAuthenticationMethods : {Ntlm, WindowsIntegrated}
FormsAuthentication           : False
BasicAuthentication           : False
WindowsAuthentication         : True



[PS] C:\Windows\system32>Get-WebServicesVirtualDirectory vowpd002\* | select server,internalurl,internalnlb*,externalurl
,internalauth*,basicauth*,windowsauth*


Server                        : VOWPD002
InternalUrl                   : https://vowpd002.wilmette.com/EWS/Exchange.asmx
InternalNLBBypassUrl          : https://vowpd002.wilmette.com/ews/exchange.asmx
ExternalUrl                   :
InternalAuthenticationMethods : {Ntlm, WindowsIntegrated, WSSecurity}
BasicAuthentication           : False
WindowsAuthentication         : True



[PS] C:\Windows\system32>
[PS] C:\Windows\system32>Get-AutodiscoverVirtualDirectory *\* | select server,internalauth*,basicauth*,windowsauth* | ft
 -a

Server   InternalAuthenticationMethods                BasicAuthentication WindowsAuthentication
------   -----------------------------                ------------------- ---------------------
VOWVH002 {Basic, Ntlm, WindowsIntegrated, WSSecurity}                True                  True
VOWPD002 {Basic, Ntlm, WindowsIntegrated, WSSecurity}                True                  True


Quick Question:
So, I have created a user/mailbox - Winnie T Pooh - at AD site B and mailbox is located on vowpd002.  It looks like I am able to receive emails OK, whether it's from an external sender or an internal sender.  However, it looks like sending emails to external or internal addresses seems to be a problem.  Here's what I noticed, the Send Connector has the Source Server of vowvh002.  Do I need to add this new vowpd002 server in there as well?

Thanks
0
 
LVL 12

Expert Comment

by:Nenadic
ID: 34953006
All output looks OK.

Yes, you do need to add the source server. I omitted that.  The mail queues should empty up within a few minutes after AD replication updates the local Site GC.
0
 

Author Comment

by:Wilmette
ID: 34955581
OK, this is a bit interesting.  After seeing that the test user that I created appeared at all of my sites, I went ahead and added vowpd002 as the source server.  For a period of about 30 minutes, I noticed that all emails were flowing correctly.  Now, however, it seems like everything is working except external outbound emails from this test account to, for example, Hotmail and Yahoo.  I do see these emails stuck on the vowpd002 queue with a Delivery Type of DNSConnectorDelivery.  When I right-click and click Retry, the connection status turns to Connecting, but eventually stays right where it is.  Any thoughts?  Note:  I have not yet have the opportunity to restart this server, nor any of the other Exchange servers.  Just curious if a restart is necessary?

Thanks
0
 
LVL 12

Expert Comment

by:Nenadic
ID: 34957045
Hmmm, this could point to a wider problem. Are any other emails going out externally? Have emails to Yahoo and Hotmail gone without problems during the first 30 minutes? Finally, what errors do you see?
0
 

Author Comment

by:Wilmette
ID: 34957509
Only emails from this mailbox is having outbound problems.  And that's really the only mail flow problem.  There really is no error, at least I haven't seen anything.  The vowpd002 queue would just have those outbound emails stuck there.  I eventually just cleared it.  I guess I leave a couple until it times out to see what the ndr comes back with.
0
 

Author Comment

by:Wilmette
ID: 34957577
Just looked at the queue a bit closer and here's what I got:
451 4.4.0 Primary target IP address responded with: "421 4.2.1 Unable to Connect." Attempted failover to alternate host, but that did not succeed.  Either there are no alternate hosts, or delivery failed to all alternate hosts.
0
 
LVL 12

Expert Comment

by:Nenadic
ID: 34959673
Hi Wilmette, I feel like I've missed something obvious here, so can I just confirm the structure of the mail routing in your organisation, please...

Site A contains the following:
1 Exchange 2010 Std SP1 with CAS and HUB (servername vowvh02)
1 Exchange 2010 Std SP1 with MB (servername vowvh005)
Site B only contains:
1 Exchange 2010 Std SP1 with MB/HUB/CAS and is called vowpd002.

What is your Internet connectivity like?
Could you please run Get-SendConnector and post results.
0
 

Author Comment

by:Wilmette
ID: 34960675
OK, just got in the office, and I was also thinking that this is one of those easy or obvious error that we might have missed.  So, thinking back, I remembered it was working while vowpd002 wasn't added to the Source Server list in the Send Connector.  So, I decided to remove this server again and leaving only vowvh002, the original server.  And voila - my emails are getting to its destinations.  I have been testing this for the last 15 minutes now and all is well still.  So, that's interesting the only source server that is needed is the Internet-facing or original CAS/HUB server.

Now, let's get to another problem that I noticed - OWA.  Looks like this is not working at all - for all users.  I do get the OWA logon page, but as soon as I enter my User Name and Password and click Sign In, I get the attached error:

HTTP 500 Internal Server Error
The URL on the browser would redirect to https://webmail.domain.com/owa/auth.owa

Any ideas?  Something with rediction maybe?  One other note, email flows are not effected.  Sending and receiving are working normally.  Also, ActiveSync, using the same name - webmail.domain.com - is also working normally.

Thanks
0
 
LVL 12

Expert Comment

by:Nenadic
ID: 34961654
Can you access OWA internally?
0
 

Author Comment

by:Wilmette
ID: 34961703
nope.  Pretty much the same, it woudl get to the logon page, attempt to logon, then goes to the 500 error page.
0
 
LVL 12

Expert Comment

by:Nenadic
ID: 34961743
Can you run these two and let me see the result please:

Get-OwaVirtualDirectory vowpd002\* | select server,internalurl,externalurl,internalauth*,formsauth*,basicauth*,windowsauth*
Get-OwaVirtualDirectory vowvh002\* | select server,internalurl,externalurl,internalauth*,formsauth*,basicauth*,windowsauth*
0
 

Author Comment

by:Wilmette
ID: 34962044
Here's what I got:

[PS] C:\Windows\system32>Get-OwaVirtualDirectory vowpd002\* | select server,internalurl,externalurl,internalauth*,formsa
uth*,basicauth*,windowsauth*


Server                        : VOWPD002
InternalUrl                   : https://vowpd002.wilmette.com/owa
ExternalUrl                   :
InternalAuthenticationMethods : {Ntlm, WindowsIntegrated}
FormsAuthentication           : False
BasicAuthentication           : False
WindowsAuthentication         : True



[PS] C:\Windows\system32>Get-OwaVirtualDirectory vowvh002\* | select server,internalurl,externalurl,internalauth*,formsa
uth*,basicauth*,windowsauth*


Server                        : VOWVH002
InternalUrl                   : https://vowvh002.wilmette.com/owa
ExternalUrl                   : https://webmail.wilmette.com/owa
InternalAuthenticationMethods : {Basic, Fba}
FormsAuthentication           : True
BasicAuthentication           : True
WindowsAuthentication         : False
0
How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

 

Author Comment

by:Wilmette
ID: 34962063
Obviously vowvh002 would have the external url.  It looks like the authentications are different between the two servers.  Also, both CAS servers should be able to differentiate mailbox locations after an OWA request, correct?  
0
 
LVL 12

Expert Comment

by:Nenadic
ID: 34962315
Looking at above, everything looks OK, so we may have to look at Certificates. Before that, let me explain the process:

EXTERNALLY
1. User connects to https://webmail.wilmette.com/owa which is on VOWVH002 CAS.
2. The user is authenticated through forms.
3a. If the mailbox is in Site A, the request is made to the Mailbox server and mailbox is accessed.
3b. If the mailbox is in Site B, VOWVH002 will check for CAS servers in that site and obtain VOWPD002.
4b. Since VOWPD002 hasn't got the External URL set, VOWVH002 will proxy to Internal URL as long as the authentication is set to Windows Integrated.

INTERNALLY
1. User connects to Internal URL and is automatically authenticated based on his/her Windows token.

So, back to the problem.  Are all three URLs resulting in the same error?
Externally:
- https://webmail.wilmette.com/owa
Internally:
- https://vowvh002.wilmette.com/owa
- https://vowpd002.wilmette.com/owa
0
 

Author Comment

by:Wilmette
ID: 34962459
Both of these links came back with the same 500 error:
https://webmail.wilmette.com/owa
https://vowvh002.wilmette.com/owa
But it at least hits the actual OWA logon page.

For https://vowpd002.wilmette.com/owa, it asks for the username and password, but not the normal OWA logon page.  If I enter my username and password, in which my mailbox is is located in vowvh005 (not the new Exchange server), it will just reappear with the logon page.  Basically a loop.  However, if I log on as the test user that I created on AD site A with the mailbox located on this new Exchange server (vowpd002), I can see the Outlook Web App Language and Time Zone page, click OK to proceed, and then I am able to get in to OWA.  Hmmm, that's interesting.  

So, it looks like OWA only works if I go directly to https://vowpd002.wilmette.com/owa using only the user that has the mailbox on that server.  Again, I am thinking this might be another one of those easy redirection problem.

THanks,
0
 

Author Comment

by:Wilmette
ID: 34962774
Correction on the comment above:
The line that says:
However, if I log on as the test user that I created on AD site A with the mailbox located on this new Exchange server (vowpd002), I can see the Outlook Web App Language and Time Zone page, click OK to proceed, and then I am able to get in to OWA.

Should say:
However, if I log on as the test user that I created on AD site B with the mailbox located on this new Exchange server (vowpd002), I can see the Outlook Web App Language and Time Zone page, click OK to proceed, and then I am able to get in to OWA.
0
 

Author Comment

by:Wilmette
ID: 34964137
OK - progress!!!  It looks like Integrated Windows authentication wasn't set up for both CAS servers.  I went into EMC\Server Configuration\Client Access, checked the authentication for Outlook Web App and Exchange Control Panel for both servers are set to Integrated Windows.  Reset IIS on both servers, and was able to log in.  However, because this is now Integrated Windows authentication, a couple of things have changed:
1.  When I go to webmail.wilmette.com, I get the immediate Connect to webmail.wilmette.com logon dialog box (see attachment).  I do not see the normal Outlook Web App logon page anymore, which is OK I guess.
2.  Now when logging on to the box above in step 1, I have to use the format of domain\username as the username (see the same attachment), otherwise I am unable to log on.  This is a potential problem for our users.  Anyway I can change this to just the username not having to preceed it with the domain\?  I guess that's why the original setting was Use forms-based authentication with User name only.  It would be a little learning curve for our users if we can't change this setting, which most of our users will not accept unfortunately.
prt-scrn.doc
0
 

Author Comment

by:Wilmette
ID: 34966160
Another odd behavior I just noticed.  When sending emails from the test mailbox, which is located in AD Site B and mailbox is in vowpd002, the email doesn't reach its destination immediately.  This is the error I get in the Queue Viewer:
451 4.4.0 DNS query failed.  The error was: SMTPSEND.DNS.NonExistentDomain; nonexistent domain
The delivery type is:
SMTP Relay to Remote Active Directory Site
Now, as I said, the email doesn't reach its destination immediately.  As soon as the next try occurs, which is 10 minutes later, the email went through.  Also the second attempt adds in another line in my Queue Viewer:
Next Hop Domain:
vowvh002.wilmette.com
Delivery Type:
Shadow Redundancy
Status:
Ready
Message:
1
Any thoughts?
0
 
LVL 12

Expert Comment

by:Nenadic
ID: 34968751
The second part is clear and by design. Shadow Redundancy is the component that protects your message until it gets delivered to the next hop. For example, in case VOWVH002 fails after receiving the message but before delivering it to the mailbox or to Internet.

First part.  Where are you sending the message to? An Internet-based address, I assume? What are DNS settings on both servers? Do they go to AD-based DNS servers?  How do those servers look up Internet-based addresses?
0
 

Author Comment

by:Wilmette
ID: 34970275
This how I have our DNS set up for both AD sites.
Site A:
servername vowvh004 (headquarter - 192.168.21.34) - DNS/DC/GC/DHCP - DNS server has forwarder addresses of our ISP's (Comcast).  The server itself has itselft as the preferred DNS address and vowpd001 (see below) as the alternate.
Site B:
servername vowpd001 (167.141.88.31) - DNS/GC/DC/DHCP - DNS server has forwarder address pointing to our ISP's DNS address.  This site is directly connected to site B above via T1.  The server itself has itself as the preferred DNS address, and vowvh004 as the alternate.  
On vowpd002, while this problem is still occurring, the dns addresses are:
preferred:  167.141.88.31
alternate:  192.168.21.34

Now, after seeing our last post, I decided to swap the dns entries on this new Exchange server to:
preferred:  192.168.21.34
alternate:  167.141.88.31
I just did another test a few minutes ago, and the external outbound email got to its destination immediately.  I am going to monitor this for a few more hours to see if it's consistently sending the message - immediately.

On a seperate note, any ideas regarding the OWA login where I have to preceed the username with domain\?

Thanks
0
 
LVL 12

Expert Comment

by:Nenadic
ID: 34970363
All problems could be rooted in DNS, so let's ensure that is cleared out first and we'll come back to OWA.

It appears you have problems with VOWPD001's DNS access to your ISP's DNS server. Can you run in Command Prompt:
1. NSLOOKUP - xxx.xxx.xxx.xxx (your ISP's DNS server IP address)
2. set type=mx
3. microsoft.com
Do you get results?

As a separate check, run DCDIAG on VOWPD001 and see if there are any reported errors in the output.

Thanks.
0
 

Author Comment

by:Wilmette
ID: 34970649
Here are the nslookup results:

C:\>nslookup
Default Server:  vowpd001.wilmette.com
Address:  167.141.88.31

> 68.87.72.130
Server:  vowpd001.wilmette.com
Address:  167.141.88.31

Name:    nrcns.area4.il.chicago.comcast.net
Address:  68.87.72.130

> set type=mx
> microsoft.com
Server:  vowpd001.wilmette.com
Address:  167.141.88.31

Non-authoritative answer:
microsoft.com   MX preference = 10, mail exchanger = mail.messaging.microsoft.co
m

mail.messaging.microsoft.com    internet address = 216.32.180.22
>

There is one error with dcdiag:

 Starting test: NCSecDesc
    Error NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS doesn't have
       Replicating Directory Changes In Filtered Set
    access rights for the naming context:
    DC=ForestDnsZones,DC=wilmette,DC=com
    Error NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS doesn't have
       Replicating Directory Changes In Filtered Set
    access rights for the naming context:
    DC=DomainDnsZones,DC=wilmette,DC=com
    ......................... VOWPD001 failed test NCSecDesc
0
 

Author Comment

by:Wilmette
ID: 34970675
Quick question regarding my DNS servers.  Considering that I have multiple DNS servers, wouldn't it be logical to have it set up as such:
-Primary DNS server at headquarter site - forwarder address is ISP's DNS servers
-Any additional DNS servers within our domain should have the forwarder address of the Primary DNS server.
0
 
LVL 12

Expert Comment

by:Nenadic
ID: 34970895
That error from DCDIAG can be ignored.

The answer to your question depends on the type of DNS you use internally.  If you have an Active Directory-integrated zone, your Domain Controllers will replicate the information using AD replication. That way they don't need to forward to one another and you can use the local DC in each Site to provide DNS resolution.

DNS seems OK from VOWPD001 to Internet.  So, that leaves VOWPD002 to VOWPD001. Could you run from VOWPD002:
1. NSLOOKUP - 167.141.88.31
2. set type=mx
3. cnn.com
And see if you can obtain correct information.

Btw, your OWA login screen is as expected.  Only VOWVH002 should have forms based authentication, as it will then proxy requests to VOWPD002.
0
 

Author Comment

by:Wilmette
ID: 34971162
Here's what I got:

C:\>nslookup
Default Server:  vowpd001.wilmette.com
Address:  167.141.88.31

> 167.141.88.31
Server:  vowpd001.wilmette.com
Address:  167.141.88.31

Name:    vowpd001.wilmette.com
Address:  167.141.88.31

> set type=mx
> cnn.com
Server:  vowpd001.wilmette.com
Address:  167.141.88.31

Non-authoritative answer:
cnn.com MX preference = 10, mail exchanger = atlmail5.turner.com
cnn.com MX preference = 10, mail exchanger = atlmail3.turner.com
cnn.com MX preference = 10, mail exchanger = nycmail2.turner.com
cnn.com MX preference = 10, mail exchanger = nycmail1.turner.com
cnn.com MX preference = 10, mail exchanger = lonmail1.turner.com
cnn.com MX preference = 10, mail exchanger = hkgmail1.turner.com

nycmail1.turner.com     internet address = 157.166.157.8
hkgmail1.turner.com     internet address = 168.161.96.115

We are using AD-Integrated for all of our DNS servers.  So, from what you are saying, it sounds like the non-primary DNS server (the ones other than vowvh004) should have Forwarder address of vowvh004/192.168.21.34, instead of the ISP's addresses?
0
 

Author Comment

by:Wilmette
ID: 34973059
OK, I think I noticed a level of consistency with this problem.  Whenever the external outbound email gets send (by clicking the Send button), it will immediately get sent only if the Shadow Redundancy for next hop domain of vowvh002.wilmette.com in the Queue Viewer appears.  Now, when does this Shadow Redundancy appear, I have no idea, but it looks like this is the trigger that allows the mail to get out.  I have tried swapping the order of DNS IP addresses, swapping Forwarder addresses, even removing the ISP's forwarder addressed, but the only consistency I see if this Shadow Redundancy.
0
 
LVL 12

Expert Comment

by:Nenadic
ID: 34974366
Shadow Redundancy is actually just the result of email moving. Once a message has been submitted and passed to the next hop, a copy is stored in Shadow Redundancy queue. So, although it may appear that causes quick delivery, it is actually just a result of successful delivery.

Let's try to recap. Email transfer works well if VOWVH004 is the DNS server, but not when it's VOWPB001?

OWA works OK internally for VOWPB002, but neither internally nor externally for VOWVH002?
0
 

Author Comment

by:Wilmette
ID: 34974795
Owa is working perfectly right now, except it has that irritating logon requirement where wilmette\ needs to preceed the username.  Other than that all is well.  

The other problem really doesn't matter what dns entries are entered.  If shadow redundancy is just a result of the mail being moved, then I can't see anything consistent with this issue.  At least I know emails are going out from the new mb server, just not sure when.  Either dns entries would result in mails going out, but the fact it doesn't consistently go out immediately is the problem.
One thing I just thought of is the firewall outbound rule for smtp traffic.  There is one right now for vowvh002, the 1st cas server, but there isn't one for this new vowpd002 server.  Do you this is needed?  If it is needed, I am curious how emails are going out right now at all?

Thanks
0
 
LVL 12

Expert Comment

by:Nenadic
ID: 34978855
That window should only appear if you use OWA internally. Externally, you shouldn't see it.

VOWVH002 is the only server sending email out to and receiving email from Internet, so no need for other firewall rules to allow SMTP traffic.
0
 

Accepted Solution

by:
Wilmette earned 0 total points
ID: 35016817
OK, I believe the problem has been solved.  Looks like vowpd002, the new Exchange server, has a 3rd DNS IP Address entered.  Even though this address is 3rd on the list, it definitely affected email flow.  So, I removed it out of there, and it has been 3 days, and all email flows are still good.  As for the OWA login problem, I removed Windows Integrated on vowvh002 (the Internet Facing box) and chose the original settings, forms-based with username only, and it looks like the login is back to the way it was.  So, looks like all problems are solved at this point.  Again, I want to thank you - Nenadic - for the help.  And of course EE came through again.

Thanks!!!
0
 

Author Closing Comment

by:Wilmette
ID: 35067646
Figured out that a 3rd DNS address was listed on the server.
0

Featured Post

Free Trending Threat Insights Every Day

Enhance your security with threat intelligence from the web. Get trending threat insights on hackers, exploits, and suspicious IP addresses delivered to your inbox with our free Cyber Daily.

Join & Write a Comment

Utilizing an array to gracefully append to a list of EmailAddresses
Disabling the Directory Sync Service Account in Office 365 will stop directory synchronization from working.
To show how to create a transport rule in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.: First we need to log into the Exchange Admin Center. Navigate to the Mail Flow >> Rules tab.:  To cr…
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…

746 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

Need Help in Real-Time?

Connect with top rated Experts

11 Experts available now in Live!

Get 1:1 Help Now