4.4 PART
Use
the PART syntax to specify options such as drop-down lists, text boxes,
and text in the lower pane of a policy in the GPME. The previous
example shows the PART syntax used in the .adm template and the
resulting GPME interface from Figure 2.
You
can also use the PART syntax to create an introduction or information
about the policy in the lower pane of the policy. This PART syntax
would simply introduce a clarifying sentence, without associating it
with a registry value.
PART "Do you want to see Super Hidden files?" TEXT
END PART
Associating a PART within a “policy” to a registry value would look like this:
PART "Super Hidden" DROPDOWNLIST
VALUENAME Showsuperhidden
ITEMLIST
NAME "Yes" VALUE Numeric 1
NAME "No" VALUE Numeric 0
END ITEMLIST
END PART
The
PART syntax can handle the various types of registry values that you
include in your custom .adm templates. Each type of registry value
requires the use of additional syntax to handle the input for the
registry value. The previous example uses ITEMLIST, but other syntax
options are available that you will need to use.
Note
The
PART syntax requires an END PART to tell the GPME when to stop the
configuration of the registry value within the interface. Additional
syntax that you can use in conjunction with PART includes CHECKBOX,
CLIENTTEXT, COMBOBOX, DROPDOWNLIST, EDITTEXT, LISTBOX, NUMERIC, END,
PART, and TEXT. |
To
create the environment that allows the user to modify the registry
values, you must include additional syntax after the PART syntax. Table 1 lists the valid syntax options that are used in conjunction with the PART syntax.
Table 1. Syntax Options for the PART Syntax
| Type | Description |
|---|
| CHECKBOX | Displays
a check box. The value is set in the registry with the REG_DWORD type.
The value is other than zero if the check box is selected and zero if
it is not selected. |
| CLIENTTEXT | Specifies which client-side extension to use for the specific policy setting. |
| COMBOBOX | Displays a combo box. |
| DROPDOWNLIST | Displays a combo box with a drop-down list style. The user can choose only one of the entries supplied. |
| EDITTEXT | Displays a text box that accepts alphanumeric text. The text is set in the registry with the REG_SZ or the REG_EXPAND_SZ type. |
| LISTBOX | Displays
a list box with Add and Remove buttons. This is the only PART type that
can be used to manage multiple values under one key. |
| NUMERIC | Displays
a text box with an optional spin box control that accepts a numeric
value. The value is set in the registry with the REG_DWORD type. |
| TEXT | Displays a line of static text. No registry value is associated with this PART type. |
4.4.1 CHECKBOX
When
you are combining multiple registry values under one policy, you use
the CHECKBOX syntax to function like the VALUEON/VALUEOFF syntax. If
the check box is selected (VALUEON), the registry value associated with
the CHECKBOX syntax has a value of 1 written to the registry. A value
of 0 is written to the registry if the check box is not selected
(VALUEOFF).
You can also combine the
CHECKBOX syntax with the VALUEON/VALUEOFF syntax to clearly specify
what the registry values should be when the check box is selected and
not selected. Here is a snippet of the System.adm template, which uses
the CHECKBOX syntax:
PART !!StdCheckT CHECKBOX
VALUENAME "DisableRollback"
VALUEON NUMERIC 1
VALUEOFF NUMERIC 0
END PART
Note
Additional
syntax that you can use in conjunction with CHECKBOX includes KEYNAME,
VALUENAME, ACTIONLISTON, ACTIONLISTOFF, VALUEON, VALUEOFF, DEFCHECKED,
CLIENTTEXT, and END. |
4.4.2 CLIENTTEXT
The
CLIENTTEXT keyword is used to specify which client-side extension (CSE)
to the GPME needs to process the particular settings on the client
computer. By default, the registry extension processes all settings
configured under the Administrative Templates node. The CLIENTTEXT
keyword changes the default behavior and causes the specified extension
to process these settings after the registry extension has placed them
in the registry.
The CLIENTTEXT syntax
is the keyword followed by the GUID, representing the CSE. This implies
that the registry key and value information will be stored in the
registry.pol file when the policy setting is configured to either an
enabled state or a disabled state. Instead of the registry CSE acting
on this registry information, a different CSE represented by the GUID
value will be called to process the registry information during Group
Policy processing on the client computer. For example, the disk quota
CSE uses the GUID value of {3610eda5-77ef-11d2-8dc5-00c04fa31a66} in
the following example. GUID values are used to represent CSEs to employ
a unique designation for each CSE.
The CLIENTTEXT syntax must be used within the POLICY scope or the PART scope and should follow the VALUENAME statement.
CLIENTTEXT
alters the default behavior of typical GPOs. Typical GPOs process all
settings under the Administrative Templates node. The CLIENTTEXT syntax
specifies the specific extension to process a GPO setting, after it has
been placed in the registry.
The
following is an example from the System.adm template. It configures the
disk quotas within the GPO. As you can see, Disk Quotas has a separate
CSE, which is referenced within the example code:
POLICY !!DQ_Enforce
KEYNAME "Software\Policies\Microsoft\Windows NT\DiskQuota"
VALUENAME "Enforce"
VALUEON NUMERIC 1
VALUEOFF NUMERIC 0
CLIENTEXT {3610eda5-77ef-11d2-8dc5-00c04fa31a66}
END POLICY
Note
The
CLIENTTEXT syntax shown in this example assumes that a corresponding
CSE has been written and is resident on each client machine that needs
to process this registry information. |
