There are a number of factors that drive a good logon script design. This post lists those that have driven the design of the scripts that will be the subject of my blogs for the foreseeable future. In the corporate environment where I work we have many specialized constraints and requirements. The complexity of these prevent an efficient administrative model that could be designed exclusively through GPO’s. Much logic has been placed into the scripts to account for a very heterogeneous environment. Below is a list of the criteria used in the design. These criteria take into account agility, flexibility, and service as an over-arching framework in which to develop.

1. Scripts should run with the assumption that no software is installed on the host system aside from the OS
   Reasoning: Logon scripts should be able to run right after a server or workstation has been added to the domain and rebooted. Build techniques may be from distribution media, image, or other process and the suite of software on the system, aside from what is included with the base OS, cannot be assumed.
2. Service pack levels and OS versions cannot be assumed
   Reasoning: Multiple OS’s are installed in our environment and the service pack level can never be assumed for a given OS due to the nature of how upgrades to new service packs are performed
3. User level permissions to directories on the C drive cannot be assumed and neither can permissions to the registry or any other location on the system
   Reasoning: New versions of OS’s often change the default permissions of various registry locations and for the file system. Local administrators may also change permissions
4. Batch scripts should be designed to run on lowest common denominator systems and should avoid commands and features that are not supported on them. Additionally, if a command is removed in later OS’s or only supported on servers and not workstations, or vice versa, it should be avoided. If the command or feature is improved on in the future then only the options that give like results across all OS’s should be used
   Reasoning: This prevents having to maintain multiple, version specific batch files which, though possible, are more difficult to account for version specific scripting
5. Scripts need to take into consideration location of logon and speed of connection
   Reasoning: In a distributed environment with multiple geographic locations the resources that are available at all locations are not uniform. Some aspects of logon scripting can be network intensive and if a link to the nearest authenticating controller or network resource being referenced is across a low bandwidth link the logon script can take a long time to complete
6. Single code base for scripts should provide functionality for different domains can be replicated from the source domain to any number of other Active Directory domains
   Reasoning: Though domains are separate, having a single code base and accounting for domain differences in the scripts where needed allows a much simpler code management scheme and standardization across domains
7. Windows 2000, Windows 2003, and Windows 2008 functional level domains should be supported
   Reasoning: If there are domain specific functions they need to be accounted for. In practice it has thus far been shown that there are not any AD domain level nuances that need to be accounted for in the scripting we have thus employed but if there are in the future, the ability needs to be available to account for them
8. Detailed debugging logs should be provided
   Reasoning: These are invaluable in troubleshooting logon scripts – especially where actions are taking place that are not visible to the user
9. Capture of logon/logoff information should be captured for every logon
   Reasoning: This information is invaluable for determining the machines that a user logs onto and when they logon as well as any other information desired to be captured at logon. This information, when placed into a relational database, provides excellent reporting and auditing information which helps with investigations and compliance issues
10. GPO’s will control running of logon/logoff scripts for all users
    Reasoning: This is functionality that has been provided by GPO’s since Windows 2000. By using this means, instead of setting each user’s profile, you can control the parameters passed to the logon scripts based upon site, domain, OU, and/or group filtering criteria. This also prevents you from having to set each individual users logon script information in the AD profile (ease of administration)
11. Capability to provide for multiple locked down desktop environments and alternate user shells needs to be provided
    Reasoning: In our environment we have locked down kiosks, cash registers, order entry/customer service systems, and the ability to logon with an ID that directs to a web site to allow users to unlock their user accounts and reset their passwords. All of these require running a user shell other than explorer.exe and require logic to load the appropriate shell
12. Uncompiled code should be used for all scripting components to facilitate easy debugging, troubleshooting, and modification. This does not include external tools and utilities that are called
    Reasoning: Scripting languages available on the Windows platform are powerful enough to support nearly any logon task that would need to be supported. Using a script technology vs. compiled code allows for easier and quicker editing and troubleshooting of code and does not require a third party tool for editing or compiling
13. External tools and utilities that are used in scripts should not require software to be installed but should be able to run stand-alone by simply calling the executable
    Reasoning: This avoids a dependency on software that may not be available and the requirement for elevated privileges of the user logging in (or elevating privileges) for the purposes of installing required software. This does not include command line utilities provided with Windows Resource Kits or other tools that run as a stand alone executable
