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

x
?
Solved

Slow propagation between front-end & back-end Exchange

Posted on 2007-10-10
30
Medium Priority
?
426 Views
Last Modified: 2010-04-21
We have the following set up:

Front End Exchange server (2003) that is on our DMZ, being NAT'ed from the public IP.  We then have our back-end Exchange server.  They are both fairly beefy boxes on a gigabit network.  

The problem I am having is not that OWA is slow or even RPC over HTTP...the problem is with changes propagating between the two.  Examples

1) Someone changes their network password - the change takes effect immediately for inside usage...however, for OWA & anything else on the front-end Exchange server (ie - Exchange ActiveSync), it takes several hours (sometimes up to 8)

2) We create a new user & within 2 minutes, their email-addresses are created depending on which Recipient Policy applies to them.  If I send the mail from the inside, it works fine...however, if I send them an email from an outside source, it gets to the front-end server (which is our gateway) & gets rejected since it is an un-routeable address (not found in the recipient policy?).  If I wait a day or so, it works.

3) Same general scenario, but if I add another email alias for someone (ie....first.last@domain in addition to f.last@bioness.com), it takes several hours before thos emails are accepted by the gateway.

Please, this cannot be normal.  Let me know what I can do to diagnose the issues.

Thanks!

These are just some examples of slowness going through.  Does anyone have any ideas?
0
Comment
Question by:rustyrpage
  • 16
  • 11
  • 3
30 Comments
 
LVL 39

Expert Comment

by:redseatechnologies
ID: 20053345
*shudder*

Exchange servers should not be in the DMZ.  I am not surprised you are having problems really, and I would be scheduling time right now to bring that server back on the right side of the router, preferably with a format/rebuild in there as well.

-red
0
 
LVL 6

Author Comment

by:rustyrpage
ID: 20053366
Sorry to nit-pick, but it's not a problem with the way we have it setup.  We have the server in the private DMZ which is still secured.  Basically we have it NAT'ting from the public IP address to the private IP of the front-end Exchange...then we just open up the ports that are needed to communicate between the two.

There isn't any other way to do it & still have it accessible to the outside world (which is the point of a front-end Exchange server)
0
 
LVL 39

Expert Comment

by:redseatechnologies
ID: 20053379
nitpick all you like, the fact is, secure or not, the way you are doing it is against best practices, not a good idea, and probably the cause of your problems

And the point of a front end server isn't to have outside access to the world, it is to have a single point between multiple back end servers.

If you only have 1 backend server, I wonder why you have a front end at all.

Feel free to tell me to go away, but I am not going to treat the symptoms of a problem caused by a poor deployment (that is not a criticism on you, i know a lot of places that have deployed exchange like this, based on outdated information).  It just makes far much more sense to me to configure things properly.

-red
0
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
LVL 6

Author Comment

by:rustyrpage
ID: 20053400
So...figure me this...how would you do the following:

1) Setup Exchange ActiveSync on mobile devices
2) Setup RPC over HTTP
3) Have OWA on a public computer
4) Have POP3 & SMTP clients
0
 
LVL 39

Expert Comment

by:redseatechnologies
ID: 20053426
1,2,3) have TCP port 443 open to the server (or an ISA frontend if you REALLY want)

4) not have them.  RPC/HTTP should mean you don't need it.  But, for the sake of fun and games, lets say you do - just redirect TCP port 110, and you have pop3.

TCP 25 should obviously be redirected to the server as well, to allow inbound mail (which will also allow your pop3 users to relay).

The whole point is, with all the swiss cheesing you will need to do with port rules between the dmz front end and the backend, you may as well have it all on the inside of the network - it is actually MORE secure, as you no longer have a domain member "out in the cold"

-red
0
 
LVL 6

Author Comment

by:rustyrpage
ID: 20053431
Add to that list (sorry forgot):

