ULTIMATE REGISTRY GUIDE Part II

Must−Know Concepts
Learning the concepts in the following sections is important to your satisfaction with this book.
These are the things you must know to work efficiently with the registry. For example, the registry is
filled with hexadecimal numbers, and if you don't understand hexadecimal, they're not going to
make sense to you. If you're a programmer, you can probably skip these sections; otherwise, don't
The following sections walk you through the most important of these concepts, beginning with
security and globally unique identifiers. You learn how to read hexadecimal numbers and convert
them to binary and decimal notation and use them as bit masks. You learn the difference between
Unicode and ANSI character encoding. You even learn how Intel−based computers store numbers
in memory. All of these topics are significant to your ability to use the registry as a tool.
Security Identifiers
Computer accounts, user accounts, groups, and other security−related objects are security
principles. Security Identifiers (SIDs) uniquely identify security principles. Each time Windows XP or Active Directory creates a security principle, they generate a SID for it. Windows XP's Local Security
Authority (LSA) generates SIDs for local security principles and then stores them in the local
security database. The Domain Security Authority generates SIDs for domain security principles
and then stores them in Active Directory. SIDs are unique within their scope. Every local security
principle's SID is unique on the computer. And every domain security principle's SID is unique within
any domain in the enterprise. What's more, Windows XP and Active Directory never reuse a SID,
even if they delete the security principle to which that SID belonged. Thus, if you delete an account
and then add it back, the account gets a new SID.
The important thing to remember is that every account has a SID. It's kind of like having a passport
number that uniquely identifies you to immigration. You can refer to an account by its name or by its
SID, but in practice you seldom use the SID because its format is cumbersome. You frequently see
accounts' SIDs in the registry, though, and that's why you're learning about them here.
An example of a SID is S−1−5−21−2857422465−1465058494−1690550294−500. A SID always
begins with S−. The next number identifies the SID's version—in this case, version 1. The next
number indicates the identifier authority and is usually 5, which is NT Authority. The string of
numbers up to 500 is the domain identifier, and the rest of the SID is a relative identifier, which is
the account or group. This is a real rough overview of the format of a SID, which is much more
c o m p l e x t h a n t h i s b r i e f e x a m p l e . I f y o u w a n t t o l e a r n m o r e a b o u t S I D s , s e e
http://www.microsoft.com/windows2000/techinfo/reskit/en/distrib/dsce_ctl_xgqv.htm, which is a
section in the Windows 2000 Resource Kit about SIDs.
Some SIDs are shorter than the previous example, such as S−1−5−18. These are well−known
SIDs, and they are the same on every computer and in every domain. They are interesting because
they pop up over and over again in the registry and in other places. Table 1−1 describes Windows
XP's well−known SIDs. I've italicized the names of SIDs that are of particular interest to you while
you're reading this book. The placeholder domain is the SID's domain identifier.
Table 1−1: Well−Known SIDs
SID User or Group name
S−1−0 Null Authority
S−1−0−0 Nobody
S−1−1 World Authority
S−1−1−0 Everyone
S−1−2 Local Authority
S−1−2−0 Local
S−1−3 Creator
S−1−3−0 Creator Owner
S−1−3−1 Creator Group
S−1−3−2 Not used in Windows XP
S−1−3−3 Not used in Windows XP
S−1−4 Nonunique Authority
S−1−5 NT Authority
S−1−5−1 Dialup
S−1−5−2 Network
S−1−5−3 Batch
S−1−5−4 Interactive
S−1−5−5−X−Y Logon Session
S−1−5−6 Service
S−1−5−7 Anonymous
S−1−5−8 Not used in Windows XP
S−1−5−9 Enterprise Domain Controllers
S−1−5−10 Self
S−1−5−11 Authenticated Users
S−1−5−12 Restricted
S−1−5−13 Terminal Service User
S−1−5−14 Remote Interactive Logon
S−1−5−18 LocalSystem or System
S−1−5−19 LocalService
S−1−5−29 NetworkService
S−1−5−domain−500 Administrator
S−1−5−domain−501 Guest
S−1−5−domain−502 krbtgt
S−1−5−domain−512 Domain Admins
S−1−5−domain−513 Domain Users
S−1−5−domain−514 Domain Guests
S−1−5−domain−515 Domain Computers
S−1−5−domain−516 Domain Controllers
S−1−5−domain−517 Cert Publishers
S−1−5−root domain−518 Schema Admins
S−1−5−root domain−519 Enterprise Admins
S−1−5−root domain−520 Group Policy Creator Owners
S−1−5−domain−553 RAS and IAS Servers
S−1−5−32−544 Administrators
S−1−5−32−545 Users
S−1−5−32−546 Guests
S−1−5−32−547 Power Users
S−1−5−32−548 Account Operators
S−1−5−32−549 Server Operators
S−1−5−32−550 Print Operators
S−1−5−32−551 Backup Operators
S−1−5−32−552 Replicator
S−1−5−32−554 Pre−Windows 2000 Compatible Access
S−1−5−32−555 Remote Desktop Users
S−1−5−32−556 Network Configuration Operators
S−1−6 Site Server Authority
S−1−7 Internet Site Authority
S−1−8 Exchange Authority
S−1−9 Resource Manager Authority


Deploying with Answer Files
Users installing Microsoft Windows XP on their own computers don't often worry about automating
the setup program. Instead, they drop the CD in the drive, the setup programs starts, and they
answer the setup program's prompts. That won't work in a business because most business users
don't know the answers to all the setup program's questions. Automating the setup program
prevents users from having to fumble with the installation. Furthermore, as an IT professional, you
want to ensure that users have a positive experience so that they say good things about you.
You should still consider automating Windows XP installation even if you are a power user. It makes
installing Windows XP more convenient, and options are available to you through answer files that
just aren't available through the setup program's user interface.
Microsoft provides several tools that help you to deploy automated and customized Windows XP
installations. Each tool has purposes, strengths, and weakness that are different from the other
tools in various deployment scenarios. Examples of deployment tools include Sysprep for disk
imaging and Remote Installation Service, both of which come with the Microsoft Windows 2000
Server and Microsoft Windows .NET Server family of products. Every deployment method and tool
has unattended answer files, which you use to automate the setup program so that it runs with little
or no user interaction. The operating system's setup program uses the information contained in the
answer files rather than prompting users for it.
Answer files are text files that look like INI files. Answer files have many sections, and each section
contains settings. Because this book is about Windows XP's registry and user settings rather than
desktop deployment, I only introduce you to answer files.
After you learn the basics, I'll describe two answer file features that specifically enable you to deploy
user settings as part of the Windows XP setup process. If you're interested in learning more about
deploying Windows XP, see the Microsoft Windows XP Corporate Deployment Tools User's Guide.
You find it in Deploy.chm, which is in the Deploy.cab cabinet file in the Support\Tools folder of your
Windows XP CD. You start this chapter by learning how to add files to Windows XP distribution files