Managing The Windows 2000 Registry: Help for Windows 2000 System Administrators

465 Pages·2000·2.67 MB·English

by  Paul Robichaux

Managing the Windows 2000 Registry
2000 O'Reilly & Associates, Inc.
Printed in the United States of America.
Published by O'Reilly & Associates, Inc., 101 Morris Street,
Sebastopol, CA 95472.
Managing the Windows 2000 Registry

Preface
Keys and Values and Classes, Oh My!
Who's This Book For?
How This Book Is Organized
Conventions Used in This Book
Comments and Questions
Acknowledgments

1. A Gentle Introduction to the Registry
1.1 A Brief History of the Registry
1.2 What Does the Registry Do?
1.3 Advantages Offered by the Registry
1.4 Registry Zen

2. Registry Nuts and Bolts
2.1 How the Registry Is Structured
2.2 What Goes in the Registry
2.3 Getting Data In and Out

3. In Case of Emergency
3.1 Don't Panic!
3.2 Safety Strategies
3.3 All About Emergency Repair Disks
3.4 Backing Up the Registry
3.5 Restoring a Backed-up Registry

4. Using RegEdit
4.1 Know Your Limitations
4.2 Learning the RegEdit Interface
4.3 "Just Browsing, Thanks"
4.4 Connecting to Other Machines' Registries
4.5 Searching for Keys and Values
4.6 Printing Registry Contents
4.7 Working with Keys and Values
4.8 Exporting and Importing Data
4.9 RegEdit Command-Line Options

5. Using RegEdt32
5.1 How RegEdt32 and RegEdit Differ
5.2 Learning the RegEdt32 Interface
5.3 Browsing with RegEdt32
5.4 Remote Registry Editing
5.5 Searching for Keys
5.6 Saving and Loading Registry Keys
5.7 Printing Registry Contents
5.8 Editing Keys and Values
5.9 Registry Security Fundamentals
5.10 Securing Registry Keys in Windows 2000
5.11 Securing Registry Keys in Windows NT

6. Using the System Policy Editor
6.1 All About System Policies
6.2 Introducing the System Policy Editor
6.3 Managing Policies with POLEDIT
6.4 Distributing Policies
6.5 What's in the Standard Policy Templates
6.6 Picking the Right Policies
7. Using Group Policies
7.1 What Are Group Policies?
7.2 Introducing the Group Policy Snap-in
7.3 Managing Policies
7.4 Distributing Policies
7.5 What's in the Standard Policy Templates?

8. Programming with the Registry
8.1 The Registry API
8.2 The Shell Utility API Routines
8.3 Programming with C/C++
8.4 Programming with Perl
8.5 Programming with Visual Basic

9. Administering the Registry
9.1 Setting Defaults for New User Accounts
9.2 Using Initialization File Mapping
9.3 Limiting Remote Registry Access
9.4 Fixing Registry Security ACLs in Windows NT
9.5 Adding Registry ACLs to Group Policy Objects
9.6 Encrypting HKLM\SAM with SYSKEY
9.7 Miscellaneous Good Stuff
9.8 Using the Resource Kit Registry Utilities
9.9 reg: The One-Size-Fits-All Registry Tool
9.10 Spying on the Registry with RegMon

10. Registry Tweaks
10.1 User Interface Tweaks
10.2 Filesystem Tweaks
10.3 Security Tweaks
10.4 Performance Tweaks
10.5 Network Tweaks
10.6 Printing Tweaks

11. The Registry Documented
11.1 What's Here and What's Not
11.2 HKLM\HARDWARE
11.3 HKLM\SOFTWARE
11.4 HKLM\SYSTEM
11.5 HKU
11.6 HKCR
11.7 HKCU
11.8 HKCC
11.9 HKDD

A. User Configuration Group Policy Objects
A.1 Administrative Templates

B. Computer Configuration Group Policy Objects
B.1 Windows Settings
B.2 Administrative Templates

