The Best Damn Windows Server 2003 Book Period- P60 ppsx

meet the “Certified for Windows” requirements. If you stick with the standards, any changes you
make will be less likely to cause problems.
Working with the Schema MMC Snap-In
When working with the Schema snap-in, you need to be aware of some other configuration items.
If you right-click Active Directory Schema, you are presented with various options as shown in
Figure 16.12.
If you select Change Domain Controller, you can choose what DC you want to feed the
schema information. If you select Operations Master, you can see what server is holding the
Schema Master role, or change the server responsible for that role.You can use the Permissions
option to change permissions on the schema. In most cases, network administrators would have no
reason to go into the Permissions tab.
The last option in the first section of the list is Reload the Schema.This option will reload the
schema from the database to make sure you don’t have cached information that could be outdated.
When working with the Schema snap-in in a mixed environment, you might find yourself at a
Windows 2000 server. If you are making schema modifications from a Windows 2000 server, you
must ensure that Service Pack 3 for Windows 2000 has been installed.
Modifying and Extending the Schema
There will be times when the default schema layout doesn’t meet your needs. If this is the case, you
can modify the schema by changing existing classes or attributes.You could also extend the schema
by adding classes or attributes that do not exist. Again, you must be extremely careful when making
changes to the schema; modifying or extending the schema should only be done when absolutely
necessary.
556 Chapter 16 • Working with Global Catalog Servers and Schema
Figure 16.12 Schema Administrative Options
301_BD_W2k3_16.qxd 5/12/04 1:28 PM Page 556
To modify or extend the schema, use the Schema snap-in. Begin by making your changes in a
test environment and testing thoroughly before making modifications or extensions on your pro-
duction network. Remember that the user using the snap-in must be a member of the Schema
Admins group. Before you modify the schema by changing or adding classes or attributes, keep the
following guidelines in mind:
■

Double-check to be certain that the existing schema configuration does not meet your
needs. It is possible that there is an existing class or attribute that will work for your
requirements.
■
When you add a class or attribute, that class or attribute cannot be removed.You can, how-
ever, deactivate a class or attribute. We will look at that in the next section.
■
Make sure you have a valid OID; do not just pick one out of thin air.
■
Default system classes cannot be modified. Windows uses these classes for basic function-
ality.
■
Review documentation on the schema. In particular, review the Active Directory
Programmer’s Guide, which can be downloaded at www.microsoft.com, if you intend to
make extensive modifications or extensions.
■
Remember that schema changes affect the entire forest, because only one schema exists in
a Windows Server 2003 forest and is shared by all domains in that forest.
When creating a new class, various attributes need to be filled out as shown in Figure 16.13.
The first section is the Identification section.You will have to complete both Common Name and
LDAP Display Name.You also have to enter the object ID, so you need to know how they are
assigned.There is also an optional Description attribute that you use if you want to.
The other section is Inheritance and Type.The Parent class will have permissions assigned. Being
a Child class, we would inherit the permissions from the Parent class objects.
Working with Global Catalog Servers and Schema • Chapter 16 557
Figure 16.13 Create a New Object Class
301_BD_W2k3_16.qxd 5/12/04 1:28 PM Page 557
Deactivating Schema Classes and Attributes
If changes or additions are made to the schema, they cannot be deleted. Windows Server 2003 does not
allow for deletion of classes or attributes after they are defined in the schema. However, you can

