Private Domain Name #1 (.local) vs Public Domain Name #2 (.com)

Greetings,

I have an intersting issue that I've inherited from my company's original
SBS 2003 setup & configuration and would love some outside input for possible
solutions.

SBS 2003 Sp1 was originally setup without Exchnage services active as the
company had chosen to continue using pop email services along with their
public web-hosting package via a local ISP (poor planning for the future I'd
say!)..

My company now wants to start using Exchange for email and collaboration and
now I have the following issue:

The SBS server is configured with an internal domain name
(sbs.ServerName.local) and and the public domain name that the ISP is hosting
is actually the one I need to use (www.ComapnyName.com).

I understand that SBS 2003 does not support Domain Rename using Rendom.exe,
so my only options at this point is to reinstall SBS 2003 and configure the
new domain structure to match the public .com domain (argh!) - or try to
forward email traffic from the the www.CompanyName.com domain to Exchange and
then have outbound smtp traffic appear as if it is coming from
www.CompanyName.com and not the sbs.ServerName.local domain.

This is where I get a headache... any ideas to get me pointed in the right
direction would be most helpful - Cheers!

 

Hi Oswego:

Do NOT create an SBS server with the name of mycompany.com. This will cause
you big headaches.

Instead, have your ISP create an MX , PTR and if possible a SPF recored
pointing your mail to your public ip address.

Then run the CEICW. There you can set the default reply address for your
exchange users.

 

No headache, domain rename, or reinstall needed. Is Exchange actually
installed but just not being used? If not installed of course you have to do
that properly from the integrated setup under add/remove programs/Windows
Small Business Server 2003. I'd also advise installing Exchange SP2. After
that run the CEICW putting in the proper companyname.com when asked. That
will take care of not showing the .local as the outgoing name. Then make
sure your public DNS hosting service has an A record and a primary MX record
(something like mail.companyname.com) that points to your external IP
address. A secondary MX record pointing to another mail host (probably your
current ISP) will cover you if your SBS is down for a period of time. BTW
don't confuse a web site (www.companyname.com) with your registered domain
name (companyname.com) as its your domain name that's important here for
your mail.

 

Hi

Yipeeee, dont worry, all you have to do is run the internet connection
wizard, put the email domain in and all users will be updated with the email
domain..

However, some planning needed first...

1. What is you plan for email collection? POP3 or SMTP, pop3 is not
recommended. Are you ok with SMTP / MX Records. Review your Domain hosting
provider FAQs. Global pop3 is the worst, individual pop3 better but then
always recommend SMTP.

2. Assume all users are in personal folders so need to export / copy these
to their exchange outlook account.

3. What AV protection do you have on the desktops? Boy, company had big risk
here relying on users to protect the network and corporate data. Is there a
Server based AV (antivirus) product installed.

Cant think of any more...

 

The SBS domain name bears no relationship to any email domain(s) that
Exchange handles. The Configure Email wizard will ask all the questions
necessary. Each user will have multiple email names, of which one will
be the 'local' version and one will be the primary, which will be used
for Reply-To and suchlike.

Outsiders will never see the local domain name. The public FQDN will
be mapped by the relevant DNS authority to your public IP address, and
the SBS internal DNS system again has no connection with this. The
Exchange HELO will be based on its primary email domain, not on the
local one.

 

Hi Anna,

Thanks for the helpful reply!

I should have mentioned that the 1st Exchange Organization had already been
setup on a different Windows 2003 Std server with Exchange 2003 Std as a std
member server of the sbs.ServerName.local domain - (probably as a simple
means of unloading additional high-impact services from the SBS server).

I've checked the Exchange 2003 Sp2 server setup using all of the standard
domain forest prep tools and it also passes all of the Exchange Best
Practices Analyzer Tool tests and seems to be ready to go for the migration
of everyone's current Outlook 2003 .pst files using ExMerge.exe

I'm under the assumption that in this scenario since Exchange services were
not intended by the previous systems admin to be run from the SBS server,
that running CEICW is out the window.

I think your advice on the ISP configuring MX, PTR, and SPF records will
solve my domain name and incoming email routing issues, but I think now the
remaining issue with not being able to run CEICW to resolve setting the
default reply address for Exchange users will fall under an Exchange 2003 Std
problem. I'll look there next.

Cheers! -Chris

 

I should have mentioned that the 1st Exchange Organization had already been
setup on a different Windows 2003 Std server with Exchange 2003 Std as a std
member server of the sbs.ServerName.local domain - (probably as a simple
means of unloading additional high-impact services from the SBS server).

I've checked the Exchange 2003 Sp2 server setup using all of the standard
domain forest prep tools and it also passes all of the Exchange Best
Practices Analyzer Tool tests and seems to be ready to go for the migration
of everyone's current Outlook 2003 .pst files using ExMerge.exe

I'm under the assumption that in this scenario since Exchange services were
not intended by the previous systems admin to be run from the SBS server,
that running CEICW is out the window.

