Access Keys:
Skip to content (Access Key - 0)

Windows Server Platforms - Group Policy and win.mit.edu

On this page:

Introduction

WIN, the win.mit.edu domain, organizes sets of machines, called containers, in Active Directory underneath the OU WIN.MIT.EDU\Machines. A Container Administrator is a person to whom privileges have been granted over a particular container or set. This document is intended to provide container administrators with useful information for configuring the machines in their containers using Group Policy, or GP. win.mit.edu specific notes appear in red.

Start with the Introduction to Group Policy.

Group Policy Details

The first reference above explains that GP Objects, GPOs, are collections of settings that can be applied to a container, by default will apply to all users and computers located in or under this container. It is possible to restrict this to a subset of these users and computers by using Access Control Lists (ACLs) on the group policy object.

Recall that GPOs are composed of two halves: Computer Configuration (also known as Machine Configuration or Settings) and User Configuration (or User Settings). As the names imply, Computer Configuration only applies to computers in the container subtree, and User Configuration only applies to users in the container subtree. In our case, the containers over which container administrators have control holds computer objects. The user objects corresponding to all Athena users are stored elsewhere. Therefore, only the Computer Configuration half of a GP object are used by container admins.

Non-Overrideable Machine Settings

Certain machine settings are set for the Machines container and are not overrideable by GPs at lower levels. This GPO is named "GP.Pismere.NO-OVERRIDE." Its settings may change with time, so be sure and check for the latest details using GPMC, but this section tries to provide a functional description.

Nonoverrideable settings have been minimally chosen to keep the domain running smoothly. If you think that your container should be allowed to override one of these settings, let us know why you think so. An approximate state of this GPO follows:

  • Installation of Pismere.msi: This software package includes many programs necessary for a machine to be a functional part of the domain. This includes Kerberos, Moira, and self-maintenance services for automatic running of scripts.
  • Installation of Windows 2000 Resource Kit: The Windows 2000 Resource Kit contains many useful binaries and scripts. The startup / shutdown / logon / logoff scripts assume the existence of these files.
  • Installation of Windows 2000 Support Tools: The Support Tools package also contains many useful binaries and scripts.
  • Machine Startup/Shutdown Scripts: These scripts are located down from \\win.mit.edu\dfs\ops\auto\operational\scripts\machine at startup\startup.wsf and shutdown\shutdown.wsf They perform some necessary operations in keeping the machines properly configured.
  • Run Logon Scripts Synchronously: This forces all group-policy-based logon scripts to be finished before the user's shell (explorer) starts. Asynchronous logon scripts can lead to non deterministic behavior (race conditions).
  • Primary DNS Suffix = mit.edu: All machines in the WIN domain (with the exception of the domain controllers) are "machine.mit.edu" and not "machine.win.mit.edu".
  • Folder Redirection, Registry, Scripts, and Security Policy Processing is enabled and will be performed even if these policies have not been changed: This means that if users change the machine settings to conflict with these policies, they will be changed back upon the next group policy refresh. This helps to maintain a clean and consistent computing environment.
  • ATHENA.MIT.EDU Kerberos Realm KDC's set to kerberos.mit.edu, kerberos-1.mit.edu, and kerberos-2.mit.edu. Kerberos password change server set to kerberos.mit.edu: These settings allow machines to authenticate user logons to the ATHENA realm.
  • AFS Client settings: The AFS Client has been configured to not attempt to get AFS tokens for users logging into the local machine or to the WIN domain. It will, however, attempt to get AFS tokens for users logging into the ATHENA.MIT.EDU realm. Also, all users who log into either the WIN or the ATHENA.MIT.EDU domains will launch the following script: \\win.mit.edu\dfs\ops\auto\operational\scripts\machine\logon\logonbefore.wsf
    This does some important tasks like getting the user's MIT Kerberos ticket cache.

Non-Overrideable User Settings

User settings are unchangeable, because GPOs are applicable only to items in your container, and all user items are located elsewhere. This is, of course, unless you enable loopback processing. (See Microsoft Knowledge Base Article Q231287). Recall that this may cause problems if you choose to override important user settings or choose to completely prevent the user's own group policy settings from being used at all. This will most definitely cause problems, and we suggest that you do not do this.

Here are a couple user settings that are set in GP and which you should not override:

  • User Logon/Logoff Scripts: These scripts are located at ...\scripts\machine\logon\logonafter.wsf and ...\scripts\machine\logoff\logoff.wsf. These, along with the logonbefore.wsf script mentioned above, guarantee that certain vital procedures will occur at user logon and logoff.
  • Folder Redirection: Users located in the Moira\Users container will have several of their roaming profile directories (My Documents, My Pictures, Favorites, and Application Data) redirected into their WinData directory.

Overrideable Machine Settings

