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.

Existing 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.

Migration

This section will be used to address the specifics of the migration to from the TX domain to the WolfTech domain.

General Concerns

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.

User Accounts

Naming

Unity account names are used in the WolfTech Domain. The default OU layout allows for 'Departmental Users' including 'OU Admins', 'Class Accounts', 'Service Accounts', and 'Other Users'. For clarity I recommend we use the dotted notation for all 'Departmental User' accounts - i.e. srleap.admin, txguest.user, bodyscan.localadmin, etc.

Account Creation

Dan Green will populate the WolfTech 'People' OU with the unity ID's of Textiles faculty, staff, & students. He has access to the campus directories though I'm not quite clear on his process for connecting and acquiring the correct set of users. The users will be members of the 'Domain Users' group.

Questions

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:

Computer Accounts

Naming

We are currently formulating a new computer naming scheme. Our current naming scheme includes the room number however we have found that this changes too frequently to manage effectively. Suggestions have included using themes or simply having a departmental prefix in the name to indicate the department that originally purchased the equipment.

OU's, Groups, & Group Policy

Questions

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

A: Here are the results from the initial workstation added to the WolfTech Domain:

   NCSU-Banned Software
   NCSU-Local Accounts Policy
   Domain-Domain Accounts Policy
   Domain-Software Update Services
   Default Domain Policy
   Default Domain Policy-XP/2003
   Domain-Allow RIS
   TEX-OU Policy

I'll need to do some exploring as to what these policies entail. At a minimum I know it enforces a Windows Update policy.

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?

A:

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:

Migration Schedule

Public Labs

We think our safest path of migration will be to start with our public labs followed by our teaching labs. The public labs include a student lounge, four computers in the atrium and three labs in the Textiles library. These systems are currently configured with the basic WolfPrep Windows XP unity setup. The primary considerations for the public labs include:

1. Ability for all Faculty/Staff/Students (students of various colleges) to login
2. Web browsing
3. Access to basic productivity software - Office, perhaps Adobe CS3 Products
4. Access to AFS space
5. Ability to print to WolfCopy managed printers

The public library labs are sometimes used by students to complete assignments that require the various applications that are delivered with the WolfPrep Unity setup like SAS, JMP, Mathlab, ArcGIS, etc. We probably need to continue to accommodate the majority of these applications in the public library labs. Sometimes professors request that course specific applications be deployed to the library labs so that students will have access to those applications outside of regular operating hours (Burlington Library Hours).

Teaching Labs

The teaching labs have the same considerations as the public labs with the following additional requirements:

1. Must host Textiles specific applications
2. Must be able to access ETF purchased disk space hosted at the COT
3. Access to licensing servers hosted at the COT

Many of the Textiles specific applications have been prepared for mass deployment via NDS environment using a Novell tool set. Some significant time will need to be invested to prepare the various Textiles applications for Group Policy deployment.