14. Any third party executables called should be of the free license variety
    Reasoning: There a plenty of free tools available to perform nearly any logon script task needed. Where there is not a free tool available the functionality can almost always be provided for through a batch script, kix script, vbscript, or hta
15. The version of an executable called in the logon scripts needs to be capable of running in all the OS version environments supported. Sometimes this will require using an older version of a utility with less functionality
    Reasoning: This prevents having to provide and maintain multiple versions of an executable and provide script logic to determine which version to run with what parameters at logon script run time
16. Scripts should be stream lined to run as rapidly as possible. Where there are any areas where the script actions are taking place that may take more than a second or two to complete, status should display to the user
    Reasoning: Users tend to get fidgety when they are not made aware that something is actually happening even though they may not see what it is that is happening. When this happens they tend to call the help desk or end up putting their workstation in a state that requires desktop support. Additionally, if logon takes too long they will complain
17. Logon status displayed should look professional
    Reasoning: Self explanatory. If the logon process looks professional it reflects accordingly on the logon script administrator’s skills and makes the company look better if the logon process ever has any customer or vendor facing exposure
18. Ability to display date specific messages such as “Merry Christmas, Happy Mother’s Day” etc
    Reasoning: Tradition. Not entirely necessary
19. Display of acceptable use policy
    Reasoning: Make Legal happy
20. Display of password expiration
    Reasoning: Feedback to user to let them know how much time is left with their current password. Though this is displayed at a prompt asking the user if they want to change their password, many answer no without really reading the message. The logon splash provides a good opportunity to emphasize this information while logon completes
21. Mapping of drives based upon group membership and other criteria
    Reasoning: This is one of the major reasons for having logon scripts
22. Setting up of printers
    Reasoning: This is one of the major reasons for having logon scripts
23. Setting of environment variables that will persist for just the user session and those that persist at the machine level
    Reasoning: The default environment variables are very helpful but others, such as site location, are conspicuously missing. This and others can be easily added to machine and/or user session environment variables. These can then be used as needed in your environment
24. Ability to dynamically turn off parts of the logon scripts that should not run based upon varying criteria
    Reasoning: Certain groups are very sensitive about there environments that they run their systems in, such as developers. To be able to easily bypass those parts of the code allows for maximum logon script flexibility
25. Modularization of logon script code so that other people may maintain the parts that they are responsible for without affecting the whole
    Reasoning: Dealing with smaller code chunks at a time is much easier. Additionally an error in one code module is less likely to break the logon scripts when run at logon and can provide for more easy troubleshooting in the event of an error
26. Running of scripts locally on each machine
    Reasoning: This provides for better performance running logon scripts (generally) and also mitigates any file contention issues that might be incurred by directly running scripts from the DC’s. Updating of logon script files on the servers can be performed at any time
27. Support of test and production branches of code and, if needed, any other number of branches
    Reasoning: It is imperative to have a means to develop and test your logon script changes prior to placing them into production
28. Leveraging of Windows Active Directory SYSVOL automatic replication
    Reasoning: With multiple sites with AD controllers in those sites, replicating files is automatic across sites. This combined with AD aware clients ensures that user logons will access the logon script files on the server that is closest to them thereby minimizing logon time
29. Ability to provide a means by which to install software and make configuration changes for users that logon with credentials that have local Administrator privileges
    Reasoning: This allows for standardization of the desktop and server platforms. For instance: a list of standard software to install on all newly built servers allows for standardization of server builds at first logon to the domain

This is the first post of what will likely be a long series of posts regarding logon scripts in an Active Directory 2003 environment. In this series of posts I plan on laying out the design criteria and actual design, accompanied by ample technical discussion, examples, and lessons learned.

The environment that this series comes out of is on containing 350 Windows servers from versions 2000 to 2008 and workstations from versions 2000 to Windows 7. The logon scripts will support Windows NT and Windows 9x with some tweaking as those were environments that were originally supported when we first implemented Active Directory 2003. Our environment also supports 140 retail stores, each with an AD 2000 domain controller, multiple sites, and multiple domains.

As I am a lazy administrator, if you ask questions I will try to answer them but may not be as timely as you might like - especially if questions would require troubleshooting in a test or production environment. But, if I have a ready answer to your questions I will answer them as soon as I can.

My next post will list the design criteria for the environment that I outlined above.