Outsource MSG, Can I eliminate need for front end exchange server?
I dont currently have a front end server.. however i need to expand and put another exchange heap in a remote office.
this remote office will be a child domain. however it will have the same public namespace for email.
Can i use one of these services, say postini to eliminate this need.
As i understand it you can group users and assing them to different mail servers.?? that is what the front end server does right?
at the same time i would eliminate our main office relaying all the other offfices emails?
Would i still be able to get internal mail to flow between the offices.
Main offfice would be
Domain.com
remote office would be
far.domain.com
both would be setup to recieve mail addressed to @domain.com Postini would route the mail according to the users.
IS this possible? what am i missing? feel free to blow holes in this idea.. but this may be a good way to offset the cost of postini, while reducing my workload if i can avoid another server + exchange licence.
THanks.
this remote office will be a child domain. however it will have the same public namespace for email.
Can i use one of these services, say postini to eliminate this need.
As i understand it you can group users and assing them to different mail servers.?? that is what the front end server does right?
at the same time i would eliminate our main office relaying all the other offfices emails?
Would i still be able to get internal mail to flow between the offices.
Main offfice would be
Domain.com
remote office would be
far.domain.com
both would be setup to recieve mail addressed to @domain.com Postini would route the mail according to the users.
IS this possible? what am i missing? feel free to blow holes in this idea.. but this may be a good way to offset the cost of postini, while reducing my workload if i can avoid another server + exchange licence.
THanks.
ASKER
postini is like megamailserver etc.. they are where you point your mx records. they proxy your mail and will scan it for virus/spam. They are much more efficent at it since its all they do. ( you know how painful it can be updating spam rules all the time)
however, you have to add users email addresses or it will reject them. (no catchall type system) When u add them I am told you can specify mail servers to deliver to. SO in theory i can use the postini smtp servers to direct mail to 2 seperate branches with seperate exchange servers. The only question then is,
will it work like this? can i have two stand alone exchange servers in the same exchange organization routing mail on the same public DNS.
one office will be a child domain if that matters.
Or would i still need a front end server?
however, you have to add users email addresses or it will reject them. (no catchall type system) When u add them I am told you can specify mail servers to deliver to. SO in theory i can use the postini smtp servers to direct mail to 2 seperate branches with seperate exchange servers. The only question then is,
will it work like this? can i have two stand alone exchange servers in the same exchange organization routing mail on the same public DNS.
one office will be a child domain if that matters.
Or would i still need a front end server?
> can i have two stand alone exchange servers...
The question is, how postini is able to route. If you can setup to route a mail to a specific server dependend on their email address, it is not the problem in general, as the frontend server would be the postini server. Now it depends on your AD structure, how to setup exchange. If you have a common AD structure (including AD replication), you can install the two servers into the same exchange organisation. That means, it doesn't matter, which exchange get the mails, as exchange will route them internally. If a user is moving from one to the other office, its not a problem and you have time to change the postini settings. But you may be able to forward the mails to the correct server via postini, to lower server to server traffic. But AD replication needs a line, which is 24h alive and can handle some traffic.
If you have two DCs independend from each other, every exchange server is not knowing, that the other one exists. That means, you can setup them independend from each other with the same mail domain, but this requests, that postini will handle to correct forwarding. If postini send the mail to the wrong server (due to a user move), the mail is bounced back, as one exchange do not know the users of the other server. For this constellation, you do not really need a permanent connection between the offices. This constellation has the lack, that you may have problems to send internal mails from one office to another.
Another option is a splitt email domain, you can setup a secondary email domain (the primary can not be splitted) and advice exchange to forward all unresolved mails to the other server. The precondition for that szenario is, that you have a route beween the servers, so that the one server knows, how to reach the other server without using postini. Also this constellation is in danger of mail loops, as you would have to setup a route in both directions. If somebody would send a mail with an unresolved user to one of the server, the mail will run dead between the server.
To solve the second and third lacks, you can setup to foward the mail to the exchange server, which runs in splittet mode (forwarding all unresolved mail to the second server). The second server then can bounce the mail back to the sender, if no user is available.
Resume:
If you have a common AD with replication and a direct connection between the offices (maybe a VPN tunnel via internet), you install both servers into the same exchange org and postini acts as relay frontend.
If you have two independend AD structures, you can forward all mails from postini to the main office, and all unresolved mails there to the branch office.
The public DNS records doesn't matter as postini is also used for sending out mails. If your exchange server should also send mails (directly), they should have a public registration (two different names of course and reverse record). MX records are only pointing to postini, as this server then knows, what is to do with the mails.
The question is, how postini is able to route. If you can setup to route a mail to a specific server dependend on their email address, it is not the problem in general, as the frontend server would be the postini server. Now it depends on your AD structure, how to setup exchange. If you have a common AD structure (including AD replication), you can install the two servers into the same exchange organisation. That means, it doesn't matter, which exchange get the mails, as exchange will route them internally. If a user is moving from one to the other office, its not a problem and you have time to change the postini settings. But you may be able to forward the mails to the correct server via postini, to lower server to server traffic. But AD replication needs a line, which is 24h alive and can handle some traffic.
If you have two DCs independend from each other, every exchange server is not knowing, that the other one exists. That means, you can setup them independend from each other with the same mail domain, but this requests, that postini will handle to correct forwarding. If postini send the mail to the wrong server (due to a user move), the mail is bounced back, as one exchange do not know the users of the other server. For this constellation, you do not really need a permanent connection between the offices. This constellation has the lack, that you may have problems to send internal mails from one office to another.
Another option is a splitt email domain, you can setup a secondary email domain (the primary can not be splitted) and advice exchange to forward all unresolved mails to the other server. The precondition for that szenario is, that you have a route beween the servers, so that the one server knows, how to reach the other server without using postini. Also this constellation is in danger of mail loops, as you would have to setup a route in both directions. If somebody would send a mail with an unresolved user to one of the server, the mail will run dead between the server.
To solve the second and third lacks, you can setup to foward the mail to the exchange server, which runs in splittet mode (forwarding all unresolved mail to the second server). The second server then can bounce the mail back to the sender, if no user is available.
Resume:
If you have a common AD with replication and a direct connection between the offices (maybe a VPN tunnel via internet), you install both servers into the same exchange org and postini acts as relay frontend.
If you have two independend AD structures, you can forward all mails from postini to the main office, and all unresolved mails there to the branch office.
The public DNS records doesn't matter as postini is also used for sending out mails. If your exchange server should also send mails (directly), they should have a public registration (two different names of course and reverse record). MX records are only pointing to postini, as this server then knows, what is to do with the mails.
ASKER
In the senerio I want.
-I will NOT Have a front end server.
-I will have a direct VPN between the offices
-my office ( domain.com ) will ber the forest root for the remote site ( child.domain.com ) so that involves a common AD with replication as i understand?
Senerio one:
fatguy@aol.com sends an email to skinnyguy@MY_public_domain
Postini gets the msg, and says ok this user is part of group B I send it to mail.child.domain.com.
THen mail.child.domain.com gets it from postini, and places it in skinnyguys's mailbox.
senerio two:
skinnyguy at our remote office sends an email to slacker@ main office. he presses send.
what does his exchange server do? does it say, this goes to a mailbox i know about on a seperate server via VPN?
or does it send it to postini?
i only ever had a single stand alone exchange heap.
-I will NOT Have a front end server.
-I will have a direct VPN between the offices
-my office ( domain.com ) will ber the forest root for the remote site ( child.domain.com ) so that involves a common AD with replication as i understand?
Senerio one:
fatguy@aol.com sends an email to skinnyguy@MY_public_domain
Postini gets the msg, and says ok this user is part of group B I send it to mail.child.domain.com.
THen mail.child.domain.com gets it from postini, and places it in skinnyguys's mailbox.
senerio two:
skinnyguy at our remote office sends an email to slacker@ main office. he presses send.
what does his exchange server do? does it say, this goes to a mailbox i know about on a seperate server via VPN?
or does it send it to postini?
i only ever had a single stand alone exchange heap.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I totally agree.. i am new to child domains too. playing with in in my virtual envrironment.
Reason is, i want to be able to give a local guy at the remote office that is semi-trained in windows 2003 full domain admin.
Otherwise he is not auto admin of local XP machines (default is add domain admins to administrators group when u join a domain)
and he cant do some other tasks easily. HOwever I want to kee my main domain here locked down for just me so I dont ahve to worry about
someone else messing something up. Seems like only things delegation wizzard allows is all Active direcotry stuff. (allow users to change pasword, allow user to add users) etc etc..
SO i am hesitant to make it a new ou in my domain.
Am i missing something?
And you already got the points as the last answer is what I needed. I will be setting up postini as my smarthost.. so they will send all mail too.
This way i can tell my firewall to only allow email from WAN to LAN via port 25 from the postini IP addresses! one less hole to worry about.
Thanks for all your help!
Reason is, i want to be able to give a local guy at the remote office that is semi-trained in windows 2003 full domain admin.
Otherwise he is not auto admin of local XP machines (default is add domain admins to administrators group when u join a domain)
and he cant do some other tasks easily. HOwever I want to kee my main domain here locked down for just me so I dont ahve to worry about
someone else messing something up. Seems like only things delegation wizzard allows is all Active direcotry stuff. (allow users to change pasword, allow user to add users) etc etc..
SO i am hesitant to make it a new ou in my domain.
Am i missing something?
And you already got the points as the last answer is what I needed. I will be setting up postini as my smarthost.. so they will send all mail too.
This way i can tell my firewall to only allow email from WAN to LAN via port 25 from the postini IP addresses! one less hole to worry about.
Thanks for all your help!
ASKER
oh,
and will i need a new routing group for this? I never used anything but default routing groups and setup a single SMTP connector.
and will i need a new routing group for this? I never used anything but default routing groups and setup a single SMTP connector.
OK, sub delegation for a (sub-) domain account may be a reason. If your branch office is not so large, you can also think about to create a "OU-Admin" grroup, then delegate the AD, but you would have to add then this group to th local admin group on the machines as well. A sub-domain can handle it by the default domain / org admin.
> I will be setting up postini as my smarthost...
Goto ESM and setup a SMTP connector (connectors folder), there you can setup the smarthost address or [iP-Address] in brackets, your Virtual SMTP Server as Bridge-haed and a "*" as address space. Internal mail should not go via the smarthost. If you need an authentication for postini (I assume that), you can go to the "enhanced" tab of the connector, select "Not to use ETRN/TURN" - select "outgoing security" button, set the user credentials there you have got from postini and thats it.
> I will be setting up postini as my smarthost...
Goto ESM and setup a SMTP connector (connectors folder), there you can setup the smarthost address or [iP-Address] in brackets, your Virtual SMTP Server as Bridge-haed and a "*" as address space. Internal mail should not go via the smarthost. If you need an authentication for postini (I assume that), you can go to the "enhanced" tab of the connector, select "Not to use ETRN/TURN" - select "outgoing security" button, set the user credentials there you have got from postini and thats it.
ASKER
Perfect.
Thanks a bunch.
Thanks a bunch.
What does postini do, just a mailbox provider or an exchange host service?
> As i understand it you can group users and assing them to different mail servers.?? that is what the front end server does right?
A front end server is usually a common gateway to several backend servers. The backend servers are hosting the mailboxes. The frontend server get the mails and delivers them to the correct backend servers. A typical frontend / backend constellation has one frontend server and at least two backends, or you use a frontend server for filtering and virus detection (what is then more a relay).
> Would i still be able to get internal mail.
For exchange, there is no need to splitt the domains. You can host mails for the same domain on different servers, as long as they are within the same organisation. The mail flow is handled internally. Also you can setup both servers to receive mails for both domains. Mail domains need not to have something to do with computer domains (nevertheless they are usually the same).
The question is more a routing and connection issue as I can see and maybe a question of the general infrastructure, means, how the branch office is connected to your head office. This affects the general setup of your exchange and also your AD topologie.
So, if you have a fast connection between the offices, which allow AD replication, you can setup a DC and an exchange server on each office, as they where located at the same office. You can connect the offices via a leased line or via a VPN tunnel.
If your connection is slow or not stable, it may be better to splitt it up into two independent infrastructures, but this makes the setup to handle the same email domain more complicate.