Domain Topology and Exchange Server

[rakem]

We are planning on implementing Exchange Server 2003 onto our network, one of my work mates has been on an exchange server course and he feels that we have our domain topology setup wrong.

At the moment we have 7 separate domains each operating independently of each other. For example – domain1.local, domain2.local, domain3.local. All domains obviously have their own DC and they are all running Windows 2003 standard.

We have Two way trusts linking all the domains as well as DNS. Our DNS is configured to have Active Directory Integrated Primary forward lookup zones for the DC of that domain and then secondary forward lookup zones which point to every other domain.

Now I think that our topology is fine and that we can implement exchange onto it. My work mate thinks that we need to have one central DC e.g. central.local, then have each of our other domains as child domains of that e.g. domain1.central.local, domain2.central.local, domain3.central.local.

We are planning to put Exchange onto a server that does not have Active Directory Installed, I know that exchange has an active directory integrator thing, so it shouldn’t be a problem to connect to the other domains AD from the exchange server to set up mail boxes right?

So what do you guys think? Reconfiguring every domain would be a massive job that would cause so much disruption its not funny, we have about 200 users so I don’t really want to go down that road. And also if the central DC crashes then we loose the whole network. I cant see a problem with out current set up.

Any suggestions would be great! thanks

[fizban2]

having 7 seperate domains may cause some issues with the exchange propegating across all of them, just one domain run AD? or do each have there own active directory also? having one primary domain (ie central.local) the having child domains in the same forest (ie, site1.central.local, site2.central.local, etc) would allow for a easier deployment of exchange i would think. but sadly my exchange knowledge is a little weak so i can only suggest. hopefully this helps, i am curious also so i will do some research the 2 different setups and see which one would work better or the pluses and minuses of each.

[rakem]

each of the 7 seperate domains has its own Active Directory.

The domains are located accross the country (Australia) so we thought it better that each domain can run independently of each other to help with redundency

[cluberti]

The domains are located accross the country (Australia) so we thought it better that each domain can run independently of each other to help with redundency

Actually, if you had one single AD domain with 7 separate sites within it, that would be MUCH more redundant. I am quite sure your Exchange guy is onto something there with his assessment .

You've created a 7-headed monster, when all you really needed was 7 (or more) subnets and 7 AD sites - all could be centrally managed much easier from one AD domain (which Exchange is going to require if all of those users are to be in one Exchange cluster).

I'd suggest the following, at a minimum:

1. AD domain migration into a new domain (and not yourdomain.local, but yourdomain.tld for a split DNS if you plan on publishing Exchange via ISA 2004, which I also suggest as it makes life much easier on your user base regarding email access). Create trusts from all 7 domains to the new domain, and migrate EVERY object into the new domain, machines, users, and printers all.

2. Decommission all of your old domains, moving each domain's old DC into the new AD and promoting to a DC in that domain (I'd also suggest a complete rebuild of each DC, so as not to bring any invalid data into the new AD schema, but that's just a suggestion).

3. Create 7 sites and 7 subnets (or more) in your AD Sites and Services snapin, and move the requisite servers into their proper sites. Assign the proper subnets to their respective site - this will help clients and servers "know" where they are by the IP they get from DHCP, and will use the closest DC and DFS root (which I explain later).

4. Make sure you have at least one global catalog server at each site, preferably two.

5. If you've got fileservers at each site, migrate them all into a domain DFS root, so that all shares appear to come from \\DOMAIN\SHARE, rather than \\fileserver\share. This data can be replicated amongst all file servers in the DFS root (since you value redundancy, STRONGLY suggested if you have the disk space), or the data can simply reside on each file server and not be redundant. This way, all old (and new) file shares you create in your domain are always available via \\DOMAIN\SHARE, no matter which file server it's on. If you choose to replicate, users will attach to the closest working DFS root based on their IP and site in the AD.

I know that exchange has an active directory integrator thing, so it shouldn’t be a problem to connect to the other domains AD from the exchange server to set up mail boxes right?

Well, actually, Exchange 2003 REQUIRES a working, well laid-out AD (which you will have just created). It goes without saying that until you do this, you will find that Exchange 2000 or 2003 just won't work right for you (unless you plan on purchasing Exchange 5.5 and paying over $200,000 USD a year for support for said product) - Exchange requires all users to be in the same domain unless you plan on some hacks to make it work, which actually won't work if you upgrade to Exchange 12 in the future. Your Exchange guy isn't entirely right (you CAN make this work, but you SHOULDN'T ), but he will be in about a year. I'd suggest embarking on a clean (and well laid-out) AD before Exchange 12, not after.

6. At this point, you can sit back, relax, have a few adult beverages, and watch your daily grind become a little easier to manage - not to mention that Exchange 2003 will now work properly for everyone in the organization without convoluted hacks that will cease to work when Exchange 12 comes out!!!