Colophon
Preface
Keys and Values and Classes, Oh My!
Who's This Book For?
How This Book Is Organized
Conventions Used in This Book
Comments and Questions
Acknowledgments
Keys and Values and Classes, Oh My!
The Registry scares people. Practically every Windows NT user or administrator has
some horror story of the damage done to a machine by careless Registry editing.
Microsoft doesn't try to discourage this perception, either; the articles in their
Knowledge Base, as well as documentation in the various resource kits, is liberally
peppered with warnings about the dire consequences of screwing up something vital if
you make a mistake while editing the Registry.
While making a mistaken Registry edit can indeed send your machine to Blue Screen
of Death territory quick as a wink, there's no reason to be afraid of the Registry any
more than you'd be afraid of a chainsaw, your car, or a high-speed lathe. If you know
how to safely handle any of those inanimate objects, you can do much more work
with them than you can manually.
This book teaches you how to safely use the Registry; how to administer, back up,
and recover Registry data on computers running Windows 2000, both locally and over
the network; and how to use the Registry editing tools Microsoft supplies, and when
you should--and should not--do so. Much of the material also applies to Windows NT,
since there are more similarities than differences between the two.
Who's This Book For?
This book is for anyone running Windows 2000, particularly people responsible for
administering networks of Windows 2000 computers or providing technical or help
desk support. It's also for programmers who are familiar with the Win9x Registry and
its workings but are making the move to the similar-looking but internally different
Windows NT/2000 world.
To get the most out of this book, you should be familiar with the Windows 2000 user
interface; you should know how to right-click, run programs, and so on. Some
background as a Windows NT or Windows 2000 administrator would be useful, but
it's not required.
How This Book Is Organized
The book is organized into 11 chapters:
Chapter 1, locates the Registry in the evolution of Windows systems. After a
historical discussion of INI files and their traditional role as the repositories of
configuration information, the chapter offers an apologia for the Registry, its
philosophy, and its advantages.
Chapter 2, discusses the keys, subkeys, values, and hives that comprise the Registry
structure.
Chapter 3, provides the compendium of caution. The major topics of discussion
include the creation of emergency repair disks and strategies for effectively backing
up and restoring the Registry.
Chapter 4, is a complete guide to the original Registry editor.
Chapter 5, is a similar guide to Microsoft's 32-bit Registry editor.
Chapter 6, explains the roles of system policies and the management of them with
POLEDIT.
Chapter 7, describes Windows 2000's group policy object (GPO) mechanism and
explains how to use it to apply policy settings.
Chapter 8, presents the Registry API and follows up with sections on how to
administer the Registry with programs implemented in C++, Perl, and Visual Basic.
Chapter 9, covers a number of vital topics, including user accounts, INI file mapping,
remote access, security, and a number of Resource Kit utilities.
Chapter 10, is a collection of tips and tricks you can use to bring your own system's
Registry under control.
Chapter 11, is a snapshot of the Registry keys created by the Windows 2000 and NT
systems.
Appendix A, describes the group policy settings applicable to user accounts. These
include desktop lockdown and security policies.
Appendix B, describes the group policy settings that can be applied to computers,
including the security and software installation policy components.
Conventions Used in This Book
This book uses the following typographic conventions:
Constant width
Indicates a language construct such as a data type, a data structure, or a code
example.
Constant width italic
In syntax statements, indicates placeholder elements for which the user must
provide actual parameters.
Italic
Indicates filenames, URLs, commands, variable names, utilities, and function
names. Italic is also used to highlight the first mention of key terms.
Registry pathnames can get long and unwieldy. To save space, they are set in roman
text, and the top-level keys are abbreviated as follows:
HKCR HKEY_CLASSES_ROOT
HKCU HKEY_CURRENT_USER
HKLM HKEY_LOCAL_MACHINE
HKU HKEY_USERS
HKCC HKEY_CURRENT_CONFIG
HKDD HKEY_DYN_DATA
This icon marks text describing NT4-specific features that still have relevance in a
a Windows 2000 context
This icon designates a note, which is an important aside to the
nearby text.

