Unity Migration Blog

Here's some change management info:

I've granted the following rights to P:\Scripts and P:\Logs on scripts00, so that we can move off of the local D: drive:

itd.scripter: full control
itd_microsys_staff: full control
itd_microsys_unity_accounts: full control

I've moved the following scheduled jobs to refer to P: rather than D: (damn whoever decided that environment variables can't be used in scheduled tasks!)

AD Sync Report
Generate Web Pages
Generate_GPO_Settings_Report
GPO Report
GroupSync Remedy
oncallremind
Status-KMS

I have not changed the SCRIPTS_ROOT and LOG_ROOT environment variables, so as not to disrupt Andy unexpectedly. Scripts will continue to use the D: drive until these are directed to P:

Adding a file system

Issue: After creating user accounts, what are the consequences of using them but adding home directories and roaming profiles later?

Recommended course of action:
Wait for implementation of roaming profiles before having users log in. Ideally, wait for home directories as well.

Optional Plan:
For departments that plan to opt out of roaming profiles, have them configure loopback. Home directory space will come later but will be non-disruptive.

Departments that plan to use roaming profiles should wait. Adding roaming profiles to an existing user will cause a headache. While the user's existing profile would not be destroyed. The new domain profile would not have the user's data. The data would have to be copied by someone with rights to both the existing profile and the user's new roaming profile on the network.

Folks,

I had a chat with Barry on Friday regarding the types of tasks typically performed by his administrators, and we have a (short) list of default roles I plan to document and someday codify.

We were basically trying to ease adminstrator of three types of resources - containers, file systems, and printers.

In a new delegated OU, we would create a series of groups, and assign rights to those groups. The plan is to make it as easy as possible for folks to do routine tasks. The option to arbitrarily complex rights assignment is still available in MMC.

== Group OU_Supervisors
Membership would intially be the "Manager" associated with the organization's remedy group.

Members of this group would have the rights needed to add or remove members from any of the role/security groups. The Remedy Manager would be responsible for identifying who in their organization should control access, and place them in this group.

== Group OU_Full_Control
Membership would initially be null.

Members of this group would have full control, including create and delete object rights of the organization's AD container.

The Remedy Manager would populate this. Barry confirms that most folks who would manage AD would manage everything, but not likely delegate.

== Group GPO_Full_Control
Membership would initially be null.

Membershers of this group would have rights to create, modify, and assign Group Policy Objects. Since GPOs aren't stored in a shared container for the whole domain, it was desirable to have this seperate from GPO_Full_Control. Mistakes made with accounts in this group could potentially impact the entire campus.

The Remedy Manager would populate this.

== Group LockerName_Full_Control
== Group LockerName_ReadOnly
== Group LockerName_ReadWrite

Membership for all three groups would initially be null, and the Remedy Manager would populate them.

These groups would control basic access to a filesystem or "locker" Members of "ReadWrite" would have modify, read, write and create style access. The Full_Control group could also assign rights and take ownership. By default, no read access at all is set for new lockers. For "public" lockers, like App space, the "ReadOnly" group would need to include "Everybody"

== Group Printer_Operators

Membership would initially be null, and the Remedy Manager would populate this group.

Members can start and stop printers, see and hold the job queue, and basically control printers in the OU.

== Group Printer_Creators
With changes coming to the WolfPrint system, it may be possible to delegate the creation of new accounted printing printers directly. This group would control access if this proves viable.

The Help folder in the NAL is very cluttered and potentially not very helpful to end users. Some of the items are possibly outdated. Here are some suggestions about what to keep and kill. I'd like to do this tomorrow unless there are objections.

Things to get rid of in the "Help" folder:

KEEP:
- Change Password
- Check Profile Quota
- Help @ NC State
- Remedy 7.1
- Unity Print Quota
- Workstation Name

ADD:
- Quota Manager (shortcut to SysNews Quota Manager tool)