Edited January 12, 2006 by cluberti

[rakem]

The domains are located accross the country (Australia) so we thought it better that each domain can run independently of each other to help with redundency

I'd suggest the following, at a minimum:

1. AD domain migration into a new domain (and not yourdomain.local, but yourdomain.tld for a split DNS if you plan on publishing Exchange via ISA 2004, which I also suggest as it makes life much easier on your user base regarding email access). Create trusts from all 7 domains to the new domain, and migrate EVERY object into the new domain, machines, users, and printers all.

yourdomain.tld? i have never heard of that.

so what your saying is that we have tha main domain e.g. yourdomian.tld, then have the seven sites as childs? like domain1.yourdomain.tld, domain2.yourdomain.tld.. etc

4. Make sure you have at least one global catalog server at each site, preferably two.

How exactly do you create a GC server? or is it just a server that hosts the GC's and if so how does the GC get onto the server, isnt the GC directly related to active dirctory?? maybe im a bit wrong here haha not sure...

5. If you've got fileservers at each site, migrate them all into a domain DFS root, so that all shares appear to come from \\DOMAIN\SHARE, rather than \\fileserver\share. This data can be replicated amongst all file servers in the DFS root (since you value redundancy, STRONGLY suggested if you have the disk space), or the data can simply reside on each file server and not be redundant. This way, all old (and new) file shares you create in your domain are always available via \\DOMAIN\SHARE, no matter which file server it's on. If you choose to replicate, users will attach to the closest working DFS root based on their IP and site in the AD.

We have one massive file server in our head office that hosts all files, its got almost a terra byte haha, so DFS wouldnt be the best bet for us i dont think

well thanks for all that... the main thing is that with alot of users in different states it will mean alot of flights and a hell of a lot of work to switch everyone over to this new domain.

but again thanks for the input

Edited January 12, 2006 by rakem

[eyeball]

