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.

The first two groups created are "OIT-ISO-SHS-Windows-Action-League-Users" and  "OIT-ISO-SHS-Windows-Action-League-Admins" containing the Windows team normal Unity accounts, and special "dot admin" accounts, respectively.  We need groups to ID these folks because there is no org chart difference we can use to automatically provision such things.

I've put the "OIT-ISO-SHS-Windows-Action-League-Admins" group into the OIT-OU-Admins group rather than the individual accounts, so that we can keep out identity groups seperate form our security groups.  If someone ceases to be a member of the Action League and is removed from the one group, they will automatically lose access to all the things that were assigned to them as a result of their group membership.

In the OIT "Servers" container, I've created an admin group for each subcontainer representing a server  configuration, and assigned the appropriate rights.

Each of these admin groups (named as OIT-Servers-ServerTag-Admins, eg OIT-Servers-SCRIPT-Admins) is collected up into OIT-Server-Admins, a group to contain every administrator of any OIT server.

On the assumption that if you're managing a Windows server for OIT, you might be useful in a disaster situation even outside of your own little OU, I've granted remote console and restart computer rights to all OIT servers to the OIT-Server-Admins group.  This is NOT administrator rights.  Anyone with machine room access can walk up and power cycle your server or play with it's console, so these rights match what people already physically have access.

The plan is of course to have some sort of PCI ou where none of these happy helpful permissions are granted.  Since PCI is such a small percentage of our total server count, it gets to be the exception to the rule, rather than set the rules.

The GPOs have not yet been tested for this, but there are two groups to contain servers, OIT-Servers-WSUS-Early and OIT-Servers-WSUS-Late that will tag a server as either "early" (gets updates as soon as they are available) or "late" (delay updates as long as possible).  The default policy for the servers container is to allow the local admin to decide when updates are applied -- we assume that we'll be doing updates with some sort of "put it in maintaince mode and do an orderly restart" script in most if not all cases. Of course, if someone needs GPOs on their servers' containers, thats easy too.

I'd like to have a group get-together to go over the default policies applied at OU=Servers, and decide if they're appropriate and if any are missing.  Looks like it will be next week at the earliest.