Windows NT Server has several limitations compared to other Network Operating Systems. Other systems such as Novell NetWare and Banyan Vines had the luxury of being
created from the ground up to be full featured in network utilities. Since Windows NT came from a workstation background, some compromises had to be made.
Login scripts and effectively mapping home directories are two things that are weak with Windows NT. Many solutions to this problem have been suggested, but none
I have seen have ever worked correctly as advertised. The solution that I propose has been tested and works in several different installations in many different
companies, and the results have been excellent.
Novell and Banyan allow the use of special commands for their logon scripts. Windows NT only allows normal programs, usually contained within batch files. A “Typical”
logon script is one such as below called LOGON.BAT:
The script above maps four drives and sets the workstation time to match the server. Simple, and generally effective. But does it do what we really want it to
do? Well, mostly it does. Except for the home directory line. It doesn’t actually map you to the home directory itself, but to the USERS share (Assuming its called
\\SERVER1\USERS.) So, in order to put a document in your personal directory, you don’t put the file in the P:\ drive, but you have to navigate down a level to your
personal directory. That is rather a pain to do every time you need to save a file.
But it is also more than that. When I set up Microsoft Office or any other applications, I will configure them to save data to the network. That is one of the major
reasons why you install a network. If you do these individually, you could set the default save directory to be P:\CAMBERG\DOCS, for example. If, on the other hand,
someone else needs to use my computer, when they go to save a document while logged on as themselves, errors occur, and you have to go out of your way to save the
information. And that is just with a program as forgiving as Microsoft Office is. Many other programs won’t do this, and simply not work. If you ever have to roll
out disk images on a large number of machines, now, you also have to change the default settings on each and every machine. It’s almost easier just to do a custom
install on each one. Or even using the Microsoft Systems Management Server to deliver applications to each machine, you now have to visit each one still; just to
make sure you set the right directory up for data. Suddenly the simple capability is no longer good enough.
So, our Holy Grail is to be able to map a drive that is the home directory itself. Since NET USE can only have an argument of \\SERVERNAME\SHARENAME, you can’t
just add on the user directory and have it map to the root. You can, however, share each user’s directory. Then you can do static mappings on each workstation and
they’ll have their dedicated drive. With this comes two problems. If you log on somewhere else, you’re drive won’t be the same one as on your machine. Also, when
you go through Network Neighborhood, you’ll see each and every user’s directory listed. If you have hundreds of users, this can get crowded rather quickly. A solution
to this is hidden shares. Now you could map on each user’s PC, but you still can’t share machines.
Lets say sharing machines is a higher priority than hiding the names of all the shares. There is a way to automatically map the home directory according to who
logs in. With a login script that has a line like below, it is possible:
Solves, the problem, right? Unless you’re using anything other than Windows NT Workstation, that is. Windows 95 does not understand the environmental variable
%USERNAME%. Remember that the /HOME command on NET USE only maps to the USER share, and drops you off in their directory. But its still not mapped as the root.
Other utilities are available that will allow this, but they’re rather a pain to use and set up. And you have to have different scripts usually for NT and Windows
95. I’d prefer something much simpler, where I don’t worry about detecting the different operating systems, and just use something that works with both.
A few years ago an enterprising man named Ruud Van Velsen of Microsoft Benelux created a new program. He realized the limitations of the Windows NT logins.
KiXtart is a utility that is really a rather sophisticated scripting language that matches the capabilities of the NetWare
and Banyan login scripting. The capabilities of this program are amazing. You can even have it change registry settings on client machines. The best reason for
using this is that it gives the same capabilities to both Windows 95 and Windows NT Workstation.
SECTION 1 concerns setting up the display for the users (See Figure 1.) It designs a nice looking grid background. This through SECTION 3 is from the default script that comes with KiXtart. SECTION 2 creates an informational display within the box created by SECTION 1. SECTION 3 uses the environmental variables used within KiXtart to display the user ID, name, rights, etc.
|
FIGURE A |
SECTION 4 is where the “magic” happens. To prepare for this, as an administrator, you need to do a few things for each user you create. First, you’ll need the rights
to change the properties of their home directory, namely to be able to share the directory. After you create a user and assign a home directory, the User Manager
for Domains will create the directory and only give the user full control. If you attempt to share the folder, you won’t be able to since you don’t have access.
Most administrators want full control over the users’ directories anyway. To do this, the CACLS utility in a batch file comes in handy:
That section will determine if the login ID is a member of the Administrators group. If so, it will do anything before the ENDIF statement, in this case, map
a few extra drive mappings.
Another way to do things according to user groups is as follows. Let’s say you have the Accounting group that has a certain drive for the tax software.
