Policies Versus Preferences

One of the most heralded benefits of moving away from your old Windows NT 4-based System Policy is the nonpersistence of the Registry changes using Group Policy. Every Windows NT 4 System Policy change was persistent. When you enabled a System Policy, it stayed turned on until you set an explicit policy to turn it off. You couldn't just delete the policy and have the setting go away, as is the case with today's Group Policy engine. If you used Windows NT System Policy, you had to fight the same problem over and over.

With Windows 2000 and newer versions of Windows comes a new model for policies. Microsoft has created special locations in the Registry for Windows 2000, aptly named Policies. Microsoft documentation states that four Registry areas are considered the approved places to create policies out of Registry hacks:

  • HKLM\Software\Policies (computer settings, the preferred location)

  • HKLM\Software\Microsoft\Windows\CurrentVersion\Policies (computer settings, an alternative location)

  • HKCU\Software\Policies ( user settings, the preferred location)

  • HKCU\Software\Microsoft\Windows\CurrentVersion\Policies (user settings, an alternative location)

These locations are preferred because they have security permissions that do not allow a regular user to modify these keys.

When a policy setting is set to "Enabled" and the client embraces the Group Policy directives, a Registry entry is set in one of these keys. When the GPO that applied the keys is removed, the Registry keys associated with it are also removed. Whether an application that is looking for these Registry keys can locate them depends on whether you manipulate the setting.

Note 

A local administrator has security permissions to these keys and can modify the GPO setting for this portion of the Registry.

This is the magic that makes Group Policy shine over old-style NT 4 System Policy; that is, Group Policy won't tattoo because it's being directed to go in a nonsticking place in the Registry. Old-style NT 4 System Policy had no such facility. Today, Microsoft calls these NT-style policies that tattoo preferences.

You might want to control a pet application that you have deployed in-house, say, DogFood-Maker 6.1. Greatyou've decided you want more control. Now, you need to determine which Registry values and data DogFoodMaker 6.1 understands. That could take some time; you might be able to ask the manufacturer for the valid registry values or you might have some manual labor in front of you to determine what can be controlled via the Registry. You'll then be able to begin to create your own ADM templates (with the syntax in "ADM Template Syntax" on this book's website.

However, after you've determined how DogFoodMaker 6.1 can be controlled via the Registry, you'll find you have two categories of Registry tweaks:

  • Values that fit neatly into the new Policies keys listed earlier

  • Values that are anywhere else

You'll have some good news and some bad news. If DogFoodMaker 6.1 can accept control via the Registry, you can still create ADM template files and control the application. The bad news is that if the Registry punches it accepts are not inside the new Policies keys listed earlier, you will not have proper Policies. Rather, they become old-style tattooing preferences.

To reiterate, the target applications must be programmed to look for values in the Policies keys. Some applications, such as Word 2000, check the Policies keys ( specifically HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\9.0\Word\ ). Other applications, such as WordPad, do not "understand" the Policies keys. (WordPad looks in HKEYCURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Applets\Wordpad .) Hence, WordPad wouldn't be a candidate for which to create official policies; you could still create your own preferences for WordPad that modify and tattoo the Registry. Therefore, you will have to do the legwork to figure out if your applications are compatible with the new Profiles keys.

Because preferences and policies act so differently, you will need to quickly identify them within the Group Policy Object Editor interface. You will want to note whether you're pushing an actual new-style policy to them or a persistent old-style policy. You'll see both cases in this chapter.

New-style policies are designated by blue dots because they modify the Policies Registry keys. Policies that represent Registry punches in places other than the preferred Microsoft policies are designated by red dots. Again, you'll see this distinction a bit later as you work through the examples.

Since this is an important distinction in the rest of this chapter, let's recap:

  • New-Style policies are temporary Registry changes that are downloaded at logon and startup. They don't tattoo the Registry (though they are cached should the user log on while offline). These are set to modify the Registry in specific Microsoft-blessed Policies keys. Applications need to be coded to recognize the presence of the keys in order to take advantage of the magic of policies. In the Group Policy interface, these have a blue dot.

  • Old-style preferences are persistent Registry changes sent from on high using the Group Policy Object Editor. These typically tattoo the Registry until they're specifically removed. They work like old-style NT System Policy. These are set to modify the Registry anywhere.

Hang tight, dear reader. The differences between preferences and policies will be underscored when you create your own settings to manipulate your clients later in this chapter.



Group Policy, Profiles, and IntelliMirror for Windows 2003, Windows XP, and Windows 2000
Group Policy, Profiles, and IntelliMirror for Windows2003, WindowsXP, and Windows 2000 (Mark Minasi Windows Administrator Library)
ISBN: 0782144470
EAN: 2147483647
Year: 2005
Pages: 110

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net