5) Receiving emails (ie pointing our MX records to that mail processing server (after they have been cleansed by MX Logic))
6) SMTP Connector for sending messages out of our Exchange server (since in order to avoid being marked as SPAM, the SMTP server has to be a resolvable (and cannot be our internal Exchange server).

I'm not trying to be a pain, but just want to see how you would accomplish that.

That said, I don't think that is the issue since we keep a very close eye on all the servers & they are not hacked.  If anything, I'm thinking that maybe the issue is that we do not have enough ports open & are not passing that info.

Thanks for your help!
0
 
LVL 39

Expert Comment

by:redseatechnologies
ID: 20053491
>>I'm not trying to be a pain, but just want to see how you would accomplish that.

No problems at all, I want you to understand why I am saying not to have a server in the DMZ.

5) with TCP 25 redirected to the backend, it will come through without a problem.

6) with TCP 25 redirected to the backend, it will be a "real" server - as long as it has a correct greeting, and accepts port 25 requests, it is real.

>>If anything, I'm thinking that maybe the issue is that we do not have enough ports open & are not passing that info

You are probably right, but that is just a symptom, not the problem.
0
 
LVL 6

Author Comment

by:rustyrpage
ID: 20053499
Well that said, that is how we have it set up...I guess I just used the term DMZ wrong...we have two DMZ's...one is a public (no firewall protection & wide-open), then we have our private DMZ, which is not fully accessible from our inside network, but still behind our firewall & only certain ports are NAT'ted (the ones mentioned above).  Everything is in stealth mode & it is being secured by a Cisco ASA device.

Does that sound more reasonable?

That said, we still have the problem that I originally asked about.
0
 
LVL 6

Author Comment

by:rustyrpage
ID: 20053508
Yeah, so basically our idea is to keep the back-end completely blocked from ANY outside ports & have the front-end be the only one with any externally accessible ports...(to do the above tasks)

The main idea was that we do not want the front-end server on the inside of our network either since we don't want everyone to be able to use it for their SMTP server inside our office (to bypass our security we have for outbound tracking/disclaimers etc)
0
 
LVL 39

Expert Comment

by:redseatechnologies
ID: 20053520
I don't see the point of having the back end blocked - if anything gets to the front end, it can easily traverse the open ports to the backend.  All you have done is complicated your deployment.

>>The main idea was that we do not want the front-end server on the inside of our network either since we don't want everyone to be able to use it for their SMTP server inside our office (to bypass our security we have for outbound tracking/disclaimers etc)

That is the main idea?  That is EASILY resolved - just deny those servers, ips, users, whatever to the SMTP server - outlook will still send mail, but nothing else.

Why do you not open up all the ports between the backend and front end?  And if you are willing to do that, why do you not just move it all inside? :)

These are the ports that Exchange uses - > http://www.petri.co.il/ports_used_by_exchange.htm

The thing is, if you open them all up, you may as well be wide open (and therefor not have anything in between)
0
 
LVL 6

Author Comment

by:rustyrpage
ID: 20053531
Well, the good news is that I am going to be deploying a new Front End Exchange (as a secondary) this next week.  I will do it on the inside with it fully open to the inside world, but only the ports needed to do the 7 things listed above open to the public world.  

That said, I still need to figure out why my propagation is so stinkin' slow.

(although my set up is not the easiest, it came built that way when I got the job & I feel it's secure enough & run under the "why touch it if it's working & not insecure".
0
 
LVL 39

Expert Comment

by:redseatechnologies
ID: 20053551
>>why touch it if it's working & not insecure".

ahhhh, but it ISNT working, is it? :)

I gave you a list of ports above, open those from the dmz to the back end - there isn't much else you can do, besides move the FE server.
0
 
LVL 6

Author Comment

by:rustyrpage
ID: 20053571
I am also wondering if it is a DNS issue or something else...are there any other ways to troubleshoot?  I cannot imagine I am the first one to have this problem.
0
 
LVL 39

Expert Comment

by:redseatechnologies
ID: 20053718
I doubt you are the first one to have this problem as well, but as I already pointed out, this is an unsupported configuration - as such, troubleshooting it is not recommended, you are supposed to reconfigure.

