User Policy Conflicts
When conflicts arise because of multiple registry settings for a user (i.e., a setting exists in the Default User policy, in multiple group policies, and in the individual user policy), there is more than one possible outcome, depending on the value of the setting.
To illustrate the example, we use the setting shown in Figure 28.
The setting shown in Figure 28 is applied in the Default User properties sheet, meaning that this setting will be applied for all users. The same value is grayed out in the Accounts group policy, and is set as disabled (white box but with no check mark) in the Management group policy. User Jsmith is a member of Accounts and Management groups in the domain. He does not have an individual user policy. The group priorities have been set in the order shown in Figure 24 in the Individual User and Group Policies section. These priorities (from highest to lowest) are Management, Accounts, Sales.
When the policies are applied, they are applied in the priority order shown in Figure 29.
The settings applied in the Default User policy are applied first if no individual user policy exists. If an individual policy exists, then it is applied and the Default User policy and group policies are skipped. Group policies are applied in the order defined by their respective group priorities.
For the example shown in Figure 28, the Default User policy is set to hide the drive in My Computer. This setting is ignored in the two group policies. The Accounts group policy is applied next and the setting is grayed out so the active setting remains in force. The Management group policy is applied last and the setting is also grayed out. The net result is that this user can see the drives in My Computer.
When an individual user policy exists the Default User policy and Group polices are NOT applied. Only the named policy is applied. Therefore a named policy takes precedence over all other user-related policies.
The Dangers of Conflicts
The main danger when applying conflicting settings is that you may leave a setting ignored (grayed out) in the higher-priority policy, expecting the existing setting to remain in place. If one of the interim stages of policy application (such as from group membership) alters the existing setting, then this new setting is passed through the higher-priority policy and the result is not what you expected. If a setting is important to you, set it as enabled or disabled. Do not leave it grayed out unless you are certain of the underlying logic of policy structure (including group membership).
This same warning does not apply to computer policies. For these policies, you can only receive settings from one of two places (Default Computer and named computer), so the chances for confusion are eliminated.
POLICY TEMPLATE FILES
The policy template files expose areas of the registry that should be configured by the Policy Editor without allowing any other registry changes to take place through the tool.
Template files are flat ACSII files that can be opened and edited with a text editor such as Notepad. The exposure of registry keys is defined in the template file structure, which is checked every time you try to load a template (and at Policy Editor startup). If you make a syntax error in the file structure, the template will not load and an error similar to that in Figure 30 is displayed.
The error message gives you the file name and location as well as the line number that contains the syntax error and the text that is invalid. You cannot get much more helpful than this.
Appendix A contains the listings of the two Windows NT-related template files; Common.adm and Winnt.adm. The third template file supplied is for use with Windows 95 only.
Template File Structure
The file listing that follows is an edited extract from the Winnt.adm template file. This extract inserts the Windows NT Printers category into the Computer properties screens in the Policy Editor. It is placed in the Computer policy screen as opposed to the User policy screen because of the Class statement type which is set to Machine.
CLASS MACHINE
CATEGORY !!Printers
KEYNAME System\CurrentControlSet\Control\Print
POLICY !!PrintManager_Browser_Restrict
VALUENAME DisableServerThread
PART !!Disable_Server_Tip1 TEXT
END PART
PART !!Disable_Server_Tip2 TEXT
END PART
END POLICY
POLICY !!Scheduler_Thread_Priority
PART !!Scheduler_Priority DROPDOWNLIST
VALUENAME SchedulerThreadPriority
ITEMLIST
NAME "Above Normal" VALUE NUMERIC 1
NAME "Normal" VALUE NUMERIC 0
NAME "Below Normal" VALUE NUMERIC -1
END ITEMLIST
END PART
END POLICY
POLICY !!Beep_Enabled
VALUENAME BeepEnabled
VALUEOFF NUMERIC 0
PART !!Beep_Tip1 TEXT END PART
PART !!Beep_Tip2 TEXT END PART
END POLICY
END CATEGORY
[strings]
Printers="Windows NT Printers"
PrintManager_Browser_Restrict="Disable browse thread on this computer"
Disable_Server_Tip1="When this box is checked, the print spooler does not"
Disable_Server_Tip2="send shared printer information to other print servers."
Scheduler_Thread_Priority="Scheduler priority"
Scheduler_Priority="Priority"
Thread_Priority_Above_Normal="Scheduler priority above normal"
Thread_Priority_Below_Normal="Scheduler priority below normal"
Thread_Priority_Normal="Scheduler priority normal"
Beep_Enabled="Beep for error enabled"
Beep_Tip1="A check in this box enables beeping (every 10 seconds)
when a remote"
Beep_Tip2="job error occurs on a print server."
The first part of the template files is made up from keywords and values. While discussing the different sections of the template, we will refer to the screen shot in Figure 11 previously shown. This screen shot of the Default Computer policy shows the Windows NT Printers category expanded. This category is the entry represented by the file extracts above. The next sections explain how the file sections and keywords correspond to the Policy Editor interface and the registry setting. Figure 31 repeats Figure 11 for convenience.
CLASS
The first entry in the file is the class. The class is always set to one of two options. Machine is used as the class when all of the entries that follow are to be part of the Computer policy. User is the class when all of the entries that follow are part of the User policy. All entries that follow a class statement are placed in the corresponding policy until the next class statement changes the focus to the other policy type.
CATEGORY
The Category keyword opens a new section in the policy properties screen or further subdivides a section already opened. Referring again to Figure 11, the category keyword in the listing above corresponds to the Windows NT Printers category.
You can have many layers of categories. They should simply be nested within the parent category. This structure will be familiar to anyone with programming experience.
All category statements should have a corresponding END CATEGORY statement.
Text String
If you look at the text string that immediately follows the Category keyword in the listing above, you will see that it is !!Printers. The !! symbols indicate that there is a string definition for this entry in the [strings] section. If you follow the listing down to the [strings] section, you see the entry Printers="Windows NT Printers". This is where the Windows NT Printers category title comes from (see Figure 11).
Text string variables are defined so that short variable names appear in the category design and can represent much longer text strings that are substituted when the policy editor is run. The short variable name only has to be defined once, and it can be used many times throughout the file.
KEYNAME
The KEYNAME statement points to the registry key that will be amended within this category. Because the class has been defined already, there is no need to put the registry hive name here.
POLICY
POLICY is the actual change that can be made with this selection. It is identified with another text string that should translate in the [Scripts] section to a meaningful label describing the type of change that can be made with this selection. Policy statement requires a corresponding End Policy statement.
VALUENAME
The value name is the name of the registry value that should be amended for this option. If the value needs to be set in the lower part of the Policy Editor screen (where value input is required), then the value name must be contained within a Part statement.
PART
The PART statement places text information, drop-down lists, or dialog boxes in the lower part of the Policy Editor screen. These can be used to convey context, sensitive help or for user input when registry values are required. The Part statement comes before the corresponding value name statement and must finish with a corresponding End Part statement.
PART Value
The value is a flag that is placed on the end of a Part statement and denotes the type of information contained in Part. The several options are listed.
TEXT • The Text flag only displays text and can be used as context-sensitive help. The text can be displayed when the option is highlighted.
NUMERIC • The NUMERIC flag causes the value to be written to the registry with the data type of REG_DWORD. You need to know what data type the registry value can hold before setting this flag.
DROPDOWNLIST • The DROPDOWNLIST flag provides exactly what you would expect. The list syntax is shown below in an extract from the fuller listing provided at the beginning of this section.
PART !!Scheduler_Priority DROPDOWNLIST
VALUENAME SchedulerThreadPriority
ITEMLIST
NAME "Above Normal" VALUE NUMERIC 1
NAME "Normal" VALUE NUMERIC 0
NAME "Below Normal" VALUE NUMERIC -1
END ITEMLIST
END PART
The text for the drop-down items is defined by the Name statement. The data values that would be entered into the registry are associated with each option: in this case, the numbers 1, 0, and –1.
EDITTEXT • The EDITTEXT flag denotes that the data type for the selected registry value is REG_SZ.
REQUIRED • The REQUIRED flag does not allow the option to be selected without a corresponding value being entered. An error message is generated if no value is entered and the user must either enter a value or deselect the option.
EXPANDABLETEXT • The EXPANDABLETEXT flag denotes that the data type for the selected registry value is REG_EXPAND_SZ.
MAXLEN • The MAXLEN flag specifies the maximum length of a text input.
DEFAULT • The DEFAULT flag specifies the default value for numeric or text input.
MIN and MAX • The MIN and MAX flags denote the minimum and maximum values allowed for a numeric field.
VALUEOFF
The VALUEOFF statement places a specified value in the registry if the option is set as OFF.
VALUEON
The VALUEON statement places a specified value in the registry if the option is set as ON.
[STRINGS]
The last part of the template files is made up of the string definitions. For every entry in the file preceded with !! symbols, there should be a corresponding entry in the [strings] section.
Hints for Building Custom Template Files
You can build your own template files to expose registry settings that are not normally available to the Policy Editor. You may want to do this so that you can include extra security related settings in a policy that can be implemented domainwide. An outline of instructions for creating your own template files is presented below. Make sure you are comfortable with the layout of the template files and the keyword uses before proceeding.
Make a list of the registry key that you want to include in your template, along with all supported values and data type involved.
Start a new template file in Notepad or open a copy of an existing file and remove most of the entries, leaving just enough information to help you lay the file out properly.
Enter the required information in the proper format. This instruction is only eight words but is the most difficult part of the whole exercise.
Test the template file by trying to load it into the Policy Editor. Do this often and fix problems before adding more functionality.
Build up the functionality of your policy template step by step with testing at each stage.
Test the finished, loaded policy on the local registry of a machine that you can afford to destroy. This is no idle warning. Mistakes in syntax are found by the Policy Editor at load time. Mistakes in registry settings are not found until they are applied and possibly kill the system.
Last but not least, make sure you understand the registry before attempting this type of exercise. A custom-made policy can bring great benefit to your organization by allowing you to apply controlled measures to restrict unwarranted activity. If it exists as a registry key in the HKEY_LOCAL_MACHINE or HKEY_USERS registry hives and it can be amended with Regedt32.exe, then it can be controlled by this program with a custom template file. Take some time to browse through these registry hives and look at the number of entries here.
SUMMARY
Take some time to look at the template files and get used to the layout before trying to build custom files of your own. The syntax can be quite tricky, and you should test any changes on a registry that you can afford to trash. Remember to make copies of the template files and only work from the copies.
Order Your SQL Fundamentals CD Today! Learn how to use SQL Server, understand Office integration techniques and dive into the essentials of SQL Express and Visual Basic with this free SQL Fundamentals CD.
You've Deployed SharePoint...Now What? This one-day free online conference delivers the technical knowledge needed to kick MOSS up a notch. In one information-packed day, independent SharePoint experts will present practical, real-world information and provide take-away, ready-to-use solutions
What Would You Do If You Ran Microsoft? ITTV's 2008 inaugural video contest, "If I Ran Microsoft..." is your chance to tell it like it is. Be goofy or be serious, but don"t miss this chance to have fun, win prizes, and go viral in a major way.
Maximize Your SharePoint Investment This web seminar discusses how true bi-directional replication of SharePoint content from one server to another enables branch offices to maintain access to current SharePoint content.
Windows IT Pro
Register