This icon designates a warning relating to the nearby text.
Chapter 1. A Gentle Introduction to the Registry
The Windows 2000 Registry plays a key role in making Windows 2000 work. It
serves as a central data repository, and it's involved in everything you do with
Windows 2000 computers, from the initial boot sequence to logging in and running
applications and services. For such an important component, though, there is
surprisingly little documentation that explains how the Registry works, what's in it,
and what it's good for. Even seasoned Windows NT administrators who are making
the leap to Windows 2000 admit to being a little unsure of the Registry's inner
workings.
Part of the Registry's mystery comes from the fact that its data is stored in a special
format that can be read only with the tools and programming interfaces routines
Microsoft provides; part comes from the strict warnings against Registry tampering
plastered on page after page of Microsoft (and third-party) documentation, books, and
web pages. However, since the Registry's an integral part of Windows 2000, you
should be comfortable using, repairing, and modifying it if you want to administer
Windows 2000 systems. The overall goal of this book is to demystify the Registry's
workings and help you understand when, how, and why Windows 2000 services,
applications, and operating-system components use it so you'll be better able to
administer the machines under your care.
1.1 A Brief History of the Registry
Before I plunge into the nuts and bolts of working with the Registry, let me set the
stage by explaining how the Registry gained its starring role in Windows 2000.
Besides being good preparation for amazing your friends with computer-industry
trivia, the Registry's path to fame illustrates some of its strengths and weaknesses.
In the beginning, of course, there was no Registry. MS-DOS applications were
responsible for storing their own persistent settings in configuration files. The
operating system had its own set of configuration files; the most famous of these files
are config.sys andautoexec.bat, which control hardware and operating system settings.
At first blush, this approach may seem reasonable. After all, applications' settings are
generally private, and they don't usually affect other programs. Most components of
MS-DOS itself weren't configurable anyway, so there was little need (or demand) for
a better configuration mechanism. If the configuration data for a single application
was lost or corrupted, restoring it was reasonably simple and could be done without
affecting anything else on the computer.
1.1.1 Windows 3.0
Windows 3.0 improved on the MS-DOS approach by introducing the idea of a single,
systemwide set of operating-system preference and settings data. In addition to DOS'
configuration files, Windows 3.0 itself added four initialization files ( progman.ini,
control.ini, win.ini, and system.ini ) that contained information about the system's
hardware configuration, device drivers, and application settings. These files quickly
became known as INI files, after their extension.
Microsoft chose a simple, human-readable ASCII format for INI files; not only did
this ease the task of writing programs to use these files, but it also made it possible for
end users to inspect and change their contents. One of the important features
Microsoft wanted to deliver in Windows 3.0 was Macintosh-like customization; users
wanted to be able to set their own color schemes, fonts, desktop backgrounds, and so
on. By default, the Windows File Manager included a file mapping so that double-
clicking an INI file would open it in the Notepad text editor, as shown in Figure 1.1.
Figure 1.1. Simple INI file

In addition to storing Windows' settings in INI files, Microsoft provided a set of API
routines (often called the private profile API ) that gave programmers a way to create
their own initialization files. The theory was that application programmers could use
INI files to store private settings that were specific to their applications. Settings that
could be useful to several applications--for example, lists of which fonts were
installed on a computer--lived in the system's INI files, while application-specific
settings were in the application's private INI files. Application programmers
enthusiastically embraced this idea, and before long most applications used INI files
for their private settings.
However, INI files weren't perfect; in fact, they suffered from some fairly serious
weaknesses:
They were easily editable
An old quote from the Unix fortune program says that you can make software
foolproof, but you can't make it damn-fool proof. INI files quickly provided a
concrete example of this old saw; because INI files were editable, users felt
free to edit them. This flexibility did make it easy for users to customize their
environments or make necessary changes; it also made it much easier for a
user to break a single application, an entire service (such as printing or file
sharing), or Windows itself by making an accidental or ill-informed change to
an INI file.
They were easy to break
INI files provided a one-time link between a program and its settings; they
weren't dynamic enough to reflect changes in the machine's configuration or
environment. For example, many presentation graphics programs built a list of
available fonts during their installation process. If you later added—or, worse,
remov—fonts, the presentation package might or might not notice the changes,
meaning either that you couldn't use newly installed fonts or the package
could crash while trying to use fonts the application thought were still
available. This lack of flexibility was partly due to the fact that Windows
didn't have any way to be notified when something on the computer was
changed; without these alerts, there was no way to tell when INI file data
needed to be updated.
They led to Balkanization
Microsoft didn't provide any explicit guidelines as to where INI files should be
stored or what should go in them; in the absence of these rules, application
programmers felt free to put INI files in various locations. Some used the
Windows directory itself, while others stored their INI files in the same
directory as the application or in some other seemingly logical location. To
compound the problem, some applications put their private data directly into
win.ini, while others kept their own private copies of such things as font lists
and printer settings that were explicitly supposed to be shared between
applications.
They had implementation limits
INI files had to be smaller than 64 KB in length; in addition, the Windows
profile API calls blissfully ignores all but the first instance of settings with the
same name within one section of the file. An even more serious limit was that
INI files were inseparably bound to the original PC concept of "one user, one
machine"; there was no way to easily move settings around so that users who
needed to use different computers could keep their preferred settings.
1.1.2 The First Registry: Windows 3.1
Windows 3.1 added several new features that improved interapplication integration
and ease of use. Chief among them were two new technologies, Object Linking and
Embedding (OLE) and drag and drop. Both features required an up-to-date, correct
database of program locations and capabilities. For example, object embedding could
only work if the source and destination applications had some way to communicate
exactly what type of data was being embedded, and the File Manager required access
to a database of mappings to associate files with the applications that created them.
To provide this information, Windows 3.1 included the first Windows registration
database, which quickly became known as the Registry. This Registry offered
solutions to several of the problems posed by INI files:
The Registry provided a single place to store data