The following machine settings are example default settings that are Overrideable by lower levels (Group Policy Object "GP.Pismere"), although you may want to be reasonably sure about the implications of such changes before trying to override them.

  • Audit Account logon, account management, logon, and policy changes: This allows the machine to record certain events in its Security event log. These records can then be used to track down exactly when certain breaches of security have occurred.
  • Do not display last username in logon screen: This is useful for public machines. Displaying the username of the last logged-on user could be construed as an intrusion into someone's privacy.
  • %SystemRoot%\system32\RestrictedSnapIns directory can only be read by system, domain admins, and members of the group container-admins: this directory contains snap-ins for the Microsoft Management Console which you may not want regular users to access, such as the Active Directory Users and Computers snap-in.
  • IBM AFS Client can be stopped, started, and paused by all authenticated users: Currently the AFS client has been known to crash unexpectedly. If this occurs, the client will be restarted automatically. However, it may be useful if users can stop and restart the service by themselves as well.
    Note: If you decide to override this, make sure NEVER to remove Full Control privileges from the SYSTEM account. If you do, it requires a registry edit on each affected machine to fix.
  • Disable autoplay on CD or DVD drives.
  • Do not detect slow network connections: The system will not behave differently for users logging in over a slower connection.
  • Wait for remote user profile: The system will not time out when a user's roaming profile takes a while to download.
  • Do not log users off when roaming profile fails: Instead, allow the user to log in with a temporary profile.
  • Delete cached copies of roaming profiles, workaround: As described in the Extensions section, this is the supported method for deleting the locally stored copy of the user's roaming profiles upon logout.
  • Verbose logging: Explained in the Extensions section.
  • Force a Root (Administrator) Password: Explained in the Extensions section. By default all machines' root passwords are synced to Athena.
  • (The following setting has not happened yet, but is scheduled to occur soon.) Messenger service is Manual: The Messenger service allows any NETBIOS-enabled machine on the internet to bring up a pop-up message box on the local machine. This is usually undesirable. The Messenger service is Automatic by default, but we have made it Manual in the WIN domain. Users with administrative access to a machine can turn the service on and off manually. If you wish to override the setting for machines in your container, you can edit your Group Policy object as follows:
    Computer Configuration/Windows Settings/Security Settings/System Services: Messenger...Startup: Automatic.
    Note: If you decide to override this, make sure NEVER to remove Full Control privileges from the SYSTEM account. If you do, it requires a registry edit on each affected machine to fix.

WIN Extensions to Group Policy

In order to provide additional machine configuration options for container administrators, win.mit.edu has occasionally extended Group Policy. These extensions can be found (via the Windows Group Policy editor, gpedit.msc) in all group policy objects in the WIN domain under Computer Configuration/Administrative Templates/WinAthena Settings.

Please see the detailed description of the settings.

As of Summer, 2003, The tool of choice to see Domain GP is the Group Policy Management Console, GPMC.

Description of Domain-Level Tools

Self-Maintenance Service

Introduction

Self-Maintenance is a WIN service which manages the automatic running of scripts in system context. Currently there are two types of automatic scripts: Cleanup and Scheduled. The Cleanup script is run whenever a user logs out. It is given (as command-line parameters) the username and domain of the logged-out user. Scheduled scripts reside in a Scripts directory hierarchy and are launched at particular times and with particular frequencies, specified by their filenames. Scheduled scripts are launched only when no users are logged in, and will wait for logout before running, if necessary.

General SelfMaint Behavior

Automatic scripts (cleanup, daily, weekly, periodic, one-time, and update scripts) located in the scripts directory (specified by MAINTDIR in ist:SelfMaint.conf) are only launched when no user is logged in. If a user is logged in when the script is scheduled to run, SelfMaint waits until the user logs out to launch the script. During the time a script is being run, non-administrative users are prevented from logging into the machine. A dialog box will inform the user that a script is being run and that the user must either wait or find another workstation. These scripts are run in system context.

A log file is kept (specified by LOGFILE in ist:SelfMaint.conf) which stores the name of each script run and the date and time (to the minute) of its most recent successful run. This allows SelfMaint to maintain state upon restart. You may wish to view ist:a sample log file.

After a user logs out, SelfMaint launches one cleanup script if one is located in the scripts directory. The username and domain of the logged-out user are passed as command-line arguments to the cleanup script.

WIN machines keep track of their current Pismere.msi software Version. Each one has a registry value "HKLM\Software\MIT\Pismere\PISMERE_VERSION" which represents this Version as a string of three numbers separated by periods: "Major.Minor.Patch". Other acceptable representations are "Major.Minor" (where the Patch is assumed to be zero) and "Major" (where both Minor and Patch are assumed to be zero). If there is no such value in the registry, SelfMaint will assume it is "-1.-1.-1", the "Unknown Version". SelfMaint will look in a subdirectory of MAINTDIR corresponding to the current major and minor revision of the software version. There are also update scripts which alter this version. In this case, both SelfMaint's current value and the value stored in the registry are updated.
win.mit.edu Specific: MIT hasn't really ever used this. We just set the Pismere Version to 0.1.0 and leave it there.

Two or more scheduled scripts are never run simultaneously. Each one waits for the currently executing script to finish. There is no guarantee, however, that two scripts will run in a specific order. Even if one script is scheduled for an earlier time than another, it is possible that a logged-in user will prevent either script from running until after both have been set to launch. When the user logs out, both scripts will try to run, and it is not necessarily true that the one originally scheduled for an earlier time will run first. If you need a particular script to run before another one, consider using versioning, as in ist:this example, discussed later.

All scheduled scripts which have a period (daily, weekly, periodic) will run immediately upon starting SelfMaint. However, SelfMaint will always wait at least half of the script's period before re-running a script. So, if it turns out that less than half of the script's period has elapsed since the last successful run, it will be skipped. After this, the script will be scheduled to run at the next appropriate time.

SelfMaint occasionally re-examines the script directory for new scripts (or even pre-existing scripts which may now apply to the machine after a version change). It does this whenever a user logs out, whenever an update script finishes running, and periodically every UPDATE minutes while no users are logged in (where UPDATE is an integer specified in ist:SelfMaint.conf).