deactivate a class or attribute if you don’t want to use it anymore.This is essentially the same as dele-
tion, because the class or attribute is no longer available for use. However, the class or attribute still
exists within the schema.The deactivated class or attribute is called defunct. Default classes and
attributes cannot be deactivated. If you decide that you need to have the attribute available, you can
reactivate it later.
When you deactivate a class or attribute, you can redefine it if your forest is at the Windows
Server 2003 functional level. For example, if you have an attribute that has the wrong syntax, you
can deactivate the existing attribute and then create a new attribute with the proper syntax.You can
reuse the LDAP display name and the OID. Note that you have to rename the original attribute
after you deactivate it and before you create the new attribute to prevent conflicts.
You use the Schema snap-in to deactivate or reactivate an attribute or class. Figure 16.14 shows
where you can activate or deactivate an attribute.
Create and deactivate classes or attributes
In this procedure, you will use the Schema snap-in to create an attribute, and then you will deacti-
vate it.You should work on a test system before using this procedure on a live schema since addi-
tions to the schema cannot be removed (only deactivated).
1. Open the Schema snap-in.
2. Expand Active Directory Schema, right-click Attributes, and select Create Attribute.
3. Click Continue at the warning dialog box.
4. In the Common Name dialog box, type Telephone number 2.
558 Chapter 16 • Working with Global Catalog Servers and Schema
Figure 16.14 Activating or Deactivating
301_BD_W2k3_16.qxd 5/12/04 1:28 PM Page 558
5. In the LDAP Name dialog box, type Telephone number 2.
6. For the OID, type 2.5.4.20.2.
7. Change the syntax drop-down to Integer, and then click OK.
8. Now, find the new attribute, right-click, and choose Properties.
9. On the General tab, you should see a check box for Attribute is Active.
10. Click the check box to remove the check. Click Ye s to the question about the making the
object defunct.

11. Click OK and the status window in the details pane should show Defunct under the
Status column.
Troubleshooting Schema Issues
You might run into issues when working with the schema.They could be as simple as not finding
the Schema snap-in to not being able to extend the schema.The most common problem is running
or finding the snap-in. Make sure you register the .dll for the snap-in, and then create a customized
MMC to run the snap-in.
There might be times where you simply cannot extend the schema; for example, if you are
trying to add a class and are unable to complete the operation. A few things could cause this; the
most common being that the user trying to make the changes is not a member of the Schema
Admins group. In addition, the Schema Operations Master role has to be up and available on the
network. If the Schema Operations Master role is across a WAN link, you might be experiencing
too much latency.You can move this role if needed to solve network connectivity problems.
You might also experience an issue where you cannot associate an attribute with a class.
This is because the schema cache is not up to date. If this happens, you need to make sure
the Schema cache is updated by reloading the schema.This could also be caused by trying
to make changes on a server other than the Schema Operations Master. When modifying
the schema, it is recommended that you make changes on the server running the Schema
Operations Master role.
Working with Global Catalog Servers and Schema • Chapter 16 559
301_BD_W2k3_16.qxd 5/12/04 1:28 PM Page 559
301_BD_W2k3_16.qxd 5/12/04 1:28 PM Page 560
Working with Group
Policy in an Active Directory
Environment
In this chapter:
 Understanding Group Policy
 Planning a Group Policy Strategy
 Implementing Group Policy
 Performing Group Policy Administrative Tasks

 Applying Group Policy Best Practices
 Troubleshooting Group Policy
Introduction
We briefly touched on Group Policy in earlier chapters. In this chapter, we’ll take an in-
depth look at Group Policy in Windows Server 2003. Group Policy is used to manage
and control various features and components of the Windows Server 2003 network.
Group Policy settings can be used to define users’ desktop environments, to specify
security settings, and to configure and control application behavior. Group Policy can be
used to automatically deploy software to users and computers.You can also use group
policies to assign scripts and redirect folders. Policies can be applied to a site, a domain,
an organizational unit (OU) or a local computer.
Because Group Policy is used for so many important management functions, it is
important for network administrators to be intimately familiar with how Group Policy
works, and how they can use it for more flexibility and control of network components.
This chapter starts with a brief review of the basics of Group Policy terminology
and concepts, including user and computer policies and Group Policy Objects (GPOs).
We discuss the scope and application order of policies, and you’ll learn about Group
Policy integration in Active Directory. We show you how to plan a Group Policy
Chapter 17
561
301_BD_W2k3_17.qxd 5/12/04 2:18 PM Page 561
strategy, and then walk you through the steps of implementing Group Policy. We show you how to
perform common Group Policy tasks, and discuss Group Policy propagation and replication.You’ll
also learn best practices for working with Group Policy, and we’ll show you how to troubleshoot
problems with Group Policy.
Understanding Group Policy
Group Policy is derived from the System Policies of the Windows NT days, and has been signifi-
cantly enhanced, first in Windows 2000 and now again in Windows Server 2003. Implementing
Group Policy in the Active Directory allows system administrators to control aspects of the user or
service environment within the network from a global perspective.

