I've added significant rights to the OIT role for this site, which is fed from the "OIT People" application.  Basically, I'm granting everyone in OIT the same rights that we used to have only for ISO staff, meaning personal blogs, forum creation, book editing, and overall content creation rights.

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. 

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.

Be careful what you wish for!

E-mail notifications have been added to this site, as some folks were missing them from our earlier blogs/drupal sites.  You'll see a link for "subscriptions" at the bottom of most content.

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.