Scripts
With the Scripts extensions, you can assign scripts to run when the computer starts or shuts down or when users log on or off their computers. For this purpose, you can use Windows Scripting Host to include both Visual Basic® Scripting Edition (VBScript) and Jscript® development software script types.
Windows 2000 includes Windows Scripting Host, a language-independent scripting host for 32-bit Windows platforms. Microsoft anticipates that other software companies will provide ActiveX® scripting engines for other languages, such as Perl, TCL, REXX, and Python.
For more information about Windows Scripting Host, see http://www.microsoft.com/scripting.
The names of scripts and their command lines (in the form of registry keys and values) are stored in the Registry.pol file, described later in this document.
Types of Scripts
The five script types are as follows:
Group Policy logon scripts.
Group Policy logoff scripts.
Group Policy startup scripts.
Group Policy shutdown scripts.
Legacy logon scripts (those specified on the User object). This includes support for Windows Scripting Host3 scripts. Windows Script Host supports scripts written in VBScript or JavaScript. This means that you can now enter a command line like sample.vbs in the logon script path of the user object.
Note: Consider carefully how to use such scripts if you have a mixed environment that includes Windows NT 4.0, Windows 95, Windows 98, and Windows 2000 clients. The Windows 2000 and the Windows 98 clients will properly run .vbs and .js scripts. To run .vbs and .js scripts on Windows NT 4.0 and Windows 95 clients, you must embed the scripts in batch (.bat) files. The scripts continue to run in a normal window. There is a policy that allows for scripts to be run as hidden or minimized. You can also install Windows Scripting Host on Windows NT 4.0 and Windows 95 clients. For information on Windows Scripting Host, see http://msdn.microsoft.com/scripting/windowshost/default.htm.
By default, each of these script types runs asynchronously, and the window is hidden. User logon and logoff scripts run as the user (not administrator), and computer logon and logoff scripts run as local system.
Specifying Policy Settings for Script Behavior
The following table lists the Group Policy options that are available to control the behavior of scripts.
Policy in Computer Configuration\Administrative Templates\System\Logon
|
Description
|
Run logon scripts synchronously
|
When this option is enabled, the system waits until the script finishes running before it starts Windows Explorer.
Note that an equivalent option for this is available under the User Configuration node. The policy setting you specify in the Computer Configuration node has precedence over that set in the User Configuration node.
|
Run startup scripts asynchronously
|
By default, startup scripts run synchronously and hidden, which means the user cannot logon until the scripts complete. In some corporations, the administrator might want the scripts to run asynchronously since they could take a long time to complete. This policy allows the administrator to change the default behavior.
|
Run startup scripts visible
|
If this option is enabled, startup scripts run in a command window.
|
Run shutdown scripts visible
|
If this option is enabled, shutdown scripts run in a command window.
|
Maximum wait time for Group Policy scripts
|
This policy setting lets you change the default script timeout period. (By default, scripts will timeout after 600 seconds). The range is 0 to 32000 seconds.
|
Policy in User Configuration\Administrative Templates\System\Logon/Logoff
|
|
Run logon scripts synchronously
|
When you enable this option, Windows waits for the scripts to finish running before it starts Windows Explorer.
Note that an equivalent option for this is available under the Computer Configuration node. The policy setting you specify in the Computer Configuration node has precedence over that set in the User Configuration node.
|
Run legacy logon scripts hidden
|
If this option is enabled, legacy logon scripts will run in hidden mode.
|
Run logon scripts visible
|
If this option is enabled, logon scripts run in a command window.
|
Run logoff scripts visible
|
If this option is enabled, logoff scripts run in a command window.
|
Note: Scripts that run hidden (and to a lesser degree minimized) can cause an errant script or one that prompts for user input to wait for 600 seconds. This is the default wait-time value and may be changed using a Group Policy. During this time, the system appears to be hung up. In the case of a script running in a minimized window, if the user selects the window, its processing can be stopped.
Best Practice: For easier manageability, it is a good idea to use Group Policy scripts and to avoid using per-user scripts, if at all possible. Rather than using a single monolithic script with lots of internal logic branching, Group Policy-based logon scripts allow for use of tiered and modular scripts targeted to the desired set of users.
Folder Redirection
The Folder Redirection extension is used to redirect any of the following special folders in a user profile to an alternate location (such as a network share):
Application Data
Desktop
My Documents
For example, you could redirect a user’s My Documents folder to \\Server\Share\%username%. By redirecting the My Documents folder, you can provide the following advantages:
Ensure that users’ documents are available when they roam from one computer to another.
Reduce the time it takes to log on to and log off from the network. In Windows NT 4.0, the My Documents folder is part of the Roaming User Profile (RUP). This means that the My Documents folder and its contents are copied back and forth between the client computer and the server when users log on and log off. Relocating the My Documents folder outside of the user profile can significantly decrease that time.
Store user data on the network (rather than on the local computer). The data can then be managed and protected by the Information Technology department.
Make users’ network-based My Documents folder available to users when they are disconnected from the corporate network by using Offline Folder technologies.
More information on Folder Redirection will be available in a white paper called “User Data and Settings Management” at http://www.microsoft.com/windows2000/library/operations/management/settings.asp.
Internet Explorer Maintenance
The Internet Explorer Maintenance extension snap-in includes policy settings to manage the following:
Browser User Interface—You use these options to customize the browser’s appearance. For example, you can specify settings for the browser title bar, toolbar button options, and so on.
Connection Settings—You can preset and manage the connection settings, such as local area network (LAN) and dial-up options.
Custom Universal Resource Locators (URLs) —You can specify which URLs are displayed by the browser, for example, for the Home page, those on the Favorites list, and for the Search page.
Security—You can preset security settings such as security zones, content ratings, and Authenticode. (A browser can be configured to allow only signed code to be downloaded. Authenticode is Microsoft’s version of object signing; it provides a basis for verifying the origin and integrity of an object, as well as links to policies of a certificate authority).
Program Associations—You can specify which Internet programs to use by default for Internet-related tasks such as reading e-mail or viewing newsgroups.
Exporting Internet Explorer Settings for Down-level Clients
Administrators can export Internet Explorer policy settings into an auto-configuration package (an .ins file and its associated .cab files) to be used to apply these settings to Windows 95, Windows 98, and Windows NT 4.0 clients. The exported packages are auto-configuration packages. Before the Windows 2000 Group Policy MMC snap-in extension was created, Internet Explorer settings were applied to Internet Explorer clients using auto-configuration packages after Internet Explorer installation. Using GPOs is the preferred method of applying Internet Explorer policy settings on Windows 2000 clients, although Windows 2000 does support auto-configuration packages.
Using the Internet Explorer Maintenance Preference Mode Option
Administrators can specify to use a Preference Mode option for Internet Explorer Maintenance. By default, the Internet Explorer Maintenance extension snap-in is in true policy mode; that is, the options apply and work like all other policies. Optionally, administrators can set the mode for a given GPO as a Preference Mode—this constitutes a one-time default mode. The Preference Mode option enforces the specified setting only once per GPO. When this mode is selected, this is tracked in the registry and it is checked the next time the GPO is applied.
By default, the Preference Mode option is hidden. The Internet Explorer Maintenance node has to have focus before this option can be accessed. You access this option by right-clicking Internet Explorer Maintenance node and selecting Preference Mode on the context menu. This adds an Advanced node to the results pane. This node contains settings for managing Temporary Internet files and other UI features. Note that switching to Preference Mode disables some of the Internet Explorer Maintenance nodes. If a setting name has Preference Mode appended to it, it can be used in that mode; otherwise, it means that setting is disabled. For example, the Connection Settings (Preference Mode) option under the Connection node can be used in Preference Mode as indicated by its labeling in the UI, whereas the User Agent String option (note the exclusion of Preference Mode) cannot be used in Preference Mode and this is reflected in its labeling.
A listing of Group Policy settings for Internet Explorer Maintenance is presented in Appendix B: Group Policy Settings for Internet Explorer later in this paper.
Using Internet Explorer Customization Wizard and
Internet Explorer Profile Manager
Besides the Internet Explorer Maintenance Group Policy options mentioned above, it is also possible to customize Internet Explorer before deployment and to manage Internet Explorer on other operating systems by using the Internet Explorer Customization Wizard, found at http://www.microsoft.com/windows/ieak/en/corp/features/custwiz/default.asp, and the Internet Explorer Profile Manager, found at http://www.microsoft.com/windows/ieak/en/corp/features/profmanager/default.asp. They can also be found at http://www.microsoft.com/windows/ieak/en/default.asp (Microsoft Internet Explorer Administration Kit). These tools provide options for System Policies and restrictions that administrators can use to specify desktop, shell, and security settings, for example.
The System Policies and Restrictions folder of the Internet Explorer Profile Manager contains nine default policy template (.adm) files to specify policies and restrictions. These are saved to information (.inf) files, which are packaged into the automatic configuration companion cabinet (.cab) files for download to a user’s system. When these .inf files are unpacked, they are used to change policies and restrictions on users’ systems.
For detailed information on these tools, see the Microsoft Internet Explorer 5 Corporate Deployment Guide at http://www.microsoft.com/windows/ieak/en/deploy/corp/default.asp, available on the Microsoft Internet Explorer Administration Kit Web site.
Remote Installation Services is an optional component that is included in the Windows 2000 Server operating system and works with other Windows 2000 technologies to implement the Remote Operating System Installation feature. Administrators use Remote Operating System Installation to remotely install a copy of the Windows 2000 Professional operating system on supported computers4. Administrators use the Remote Installation Services extension of Group Policy to specify which options are presented to users by the Client Installation Wizard, for example, Automatic Setup, Custom Setup, and Restart Setup.
Client computers that are enabled with Pre-boot Execution Environment (PXE) remote-boot technology access the RIS server to install the operating system, and then the Remote Installation Services server checks for Group Policy that affects remote installation options defined for the user. The Boot Information Negotiation Layer (BINL) service running on the RIS server performs this work. It impersonates the user who logs on to the RIS client-side pre-boot user interface, and evaluates the Group Policy objects to determine the resulting policy. Based on the resulting policy, it determines which screens to send to the pre-boot RIS client code for display to the user.
For more information, see the "Remote Operating System Installation" white paper at http://www.microsoft.com/windows2000/library/planning/management/remoteos.asp.
Extending the Group Policy Functionality
It is possible to extend the current functionality of the Group Policy snap-in by creating administrative template files (.adm), or by authoring a Group Policy extension snap-in.
For information on creating Group Policy extension snap-ins, see the Group Policy documentation in the Microsoft Platform SDK at http://msdn.microsoft.com/downloads/sdks/platform/platform.asp. Further information on creating registry-based Group Policy for applications can be found in a white paper called “Implementing Registry-Based Group Policy for Applications,” which is being posted at http://www.microsoft.com/windows2000/library/howitworks/default.asp.
Group Policy Processing
Group Policy is processed in the following order: Local Group Policy Object (LGPO), then GPOs linked to containers in this order: site, domain, and OUs, including any nested OUs (starting with the OU further from the user or computer object). This means that the local Group Policy Object is processed first, and the OU to which the computer or user belongs (the one that it is a direct member of) is processed last. All of this is subject to the following conditions:
Security group filtering that has been applied to GPOs
Any domain-based Group Policy object (not local GPO) may be enforced by using the No Override option so that its policies cannot be overwritten. When more than one GPO has been marked as enforced, the GPO that is highest in the Active Directory hierarchy takes precedence.
At any site, domain, or OU, Group Policy inheritance may be selectively designated as Block Inheritance. However, blocking inheritance does not prevent policy from No Override GPOs from applying; this is because enforced GPOs are always applied, and cannot be blocked.
Note: Every computer has a single local GPO that is always processed regardless of whether the computer is part of a domain or is stand-alone computer. The LGPO can’t be blocked by domain-based GPOs. However, settings in domain GPOs always take precedence since they are processed after the LGPO.
Initial Processing of Group Policy
Group Policy for computers is applied at computer startup. For users, Group Policy is applied when they log on. By default, the processing of Group Policy is synchronous, which means that computer Group Policy is completed before the CTRL+ALT+DEL dialog box is presented, and user Group Policy is completed before the shell is active and available for the user to interact with it.
Synchronous Versus Asynchronous Processing
Synchronous processes can be described as a series of processes where one process must finish running before the next one begins. Asynchronous processes, on the other hand, can run on different threads simultaneously because their outcome is independent of other processes.
You can change the default processing behavior by using a policy setting for each so that processing is asynchronous instead of synchronous. However, this is not recommended because it can cause unpredictable or undesirable side effects. For example, if the policy has been set to remove the Run command from the Start menu, it is possible under asynchronous processing that a user could logon prior to this policy taking effect, so the user would initially have access to this functionality. To provide the most reliable operation, it is recommended that you leave the processing as synchronous.
Time Limit for Processing of Group Policy
Under synchronous processing, there is a time limit of 60 minutes for all of Group Policy to finish processing on the client. Any client-side extensions that are not finished after 60 minutes are signaled to stop, in which case the associated policy settings may not be fully applied. An errant extension may not be able to respond; in either case the Group Policy engine goes into asynchronous processing mode. This means that the Group Policy engine is no longer blocked while waiting for a running (likely errant) extension and continues to process; it leaves the extension(s) running and does not terminate it (them). There is no setting to control this time-out period or behavior.
Background refresh of Group Policy
In addition to the initial processing of Group Policy at startup and logon, Group Policy is applied subsequently in the background on a periodic basis, and can also be triggered on demand from the command line.
During a background refresh, a client side extension will by default only reapply the settings if it detects that a change was made on the server in any of its GPOs or its list of GPOs. This is done for performance reasons.
Not all Group Policy extensions are processed during a background refresh. Software Installation and Folder Redirection processing occurs only during computer startup or when the user logs on. This is because processing periodically could cause undesirable results. For example, for Software Installation, if an application is no longer assigned, it is removed. If a user is using the application while Group Policy tries to uninstall it or if an assigned application upgrade takes place while someone is using it, errors would occur.
Note: The script’s extension is processed during background refresh, however the scripts themselves are only ran at startup, shutdown, logon, and logoff, as appropriate.
Periodic Refresh Processing
Group Policy is processed periodically. By default, this is done every 90 minutes with a randomized offset of up to 30 minutes. You can change these default values by using a Group Policy setting in Administrative Templates. Setting the value to zero minutes causes the refresh rate to be set to seven seconds.
Note: Setting a short refresh interval in a production environment is not recommended; however this can be useful in test or demonstration scenarios. This is because a policy refresh causes the Windows shell to be refreshed, which in turn causes all open context menus to close, a brief flicker of the screen, and so on.
To change the policy refresh interval setting, edit the Default Domain Controllers Group Policy object, which is linked to the Domain Controllers organizational unit. The Group Policy Refresh Interval for Computers setting is located under Computer Configuration/Administrative Templates/System/Group Policy node.
For domain controllers, the default period is every five minutes. Group Policy Refresh Interval for Domain Controllers setting is available under Computer Configuration/Administrative Templates/System/Group Policy node.
On-Demand Processing
You can also trigger a background refresh of Group Policy on demand from the client. However, the application of Group Policy cannot be pushed to clients on demand from the server.
To refresh policy from the command line
Click Start, and click Run.
To refresh policies under the Computer Configuration node, type the following: secedit /refreshpolicy MACHINE_POLICY [/enforce], then Click OK.
To refresh policies under the User Configuration node, type the following, and then click OK: secedit /refreshpolicy USER_POLICY [/enforce].
The optional “/enforce” switch causes policy for the Security and Encrypted File System (EFS) extensions to refresh regardless of whether or not there is a policy change. For other extensions, it has no effect.
Applications can request a policy refresh by calling the RefreshPolicy function.
Messages and Events
When Group Policy is applied, a WM_SETTINGCHANGE message is sent, and an event is signaled. Applications that can receive window messages can use it to respond to a Group Policy change. Those applications that do not have a window to receive the message (as with most services) can wait for the event.
Registry Reads
Group Policy snap-in extensions can temporarily claim (or lock) a mutex (mutual exclusive) for policy, and then release that mutex. A function called EnterCriticalPolicySection pauses the background application of policy for the purpose of safe reading of the registry. Applications that read multiple policy entries and need to ensure that the values are not changed while they are being read should use this function.
If the critical section is not released in 10 minutes, the system forces the application to release it, and then policy can be applied again. This ensures that the background refresh of Group Policy does not occur during the read process.
For information on server-side details of Group Policy and related APIs, see the Microsoft Platform SDK at http://msdn.microsoft.com/developer/sdk/platform.htm.
|
