Group Policy and win.mit.edu
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.
- 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.
[Back
to top]
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. To see recent snapshots
of win.mit.edu policy, see GPMC
reports.
[Back
to top]
Description
of Domain-Level Tools
Self-Maintenance
Service
1. 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.
2. General
SelfMaint Behavior
Automatic scripts (cleanup, daily, weekly,
periodic, one-time, and update scripts)
located in the scripts directory (specified
by MAINTDIR in 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 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
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 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 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).
3. 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:
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.
The name of a scheduled script determines
which machines (in the appropriate object
container) will run it and when. The naming
convention is:
['I' [additional letters] '.'] [Version
Interval '.'] Script Type ['.' 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 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' [optional characters] LeftDelim
[optional MinVer] ',' [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 '['. 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[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' [optional characters] LeftDelim
[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[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[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' [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' [optional letters] '.' HH '-' MM
'.' DayOfWeek [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' [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' [optional letters] '.' YYYY '-'
MM '-' DD '.' HH '-' MM '.' PdMagnitude
PdUnit [PdMagnitude PdUnit [Pd Magnitude
PdUnit [...]]]
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' [optional letters] LeftDelim [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 '['. 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' [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' [additional letters] '.'] [Version
Interval '.'] Script Type ['.' 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[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[1.2.5].Update[1.2.6].ASAP.First.cmd":
This inheritable script will update machines
running Pismere Version 1.2.5 to 1.2.6.
"I.V[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"
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).
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.
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.
"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.
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.
\\win.mit.edu\dfs\ops\auto\operational\scripts\machine\startup\startup.wsf
(Windows Script Host file, written in VBScript)
\\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
\\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.)
\\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).