You can use Group Policy to accomplish the following tasks, among others:
■
Assign scripts You can specify scripts that will run at login, logoff, startup, shutdown,
and other times.
■
Manage applications You can designate applications that will be installed on, updated
on, or removed from computers.
■
Redirect folders You can specify alternate locations for system folders, such as My
Documents, My Pictures, and others.
■
Change Registry settings You can designate a set of Registry settings that will be
applied to the local computer when a user logs on.
Gaining a full understanding of how Group Policy can impact the network requires a full
understanding of the terminology and concepts.
Terminology and Concepts
You will encounter a number of terms, acronyms, and jargon when designing and implementing a
group policy in your organization. When we refer to Group Policy, we are actually talking about the
superset of all the individual components that make up the larger whole.You will find policy ele-
ments that affect only users or computers, policies that are set at the workstation level or applied to
an OU in Active Directory, and ways to apply basic security to policies. Let’s review the basic terms
used as the foundation of building Group Policy.
Local and Non-Local Policies
Group Policy allows you to set policies that will impact resources connecting to a specific computer
or interacting with the entire directory.The terms local policy and non-local policy identify where the
group policy settings originate. A local policy is stored on a specific computer (a workstation or a
member server) and applies only to activities on that computer. For example, a local policy only
affects a user object when the user logs on interactively on the server, either at the console or via
terminal services. Local policies can also affect the way a user object accesses data from the specific
server across the network. Generally, local policies should only be used on workstations; however,

there are a few situations where local policies on a server would make sense.
562 Chapter 17 • Working with Group Policy in an Active Directory Environment
301_BD_W2k3_17.qxd 5/12/04 2:18 PM Page 562
Non-local policies are applied primarily to group objects.These policies affect objects in the
directory and are enacted when the object is active in the network. If a non-local policy affects a
user object, its effect is applied every time that user object logs on, no matter what PC is used as the
logon console. Group policies can apply to any of the following:
■
A local computer
■
An entire site
■
A domain
■
A specific OU
Group policies can be filtered through security settings, much like NTFS file and folder permis-
sions control access to data on a server volume. As you will see shortly, there is a specific order in
which policies are applied if local and group policies differ in a specific area, but the best practice
for policies in general is to apply the policies at the group level, not at the local level.
User and Computer Policies
As you might have guessed, some policies apply to user accounts, and other policies apply to com-
puter accounts.You can only apply policies to user and computer objects, not security groups or
other objects (however, policies can be filtered by security groups by setting the security group
Access Control Entry on the GPO).These two types of policy application work as follows:
■
User policies affect how user accounts interact with the network and are applied when a
user logs on to the network.
■
Computer policies affect how computer objects interact with the network and only apply
to those computers that participate in the Active Directory.

You configure each of these types of policies in separate areas in the GPO Editor.
User and computer policies are divided into three groups: Software Settings, Windows Settings,
and Administrative Templates.
Software Settings
The primary use of this setting is to install, update, or remove software on computers on the net-
work.The Software Installation node is located in this group, and other policy groups can be added
in this area by other applications.
Software policies set in this area under Computer Configuration apply to all users who log on
to the computer where the policy applies.This policy setting could be used to designate a specific
computer on the network where a particular application should be installed, no matter who logs on
to the computer. Software policies set in this area under User Configuration apply to all computers
that a particular user logs on to.This setting is useful if a particular user has a specific application
that he or she needs to use, no matter where that user uses a computer in the organization.The
policies can be set so that if an application is installed on a computer this way, only the user to
whom the policy is applied is able to see or run the application.
Working with Group Policy in an Active Directory Environment • Chapter 17 563
301_BD_W2k3_17.qxd 5/12/04 2:18 PM Page 563
Windows Settings
Policies applying to scripts, security, folder redirection, and Remote Installation Services, among
others, are located in this area.There are significant differences between these policy settings
depending on whether they are applied in the Computer Configuration or User Configuration
node.Table 17.1 details some of the policy groups and whether they are applied to user or com-
puter settings.
Table 17.1 Group Policies for Windows Settings
Policy Location Description
Scripts Computer Configuration Specifies startup and shutdown
scripts to be run on the computer.
Scripts User Configuration Specifies logon and logoff scripts
to be run by users.
Account policies Computer Configuration\ Contains policies related to pass-