I have given you the ports - check to see they are open.  If you do not want to move the server back where it should be, then at least open a full rule from the FE to the internal LAN.

-red
0
 
LVL 39

Expert Comment

by:redseatechnologies
ID: 20053721
disclaimer;

An open rule from the DMZ to the lan is a stupid idea
0
 
LVL 6

Author Comment

by:rustyrpage
ID: 20053752
So there's not like a "sync settings every X minutes" or something like that we're missing?

I doubt that everyone with this config has the same problem.  (especially since this is pretty much the same configuration as your "best practice" since it is the same level of "openess" to the public internet).

If you don't know of anything else to try, I'll leave the ? for someone else who may have some ideas.
0
 
LVL 39

Expert Comment

by:redseatechnologies
ID: 20053774
(especially since this is pretty much the same configuration as your "best practice" since it is the same level of "openess" to the public internet).


Huh?  It is totally different.  Best practice is to not have anything between servers.  Just because you only have limited ports open to the world doesn't have anything to do with the problem - or make it a best practice.

I have already told you some things to try - move the exchange server inside, or open up the firewall.  If you would rather wait for a band-aid solution, be my guest.

I honestly do wish you the best of luck with this - but seriously, you should be configuring things correctly, for your own benefit if nothing else.

-red
0
 
LVL 6

Author Comment

by:rustyrpage
ID: 20053786
The way I see it...if it were the way it is set up...it would either work or it wouldn't.  (ie if a port were closed).  So thank you for your best practice advise, which is going to be done on the next server...however, in the meantime, I need an expert's advise on why this is slow now.  

Also, remember that the overall email performance is extremely fast on the front end (ie, the emails that are relayed through there & OWA & RPC over HTTPS).  The only slowness is changes that are made to active-directory that do not inherit very quickly.  That points more to a timing configuration or DNS issue & that's what I am asking advice for.
0
 
LVL 6

Author Comment

by:rustyrpage
ID: 20053813
I think to test we will open up all traffic between just our front-end server & the inside network (basically adding it to the internal network without having to reconfigure a bunch of stuff for now) & then just ensure that the only open public ports are SSL ones needed for functioning.  That will at least tell us if the slowness is port related.

Obviously when I build the new box it will have all of the optimal settings.
0
 
LVL 39

Expert Comment

by:redseatechnologies
ID: 20053840
>>That points more to a timing configuration or DNS issue & that's what I am asking advice for.

I disagree - I think that points to a problem with your front end accessing the DCs.

>>I think to test we will open up all traffic between just our front-end server & the inside network

Gee, I wish I had suggested that 4 posts ago :))
0
 
LVL 6

Author Comment

by:rustyrpage
ID: 20053873
What I am looking for you just said....maybe it is a communication issue between the front end & DC.

Granted, that doesn't explain why it does work eventually.
0
 
LVL 39

Expert Comment

by:redseatechnologies
ID: 20053908
I don't know why it will work eventually, but I know that RPC/HTTP will still work with a failing directory lookup (albeit, slowly).  Not the best comparison, but an example of where DC lookups take their sweet time.

Sit tight, I don't doubt that someone else will be along soon
0
 
LVL 6

Author Comment

by:rustyrpage
ID: 20053917
I think it is an LDAP issue...I'll experiment & let you know
0
 
LVL 104

Expert Comment

by:Sembee
ID: 20054983
There is no "sync" between Exchange and active directory when changes are made. All lookups are live. Therefore the only delay would be in replication between your domain controllers, as Exchange servers tend to lock on to one specific DC/GC and if the user has changed their password on another DC a delay can indicate replication issues.

