Special considerations apply when processing Group Policy over slow links or remote access.
NOTE: Note that while these issues are related, they are distinct, and the processing of Group Policy is different for each. In particular, remote access does not necessarily imply a slow link, nor does a LAN necessarily imply a fast link. A slow link is by default based on the algorithm described in the section below. Windows 2000 Server remote access is part of the integrated Routing and Remote Access Service; it connects remote or mobile users to corporate networks, allowing users to work as if their computers are physically connected to the network. Users run remote access software to connect to a remote access server, which is a computer running Windows 2000 Server and the Routing and Remote Access Service. The remote access server authenticates the user and services sessions until terminated by the user or network administrator. The remote access connection enables all services typically available to a LAN-connected client, such as file and print sharing, messaging, and Web server access.
Group Policy and Slow Links
When Group Policy detects a slow link, it sets the GPO_INFO_FLAG_SLOWLINK flag in the GPO_INFO structure to indicate that policy is being applied across a slow link. Individual client-side extensions can determine whether or not to apply policy over the slow link.
The default settings are as follows:
Security Settings—ON (and cannot be turned off).
Administrative Templates—ON (and cannot be turned off).
Software Installation—OFF.
Scripts—OFF.
Folder Redirection—OFF.
For all but the Administrative Templates snap-in and security settings snap-in, a policy is provided for toggling the slow link processing settings.
Setting Policy for Slow-Link Definition
You can use Group Policy to set the definition of a slow link for computers and users, and for user profiles.
For Group Policy, Windows 2000 uses a new IP ping algorithm to ping the server, rather than measuring the file system performance method that was used in Windows NT 4.0.
A slow link is, by default, based on the following algorithm (where ms = milliseconds):
Ping the server with 0 bytes of data and time the number of milliseconds. This value is time#1. If it is less than 10 ms, exit (assume a fast link).
Ping the server with 2 KB of uncompressible data, and time the number of milliseconds. This value is time#2. The algorithm uses a compressed .jpg file for this.
DELTA = time#2 - time#1. This removes the overhead of session setup, with the result being equal to the time to move 2 KB of data.
Calculate Delta three times, adding to TOTAL each DELTA value.
TOTAL/3 = Average of DELTA, in milliseconds.
2 * (2 KB) * (1000 millisec/sec) / DELTA Average millisec = X
X = (4000 KBytes/sec) / DELTA Average
Z Kilobits per second (Kbps) = ((4000 KBytes/sec) / DELTA Average) *(8 bits/byte)
Z Kbps = 32000 kbps/Delta Avg.
Two KB of data have moved in each direction (this is represented by the leading factor two on the left side in step six above) through each modem, Ethernet card, or other device in the loop once.
The resulting Z value is evaluated against the policy setting. A default of less than 500 Kbps is considered a slow link; otherwise it is a fast link. This value may be set through Group Policy in the Administrative Templates node.
To specify policy settings for Group Policy slow link detection for computers, you use the Computer Configuration\Administrative Templates\System\Group Policy node. To set this policy for users, you use the User Configuration\Administrative Templates\System\Group Policy node. The connection speed is set for kilobits per second (Kbps).
For User Profiles, the Slow network connection timeout for user profiles policy is located in the Computer Configuration\Administrative Templates\System\Logon node. This policy has support for both pinging the server and checking the performance of the file system. This is because user profiles can be stored anywhere, and that server may or may not have IP support. Therefore, the user profile code first tries to ping the server. If the server does not have IP support, it falls back to measuring the file system's performance. You must specify connection speeds in both kilobytes per second (Kbps) and milliseconds (ms) when setting this policy.
Application of Group Policy During a Remote Access Connection
Group Policy is applied during a remote access connection as follows:
When using the Logon using dial-up connection checkbox on the logon prompt, both User and Computer Group Policy is applied, provided the computer is a member of the domain that the remote access server belongs to or trusts. However, computer-based software installation settings are not processed. This is because normally computer policy would have been processed before the logon screen, but since no network connection is available until logon, the application of computer policy is done as background refresh at the time of logon.
When the logon is done with cached credentials, and then a remote access connection is established, Group Policy is not applied.
Group Policy is not applied to computers that are members of a foreign domain or a workgroup. Although the connection may still be made, access to domain resources may be affected (because of mismatched IPSec security).
Client-side Processing of Group Policy
Some of the Group Policy components include client-side extensions (.dlls) that are responsible for implementing Group Policy at the client computers. The client-side extensions are listed in the following table.
Client-side extension
|
DLL file name
|
Registry (Administrative Templates)
|
Userenv.dll
|
Disk Quota (in Administrative Templates)
|
Dskquota.dll
|
Folder Redirection
|
Fdeploy.dll
|
Scripts
|
Gptext.dll
|
Software Installation
|
Appmgmts.dll
|
Security
|
Scecli.dll
|
IP Security
|
Gptext.dll
|
EFS (Encrypting File System) Recovery
|
Scecli.dll
|
Internet Explorer Maintenance
|
Iedkcs32.dll
|
For each client-side extension, the Group Policy object processing order is obtained from a list of Group Policy objects, which is obtained from the GetGPOList Win32 function. Each client-side extension processes the resulting list of GPOs.
The client-side extensions are loaded on an as-needed basis when a client computer is processing policy. The client computer first gets a list of Group Policy Objects. Next, it loops through all the client-side extensions and determines whether each client-side extension has any data in any of the GPOs. If a client-side extension has data in a GPO, the client-side extension is called with the list of Group Policy Objects that it should process. If the client-side extension does not have any settings in any of the GPOs, it is not called.
Computer Policy for Client-Side Extensions
A computer policy exists for each of the Group Policy client-side extensions. Each policy includes a maximum of three options (checkboxes). Some of the client-side extensions include only two computer policy options; in those cases, this is because the third option is not appropriate for that extension.
The computer policy options are:
Allow processing across a slow network connection. When a client-side extension registers itself with the operating system, it sets preferences in the registry, specifying whether it should be called when policy is being applied across a slow link. Some extensions move large amounts of data, so processing across a slow link can affect performance (for example, consider the time involved in installing a large application file across a 28.8 Kbps modem line). An administrator can set this policy to mandate that the client-side extension should run across a slow link, regardless of the amount of data.
Do not apply during periodic background processing. Computer policy is applied at boot time, and then again in the background, approximately every 90 minutes thereafter. User policy is applied at user logon, and then approximately every 90 minutes after that. The Do not apply during periodic background processing option gives the administrator the ability to override this logic and force the extension to either run or not run in the background. Note: the Software Installation and Folder Redirection extensions process policy only during the initial run because it is risky to process policy in the background. For example, with Software Installation application upgrades, applications are installed during the initial run and not in the background. If it were done in the background, a user could be running an application, and then have it uninstalled and a new version installed. The application could also have a shared component that is in use by another application. This would prevent the installation from completing successfully.
Process even if the Group Policy Objects have not changed. By default, if the GPOs on the server have not changed, it is not necessary to continually reapply them to the client, since the client should already have all the settings. However, local administrators may be able modify the parts of the registry where Group Policy settings are stored. In this case, it may make sense to reapply these settings during logon or during the periodic refresh cycle to get the computer back to the desired state.
For example, assume that you have used Group Policy to define a specific set of security options for a file. Then the user (with administrative privileges) logs on and changes it. The Group Policy administrator may want to set the policy to process Group Policy even if the GPOs have not changed so that the security is reapplied at every boot. This also applies to applications. Group Policy installs an application, but the end user can remove the application or delete the icon. The process gives the administrator the ability to restore the application at the next user logon, even if the Group Policy Objects have not changed option.
Note that, by default, security settings are applied every 16 hours (960 minutes) even if a GPO has not changed. It is possible to change this default period by using the following registry key:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtentions\{82...}\MaxNoGPOListChangesInterval, REG_DWORD, in number of minutes.
The following table lists the client-side extensions that include only two computer policy options, as well as the reason for this.
Client-side extension
|
Missing policy checkbox
|
Reason
|
Registry
|
Slow link (Allow processing across a slow network connection)
|
Registry policy is always applied because it controls the other client-side extensions.
|
Security Settings
|
Slow link (Allow processing across a slow network connection)
|
To ensure that security settings are in effect, they must always be applied, even across a slow link.
|
Folder Redirection
|
Background processing (Do not apply during periodic background processing)
|
It is considered too risky to move users’ files while they are logged on.
|
Software Installation
|
Background processing (Do not apply during periodic background processing)
|
It is considered too risky to install and uninstall an application when the user is logged on.
| Server Processing Group Policy Snap-in and the Operations Master
The Group Policy snap-in uses the Operations Master token for the primary domain controller (PDC) emulator when editing a GPO. This ensures that the Group Policy snap-in is always focused on the same domain controller (DC). User preference options and policy settings are available to modify this behavior. For more information on setting domain controller options, see the upcoming section on Specifying a Domain Controller for Setting Group Policy .
Synchronization Between the Group Policy Template and the Group Policy Container
Lack of synchronization between the Group Policy Template (data stored on Sysvol) and Group Policy Container (data stored in the Active Directory) portions of the Group Policy Object can occur temporarily because of the differences in the replication schemes used by the Active Directory and the File Replica Set (FRS—for system volume data).
For those Group Policy extensions that store data in only one data store (either the Active Directory or Sysvol), this is not an issue, and Group Policy is applied as it can be read. Such extensions include Administrative Templates, Scripts, Folder Redirection, and most of the Security Settings.
For any Group Policy extension that stores data in both storage places (the Active Directory and Sysvol), the extension must properly handle the possibility that the data is unsynchronized. This is also true for extensions that need multiple objects in a single store to be atomic in nature, since neither storage location handles transactions.
An example of an extension that stores data in the Active Directory and Sysvol is Software Installation. The script files are stored on Sysvol and the Windows Installer package definition is in the Active Directory. If the script exists, but the corresponding Active Directory components are not present, then nothing is done. If the script file is missing, but the package is known in Active Directory, application installation fails gracefully and will be retried on the next processing of Group.
Specifying a Domain Controller for Setting Group Policy
In this version of Windows 2000, Group Policy writes data to the GPO immediately for each change. If two administrators are simultaneously editing the same GPO on different domain controllers, it is possible for the changes written by one administrator to be overwritten by another administrator, depending on replication latency.
To avoid this situation, the Group Policy snap-in by default uses the Operations Master token for the PDC emulator when editing a GPO. This forces the Group Policy snap-in to use the same domain controller and helps ensure that no data loss occurs.
However, it is possible to modify this default behavior by using either user-preference options or policy settings to set domain controller options for Group Policy, as described in the next sections. This will be useful in situations that require editing a GPO on a local domain controller. For example, if an administrator were delegated a GPO across a slow link, he or she would want to edit that GPO on thelocal domain controller for optimum performance. This functionality can be useful in some corporate scenarios, provided that more than one administrator does not typically administer a given GPO. For example, if you are an administrator in Japan and the PDC emulator is in New York, it may be problematic if you are forced to rely on a WAN link to access the New York PDC emulator. However, if no one else administers your GPOs, you could choose this option so that you could make your policy edits on a local domain controller so that performance is acceptable.
Specifying a Domain Controller for Group Policy Editing
by Using Preferences
Administrators can use the Group Policy snap-in user interface to set domain controller options by selecting DC Options from the View menu. This option is available only when focus is on the root node of the Group Policy snap-in.
Selecting DC Options opens the Options for domain controller selection dialog box, where you can specify a domain controller (DC) to use for editing Group Policy:
F
igure 6. Options for domain controller selection dialog box
The available options for the Options for domain controller selection dialog box are:
The one with the Operations Master token for the PDC emulator. This is the default and preferred option. Using this option helps ensure that no data loss occurs. This forces the Group Policy snap-in to use the same domain controller. Data loss could occur if two administrators were working on changes to the same GPO on different domain controllers within the replication cycle. In this version of Windows 2000, Group Policy writes data to the GPO for each change. If two administrators are editing a GPO on different domain controllers, it increases the possibility of changes being overwritten by replication. It is strongly recommended that the number of administrators be limited, that Group Policy use the PDC emulator Operations Master, and that the administrator be aware of other administrators who may be editing the same GPO.
The one used by the Active Directory Snap-ins. Uses the domain controller that the Active Directory management snap-in tools are currently using. Each of these snap-ins includes an option for changing which domain controller is the focus of the current operations. When this option is selected, the Group Policy snap-in uses the same domain controller as the Active Directory snap-ins. For example, if the Active Directory Users and Computers snap-in is focused on DC3, Group Policy also uses DC3.
Use any available domain controller. The third, and, in most cases, least desirable option allows the Group Policy snap-in to choose any available domain controller. When this option is used it is likely that a domain controller in the local site will be selected.
All of these options may be overridden by a using policy setting, as described next. These settings are available in the User Configuration\Administrative Templates\System\Group Policy node of the Group Policy snap-in.
|