I think your advice on the ISP configuring MX, PTR, and SPF records will
solve my domain name and incoming email routing issues, but I think now the
remaining issue with not being able to run CEICW to resolve setting the
default reply address for Exchange users will fall under an Exchange 2003 Std
problem. I'll look there next.

Thanks -Chris

 

That's kinda important! You mean you've already spent the extra money for
Windows 2003, Exchange 2003, and Exchange CALs for a separate box and now
you want to decommission that and go to Exchange on your SBS? Interesting
scenario for sure. How many users do you have?

 

Hi Steve,

I'm coming into this whole thing long after the setup of SBS was done by a
previous systems admin about a year ago and then Exchange 2003 Sp2 was setup
on another 2003 Std server approx 3-months later...

It looks like the intent was to implement a full Exchange 2003 server
separate from SBS. It is not my intent to de-commission this server but just
to have it co-exist functionally within the SBS domain and the outside world
for Exchange email routing (using RPC over HTTPS).

There are currently about 60-users utilizing Outlook 2003 via ISP hosted
POP3 accounts and the company anticipates that number to increase to over 100
by the end of the year - hence the full Exchange 2003 setup I'm assuming...

I think my original issues are partially resolved thru the MX, PTR, and SPF
records routing the company's public domain email to the new Exchange box -
but since I cannot run CEICW on the actual Exchange server I just need to
make sure smtp traffic comming from the sbs.ServerName.local domain looks
like it is coming from the public CompanyName.com domain, and I'm still not
sure how all of this affects RPC over HTTPS for connecting my Outlook
Exchange clients.

-Chris

It appears all ready to go - I just

 

It looks to me that you'll soon be beyond the 75 CAL limit for SBS so you
probably need to consider removing that totally from the configuration. I
have no experience in setting up RPC/HTTP on a standard Exchange 2003 but
its certainly not as neat as what the SBS wizards do for you.

 

How to configure an RPC over HTTP topology on computers that are running
Exchange 2003 with Service Pack 1

http://support.microsoft.com/kb/841652/en-us

"Wizard-less", but much the same under the covers.

I'm a little confused about the relationship of these two environments. You
only get ONE Exchange ORG per Forest and only one DOMAIN per SBS with no
TRUSTS to other domains.

How are these two environements "connected"?

 

I think the original spec and subsequent configuration for SBS was flawed
from the beginning.

It appears as if it is the SBS server was configured as a quasi 2003 domain
controller running Active Directory for local security, file-sharing
services, and Project Server/SharePoint, but no real CompanyWeb, Exchange,
etc...

Email and web services were kept outside at the ISP level and Exchange 2003
was just added on another box as a member server of the local SBS AD domain.

Probably at the time of SBS installation there was a cost benefit for going
with SBS vs Server 2003, but as is eveident now - it would have made sense to
go with a normal Server 2003 domain plus Exchange 2003 rather than SBS.

However, I'm currently stuck with trying to make this all work... (current
topolgy)

a) Server-1, (SBS 2003 Premium Sp1) = Domain Controller
(sbs.DomainName.local) + ProjectServer 2003/Sharepoint + Local File Sharing

b) Server-2, (Win Svr 2003 Std) = Exchange 2003 Sp2 (exch.DomainName.local)

c) ISP hosting = POP3 accounts (60) + company website @ CompanyName.com

Currently there is only one local domain and only one Exchange ORG attached
to this local domain and no trusts to other domains since SBS will not
support that.

My only real challenge here is to get all email traffic currently handled by
the ISP for CompanyName.com routed to the Exchange server on the local
domain, and then in turn have outbound email show as being sent from the
CompanyName.com domain and not the local domain.

The real concern here is how to achieve this public-to-private domain
routing of Excahnge traffic and then also support RPC over HTTP using an SSL
Certificate which is also dependant on domain/site name as well...

If everything was running Server 2003 I would probably just do a Domain
Rename and fix DNS to match whatever I needed and just move on.

SBS is great when things stay relativley small and simple but this is more
of a headache than I would have thought!

Thanks for the input...

Cheers, -Chris

 

My only real challenge here is to get all email traffic currently handled

This is really just a routine problem except that you don't have the benefit
of the SBS POP3 connector.

Same thing, except you don't have the benefit of the SBS wizard. Get a cheap
third party SSL (Godaddy.com is one such source).

NO. Don't even think about, and really there is no reason to anyway. Your
public name and internal name are unrelated and best kept different.

Most things get this way when poor planning and understanding are involved.
You aren't in nearly as bad a shape as I thought you were.

 

Thanks for the encouragement - very appreciated!

I just got handed this whole enchilada on Monday and have a small window to
get things working (with no additional time and/or resources of course...)

I really haven't worked on more than a handful of Exchange 2003 systems from
the configuration side, and the SBS stuff has always been fairly straight
forward and easy to use/maintain - it's just the mixed-up way this was all
implemented that's thrown me off track slightly.

I agree - it's not as bad as I thought at first either, I beleive I've got
the right direction on all issues now.

Its good to have some folks around to make a few callouts and get you back
on the straight and narrow!

Cheers, -Chris