0

I have a client that is using Exchange 2003 on SBS 2003 R2, but only for calendar sharing and contacts sharing. Their email is still coming to their clients via a POP3 account on each client's Outlook.

I'd like to move them over to using Exchange for both email and the other things they are utilizing it for now. Can you folks guide me in the right direction?

The setup:

  • external domain is akin to domain.com (and is where they get their POP3 email from now)
  • internal domain is akin to domain.local
  • only simple hardware firewall (no ISA)
  • static external IP is available to use

My "assumptions":

  1. Setup SMTP default connector in Exchange for their existing external domain
  2. Have their existing email backed up to PST files (just in case)
  3. Setup the new MX records to point domain.com to the static external IP

I'm a little confused how I'm going to setup their existing Exchange accounts with the proper SMTP address though. Right now it is just user@domain.local. Do I just need to modify or create a new recipient policy?

Are there other steps involved that I'm missing? Anyone with a walkthrough or even a basic "steps" is fine. I'm fairly used to Exchange 03, but I've been on Exchange 07 for a while now so going back is the weird part...plus I don't know what issues Exchange 03 on SBS has versus the normal "version".

Thanks for all the help!

1

It sounds like you just want to get them off of POP3 and get their email flowing straight into Exchange via SMTP. That can be really, really simple, or it can be somewhat complicated, depending on a couple of factors. (You can "gateway" POP3 into Exchange directly via a "POP connector". I highly discouage this, but some people do it. Some people think the earth is flat, too...)

Adding an additional SMTP address and marking it "default" for users is pretty easy. Microsoft goes thru the basics here: http://support.microsoft.com/kb/822447 Based on my perception of your level of Exchange familiarity, throw up a test Active Directory and Exchange installation in a virtual machine to play with before you touch the "real thing". You'll be glad you did. All of this (below) really needs to be familiar to you if you're going to be sure that you don't accidently route the Customer's email to "nowhere". If you're not familiar enough to pull it off with confidence consider hiring somebody who can.

Readi up on how DNS and SMTP interact with each other (ala MX records). There's a decent tutorial here: http://www.sandh.com/support/mx.htm (If I wasn't so tired and didn't need to be at a Customer site in 5 hours I might consider writing one myself... Oh, well...)

You should also look into an email anti-spam / anti-virus solution. If you're not going to run the email through an ISP's mail servers you're going to be receiving all of the spam, viruses, etc yourself. Personally, I'd look at a hosted solution like Google Postini. You can run software on the Customer's server, too. Some people like that. Personally, I don't. I'd rather have somebody like Google maintain that part of the infrastructure / arms race.

You need to be sure that the Customer's firewall will support forwarding TCP port 25 from the Internet into the Exchange Server computer, and that the ISP will allow incoming traffic on port 25. This is a matter for you and their firewall to address. From a computer elsewhere on the Internet you should be able to TELNET to the Customer's public IP address, port 25, and see an SMTP banner. If you don't incoming email isn't going to-- erm-- come in.

You need an "A" record in the Customer's DNS that refers to the public IP addres where the Exchange SMTP server is being exposed to the Internet on TCP port 25. You'll have to work this out with whoever is hosting their DNS.

The Customer is probably already sending outbound email from Exchange, but if they aren't, you should be sure that the ISP will allow if. If they won't, consider smart-hosting the outbound email either through the ISP or through a third-party smart hosting service (like DynDns.org "Mailhop Relay").

Once you have all that working you're ready to do some testing of inbound email and, ultimately, "throw the switch" and update the Customer's MX record (you'll understand what this means when you're ready, and if you don't then DON'T DO IT). Before you go off and update MX records for the Customer's domain be sure that the email anti-virus / anti-spam, A record for the SMTP server in DNS, TCP port forwarding for inbond SMTP is working, and outbound SMTP is working.

BTW: You don't need to "backup" their mail into PST files for this "migration", or at any other time. In fact, you shouldn't be using PST files for anything. You do need to be sure that Exchange is being backed-up regularly using an online backup method (see http://technet.microsoft.com/en-us/library/aa997165(EXCHG.65).aspx).

  • @Evan - thanks. I'm familiar with all of what you said...but haven't ever had to work with a .local domain before. It seems from the KB article that the default policy will still set the SMTP address to domain.com instead of domain.local. Correct? That was really my foggiest part (and yes, I like many, didn't bother yet with a "test environment" first. :) – TheCleaner Sep 10 '09 at 17:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.