Advanced Functions with Windows NT Login Scripts

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:

@ECHO OFF

NET USE M: \\SERVER1\APPS

NET USE N: \\SERVER1\PUBLIC

NET USE O: \\SERVER1\GROUPS

NET USE P: /HOME

NET TIME \\SERVER1 /SET /YES

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:

NET USE P: \\SERVER1\%USERNAME%

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.

CLS ; SECTION 1

SMALL

COLOR b+/n

BOX (0,0,24,79,GRID)

COLOR b/n

BOX (8,21,18,61,Å)

COLOR g+/n

BOX (7,20,17,60,FULL)

COLOR w+/n ; SECTION 2

AT ( 9,25) “UserID :”

AT (10,25) “Full name :”

AT (11,25) “Privilege :”

AT (12,25) “Workstation :”

AT (13,25) “Domain :”

AT (14,25) “Logon Server :”

COLOR y+/n

AT (9,40) @userid ; SECTION 3

AT (10,40) @fullname

AT (11,40) @priv

AT (12,40) @wksta

AT (13,40) @domain

AT (14,40) @lserver

COLOR w/n

$userdir=@userid + “$$” ; SECTION 4

USE M: “\\SERVER1\APPS”

USE N: “\\SERVER1\PUBLIC”

USE O: “\\SERVER1\GROUPS”

USE P: “\\SERVER1\$userdir”

SETTIME “\\SERVER1”

SLEEP 4

EXIT

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

Provides a nice display for each user account.

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:

@ECHO OFF

CACLS \\SERVER1\USERS\*.* /E /G ADMINISTRATORS:F

This will grant the Local Administrators group full control over all the home directories. After adding a bunch of users, I will run this batch file, then just go in through Explorer and share each home directory as a hidden share. Back in the logon script, the first line in SECTION 4 creates a variable called $userdir. I take the user ID, and add the $. For example, I previously shared the \\SERVER1\USERS\CAMBERG directory as CAMBERG$, a hidden share. $userdir takes CAMBERG, my user ID, adds the $ to the end of it, ending up with CAMBERG$. (The double “$$” is because anything preceded by a $ in KiXtart is treated as a variable, and $$ makes it use the actual $.)

Next, a few drives are mapped, just like before using the batch files and net use. Finally, we map the users home directory. You don’t have hundreds of user shares available for viewing in Network Neighborhood, and everyone’s home directory is mapped as a root drive. We are finally up to the level of scripting that other operating systems have. The time is set using the SETTIME command, the SLEEP is a pause so users can look at the information screen set up in SECTIONS 1-3.

With KiXtart, many more capabilities are added. Lets add a section after the standard mappings to give administrators special drive mappings. After the last mapping command, add the following section:

IF @PRIV=”ADMIN”

USE Q: “\\SERVER1\USERS”

USE R: “\\SERVER1\CLIENTS”

USE S: “\\SERVER1\C$$”

USE T: “\\SERVER1\D$$”

ENDIF

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.

IF INGROUP(“Accounting”)

USE T: “\\SERVER1\TAXSOFT”

ENDIF

Of course, this works another way. Lets say you don’t want temp workers to have access to the main public share. Easy with access permissions, but, you don’t even want them to see the drive itself.

IF INGROUP(“Temps”) = 0

USE N: “\\SERVER1\PUBLIC”

ENDIF

That section says that if the user is NOT a member of Temps, to go ahead and map the drive. Of course, OR and AND and other Boolean operators are allowed.

The capabilities of this great utility go on. You can even set registry entries if necessary. KiXtart comes with the Windows NT 4.0 Resource Kit if you want to use it. The script that I used above was modified from the DEFAULT.SCR script that came with the distribution. Read the documentation that comes with the program for more tips on its use. So if you are coming from a Novell installation with a two hundred line script, you should be able to recreate most of your functionality in a new NT network.