If you want to modify the sample scripts in "KiXtart User Logons" or you’re ready to write your own KiXtart scripts, keep these five tips in mind. These suggestions will increase the efficiency of your scripts and simplify troubleshooting.
- Use the default script kixtart.kix as the starting point for all scripts. I see many examples in which user profiles define different scripts based on user group, but this approach complicates the environment. You can call scripts from the initial kixtart.kix script, based on UserID, group affiliation, which server authenticated the user, or virtually any other criteria, so adhering to this rule will greatly simplify your scripting environment. That way, you never need to wonder what the initial script is for a given user—the data will tell the script what to do.
- Define variables at the top of the script in which you plan to use them. Define variables that you plan to use throughout all scripts in the initial kixtart.kix script; define variables that you’ll use within only one script in that script only. This habit greatly simplifies debugging your scripts.
- Use variables to pass data to functions. At times, this approach might seem to create extra work. For example, the sample code in "KiXtart User Logons" uses the SUBSTR() function to return the location code as specified in the @PRIMARYGROUP macro. Although I could have accomplished this action through one line of code:
- To prevent scripts from taking a long time to run or failing to run (and to ease user frustration), test for the existence of the data resource you want to attach to before you run the Use server\resource command. KiXtart provides the EXIST() function to test for the existence of files. Both Web Listing 1 and Web Listing 2 (http://www.winscriptingsolutions.com, InstantDoc ID xxxxx) in "KiXtart User Logons" contain examples of this function. To test for the existence of network shares, use the following syntax:
- Keep your users informed. KiXtart’s power is that you can kick off complex routines, application installations, or configuration changes without visiting user desktops. However, when you’re going to make a major change (e.g., add an icon, install an application, add an important drive letter) let your users know. You can use KiXtart’s MESSAGEBOX() function to notify users of any changes. Here’s an extra hint: Use the CHR(13) function to append a line return to your message text.
$loccode = SubStr(@PRIMARYGROUP,2,3)
Instead I used two lines of code:
$pgroup = @PRIMARYGROUP $loccode = SubStr($pgroup,2,3)
Although this approach might seem like extra work, using these variables simplifies debugging because I can use dummy macro variables to test scripts on a standalone or local system. For example, consider the following code
$pgroup = "_CHI_Execs" ; Set using @PRIMARYGROUP. $loccode = Substr($pgroup)
The group _CHI_Execs doesn’t need to exist to test the script, and I don’t need to place any users in that group to test the script’s accuracy. When the script works correctly using the dummied variables, I can simply remove the comments, leaving the @PRIMARYGROUP macro to return its value as needed.
If Exist("\\servername\share")
