I've migrated the volumes off of 22acn to clear a stuck Thunderbird lock file. I'm also rebooting it to clear some old connections that can't be manually cleared. I'll re-balance tonight.

I've migrated the volumes off of 22acn to clear a stuck Thunderbird lock file. I'm also rebooting it to clear some old connections that can't be manually cleared. I'll re-balance tonight.

I've reconfigured the exclusions of Symantec AV on UNI04NT and Scripts00 to hopefully not touch those files. I'll check on the other servers. Any SMS attached drives need to be included in the exclusion.

We are using the automatic quota feature so it knows when a directory is created or deleted under a directory it is set to manage. The service writes to files in "P:\System Volume Information\SRM" whenever a quota is set or unset.

Stopping the File Server Resource Manager service while performing bulk deletes caused the sluggish performance to improve substantially.

Any user who has used the password reset web page after 5/17/2006 has a synchronized AD password.

Any user account generated after 5/17/2006 has a synchronized AD password becuase the default Unity password combination is used when the accounts are generated.

This means that all Unity AD passwords should be known to the user. The password will either be determined by the user via the password reset web page or will be the default Unity combination.

Here are some statistics:

By looking at the pwdLastSet attribute on AD user entries, you can tell when the password was last set. This attribute will be set to whenever the account was created if the password was never reset. There were 76,157 total users in the "Unity Computers" OU of the Unity domain.

I am certain that the accounts with a pwdLastSet date of 5/17/2006 were random and the passwords have not been reset since the accounts were generated because all of the resets occurred between 11:00 AM and 2:00 PM, the time the accounts were all recreated:

------------------------------------------------
Password resets on 5/17/2006 by hour:

Hour: 11:00 (Total: 1714)
Hour: 12:00 (Total: 10423)
Hour: 13:00 (Total: 8097)

Total users found by hour: 20234
------------------------------------------------

20,234 of these users had pwdLastSet dates of 5/16/2006. This means that their passwords were random. Of these users, the ratio of disabled to enabled is approximately 2:1.

------------------------------------------------
Password resets on 5/17/2006 by account status:

Enabled users reset on 5/17/2006: 6599
Disabled users reset on 5/17/2006: 13635
Total users reset on 5/17/2006: 20234
------------------------------------------------

Total users found: 76157
Total users to reset: 20234
------------------------------------------------

The 20,234 users whose password was last reset on 5/17/2006 have had their passwords reset to the default Unity combination.

Novell's description of the "UNC Path Filter" setting:

Enables/disables the UNC Path Filter. Filters requests for UNC path resolution sent to the Client for Microsoft Networks (Microsoft Redirector). When enabled, UNC path queries sent to the Microsoft Redirector will first be filtered by the Novell Client to see if the server name is known by the Novell Client. If it is known, then a name resolve will not be attempted by the Microsoft Redirector. If the server name is not known, then the usual name resolution process will occur. This can dramatically increase the speed of network file operations and resource mappings.

This has happened to me on 2 different machines. Here's the configuration:

-Machine is a member of the UNITY domain.
-Novell Client is installed. The problem happened with both 4.91 SP3 and 4.01 SP4.
-UNC Path Filter is set to On.
-Drive is mapped to a DFS path.

Create a directory somewhere in DFS. Rename it. BSOD probably occurs.

The BSOD doesn't occur when using the same configuration but mapping to the underlying share path instead of to DFS.

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:

I've installed a clean windows machine on a VM, joined it to the domain, and then installed Client-32 v4.91SP4 plus the "491psp4_lgncxw32" patch to fix "contextless login prolems with Citrix" Under "advanced properties" I've unchecked "Initial Novell Login" so nwgina doesn't nuke msgina.dll.

Contextless login with LDAP is all configured.

Whrn "Login Without Novell's GINA" was "On" I didn't get either a dialog or a login when I authenticated as a domain user. I set it to "Off"
and still got no Novell login.

Tomorrow I'll try installing the optional "Identity Manager" C32 bits, and see if that helps.

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.

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.