Unity Migration Blog

The sluggishness experienced while deleting a large number of profile and home directory folders on FS03 was due to the File Server Resource Manager. This is the service that maintains and keeps track of the quotas.

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.

Hey folks,

I'd like to reawaken our discussion of Windows Share +/- NTFS file permissions for Friday's pilot meeting.

I won't duplicate the old blog post with a repeat of the background info, but would appreciate it if you'd review it before Friday's meeting so we could discuss our "best practice" stance.

Some Microsoft documentation is suggesting different practices, see http://microsys.unity.ncsu.edu/blog/index.php?title=gpo_creation_problem_solved&more=1&c=1&tb=1&pb=1 for context.

While working on deploying applications I came across a problem with how the permissions on our home and profile directory permissions were set.

Users had list perms to the root of Home and Profile. As a result, they could see the a-z directories contained within. Users did not have perms to list the contents of the directories under a-z. This was by design. I didn't want to give users an easy way to get a listing of every Unity ID.

This causes problems with application deployment because "My Documents" is redirected to the users home directory. When trying to install a published application, I would receive an error saying something to the effect of:

Access denied to: \\unity\itd\home\a

I had permissions to list the contents of Home and arkurth, but not to the "a" directory. Many MSI application installers use "My Documents" in some way or another. They seem to need permission to list all of the directories that make up the path to where "My Documents" is redirected. If this fails, the MSI installation fails. I have seen this with the old environment which redirected "My Documents" to K:. If the K: drive wasn't mapped, MSI installations would fail.

So, I needed to grant Domain Users list permissions to all of the a-z directories. The side effect of this is that they could now enumerate all of the other users' directory names.

Access-based Enumeration solved this problem. I have enabled Access-based Enumeration for the "Home" and "Profile" shares on FS03. There isn't much to configure - it's either off or on for a particular share. For shared directories, there is a tab under the directory properties:

The Home and Profile shares currently reside at the root of their respective volumes and there is no Access-based Enumeration tab under volume properties:

This doesn't mean that you can't enable Access-based Enumeration. The abecmd utility can be used. The following commands were executed on FS03:

abecmd /enable /Home
abecmd /enable /Profile

The end result is that I can traverse all of the directories making up the path:
\\unity\itd\home\a\arkurth

When I view the a-z directories, I only directories that I have permission to view even though I have list permission on the "a" directory:

For the packages that aren't from a traditional vendor, what if we named the folder under applications based on the primary web site for the project?

