Managing the Windows 2000 Registry

Managing the Windows 2000 Registry
by Paul Robichaux

Download Book

If you are the author or the publisher, and would like to link to your site here, please contact us.

About Book

Book Description
The Windows 2000 Registry is the repository for all hardware, software, and application configuration settings, and Managing the Windows 2000 Registry is the system administrator's guide to maintaining, monitoring, and updating the Registry database. The book, which is an update of Managing the Windows NT Registry, addresses four main areas:

What is the Registry? Where does it live on disk? How do system services access and use it? What do you do if it's damaged or corrupted? Every 2000 administrator faces questions like this, often in a desperate attempt to fix something that's broken.
What tools are available? Detailed descriptions of Regedit, RegEdt32, the System Policy Editor, Group Policy Editor and selected Resource Kit utilities explain how to edit and secure the Registry both on local and on remote computers.
How can I access the Registry from a program? Regularly monitoring the Registry's contents is one way to preclude unpleasant surprises. Using examples in C++, Visual Basic, and Perl, Managing the Windows 2000 Registry demonstrates how to create Registry-aware tools and scripts.
What's in the Registry? Not all Registry keys are adequately documented by Microsoft or by the other vendors who store configuration data in the Registry. Managing the Windows 2000 Registry offers a guided tour of some of these undocumented keys.

This book is a "must have" for every 2000 system manager or administrator.

Book Info
System administrator's guide to maintaining, monitoring, and updating the Registry database. Explains what is in a Registry and offers a guided tour of some of the undocumented keys. Softcover. DLC: Microsoft Windows (Computer file)

About the Author
Paul Robichaux is an experienced software developer and author and the principal of Robichaux and Associates, Inc. He has worked on Unix, Macintosh, and Win32 development projects over the past eight years, including a stint on Intergraph's OLE team. He is the author of Managing the Windows NT Registry and Managing Microsoft Exchange Server.

Excerpted from Managing Windows 2000 Registry by Paul Robichaux, Robert Denn. Copyright © 2000. Reprinted by permission. All rights reserved
Chapter 7

Using Group Policies

One of the most powerful capabilities included with Windows 2000 is the Group Policy mechanism. Active Directory provides a comprehensive way for administrators to manage network resources. When you use Active Directory, Group Policy allows you to apply policies to users and computers over the entire hierarchy of your network, from entire domains right down to individual computers.

As you learned in the preceding chapter, the Windows NT 4.0 System Policy Editor is used to configure membership-based permissions for users, groups, and computers in a domain. System policies, such as desktop appearance and program control, can be distributed and applied to whole domains. For Windows 2000 network clients, policies are no longer Registry-based; they're replaced by Group Policy. By associating policies with actual objects in Active Directory, each site, domain, and organizational unit can distribute its own set of policy demands. You manage this capability with the Group Policy snap-in for the Microsoft Management Console (MMC). Group Policy, sometimes referred to as the Group Policy Editor, uses policy files to interface to a system's Registry.

What Are Group Policies? In a general sense, policies define what a user can and can't do. Under Windows 2000, system administrators use Group Policy to manage the policies that apply to computers and users within a site or domain. These policies define certain aspects of the user's desktop environment. They specify system behavior, and they restrict what users are allowed to do. In short, a policy is simply a group of related settings an administrator can set.

Many of these policy settings are applied to keys in the Registry. The specific keys and values written into the Registry depend on the policies you're trying to enforce. In the Windows NT world, policy changes are persistent because they're applied throughout the Registry, and no mechanism exists to sweep away the changes once they're made (though one policy's changes can be overwritten by another set of changes that occurs later).

Under Windows 2000, Group Policy settings that modify the Registry are always applied in one of four Registry subtrees. Microsoft recommends that Windows 2000-savvy applications should look for policy information in HKLM\Software\Policies and HKCU\Software\Policies. If they don't find their settings there, they can look in HKLM\Software\Microsoft\CurrentVersion\Policies and HKCU\Software\Microsoft\Windows\CurrentVersion\Policies. If the application still hasn't found the settings it needs, it can look elsewhere in HKCU or HKLM, or even in INI files (though that's strongly discouraged). None of these subtrees may be modified by nonadministrators.

Elements of a Group Policy Much the same way that the Registry is arranged in a hierarchical structure, policies are categorized into sections and subsections. The sections and subsections that build the hierarchy of Group Policy are called categories. Think of categories like folders: a group policy contains one or more categories, and each category may contain subordinate categories. The subordinate categories may contain their own subcategories, and so on. In addition to containing subcategories, categories contain the specific policies an administrator can configure.

Each policy controls the behavior of one aspect of a user's environment. For example, a simple desktop policy specifies whether to hide all icons on the desktop. There are more elaborate policies that define the default quota limit and warning level for an individual filesystem.

Remember that these specific policies are applied to keys in the Registry. The number of Registry keys affected depends on the complexity of the actual policy. A single policy can consist of multiple settings, or parts. A part represents a single value that is stored in the Registry. Each policy is made up of zero or more parts. The policy for hiding icons on the desktop does not contain any parts; it's simply enabled or disabled. The quota limit and warning level policy, however, contains a number of parts, one for each value that needs to be stored: the default quota limit value, the measurement units for the quota limit, and so on. Since policies require values of various data types, parts differ as to their permissible values. Some parts require strings, some require numeric values, and some parts' values are restricted to a set of predefined values.

User Versus Machine Policies There are two types of group polices: polices that apply to the computer and policies that pertain to users. Computer configuration policies apply to all users on a computer and are active whenever a machine is running. They're stored in the HKLM section of the machine's Registry and include policies that define security settings, desktop appearance, and startup and shutdown scripts. They're applied when the machine boots. This is different from System Policy Editor machine policies, which are applied when a user logs on.

User configuration settings, on the other hand, are active for each user on a computer. They're stored in the Registry under HKCU and define user-specific settings such as assigned programs, program settings, and desktop appearance. Unlike computer settings, which remain in effect until the computer is shut down, user configuration settings are reloaded for each new user. In this way, user policies can be downloaded for a user, regardless of what machine she logs into. You can specify user policies that can be applied to all users of a specific machine, or you can apply policies that apply only to specific users no matter where they log on. TIP:

For detailed information about these templates and the policies, Registry keys, and values that they cover, refer to Appendix A, User Configuration Group Policy Objects, and Appendix B, Computer Configuration Group Policy Objects.

--------------------------------------------------------------------------------

1. You sometimes see reference to the local machine policy; that's just another name for the LGPO.

2. A second, but much more ambitious, way to extend the functionality of Group Policy is to write a software extension for the Group Policy snap-in. Software development, unfortunately, is beyond the scope of this book.

Comments

SEND A COMMENT

PLEASE READ: All comments must be approved before appearing in the thread; time and space constraints prevent all comments from appearing. We will only approve comments that are directly related to the article, use appropriate language and are not attacking the comments of others.