Depends on what they need to do...if they're developing LDAP-enabled apps, they will 
inevitably want to extend the schema sooner or later.  That means they'll need a 
seperate forest in which to test their extensions (and the scripts, LDIF files, or 
programs they write to do the extensions).  You do NOT want to introduce their 
extensions into your production forest until they've done it in a test forest and 
validated that they work as intended.  This also implies that this test forest may 
need to be rebuilt when their extensions don't work out (been there/done that).
My preference would be a seperate forest - one domain with 2 DCs.  Back up at least 
one DC regularly, and certainly before they do schema extensions.  If they screw it 
up, you can blow the domain away and restore the backup.  Yes, it's a pain, but it 
beats screwing up the production AD.
If you can swing it, I'd even go so far as having THREE forests - production, dev, 
test.  Use the test forest as described above.  When schema extensions have been 
validated there, use the scripts/files/programs they built there to extend the dev 
schema.  The developers can do most of their app development and testing there.  ONLY 
when all is well there should the extensions be applied in production.  The test 
forest could be just one PC installed as a DC, so you could dcpromo it down and up 
again at will while testing schema extension scripts, etc.  

Oh, I see since I started this note a couple others have replied with similar 
thoughts...I guess I'm not crazy after all.

It sure will be nice when we can actually delete schema elements that were defined in 
error !
Dave

-----Original Message-----
From: Andy Grafton [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 06, 2002 9:03 AM
To: [EMAIL PROTECTED]
Subject: [ActiveDir] Development Domain


We have Developers.
They are Evil Beasts who like to mangle anything they can.
They can kill any system with one line of code, from 50 paces, at the most
unfortunate time imagineable.
Our corporate domain (say co.int) is a beautiful Active Directory thing with
a single root and sites spread across Scandinavia.
The Evil Beasts have their own, separate NT4 domains which they persecute -
one on each site.
They don't develop in the corporate domain.  Not that we know of...
Now they are howling for Exchange 2000, live Active Directory with different
sites, the ability to test their code against MS LDAP rather than faithful
Unix.
To encourage the sharing of resources between sites we shall set up an AD
domain just for them.

The question has arisen:

Do we give them their own domain, with separate root (say dev.int),
or give them a child domain in our corporate tree (say dev.co.int)?

As far as I am aware, there is one Exchange Organisation and one AD database
per tree.  If the developers in dev.co.int kill something fundamental [not
just a server in the child domain], there will be an impact on the parent
domain co.int.  Is this correct?

I'm all for making them a separate root from a
keep-their-hands-off-my-infrastructure prespective, but colleagues argue
that we will be better served by and integrated with the corporate domain
(where they are logging in, most often) if we go with the parent-child
scenario.

Does anyone out there have experience of this sort of thing?  Are parent and
child domains separated enough that the corruption of a child domain would
not affect the parent?

As I write this, I feel that I already know the answer, but I have to be
sure before I argue my point...

All the best,

Andy
List info   : http://www.activedir.org/mail_list.htm
List FAQ    : http://www.activedir.org/list_faq.htm
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
List info   : http://www.activedir.org/mail_list.htm
List FAQ    : http://www.activedir.org/list_faq.htm
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/

Reply via email to