OK - now for the nits...

Use of "?" - this is a shorcut for @CRLF, or a NewLine, which should generally be placed at the END of the line of text. It is not (as in BASIC) a shortcut for a PRINT statement. Even more important is consistency - some messages have "?" in front while others have it at the end.

Variable Declarations - These are very important, and all vars should be declared, including those in functions. Some simple projects allow declaring all your vars on a single DIM line, separated by commas. As a project gets more advanced, you'd be much better served by declaring each var or var set on a single Dim line, with a comment that describes their use. When I refer to a "var set", it usually means similar vars, such as:
Dim $I, $J, $K ; index pointers
Dim $aComputers, $Computer ; Array of computers, loop enumerator

If you download my KGen tool, you'd see the result of a sanity check, which would issue dozens of warnings about variables.. It would also generate a report of which vars are declared/used where, which is useful in troubleshooting larger projects.

Use of double quotes - Since most DOS commands require double quotes, I perfer to use single quotes within Kix. This simplifies calling external apps. More than anything - be consistent!

Comments - a good start, but more is better, especially when you're sharing your code. YOU may know why you did something a certain way, but others won't. Further, will you remember why you did things that way 6 months from now? Maybe with heavy doses of Ginko-Biloba! ;\)

Debugging - Instead of commenting out critical but high-impact pieces of code, use a global $DEBUG variable. Then, you can do something like:
$Cmd = 'bmail -s ' + $EmailServer + ' -t ' $IT_Email
If $DEBUG
'DEBUG: -identifier-: Shell' $Cmd
Else
Shell $Cmd
; do error check!!!
EndIf

Command strings - should be built using a $Cmd var, which lets you easily display or run a command, as shown by the debug process above. The process in your script has variables in the string, which is a bad idea. Here's an example of how command vars are built
$Cmd = '%COMSPEC% /c ' ; define the command shell
$Cmd = $Cmd + 'bmail.exe ' ; command to run
$Cmd = $Cmd + '-s ' + $EmailSever + ' ' ; add the mailserver arg
and so on... This is much easier to check for missing quotes, too.

Ramifications of Explicit option are that variables that default to GLOBAL will need to either be declared as global (messy) or passed to functions (need careful review) to work properly. $UsersToSkip and the CheckUsers function are one example of this, although several functions seem to rely on global vars.

Eliminate repetetive definitions - Instead of defining the complete path in the Include statements (which can't process vars), define the path once and use the Call statement instead. Call runs after the script initializes and can take advantage of variable references. If you use KGen, it will resolve the dependencies automatically and include those functions in the final script, eliminating the need to make the library available on the network and making the finished script more portable.

Use of customized data - While keeping all user/site specific data in one place in vars is good, the next step would be to place it outside of the script entirely using a config file. Kix has powerful INI read/write capabilities that you could leverage. You could even write it in such a way that if the config file was empty or not found, you could prompt the user to update it on the spot. Might even ask if a predefined config was available on the network? Several ways this could go, really.

Well, I suppose that's enough for now. If this were presented in my class, you'd score high for concept and thought. The points I've outlined will make the tool more portable, reliable, and supportable - better suited for an enterprise helpdesk environment.

I'll look forward to seeing progress on this!

Glenn
_________________________
Actually I am a Rocket Scientist! \:D