Actually - the empty root should be just that - empty. The transitive trust model handles the rest.
------------------------------------------------------ Roger D. Seielstad - MCSE Sr. Systems Administrator Inovis - Formerly Harbinger and Extricity Atlanta, GA > -----Original Message----- > From: Salandra, Justin A. [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, December 11, 2002 9:24 AM > To: '[EMAIL PROTECTED]' > Subject: RE: [ActiveDir] Back to Basics - Design Pros and Cons > > > I also agree with those people here that say to have a 3 > domain model in a > single forest. By creating an empty root and having two > child domains, you > can ensure security and separation from faculty and students > as well has > have a very detailed OU Structure in your students domains > based on year or > majors and your faculty can have an OU structure of department. > > For the empty root, I would put in the root those services > and servers that > both students and faculty members need, such as a e-mail > server and web > server. File servers and application servers I would put in the child > domains that are relative to each domains. (ie FACULTYFP01 > and FACULTYAPP01 > in the Faculty domains and STUDENTFP01 and STUDENTAPP01 in the student > domain. > > Just the path I would head down. > > Justin A. Salandra, MCSE > Senior Network Engineer > Catholic Healthcare System > 914.681.8117 office > 646.483.3325 cell > [EMAIL PROTECTED] > > > -----Original Message----- > From: Craig Cerino [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, December 11, 2002 9:10 AM > To: [EMAIL PROTECTED] > Subject: RE: [ActiveDir] Back to Basics - Design Pros and Cons > > Max, > > While I think there are a LOT of issues that should be addressed > (probably too many for you top get enough quality feedback through an > email forum) there are a few basic things I would recommend > considering. > > 1. Who needs to do what or get where (appliance wise) > 2. What needs to be accessible to these people (as a whole) > 3. Who needs to be able to access what? > > Again, these are just "tip of the Iceberg things" but that is > where I'd > start. I'm guessing by what you said and the mere fact that it is a > multi campus university, that you have a healthy reliable backbone in > place already. > > While multiple FORRESTS are doable (some people may even lead you down > that path - your decision) I always consider them to have a TON over > administrative and maintenance related overhead. (Not sure how large > your team is that will support this architecture) > > If it were me (because I never tell someone "THIS IS WHAT YOU SHOULD > DO") I would forget about the domain for each campus etc. I > would stick > with two domains FACULTY and STUDENTS (naming convention to be decided > later) and move on from there. > > Just my 2 cents Max. > > Good luck with this project - sounds exciting to me. > > Craig > > > Craig P. Cerino > MCSE, MCP+I > Systems Administrator > TIE SOLUTIONS, Inc > > > > > > -----Original Message----- > > From: Wohlgehagen, Max W > > [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, December 10, 2002 8:20 PM > > To: '[EMAIL PROTECTED]' > > Subject: [ActiveDir] Back to Basics - Design Pros and Cons > > > > > > There is so much material out there on AD now it is almost > > scary [in many ways it is not too dissimilar to NDS 'cepting > > the DNS component] My problem is design for a new network, > > being in a school we have the luxury of starting from scratch > > without business fallout problems. We are multi-campus and > > have a fairly substantial network with an 11MB "Spread > > Spectrum" Microwave link between campuses. I am a big fan of > > the KISS principle but am stuck in deciding between multiple > > trees or a single tree with many sites, both concepts have > > advantages. We do not need to implement a Forrest structure > > as our DNS is set in concrete. We have the following > > elements: Campus1, Campus2, Students1, Students2, Staff1, > > Staff2 ... or OrganisationAll, StaffAll, StudentsAll. > > Obviously there are sub components of these elements as well. > > The main concern is to have the most useful GPO structure > > without too much complexity. Does anyone have any experience > > in setting up this type of AD. Any ideas on multiple domains > > versus single domain many sites?? Help, opinions, comments, > > ideas all welcome. Thanks. > > > > Max Wohlgehagen > > TSI - Rowville > > "Of all the things I've lost, it's my mind I miss the most." > > <<Wohlgehagen, Max (E-mail).vcf>> > > > > > > > > ************************************************************** > > ***************** > > Important - This email and any attachments may be > > confidential. If received in error, please contact us and > > delete all copies. Before opening or using attachments check > > them for viruses and defects. Regardless of any loss, damage > > or consequence, whether caused by the negligence of the > > sender or not, resulting directly or indirectly from the use > > of any attached files our liability is limited to resupplying > > any affected attachments. Any representations or opinions > > expressed are those of the individual sender, and not > > necessarily those of the Department of Education & Training. > > > > > 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/ > > 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/