I echo what has been said above. Frontend servers are not for security. They cannot be locked down in any way, because they are full Exchange servers. They are proxy to the backend and are designed for load and single point of entry. If you want something to go in between Exchange and the internet then you should be using an ISA - that is designed to go in to a DMZ or similar network and doesn't have to be a member of the domain to work.
The key problem with Exchange in a DMZ is the fact that it is a member of the domain. Therefore as well as communication with the backend Exchange servers it needs to communicate with the domain controllers. That usually means port 135 being open on a firewall which any network security person will go ballistic over.

Simon.

--
If your question has been answered, pleased remember to accept the answer and close the question.
0
 
LVL 6

Author Comment

by:rustyrpage
ID: 20057743
I understand that.  That said, we do not have port 135 open on the public internet.

Now, back to the question at hand.  I created a new user yesterday with her email addresses & if I look at the email address section in AD I can see all of the correct recipient policies have been applied.  However, when I try to send a test message, I get a PERM_FAILURE: SMTP Error (state 13): 550 Unrouteable address bounce-back from my front-end server.  

On my front-end server, if I look at the recipient policies from there, everything is correct...so it has all of the information.  What else could it be?

The reason that this is just now becoming an issue is because before yesterday we ran all of our email through a Linux processing box & then forwarded it directly to our Exchange server...so it worked fine doing that.

Can anyone please help with that specific problem, short of telling me to rebuild my whole network, which is not going to happen right now as I am getting ready to replace the front-end server.
0
 
LVL 6

Author Comment

by:rustyrpage
ID: 20058617
Okay, I figured out why it isn't working with the new user...now I just don't know how to fix it:

I send a message, it goes to MX Logic to be processed, which then passes the messages to my front-end Exchange server.  Instead of my FE Exchange server passing it to my back-end Exchange server, it is passing it on to the Linux Mail Processing server which we want to eliminate.  The reason why these were bouncing is because on the Linux Mail Processing server, that alias was not set up & for security, it is blocking the message.

Can anyone tell me how my FE server is sending messages to the Linux box instead of BE Exchange?

Thanks for your help
0
 
LVL 104

Expert Comment

by:Sembee
ID: 20060050
The only reasons I can think of it sending to another machine would be a smart host configured on the SMTP virtual server, a DNS error returning the wrong machine name or something is intercepting the SMTP traffic and redirecting it to another machine.

Simon.

--
If your question has been answered, pleased remember to accept the answer and close the question.
0
 
LVL 6

Author Comment

by:rustyrpage
ID: 20060107
The smart host is set up in Exchange to use the Linux.  That being said, when I change it to our front-end exchange server, we get a bounce-back on all sent messages saying:

A configuration error in the e-mail system caused the message to bounce between two servers or to be forwarded between two recipients.  Contact your administrator.

How can we have all of our messages come into the BE Exchange server from the FE, while still having all of our messages that are sent go out the FE (the BE is not rDNS'able)
0
 
LVL 104

Accepted Solution

by:
Sembee earned 2000 total points
ID: 20060442
You have to remove the smart host from all SMTP virtual servers. Both the backend and the frontend.
Once you have removed that you can then configure an SMTP connector with the frontend only set as the Bridgehead. That will result in the backend server sending email to the frontend server for delivery. Smart hosts on the SMTP virtual server interfere with that process - which is why they have to be removed.

Simon.

--
If your question has been answered, pleased remember to accept the answer and close the question.
0
 
LVL 6

Author Closing Comment

by:rustyrpage
ID: 31408121
Sorry, I got side-tracked, this is definetely the solution that I was looking for, then I was able to set a smart-hose of MXLogic (our email security provider) & it goes from our back-end to front-end to them.  Our average in & out speeds are 1-5 seconds now!

Thanks a lot!
0

Featured Post

Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

Question has a verified solution.

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

The main intent of this article is to make you aware of ‘Exchange fail to mount’ error, its effects, causes, and solution.
Here in this article, you will get a step by step guidance on how to restore an Exchange database to a recovery database. Get a brief on Recovery Database and how it can be used to restore Exchange database in this section!
In this video we show how to create a mailbox database 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 Servers >> Data…
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 Month20 days, 10 hours left to enroll

868 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