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.
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.
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.
We use a simple group naming convention where group names begin with either GG_<groupname> or LG_<groupname>. 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<Site Name> 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<Site Name> 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).
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.