Logon Script for Brennen

[nmX.Memnoch]

Brennen,

I finally finished testing most of my functionality changes and cleaned up a version for you. Most of what I've been doing is creating the custom UDFs (user defined functions) at the bottom of the script. It cleaned up some of the other code I had in the script. As you can tell, I still haven't migrated everything to using the new UDFs yet (a lot of the Shell lines still need to be converted to the ShellExec() UDF). I've attached it in both RTF format and TXT format (in the ZIP). The RTF is mainly so you can see the color coded format from the script editor I use (AdminScriptEditor 3.x).

I tried posting it in a code box but something in the script keeps it from posting gracefully. The attachments should work just fine though.

I'm sure you'll have questions so just ask away...

logon.zip

Edited August 22, 2007 by nmX.Memnoch

[nmX.Memnoch]

I guess I could've mentioned some of the features as well...

• First Logon Check: Checks to see if this is the first logon after the machine has been joined to the domain. We have another custom script that's setup to install our standard suite of applications when the workstation is first joined to the domain.
  
• Checks WMI Repository Size: We've had a problem on several of our workstations where the WMI Repository located at %SystemRoot%\system32\wbem\Repository\FS\INDEX.BTR has grown waaay too large (several GB!). At that point the machine basically becomes unusable. Fortunately WMIDIAG fixes the problem by rebuilding the Repository. This check simply alerts us if any workstation has a Repository size greater than 15MB (the size is configurable in the script).
  
• Checks SAV Installation: Checks to see if Symantec AntiVirus Corporate Edition is installed. If an Admin logs in and it isn't installed, the script prompts to install. If a User logs in, it alerts us so we know to go install it.
  
• Checks SAV Version: Makes sure the workstation has the currently approved SAV version installed. If not, it alerts us so we can update it (I did have a check included to prompt for update if an Admin was loggin in but I removed it because the code wasn't exactly right...I'll revisit that later).
  
• Checks SAV Definitions: Makes sure the workstation has current AV definitions. If they're older than 5 days it alerts us so we can see what the cause may be (usually that the workstation was left off for a few days).
  
• Drive Space Check: We've had an issue with SMS leaving abnormally large temp files on workstations. Basically the temp file keeps growing until the drive runs out of space. This check lets us know if the free drive space is below 1GB. We haven't had this problem since moving to SMS 2003 but I left it there just in case (we've got some older installs that had small system partitions so it's still be useful).
  
• Skips script if logging onto a server
  
• Maps drives based on user groups
  
• Clears Outlook temporary files
  
• Sets wallpaper and screensaver settings for current user
  
• Sets security settings depending on OS
  

I'm sure there's some other stuff I've missed. Also, a lot of the registry settings that we have in our script can be controlled by Group Policy. At the time I added the settings they weren't being controlled by Group Policy. The Group Policy settings we have also depend on some custom WMI data so I've left the settings in for machines that don't get that custom WMI data.

[Brennen]

Awesome, thanks!!

I think this will be very useful for anyone who needs a basic kick start (pun...KiXtart..?) to use some functions and want to get a gist of how to use a login script. Since I started I have made a much more detailed script, and in turn found I can cancel many of the functions out and use GP -- but I love scripting, so with this I am sure I will touch some new ground.

Thanks again!!

Edited August 28, 2007 by Brennen

[nmX.Memnoch]

Yeah, a lot of what I do in my script can be forced with Group Policies. However...I don't have access to edit the Group Policies at work (and they won't create custom ones for us) so I've had to get creative.

I hope you can find some use for at least some of what I posted. The email alerting is probably some of my favorite stuff in the script.

I need to rework my printer script and post a cleaned up version of that. The eventual plan is to do printer mapping based on workstation location.

Edited August 28, 2007 by nmX.Memnoch

[Brennen]

Dang, that sounds cool. When I have more time i will look into more of this stuff. I have played around with some of the commands and such that I have from their index page -- but there is only so much I can "test" on my own computer logging in and logging out etc without losing my sanity.

Oh, is there a way to test run KiX scripts without actually logging in / out. I figure there is...but I get an error whenever I try. Never pursued it much past there.

[nmX.Memnoch]

Yeah...you can test 'em. Put a copy of KIX32.EXE and WKIX32.EXE in your %SystemRoot% (normally C:\WINDOWS\). Now you can run scripts from the command line:

KIX32.EXE scriptname.kix

Or if you're not in the script directory:

KIX32.EXE C:\full\path\to\scriptname.kix

Additionally...for the sake of sanity when you're testing make the very first line of your script Break On. Without that setting KiX will automatically log you out if the KIX32.EXE (or WKIX32.EXE) process is terminated before the script ends. It's handy when you have a script that hangs or loops due to a syntax error. For logon scripts you can add this to the beginning instead of just adding Break On. This way you can test it without worrying about being logged out if the script hangs.

If @LOGONMODE = 1
   Break Off
Else
   Break On
EndIf

Edited August 28, 2007 by nmX.Memnoch