In order to ease net congestion and prevent a situation in which dozens of machines are simultaneously trying to access the same file, all script launches and script directory re-examinations are desynchronized. This means that the system will actually schedule the events for some time later than the nominal time. This delay is randomly chosen between 0 and DESYNC minutes (where DESYNC is an integer specified in SelfMaint.conf).

Scripts Directory Hierarchy

The Scripts directory, specified by MAINTDIR in SelfMaint.conf, should contain subdirectories corresponding to the current Pismere Version, of the form "Major.Minor". Thus a computer running Version 3.4.5 will access the "3.4&" subdirectory of MAINTDIR. This directory should be named exactly "Major.Minor" without leading zeros. Therefore "1.0" and "1.1" are acceptable, while "1.00" and "1.01" are unacceptable. Remember that if SelfMaint cannot find the registry value for the Pismere Version, it will assume "-1.-1.-1". Therefore, you may want to have a "-1.-1" directory which contains a single script whose purpose is to update the version to an initial value.

To restrict a script to the computer objects in a certain container or subtree of the Active Directory, place the file in a directory below MAINTDIR\Version. The file system directory hierarchy below MAINTDIR\Version should parallel the Active Directory hierarchy of the domain, specifically the portion of the Active Directory which contains the relevant computer or container objects. For example, if all machines are running Version 1.0.x and the domain has the following partial structure:

ACTIVE DIRECTORY STRUCTURE

DC="DomainRoot"
|
|__CN="Computers"
|.....|
|.....|__CN="MyComputer" (computer)
|.....|
|.....|__CN="OtherComputer" (computer)
|
|__OU="RIS"
|
|__OU="Development"
|.....|
|.....|__CN="DevComputer" (computer)
|
|__OU="Production"
|
|__CN="ProdComputer" (computer)

then the scripts directory could look like:

FILE SYSTEM STRUCTURE
Folder="MaintDirec" (MAINTDIR)
|
|__Folder="1.0"
|.....|
|.....|__Folder="Computers"
|.....|
|.....|__Folder="RIS"
|...........|
|...........|__Folder="Development"
|...........|.....|
|...........|.....|__File="BLOCK"
|...........|.....|
|...........|.....|__Folder="DevComputer"
|...........|
|...........|__Folder="Production"
|.................|
|.................|__Folder="ProdComputer"
|
|__Folder="1.1"

Each machine will locate the deepest subdirectory of MAINTDIR\Version which matches its place in the Active Directory. For example, "DevComputer" will locate "MaintDirec\1.0\RIS\Development\DevComputer", but "MyComputer" will locate "MaintDirec\1.0\Computers". All the scripts located in this directory will apply to the machine. The machine will then move up to successively higher levels in the tree. All scripts it finds along the way which bear an "inherit" flag will also apply to the machine. (Those without the flag will NOT apply to the machine.) The machine will stop traversing the tree once it reaches MAINTDIR\Version or once it encounters a directory containing a file whose name begins with "BLOCK".

For example, "ProdComputer" will acknowledge all scripts in "MaintDirec\1.0\RIS\Production\ProdComputer", and all inherited scripts in "MaintDirec\1.0\RIS\Production", "MaintDirec\1.0\RIS", and "MaintDirec\1.0". "DevComputer" on the other hand will acknowledge all scripts in "MaintDirec\1.0\RIS\Development\DevComputer", and all inherited scripts in "MaintDirec\1.0\RIS\Development". It will not traverse any higher in the tree because of the "BLOCK" file in the Development folder.

Automatic Script Naming

The name of a scheduled script determines which machines (in the appropriate object container) will run it and when. The naming convention is:

['I' [ist:additional letters] '.'] [ist:Version Interval '.'] Script Type [ist:'.' optional Additional Descriptive Information] '.' Extension.

Note: If a script name does not conform exactly to the naming convention, the behavior is unspecified. Although it is possible that SelfMaint will correctly interpret some deviations, it will most definitely fail on others. If an element is not optional (is not surrounded by square brackets), you must include it. At the end of this document are some ist:more liberal examples of script naming which do not conform to the naming convention.

The 'I' is an optional inherit flag, indicating that the script should be run by all machines AT AND BELOW the current node. Without this flag, the script will only be run by machines AT the current node. Additional letters may be included to make this flag more readable (e.g., "Inherit"). If the inherit flag is included, it is important to include the terminating delimiter ".".
win.mit.edu Specific: In retrospect, a flag for "no-inherit" should have been created, and made inherit the default. MIT never uses no-inherit. All these files are required to start with "i.".

4.1. Version Interval

win.mit.edu Specific: MIT has not used this. The version interval is left blank.

As mentioned earlier, WIN machines keep track of their current Pismere.msi software Version. Each one has a registry value "HKLM\Software\MIT\Pismere\PISMERE_VERSION" which represents this Version as a string of three numbers separated by periods: "Major.Minor.Patch". The directory hierarchy already restricts each machine to a subdirectory corresponding to the Major and Minor revisions. However, you may wish to write a script which runs or does not run based on the current patch. For example, you may write a script that periodically updates a piece of software that was not introduced until Pismere Version 1.0.3, but some WIN machines are still running Version 1.0.2 and below. The Version Interval allows you to specify what range of Pismere Versions should run this script. If the Version Interval is omitted, all version machines will run the script.