by yourdomain.tld he means Top Level Domain eg your domain.com so that when you come to using Outlook Web Access you can simply type in mail.yourdomain.com and your OWA will appear. (as opposed to your users remembering https://81.55.168.154/exchange) lol

Edited January 12, 2006 by eyeball

[cluberti]

How exactly do you create a GC server? or is it just a server that hosts the GC's and if so how does the GC get onto the server, isnt the GC directly related to active dirctory?? maybe im a bit wrong here haha not sure...

You can configure a domain controller to host a copy of the GC in the Sites and Services snapin. And yes, GC is related to AD - it's the Global Catalog of AD objects, and having one at each site increases redundancy. If you do so, you'll have multiple copies of the GC at multiple sites; not only will it increase the speed and accuracy of AD searches at each site, you'll be OK if you lose a GC AD domain controller to a disaster.

yourdomain.tld? i have never heard of that.

What I meant was, whatever your public domain is, use that internally for your AD as well. So, for example, if you own the domain "domain.com", you would name your AD "domain.com" and use split DNS. Hopefully that makes more sense.

well thanks for all that... the main thing is that with alot of users in different states it will mean alot of flights and a hell of a lot of work to switch everyone over to this new domain.

Well, if you ever plan on using Exchange 12 or Longhorn server, you won't have a choice - better to do it now and get used to it, rather than continue growing 7 separate domains and go through the pain later.

Edited January 12, 2006 by cluberti

[fizban2]

yourdomain.tld? i have never heard of that.

so what your saying is that we have tha main domain e.g. yourdomian.tld, then have the seven sites as childs? like domain1.yourdomain.tld, domain2.yourdomain.tld.. etc

think of it like this, you domain name on the web is www.australia.com

for your domain you would use australia.com, then each site could be something like sydney.australia.com, townsville.australia.com, brisbane.australia.com. this way it is easier to identify each domain and where it is located the tld is australia.com and for owa you could have owa.australia.com or something to that nature.

We have one massive file server in our head office that hosts all files, its got almost a terra byte haha, so DFS wouldnt be the best bet for us i dont think

well thanks for all that... the main thing is that with alot of users in different states it will mean alot of flights and a hell of a lot of work to switch everyone over to this new domain.

DFS would still be an ideal way to go through this, remeber you don't have to replicate the whole thing. you can choose what folders you wish to replicate across to other machines, maybe just software shares or shared drives for users. this would also help with latency issues accross the network.

As for everyone being all over the place, as cluberti stated earlier, you can setup this new domain independtly of the old one, then move everything to the new domain, on the client end the most they should have to do would be change the domain registration. in effect, bring online new domain, create trust to old domain, move test AD object (or a small group of beta testers(preferably some from each site) to the new domain, register the machine with the new domain and make sure they work, once they work move everything else across and test, if not working you can always move back to the old domain as a last resort, once everything has been tested and working you can shutdown the old domain, then you can use those machines in the new domain (i would defiantly wipe the boxs to be sure nothing contaminates the new domain). You are right it will defiantly be alot of work, but you can either do it now, or wait for longhorn server and have to do a server migration as well as a domain migration, THAT would be a nightmare.

Edited January 12, 2006 by fizban2

[cluberti]

You are right it will defiantly be alot of work, but you can either do it now, or wait for longhorn server and have to do a server migration as well as a domain migration, THAT would be a nightmare.

Exactly my point. Sometimes we can't see the forest for the trees sometimes, but I'll still point them out .

[rakem]

As for everyone being all over the place, as cluberti stated earlier, you can setup this new domain independtly of the old one, then move everything to the new domain, on the client end the most they should have to do would be change the domain registration. in effect, bring online new domain, create trust to old domain, move test AD object (or a small group of beta testers(preferably some from each site) to the new domain, register the machine with the new domain and make sure they work, once they work move everything else across and test, if not working you can always move back to the old domain as a last resort, once everything has been tested and working you can shutdown the old domain, then you can use those machines in the new domain (i would defiantly wipe the boxs to be sure nothing contaminates the new domain). You are right it will defiantly be alot of work, but you can either do it now, or wait for longhorn server and have to do a server migration as well as a domain migration, THAT would be a nightmare.

To set up a new domain independtly of the old one we would need to do that on a brand new server, because you can set up two domains on one server right?

however this does sound like the best approach to our problem.

So using this top level down (TLD) approach sounds good do, so this means that we have our main DC hosting the domain australia.com and our other domains use the australia.com name with their domain name in front e.g. nsw.australia.com.

each domain will still have its own DC which hosts all its user accounts in Active Directory, but does this mean that the DC that hosts the main domain (australia.com) will have all the user accounts from every state in it, or none or what?

Im a bit confused as to the role of the DC that will be hosting the main domain name - australia.com

Edited January 12, 2006 by rakem

[fizban2]

To set up a new domain independtly of the old one we would need to do that on a brand new server, because you can set up two domains on one server right?

correct, you would need a new server for each site at least to setup the initial DC and get the site running, i know if sounds like alot of money, but it is a good investment,

So using this top level down (TLD) approach sounds good do, so this means that we have our main DC hosting the domain australia.com and our other domains use the australia.com name with their domain name in front e.g. nsw.australia.com.

correct, you would have the domain australia.com and the primary domain, then have child domains in that forest, (nsw.australia.com, etc) this is one way to do it, there are other ways as well

each domain will still have its own DC which hosts all its user accounts in Active Directory, but does this mean that the DC that hosts the main domain (australia.com) will have all the user accounts from every state in it, or none or what?

Im a bit confused as to the role of the DC that will be hosting the main domain name - australia.com

each site would have its own DC but it would be a child of the australia domain, to explain better, australia.com would host your AD for all sites, the domain controller at each site would act like a local repositrory for the the australia AD, allowing the users to gain access without have to hit the main DCs everytime, this allows for a central point of management for all sites from one place, AD sites and service will allow you to setup sites for each one of your physical sights as cluberti mentioned in a post earlier.

what this design allows the impression of a single point of entry and change (ie autralia.com) where things can be changed and then can propogate down the child domains the are part of australis.com. It is a confusing topic, let me know if there is anything that seems confusing.

Can anyone else elaborate more?

[Marsden]

Let's not leave out Windows 2003 R2. With the new DFS (Distributed File System) you can simplify file sharing acrous your entire domain (multi sites).

DFS allows you to create a single namespace for file shares that are located on different servers, redirecting remote users as required to the correct physical locations. Among other niceties, DFS is site aware: Based on the IP address of the user accessing a DFS share, DFS will ensure that they're using the closest possible DFS server. Abstraction in DFS is important for a variety of reasons, but the most obvious is that administrators can move shared folders to different locations, even on different servers, without disrupting or even informing users of the change.

FRS has been succeeded by a new DFS 2 technology called DFS Replication. DFS Replication uses a multimaster replication model that allows DFS-based data to be replicated more efficiently over the network than was possible with FRS. A good part of this efficiency is due to a new technology called Remote Differential Compression (RDC) that replicates only those parts of a file that have changed, dramatically lowering network bandwidth. If you change the title in a PowerPoint presentation, only that title change will be replicated across DFS, not the entire file. This is far more efficient and, ultimately, less expensive.

[cluberti]

correct, you would have the domain australia.com and the primary domain, then have child domains in that forest, (nsw.australia.com, etc) this is one way to do it, there are other ways as well

No no no no no - I'm not talking about a root domain with 7 child domains - I'm talking about a SINGLE domain with 7 SITES. This is MUCH different. 7 sites is not enough, at least in my opinion, for multiple domains. You need to get to thousands of users in more than 20 sites to even need to think about multiple domains.

Please pm or email me, rakem, if you have any further questions. I think I may be confusing some people with my suggestions, and I don't want to muddy the waters any further.