Security Settings word and account lockout
settings.
Folder redirection User Configuration\Security Contains policies to redirect certain
Settings user folders, such as Application
Data, My Documents, and Start
Menu, to alternate locations.
Internet Explorer User Configuration\Security Contains settings to modify
maintenance Settings defaults for Internet Explorer, such
as user interface settings, favorites,
connection settings, and security
zone settings.
Public Key policies Computer Configuration\ Contains policies related to
Security Settings system-level public key activities,
such as Encrypted File System,
Enterprise Trust, Autoenrollment
settings, and Automatic Certificate
Request settings.
Public Key policies User Configuration\Security Contains policies related to
Settings user-level public key activities, such
as Enterprise Trust and
Autoenrollment settings.
Administrative Templates
Policy settings that appear in the Administrative Templates node of the GPO Editor contain
Registry settings to achieve each of the settings contained in the hierarchy. Policies for user configu-
ration are placed in the HKEY_CURRENT_USER (HKCU) area of the Registry, while those for
computer configurations are placed in the HKEY_LOCAL_MACHINE (HKLM) area.
564 Chapter 17 • Working with Group Policy in an Active Directory Environment
301_BD_W2k3_17.qxd 5/12/04 2:18 PM Page 564
Administrative templates contain settings for Windows components such as NetMeeting,
Internet Explorer,Terminal Services, Windows Media Player, and Windows update, to name a few.

Other components common to both user and computer configurations include settings for user
profiles, script execution, and group policy.
While the different policy settings between user and computer configurations are too numerous
to list here, there are some key components available for the user configuration.These include the
Start Menu,Taskbar, Desktop, Control Panel, and Shared folder settings.
Group Policy Objects
All group policy information is stored in Active Directory in GPOs.You can apply these objects at
the site, domain, or OU level within the directory. Since the GPO is an object in the directory, you
can set security permissions on the objects to determine who will access the policy settings stored in
the GPO.
Because GPOs can impact a large portion of the directory, you should update GPOs infrequently.
Each GPO update must propagate across the entire directory to take effect, and this could be a time-
consuming process if the directory structure is very large.You should also restrict the number of indi-
viduals who make changes to GPOs that can impact the entire organization. Otherwise, you can run
into the situation where two administrators make contradictory changes to a GPO in different loca-
tions of the tree, and the changes propagate differently around the tree, potentially causing problems
until the directory has completely updated the GPO changes.
Scope and Application Order of Policies
A single object in the network can be subject to multiple policy settings, depending on how Group
Policy is configured on the local machine and in the directory. Active Directory processes policy set-
tings in a specific manner when an object connects to the network. Knowing this process will help
you troubleshoot problems with policy settings as they arise.
Local, Site, Domain, OU
Group Policy settings are applied in the following order:
1. Local settings Each computer has its own local GPO, and these settings are applied
before any others.There is only one local GPO per computer.
2. Site settings Group policies associated with the site in Active Directory are processed
next.The system administrator can set a specific order in which the site policies are to be
applied, if more than one policy is defined.
3. Domain settings Group policies associated with a domain object follow the completion

of the site settings. If multiple domains are involved, the administrator can set the order of
preference in which those settings will be applied.
4. OU settings Group policies associated with an OU are applied last in the processing
order, but the processing starts with the OU highest in the directory structure.The
remaining OU GPOs will be processed in descending order until the OU that contains
the directory object is reached. If multiple policy settings are applied for a particular OU,
the administrator can set the order in which the settings are applied.
Working with Group Policy in an Active Directory Environment • Chapter 17 565
301_BD_W2k3_17.qxd 5/12/04 2:18 PM Page 565