The win.mit.edu Domain

Windows Server Platforms

win.mit.edu Extensions to Group Policy

Introduction

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

• Root Password/Force a Well-known Root (Administrator) Password
• Auto Rebooter Behavior/Opt Out of Domain-wide Reboots
• Printers/Install These Network Printers
• Printers/Install These KLPR Printers
• Printers: Special-Cased Drivers
• Internet Explorer/Deploy Internet Explorer 6.0 SP1 (v 6.0.2800.1106)
• Sendbug/Choose Locations of Sendbug Configuration Files
• Logoff Scripts/Run These Programs at User Logoff
• Event Log/Restrict Remote Viewing of Event Logs
• System Path: Fix System Path
• OpenAFS Settings: Fail Logins Silently, Freelance Client, Show Tray Icon, Use Kerberos 4, AFSCreds Shortcut
• Folder Redirection Settings: Always map home drive locally
• Vista Settings

Note: To view these settings with the GP editor, you must first go to the View menu and uncheck Show Policies Only. This is unfortunately checked by default, but once you uncheck it, it should stay that way on subsequent launches of the GP editor.

[Back to top]

Root Password/Force a Well-known Root (Administrator) Password

By default, all win.mit.edu machines have a well-known local Administrator password. (This mirrors UnixAthena's well-known root password.) For all win.mit.edu machines, the local Administrator account cannot access the machine remotely. Therefore, the well-known password only allows users with physical access to the machine to gain administrative access. This policy allows the Administrator password behavior to be customized on the affected machines:

If this policy is disabled, affected machines will not force the local Administrator password, and thus the local Administrator password can be set on a per-machine basis. This is the best choice for machines that you do not want to have a well-known Administrator password.

If this policy is enabled, affected machines will force their Administrator password to be the value you specify. If you check "Sync to Athena", the Administrator password will be set to that of Athena (the result of "tellme root" on a public Athena machine), and any value typed below will be ignored. (See the above image for an example. Note that here the root password is specified and not synchronized to Athena.)

If this policy is not configured, affected machines will defer to higher-level GP. A GPO at the Machines level enables this setting and synchronizes the password to Athena.

[Back to top]

Auto Rebooter Behavior/Opt Out of Domain-wide Reboots

Occasionally win.mit.edu will be upgraded in such a way that all machines in the domain should be rebooted to function properly. For instance, newly deployed msi software will only install upon reboot. On these occasions, a domain-wide reboot will be scheduled and run automatically by the SelfMaint program. These reboots will be announced in advance, scheduled for the middle of the night, and will never force a logout (SelfMaint always waits until no users are logged in before it runs any tasks.) This policy allows affected machines to opt out of such reboots. If this policy is disabled, it allows selfmaint to perform domain-wide reboots.

If this policy is enabled, affected machines will not reboot when directed to by selfmaint. It is then the responsibility of the administrator to reboot the machine.

It is recommended to leave this setting Not Configured or Disabled.

[Back to top]

Printers/Install These Network Printers

Network printers are printers which are shared by a Windows machine in the domain. If the server is named "server.mit.edu" and the shared printer is "printername", then the full name of the network printer is "\\server.mit.edu\printername". Any printer published in the Active Directory will be of this form.

If this policy is enabled, the network printers specified in the list box (click Show... to view/edit) will be installed so that all users of the affected machines can print to them. The listbox should contain only printers shared via a server in the domain, of the form "\\server.mit.edu\printername". Make sure to fully qualify the name of the server, including the domain suffix. Do NOT use the form "\\server\printername". (See the above image for an example.)

You can also specify a default printer by typing its name in the "Default printer" edit box. (Use the same "\\server.mit.edu\printername" format, making sure that it is one of the printers from the list box.) This printer will be forced to be the default for all users who log on to the affected machines. If this box is left blank, the default printer will not be forced.

If the "Delete network printers if..." checkbox is checked, other network printers which may have been previously installed on the affected machines (even via this policy) will be deleted. If the checkbox is unchecked, such printers will remain installed on affected machines. It is recommended to check this box as it will tend to "clean up" unwanted network printers. (Note: this will not affect or delete local printers on the machines, including KLPR printers. It will also not affect or delete any per-user printers.)

If this policy is disabled, network printers will not be managed via group policy on the affected machines.

[Back to top]

Printers/Install These KLPR Printers

KLPR printers are printers which use Kerberos authentication for TCP/IP printing. Specifically, the printers installed by this GP setting must be Athena print queues. To get a list of all such printers in public clusters, type "cview printers" at a command prompt or read the Athena Clusters Pocket Reference. Other Athena print queues exist in private clusters. To find out if a particular printer has an Athena print queue, type "lpq -Pprintername" at a command prompt. If there is an error, there is probably no Athena print queue with that name. If there is a list of jobs (or "no jobs"), then the name is a valid Athena print queue and can be installed via this GP setting.

If this policy is enabled, Athena print queues specified in the listbox (click "Show..." to view/edit) will be installed locally via KLPR ports on the affected machines. (See the above image for an example.) The listbox should contain the name of the print queues (such as "ajax", "ceres", etc.) in the first column, and it should contain the exact names of the appropriate Windows PostScript printer drivers (such as "HP LaserJet 8100 Series PS", "HP LaserJet 5Si/5Si MX PS", etc) in the second column. It is very important that both are correctly spelled; do not attempt to fully-qualify the print queue names (they do not end in ".mit.edu"), and you must be especially careful with the driver name.

A word about printer drivers:

If you do not know the driver name for a particular print queue, leave the driver entry blank (see the entry for "ceres" in the image above). An appropriate driver will be chosen for you. The print queue will be looked up in a list of printer-to-driver mappings. If the print queue does not appear on the list, the generic driver "MS Publisher Color Printer" is used.

If you do not want the driver to be chosen for you, make sure you type in the name of a PostScript driver, and that this exact name appears in either the full list of Windows 2000/XP printer drivers or our list of special-cased drivers. (You may want to use the clipboard to copy from these lists and paste into the GP editor. If you mistype the driver name, you may end up specifying a different driver or getting a generic driver.)

You can also specify a default print queue by typing the queue name ("ajax", "ceres", etc. It must be one of the printers from the list box) in the "Default printer" edit box. This printer will be forced to be the default for all users who log on to the affected machines. (Note: the similar setting in the Network Printer policy will take precedence, if specified.) If this box is left blank, the default printer will not be forced.

If the "Delete KLPR printers if..." checkbox is checked, other KLPR printers which may have been previously installed on the affected machines (even via this policy) will be deleted. If the checkbox is unchecked, such printers will remain installed on the affected machines. It is recommended to check this box as it will tend to "clean up" unwanted KLPR printers. (Note: this will not affect or delete non-KLPR printers on affected machines, including network printers. It will also not affect or delete any per-user printers.)

If this policy is disabled, KLPR printers will not be managed via GP on the affected machines.

[Back to top]

Printers/Install These KLPR Printers: Special-Cased Drivers

Generally, in order for a driver to be available to be installed by this policy, it must be one of the many drivers that come with Windows. It is very likely that this list either contains a driver for your exact printer model or for a printer model which is close enough to work. At worst, the generic Postscript driver "MS Publisher Color Printer" should work well enough to print.

It is possible that no driver which comes with Windows is sufficient for a particular printer model, and that the exact printer driver is required. In these cases, the printer driver can be placed on our dfs share and installed over the network, but it must be special-cased by our installation script, so that the script knows the driver name and where the configuration files reside.

Currently, there are two such special-cased drivers: "HP LaserJet 8150 PS" and "HP Color LaserJet 8550 PS".

The relevant portion of the script is shown below. If you want to add an entry to this list and cannot get an existing driver to work, and have successfully tested the driver installation for the particular printer, please send us this information.

# The following is a list of extra drivers which do
# not come with Windows 2000 or XP. For each driver
# it lists both the exact driver name and the location
# of the .inf file which installs it.

my %SpecialCasedDrivers = (
"HP LaserJet 8150 PS" =>
"%programfiles%\\MIT\\mirror\\distrib\\print-drivers\\hp8150ps\\hp8150ps.inf", 
"HP Color LaserJet 8550 PS" =>
"%programfiles%\\MIT\\mirror\\distrib\\print-drivers\\hp8550ps\\HP402Ips.inf",  
);

[Back to top]

Internet Explorer/Deploy Internet Explorer 6.0 SP1 (v 6.0.2800.1106)

GP can be used to easily deploy software which has an .msi installer. Curiously, no such installers exist for any version of Microsoft Internet Explorer. Consequently, installing newer versions of this software remotely and non-interactively (without having an administrator visit each machine) is somewhat more involved. The purpose of this GP setting is to allow container administrators to install a recent version of Internet Explorer on a set of machines.

If this policy is enabled, Microsoft Internet Explorer version 6.0 SP1 (v 6.0.2800.1106) will be deployed to the affected machines. (See the above image for an example.)

In the edit box labeled"Minimum Acceptable Version", enter a version number in dotted notation (major, major.minor, major.minor.patch, etc). If the version of Internet Explorer installed on the machine is at least this version, it will NOT be upgraded to IE6SP1. For instance, if you specify "5.50", then machines with IE5.0 or IE5.01 (v 5.00.*) will be upgraded, but machines with IE5.5 (v 5.50.*) or IE6.0 (v 6.00.*) will not. If you want all machines to be upgraded, enter the version "6.0.2800.1106" or leave the setting blank. This will force any machine without IE6SP1 to take IE6SP1.

About the advanced "Maximum # of times" option: The IE6SP1 installer will most likely only run once. However, in the unlikely event that the installer both fails and reboots the machine, it could go into an infinite loop. In order to prevent this, there is a maximum number of times per day to run the installer. The default is 3. You can change this if you want, but it must be at least 1. You probably do not need to touch this setting.

If this policy is disabled, IE6SP1 will not be deployed. Note that this can not be used to uninstall IE6SP1. Disabling the policy will not change the current version of IE on the machine.

[Back to top]

Sendbug/Choose Locations of Sendbug Configuration Files

Sendbug is an application (available by typing sendbug at a command prompt on a win.mit.edu machine) which automatically collects status information about the machine, and helps the user file an email bug report. There are two configuration files which determine how Sendbug behaves. "Category.ini" specifies where the bug reports will be sent. "Problem.ini" specifies what information is collected from the machine.

If this policy is disabled, Sendbug will first look for these files in %ProgramFiles%\MIT\Sendbug\ on the local machine. If a file is not found there, Sendbug will then use the default files found in \\win.mit.edu\dfs\ops\distrib\sendbug\ on the network.

If this policy is enabled, Sendbug will first look for these files in the full path locations specified in the edit boxes. (See the above image for an example.) These locations can be network paths (e.g., "\\win.mit.edu\dfs\departmental\mycontainer\sendbug\"), or local machine paths (e.g., "%SystemDrive%\mydir\"). They can include environment variables encased between percent symbols (e.g., "%ProgramFiles%\somedir\"). They can also specify the exact file name, which is useful if you do not want to use the default value of "category.ini" and "problem.ini" (e.g., "%SystemDrive%\mydir\myproblem.ini"). When specifying a directory, the trailing backslash is not necessary, but helps distinguish it from a file with no extension. If you specify only a file name and not a full path, Sendbug will look for this file in the %SystemRoot% directory.

Note that the default values which initially populate the edit box when you enable the policy correspond to the default files on the network. This is useful if you want to guarantee that Sendbug uses these default files instead of ones which may be on the local machine.

If the policy is enabled but Sendbug cannot find a file in the location specified in the edit boxes, it reverts to looking for this file in %ProgramFiles%\MIT\Sendbug\ and then in \\win.mit.edu\dfs\ops\distrib\sendbug\.

If this policy is not configured, affected machines will defer to higher-level GP. A GPO at the Machines level disables this setting.

[Back to top]

Logoff Scripts/Run These Programs at User Logoff

The GP setting "Computer Configuration\Administrative Templates\System\Logon\Run these programs at user logon" allows a set of scripts/programs at user logon, in user context, on a per-machine basis. However, there is no analogous setting to allow scripts to run at user logoff, in user context, on a per-machine basis. This extension is meant to emulate the behavior of such a setting.

If this policy is enabled, when a normal domain user (whose account exists in the Moira\users container) logs off of an affected machine, the machine will run the scripts listed in the Show window, in user context.

To use this setting, click Show. For each program that should be run, click Add, and type the name of the program to run (followed by any command-line arguments or parameters) in the text box. (See the above image for an example.)

Caveats and notes:

• Unless the file is located in the %SystemRoot% directory or accessible via the user's %Path% environment variable, you must specify the fully qualified path to the file. It is always a good idea to specify the full pathname to avoid confusion. The full pathname should be either a valid local or UNC pathname. If the pathname is invalid, the script will not be run.
  
  
• You may also use environment variables encased in parentheses; these variables will be expanded automatically. This is preferable to using hardcoded local pathnames. For example, "%SystemRoot%\Hard-coded-Paths-are-Fragile.pl" is much better than "C:\Windows\Hard-coded-Paths-are-Fragile.pl", given that machines are not guaranteed to have a "Windows" directory or even a C drive. If the specified directory/file does not exist, the script will not be run.
  
  
• The programs must be accessible to the domain user who is logging out. If the specified server/share or filesystem permissions deny read access to the user, the script will not be run.
  
  
• If there are spaces in the program name, enclose it in quotes, in order to distinguish the program name from any command-line arguments you may wish to pass. Beware that if you use environment variables, there may be spaces in the expanded name, and you should use quotes just in case. For example, on most systems, %ProgramFiles% will expand out to something like C:\Program Files. In such a case, "%ProgamFiles%\Widget\Quotes-are-Important.cmd" will work, but %ProgamFiles%\Widget\Probably-Fails-to-Run.cmd will not. It is also important to encase with quotes any command-line parameters which contain spaces. If the program name contains a space and is not encased in quotes, the script will not be run.
  
  
• Scripts will be run in the order they appear in the Show window. Unfortunately, the listbox will automatically arrange the scripts in alphabetical order. This means that scripts will be run in alphabetical order, and you have no control over this. (The same is true for the "Computer Configuration\Administrative Templates\System\Logon\Run these programs at user logon" setting.) If the order is important to you, you should write a single script which launches the other scripts in the desired order, and specify only this one script via GP.
  
  
• User logout will not complete, and the user's profile will not be saved or synchronized until all the scripts are completed. Therefore, you should not use this policy to run any scripts which "hang" or which take a very long time to complete. It is also not recommended to run any program which requires user input, because the user may have already left the computer.
  
  
• This policy is not an exact complement to "Computer Configuration\Administrative Templates\System\Logon\Run these programs at user logon". While the logon script setting will run for any user who logs on to the system, including local machine accounts, the logoff script setting only applies to domain accounts in the Moira/users container. Local machine accounts will not run these scripts. Please keep this in mind.

If this policy is disabled, no per-machine scripts/programs are run at user logoff. If this policy is not configured, affected machines will defer to higher-level group policy. A GPO at the Machines level disables this setting.

[Back to top]

Event Log/Restrict Remote Viewing of Event Logs

By default, Windows 2000, XP and Server 2003 machines allow all Authenticated Users to remotely view the System and Application Event Logs. In a domain like Win.Mit.Edu, Authenticated Users include thousands of people, most of whom you as container administrator may not want to grant this privilege.

If this policy is disabled, all Authenticated Users will be able to remotely view the machine's System and Application Event Logs.

If this policy is enabled, only members of the machine's Administrators group will be able to remotely view these Event Logs.

If this policy is not configured, this privilege will not be affected by Group Policy.

WARNING: This setting can potentially conflict with "Computer Configuration/Security Settings/Local Policies/Security Options/Network access: Remotely accessible registry paths". At most one of these settings should be configured at the same time. Configuring both settings may cause unexpected behavior.

[Back to top]

System Path

Fix System path

If this policy is enabled, the system's PATH environment variable will periodically be automatically fixed to remove duplicate entries and superfluous characters. Checking 'test accessibility' will also test the entries in the system path for accessibility. If they are not accessible a warning will be logged. Checking 'aggressively' will remove ill-formed entries as well as entries which are considered duplicates only after expansion of variables.

If this policy is disabled, the system's PATH environment variable will never be automatically fixed.

If this policy is not configured, affected machines will defer to a higher-level group policy. A group policy object at the Machines level enables this setting.

[Back to top]

OpenAFS Settings

Fail Logins Silently

If this policy is enabled, the OpenAFS client will not report errors at user logon. This is useful for machines which often experience disconnected logons.

If this policy is disabled, the OpenAFS client will report any errors obtaining tokens at user login.

If this setting is not configured, this feature can be configured locally for each machine. It is recommended to enable this setting for machines where disconnected access is common, and to leave the setting disabled or not configured for machines which are usually connected to the network.

Freelance Client

If this policy is enabled, the OpenAFS client will operate in Freelance Mode. This means that the root of AFS (dir \\afs\all) only contains the cells you've used and not all the cells listed by athena.mit.edu. While making it more difficult to enumerate cells, this allows OpenAFS to start when not connected to the network. This is useful for machines which often experience disconnected boots.

If this policy is disabled, the OpenAFS client will not operate in Freelance Mode. It will obtain the list of available cells from athena.mit.edu at startup. This requires the machine to be connected to the network for OpenAFS to start.

If this setting is not configured, this feature can be configured locally for each machine. It is recommended to enable this setting for machines where disconnected access is common, and to leave the setting disabled or not configured for machines which are usually connected to the network.

Show Tray Icon

If this policy is enabled, the OpenAFS client will not run the 'Authentication for AFS' system tray application (AFSCreds.exe) when users log in (unless the particular user's registry or profile overrides this). This is desirable in the Win.Mit.Edu domain because the tray application tends to conflict with the normal login process.

If this policy is disabled, the OpenAFS client will run the tray application when users log in (unless the particular user's registry or profile overrides this). This is not recommended. If this policy is not configured, this feature can be configured locally for each machine. It is recommended to enable this setting, and it is currently enabled domain wide.

Use Kerberos 4

If this policy is enabled, the OpenAFS client will convert the current Kerberos 5 tickets to Kerberos 4 tickets and use the Kerberos 4 tickets to obtain AFS credentials. This is only necessary for AFS cells which do not support Kerberos 5, which is generally not the case. If this policy is disabled, the OpenAFS client will use the Kerberos 5 tickets to optain AFS credentials.If this policy is not configured, this feature can be configured locally for each machine.

AFSCreds Shortcut

If this policy is enabled, the OpenAFS client will configure the 'Authentication for AFS' system tray application's shortcut with the parameters specified in the editable text box. The default value is '-A -N -Q'. Other possible options are listed below the text box. WARNING: Take care only to specify valid and desired options, as the editable text box will accept any input value, including invalid and undesired options.

If this policy is disabled, the OpenAFS client will configure the tray application's shortcut with no parameters. If this policy is not configured, this feature can be configured locally for each machine. It is recommended to not configure this setting or to enable it with the default value.

[Back to top]

Folder Redirection Settings:

Always map home drive locally

If this policy is enabled the Homedrive will be mapped to the local profile directory. If you use this setting, this will be the behavior regardless of whether or not you are disconnected from the network.

[Back to top]

Vista Settings

Disable Desktop-Sync

If this policy is enabled the Vista<->XP Roaming Profile Desktop Syncronizstion will no longer run. This setting is only recommended if your users no longer logon to XP and 2003 machines.

[Back to top]