It's getting time to talk about what needs to happen for a clean and successful decommissioning of the Unity domain,  I'd like to start by identifying the stakeholders and calling them together to discuss their transistion needs and priorities.

Here's the services so far identified

The following table lists the attributes that are set on Active Directory user accounts in the "People" OU:

The purpose of this project is to consolidate the four OIT Active Directories into the WolfTech Active Directory. We need to move to this campus-managed AD environment in order to meet existing customer needs and position ourselves to securely deliver next-generation services at an enterprise scale. We will achieve this by combining and standardizing our services into a consistent focused environment, which will reduce confusion and costly duplication, while increasing flexibility.

Debbie's called an internal meeting this afternoon to setup some projects and get some timelines together for moving our various ADs to WolfTech

I figured I'd put out my project list to save some face to face time

Project: Migrate existing servers to WoldTech WSUS
Should just be a matter of mapping our "approval" models to the WolfTech ones, adjusting for any mismatches (eg does WT currently have a "all patches except for Office" profile needed by the Citrix boxen?) and set a timetable to implement.

I've just modified Unity.ad to hold the attributes uidNumber, gidNumber, and uid in the global catalog, using the info from http://support.microsoft.com/kb/248717

The "global catalog" is a partial replica of the account information needed to log in to the domain, used for performace so that users don't have to chase referrals when trying to login.

These particular attributes are used by Samba, in particular the 3.3 release that we're migrating towards, in identity management between the AD domain and the posix world.

I'm doing some cleanup in the UNITY domain, and am starting to collapse the "OU=Unity Computers" into OU=Organizations.

Towards this end, I've changed the container to hold unassigned workstations in Unity.ad (to OU=Computers,OU=Unassigned) and moved the existing machines into the new container.  I'm planning to leave the debris under OU=Unity Computers for a few days to make sure everything "took".

I've documented the steps to take to allow any domain user to register workstations in the domain at

http://xteams.oit.ncsu.edu/iso/node/131

The unity.ad domain was set up so that any authenticated user can "add a workstation to the domain"

Adding a workstation to the domain means that a computer account is created (a "service principal" in Kerberos-speak) which allows the domain controllers and workstations to authenticate each other and setup a secure cryptographic channel for private communications. The workstation can then accept policies, including those that set security settings, and allow logins for accounts held in the domain.

Your DNS domain can be configured so that your workstations will automatically locate the KMS service. This method is called "auto discovery". Client computers use DNS SRV records to automatically locate the KMS service. The SRV records need to be appended to your DNS domain configuration.

Question:

Do I need to configure my clients to use a special DNS server in order to participate in the unity.ad.ncsu.edu Active Directory?

Answer:

No. The usual campus DNS servers as delivered by DHCP are what you should use.

Question:

Can I use Dynamic DNS ?

Each organization that provides services in Unity.AD is assigned their own DFS namespace. This allows them to establish a logical filesystem layout that does not refer to server or cluster names. The organizational namespaces are linked together under \\unity.ad.ncsu.edu\dfs, so that all content is available from a single root namespace, or drive letter.

Namespaces are kept on file servers fs00 and fs03 in DC1 and DC2.