#188836 - 2008-07-21 06:10 AM
Logon Scripts - Requirements
|
NearZero
Fresh Scripter
Registered: 2007-11-16
Posts: 10
|
Having just completed a logon script, I'am curious on what functionality others have built into scripts in order to meet the needs of various environments, without the one off's.
For example maping drives and connecting printers would be obvious.
Extending this with INI file mods, registry mods and so on would provide useful functionality.
So is there anything others have found to be extremely useful.
Look forward to some input.
|
|
Top
|
|
|
|
|
#188840 - 2008-07-21 12:20 PM
Re: Logon Scripts - Requirements
[Re: Allen]
|
NearZero
Fresh Scripter
Registered: 2007-11-16
Posts: 10
|
Thanks Allen, but I'am aware of the UDF's, perhaps I should explain myself better.
I'am sure many who visit here have written more then one logon script, thus during the process they would have noticed repeatitive use of particular functionality, this is the kind of input I'am looking for.
Cheers 
|
|
Top
|
|
|
|
|
#188842 - 2008-07-21 01:46 PM
Re: Logon Scripts - Requirements
[Re: Mart]
|
NearZero
Fresh Scripter
Registered: 2007-11-16
Posts: 10
|
Mart, outlook profiles... interesting... if roaming not used, worthy of some thought, thanks
|
|
Top
|
|
|
|
|
#188844 - 2008-07-21 02:51 PM
Re: Logon Scripts - Requirements
[Re: Mart]
|
Glenn Barnas
KiX Supporter
Registered: 2003-01-28
Posts: 4403
Loc: New Jersey
|
We never do one-off's when it comes to login scripts. We might do the occasional one-off config file for a special user or admin (for testing), but never change the login script code itself to accomodate a situation. When we do modify the login script, the same code is re-deployed to all organizations that utilize our script.
The login script that's available from my web site has been in use since 1996. There have been code changes to take advantage of new Kix capabilities, but the logic is virtually unchanged. In that time, the script has been used at dozens of client sites without any client-spcific code modifications. All of the configuration is done from a configuration file containing what we call Resource Records.
There are four kinds of resource records - Disk, Printer, Message, and Command, and they do pretty much what the names imply.
The general process of our script is:
- Set TICKS
- Determine the config file names - one for the user and one for the enterprise. A per user file overrides the enterprise file. Decide if a per-user file is present and set that as the primary config file.
- Determine if a cached file is present, and if it is, if its current. If it is missing or outdated, update it from the Netlogon share.
- Enumerate the resource records, determine if they are "processable" - that is - based on the group, OU, user, security and other conditions, can we eliminate this record from being processed? If so, ignore it, otherwise add the record data to an array. All record processing, including path rewriting, occurs at this stage.
- Display a brief logon message identifying the user, workstation, and privelege level. If defined, force visible display, clear drive/print mappings, and flush Kix token cache.
- Enumerate the Drive and Printer resource arrays, calling the drive and printer mapping functions as appropriate. Display a message indicating the map and success status. If it failed, set a global error flag & enable logging. Any failure writes key info about the user, settings, and the failed mappings to a file on the PC, so the help desk can determine the cause of the problem.
- Enumerate message resources, displaying any message files and delaying as defined in the record.
- Enumerate the command resources, and perform the commands. We support Shell, Run, and Call (to call other Kix scripts with the full login environment available).
- If a failure has occurred, set BREAK ON, display a message to call the help desk, and wait for a keypress - up to 15 minutes. After 15 minutes, or at the first key press (or Ctrl-C), the script window will close and the desktop will appear.
- If there were no failures, and the TICK count is less than the minimum defined, the script will delay until the desired TICKS have elapsed. This assures that the script status messages are displayed for a minimum amount of time. In our VMWare environment, the script runs in under a second, so we set a 6 second minimum display time - the max is 10 seconds.
Some things we absoutely WILL NOT do in a login script:
- Set registry values. This is done by GPO in every enterprise I've ever supported or maintained. If login scrips were used for this, we remove that pretty quickly once we take over support of the environment.
- Install software - Most software requires admin rights, and not every user is a local admin. Many users have a local admin account, but it isn't their network account. Local admin access via a network account is a major security violation in most enterprise environments.
- Modify desktop settings (ie: color, background, screensaver, etc) - again, the role of GPOs. One exception - some clients use BGInfo.exe in a Command record, which dynamically sets the background during logon, which displays some info used by the help desk. We have a GPO that enforces that image, although the image is updated during each logon.
There are a few rather powerful capabilities in our login script that have come about over nearly 12 years of use.
Flexible Resource Activation - a resource record goes through a number of checks to determine if it should be processed.
- If the user is a member of any listed AD group.
- If the user is a member of all listed groups.
- If the user is NOT a member of of any listed group
- If the user is a member of specific groups and NOT a member of other specific groups.
- Inverse logic - DO NOT map if the user is a member of any defined group
- If the user is a member of one of the listed OUs
- If the user is a Guest, User, or Admin
- The priority of a record when multiple resources "compete" for a single mapping.
All in all, there are 16 combinations of AD Group based processing, 8 combinations of OU processing, and 3 levels of generic access role processing that contribute to the decision to process a record.
One of the most powerful features is Path Rewriting. This allows the admin to specify a "variable" in the path that's being referenced, and the script will dynamically rewrite the path based on the variable. Path Rewriting can be based on User, OU, or Site, and can be a direct translation or a lookup. For direct translations, the string "&var&" (where "var" is USER, OU, or SITE) is simply replaced with the appropriate value. For lookup translations, a translation record is used. For example, if "&SITE:SITESHARE&" is specified, the SITESHARE record is searched for a value that matches the site name, and the data in that value is used in the path.
Glenn
_________________________
Actually I am a Rocket Scientist! 
|
|
Top
|
|
|
|
|
#188851 - 2008-07-22 12:42 AM
Re: Logon Scripts - Requirements
[Re: Glenn Barnas]
|
NearZero
Fresh Scripter
Registered: 2007-11-16
Posts: 10
|
Excellent stuff gentlemen,
Glenn nice approach, thanks for the detail.
The logic and structure behind scripting taken by other coder's is always of great value, again good stuff
Cheers
|
|
Top
|
|
|
|
Moderator: Jochen, Allen, Radimus, Glenn Barnas, ShaneEP, Ruud van Velsen, Arend_, Mart
|
0 registered
and 2679 anonymous users online.
|
|
|
kinda obvious but hey it's always the little thing that are missed) all issues were fixed.
