Deploying Exchange 2003 and best practice in AD design 2

[tuliphead]

I consider deploying Exchange 2003 at work and in relation to that, I am looking for the best practice to design my AD-envioronment.

Today we have a registered internet-domain name that is mainly used for different web-services for our customers.

Our AD domain is named mycompany.internal and is the root-domain in the forrest. No other subdomains exists. We are approximately 1000 users and have no plans to create more domains than necessary.

As far as I know, there is no relationship between AD-domains and SMTP-domains, so possibly there is no need to create an external domain that is named with the name of our internet domain?

The exchange servers will be located both in the internal network and in our DMZ (front-end & back-end solution). I also wish to protect internal DNS-resources from outsiders.

I´ve seen a couple of examples that goes in the direction of two domains:

internal.internetdomain.com (internal domain)

and

internetdomain.com (external domain)

In that case the external domain also would be the root domain in the forrest.

What would be the best approach for my exchange deployment? Any suggestions would be appreciated.

- Could I keep my existing environment and at the same time fulfill my goals?
- If I need to restructure our AD domain-name to relate to our internet domain name, what would be the best approach? (renaming or migrating to a new forrest?)

 

[markdmac]

You are correct int hat there is no link between the AD domain name and the SMTP domain name. All that is required os you have an MX record in public DNS that points to the Exchange public IP. So no changes should be required to your AD.

Thsi KB should assist you with your Front End/Back End questions.

http://www.microsoft.com/technet/security/prodtech/exchangeserver/secmod47.mspx

I hope you find this post helpful.

Regards,

Mark

 

[tuliphead]

Ok, if we talk about pro and cons:

What is the advantages/disadvantages with:

internal.myemaildomain.com
myemaildomain.com

vs

mycompanyname.internal only?

Is one modell easier to administer than the other?

 

[markdmac]

mycompanyname.internal or mycompanyname.local is easiest as it will prevent DNS issues unless you are hosting your own email and

http://WWW site.

If you are hosting both the email AND

http://WWW I'd

go with the public name then.

I hope you find this post helpful.

Regards,

Mark

 

[tuliphead]

One design goal is to separate the internal DNS space with the external dns space. We will be running our own DNS server for the external e-mail domain. It could be quite a few services served from the company itself in the near future, webpages, e-mail, ftp and so on.

I need to take a few design choices quite soon, so I am interested in hearing other peoples opinions and experiences with this. This is not a big company. 1000 users ain´t that much ... and by dividing our AD into two domains, you get a more complex administration environment. But I will do this the right way from the start. Thats the reason for asking.

Any other input?

 

[Zelandakh]

1,000 people. One domain. Use companyname.local or similar for the domain name and companyname.com would then get picked up externally as per other externals. Simplifies stuff.

 

[markdmac]

I agree with Zelandakh.

I hope you find this post helpful.

Regards,

Mark

 

[tuliphead]

And if I choose to host my own DNS-zone for the external domain ... and that server happens to be a windows server? domain? workgroup?

And can someone refresh the thing with smtp-domains and how it works against AD accounts? Lets say I create user john.doe@mycompany.internal, what parameters is it that decides that he will get an e-mail adress of john.doe@internetdomain.com ?

 

[markdmac]

The recipeint policy determines that he will get the internet address in addition to the intranet address.

SMTP domains are totally independent of AD and are not aware of AD. SMTP goes by what DNS says is the MX record for a domain.

If you host your own DNS, you will want it to be in a DMZ and not connected to your domain.



I hope you find this post helpful.

Regards,

Mark