Active Directory/Documentation/College of Textiles Migration

Overview

The College of Textiles (COT) currently uses its own Active Directory implementation to manage the computing environment for its faculty, staff, and graduate students. However, having considered the community of NCSU Colleges assembled under the WolfTech domain, the expertise of the members therein, and the willingness of the administrators to bring us on board the COT IT staff is eager to become a productive member College. To that end, this document will be used to journal our migration from the Textiles AD domain to the WolfTech domain. Hopefully the visibility provided here will assist us toward a successful migration and serve as an aid to other Colleges considering joining WolfTech.

Textiles Active Directory Architecture

The following is a description of the COT Active Directory environment from which the migration to the WolfTech AD Domain will take place.

Physical Architecture

Three domain controllers running Windows 2000 Server SP4 host AD at the COT. These servers have reached the end of their lifecycle – two are single processor Xeon 2GHz machines with 1 GB RAM and the third has 512MB RAM. Two of the servers are hosted here at the COT and the third is hosted at Poe Hall. The AD distributed installation packages are also hosted on the domain controllers.

Logical Architecture

The COT hosts a single domain named ‘tx.ad.ncsu.edu’ or ‘TX’ for short. There are two primary OU’s for faculty and staff computer accounts. The first is named ‘Faculty-Staff’ and is being phased out as we cycle in new computer systems. Some common settings are applied to this OU along with frequently used software (like Adobe Reader, KeyClient, Oracle Calendar, etc.) via Group Policy. This OU also serves as a container for several OU’s that are named based on a version of Microsoft Office. Computers were added to the appropriate OU based on the version of Microsoft Office that was purchased with the system and each office based OU has a group policy associated with it to deploy the Office suite.

The second primary OU (and the one that is used for new systems) is named ‘Production’. This OU also has some group policy objects linked to it to apply common settings and install frequently used software. The OU’s contained within are organized primarily by department but also by function. Office and other licensed software are deployed to systems in the Production OU via Group Policy based on security group membership.

User account logon names mirror a person’s unity ID. User accounts are also created for specialty purposes that do not correspond with a unity ID. Workstation computers are generally named with a TX prefix followed by the room number followed by a dash (-) and then a number starting with 01. Servers are named based on function or after a former dean.

Questions

This section will be used more as a note taking area - if you have a question of any sort related to the migration just pose it here so we can address it as it becomes the focus of our efforts. The answers may be obvious or clearly answered in other parts of the WolfTech AD doc but feel free to use this as a scratch area for your migration concerns. As the answers to the questions begin to materialize we will create new sections in the Textiles migration wiki to fully address the topic.

Q: What policies will be inherited from the WolfTech Site/Domain/Parent OU's? Are they enforced or can they be blocked?

A: Quick from the top of my head answer - I believe at a minimum there is an enforced anti-virus policy and windows update policy - but I don't know the details.

Q: What will be our local admin access strategy as we move to the WolfTech domain? Currenty we add professors and some staff to the local admin group and sometimes grad students but it is more an issue of discretion than one that is handled via Group policy. How will we design our GP to support our local admin strategy?

A:

Q: We currently deploy a slew of applications to any computer placed in our production OU - zip util, wolfcall, adobe reader, etc. This is convenient but prevents us from having fine-grained control over application deployment. How will we address 'baseline application' deployment in the WolfTech environment? If we control all application distribution via security groups will we have a scripting solution to simplify the process of adding a new computer to the domain?

Q: Will we keep the default OU layout provided by WolfTech? Will this support the needs of our college?

A: We fully intend to follow the OU structure layout required to apply (and contribute) software packages to our computer resources. As for the default OU structure we believe the the COT more closely resembles a Department OU than a College OU mainly because we have a single set of IT administrators - there will be very little delegation of IT Administration outside of Textiles Computer Operations (TCO). That being said we do have an IT Administrator for the ITT department who is not a member of TCO and we would like to accomodate him as a quasi-OU Admin - we need to consider this in our OU design.

Q: What will our strategy be for effectively managing laptops? We don't have a clear strategy at present - some laptops are fully managed as though they were just another workstation with a full suite of both keyed and non-keyed applications while other laptops are simply members of the domain but left mostly untouched by any form of Group Policy.

A: