Here's a long description of how the rights are established for the software groups in OIT's portion of the WolfTech active directory.  It's long and in narrative style, in hopes it will illustrate the thought processes that yielded this configuration.

Two facts one should know

• Computers objects can be members of AD groups
• Group objects can be members of AD groups

In WolfTech, to assign an application to be installed on a machine, you just add that machine to a specially named group. 

Kevin and I met with TSS to finalize our plans to create a better OU structure for OIT.

Workstations and other computers will be gathered up under an OU=Computers directly under OU=OIT

Kevin

Clients that TSS supports will get sub-containers under "Clients"

The "Test" OU will be used for application/gpo testing

I met with Bill Coker and we're going to try to get a software distribution share to deliver ISOs to on-campus administrators.  Products like SAS are up to 3 DVD's of install media, and with the double layer ISOs it's hard to deliver without a good old fashioned network share.

I'm clearing up space on the oitfs0 Celerra share, which we'll link in under the path

\\wolftech.ad.ncsu.edu\oit\Original_Media

I'm meeting with Bill again today or tomorrow to branstorm how he wants to manage rights -- I'll introduce hi to the automatically created groups in WT.

OIT-ISO-SHS and have made a change at the OU=OIT level that should make things less complicated for all our various OU admins.

I've packaged the 32 and 64 bit ActivePerl distributions for Windows, version 5.10.1.1006.

To have it installed via GPO from the WolfTech domain, add the computer or groups of computers to the group FW-OIT-ActivePerl-5.10.1.1006, which you'll find in OIT/Software Packages/OIT Software

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

In working with group policies, I've run into some frustrating test conditions where the policies I set just weren't getting set on the target computers.

Checking into the event log, the issue appears to be that the clock on my vmware machine was too far out of sync with the time on the WolfTech domain controllers for a session to be established, and so the workstation service principal couldn't log in and get the list of gpo's it should apply.

I'm working to clean up and standardize our OU=OIT in the WolfTech active directory.

I've created under "Management Objects" a "People Groups" container, for holding groups representing teams or other assemblies of humans or human analogs.

Present: John K, Kevin S. Patrick W. Tom F., Dan E. Danny D

We got a small group together to advise management on how to best consolidate the many OU's that OIT is creating in WolfTech.  There's more background at

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

The results of the meeting were

Attending: Dan G, Billy B., Kevin S. John K, Mark S., Mike McC, Craig DeS, Jack F and Richard M.

Continuation of previous meeting in July in which we discussed using Wolftech to replace etssauth servers and Sun IDM integration.

Craig gave an overview of how the portal et al currently used the Auth Tree eDir, and it's requirements.  We discussed how AD password policies differ, and covered some workflows about what would happen if one's basic access to one's desktop was controlled by the P1..P5 security policies.