ScriptLogic In Production – Part Two

One of the many problems facing Network Administrators of a medium to large Windows NT 4.0 network is managing multiple
and complex logon scripts. Fortunately, ScriptLogic

makes this much easier.  In Part Two of this article, I’m going to
cover the group setup in more detail as well as utilizing
the custom scripting functionality of ScriptLogic.

BACKGROUND:

One of the many problems facing Network Administrators of a medium to large Windows NT 4.0 network is managing multiple and complex logon scripts. Fortunately, ScriptLogic makes this much easier.

In Part One of
this article, I covered some of the
basics of using ScriptLogic Professional 3.0 on your network and how it has helped us to solve the problem
of managing multiple and complex logon scripts. I discussed how we use ScriptLogic
to push out InoculateIT AntiVirus updates to our users so that the update only runs
once per day when the users first login.  I also discussed some of the drive mapping techniques
that are presently in place and how ScriptLogic validation logic makes the drive
mappings much easier to deal with than our existing logon scripts.

GROUP SETUP:

ScriptLogic makes drive mappings extremely
versatile.  Based upon the validation logic, the customization that the
application offers is virtually endless.

ScriptLogic gives the capability to map a drive based off of any of the settings listed above. 
The primary validation logic that we utilize the most, is Group Membership.  But
before we could truly implement group membership validation logic, we obviously had
to have our users setup into logical groups that corresponded with how our
business operates.  In our environment, we have four locations on the WAN
running on a Windows NT 4.0 network  Although we have four physical
locations, we only have Windows NT server running in three physical
locations.  The fourth location does not have a server at their physical
site.  They log into Site A via a WAN link, so far our purposes here we
have three physical locations.

• Brandon
• Corporate
• Spruce

We use a simple group naming convention where group names
begin with either GG_ or LG_.  This
allows us to easily and rapidly determine if a group is a
global group or a local group.

We have groups setup that correspond to each physical location and is for the users
that are physically located at that location.  So, we have GG_AtBrandon, GG_AtCorporate and GG_AtSpruce global groups.  In addition, we have groups setup
that correspond to each physical location and is for users that only need to
map a drive to that location.   These users are not physically
located at that location.  So, we also have GG_MapBrandon, GG_MapCorporate and GG_MapSpruce global
groups.

The primary reason that we have the GG_At global groups, is to make it easier to map the G: drive to user home directories and to make
the H: drive to the shared folder of the user’s home server.  In addition, having the GG_Map allows us to map drives across the WAN in a much easier fashion. 

Utilizing the groups shown above gives us a quick and easy means of modifying
user groups when users move from location to location (permanently). 

CUSTOM SCRIPTING:

One of the nicest features of ScriptLogic Professional 3.0 is the capability
to run what are called custom scripts.  Custom scripts are simply KiXtart
scripts that you have ScriptLogic run for you.  The scripts can run either
before the main ScriptLogic user script or after the user script.

Because ScriptLogic is simply a front-end interface for KiXtart, many of the
same scripts that you can find on the Net can be easily implemented to use with
ScriptLogic. KiXtart was designed and developed by Ruud van Velsen of Microsoft
Benelux.  More information relating to KiXtart can be found at www.kixtart.org.

Ryan Smith