The Version Interval is a string of the form:

'V' [ist:optional characters] LeftDelim [ist:optional MinVer] ',' [ist:optional MaxVer] RightDelim.

The 'V' flags the string as a version interval. You may add additional characters to make it more readable (e.g. "Version").

LeftDelim is either an open parenthesis '(' or an open square bracket '[ist:'. The parenthesis signifies an open interval boundary, which excludes the lower endpoint, while the bracket signifies a closed interval boundary, which includes the lower endpoint.

MinVer is an optional version string of the form "Major.Minor.Patch", "Major.Minor" or "Major", which represents the lower boundary of the acceptable interval. If MinVer is omitted, there is no lower bound.

The comma ',' is a separator for the two versions.

MaxVer is an optional version string of the form "Major.Minor.Patch", "Major.Minor" or "Major", which represents the upper boundary of the acceptable interval. If MaxVer is omitted, there is no upper bound.

RightDelim is either a close parenthesis ')' or a close square bracket ']'. The parenthesis signifies an open interval boundary, which excludes the upper endpoint, while the bracket signifies a closed interval boundary, which includes the upper endpoint.

Examples:

"Version[1.0.3,1.1)": This interval requires that the current Pismere Version be at least 1.0.3 and strictly less than 1.1.0. Therefore, the script will only be run for machines of the form "1.0.xxx" where xxx is at least 3.

"Version(,1.0.4)": This interval requires that the current Pismere Version be strictly less than 1.0.4.

"Version(,1.0.4]": This interval requires that the current Pismere Version be less than or equal to 1.0.4. Therefore, the script will be run for all the machines of the previous example, as well as those whose version is 1.0.4.

"Version(1.0.3,)": This interval requires that the current Pismere Version be strictly greater than 1.0.3. Therefore, the script will be run for Version 1.0.4 (and greater), but not Version 1.0.3 (or less).

"Version(,)": This interval does not place any restrictions on the Pismere Version. All versions will run this script.

"Version[ist:1.0.5,1.0.5]": This closed, zero-width interval requires that the current Pismere Version be exactly 1.0.5.

"Version(1.0.5,1.0.5)": This is an open zero-width interval, by virtue of the parentheses. Therefore, NO machine will run this script. It is unlikely that one would ever wish to specify such an interval. Therefore, be sure to use the square brackets in such cases.

The Version Interval may also take the following form:

'V' [ist:optional characters] LeftDelim [ist:optional Ver] RightDelim.

In this case only one version is specified. This interval requires that the current Pismere Version be exactly Ver. If Ver is omitted, all Versions are accepted.

Examples:

"Version[ist:1.0.5]": This interval requires that the current Pismere Version be exactly 1.0.5.

"Version(1.0.5)": This interval also requires that the current Pismere Version be 1.0.5. Note that when only one version is specified in the interval, the parentheses do not exclude the endpoint. Therefore this interval corresponds to "V[ist:1.0.5,1.0.5]", not "V(1.0.5,1.0.5)".

"Version[]": This interval does not place any restrictions on the Pismere Version. All versions will run this script.

4.2. Script Type

There are six types of automatic scripts: Daily, Weekly, One-Time, Periodic, Update, and Cleanup.

4.2.1. Daily Scripts
Daily Scripts are run once per day at a particular time. Their period is one day, and if more than half a day has passed since the last successful run when SelfMaint starts, they will be run immediately. Otherwise, they will be scheduled for the next appropriate time. The Script Type string for daily scripts is of the form:

'D' [ist:optional letters] '.' HH '-' MM

The 'D' flags the script as daily. Additional letters may be included to make this more readable (e.g., "Daily").

The time of day is specified in European or Military time, as four digits HH-MM separated by a hyphen. The first two HH digits specify the hour (00 through 23) and the next two MM digits specify the minute (00 through 59).

Examples:

"Daily.10-30": Launch the script every day at 10:30 AM.

"Daily.00-00": Launch the script every day at midnight.

"Daily.18-52": Launch the script every day at 6:52 PM.

4.2.2. Weekly Scripts

Weekly Scripts are run once per week at a particular time on a particular day of the week. Their period is one week, and if more than half a week has passed since the last successful run when SelfMaint starts, they will be run immediately. Otherwise, they will be scheduled for the next appropriate time. The Script Type string for weekly scripts is of the form:

'W' [ist:optional letters] '.' HH '-' MM '.' DayOfWeek [ist:optional letters]

The 'W' flags the script as weekly. Additional letters may be included to make this more readable (e.g., "Weekly").

The time of day is specified in European or Military time, as four digits HH-MM separated by a hyphen. The first two HH digits specify the hour (00 through 23) and the next two MM digits specify the minute (00 through 59).

DayOfWeek represents the day of the week and can be one of the following strings: "M", "Tu", "W", "Th", "F", "Sa" or "Su". Additional letters may be included to make this more readable (e.g., "Wednesday").

Examples:

"Weekly.10-30-W": Launch the script every Wednesday at 10:30 AM.

"Weekly.00-00-Tues": Launch the script every Tuesday at midnight.

"Weekly.18-52-Sunday": Launch the script every Sunday at 6:52 PM.

4.2.3. One-Time Scripts

One-Time Scripts are launched only once. The Script Type string for one-time scripts is of the form:

'O' [ist:optional letters] '.' YYYY '-' MM '-' DD '.' HH '-' MM

The 'O' flags the script as one-time. Additional letters may be included to make this more readable (e.g., "One-time" or "Once").

