I may be mistaken, but you only need to have a native mode domain in the forest to facilitate the DL to DG migration. IIRC, the native mode domain merely allows Universal Security Groups to exist in the forest, which are then used for the E2K Distribution Groups. I would run domainprep only on the (probably mixed mode) AD domain that will host the Exchange 2000 server.
-----Original Message-----
From: Darren Sykes [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 31, 2001 9:20 AM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] Pros and Cons f an "empty" top level domain
I'd agree that a native mode domain is highly desirable when migrating
to Exchange 2000.
However, the root level domain should be empty to benefit from some of
the points mentioned.
I wouldn't really advise running domainprep in the root domain, as would
be necessary if this domain
were to be used for e2k migration.
Darren.
-----Original Message-----
From: Ryan, John [mailto:[EMAIL PROTECTED]]
Sent: 31 May 2001 15:03
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] Pros and Cons f an "empty" top level domain
If you are plannning the deployment as part of an NT4-Win2K migration,
another advantage of the empty root domain is the ability to set the
domain in Native Mode immediately. A native mode domain is important in
an Exchange 2000 deployment to handle distribution list migration
issues.
-----Original Message-----
From: Murray-Smith Tony CF CH [ mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> ]
Sent: Wednesday, May 30, 2001 7:25 AM
To: '[EMAIL PROTECTED]'
Subject: RE: [ActiveDir] Pros and Cons f an "empty" top level domain
Yes, I understand that this is a fairly common approach. One advantage
of
having the empty root domain in a separate tree means it does not have
to
share a namespace with the rest of your domains.
You could call your empty forest root "domain.local" and then have a
separate tree starting with your company's registered domain name, e.g.
"pacbell.net".
This approach makes it easier to deal with name changes as a result of
re-branding, mergers, etc. The name "domain.local" is generic enough to
cope with such changes.
Tony
-----Original Message-----
From: Ayers, Diane [ mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> ]
Sent: Dienstag, 29. Mai 2001 19:09
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] Pros and Cons f an "empty" top level domain
All:
Thanks for all of your input. It is helpful.
For a slightly different take, one example of a forest structure using
an
empty top level domain, was to not make it a "top level" domain of your
domain tree such as company.com for child.company.com but to make it a
separate tree in the forest. You first domain (and tree) would be
anything
that was not part of your contiguous domain tree. For example, your
first
domain would be company.net or in the example I saw <registered OID>.net
The reset of the forest was built in a domain tree fashion as you
normally
would see.
Diane
-----Original Message-----
From: [EMAIL PROTECTED]
[ mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> ]On Behalf Of Tony Murray
Sent: Tuesday, May 29, 2001 5:48 AM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] Pros and Cons f an "empty" top level domain
Hi Diane
The only other advantage I can think of is that because the empty root
domain is small, it can be easily replicated anywhere on the network to
protect against location-based disasters.
The empty root domain obviously incurs an additional cost, both the
up-front
cost of additional domain controllers and the ongoing management and
support
overhead. If you do decide to opt for an empty root domain be sure to
buy
enough DCs (and maintain off-site backups) in case of disaster. There
is no
way to re-install the forest root domain if it has been lost.
Tony
---------- Original Message ----------------------------------
From: "Darren Sykes" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Date: Tue, 29 May 2001 07:46:32 +0100
Diane,
A couple of things that sping to mind:
1) Naming. The name you choose for your root domain cannot be changed.
If your domain design is based on location for example, you don't want
to rely on the fact that you will always have company offices in a
particular location so a generic root domain is sensible.
2) Kerberos referrals. When you access resources across domain trees a
Kerberos referral will be made through the room domain DC's. In some
situations it is therefore sensible to locate root DC's close to
clients. If you use an empty root domain unnecessary account replication
will not need to take place.
3) Domain Administrator logins. As you mentioned in your original
posting, permissions on the root forest should be split for security's
sake. You can set permissions by ACL's, but we aware that Domain Admins
in the root domain can make themselves members of the Enterprise Admins
group by default which can then be used to gain administrator access to
every machine in the forest.
4) Password policy is domain specific. You can apply more secure
policies regarding passwords etc on the root domain to limit the risk of
a forest wide security breach.
I'm scraping the bottom of the barrel now so I'll stop, I hope those are
of some help.
Darren.
-----Original Message-----
From: Ayers, Diane
Sent: Mon 28/05/2001 17:26
To: [EMAIL PROTECTED]
Cc:
Subject: [ActiveDir] Pros and Cons f an "empty" top level domain
All:
I am finalizing our organization's forest and domain plan for
our active
directory deployment. One element that keeps getting brought up
is the
"need" for an empty top level domain in the forest. I really
haven't been
able to find a good overview of this design factor.
We will be delegating a DNS zone (something.company.com) from a
primary DNS
zone (comapny.com) managed by our UNIX BIND folks (a partner in
our DNS
design) and have a good handle on the overall DNS design. We
also run a
split DNS design so externally, there is no reference externally
to our
internal DNS world.
The two criteria often stated for the empty top level domain is
one,
protecting the presence of your internal DNS space from the
outside world
which isn't a factor in our case (spilt DNS). The other factor
is the need
to segregate the Enterprise and Schema Admins from the rest of
your
administrative model. This may or may not be an issue since
there are (I
believe) other ways to protect these groups (ACLs as one
example). Our
domain design will be fairly flat. One domain with maybe one or
two child
domains but hopefully we will stick with the one domain. We
will be
incorporating approx. 20,000 users and 20,000 devices into our
AD.
With these factors, I see little need to build the additional
empty top
level domain. However, in my investigation I may have missed
other factors
that may lend to having an empty top level domain.
Any feedback?
Diane A.
Team Lead
Distributed Computing. System Server Support
"Als ik kan"
List info: http://www.activedir.org/mail_list.htm
<http://www.activedir.org/mail_list.htm>
List archive:
http://www.mail-archive.com/activedir%40mail.activedir.org/
<http://www.mail-archive.com/activedir%40mail.activedir.org/>
List info: http://www.activedir.org/mail_list.htm
<http://www.activedir.org/mail_list.htm>
List archive:
http://www.mail-archive.com/activedir%40mail.activedir.org/
<http://www.mail-archive.com/activedir%40mail.activedir.org/>
List info: http://www.activedir.org/mail_list.htm
<http://www.activedir.org/mail_list.htm>
List archive:
http://www.mail-archive.com/activedir%40mail.activedir.org/
<http://www.mail-archive.com/activedir%40mail.activedir.org/>
List info: http://www.activedir.org/mail_list.htm
<http://www.activedir.org/mail_list.htm>
List archive:
http://www.mail-archive.com/activedir%40mail.activedir.org/
<http://www.mail-archive.com/activedir%40mail.activedir.org/>
List info: http://www.activedir.org/mail_list.htm
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
