Thanks to all who replied, - seems like my instincts are still fairly well
on the money... one thing that would really seal the deal for me would be
something documented, ideally by Microsoft, that simply puts these points
into a straightforward recommendation of best practice, ideally with some
numbers to back it up... - you know the sort of thing that I can take into
the next planning meeting to argue my case against the other guys who are
pushing for more domains... I'm searching TechNet, MSDN and other such
knowledge repositories, and I've yet to find the exact article or doc that
would fit the bill.

 

For instance, I've seen mention of 100,000 objects as being a trigger for
considering additional domains, in other places I've seen 120,000 objects
stated. I'm also looking for something that gives an indication of DIT size
requirements for a given number of objects (e.g. does each user object
equate to an average size, like 2.5K per user or some such). - There used to
be an AD sizing tool available - and I've got an old copy here - but it
hasn't been updated for years, it appears to no longer be
available/supported direct from MS, and it won't run on Windows 7... Other
things like what actual amount of bandwidth is considered as "low" for
inter-site replication? - one article I saw suggested 28K!!! - I can't
believe anyone would seriously implement links that slow these days, so I
guess that must have been quite an old doc...

 

Anything with some numbers in it to back up the assertions that it seems we
broadly agree on would be an absolute boon!! - anyone know where/if this
doc/article lives?...

 

TIA

 

Paul G.

 

 

From: Brian Desmond [mailto:[email protected]] 
Sent: 10 November 2009 17:22
To: NT System Admin Issues
Subject: RE: Active Directory design in the win2008 R2 world

 

Not much has although you should aim for a single domain forest. I think I
had some slides on that

 

Thanks,

Brian Desmond

[email protected]

 

c - 312.731.3132

 

From: Pauls Hotmail [mailto:[email protected]] 
Sent: Tuesday, November 10, 2009 11:13 AM
To: NT System Admin Issues
Subject: RE: Active Directory design in the win2008 R2 world

 

Thanks Brian, definitely some food for thought there... I wonder if there's
an article somewhere that illuminates the rationale for selecting between
the various choices, - and indeed whether this has changed at all in light
of the W2008 landscape? - strikes me that not much seems to have changed
with regard to namespace planning since the original AD releases....

 

Paul G.

 

 

From: Brian Desmond [mailto:[email protected]] 
Sent: 10 November 2009 16:45
To: NT System Admin Issues
Subject: RE: Active Directory design in the win2008 R2 world

 

See the deck I sent earlier.

 

Doesn't really matter although I usually side with something registered. You
can either do a subdomain off the company's domain, use something like
company.net (I'm a fan of this one), or company.com or whatever. 

 

Thanks,

Brian Desmond

[email protected]

 

c - 312.731.3132

 

From: Pauls Hotmail [mailto:[email protected]] 
Sent: Tuesday, November 10, 2009 9:38 AM
To: NT System Admin Issues
Subject: RE: Active Directory design in the win2008 R2 world

 

An additional query if I may... - What about DNS Namespace choice these
days? - I've always had a personal preference to keep internal AD & public
facing names unique & separate, i.e. NOT using the company's registered
internet domain name as the AD forest name. Obviously this has implications
for DNS configuration, but I've always felt it generally a "good thing" to
maintain isolation between the public & private sides. - Any need to publish
internal resource names outside of the corporate LAN can be achieved simply
enough with products & technologies designed expressly for that purpose...

 

Anyone have any reason to violently disagree with this approach? - care to
comment?

 

TIA

 

Paul G.

 

From: David Lum [mailto:[email protected]] 
Sent: 10 November 2009 14:19
To: NT System Admin Issues
Subject: RE: Active Directory design in the win2008 R2 world

 

+1 Domains are an administration boundary, not a traffic boundary. You will
have DC's and GC's all over the place but not different domains, and as you
said, since 2008 allows different password policies you don't even need
different domains for that.

David Lum // SYSTEMS ENGINEER 
NORTHWEST EVALUATION ASSOCIATION
(Desk) 971.222.1025 // (Cell) 503.267.9764

 

 

 

From: Steven M. Caesare [mailto:[email protected]] 
Sent: Tuesday, November 10, 2009 5:05 AM
To: NT System Admin Issues
Subject: RE: Active Directory design in the win2008 R2 world

 

Agreed. 1 domain.

 

Additional complication requires justification. Ask them to quantify the
additional traffic load for the expected domain topology and provide traffic
statistics demonstrating that a single domain environment would be
problematic.

 

-sc 

 

From: Pauls Hotmail [mailto:[email protected]] 
Sent: Tuesday, November 10, 2009 6:31 AM
To: NT System Admin Issues
Subject: Active Directory design in the win2008 R2 world

 

What's the collective wisdom these days regarding the justification of
deploying multiple domains as a means of limiting replication traffic? I
have an instance here where every part of me wants to suggest a single
forest/domain as the optimum solution, but a couple of other admins are
pushing for multiple domains purely with the justification of controlling AD
object replication. The AD will be a completely new implementation based on
Win 2008 R2, there are about 8 countries in scope, but all have extremely
good/fast MPLS WAN links between them. There are currently only about 1200
users in total, and Exchange 2010 will be going in as well.

 

 I'm proposing a single domain, with multiple AD sites, as there's no other
good reason for over-complicating the design with additional domains, i.e.
none of the traditional justifications for adding additional domains apply
in this case.. Plus I believe at least some of the traditional
justifications no longer apply in W2008 anyway do they? - things like
needing domains for the purpose of applying differing password policies for
example, now that we have the new granular password policy ...

 

Can anyone point me in the direction of some best practice design guidelines
that would cast some light on these questions? - it's been a few years since
I was last "properly" involved in AD design, so I'm conscious that things
have moved on in the AD world, and I probably need to take up-to-date
information into consideration..

 

Many thanks.

 

Paul Gordon

 

 

 

 

 

 

 

 

 

 

 

 

 

 

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

Reply via email to