The YYYY-MM-DD and HH-MM represent the date and time that the script should be launched. The four YYYY digits represent the year (e.g., 2001), the next two MM digits represent the month (01 through 12) and the last two DD digits specify the day (01 through 31). The time HH-MM is specified in European or Military time, as a string of four digits. The first two HH digits specify the hour (00 through 23) and the next two MM digits specify the minute (00 through 59). If SelfMaint is started after the specified time, the script will be scheduled to run immediately. Instead of YYYY-MM-DD.HH-MM, it is possible to specify the string "ASAP". This will guarantee that the script will be scheduled to run immediately.

Examples:

"Once.2001-12-25.01-23": Launch the script at 1:23 AM on December 25, 2001. If SelfMaint is started after this time, launch the script immediately.

"Once.ASAP": Launch the script immediately.

4.2.4. Periodic Scripts

Periodic Scripts are like daily or weekly scripts in that they run periodically. However, periodic scripts are run beginning at a "start time", and with an arbitrary period of at least one minute. If more than half of this period has passed since the last successful run when SelfMaint starts, they will be run immediately as long as it is after the "start time". Otherwise, they will be scheduled for the next appropriate time. The Script Type string for periodic scripts is of the form:

'P' [ist:optional letters] '.' YYYY '-' MM '-' DD '.' HH '-' MM '.' PdMagnitude PdUnit [PdMagnitude PdUnit [Pd Magnitude PdUnit [ist:...]]]

The 'P' flags the script as periodic. Additional letters may be included to make this more readable (e.g., "Periodic").

The YYYY-MM-DD and HH-MM represent the date and time that the script should first be launched. The four YYYY digits represent the year (e.g., 2001), the next two MM digits represent the month (01 through 12) and the last two DD digits specify the day (01 through 31). The time HH-MM is specified in European or Military time, as a string of four digits. The first two HH digits specify the hour (00 through 23) and the next two MM digits specify the minute (00 through 59). If SelfMaint is started after the specified time, the script will be scheduled to run immediately.

PdMagnitude is a non-negative integer, and the Pd Unit is a string starting with the character 's', 'm', 'h', 'd' or 'w', corresponding to seconds, minutes, hours, days, or weeks, respectively. You must include at least one PdMagnitude/PdUnit pair. The sum of the times represented by these pairs specify the period between the first launching and each subsequent scheduled launching of the script. For example, "10min" corresponds to a period of ten minutes. "1h45m" corresponds to an hour and forty-five minutes. If a zero period is specified, the script is treated as a one-time script.

If SelfMaint is started after the initial launch time, the script will be run immediately, and then rescheduled for the next scheduled launch time.

Examples:

"Periodic.2001-01-03.00-00.3days": Launch the script every three days, starting at midnight on January 3, 2001. That is, midnight on January 3, January 6, January 9, January 12, etc. If SelfMaint starts running after midnight on January 3, 2001, it will launch immediately, and then every three days, starting at the next scheduled launching. For instance, if SelfMaint starts running sometime on January 4, the script will run immediately, and then at midnight on January 6.

"Periodic.2001-03-01.13-35.2hours30minutes": Launch the script every 150 minutes, starting at 1:35 PM on March 1, 2001. That is, 1:35 PM, 4:05 PM, 6:35 PM, etc.

"Periodic-17760704-1107-52weeks": Launch the script every 52 weeks, starting at 11:07 AM on July 4, 1776. That is, 11:07 AM on July 4, 1776, July 3, 1777, July 2, 1778, July 1, 1779, June 29, 1780, etc. Again, if SelfMaint starts running after the nominal initial launch time, the script will run immediately, and then at one of these subsequent times, for example, 11:07 AM on September 27, 2001.

"Periodic-20011225-0123-0minutes": Launch the script only once at 1:23 AM on December 25, 2001. If SelfMaint is started after this time, launch the script immediately.
win.mit.edu Specific: It is not cron. Periodic scripts are really periodic. "Every Wednesday at 5am" is periodic with a period of 168 hours. "Every month at 5am" is not, because the "period" varies. Hence, there is no "month" or "year" option. Selfmaint would need substantial revision to get this done.

4.2.5. Update Scripts

An update script is a special type of one-time script that additionally changes the Pismere Version during the script. The Script Type string for update scripts is of the form:

'U' [ist:optional letters] LeftDelim [ist:optional Ver] RightDelim '.' YYYY '-' MM '-' DD '.' HH '-' MM

The 'U' flags the script as an update script. Additional letters may be included to make this more readable (e.g., "Update").

LeftDelim is either an open parenthesis '(' or an open square bracket '[ist:'. Here there is no difference in meaning between these two symbols.

Ver is an optional version string of the form "Major.Minor.Patch", "Major.Minor" or "Major", which represents the new Pismere Version after the script is run. If Ver is present, SelfMaint will update Pismere Version automatically upon successful completion of the script. If Ver is omitted, the script must be written such that it changes the HKLM\Software\MIT\Pismere\PISMERE_VERSION registry value.

RightDelim is either a close parenthesis ')' or a close square bracket ']'. Here there is no difference in meaning between these two symbols.

