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

Questions

Q: How will we help the students with the transition from a Unity Lab environment to an AD Lab environment? In the unity environment a student's profile settings follow them from lab to lab. Additionally files saved on unity systems are copied to their AFS space (K: drive) on logout. In an AD lab will we offer the same/similar functionality? If so how will we accomplish this task?

A:

Q: What sort of privileges will we grant user accounts in the public/conference room/teaching labs?

A: I'm (Ryan) leaning towards power user like privileges in the teaching labs as many of the Textiles applications require that level of access to operate properly. Assuming I go that route I'm expecting that re-imaging will take place more often (higher privileges = more opportunity to break the computer) than in a reduced privilege environment so I need to have the re-imaging process down to close to zero touch. The problem there is that some Textile applications require a somewhat involved licenses re-activation (generate a new GUID, email vendor, get back a product key, apply etc.) process.

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 populated (May 08) the WolfTech 'People' OU with the unity ID's of Textiles faculty, staff, & students. In order to login to the WolfTech domain users will need to perform a password reset. They can 'reset' their password to the same password to induce the synchronization. This can be done here: Password Change Tool

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

Our current naming scheme includes the room number however, we have found that this changes too frequently to manage effectively.

Desktops/Laptops Naming Scheme:

• Computer names will be in lowercase - this includes QIP entries
• A 'tex-' prefix will be used. This will help us to avoid naming conflicts with other WolfTech resources.
• A theme name will follow the 'tex-' prefix

So for example the following computer names may be used for a public lab:

   tex-achilles
   tex-belus
   tex-canopus
   tex-argus
   tex-acrisius

Server Naming Scheme:

• Computer names will be in lowercase - this includes QIP entries
• Initial theme will be countries (holland, sweden, norway, etc.)
• ...

VM Naming Scheme:

• Computer names will be in lowercase - this includes QIP entries
• ...

Account Creation

Collecting GUID's

Along with Kris Tesh (student help) Ryan Leap has been developing a vbs script that will collect GUID's from all the Unity Lab computers we have here at the College.

Managed Computer Accounts

We will use scripting (ADSI) and the collected GUID's to pre-populate to computer accounts in WolfTech AD into the appropriate OU's and appropriate software distribution groups.

RIS Server

At present, we do not have a RIS server or an associated DHCP template in QIP to direct clients to a WolfTech RIS server. CNR allowed us to use their DHCP Template 'CNR-PXE-PC' to access their RIS server.

Request for Mike Freeman: Could you pursue creating a WolfTech RIS Server for the COT w/DHCP template or formalize an alliance with another member college? For the labs in the fall I'd like a Windows XP SP3 no RAID image. Also, Mark Haven told me he is ordering RAIDed (mirrored) systems for this year's ETF purchase so a RAID-enabled image will eventually be needed as well.

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. 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
4. There is some concern about roaming profiles. We don't intend to use them but that is a benefit with the Unity environment that our users are currently accustomed to...

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.

Conference Room Computer

Like the public labs, users should have access to productivity software - Office - PowerPoint in particular as these rooms are primarily used to give presentations. Faculty & Staff who login expect to have access to the public folder (P: drive) their home folder (H: drive) which are hosted on a COT managed file server. It would behoove us to develop a fairly locked down security policy for these systems as they should only be used for presentation related purposes.

Transitional Considerations

Questions/Considerations

• We formally requested a trust between the TX domain and the WOLFTECH domain on 6/17/08. We need a one way trust so that WolfTech users can access TX domain server resources. Dan Green provided the necessary trust prior to the start of the fall 08 semester

Miscellaneous

MDB

MDB is a hardware/software inventory tool used within the WolfTech domain. We will be meeting with Brian Carty for a demo as we most likely want to integrate the use of this tool into our processes.