o'reilly - managing the windows 2000 registry

Managing the Windows 2000 Registry Copyright © 2000 O'Reilly & Associates, Inc. All rights reserved. Printed in the United States of America. Published by O'Reilly & Associates, Inc., 101 Morris Street, Sebastopol, CA 95472. Nutshell Handbook, the Nutshell Handbook logo, and the O'Reilly logo are registered trademarks of O'Reilly & Associates, Inc. The association between the image of an orangutan and the topic of the Windows 2000 Registry is a trademark of O'Reilly & Associates, Inc. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and O'Reilly & Associates, Inc. was aware of a trademark claim, the designations have been printed in caps or initial caps. While every precaution has been taken in the preparation of this book, the publisher assumes no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein. 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. Comments and Questions The information in this book has been tested and verified, but you may find that features have changed (or you may even find mistakes!). You can send any errors you find, as well as suggestions for future editions, to: O'Reilly & Associates, Inc. 101 Morris Street Sebastopol, CA 95472 (800) 998-9938 (in the United States or Canada) (707) 829-0515 (international/local) (707) 829-0104 (fax) There is a web page for this book, where examples, errata, and any plans for future editions are listed. The page also includes a link to a forum where you can discuss the book with the author and other readers. You can access this page at: http://www.oreilly.com/catalog/mwin2reg/ To ask technical questions or comment on the book, send email to: bookquestions@oreilly.com For more information about our books, conferences, software, Resource Centers, and the O'Reilly Network, see our web site at: http://www.oreilly.com Acknowledgments When I first approached Robert Denn at O'Reilly & Associates about revising Managing the Windows NT Registry to cover Windows 2000, neither of us realized what we were getting into. The devil is always in the details, and Windows NT and Windows 2000 are superficially similar in lots of ways but then the details rear their ugly heads. As with my other O'Reilly books, I was fortunate to work with a team of true professionals at O'Reilly's Cambridge office, led by the tireless (and very patient) Robert Denn. Steven Abrams was the editorial assistant for this book. This book benefited from the technical knowledge and writing skill of two other writers. Tom Fronckowiak, cryptographer to the stars, wrote Chapter 7 and revised Chapter 10 and Chapter 11 when my schedule began to oppress me. Likewise, Greg Bacon applied his considerable Perl talents to revising the Perl coverage in Chapter 8 so that it was more in keeping with an O'Reilly book; something my own meager Perl skills would have prevented. Tye McQueen, author of the Win32::TieRegistry module, generously allowed me to use his documentation as a base for the Perl discussion. The technical review process for this book took longer than usual, in large part because of the volume, and quality, of technical review comments I got back. I'd like to thank my friend Glenn Fincher for taking time out of his busy schedule to review the book; in addition, my thanks go to the other reviewers, Jon Forrest, Cory L. Scott, David White, and Adam Wood. I would be remiss if I didn't mention that this book was entirely written on a variety of Apple Power Macintosh and PowerBook computers. In fact, I even wrote the code in Chapter 8 on the Mac using Metrowerks CodeWarrior, then tested and debugged it on a "real" PC running Windows 2000. I use and manage Windows NT and 2000 every day, but I'm a more productive writer with the Mac go figure. I am indebted to David Rogelberg and the staff of StudioB Productions, the literary agency that represents me. David makes the easy tasks happen invisibly and handles the hard tasks without ever breaking a sweat, raising his voice, or appearing rattled in the least. I appreciate his negotiating skills, his extensive web of industry contacts, and his role as the voice of reason. Lastly, I could not have even considered this project without the love, support, and help of my wife Arlene and my two sons, David and Thomas. I am truly blessed to have such a loving and supportive family. 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. [...]... Windows 2000 Early rumors said that the metabase, used by the Internet Information Server (IIS) product family, would supplant the Registry in Windows 2000, but neither the metabase nor the Active Directory have completely replaced the Registry The Windows NT Registry editors survive virtually unchanged, as do the application programming interfaces programs use to read and write Registry data (though there... profile-less user gets if there's no default profile in the NETLOGON share The second group of settings are for the built-in Administrator account Windows 2000 is a little different; at any time when a user is logged on to the machine's console, there will be three subkeys under HKU The first is DEFAULT, which serves the same function it does in NT 4.0 The other two contain the settings of the logged-on... software to use the Registry instead of INI files They set a fairly good example by making most NT system components and applications use the Registry themselves; as an added incentive, they provided a special facility that lets older Windows 3.x programs use the Registry instead of an INI file automatically by creating a copy of the INI file in the Registry To top off these changes, the original version... first When faced with the choice of finding data in HKCU\Software\KoolStuff\AnApplication or the mysterious-looking HKU\S- 1-5 -2 1-1 94413561 2-1 19977719 5-2 4521265500\Software\KoolStuff\AnApplication, the choice is pretty clear More importantly, since the Windows 9x family lacks the API routines needed to get SIDs, code written to use HKCU can run without modification on Windows 95/98, NT, 2000, and even CE... part of Windows 2000 attempts to reserve an IRQ, port address, and DMA block to talk to the sound card Which values it requests depends on the hardware configuration information gathered by ntdetect Once the driver has staked out the device and resources it needs, the Registry reflects the driver's reservations so other drivers that load later in the boot sequence won't try to seize them Each of these... both keep their user profile data in the Registry Figure 1.5 User versus application settings Of course, applications can freely use any of the other types of data stored in the Registry For example, an image-retouching program can use the Registry to get the I/O address of the port to which the user has connected his digital camera, or a web page editor might use it to fetch a list of all the ActiveX... separate INI files typically found on a Windows 3.1 machine, Windows NT /2000 machines usually only have a few, and those typically belong to 16-bit legacy applications that can't use the Registry Windows 2000 itself uses the Registry for its configuration data, as do almost all 32bit applications written for Windows 9x and NT /2000 There's more to tidiness than just the reduction in clutter that comes from... it, the space is yours to use as you wish (though you're not supposed to live in them or keep anything illegal or dangerous there) Just like the local U-Store-It, every tenant of the Registry has its own individual space, where it can store anything under the sun Access to that space is controlled both by the operating system and the tenant who created the keys Also like the realworld equivalent, the. .. actually logically separate entities The groupings just provide a convenience for users The six root keys that make up the Registry (see Section 2.1.2 later in this chapter) are logically independent of one another; to reinforce this idea, the Windows 200 0- specific Registry editor, RegEdt32, shows each root key in an individual window In Windows 2000 and Windows NT 4.0, there are six root keys: HKEY_CURRENT_USER... beekeepers any more.[2] In the Registry world, a hive is a portion of the Registry tree structure from any subkey under a root key on down For example, the SOFTWARE hive contains HKEY_LOCAL_MACHINE\Software and all its subkeys, and their subkeys, and their subkeys, on down to the values attached to the "deepest" subkey [2] In Managing the Windows NT Registry, I admitted to not knowing where the term "hives" . 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. revising Managing the Windows NT Registry to cover Windows 2000, neither of us realized what we were getting into. The devil is always in the details, and Windows NT and Windows 2000 are superficially. and Windows 2000. Early rumors said that the metabase, used by the Internet Information Server (IIS) product family, would supplant the Registry in Windows 2000, but neither the metabase nor the