Custom desktop icons • The custom desktop icons setting is similar to the one above. The process for implementing this setting is the same as the one above. The desktop icons are placed in a shared central location for all defined users to access.
Hide Start menu subfolders • This setting removes from view the subfolders contained in the Start menu. This just leaves shortcuts to applications for the user. This can be a little restrictive for the advanced user. The setting is used in conjunction with the previous two and is enabled with the check box.
Custom Startup folder • This setting provides a mechanism for customizing the startup applications for various groups of users. It is implemented in a similar fashion to the Custom Programs folder mentioned above.
Custom Network Neighborhood • This setting allows you to use a set of shortcuts that point to various network resources. This setting can replace the normal Network Neighborhood and remove the need for browsing. It is only useful if you can define all of the resources that will be required for the group of users that you apply this setting to. Again, this is achieved by a process similar to that in the Custom Programs folder section above.
Custom Start menu • This setting allows you to create a Start menu that can be shared among a particular group of users. You can create many start menus and assign them to particular user groups through the group policy settings. Again, the same process as above is used. This time, the folder structure as well as the items should be created, and the path should point to the root of that folder structure.
Restrictions Only use approved shell extensions • This setting forces you to only place shortcuts to known document and file types in the Start menu and Desktop folder structure. The approved extension list is held in the registry and can be seen as a registered file type if you start Explorer and choose the View > Options > File Types tab. All shortcuts will have the appropriate program registered locally to run successfully.
Remove common program groups from Start menu • This setting removes the Common program groups from the Start menu. The programs still exist and can be run if the user knows their location or the programs in the system path. This setting may remove some temptation to explore, which is a good thing, but it does not replace the need for proper file and directory security.
Windows NT System
The Windows NT System category comes from the Winnt.adm template file. Figure 22 shows the available settings for this category.
Parse Autoexec.bat
This setting forces the Autoexec.bat file to be parsed so that any new entries since the last time it was parsed (possibly at installation) are checked and possibly removed if unneeded. One example is environment variables set by an older installed program. These can be removed and added to the user’s environment variables.
Run Logon Scripts Synchronously
This setting forces the logon script for a user or group of users to finish before shell loading can continue. This setting can be used to allow time for a network connection to be made or drive mapping in a lengthy logon script to finish. It can also be set in the Computer section; if it is, that value takes precedence.
INDIVIDUAL USER AND GROUP POLICIES
Policy settings can be applied to individual users and groups of users instead of to all users.
Single User
Follow the steps below to configure settings for an individual user on your domain.
Start the System Policy Editor.
Open the domain policy file that you have already created, or select File > New Policy to start a new policy file.
Select Add User from the Edit menu.
Enter the user name of the person to whom you wish to apply the policy. You can type the name, or browse for the name. If you type the name, make sure it is spelled correctly. There is no error checking to make sure a user exists.
Select OK. A single-person icon, which is named after the user, is added to the policy file desktop.
Double-click the new icon.
The registry settings exposed here are exactly the same as they are for the Default User policy. All settings are defined in the same way, and the only difference is that settings defined here only apply to the one named user.
Groups
Follow the instructions below to configure settings for a group of users on your domain.
Start the System Policy Editor.
Open the domain policy file that you have already created, or select File > New Policy to start a new policy file.
Select Add Group from the Edit menu.
Enter the name of the group to which you wish to apply the policy. You can type the name or browse for the name. If you type the name, make sure it is spelled correctly. There is no error checking to make sure a user exists.
Select OK. A multiperson icon, which is named after the group, is added to the policy file desktop.
Double-click the new icon.
Again, the settings exposed with the new icon are the same as above and for the Default User policy. These settings are applied to any member of the group as defined in User Manager for Domains.
Additional group settings can be defined in the same way as above. As you can see, a user may well be receiving settings from different policies now. Figure 23 shows a system policy file with multiple groups, users, and computers defined.
Group Priorities
Group priorities can resolve conflicts that may arise when a conflicting setting is made in multiple groups and a user belongs to some or all of those groups. To set priorities you must arrange the groups that have policies defined in some sort of hierarchical order. Follow these steps to arrange the groups.
Start the System Policy Editor and open your policy file.
Define the group policies that you want to place in this policy file (or at least create the icon for each group).
Select Options > Group Priority to open the dialog box shown in Figure 24.
Rearrange the order of the defined groups. Policy settings that conflict are applied from the bottom up. In this case, a conflicting setting applied in the Sales group would be overwritten by the setting in the Management group if the user belonged to both.
Select OK.
The groups have now been prioritized.
SAVING THE POLICY
You can save the system policy that you are creating at any time. The procedure for saving the policy is the same whether you are setting user configurations, computer configurations, or both, because the one policy file holds all of the policy settings for both computer and user. There are two possible ways of saving the policy for future use.
Automatic Update Mode
Follow these steps to save the policy so that it can be used in Automatic mode by each machine.
On the Default User Properties screen shown in Figure 16 in the Default User Policy section, or the Default Computer Properties screen shown in Figure 6 in the Default Computer Policy section, select OK to confirm any entries made in that portion of the policy.
Select Save As from the File menu.
Navigate to the Netlogon share of the domain controller set as the replication export server. Enter the file name NTconfig.pol. If the file name is different or the policy location is not the Netlogon share, then Automatic policy mode will not work for the workstations. No error message is given; the workstation simply does not find a policy and cannot be set to expect a policy.
Manual Update Mode
If you wish to use Manual mode for policy updates instead of Automatic mode, then follow the instructions above, substituting the file name and path for your own required details. Then, set up an Automatic policy file as described above with the single computer setting entered, as shown in Figure 7 in the Default Computer Policy section. The setting should be configured for Manual Update and should contain the path and file name for the new policy. When each machine is used, the Automatic policy setting will change the registry to pick up policy updates from the new location from then on.
POLICY IMPLEMENTATION RULES
Settings available for manipulation within the system policy are also set in other ways. A user can change his wallpaper on his own local machine by using Control Panel > Display. As an administrator, you can set the wallpaper in a roaming profile or you can set it in a mandatory profile. The system policy also allows this setting to be implemented. Where there are conflicts in system or user settings, you need to set a hierarchy to resolve any problems.
The order in which these settings are implemented is defined in Windows NT. Figure 25 shows a graphical representation of the implementation of these settings.
The order of precedence is as follows:
Original registry settings and any user-defined registry settings are applied to the machine.
Registry settings defined in user profiles are applied to the machine when the user logs on. These settings can come from a local profile, a roaming profile, or a mandatory profile. The settings contained in the profile overwrite any existing registry settings.
The system policy is applied next and overwrites any conflicting settings in the registry. This means that even if the user were to set preferences for wallpaper settings locally and save them to their roaming profile, the introduction of a system policy stipulating that all users must display the company logo as wallpaper would overwrite the local settings. If the profile is a roaming profile then these settings would be uploaded and overwrite the profile settings. If a mandatory (read-only) profile is in use, then the settings would not be saved to the profile but would still be overwritten every time the policy file is read. The user could change these settings (if the policy allows), but the next time the user logs on, the policy settings appear.
POLICY CONFLICT RESOLUTION
When using system policies, you have a great deal of choice on how and where to apply settings. Certain settings exist in both the user and computer configurations. You can apply settings to individual users, to groups (possibly containing the same users), and also to all users. You may apply settings to individual computers or all computers. It is understandable therefore that there may be conflicts when the policies are applied. A user may receive a settings for an individual registry key from the Default User policy and also through multiple group membership. There must be a hierarchy here to resolve any conflicts in settings that may arise from these possibilities.
Computer Policy Conflicts
When conflicts arise because of multiple registry settings for a computer (i.e., a setting exists in the Default Computer policy and the setting exists in the named computer 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 26.
The setting shown in Figure 26 is applied in the Default Computer properties sheet. This setting will be applied to all domain machines. An entry in the policy should be made for all servers in the domain. A single computer entry is made in the policy for the machine IBSNT03, as shown in Figure 23 in the Individual User and Group Policies section. The setting described above is made in this policy, but it is set to be disabled (white check box but with no check mark).
When the policies are applied, they are applied in the priority order shown in Figure 27.
The computer policy settings contained in Default Computer are applied if a named computer policy does not exist. This is not the case so the settings contained in the individual computer policy are applied; any defined settings in this policy overwrite already existing settings. In this particular case the server IBSNT03 will have a setting applied so that shutdown from the authentication box is not allowed.
Note: This order is accomplished because of the definite setting in the IBSNT03 policy disabling the registry key. If the setting had been grayed out instead of white with no check mark, then any setting already applied would be left untouched.
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
