Policies are the way that computers are managed,
either standalone computers or computers in the enterprise. Policies
establish the vast majority of the configuration settings that control
how the computer boots up and then how your desktop environment is
constructed when you log on.
The Standalone Computer
Each computer has a Local
Computer Policy, or LCP (also referred to as the Local GPO or LGPO), that is made up of many configuration settings on
the various configuration dialog boxes throughout the user interface, as
well as numerous settings that are configurable only in a Microsoft
Management Console (MMC) called the Local Computer Policy. This policy
is stored in the Registry on the computer’s hard drive and is applied
every time the computer is booted up. This computer configuration from
the Local Computer Policy gets read into random access memory (RAM) on
the computer. Think of this RAM copy of the Registry as the live, awake
brain of the computer when it is booted up. This RAM copy of computer
settings from the Registry is in place when you are presented with the
Windows Graphical Identification aNd Authentication (GINA) dialog box.
Further
configuration for the desktop environment is controlled by configuration
parameters stored within your user profile in a file called NTUSER.DAT.NTUSER.DAT gets read into RAM from your profile folder when
you successfully log on to the computer. As you make changes to your
desktop environment, like the desktop wallpaper or items on the Start
menu, these changes get recorded in the RAM copy of NTUSER.DAT. When you log off, by default, the operating
system saves these changes into your profile. This file is the primary
source of the configuration parameters that define your desktop
environment.
The first time you log on to a
computer, the operating system copies a read-only and hidden folder
under C:\Users called \Default
to a new folder under C:\Users and
renames the new folder with your logon name. Within that folder is the
file named NTUSER.DAT. This
becomes your user profile on this specific computer. After that first
logon on a given computer, now that you have an existing profile, this
existing copy of NTUSER.DAT is the one
that gets read into RAM for your user profile.
To
summarize, two components define a desktop environment on a standalone
computer (not participating within an Active Directory environment): the
configuration parameters in the Local Computer Policy and the
configuration parameters in your user profile. They get applied in that
order.
The LCP can be accessed on a
Windows Vista computer by building it into a new MMC.
Building a Local
Computer Policy (LCP)
To build the Local
Computer Policy (LCP) MMC, follow these steps:
1. | Click Start > Run, type MMC, and click OK.
(You can also use Start > Start Search
> MMC and then press Enter.)
|
2. | From the menu, select File
> Add / Remove Snap-in.
|
3. | Select Group
Policy Object snap-in and click Add.
|
4. | Accept the Group Policy Object for the Local Computer
by clicking Finish.
|
5. | Click OK.
|
6. | From the menu, select File
> Save As.
|
7. | Type LCP.msc and save
the MMC either on the desktop or in Administrative Tools.
|
The Domain Member
Computer
Back in the old days of the
Windows NT domain and Windows 95 clients, Microsoft used something
called System Policies, built using a tool called the System Policy Editor, to
manage and configure these down-level computers. These System Policies
would “tattoo” the Registry of the local box, actually writing settings
to the Registry files on the local hard drive. If you wanted to remove
policy settings from the computers, you had to write a new System Policy
that would actually reverse the settings from the policy that was being
removed.
When Windows 2000 was
released, Microsoft implemented a whole new generation of policies and
completely overhauled how they were applied on computers. These policies
were improved yet again with the release of Windows XP, Windows Server
2003, and now again with Windows Vista. These new policies are called Group
Policy Objects, or GPOs, and they exist in the Active Directory in an enterprise environment. These policies get
applied to the computer over the top of the Local Computer Policy and
your user profile settings to provide enterprise administrative
dominance over the local configuration settings.
Note
GPOs Apply to Domain
Members Only Keep in mind that GPOs
affect only computers and users that are members of an Active Directory
domain. If the computer and user are not members of an AD domain, only
the Local Computer Policy and the user’s profile get applied to the
user’s desktop session. No GPOs. If you apply a GPO in AD and don’t see
the effects on the computer and user, double-check to be sure that the
computer and user are members of the AD domain.
These new policies do not
affect the configuration files on the hard drive (for the most part), so
they do not “tattoo” the computer. Rather, as these new policies get
applied, they modify the copy of the Registry (computer) and the profile
(user) that has been read into RAM on the computer during the initial
bootup and then the user logon for the current session. These
modifications to settings do not get written back to the hard drive
copies of the configuration files. Remember that this RAM copy is the
actual functional copy that is being used to control and configure the
user’s current session.
L-S-D-OU-OU-OU
Active
Directory (AD) is a database and a
collection of directory services that support the database and the
network operating system. AD is created by configuring one or more
domain controllers on a network. AD utilizes four types of containers to
store and organize AD objects, like computers and users:
Forests
Sites
Domains
Organizational Units
You can apply GPOs to sites,
domains, and Organizational Units.
AD Forest
The AD forest is one or more AD domains that share a common
schema. The schema is the structure of the AD database—not the data
within the database, just the structure. The forest is created when you
run DCPromo on a server to install
your first domain controller in the first domain in the forest. This
first domain
is referred to as the forest root domain. The name of this forest root domain also is the
name of the forest. All domains within the forest are trusted by and
trusting of all other domains within the forest. Therefore, since
members of your forest are, by default, all trusted and trusting, a lack
of trust with some new domain indicates the need to generate a second
forest, or create the new, untrusted domain in a different, existing
forest. Forests are logical containers and have no real connection to
any physical location, other than you must place your domain controllers
somewhere. GPOs cannot be linked to the forest.
AD Sites
AD sites are created in AD once the forest is established
and are defined as a collection of well-connected segments, where the
bandwidth is at least local area network (LAN) speed. LAN speed is
currently considered to be 10Mbps or greater. Any network link between
segments that drops below LAN speed is defined as a boundary of the site
and indicates the need for the creation of an additional site. Because
sites are defined by physical connectivity, they are considered to be
physical containers, with one site per location that is connected to AD
by slower links. There are two major benefits to defining sites:
Client computers within a
site are preferentially directed to local (within the same site)
resources.
AD
replication within the site happens without much regard for bandwidth
consumption (because all segments are well connected at high bandwidth
LAN speeds), but AD replication between sites, over slower wide area
network (WAN) links, can be carefully controlled so as to avoid
saturation of these lower bandwidth links. GPOs can be linked to sites.
AD Domains
AD domains are logical containers that are created within an AD forest.
Domains (and AD) are created, and exist, on domain controllers. Domains
in AD are security boundaries. In Windows Server 2003, they are defined
by their unique namespace, like mobeer.com, buymeabeer.us,
or boboville.com, as well as their single-password policy per
domain. If you need a different namespace, you need another AD domain.
If you need a different password policy for users, you need another AD
domain. Domains are logical containers and can exist in multiple sites
if placed in one or more domain controllers in more than one site. GPOs
can be linked to the domain.
Note
Password
Policies Password policies for domain
users must be applied at the domain level.
Organizational Units
(OUs)
Organizational
Units (OUs) are logical containers
that are created within an AD domain. They are designed to be used to
organize computers and users for two purposes: to delegate
administrative authority of groups of computers and users to different
administrators, and to provide grouping of computers and users for the
assignment of different Group Policy Objects (GPOs). OUs can be nested
within another parent OU, so they create a hierarchical structure, like
the one shown in Figure 1. GPOs can be linked to Organizational Units.
The OU is represented in AD
Tools by a folder with a book icon on it. A folder without a book icon
on it is not an OU but is an AD container that cannot have GPOs linked
to it. By default, AD provides only one OU called the Domain Controllers OU so
that security-related GPOs can be applied to this most sensitive class
of servers. Administrators must create all other OUs.
Policies are applied in the
order of L-S-D-OU-OU-OU. That is the Local policy, then site policies, then
domain policies, and finally OU policies, starting with the top-level
OU, and then followed by its child OU, and then its child OU, and so on.
Policies have two halves:
A computer half, called the
Computer Configuration
A user half, called the User Configuration (see Figure 2)