DELETE:
- Allow Users To Restart Novell Services
- Change AV parent to UNI05NT (forcerun)
- Check IMAP Quota (doesn't work)
- NAI Stinger (virus scanner)
- Novarg (MyDoom) Removal Tool
- PSInfo (PC Patch Info)
- SAS Fonts - refresh
- Sasser Removal Tool (Microsoft)
- Sasser Removal Tool (Symantec)
- Start Key Client

In the future, tools that aren't part of our standard set of Unity tools, like virus scanners, etc. would go in a subfolder called "Utilities".

I have also modified these apps:
- Matlab 2007a
- SAS JMP 7

And the corresponding old apps
- JMP6
- Matlab 2006a&b

I set the registry keys, associations and moved the app objects into .Apps.Users for the following apps:

- courseGenie
- GhostView
- Maple 11
- QuickTime 7.2
- Remedy 7.1
- Windows Media Player 11
- WinSCP 4.0.3
- TrueCrypt
- TightVNC
- Putty 0.60

Some apps had multiple app objects, all were touched. The corresponding old apps were marked with the registry requirement that Fall07 not exist. These apps are:
- courseGenie v21
- GhostView 4.7
- Maple10*
- Putty
- QT71*
- remedy 5.1.2*
- Windows Media Player 10 (associated with .computers.users)
- WinSCP 2.0
- gaim* (associated with .computers.users)

The "Application Testing" OU has been configured with some basic GPOs. These GPOs are linked to "Application Testing" and inheritance is blocked from above.

The goal for these GPOs is to establish a simple, consistent environment for anyone building or testing applications, without unnecessary customizations.

After thinking about the layout, I would like to make one change. Rather than have applications that are ready to be tested by others linked directly to "Application Testing", a separate child OU should be used named something like "Test Workstations". This allows people to work with their personal child OUs without inheriting other apps from "Application Testing".

This means that NO application GPOs should be linked to "Application Testing". When you're working on an app, link it to your own OU. When it's ready for testing by others, link it to the "Test Workstations" OU.

If you want to control which applications you receive, move your computer object to your personal OU and configure the OU accordingly. If you want to receive all of the applications available for testing, move your computer object to "Test Workstations".

This allows all workstations under "Application Testing" to receive the general test environment GPOs and only the applications they desire.

I've created a draft project overview document for the reviewer's guide, entitled "Project Overview" under "Unity AD Guide" in the documentation section. Comments appreciated.

Another beautiful theory, shot down by ugly fact.

I can't seem to associate software with computers as "published" -- it seems to want assigned or nothing.

So the plans just posted are pretty much as bust.

Shall we re-create the idea of an AppTesters group, so that we can publish applications to them?

For what it's worth, I've broken the PuTTY application while messing with this. Shouldn't impact you if you've already installed it to C:, but it's unavailable for installation while I try to figure out how to best proceed.

I've created OU's for each of us under the "Unity Computers/Application Testing" container.

OUs under "Unity Computers/Application Testing"

I have not set any permission or group policies on these OUs (well, I've started working on my own, but nobody else's).

Andy was going to review the GPOs assigned to Application Testing to set some minimum folder redirection and other necessary bits, but not try to deliver the entire look and feel, as this might impair testing.

The plan, as I understand it, is that we will create two GPOS to deliver each of the MSI based applications that we deliver. One will be "published" and one will be "assigned." Use the same naming convention used in the file system for an app, separated by dashes (eg "BMC Software-Remedy-7.1.01-Assigned")

A published application appears in add remove programs, and so can be optionally installed. Assign apps to be tested to the "Applications Testing" ou as PUBLISHED. We will use the assigned flavor to test the interaction of many assigned apps, but most folks want control of when things are installed during testing. If you need to test the assigned version, do it in your own OU

Use microsys list and cc Tom & Ed for now to communicate about app testing availability

We're still looking into details about 'categories' and don't have a best practice guide developed just yet. Making the containers and identifying the test container is just the first step.