The YYYY-MM-DD and HH-MM represent the date and time that the script should be launched. The four YYYY digits represent the year (e.g., 2001), the next two MM digits represent the month (01 through 12) and the last two DD digits specify the day (01 through 31). The time HH-MM is specified in European or Military time, as a string of four digits. The first two HH digits specify the hour (00 through 23) and the next two MM digits specify the minute (00 through 59). If SelfMaint is started after the specified time, the script will be scheduled to run immediately. Instead of YYYY-MM-DD.HH-MM, it is possible to specify the string "ASAP". This will guarantee that the script will be scheduled to run immediately.

You should use an update script instead of a one-time script if the script has any chance of changing PISMERE_VERSION. In this case, omit Ver, and SelfMaint will check the value of PISMERE_VERSION at the end of the script. If the script has no chance of changing PISMERE_VERSION, you should not omit Ver. Otherwise, the script should have been configured as a One-time script.

Examples:

"Update(3.4.5).2001-12-25.01-23": Launch the script at 1:23 AM on December 25, 2001. If SelfMaint is started after this time, launch the script immediately. Upon completion of the script, change PISMERE_VERSION to 3.4.5.

"Update().2001-12-25.01-23": Launch the script at 1:23 AM on December 25, 2001. If SelfMaint is started after this time, launch the script immediately. Upon completion of the script, check PISMERE_VERSION for changes.

"Update().ASAP": Launch the script immediately. Upon completion of the script, check PISMERE_VERSION for changes.

4.2.6. Cleanup Scripts
A cleanup script will be launched upon user log out. A machine will launch at most ONE cleanup script. Of the set of cleanup scripts which may apply to the current machine, only the one located deepest in the directory structure will be run. Like all other scripts, cleanup scripts are subject to the constraints of inherit flags, versioning, and blocking. Therefore the machine will look for a proper-versioned cleanup script in the deepest directory, and if one does not exist there, it will select the first proper-versioned non-blocked inheritable cleanup script it finds in higher directories as it ascends through the tree. NOTE: If there are two or more such scripts in one directory, it will pick one of them in an undefined manner. Therefore, do not place two or more cleanup scripts in the same directory unless they are mutually exclusive.

The Script Type string for a cleanup script is simply:

'C' [ist:optional letters]

The 'C' flags the script as an update script. Additional letters may be included to make this more readable (e.g., "Cleanup").

4.3. Back To Script Naming

Recall that the naming convention is:

['I' [ist:additional letters] '.'] [ist:Version Interval '.'] Script Type [ist:'.' optional Additional Descriptive Information] '.' Extension.

The additional descriptive information is anything that you need to add to the script name to make it more readable, or to differentiate it from another script with identically encoded version intervals and script types.

The extension determines whether the file is executed directly or called by a particular scripting engine. Scripts with the extensions ".wsf", ".wsh", ".jse", ".js", ".vbe" or ".vbs" will be launched with "cscript.exe". Scripts with the extension ".pl" will be launched with "perl.exe". (Note, this means that perl.exe should reside in the system path.) All other scripts (e.g., with extensions ".exe", ".bat", and ".cmd") will be executed directly.

Examples:

"Inherit.Version[1.2.3,1.2.9).Periodic.2002-02-02.02-00.12hours.MyScript.wsf": This inheritable script will launched with cscript.exe, only on machines whose Pismere Version is at least 1.2.3 but strictly less than 1.2.9. It is a periodic script that will first be launched at 2:00 AM on February 2, 2002, and will run every 12 hours after that. That is, at 2 AM, at 2 PM, at 2 AM on February 3, etc. If SelfMaint is launched after 2 AM on February 2, 2002, it will run the script immediately, and then at these subsequent times.

"I.V[1.2.3,1.2.9).P.2002-02-02.02-00.12h.MS.wsf": This script will behave identically to the previous script. The difference is purely cosmetic.

"Daily.02-30.MyScript.exe": This uninheritable script will run on all machines located in this directory (not above). It will be launched every day at 2:30 AM.

"I.V[ist:1.2.5].O.ASAP.MyScript.pl": This inheritable script will only run on machines whose Pismere Version is 1.2.5. It will be launched immediately with perl.exe, and only once.

"I.V[ist:1.2.5].Update[ist:1.2.6].ASAP.First.cmd": This inheritable script will update machines running Pismere Version 1.2.5 to 1.2.6.

"I.V[ist:1.2.6,].Once.ASAP.Second.wsf" This one-time inheritable script will only run once the Pismere Version is 1.2.6 or greater. Note that the script in the previous example will always run before this one. Therefore, one can use versioning in this way to force scripts to run in a particular order.

The configuration file "SelfMaint.conf"

The configuration file "SelfMaint.conf" provides a method to configure some parameters of the SelfMaint service. The file should be located in the same directory as "selfmaint.exe". SelfMaint.conf ignores lines that start with "#". Each line that does not start with "#" should be a single parameter name followed by an equal sign, and then the appropriate value for that parameter. The parameters are as follows:

MAINTDIR: the fully qualified path of the maintenance script root directory. UNC paths are fine. Environment strings will be expanded.

LOGFILE: the fully qualified filename in which to store the record of successfully run scripts. This should be in a secure directory (only Administrators should have access to it) on the local computer. Environment strings will be expanded.

DESYNC: a non-negative integer representing the number of minutes to desynchronize when launching a script or accessing the MAINTDIR directory. For instance, if this number is 60, scripts will be launched anywhere from 0 to 60 minutes after the nominal launch time. Larger values alleviate network congestion; lower values effectively speed up network access. This number should be proportional to the number of machines running the SelfMaint service concurrently. For WIN machines, at least initially, 5 or 10 should be fine.

