On Mon, Mar 29, 2010 at 11:50 AM, David W. McSpadden <dav...@imcu.com> wrote:
> I have been given the green light to research bringing all mail in house
> onto the Exchange 2003 server.

  And there was much rejoicing!

> I have a Windows 2003 Active Directory domain.  I have an ASA firewall and
> an Ironport for email.

  IronPort is a mail filtering appliance, right?  What does it do
currently?  What *can* it do?  If it has the features and the load
capacity, I would recommend having all your incoming *and* outgoing
mail go through the IronPort.  That helps you control and monitor mail
you send as well as receive.

> -Globally change the smtp addresses for all users that already have external
> accounts in Exchange to match.

  If you're not already using your Exchange server for other mail, I
would suggest modifying the recipient policy such that it
automatically generates an appropriate SMTP address as the Primary
address.  It generally doesn't hurt anything to have multiple systems
configured to generate mail with your "From" address.

> -Add an mx record to point to an outward facing address such as
> 206.18.123.215
> -Add a dns record for mail.imcu.com or pop.imcu.com and smtp.imcu.com?

  Close but not quite.  MX records take domain names (like
<mail.example.com>) on their RHS (Right Hand Side), not IP addresses.
So generally, you could create DNS records along these lines:

imcu.com.               MX      mail.imcu.com.
mail.imcu.com.          A       206.18.123.215

> -Add a route through the firewall to the ironport and a relay to the
> exchange box. (incoming)

  Pretty much.  In more detail, to receive mail *from* other systems:

  You want the firewall to allow traffic with destination port TCP/25
to the IronPort.

  If your inside network NAT'ed?  If so, you also need the firewall
configured to do
port-forwarding/NAT/PAT/one-to-one-static-NAT/whatever-your-vendor-calls-it
between the public address and the IronPort.

  The IronPort should be configured to accept mail addressed *to* your
domain(s), and to forward that mail to your Exchange server.  You
generally cannot rely on DNS to tell your IronPort this, because DNS
will be telling your IronPort to deliver your mail to itself.

  You want your Exchange server configured to accept mail addressed
*to* your domain(s).  That's done with recipient policies, mentioned
above.

> -Add a smtp route from exchange to the ironport and relay to the internet.
> (outgoing)

  Again, that's the gist of it.  In detail, to send mail *to* other systems:

  You want the firewall configured to allow traffic with destination
port TCP/25 to any outside host, from either the IronPort or the
Exchange server.  (I recommend both even if you decide to have
Exchange relay outgoing mail through the IronPort.  If the IronPort
ever has trouble, you can reconfigure Exchange to bypass and send
direct.)

  You want the IronPort configured to relay mail from the Exchange
server to any outside system.  If you have other hosts which send
mail, add them, too.

  You want the Exchange server configured to relay all outgoing mail
through the IronPort.  This can be done just by designating the
IronPort as the "SMTP smart host".  You don't *need* an SMTP connector
for this.  If you create an SMTP connector (it won't hurt), then
configure it with a mail route to the IronPort, as you say.

  Eventually, you want most computers on your LAN to be denied if they
attempt to relay mail directly through the IronPort.  That would
indicate they are bypassing Exchange, which most of the time will be a
rogue system set-up without IT department knowledge, or a computer
compromised by malware to be a spam zombie.

> -Import all Outlook Express mail into Exchange and the delete all mail from
> the outlook express clients and remove the mailboxes from there.

  You may want to do the migration in stages.

  First, get the Exchange server configured to *send* mail.  You can
test that yourself by creating test accounts, logging in to other
users' PCs, etc.  Exchange won't know about any of the other mail
going on, but you can make sure it can send.

  Once you're sure that's working, migrate people from Outlook
Express/Win Mail/etc. to Outlook proper, but still configured to POP
mail from your current mail host.  That changes the client software,
and the mail storage and sending, but keeps mail coming in the old
way.  The advantage here is that you can back out an individual
client, or put the whole project on hold, without really disrupting
anything.  Since this is the big change in user experience, that's a
good place to have flexibility.

  Once everybody is storing all their mail on Exchange, and sending
via Exchange, cut over the MX.  Now mail delivery will be via Exchange
instead of POP, but otherwise, things will work about the same as
before.  The POP clients will continue to POP, they just won't find
mail to POP.

  Once you're satisfied the MX cut-over worked, deactivate the POP
client on everybody's PC.  Then cancel off-site mailbox hosting.

  It's more work and more time to do it in stages, but it gives you
more places to stop and catch your breath, or even to temporarily
abort and roll-back if needed.

> -Add a spf record to the 206.18.123.215.

  Yup.  There are other ways (like the "mx" SPF directive), but during
a transition like this it's best to be explict.

> I know I am missing a lot and I need to verify that the mail that was going
> to the mailanyone and still be retrieved until we are sure all the mailboxes
> and distribution lists are working???

  If you're not already hosting mail on the IronPort or Exchange, then
you can test your set-up just by sending mail directly to the IP
address you configured for this.

  If mail is already going through the IronPort, see if it can support
some kind of "virtual hosting" by IP address, and configure a new
"virtual host" for your new setup.

> Sidenote my OWA stopped working a while back.  Nobody used it but me but if
> we go to this I will need to have it up and running.  Where do I look to
> find out why it has stopped.

  Start by checking services (IIS *and* Exchange), make sure they're
running.  Then check Event Viewer.  If needed, turn up diagnostic
logging for the server in Exchange.

-- Ben


Reply via email to