For example, the "TrueCrypt" software that the folks in the Security group have requested could live under "truecrypt.org\TrueCrypt 4.3a" This would allow us to keep our namespace "flatter" (we'll have thousands of entries under "NoVendor/Free/Sourceforge/Whatever in the limit) and still organize multiple versions/platforms.

Nays/yays?

So according to microsoft, Vista and XP can interoperate happily using roaming profiles:

http://download.microsoft.com/download/3/b/a/3ba6d659-6e39-4cd7-b3a2-9c96482f5353/Managing%20Roaming%20User%20Data%20Deployment%20Guide.doc

One needs to be sure to install the Vista plugins to manage folder redirection, and not use any earlier versions.

There is a good user created comparison of the profile implementations at http://www.digitalinsane.com/archives/2006/10/14/vista_profiles_folders/

We'll want to tweak the (*&#$!@ out of several of Vista's default behavoirs. Moving the recyle bin off of the local system and into the user's roaming profile doesn't exactly seem like a step forward, to me!

We were also interested in if we could use environment variable expansions in the AD attribute holding the profile path. Well, even if we could (I haven't checked) MS provides no environmental variable to tell you which Windws family member is being used. It's all "Windows_NT" . :-( :-(

There is a third party product that claims to eliminate MS roaming profiles, while still providing the experience: http://www.scriptlogic.com/products/desktopauthority/

I'd strongly suggest MICROSYS folks take the time to read the MS whitepaper, so we can discuss our options.

We're starting to flesh out some of the docs regarding how our AD is going to "look" and what folks can expect to find where.

Here's a very ugly and rough start attempting to show the 1:1 relationship between support organizations, remedy groups, and the dfs namespace.

Boring draft image showing that under OU=Organizations in AD there is a 1:1 correspondance to Remedy workgroups

Boring diagram of how the layout of DFS will also correspond to Remedy workgroups

If we map S: to \\unity.ad.ncsu.edu\dfs, it will result in pleasant, short paths like S:\CALS\ZO . It should be clear whose stuff is whose. Groups like CALS and ITECS can easily support other groups in their areas, and the namespace keeps their clients organized. Groups like BAE, that shouldn't get grouped under either ITECS or CALS, will be able to have their own identity, not under anyone's heirarchy, when and where appropriate.

We think there may be folks who do desire a shared locker from us, but who don't want to include a support unit as a middleman. We're undecided how to best handle such a thing, so for a while we're going to show a sort of catch all "OtherSupport" container in our diagrams. We may decide that we can't afford to have "unsupported" groups or individuals, and send them to Distributed Support or our Helpdesk for some sort of help contract, the cost of which could be rolled into the rental price of the space.

We've got some plans for making administration of "locker" space as easy as possible by pre-creating some access groups at locker creation time, but I don't have those docs ready yet.

Folks,

In working with WebDAV, it worked out to be somewhat of a problem to have the pretty php generated index files. I've moved the fancy indexing so that it only takes effect on /documentation and /internal-documentation. Other dirs will get the standard apache indexing.

Right now, I have the permissions set so that http://microsys.unity.ncsu.edu/dfs is forbidden to all, so we don't let anything out we shouldn't. My plan is to secure this dir with "allow valid-user" so that we can provide file downloads (like the mmc plugins). I can't wait to set up some authorizations based on Remedy workgroup membership. :-)

Anyway, hopefully we'll have secure (https://) authenticated access that works with Dreamweaver up shortly.

We are in the process of figuring out the best way to configure AFS access on workstations in the new environment. Some questions arose about user home directory paths and where the best place to get this information would be in the future. Hesiod had been used to lookup the home directory, but the data is also in:

-Sybase hes_db database, select fsdir from userinfo (authoritative... I think)
-Sybase xfer_db database, select fsdir from ldap_data (derived from userinfo... I think)
-ldap.ncsu.edu, homeDirectory attribute (derived from ldap_data table... I think)

We could try to look it up from one of these places, populate an attribute in AD with the AFS home directory, or possibly just assemble the path if they all were in the Unity cell. We didn't know how many had been transitioned out of EOS. I ran a script to examine the fsdir paths in userinfo and here are the results:

Total users: 91,993
Users with unity fsdir: 91,658 (/afs/unity.ncsu.edu/users/x/xuser)
Users with eos fsdir: 335 (/afs/eos.ncsu.edu/users/x/xuser)
Users with other fsdir: 0

So there are some users still in the EOS cell and we cannot assemble the path. We could easily populate an AD attribute with the AFS home directory if necessary. UserSharedFolder may be one we can use.

In case you're curious, here's a breakdown of the number of user accounts we have by letter:
j 12613
m 8316
a 8138
s 7268
c 7202
t 5845
k 5590
d 5295
r 5067
b 4435
l 4306
e 3524
p 2324
w 2193
n 2137
g 1886
h 1806
v 964
f 734
i 620
y 582
z 465
o 318
x 167
q 131
u 67

New home directories have been created for all Unity users. These directories are intended to be used as the user's see fit. They will NOT be used for roaming profile data. We intend to enhance and grow the home directories in the future to provide larger amounts of space that is easily available on Windows computes (and others). The home directories reside under \\unity.ad.ncsu.edu\itd\home in directories named a-z. The a-z directories are actually DFS links. This way, the actual directories for the different letters can be volumes which can be moved to different servers for load balancing. The directories currently all reside on 1 volume - \\fs03\home. This will eventually change. Users have Modify permissions on their own directory. Users do not have permissions to list directories under a-z. The user's home directory will be mapped to U: in the new environment.

Some departments may choose to use roaming profiles in the new Active Directory environment. We do not want profile data (mainly the user part of the registry) to be included in users' home direcctories. As a result, profile directories have also been created for all Unity users in the same manner that the home directories are created. The profile directories are not currently linked in DFS because we don't want to make this space obviously available to the users.

Automatic directory quotas have been set for a-z for both home and profile directories. Home directories have a default quota of 100 MB. Profile directories have a default quota of 50 MB. Patrick posted some information about directory quotas here:

http://microsys.unity.ncsu.edu/blog/index.php?title=about_quotas&more=1&c=1&tb=1&pb=1

Read up on directory quotas if you are not familiar with this new feature of Windows Server 2003 R2. There is some good information on Microsoft's site.

I am reworking the permissions in DFS to align with the guidelines described here:

http://microsys.unity.ncsu.edu/documentation/ITD-Active-Directory-Environment/Groups-Permissions.php

Microsys staff should have the access they had before but you may need to logout and then log back in because group membership changed.

Permissions are only assigned to some new domain local groups. Global groups were made members of the local groups.