UPDATE: a non-negative integer representing the number of minutes to wait between checks for changes in the MAINTDIR directory. The service will only check while no users are logged in. If this number is 20, the system will catch new script files every 20 minutes when no users are logged in. Unless the script directory is changing very often, it is probably unnecessary for this number to be much less than a day (1440).
The following is an example selfmaint.conf file:
# Example SelfMaint.conf file - this is a comment line MAINTDIR = \\win.mit.edu\dfs\ops\auto\operational\scripts\machine\maintenance\LogFile= %SystemDrive%\selfmaint.log DeSync=10 Update = 720

Installation

You can simply use the msi file to install. If so, the string registry value HKLM\Software\MIT\Pismere\PISMERE_VERSION will not be set, causing SelfMaint to decide the version is "the Unknown Version", or "-1.-1.-1". Thus, you should make sure to have a single script in the "-1.-1" subdirectory which updates the version to the desired value (such as "0.1.0").

If you do not have the msi, one must first self-register selfmaint.dll. (Go into the path with selfmaint.dll, and "regsvr32 selfmaint.dll") Then SelfMaint should be installed (In the path with selfmaint.exe, "selfmaint.exe-install"). It is important that selfmaint.conf be located in the same directory as selfmaint.exe. Also, you should set the string registry value HKLM\Software\MIT\Pismere\PISMERE_VERSION to the appropriate level, most likely "0.1.0" to start with. After this is all done, reboot the machine.

Example LOGFILE

The following log entries originally were prepended with:
\\win.mit.edu\dfs\ops\auto\operational\scripts\machine\maintenance That string is removed for legibility: -1.-1\i.update(0.1.0).2001-01-01.00-01.record.cmd 2002-11-22 12:38 0.1\i.once.2001-04-30.12-01.installdsa.cmd 2002-11-22 12:38 0.1\i.once.2001-04-30.12-02.installtsadmin.cmd 2002-11-22 12:38 0.1\i.cleanup.cmd 2002-12-13 15:02
0.1\i.daily.02-05.installmsiv2.wsf 2002-12-16 02:09 0.1\i.daily.03-00.copydefaultuser.cmd 2002-12-16 03:04 0.1\i.daily.03-30.autohotfixer.cmd 2002-12-16 03:34 0.1\i.daily.03-45.newafsdcell.cmd 2002-12-16 03:49 0.1\i.daily.04-00.oucheck.cmd 2002-12-16 04:04

Liberal Examples

Here is a set of liberal script names which do not conform to the naming convention, but which nonetheless are correctly interpreted by SelfMaint. Also listed are some reasonable-looking script names which will NOT be properly interpreted by SelfMaint.

Examples:

"Inherit.Version[1.2.3,1.2.9).Periodic.2002-02-02.00-00.12hours.MyScript.wsf": Conforms to the naming convention.

"Inherit-Version[1.2.3,1.2.9)-Periodic-2002-02-02-00-00-12hours-MyScript.wsf": Does not conform, but is correctly interpreted. Periods, hyphens, underscores and commas can be used as delimiters. However, only the period is recommended.

"Inherit.Version[1.2.3,1.2.9).Periodic.200202020000.12hours.MyScript.wsf": Does not conform, but is correctly interpreted. When SelfMaint expects a date and time (or just a time in the Daily case), it looks for the proper number of digits (in this case twelve) and ignores all non-digit characters until the end of these digits.

"Inherit.Version[1.2.3,1.2.9).Periodic.2002.02.02.00.00.12hours.MyScript.wsf": Does not conform, but is correctly interpreted for the same reason as above.

"Inherit.Version[1.2.3,1.2.9).Periodic.2002-02-02.12hours.MyScript.wsf": Does not conform, and is NOT correctly interpreted. The time field has been omitted. In this case, the 12 in "12hours" will be interpreted as the time. Therefore, the script will be launched at NOON on the launch date, and the period will turn out to be ZERO, not twelve hours. Thus, this supposedly periodic script will run only once, at the wrong time.

"Inherit.Version[1.2.3,1.2.9).Periodic.2002-02-02.00-00.12-hours.MyScript.wsf": Does not conform, and is NOT correctly interpreted. The delimiter after the 12 will fool SelfMaint into thinking that the remainder of the filename is a comment. Therefore, the 12 will not be multiplied by "hours", and the period will turn out to be ZERO. Thus this supposedly periodic script will run only once.

WIN Scripts

The following is a description of the scripts that run automatically in the domain. The descriptions are informational only - scripts can change independent of this document, so for the final word please go to the source.

Startup (after boot, System Context):

\\win.mit.edu\dfs\ops\auto\operational\scripts\machine\startup\startup.wsf (Windows Script Host file, written in VBScript)

