I do all of my drive and printer maps in the KiXtart script. My initial script is a .cmd file, but it calls the KiXtart
script. You can put the KIX32.EXE executable on your NETLOGON share, or copy it to each workstation. I created an installer to install it on each of our workstations and pushed that with SCCM, but I also have it on the NETLOGON share just in case. This is my logon.cmd:
IF EXIST %SystemRoot%\KIX32.EXE GOTO local
ECHO Running from local drive...
REM %SystemRoot%\KIX32.EXE /f
ECHO Running from NETLOGON
REM %0\..\KIX32.EXE /f
The Bad ThingTM
about using a .bat file is that your drive maps are now persistent, unless you specified /PERSISTENT:NO on the NET USE command line. You can, however, have KiXtart remove those if you want.
Here is an example code snippet of mapping a drive with KiXtart based on membership of a domain group called "GroupName":
Use X: "\\SERVER\Share"
We have a departmental share where users are mapped directly to their departmental folder on the primary share (access to the subfolders is controlled through NTFS permissions). Instead of having a bunch of If InGroup
statements you could use Select Case
statements. This is a bit faster because it stops evaluating everything after the first true Case
Use X: "\\SERVER\Share\SubFolder1"
Use X: "\\SERVER\Share\SubFolder2"
For printer mapping, it supports a full set of commands for adding, deleting, and setting a default printer. You can add multiple printers without making any of them a default, though. We don't have any direct attached printers so we map everything from the logon script and set the default printer.
Now there's no error checking in any of that code. It could be added and display a message on whether the drive or printer map is successful or not. There's tons more that can be done...read/set/delete registry values, read WMI, read/write text files, shell to executables to run other commands not native to KiXtart, etc. If you REALLY want to get fancy you can even read from or write to a SQL database! Just keep in mind that by default the script runs in the user context of the person logging on so you're limited to what access levels they have.