Tech Support Section Home Mekong Network Home
About This Site...
Mekong.Net Sites...
Recently Updated...
Recommended Links...
Contact Us...
Questions? Comments? Requests? Click here to contact us.

Setting User Home Directories on an NT 4.0 Server

On a network it is typical to assign space private space for each user. Unfortunately, Windows NT does this in a somewhat awkward fashion.

Typically, we create users directories in a common location, at the time the user's account is created. The User Manager for Domains handles the fine points of this. For this example, let's pretend that my server is named Fileserver. Let's say that we put all of our user directories in \\fileserver\users. If I create a new user called MGorbachev, on the "Profile" screen I'll see a section for defining the home directory. If I want the "Home" drive to be mapped as H:, I can click the "Connect" radio button, select letter "H:" and type the actual path in the "To:" field: in this case, \\fileserver\users\mgorbachev.

Now, when I want to map Drive H in the logon script, I can use this syntax within the logon batch file:

net use h: /home

But this is where it gets ugly. On Windows 95 and 98, this does NOT map my H: drive to \\fileserver\users\mgorbachev. Instead, it maps H: to my "users" share. If I log in as mgorbachev, I don't just see the contents of the mgorbachev folder. Instead, I see the individual folders for ALL of my users: mgorbachev, nmandela, mthatcher. That's not a big problem; I don't have rights to access any of the other folders. If I try to open some of Mr. Mandela's files, I'll get a message saying that I don't have permission. The only folder I'll be able to get into is mgorbachev.

At first, this doesn't seem like a big problem. It's just not very elegant. And it is a (slight) security risk, since by seeing those folders, I'm probably also seeing a list of network login names. ("Oooh... look... there's a user named jcarter. Let's try the password 'peanut' and see if we can get in!")

There is a bigger problem here, however. By mapping to the higher-level share, I've made it harder to automatically access my own share: to do that, I'll need to define a variable in all of my scripts, and I'll need to assign that variable the appropriate username.

Let's look at an example of a situation where you might want to be able to automatically access a user's own directory. Suppose you have several salespeople who use laptops. You know that they are keeping critical files in their "My Documents" directories. Yes, yes, you've told them that they need to keep the files on the network, but they forget, or they don't know how to copy or move files, or whatever. Wouldn't it be nice to back up those files to the network each time they logged in? Sure, but we couldn't put them just anywhere. Thatcher's stuff has gotta go in her folder, Gorby's in his, and so on. Well, let's do this: when they log in to the network, let's copy new and changed files from their "c:\my documents" directory to their private folder on the H drive.

So, we can just have the logon script copy the files to "h:\%USERNAME%", right? Strictly speaking, you can, but that's harder than it sounds, mainly because variables are handled differently in NT/2000 and Windows 9x. A "username" variable doesn't exist by default in Win9x; there are batch files and other scripting languages that can be used to create it, but that's really a pain in the butt. (For what it's worth, Kixtart, at, is a popular approach, but I played with it for a while and ultimately went with a different approach.)

If we could just map H as \\fileserver\users\mgorbachev to begin with, we could dispense with all the crap about setting variables: our script could just copy the changed files from "My Documents" to "H:\Backups" or whatever.

The way around this is ugly, too, but in my opinion it is ultimately a better solution. My way is to manually create the user directories, make them hidden shares, designate them as the user directories, and reset the appropriate permissions.

The first step will be to create the user's directory. I'll store it in the same location as the other user directories, but I don't want that common location to be shared; instead, I'll be sharing each user directory individually. Since my new user is mgorbachev, I'll create a new folder called mgorbachev. Right-click on the icon for the mgorbachev folder in Explorer and choose "Properties" from the popup menu. Click the "Sharing" tab. Click the radio button saying "Share As", and then add a dollar sign to the end of the share name. (Appending a dollar sign on the end of a share name makes it an invisible share. That isn't essential, but it keeps things looking cleaner. There are, of course, still tools that will find these "hidden" shares, but I dislike letting everyone who opens \\fileserver in the Network Neighborhood see ALL the user directories.)

Now our share exists, but remember: By default, the share will give everyone FULL ACCESS!!! That is NOT what we want! In a few moments, we'll go back and reset the permissions so that only mgorbachev has rights to access that share.

Next, let's revisit the User Manager for Domains. On my user's "Profile" screen, I once again click the "Connect" radio button, select letter "H:" and type the path to my new share in the "To:" field: in this case, \\fileserver\mgorbachev$.

(If you've already restricted the permissions on this share, you'll get an error message saying something to the effect of "The Home Directory, \\fileserver\mgorbachev$, for mgorbachev, could not be created. The User Account has been updated. You must create the Home Directory manually." You can ignore the error.)

Now we're ready to go back to set permissions. To be thorough, we'll reset the permissions at two different levels: the directory permissions, and the share permissions. (I had a hard time understanding this at first: Permissions for a directory are NOT necessarily the same as permissions for a file share. A user might have full rights to a directory if he or she is working locally on the machine that hosts the share; but the same user might have no rights at all if attempting to access that same directory from the network.) You'll need to set the share permissions first.

In any case, setting the permissions is pretty straightforward. Go to the folder's properties page and click the "Sharing" tab, then hit the "Permissions..." button to set the share access permissions. By default, "Everyone" will have full access to the share. That's no good, so highlight "Everyone" and click the "Remove" button. Next, click the "Add" button. Select the appropriate server or domain and click the "Show Users" button. Select the correct user, and give that user Full Control.

Once you've set the share properties, click the "Security" tab. The procedure for resetting these permissions is similar to changing the share permissions: Click the "Permissions" button, remove "Everyone" from the list of users with Full Control, and assign Full Control priveleges to the user.

There one ugly thing here: if you remove "everyone" from the permissions and do not add the administrators group (or whatever user you are logged in as at the server) you'll be greeted with an error when you close the Properties page, saying "Unable to set attributes for mgorbachev." Never mind: it DOES set the permissions correctly. It's just that you're no longer allowed to see those permissions.

There is probably a way to script much of this process with the creative use of batch files and the ever-amazing "net" command. I'll let somebody else sort that out.

There are also probably several other ways to solve this problem. The easiest way? Ditch Windows 95 and Windows 98: the home directory behavior on other systems works the way it's supposed to, and this workaround shouldn't be necessary at all.