Runs "OUCheck," which checks to see if the machine OU (container) in Active Directory has changed. If so, reboots the machine.
Runs "Cleanup-Weird-Profile," which works around a Win2K SP3 related bug. Sometimes a user profile with a name of three Unicode characters (0x5359, 0x5354, 0x454D) appears. This is actually supposed to be six ASCII characters (0x53 0x59 0x53 0x54 0x45 0x4D). This code renames this directory "~SYSTEM."
Wshelp32.dll is copied into the path if it is not there already. This is another workaround.
Runs "GPNetPrintInstall," which installs both network printers (\\servername\printername) and KLPR printers (printers with Athena print queues) on machines, based on group policy settings. Details about these installations are available on request or elsewhere.
Runs "SetRootPassword," which enforces the WIN root password group policy for the machine.
Runs "LockCDrive," which re-establishes default file permissions at the root of the system drive.
Runs "SetAthenaSys," which makes sure the environment variable ATHENA_SYS is set to i386_nt40.
Runs "CopyDefaultUser," which copies a default user profile from \\win.mit.edu\netlogon to the local machine.
Runs "DenyAdmin," which revokes logon-remotely privileges from the Administrator account.
Runs "LocalRights," which revokes logon-locally privileges to the group WIN\interactive.not
Runs "Spnfix," which sets the servicePrincipalName and DNSHostName properties of the machine in Active Directory (via the spnfixd server).

\\win.mit.edu\dfs\ops\auto\operational\scripts\hotfix\autohotfixer.pl

Runs "AutoHotfixer," which installs IS&T-approved Microsoft hotfixes.

Shutdown (before shutdown, System Context):

\\win.mit.edu\dfs\ops\auto\operational\scripts\machine\shutdown\shutdown.wsf

Does nothing. Yet.

Cleanup (after user logoff, System Context):

\\win.mit.edu\dfs\ops\auto\operational\scripts\machine\maintenance\0.1\i.cleanup.cmd, which launches \\win.mit.edu\dfs\ops\auto\operational\scripts\machine\startup\cleanup.wsf

Runs "GPNetPrintInstall."
Runs "SetRootPassword."
Runs "LockCDrive."
Runs "CopyDefaultUser."
Runs "DenyAdmin."
Runs "LocalRights."
Runs "OUCheck."

Logon (during user logon, User Context):

\\win.mit.edu\dfs\ops\auto\operational\scripts\user\logon\logonbefore.wsf (runs immediately on logon, before Explorer is launched. This is run as an aklogon startup script.)

Sets a group policy related DeleteRoamingCache registry key to zero.
Maps Z: to \\afs\all
Sets the APPDATA environment variable to the appropriate value.
Runs "GpNetPrintDefault," which sets the user's default printer as specified in machine group policy.
Runs "Tix-Tox," which runs ms2mit and k524init.
Runs "CopyWinData," which creates the WinData subdirectory of the user's home directory if it does not already exist.

\\win.mit.edu\dfs\ops\auto\operational\scripts\user\logon\logonafter.wsf (runs after Explorer is launched. This is run in Group Policy via User Configuration\Administrative Templates\System\Logon/Logoff\Run these programs at user logon).

Runs a file named ".winlogon" with an executable extension in the user's home directory, if such a file exists.

Logoff (before user logoff, User Context):

\\win.mit.edu\dfs\ops\auto\operational\scripts\user\logoff\logoff.wsf

Runs "SetHomeVars," which properly sets the user HOMEDRIVE, HOMESHARE, and HOMEPATH environment variables. (For some reason these variables get unmapped before the logoff script runs.)
Checks group policy for DeleteRoamingCacheWorkaround, and sets the related registry key to one if the group policy specifies.
Erases any MIT submenu of the Start Menu, if one exists (cleans up AddMenu).
Runs "Tix-Tox" and aklog... if the Microsoft kerberos tickets are still valid, this will allow the user's profile to be saved back into AFS.
Runs a file named ".winlogoff" with an executable extension in the user's home directory, if such a file exists.

Scheduled (run by SelfMaint, System Context):

Under \\win.mit.edu\dfs\ops\auto\operational\scripts\machine\maintenance\0.1:

i.once.2001-04-30.12-03.installmsiv2.wsf: Installs Microsoft Installer version 2 unless it is already installed
i.daily.02-05.installmsiv2.wsf: Ditto
i.daily.03-00.copydefaultuser.cmd: Runs "CopyDefaultUser"
i.daily.03-30.autohotfixer.cmd: Runs "AutoHotfixer"
i.daily.04-00.oucheck.cmd: Runs "OUCheck"
i.once.2001-04-30.12-01.installdsa.cmd: Copies the Active Directory Users and Computers snap-in into Restricted Snap-Ins, and removes it from the System32 directory.
i.once.2001-04-30.12-02.installtsadmin.cmd: Copies the Terminal Services Administration component into Restricted Snap-Ins.
i.periodic.2000-01-01.00-00.3hours.gpnetprintinstall.cmd: Runs "GpNetPrintInstall".
i.periodic.2002-07-23.03-00.28days.realplayer_upgrade_disabler.vbs: Supposedly puts off the RealPlayer upgrade nag notice for approximately a month. Does not seem to work.
i.weekly.03-45-thurs.newafsdcell.cmd: Copies \\afs\athena.mit.edu\service\CellServDB to %SystemRoot%\afsdcell.ini.

Related Links

The win.mit.edu Domain
Windows Server Platforms

IS&T Contributions

Documentation and information provided by IS&T staff members


Last Modified:

March 03, 2016

Get Help

Request help
from the Help Desk
Report a security incident
to the Security Team
Labels:
gp gp Delete
grouppolicy grouppolicy Delete
m-hermes m-hermes Delete
windowsdomain windowsdomain Delete
serverservices serverservices Delete
c-win-mit-edu c-win-mit-edu Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
Feedback
This product/service is:
Easy to use
Average
Difficult to use

This article is:
Helpful
Inaccurate
Obsolete
Adaptavist Theme Builder (4.2.3) Powered by Atlassian Confluence 3.5.13, the Enterprise Wiki