70-640

PRACTICE TO PERFECT MCITP 70-640 TRAINING COURSE

Practice 2 Perfect

MCITP 70-640

Windows

Server 2008

Course


Introduction

This course Practice 2 Perfect MCITP 70-640 Windows Server 2008 is tailored for those

students who are pursuing the MCITP 70-640 certification and they are looking for an easy way

that they can learn and pass their exams.

The objective of this cause is to equip the students within the necessary skills that they can

apply to tackle the questions from this examination. The design of the course takes into

consideration the need to practice and the end of this course are some of the questions that

students can use to practice and understand the core principals and skills that are tested in this

examination.

Use of this Course

This course is designed to help both people who have prior experience working with windows

sever as well as completely new people to windows server. The course is structured in a

manner that everyone can understand and they can build on the knowledge they acquire in the

preceding chapter to solve more complex problems in the next chapter. It is our joy at Practice

2 Perfect to help you pass your exam and impact into you practical skills that you can utilize

working with Windows Server 2008.

Course Illustrations

In our quest to provide you with the most useful information that will assist you pass your

examination, we have designed a number of iconic illustrations that we have used in the entire

course to help you understand the most important aspects of working with windows server

2008. Some of the symbols that we have used in this Course include:

Caution Tip Bonus


Course Outline

PART 1

Configuring Domain Name System (DNS) for Active Directory

Configure zones.

Configure DNS server settings.

Configure zone transfers and replication.

Configuring the Active Directory infrastructure

Configure a forest or a domain.

Configure trusts.

Configure sites.

Configure Active Directory replication.

Configure the global catalog.

Configure operations masters.

Configuring Active Directory Roles and Services

Configure Active Directory Lightweight Directory Service (AD LDS).

Configure the read-only domain controller (RODC).

Configure Active Directory Federation Services (AD FSv2).


PART 2

Creating and maintaining Active Directory objects

Automate creation of Active Directory accounts.

Maintain Active Directory accounts

Configure GPO templates.

Deploy and manage software by using GPOs.

Configure account policies.

Maintaining the Active Directory environment

Configure backup and recovery.

Perform offline maintenance.

Monitor Active Directory.

Configuring Active Directory Certificate Services

Install Active Directory Certificate Services.

Configure CA server settings.

Manage enrollment

Manage certificate revocations.

Examination Questions for Practice

References


Part 1

Configuring Domain Name System (DNS) for Active Directory

Domain Name System (DNS) is one of the most important topics that all

students who are planning to take Microsoft Windows Server 2008

exams should thoroughly understand. There are a number of questions

that you can expect to come from this topic since it is the fundamental

of windows server 2008 networking and administration infrastructure.

Understanding this topic will equip you with skills to tackle 70-640

Microsoft Windows 2008 Exams.

Obviously 17% of the 70-640 Microsoft exams will contain questions

focused on DNS for Active Directory. I often tell students, that it is

important they understand Domain Name System structure for them to

work effectively with the Active directory.

As we go along you will understand the synergetic working relationship

between DNS and active directory. It is important to understand that

functionality of Active directory is dependent on the DNS. In this first

part of this course, you will understand the basic facts about DNS

including; configuration, management and troubleshooting DNS in the

Microsoft Windows server 2008.


What is DNS?

DNS is the abbreviation of Domain Name System a term used to refer

to a Computer and Network naming system that is used in the TCP/IP

(Transmission Control Protocol / Internet Protocol) networks. DNS is a

vital part or function for internet and active directory operations.

Computers in a network can only communicate via IP addresses for

them to locate each other. The IP address essentially contains a bunch

of numbers which are definitely hard for people to memorize.

Example:

The IP address of Google is 74.125.224.72 if you type it in the browser

in the following format http:// 74.125.224.72/ you will be directed to

the Google home page. All websites use the IP address for identification

and communication in the network.

While computers can effectively memorize these numbers, it is virtually

impossible for humans to remember all the IP addresses of the sites

they want to visit.

For this reason the DNS servers the purpose of simplifying the IP

addresses to more easy to remember names like http://google.com

instead of http:// 74.125.224.72/. To understand in depth the

functions and roles of DNS and Active Directory we will cover the

following topics as recommended by Microsoft for the 70-640 exams.


Configuring Zones

DNS Server Settings

Zone Transfers and Replication

Configure Zones

DNS are classified into zones where each zone encompasses the

records for hosts of the corresponding part of DNS namespace.

Namespaces contains a single domain or can have more DNS domains.

In Windows Server 2008 DNS Server service configuration works with a

list of names that is used in the DNS query process. In the process the

query is sent to the server to resolve a name from any zone under the

sever authority. The DNS server checks the query against the available

list of names. To understand in detail how the DNS process occurs refer

to the DNS Detailed Course

Dynamic DNS (DDNS)

Dynamic DNS is an addition to the DNS standard. Dynamic DNS

updates a DNS server with new or changed records for IP addresses

without the need for human intervention. DDNS further allows domain

names that are fully qualified to be associated with dynamic IP address.

Dynamic IP address can change from time to time.

DNS Zones

DNS Server supports three diverse kinds of zones that include:

Primary

Secondary

http://it.practice2perfect.com/mod/page/view.php?id=37


Stub.

Primary and stub DNS zones can be configured as Active Directory-integrated zones if the server is a domain controller in an Active Directory domain. The difference between integrated and non-integrated zones is where zone information is stored. Active Directory-integrated zones are stored within the AD DS. Zones that are not integrated are stored as text files, by default in %windir%\System32\dns.

Configure DNS Server Settings.

Aging and Scavenging

Aging and scavenging can be described using the following terms that have meaning that is related to the function that is being described. These are terms that you should familiarize yourself for you to understand how the mechanism of Aging and scavenging.

The aging and scavenging concepts introduce some terms that you may not be familiar with:

No-refresh interval: The period of time between the last refresh and the moment when the timestamp can be refreshed again.

Refresh interval: The period of time from when a record is refreshed to when it can be scavenged. This must be greater than the maximum refresh period.

Scavenging period: The period of time between scavenging operations.

Record refresh: This occurs when a dynamic update is processed and the only change made to the record is to update its time stamp. This happens when a computer restarts, every 24 hours


when the computer attempts to update its record, and when other network services attempt a fresh.

Record update: This occurs when a dynamic update is processed and other characteristics are modified in addition to its time stamp.

Scavenging servers: It’s possible to restrict scavenging to a specific list of DNS servers, identified by their IP address.

Aging and scavenging can be described as features that are available for DNS and are only useful when you are deploying your server with primary zones. DNS console can alternatively be used to perform similar tasks for the DNS server and other directory integrated zones. There are a number of things that can be done with the scavenging and the configuration settings can be set as follows;

1. Enable or disable the use of scavenging at a DNS server.

2. Enable or disable the use of scavenging for selected zones at the DNS server.

3. Modify the no-refresh interval, either as a server default or by specifying an overriding value at selected zones.

4. Modify the refresh interval, either as a server default or by specifying an overriding value at selected zones.

5. Specify whether periodic scavenging occurs automatically at the DNS server for any of its eligible zones, and how often these operations are repeated.

6. Manually initiate a single scavenging operation for all eligible zones at the DNS server.


7. View other related properties, such as the time stamp for individual resource records or the start scavenging time for a specified zone.

Normally only dynamically updated records are configured to be scavenged because in most cases when you configure a static record it’s for a server that is going to be sharing resources for a relatively long time. By default static records are given a time stamp of zero which exempts them from aging and scavenging. You can change this by modifying the records individually to permit them to use a current time stamp instead.

To configure aging and scavenging for a zone in DNS Manager:

1. Right-click on the zone and select Properties. 2. Click Aging on the General tab of the dialog box. 3. Select the Scavenge stale resource records check box. 4. Modify the other properties as appropriate.

To configure aging and scavenging for a zone from a command prompt enter the following command:

dnscmd <ServerName> /Config <ZoneName> {/Aging <Value>|/RefreshInterval <Value>|/NoRefreshInterval <Value>}

External trusts: These one-way trusts are individual trust relationships set up between two domains in different forests, as can be done in Windows 2000. The forests involved may be operating at any forest functional level. You can use this type of trust if you need to enable resource sharing only between specific domains in different forests. You can also use this type of trust


relationship between an Active Directory domain and a Windows NT 4.0 domain.

Forest trusts: As already mentioned, these trusts include complete trust relationships between all domains in the relevant forests, thereby enabling resource sharing among all domains in the forests. The trust relationship can be either one-way or two-way. Both forests must be operating at the Windows Server 2003 forest functional level. The use of forest trusts offers several benefits:

o They simplify resource management between forests by reducing the number of external trusts needed for resource sharing.

o They provide a wider scope of UPN authentications, which can be used across the trusting forests.

o They provide increased administrative flexibility by enabling administrators to split collaborative delegation efforts with administrators in other forests.

o Directory replication is isolated within each forest. Forest-wide configuration modifications such as adding new domains or modifying the schema affect only the forest to which they apply, and not trusting forests.

o They provide greater trustworthiness of authorization data. Administrators can use both the Kerberos and NTLM authentication protocols when authorization data is transferred between forests.

Realm trusts: These are one-way non transitive trusts that you can set up between an Active Directory domain and a Kerberos V5 realm such as found in Unix and MIT implementations.


Configure Zone Transfers and Replication.

Configuring Zone Transfers and Replication

Zone transfers were once the most common way to replicate DNS database updates between

servers, in recent years other replication mechanisms have become increasingly popular. There

are two types of zone transfers: full and incremental. The DNS Server service in Windows Server

2008 supports zone transfers as well as AD DS replication. This section explorers each of these

features.

Configuring Zone Transfers

A full zone transfer is fairly simple, the client, also called the “secondary” or “slave” server

requests a copy of the zone from the server, also called the “primary” or “master.” The transfer

initiates with the SOA resource record. Since the serial number of the SOA RR is incremented

each time there is a change to the zone the client can compare the serial number for the

current version of the SOA with its own copy, if they are identical then the client concludes that

there haven’t been any changes to the zone and the transfer is terminated. If the serial

numbers differ the client requests all of the remaining records for the zone. An incremental

zone transfer differs in that the client sends its own copy of the SOA RR to the server, the server

then compares the serial number with that of its own copy and only sends changes that have

occurred since that version of the SOA RR.

Active Directory-integrated zones rely on AD DS for replication between domain controllers;

whenever feasible it’s the preferred method. However, when file-based zone transfers are used

incremental zone transfers consume less network bandwidth than full transfers and therefore

they are the next best choice. For this reason the DNS Server service in Windows Server 2008

requests incremental zone transfers when retrieving a zone from a primary server. To configure

zone transfers using DNS Manager do the following:

1. Right-click on the desired zone, and then select Properties.

2. Click the Zone Transfers tab.

3. Enable or disable the Allow zone transfers check box.

4. If you have enabled transfers select the appropriate radio button: To any server, Only to the

servers listed on the Name Servers tab, or Only to the following servers; as shown in figure 7.

5. If the last button is selected click Edit and enter the IP addresses for each desired DNS server, as

shown in figure 8.


Configuring the Active Directory infrastructure

Configure a Forest or a Domain.

Managing Forests and Domains

Domains are the basic building blocks of AD DS. At the risk of confusing you, AD

DS domains are discrete from and yet related to Domain Name Services (DNS)

domains. They are distinct in that they perform many functions that are entirely

separate from DNS domains such as user authentication and group policy. AD DS

evolved from LAN Manager and Windows NT domains where the term was used

with no correlation to DNS domains. They are related to DNS in that AD DS

integrates with DNS for name resolution. Although it is possible to create an AD

DS design that does not resemble the DNS namespace I recommend against doing

so to avoid confusing users.

In AD DS a domain is a logical group of computers that share a directory database.

A tree is one or more AD DS domains that have trust relationships with one

another. Forests are one or more trees grouped together. Organizations can use

domains, trees, and forests to organize their directory services according to the

design of their business units, or their geographic distribution, or whatever

combination works best for their situation. Figure 1 presents a notional

architecture, the rectangles represent the two forests, and ovals represent the

domains. In this example kurtdillard.com is the root domain for the entire

organization, within the same tree are two additional layers of domains,

americas.kurtdillard.com is the second layer, the other three form the third. All of

the domains in the kurtdillard.com forest are located in the same tree. The other

tree, europe.kurtdillard.com, consists of only two layers. This logical architecture

also reflects the DNS namespace for the organization.


Production architecture could be as complex as the example, or even more

complex, or it could be a simple as a single domain within a single forest. What is

suitable will vary from one organization to another, however designing an

optimum domain and forest structure is beyond the scope of this book, review

the references section at the end of the chapter. for resources on exploring this

topic. Each domain has at least one domain controller (DC) that hosts the AD DS

database, best practices dictate that each domain have at least two DCs to

provide redundancy in case one of them fails. There are several additional roles

assigned to DCs, these are discussed later in this chapter. The objects and

containers within an AD DS database are discussed in Creating and Maintaining

Active Directory Objects.

Configuring a forest root domain on Windows Server 2008 R2

This scenario is suitable mostly for test environments because it is very rarely that

someone wants to do that in production (because it already exists). But of course,

maybe you start creating domain environment for new company which doesn’t

have it. Then this article is also for you.

This article describes only single forest, single domain scenario.

We need some details before we will start configuration.

Company name - which will be helpful in choosing forest/domain name

Network configuration - valid IP addresses range for our company, router’s

IP (as default gateway)

ISP DNS servers on any public DNS servers - to be able to access the

Internet resources from our company

Services we need to run - what additional services will be required to fulfill

a company requirements

Let’s start to prepare them all.

Company name – Test Environment


Network configuration – IP addresses range 192.168.1.0/24; the last

available IP address is a router (default gateway)

Public DNS servers – 8.8.4.4 and 8.8.8.8 (Google public DNS servers)

Services – Active Directory: Directory Services, DNS server(s), DHCP

server(s)

Now, we can install our first Windows Server 2008 R2 and configure it. After that

we will be able to promote this box as a Domain Controller.

When our server is installed, then we need to log on there on local administrator

account and we can start its preparation.

Open Network Card configuration and set up static IP address for your server (in

this case it’s 192.168.1.1 with 255.255.255.0 network mask)

This is very important part of network configuration before promoting server as a

Domain Controller. In DNS preferred IP address type 127.0.0.1 (loopback

interface) or the same IP address as server is configured 192.168.1.1 to point the

server to DNS itself.

Network card configuration

Accept configuration and start promoting server by typing in run box dcpromo

Running DC promotion

You should see Active Directory Domain Services Installation wizard. Select “Use

advanced mode installation” checkbox and follow with its instructions.

Active Directory Installation wizard

This warning is not so important for us, because we have no older operating systems as Domain

Controllers within network. It’s about security incompatibility between NT4 and 2008/2008R2,

so let’s skip this screen.


OS security incompatibility warning

At this point, we have to choose what we want to do with domain configuration. As this article

is about forest root domain, we don’t have to consider another option, now. We are creating

completely new domain in a new forest.

A forest root domain creation

You will see a window with question about forest root domain name. It’s good to set up name

related with your company. This is so called FQDN (Fully Qualified Domain Name or also known

as DNS Domain Name). Create internal domain name to separate it from your external (if it

would be necessary, i.e. for e-mail) with .local or .private suffix. These suffixes suggest that DNS

domain is for local resources and this is also connected with your local DNS zone name.

DNS domain name

now, specify NetBIOS domain name

NetBIOS domain name

Now, you need to choose Forest Functional Level

Setting up FFL will also configure Domain Functional Level in the same mode.

This is very important step in forest/domain configuration. This setting determines which

operating systems can be promoted to Domain Controllers. As we are configuring the only

single forest/domain environment it is not so difficult.

Domain Functional Level determines which operating systems can act as Domain Controllers

within that particular domain. By default (in new forest/domain configuration) it suggests

Windows Server 2003 which means that older OSes cannot be promoted as DCs. So, NT4 and

Windows 2000 Server cannot be used in a network with AD:DS role. They still can be a domain

member servers but not Domain Controllers.


When you change DFL to Windows Server 2008 then only Windows Server 2008 and 2008 R2

can be promoted to be DCs. And the last choice is Windows Server 2008 R2 – the only possible

operating system for Domain Controllers is Windows Server 2008 R2.

Each domain can be set up on a different Domain Functional Levels. But they have to fulfill

Forest Functional Level to be able to operate within a forest.

If you have more than one domain in a forest then you have to evaluate which one work in the

lowest mode. The lowest Domain Functional Level in a forest determines the highest Forest

Functional Level.

Forest Functional Level determines that all Domain Controllers in each domain cannot work on

older operating system than it’s specified in FFL.

If your FFL is set up to Windows Server 2003 that means, all of Domain Controllers in a forest

are based on at least Windows Server 2003.

It’s similar to other modes (2008/2008 R2)

Important! When you set up Domain/Forest Functional level it cannot be changed to lower

mode, so be careful when you choose them. If you are not sure which functional level is

adequate for you, choose the lower one. You can always raise it without any business

continuity disruption later.

As we don’t want to use older OSes as DCs, we plan to use only Windows Server 2008 R2, we

can change Forest Functional Level to Windows Server 2008 R2. Domain Functional Level will

be set up on the same level automatically.

Forest Functional Level

This is our first domain and first Domain Controller, so we need to also set up new internal DNS

server to be able to use Active Directory. Whole Active Directory services rely on DNS services,

so they have to be always available.

Additional roles for DC


We are configuring our first DNS server, so it doesn’t exist right now, don’t worry and continue

DNS warning

Specify Active Directory database, logs location (you can leave defaults, those files are not so

huge and if server act as AD,DNS only, that’s enough space)

Active Directory files location

Set up password for Directory Services Restoration Mode which will be used in case of non-

authoritative/authoritative restore or other AD database maintenance. This password should

be different than Domain Administrator password and should be also changed regularly.

DSRM password

On the summary screen, you can review chosen settings and start server promotion process

Summary screen

After all, server reboot it’s required. You can do it manually, or select “Reboot on completion”

checkbox and wait until promotion will be done

Active Directory:Directory Services installation

Congratulations! Your Domain Controller for a forest root domain is ready! You can log on, on

it, using password specified during promotion process (the same password as Directory Services

Restoration Mode)

A forest root Domain Controller


Log on, using domain administrator credentials into your new Domain Controller. We have to

configure DNS server to send unresolved DNS queries to ISP DNS server(s) or any other public

DNS server(s). This configuration is necessary to be able to access the Internet resources from

our internal network.

Open DNS management console from Administrative Tools and select server name. In the right

pane at the bottom of that window, double click on Forwarders

Configuring forwaders on DNS server

You should see a window, where you can put ISP or public DNS servers. Click on “Edit” button

to add those servers IP address

Configuring forwarders on DNS server

Enter IP addresses of external DNS servers and wait for their validation. If everything is ok, you

would see green shield next to IP addresses.

Configuring forwarders on DNS server

Close DNS management console.

After all, you should consider Domain Controller and DNS server redundancy in your network by

placing additional server with these roles. Another very important part is performing System

State backup of Domain Controllers regularly.

In case of lack hardware resources in your network, you can consider placing DHCP server on

this Domain Controller. However, it’s not recommended to install additional roles on DCs

because of security reasons.


Configure Trusts.

How to configure a DNS forwarder

DNS forwarders are necessary to get forest level trust relationships working

properly. Users can forward DNS between the two forests in the trust relationship

in order to speed up lookups between the organizations and to allow them to act

as one. This way, any domain on one side of the trust may access any resource on

the other. A DNS forwarder is a server that receives requests for lookup from

another server. For example, your company’s DNS server may have no idea who

www.google.com actually is because it is not on your network. The request is sent

to a forwarder on the Internet to resolve the name.

Follow these steps to configure a DNS forwarder:

1. Open the DNS snap-in on the DNS server for your forest (go to Start |

Administrative Tools | DNS). In this example, let’s call the DNS server at the

fictitious company Spacely Sprockets.

2. In the console tree pane, open the Properties sheet for the DNS server you

want to configure by right-clicking the server name and selecting

Properties.

3. Click the Forwarders tab.

4. Specify the domain names that require queries to be forwarded by clicking

the New button and entering the DNS name for the domain. In this case,

enter the domain for the fictitious partner company Cogswell Cogs.

5. Enter the IP address(es) of the DNS server(s) you wish to forward requests

to.

6. Click Add.

7. Click OK to close the Forwarders tab.

You will need to configure both root DNS servers to forward requests for the

domain on the other end of the trust. For example, the Spacely Sprockets DNS


server would forward requests for all things Cogswell Cogs, and the DNS server at

Cogswell Cogs would do the same for resources at Spacely Sprockets.

Now that the DNS configuration is complete, all you need to do is create the forest trust between Spacely Sprockets and Cogswell Cogs. Next week, I’ll take a look at the steps needed to get this relationship off the ground.


Configure Sites.

You know what the term replica means, right? A replica is an exact duplicate of

some other object. Similarly, in Active Directory, our domain controllers replicate

changes to the AD database in order to ensure that all domain controllers contain

consistent (exact) data.

Whereas objects like the forest, domain, and organizational unit are logical

objects that can be organized in several different ways, the Active Directory site,

subnet, and site link objects are intended to reflect the physical infrastructure of

your organization.

In a nutshell, domain controllers that exist in the same AD site will replicate

to/from each other almost immediately (in 15-second intervals, to be exact). By

contrast, domain controllers located in separate sites are connected by a site link

object that the domain administrator can control to determine replication

frequency. After all, the network link between sites is generally presumed to be

much slower and potentially more unreliable than the high-speed LAN links that

connect DCs within one site.

We implement our Active Directory site topology by using the Active Directory

Sites and Services MMC console. We can do the same thing as well by using

Windows PowerShell 2.0.

http://blogs.technet.com/b/tommos/archive/2011/10/24/managing-active-directory-via-powershell-sites.aspx


Active Directory Sites and Services console

Before you register to take the 70-640 exam, please ensure that you are very

comfortable with all technologies and procedures that are referenced in this

subobjective:

Creating Active Directory Subnets

Configuring Site Links

Configuring Site Link Costing

Configuring Sites Infrastructure

Creating Active Directory subnets

A subnet is an Active Directory object that denotes an area of high-speed network

connectivity. I personally consider “high-speed connectivity” to denote LAN

speeds of between 10Mbps and 1Gbps; however, the Microsoft literature gives

what are to me absurdly low thresholds for subnets.

http://4sysops.com/wp-content/uploads/2012/02/Active-Directory-Sites-and-Services-console.png


A subnet object

Because intrasite replication happens immediately (more or less), we define site

objects in Active Directory that reflect the physical network topology within each

site location. When we define a site, we specify the CIDR notation of the subnet

(192.168.1.0/24 to denote a network ID of 192.168.1.0 and a 24-bit subnet mask),

and the site object to which the subnet is associated.

NOTE: Windows Server 2008 R2 supports both IPv4 and IPv6 for subnet objects.

http://4sysops.com/wp-content/uploads/2012/02/A-subnet-object.png


Configuring Site links

Site links are manually created by domain administrators to, well, link site objects.

The cool thing about site links is their ability to be scheduled and configured with

a costing metric.

Active Directory Site link

Remember that because we presume that the physical network infrastructure

links between physical sites are slower than LAN speed, we can set up a

replication schedule on a site link in order to fully control how often Active

Directory takes place.

By default, site link bridging is enabled on Active Directory site links. What this

means in a nutshell is that site links are transitive in the same way that Active

Directory trust relationships are transitive.

http://4sysops.com/wp-content/uploads/2012/02/Active-Directory-Site-link.png


Configuring Site link costing

Active Directory site links use a relative costing metric; lower cost values denote

preferred replication paths. Consider the following diagram: in this topology, we

can force Active Replication between site 3 and site 2 to occur by way of site 1

due to our configured costs. We could in this case use the site 3 > site 2 link as a

backup for the purpose of redundancy.

Site link costing

Configuring Sites infrastructure

All right—now let’s tie everything together. We now know that we want all of our

domain controllers replicating changes to the AD database in a time-efficient

manner. Most administrators define site objects to reflect each physical campus

in their organization.

http://4sysops.com/wp-content/uploads/2012/02/Site-link-costing.png


Within each site we have one or more subnet objects that denote the areas of

high-speed connectivity within each campus.

Finally, we build site link objects to tie together our sites and manually specify

replication paths and frequency.


Configure Active Directory Replication.

Active Directory is made up of one or more directory partitions, or naming

contexts. A directory partition is a contiguous subtree of Active Directory that

forms a unit of replication between domain controllers.

In Active Directory a single server always holds at least three directory partitions:

The schema

The configuration (replication topology and related metadata)

One or more per-domain directory partitions (subtrees containing domain-

specific objects in the directory)

For example, domain controller "DC1" from domain "ntdev.microsoft.com" has

the following directory partitions (assuming a "microsoft.com" domain exists as

the root domain and DC1 is not a Global Catalog server):

Schema (CN=Schema,CN=Configuration,DC=microsoft,DC=com)

Configuration (CN=Configuration,DC=microsoft,DC=com)

Domain NTDEV (DC=ntdev,DC=microsoft,DC=com)

Domain controller "DC2" from domain "support.microsoft.com" has the following

directory partitions (assume DC2 is not a Global Catalog server):

Schema (CN=Schema,CN=Configuration,DC=microsoft,DC=com)

Configuration (CN=Configuration,DC=microsoft,DC=com)

Domain SUPPORT (DC=support,DC=microsoft,DC=com)

The schema and configuration are replicated to every domain controller in a given

forest. The per-domain directory partition is replicated only to domain controllers

for that domain, except when the target server is a Global Catalog server. In this

example, DC1 and DC2 replicate the Schema and Configuration directory

partitions with each other, but do not replicate the per-domain directory


partitions because they are from different domains. Domain controllers from the

same domain replicate all three directory partitions with each other.

For each of the methods below, the "source" server describes the domain

controller that replicates the changes to a replication partner. The "target"

domain controller receives the changes.

Initiating Replication Using the Sites and Services Manager Snap-in

1. Click Start, point to Programs, point to Administrative Tools, and then click

Active Directory Sites and Services.

2. Expand the Sites container in the left pane. Expand the container that

represents the name of the site containing the target server that needs to

be synchronized with its replication partners.

3. Expand the Servers container, and then expand the target server to display

the NTDS Settings object (an object that represents settings for the domain

controller).

4. Click the NTDS Settings object. The connection objects in the right pane

represent the target server's direct replication partners.

5. Right-click a connection object in the right pane, and then click Replicate

Now. Windows 2000 initiates replication of any changes from the source

server (the server represented by the connection object) to the target

server for all directory partitions the target server is configured to replicate

from the source server.

Initiating replication Using Repadmin.exe

Repadmin.exe is a command-line tool from the Windows 2000 Resource Kit that is

included in the Support Tools folder on the Windows 2000 CD-ROM.

1. Determine the name of the target server that needs to be synchronized.

2. At a command prompt, use Repadmin.exe to determine the target server's

direct replication partners by typing the following command:


repadmin /showreps target_server_name

If the target server can be reached, it displays output similar to the

following sample. In this example, DC1 and DC2 are now in the same

domain, "support.microsoft.com."

Redmond\DC1

DSA Options : (none)

objectGuid : 4a11d649-f9ab-11d2-b17f-00c04f5cb503

invocationID: 45d18b0b-f9ab-11d2-98b8-0000f87a546b

==== INBOUND NEIGHBORS ======================================

CN=Schema,CN=Configuration,DC=microsoft,DC=com

Redmond\DC2 via RPC

objectGuid: d2e3badd-e07a-11d2-b573-0000f87a546b

Last attempt @ 1999-05-03 18:07.04 was successful.

CN=Configuration,DC=microsoft,DC=com

Redmond\DC2 via RPC



DC=support,DC=microsoft,DC=com

Redmond\DC2 via RPC



(Other data excluded because it does not pertain to this article.)


Under the Inbound Neighbors section of the output, the direct replication

partners for each directory partition are identified along with the status of

the last replication.

3. Find the directory partition that needs synchronization and locate the

source server with which the target will be synchronized. Note the

objectGuid of the source server.

4. Use Repadmin.exe to initiate replication by typing the following command:

repadmin /sync directory_partition target_server_name

source_server_objectGuid

For example, to initiate replication on DC1 so that changes are replicated

from DC2:

repadmin /sync dc=support,dc=microsoft,dc=com DC1 d2e3badd-e07a-

11d2-b573-0000f87a546b

If successful, Repadmin.exe displays the following message:

ReplicaSync() from source: d2e3badd-e07a-11d2-b573-0000f87a546b, to

dest: DC1 is successful.

Optionally, you can use the following switches on the command line:

/force: Overrides the normal replication schedule.

/async: Starts the replication event. Repadmin.exe does not wait for the

replication event to finish.

/full: Forces a full replication of all objects from the destination DSA.

Initiating Replication in a Visual Basic Script Using IADsTools

On the Windows 2000-based computer that will execute the script, install the

Windows 2000 Support Tools Resource Kit, which includes Active Directory

Replication Monitor and IADsTools (a COM object that can be used for many


functions, including the one described here to synchronize replication partners).

Detailed information about the function parameters is located in the Windows

2000 Resource Kit documentation.

The ReplicaSync function can be used to synchronize a target domain controller

with a source for a given directory partition. The syntax for the ReplicaSync

function is as follows

ReplicaSync

(target_server,directory_partition,source_server,use_flags,use_credentials)

Where:

target_server is the domain controller receiving the changes, being

synchronized with the source_server.

directory_partition is the partition to be replicated.

source_server is the domain controller that will replicate the changes to the

target server.

use_flags does not have to be specified, but if set to 1, the function looks at

the flags specified by SetReplicaSyncFlags (see the Windows 2000 Resource

Kit documentation for more information) to determine which options to set

in the request. To specify no flags, use a value of 0 (zero).

use_credentials does not have to be used by default if the logged on user

has administrative credentials. If this parameter is specified and the value is

1, the function look sat the credentials defined by the SetUserCredentials

function (explained below) and passes those with the request. If this

parameter is specified, use_flags must also be specified.

This function returns 0 for success or 1 for failure.

For example, if the logged on user has administrative credentials on DC1, the

following script can be run to synchronize DC1 with any changes that have

occurred on DC2 for the directory partition "DC=support,DC=microsoft,DC=com":


Set comDLL=CreateObject("IADsTools.DCFunctions")

Result=comDLL.ReplicaSync("DC1","dc=support,DC=microsoft,dc=com","DC2")

If result=0 then MsgBox "Completed successfully." else MsgBox "Failed"

If alternate credentials need to be specified, the SetUserCredentials function can

be used to specify them in addition to specifying a value of "1" for the last

parameter to the ReplicaSync function. The SetUserCredentials function has the

following syntax

SetUserCredentials (user_name,domain_name,user_LDAP_dn,password)

Where:

user_name is the down-level user name of an account in the domain.

domain_name is the NetBIOS domain name of the user account.

user_LDAP_dn is not required for the ReplicaSync function but can be

specified. This is the Distinguished Name of the user account specified.

password is the password for the user.

For example, after modifying the above script, it would be like the following

sample:

Set comDLL=Createobject("IADsTools.DCFunctions")

comDLL.SetUserCredentials "johndoe","support","","password"

Result=comDLL.ReplicaSync("DC1","dc=support,microsoft,dc=com","DC2",0,1)


In VBScript, all variables are defined as type VARIANT. To pass variables to any

function in the IADsTools object, those variables must be explicitly typed. For

example:

Set comDLL=Createobject("IADsTools.DCFunctions")

comDLL.SetUserCredentials CStr(strUserName), CStr(strDomainName),

CStr(strPassword)

Result=comDLL.ReplicaSync(Cstr(strTargetServer), CStr(strDomainPartition),


CStr(strSourceServer), CInt(iFlags), CInt(iUseCreds))


To view a language and run-time reference for VBScript, visit the following

Initiating Replication Using Active Directory Replication Monitor

1. On the Windows 2000-based computer that will run the script, install the

Windows 2000 Support Tools Resource Kit, which includes Active Directory

Replication Monitor (Replmon.exe).

2. Start Active Directory Replication Monitor and click Add Site/Server on the

Edit menu. Use the "Add Site or Server" Wizard to add the target server to

the view.

3. Replmon.exe identifies the directory partitions and displays them as child

nodes to the target server in the left pane.

4. Find and expand the directory partition that needs to be synchronized. All

domain controllers listed for a given directory partition are source servers,

but direct replication partners are displayed with an icon that represents

two network-connected servers. Direct replication partners can also be

identified by right-clicking a server and clicking Properties. The Properties

dialog box displays the source server as a Direct Replication Partner, a

Transitive Replication Partner, or a BridgeHead Connection (also a direct

replication connection).

5. Right-click the direct replication partner, and then click Synchronize

Replica. Replmon.exe initiates replication and reports the success or failure

of the request.


Configure the Global Catalog.

Configuring a Global Catalog Server

When conditions in a site warrant adding a global catalog server, you can

configure a domain controller to be a global catalog server. Selecting the global

catalog setting on the NTDS Settings object prompts the KCC to update the

topology. After the topology is updated, then read-only partial domain directory

partitions are replicated to the designated domain controller. When replication

must occur between sites to create the global catalog, the site link schedule

determines when replication can occur.

Task Requirements

The following tools are required to perform the procedures for this task:

Active Directory Sites and Services

Repadmin.exe

Dcdiag.exe

To complete this task, perform the following procedures:

1. Determine whether a domain controller is a global catalog server

2. Designate a domain controller to be a global catalog server

3. Monitor global catalog replication progress

4. Verify successful replication to a domain controller

Whenever an AD user runs a search against the directory (to look for a shared

printer or folder, perhaps), this involves a Global Catalog query. Some enterprise


applications, such as Microsoft Exchange Server, also rely upon the Global Catalog

for AD name resolution.

Consider the following scenario: A user named Pat from the domain

core.corp.com needs to access resources to which he has permissions in the

dev.corp.com domain. Let’s go further and say that Pat attempts to authenticate

to the dev.corp.com domain by specifying his/her user principal name (UPN) of

[email protected].

In the absence of a Global Catalog, the domain controllers in dev.corp.com have

absolutely no knowledge of who pat is, and thus authentication fails.

The bottom line, friends, is that domain controllers within a single domain contain

a full, read/write copy of their own domain directory partition. The domain

partition contains all of the “good stuff” in Active Directory such as user names,

group names, group memberships, and shared resources.

In a multidomain environment, domain controllers still have a copy of only their

own domain directory partition. However, a domain controller that is also a

Global Catalog will contain a read/only copy of every other domain’s domain

directory partition. Thus, the Global Catalog can resolve Active Directory name

references across the entire multi-domain forest—isn’t that great?

To return to the previous scenario, when our user Pat submits his/her

[email protected] UPN to a domain controller in dev.corp.com, that request

results in a query to the GC in that domain. Because the Global Catalog contains

directory information from core.corp.com, the user is identified and the

authentication process succeeds.

Before you even think about registering to take the 70-640 exam, please ensure

that you are very comfortable with all of technologies and procedures that are

referenced in this subobjective:

Universal Group Membership Caching (UGMC)


Partial Attribute Sets

Promotion to Global Catalog

Universal Group Membership Caching (UGMC)

As I mentioned, the three primary benefits of the Global Catalog are:

Directory information lookup

User principal name authentication

Intra-forest object validation

The notion of the universal group touches upon all three of these points. First of

all, recall that the universal group’s scope is forest-wide and therefore universal

groups are relevant only in multi-domain forests.

Second, we should know that the membership of universal groups for users

throughout the entire forest is propagated to the Global Catalog. This means that

domain logons will fail if a Global Catalog cannot be contacted. After all, we can’t

very well authenticate a an Active Directory user without knowing which, if any,

universal groups the user belongs to, right?

The potential problem with this Global Catalog presence requirement is that your

environment’s Active Directory site topology might be such that a site does not

have a local Global Catalog server and that the nearest one is located on the other

side of a slow and/or expensive WAN link. What are we going do in this case?

Enter Universal Group Membership Caching (UGMC) as a solution. UGMC does

nothing else but force the storage of each user’s universal group membership(s)

to a local domain controller during that user’s first logon. After the initial lookup

to the remote Global Catalog server, subsequent logons won’t require that

communication with the GC except during refresh intervals.

We enable UGMC in a site by modifying the properties of a site’s NTDS Site

Settings object in the Active Directory Sites and Services MMC console. Note that


we can specify the nearest site as a source of refresh data by making a selection

from the Refresh cache from drop-down list box.

Enabling UGMC on an Active Directory site

Partial Attribute Set (PAS)

Do you remember when I said earlier in this article that Global Catalog servers are

domain controllers that possess not only a full, read/write copy of their own

http://4sysops.com/wp-content/uploads/2012/03/Enabling-UGMC-on-an-Active-Directory-site.png


domain’s domain directory partitions, but also a read/only copy of the domain

directory partition from all other domains in the forest? Well, a GC would be

pretty darned overburdened if it had to track every single schema attribute for

every object in every domain.

To solve this issue, a Global Catalog tracks a partial attribute set (PAS) of each

domain’s domain directory partition. In other words, while GCs do contain a

reference to every single AD object in every domain, they store only selected

schema attributes that Microsoft feels are most commonly searched for by users

and applications.

The good news is that forest administrators can include additional schema

attributes for use in the Global Catalog. For instance, your organization might

have a line-of-business (LOB) application that extended the AD schema with new

attributes. The forest admin would need to manually add the relevant new

schema attributes to the Global Catalog to make the attributes available forest-

wide.

One way to add schema attributes to the Global Catalog is to open the Active

Directory Schema console and enable the Replicate this attribute to the Global

Catalog option for the attribute in question. This is shown in the following figure.


Adding a schema attribute to Global Catalog

Promotion to Global Catalog

So the question arises as to exactly how we specify a Global Catalog. By default,

the first domain controller in a forest is designated as a Global Catalog. Thereafter

a forest administrator can nominate additional Global Catalogs by using the

Active Directory Sites and Services console and modifying the properties of the

NTDS Settings object for a particular domain controller. This is shown in the

following exhibit.

http://4sysops.com/wp-content/uploads/2012/03/Adding-a-schema-attribute-to-Global-Catalog.png


Designating a Global Catalog

You might be thinking, “Why would I have a need for Global Catalog server if my

forest includes only one domain?” This is a good point. Actually, Microsoft

recommends that you make EVERY domain controller in a single-domain forest a

Global Catalog. The justification for this is that within a domain, every domain

controller possesses all knowledge of Active Directory anyway. Therefore, why

not grant all DCs the ability to resolve AD name lookups?

http://4sysops.com/wp-content/uploads/2012/03/Designating-a-Global-Catalog.png


Configure Operations Masters.

You must configure the forest-level and domain-level operations master (also

known as flexible single master operations or FSMO) roles for the forest root

domain. By default, Active Directory Domain Services (AD DS) assigns all

operations master roles to the first domain controller in the forest root domain:

If your design specifies that all domain controllers in the forest root domain

are global catalog servers, leave all five operations master roles on the first

domain controller and designate the second domain controller to be the

standby operations master.

If your design specifies a child domain, transfer the infrastructure master

role to a domain controller that is not a global catalog.

If your Active Directory Domain Services (AD DS) design specifies that you

designate a standby operations master for the current operations master role

holder, configure the current role holder and the standby as direct replication

partners by manually creating a connection object between them. Designating a

standby operations master can save some time if you must reassign operations

master roles to the standby operations master.

Of all the operations master roles, the primary domain controller (PDC) emulator

operations master role has the highest impact on the performance of the domain

controller that hosts that role. In domains with more than 10,000 users, it might

be necessary to reduce the number of authentication requests that are

performed by the PDC emulator to decrease its workload and allow it to perform

other tasks. If CPU utilization is higher than 50 percent or disk queues remain

higher than 2 for several hours or days, reduce the number of client

authentication requests that the PDC emulator receives.

To reduce the number of client authentication requests that the PDC emulator

processes, adjust its weight or its priority in the Domain Name System (DNS)


environment. If you want to proportionately reduce the number of client

authentication requests that the PDC emulator receives, adjust its weight. If you

want to ensure that the PDC emulator does not receive any client authentication

requests, adjust its priority.

AD DS assigns a default value of 100 for the weight. By creating a new registry

entry for the weight and assigning it a decreased value of 50, you can

proportionately reduce the number of client authentication requests that AD DS

sends to the PDC emulator. This ensures that the PDC emulator authenticates half

the number of clients that it would if the weight value remained at 100.

AD DS assigns a default value of zero for the priority. By creating a new registry

entry for the priority, and then assigning it an increased value of 200, you can

ensure that the PDC emulator never receives client authentication requests unless

it is the only accessible domain controller.

Repeat these procedures if you transfer or seize the PDC emulator operations

master role is to another domain controller in the forest root domain.

Caution

Because Registry Editor bypasses standard safeguards, you can configure settings

that can damage your system or require you to reinstall the Windows operating

system. If you must edit the registry, back it up first. For more information, see

the Windows Server 2003 Resource Kit Registry Reference

(http://go.microsoft.com/fwlink/?LinkId=101705).

Membership in the Enterprise Admins group or the Domain Admins group is the

minimum required to complete this procedure. Review details about using the

appropriate accounts and group memberships at Local and Domain Default

Groups (http://go.microsoft.com/fwlink/?LinkId=83477).

http://go.microsoft.com/fwlink/?LinkId=101705




To change the weight for DNS SRV records by using Registry Editor

1. In the Run dialog box, type regedit, and then press ENTER.

2. In Registry Editor, navigate to

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\P

arameters.

3. Click Edit, click New, and then click DWORD value.

4. For the new entry name, type LdapSrvWeight, and press ENTER.

The value name is not case sensitive.

5. Double-click the entry name that you just typed to open the Edit DWORD

Value dialog box.

6. Choose Decimal as the Base option.

7. Enter a value from 0 through 65535, and then click OK.

The recommended value is 50.

8. Click File, and then click Exit to close Registry Editor.

Adjusting the priority of the domain controller reduces the number of client

referrals. However, rather than reducing that number proportionally to the other

domain controllers, changing the priority causes DNS to stop referring all clients

to this domain controller unless all domain controllers with a lower priority

setting are unavailable.

Membership in Enterprise Admins group or the Domain Admins group is the

minimum required to complete this procedure. Review details about using the

appropriate accounts and group memberships at Local and Domain Default

Groups (http://go.microsoft.com/fwlink/?LinkId=83477).

To change the priority for DNS SRV records by using the registry

1. In the Run dialog box, type regedit, and then press ENTER.




2. In Registry Editor, navigate to

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\P

arameters

3. Click Edit, click New, and then click DWORD value.

4. For the new entry name, type LdapSrvPriority, and then press ENTER.

5. Double-click the entry name that you just typed to open the Edit DWORD

Value dialog box.

6. Choose Decimal as the Base option.

7. Enter a value from 0 through 65535, and then click OK.

The recommended value is 200.

8. Click File, and then click Exit to close Registry Editor

Configuring Active Directory Roles and Services

Configure Active Directory Lightweight Directory Service (AD LDS).

The Active Directory® Lightweight Directory Services (AD LDS) server role is a

Lightweight Directory Access Protocol (LDAP) directory service. It provides data

storage and retrieval for directory-enabled applications, without the

dependencies that are required for Active Directory Domain Services (AD DS).

AD LDS in the Windows Server® 2008 operating system encompasses the

functionality that was provided by Active Directory Application Mode (ADAM),

which is available for Windows® XP Professional and the Windows Server® 2003

operating systems.


What does AD LDS do?

AD LDS gives organizations flexible support for directory-enabled applications. A

directory-enabled application uses a directory—rather than a database, flat file,

or other data storage structure—to hold its data. Directory services (such as

AD LDS) and relational databases both provide data storage and retrieval, but

they differ in their optimization. Directory services are optimized for read

processing, whereas relational databases are optimized for transaction

processing. Many off-the-shelf applications and many custom applications use a

directory-enabled design. Examples include:

Customer relationship management (CRM) applications

Human Resources (HR) applications

Global address book applications

AD LDS provides much of the same functionality as AD DS (and, in fact, is built on

the same code base), but it does not require the deployment of domains or

domain controllers.

You can run multiple instances of AD LDS concurrently on a single computer, with

an independently managed schema for each AD LDS instance or configuration set

(if the instance is part of a configuration set). Member servers, domain

controllers, and stand-alone servers can be configured to run the AD LDS server

role.

AD LDS is similar to AD DS in that it provides the following:

Multimaster replication

Support for the Active Directory Service Interfaces (ADSI) application

programming interface (API)

Application directory partitions


LDAP over Secure Sockets Layer (SSL)

AD LDS differs from AD DS primarily in that it does not store Windows security

principals. While AD LDS can use Windows security principals (such as domain

users) in access control lists (ACLs) that control access to objects in AD LDS,

Windows cannot authenticate users stored in AD LDS or use AD LDS users in its

ACLs. In addition, AD LDS does not support domains and forests, Group Policy, or

global catalogs.

Who will be interested in AD LDS?

Organizations that have the following requirements will find AD LDS particularly

useful:

Application-specific directories that use customized schemas or that

depend on decentralized directory management

AD LDS directories are separate from the domain infrastructure of AD DS.

As a result, they can support applications that depend on schema

extensions that are not desirable in the AD DS directory—such as schema

extensions that are useful to a single application. In addition, the local

server administrator can administer the AD LDS directories; domain

administrators do not need to provide administrative support.

Directory-enabled application development and prototyping environments

that are separate from the enterprise's domain structure

Application developers who are creating directory-enabled applications can

install the AD LDS role on any server, even on stand-alone servers. As a

result, developers can control and modify the directory in their

development environment without interfering with the organization's

AD DS infrastructure. These applications can be deployed subsequently

with either AD LDS or AD DS as the application's directory service, as

appropriate.


Network administrators can use AD LDS as a prototype or pilot

environment for applications that will eventually be deployed with AD DS

as its directory store, as long as the application does not depend on

features specific to AD DS.

Management of external client computers' access to network resources

Enterprises that need to authenticate extranet client computers, such as

Web client computers or transient client computers, can use AD LDS as the

directory store for authentication. This helps enterprises avoid having to

maintain external client information in the enterprise's domain directory.

Enabling of earlier LDAP client computers in a heterogeneous environment

to authenticate against AD DS

When organizations merge, there is often a need to integrate LDAP client

computers running different server operating systems into a single network

infrastructure. In such cases, rather than immediately upgrading client

computers running earlier LDAP applications or modifying the AD DS

schema to work with the earlier clients, network administrators can install

the AD LDS server role on one or more servers. The AD LDS server role acts

as an interim directory store using the earlier schema until the client

computers can be upgraded to use AD DS natively for LDAP access and

authentication.

Are there any special considerations?

Since AD LDS is designed to be a directory service for applications, it is expected

that the applications will create, manage, and remove directory objects. As a

general-purpose directory service, AD LDS is not supported by such domain-

oriented tools as:

Active Directory Domains and Trusts


Active Directory Users and Computers

However, administrators can manage AD LDS directories by using directory tools

such as the following:

ADSI Edit (for viewing, modifying, creating, and deleting any object in

AD LDS)

Ldp.exe (for general LDAP administration)

Other schema management utilities


Configure the read-only domain controller (RODC).

A read-only domain controller (RODC) is a new type of domain controller in the

Windows Server® 2008 operating system. With an RODC, organizations can easily

deploy a domain controller in locations where physical security cannot be

guaranteed. An RODC hosts read-only partitions of the

Active Directory® Domain Services (AD DS) database.

Before the release of Windows Server 2008, if users had to authenticate with a

domain controller over a wide area network (WAN), there was no real alternative.

In many cases, this was not an efficient solution. Branch offices often cannot

provide the adequate physical security that is required for a writable domain

controller. Furthermore, branch offices often have poor network bandwidth when

they are connected to a hub site. This can increase the amount of time that is

required to log on. It can also hamper access to network resources.

Beginning with Windows Server 2008, an organization can deploy an RODC to

address these problems. As a result, users in this situation can receive the

following benefits:

Improved security

Faster logon times

More efficient access to resources on the network

For more information about RODCs, see the Read-Only Domain Controller (RODC)

Planning and Deployment Guide (


What does an RODC do?

Inadequate physical security is the most common reason to consider deploying an

RODC. An RODC provides a way to deploy a domain controller more securely in

locations that require fast and reliable authentication services but cannot ensure

physical security for a writable domain controller.

However, your organization may also choose to deploy an RODC for special

administrative requirements. For example, a line-of-business (LOB) application

may run successfully only if it is installed on a domain controller. Or, the domain

controller might be the only server in the branch office, and it may have to host

server applications.

In such cases, the LOB application owner must often log on to the domain

controller interactively or use Terminal Services to configure and manage the

application. This situation creates a security risk that may be unacceptable on a

writable domain controller.

An RODC provides a more secure mechanism for deploying a domain controller in

this scenario. You can grant a nonadministrative domain user the right to log on

to an RODC while minimizing the security risk to the Active Directory forest.

You might also deploy an RODC in other scenarios where local storage of all

domain user passwords is a primary threat, for example, in an extranet or

application-facing role.

Who will be interested in this feature?

RODC is designed primarily to be deployed in remote or branch office

environments. Branch offices typically have the following characteristics:

Relatively few users

Poor physical security


Relatively poor network bandwidth to a hub site

Little knowledge of information technology (IT)

You should review this section, and the additional supporting documentation

about RODC, if you are in any of the following groups:

IT planners and analysts who are technically evaluating the product

Enterprise IT planners and designers for organizations

Those responsible for IT security

AD DS administrators who deal with small branch offices


To deploy an RODC, at least one writable domain controller in the domain must

be running Windows Server 2008. In addition, the functional level for the domain

and forest must be Windows Server 2003 or higher.

What new functionality does this feature provide?

RODC addresses some of the problems that are commonly found in branch

offices. These locations might not have a domain controller. Or, they might have a

writable domain controller but not the physical security, network bandwidth, or

local expertise to support it. The following RODC functionality mitigates these

problems:

Read-only AD DS database

Unidirectional replication

Credential caching

Administrator role separation

Read-only Domain Name System (DNS)


Read-only AD DS database

Except for account passwords, an RODC holds all the Active Directory objects and

attributes that a writable domain controller holds. However, changes cannot be

made to the database that is stored on the RODC. Changes must be made on a

writable domain controller and then replicated back to the RODC.

Local applications that request Read access to the directory can obtain access.

Lightweight Directory Application Protocol (LDAP) applications that request Write

access receive an LDAP referral response. This response directs them to a writable

domain controller, normally in a hub site.

RODC filtered attribute set

Some applications that use AD DS as a data store might have credential-like data

(such as passwords, credentials, or encryption keys) that you do not want to be

stored on an RODC in case the RODC is compromised.

For these types of applications, you can dynamically configure a set of attributes

in the schema for domain objects that will not replicate to an RODC. This set of

attributes is called the RODC filtered attribute set. Attributes that are defined in

the RODC filtered attribute set are not allowed to replicate to any RODCs in the

forest.

A malicious user who compromises an RODC can attempt to configure it in such a

way that it tries to replicate attributes that are defined in the RODC filtered

attribute set. If the RODC tries to replicate those attributes from a domain

controller that is running Windows Server 2008, the replication request is denied.

However, if the RODC tries to replicate those attributes from a domain controller

that is running Windows Server 2003, the replication request can succeed.

Therefore, as a security precaution, ensure that forest functional level is Windows

Server 2008 if you plan to configure the RODC filtered attribute set. When the

forest functional level is Windows Server 2008, an RODC that is compromised


cannot be exploited in this manner because domain controllers that are running

Windows Server 2003 are not allowed in the forest.

You cannot add system-critical attributes to the RODC filtered attribute set. An

attribute is system-critical if it is required for AD DS; Local Security Authority

(LSA); Security Accounts Manager (SAM; and Microsoft-specific Security Service

Provider Interfaces (SSPIs), such as Kerberos; to function properly. A system-

critical attribute has a schemaFlagsEx attribute value equal to 1 (schemaFlagsEx

attribute value & 0x1 = TRUE).

The RODC filtered attribute set is configured on the server that holds the schema

operations master role. If you try to add a system-critical attribute to the RODC

filtered set while the schema master is running Windows Server 2008, the server

returns an "unwillingToPerform" LDAP error. If you try to add a system-critical

attribute to the RODC filtered attribute set on a Windows Server 2003 schema

master, the operation appears to succeed but the attribute is not actually added.

Therefore, it is recommended that the schema master be a Windows Server 2008

domain controller when you add attributes to RODC filtered attribute set. This

ensures that system-critical attributes are not included in the RODC filtered

attribute set.

Unidirectional replication

Because no changes are written directly to the RODC, no changes originate at the

RODC. Accordingly, writable domain controllers that are replication partners do

not have to pull changes from the RODC. This means that any changes or

corruption that a malicious user might make at branch locations cannot replicate

from the RODC to the rest of the forest. This also reduces the workload of

bridgehead servers in the hub and the effort required to monitor replication.

RODC unidirectional replication applies to both AD DS and Distributed File System

(DFS) Replication of SYSVOL. The RODC performs normal inbound replication for

AD DS and SYSVOL changes.


Note

Any other shares on an RODC that you configure to replicate using DFS

Replication would be bidirectional.

RODCs also perform automatic load balancing of inbound replication connection

objects across a set of bridgehead servers in a hub site.).

Credential caching

Credential caching is the storage of user or computer credentials. Credentials

consist of a small set of approximately 10 passwords that are associated with

security principals. By default, an RODC does not store user or computer

credentials. The exceptions are the computer account of the RODC and a special

krbtgt account that each RODC has. You must explicitly allow any other credential

caching on an RODC.

The RODC is advertised as the Key Distribution Center (KDC) for the branch office.

The RODC uses a different krbtgt account and password than the KDC on a

writable domain controller uses when it signs or encrypts ticket-granting ticket

(TGT) requests.

After an account is successfully authenticated, the RODC attempts to contact a

writable domain controller at the hub site and requests a copy of the appropriate

credentials. The writable domain controller recognizes that the request is coming

from an RODC and consults the Password Replication Policy in effect for that

RODC.

The Password Replication Policy determines if a user's credentials or a computer's

credentials can be replicated from the writable domain controller to the RODC. If

the Password Replication Policy allows it, the writable domain controller

replicates the credentials to the RODC, and the RODC caches them.


After the credentials are cached on the RODC, the RODC can directly service that

user's logon requests until the credentials change. (When a TGT is signed with the

krbtgt account of the RODC, the RODC recognizes that it has a cached copy of the

credentials. If another domain controller signs the TGT, the RODC forwards

requests to a writable domain controller.)

By limiting credential caching only to users who have authenticated to the RODC,

the potential exposure of credentials by a compromise of the RODC is also

limited. Typically, only a small subset of domain users has credentials cached on

any given RODC. Therefore, in the event that the RODC is stolen, only those

credentials that are cached can potentially be cracked.

Leaving credential caching disabled might further limit exposure, but it results in

all authentication requests being forwarded to a writable domain controller. An

administrator can modify the default Password Replication Policy to allow users'

credentials to be cached at the RODC.

Administrator role separation

You can delegate local administrative permissions for an RODC to any domain

user without granting that user any user rights for the domain or other domain

controllers. This permits a local branch user to log on to an RODC and perform

maintenance work on the server, such as upgrading a driver. However, the branch

user cannot log on to any other domain controller or perform any other

administrative task in the domain. In this way, the branch user can be delegated

the ability to effectively manage the RODC in the branch office without

compromising the security of the rest of the domain.

Read-only DNS

You can install the DNS Server service on an RODC. An RODC is able to replicate all

application directory partitions that DNS uses, including ForestDNSZones and

DomainDNSZones. If the DNS server is installed on an RODC, clients can query it

for name resolution as they query any other DNS server.


However, the DNS server on an RODC is read-only and therefore does not support

client updates directly. For more information about how DNS client updates are

processed by a DNS server on an RODC

What settings have been added or changed?

To support the RODC Password Replication Policy, Windows Server 2008 AD DS

includes new attributes. The Password Replication Policy is the mechanism for

determining whether a user's credentials or a computer's credentials are allowed

to replicate from a writable domain controller to an RODC. The Password

Replication Policy is always set on a writable domain controller running Windows

Server 2008.

AD DS attributes that are added in the Windows Server 2008 Active Directory

schema to support RODCs include the following:

msDS-Reveal-OnDemandGroup

msDS-NeverRevealGroup

msDS-RevealedList

msDS-AuthenticatedToAccountList

For more information about these attributes, see the RODC Planning and

Deployment Guide (

How should I prepare to deploy this feature?

The prerequisites for deploying an RODC are as follows:

The RODC must forward authentication requests to a writable domain

controller running Windows Server 2008. The Password Replication Policy is

set on this domain controller to determine if credentials are replicated to

the branch location for a forwarded request from the RODC.


The domain functional level must be Windows Server 2003 or higher so

that Kerberos constrained delegation is available. Constrained delegation is

used for security calls that must be impersonated under the context of the

caller.

The forest functional level must be Windows Server 2003 or higher so that

linked-value replication is available. This provides a higher level of

replication consistency.

You must run adprep /rodcprep once in the forest to update the

permissions on all the DNS application directory partitions in the forest.

This way, all RODCs that are also DNS servers can replicate the permissions

successfully.


Configure Active Directory Federation Services (AD FSv2).

Active Directory Federation Services (AD FS) simplifies access to systems and

applications using a claims-based access (CBA) authorization mechanism to

maintain application security. AD FS supports Web single-sign-on (SSO)

technologies that help information technology (IT) organizations collaborate

across organizational boundaries. AD FS 2.0 is a downloadable

Windows Server 2008 update that is the successor to AD FS 1.0, which was first

delivered in Windows Server 2003 R2, and AD FS 1.1, which was made available as

a server role in Windows Server 2008 and Windows Server 2008 R2. Previous

versions of AD FS are referred to collectively as AD FS 1.x.

You can use Active Directory® Federation Services (AD FS) to create a highly

extensible, Internet-scalable, and secure identity access solution that can operate

across multiple platforms, including both Windows and non-Windows

environments. This topic provides an overview of the improvements in AD FS.

Overview of the improvements in AD FS

For Windows Server® 2008, AD FS includes new functionality that was not

available in Windows Server 2003 R2. This new functionality is designed to ease

administrative overhead and to further extend support for key applications:


Improved installation: AD FS is included in Windows Server 2008 as a

server role, and there are new server validation checks in the installation

wizard.

Improved application support: AD FS is more tightly integrated with

Microsoft Office SharePoint® Server 2007 and Active Directory Rights

Management Services (AD RMS).

A better administrative experience when you establish federated trusts:

Improved trust policy import and export functionality helps to minimize

partner-based configuration issues that are commonly associated with

federated trust establishment.

Active Directory Federation Services Role

Active Directory® Federation Services (AD FS) is a server role in the

Windows Server® 2008 operating system that you can use to create a highly

extensible, Internet-scalable, and secure identity access solution that can operate

across multiple platforms, including both Windows and non-Windows

environments. The following sections provide information about AD FS in

Windows Server 2008, including information about the additional functionality in

AD FS in Windows Server 2008 compared to the version of AD FS in the

Windows Server 2003 R2 operating system.

Who will be interested in this feature?

AD FS is designed to be deployed in medium to large organizations that have the

following:

At least one directory service: either Active Directory Domain Services

(AD DS) or Active Directory Lightweight Directory Services (AD LDS)

(formerly known as Active Directory Application Mode (ADAM))

Computers running various operating system platforms


Domain-joined computers

Computers that are connected to the Internet

One or more Web-based applications

Review this information, along with additional documentation about AD FS, if you

are any of the following:

An information technology (IT) professional who is responsible for

supporting an existing AD FS infrastructure

An IT planner, analyst, or architect who is evaluating identity federation

products


If you have an existing AD FS infrastructure, there are some special considerations

to be aware of before you begin upgrading federation servers, federation server

proxies, and AD FS-enabled Web servers running Windows Server 2003 R2 to

Windows Server 2008. These considerations apply only when you have AD FS

servers that have been manually configured to use unique service accounts.

AD FS uses the Network Service account as the default account for both the AD FS

Web Agent Authentication Service and the identity of the ADFSAppPool

application pool. If you manually configured one or more AD FS servers in your

existing AD FS deployment to use a service account other than the default

Network Service account, track which of the AD FS servers use these unique

service accounts and record the user name and password for each service

account.

When you upgrade a server to Windows Server 2008, the upgrade process

automatically restores all service accounts to their original default values.

Therefore, you must enter service account information again manually for each

applicable server after Windows Server 2008 is fully installed.


What new functionality does this feature provide?

For Windows Server 2008, AD FS includes new functionality that was not available

in Windows Server 2003 R2. This new functionality is designed to ease

administrative overhead and to further extend support for key applications:

Improved installation—AD FS is included in Windows Server 2008 as a

server role, and there are new server validation checks in the installation

wizard.

Improved application support—AD FS is more tightly integrated with

Microsoft Office SharePoint® Server 2007 and Active Directory Rights

Management Services (AD RMS).

A better administrative experience when you establish federated trusts—

Improved trust policy import and export functionality helps to minimize

partner-based configuration issues that are commonly associated with

federated trust establishment.

Improved installation

AD FS in Windows Server 2008 brings several improvements to the installation

experience. To install AD FS in Windows Server 2003 R2, you had to use Add or

Remove Programs to find and install the AD FS component. However, in Windows

Server 2008, you can install AD FS as a server role using Server Manager.

You can use improved AD FS configuration wizard pages to perform server

validation checks before you continue with the AD FS server role installation. In

addition, Server Manager automatically lists and installs all the services that AD FS

depends on during the AD FS server role installation. These services include

Microsoft ASP.NET 2.0 and other services that are part of the Web Server (IIS)

server role.

Improved application support


AD FS in Windows Server 2008 includes enhancements that increase its ability to

integrate with other applications, such as Office SharePoint Server 2007 and

AD RMS.

Integration with Office SharePoint Server 2007

Office SharePoint Server 2007 takes full advantage of the SSO capabilities that are

integrated into this version of AD FS. AD FS in Windows Server 2008 includes

functionality to support Office SharePoint Server 2007 membership and role

providers. This means that you can effectively configure Office

SharePoint Server 2007 as a claims-aware application in AD FS, and you can

administer any Office SharePoint Server 2007 sites using membership and role-

based access control. The membership and role providers that are included in this

version of AD FS are for consumption only by Office SharePoint Server 2007.

Integration with AD RMS

AD RMS and AD FS have been integrated in such a way that organizations can take

advantage of existing federated trust relationships to collaborate with external

partners and share rights-protected content. For example, an organization that

has deployed AD RMS can set up federation with an external organization by

using AD FS. The organization can then use this relationship to share rights-

protected content across the two organizations without requiring a deployment

of AD RMS in both organizations.

Better administrative experience when establishing federated trusts

In both Windows Server 2003 R2 and Windows Server 2008, AD FS administrators

can create a federated trust between two organizations using either a process of

importing and exporting policy files or a manual process that involves the mutual

exchange of partner values, such as Uniform Resource Indicators (URIs), claim

types, claim mappings, display names, and so on. The manual process requires the

administrator who receives this data to type all the received data into the

appropriate pages in the Add Partner Wizard, which can result in typographical


errors. In addition, the manual process requires the account partner

administrator to send a copy of the verification certificate for the federation

server to the resource partner administrator so that the certificate can be added

through the wizard.

Although the ability to import and export policy files was available in

Windows Server 2003 R2, creating federated trusts between partner

organizations is easier in Windows Server 2008 as a result of enhanced policy-

based export and import functionality. These enhancements were made to

improve the administrative experience by permitting more flexibility for the

import functionality in the Add Partner Wizard. For example, when a partner

policy is imported, the administrator can use the Add Partner Wizard to modify

any values that are imported before the wizard process is completed. This

includes the ability to specify a different account partner verification certificate

and the ability to map incoming or outgoing claims between partners.

By using the export and import features that are included with AD FS in Windows

Server 2008, administrators can simply export their trust policy settings to an .xml

file and then send that file to the partner administrator. This exchange of partner

policy files provides all of the URIs, claim types, claim mappings, and other values

and the verification certificates that are necessary to create a federated trust

between the two partner organizations.

The following illustration and accompanying instructions show how a successful

exchange of policies between partners—in this case, initiated by the

administrator in the account partner organization—can help streamline the

process for establishing a federated trust between two fictional organizations:

A. Datum Corporation and Trey Research.


1. The account partner administrator specifies the Export Basic Partner Policy

option by right-clicking the Trust Policy folder and exports a partner policy

file that contains the URI, display name, federation server proxy Uniform

Resource Locator (URL), and verification certificate for A. Datum

Corporation. The account partner administrator then sends the partner

policy file (by e-mail or other means) to the resource partner administrator.


2. The resource partner administrator creates a new account partner using

the Add Account Partner Wizard and selects the option to import an

account partner policy file. The resource partner administrator proceeds to

specify the location of the partner policy file and to verify that all of the

values that are presented in each of the wizard pages—which are

prepopulated as a result of the policy import—are accurate. The

administrator then completes the wizard.

3. The resource partner administrator can now configure additional claims or

trust policy settings that are specific to that account partner. After this

configuration is complete, the administrator specifies the Export Policy

option by right-clicking the A. Datum Corporation account partner. The

resource partner administrator exports a partner policy file that contains

values such as the URI, federation server proxy URL, display name, claim

types, and claim mappings for the Trey Research organization. The resource

partner administrator then sends the partner policy file to the account

partner administrator.

4. The account partner administrator creates a new resource partner using

the Add Resource Partner Wizard and selects the option to import a

resource partner policy file. The account partner administrator specifies the

location of the resource partner policy file and verifies that all of the values

that are presented in each of the wizard pages—which are prepopulated as

a result of the policy import—are accurate. The administrator then

completes the wizard.

When this process is complete, a successful federation trust between both

partners is established. Resource partner administrators can also initiate the

import and export policy process, although that process is not described here.

What settings have been added or changed?

You configure Windows NT token-based Web Agent settings with the IIS Manager

snap-in. To support the new functionality that is provided with Internet


Information Services (IIS) 7.0, Windows Server 2008 AD FS includes user interface

(UI) updates for the AD FS Web Agent role service. The following table lists the

different locations in IIS Manager for IIS 6.0 or IIS 7.0 for each of the AD FS Web

Agent property pages, depending on the version of IIS that is used.


PART 2


Creating and maintaining Active Directory objects


Groups

Know that Shadow Groups is a group that has the same members as a OU,

remember that this isn't an automatic updated group but a manual process.

Create and apply Group Policy objects (GPOs)

Group Policy Loopback

If this setting is enabled the user configuration on the computer object will win

over normally the user configuration on the user object. This can be useful on

kiosk, conference computer etc where you want a standard. When Loopback GPO

setting is enabled you have 2 choices:

1. Replace - Only User settings from the computer object takes place

2. Merge - Both User settings from computer and user object takes place, if

there is a conflict the computer object win.

Configure GPO templates

GPO Preference

New in Windows Server 2008 there is a section under User and Computer GPO

configuration called Preference. This can be used to set preference settings on

users and computer settings such as set explorer.exe to default display or not file

extension.

Security templates

Security templates can still be used in Windows 2008 and works like before

(secedit to apply parts of a security template, inf file). New is the possibility to run

The Security Configuration Wizard. After the wizard is run the result is saved into

a xml file, to apply it to computers you can export it to a gpo with the scwcmd.exe

command with the transform switch:


scwcmd transform /p:"JBKB sec.xml" /g:JBKB sec GPO"

The Security Configuration Wizard can change service startup type, Windows

Firewall settings, Registry settings concerning security (SMB signing, LDAP signing,

LAN Manager authentication level, storage of LM hashes etc) and Audit Policy.

Starter GPOs

Starter GPOs are new feature in Windows Server 2008; know that this is just a

GPO template with predefined Administrative Template settings. When you

create a new GPO you can choose to start from a blank or a Starter GPO

(template).

Central Store

Know that ADM files are stored as part of the GPO and include all language in the

same file.

Vista and Windows Server 2008 can use the old ADM but support also the newer

format ADMX (settings) and ADML (MUI), then the GPO only contains data

needed and call for ADMX/ADML from the Central Store on demand.

The Central Store can manually be created by creating a sub folder called

PolicyDefinitions under \\JBKB.local\SYSVOL\JBKB.local\Policies\ and copy all

files from a DC on %SystemRoot%\PolicyDefinitions

(c:\windows\PolicyDefinitions) to

\\JBKB.local\SYSVOL\JBKB.local\Policies\PolicyDefinitions\ with subfolder for

each language, Swedish for example would be sv-sv.

Remember that ADM and ADMX/ADML can coexist.


Automate creation of Active Directory accounts.

Two methods are described:

netdom

Scripting the computer account using Active Directory Service Interface

(ADSI) and Windows Script Host

Creating Computer Accounts Using "NETDOM"

Note that you should use only the Windows XP version of netdom, which is

included with the Windows XP CD in the Support\Tools\Support.cab file. Previous

versions do not work correctly for all features in Windows XP.You can use netdom

from the command line (or call it optionally from a batch file) to script computer

account creation.

This sample creates only the computer account and displays how you can specify

credentials of an authorized user who has permissions to create computer

accounts in the domain. Follow this example of the syntax for the netdom

command

netdom join ComputerName /domain:DomainName /userd:User

/passwordd:UserPassword

where User is a user with permission to join the domain.



Maintaining an Active Directory is a very important administrative task that one

must schedule regularly to ensure that, in case of disaster, you can recover your

lost or corrupted data and can repair the active directory database.

Extensible Storage Engine (ESE) is the active directory database, which manage all

the active directory objects in active directory database. Any of the data

modification affects database performance, database fragmentation and data

integrity.

Active Directory Database and Log Files

The ESE uses transaction and log files to ensure the integrity of the active

directory database. Active Directory includes the following files:

Ntds.dit is the Active Directory database which stores the entire active

directory objects on the domain controller. The .dit extension refers to the

directory information tree. The default location is the %systemroot%Ntds

folder. Active Directory records each and every transaction log files that are

associated with the Ntds.dit file.

Edb*.log is the transaction log file. Each transaction file is 10 megabytes

(MB). When Edb.log file is full, active directory renames it to Edbnnnnn.log,

where nnnnn is an increasing number starts from 1.

Edb.chk is a checkpoint file which is use by database engine to track the

data which is not yet written to the active directory database file. The

checkpoint file act as a pointer that maintains the status between memory

and database file on disk. It indicates the starting point in the log file from

which the information must be recovered if a failure occurs.

Res1.log and Res2.log: These are reserved transaction log files. The amount

of disk space that is reserved on a drive or folder for this log is 20 MB. This

reserved disk space provides a sufficient space to shut down if all the other

disk space is being used.


Moving and Defragmenting the Active Directory Database

Over a period of time, fragmentation occurs as records in the active directory

databases are deleted and new records are added. When then records are

fragmented, the computer must search the active directory database to find all

the records each time the active directory database is opened. This search slows

the response time. Fragmentation also degraded the overall performance of the

active directory operations.

To overcome the problems that fragmentation causes, you defragment the active

directory database. Defragmentation is the process of rewriting records in the

Active Directory database to contiguous sectors to increase the speed of access

and retrieval. When the records are updated, Active Directory saves these

updates on the largest contiguous space in the Active Directory database.

Moving Database and Log Files

You move a database to a new location when you defragment the database.

Moving the database does not delete the original database. Therefore, you can

use the original database if the defragmented database does not work or

becomes corrupted. Also, if your disk space is limited, you can add another hard

disk drive and move the database to it. Additionally, you move the database files

in order to perform hardware maintenance. If the disk on which the files are

stored requires upgrading or maintenance, you can move the files to another

location temporarily or permanently.


Configure GPO templates.

In Windows 2000 and Windows Server 2003,2008 Group Policy Objects (also

known as GPO) you may find hundreds of useful settings and configuration

options, all nicely divided in to specific sections. With GPO, you can create policies

to centralize the management of user and computer settings. Amongst the

various settings that can be accomplished via GPO, you can find the following

options:

Manage desktop environments and lock them down to reduce support calls

and TCO (Total Cost of Ownership)

Install, update, repair, and remove software

Manage security settings including account policies, auditing, EFS, and user

rights

Control running state of services

Redirect My Documents folders

Configure Internet Explorer options and security settings

Automate administrative tasks using log-on, log-off, startup and shutdown

scripts

Note that the GPO settings is divided between the Computer settings and the

User settings. In both parts of the GPO you can clearly see a large section called

Administrative Templates.

Administrative Templates are a large repository of registry-based changes (in fact,

over 1300 individual settings) that can be found in any GPO on Windows 2000,

Windows XP, and Windows Server 2003.

By using the Administrative Template sections of the GPO you can deploy

modifications to machine (called HKEY_LOCAL_MACHINE in the registry) and user

(called HKEY_CURRENT_USER in the registry) portions of the Registry of

computers that are influenced by the GPO.


The Administrative Templates are Unicode-formatted text files with the extension

.ADM and are used to create the Administrative Templates portion of the user

interface for the GPO Editor.

Windows 2000/XP/2003 has some built-in default Administrative Templates:

Administrative Template

Name

Can be found on these

Operating Systems Description

Conf.adm Windows 2000/XP/2003 Contains settings for

configuring NetMeeting

Inetres.adm Windows 2000/XP/2003

Contains settings for

configuring Internet

Explorer

System.adm Windows 2000/XP/2003


configuring core OS

functions and GUI

settings

Wmplayer.adm Windows XP/2003


configuring Windows

Media Player

Wuau.adm

Windows 2000 SP3 or

higher/XP SP1 or

higher/2003


configuring Windows

Update automatic

updates

These .ADM files are located in the %SystemRoot%\inf folder, and are copied to

the SYSVOL folder whenever you create a new GPO (unless to manually configure

it not to do so.


On top of these templates, Windows 2000/XP/2003 also has other .ADM files that

can be used in several scenarios:

Administrative Template

Name Description

Common.adm

Contains settings that are in common with

Windows 9x/NT (used with the NT-based System

Policy Editor)

Inetcorp.adm Contains settings for configuring dial-up, language,

and various Internet Explorer settings

Inetset.adm Contains additional policy settings for configuring

Internet Explorer

Windows.adm Contains settings specific to Windows 9x (used

with the NT-based System Policy Editor)

However there may be times when an administrator will need to add more

options to a new or existing GPO. Some examples of such additions are:

Settings to disable mobile storage devices (USB, MP3 players, cameras and

so on)

Settings to control the functionality of specific Windows features

Settings to control behavior of specific Windows services or drivers

Settings that add or change registry keys

Changes to the Windows security model

One method for an administrator to control such settings is by use of logon scripts

and remote registry tweaks. This process requires knowledge of scripting

languages, but is highly customizable and flexible, and is not restricted to GPO


limitations (i.e. not working on pre-W2K computers). However we will not cover

this method in this article.

Another method for an administrator to add such extensions to the GPO is by

adding new settings to the Administrative Templates sections. This can be done

by adding .ADM files to the existing Administrative Templates section in GPO.

A great example of new .ADM files that can and should be used on a network is

the set of Administrative Templates extension files that is a part of the Office

2000/XP/2003 Resource Kit. When installing the Resource Kit for the respective

Office version, new .ADM files are copied to the %SystemRoot%\inf folder of the

machine on which the Resource Kit was installed. The moment you edit an Active

Directory-based GPO on that machine (the machine can be either a Windows

2000/XP Pro machine, or a server-based machine) the used .ADM file(s) will be

copied to the SYSVOL folder on the target DC (typically the PDC Emulator), and

from there replicated throughout the domain.


Deploy and manage software by using GPOs.

When Active Directory was launched in Windows 2000, one of its key design

features was to ease the process of deploying software within an organization. To

this end, Microsoft included the ability to deploy and distribute software with

Group Policy. IntelliMirror technologies include Group Policy software installation

to simplify the management necessary for large quantities of users and

computers. The Software Installation and Maintenance component of the

IntelliMirror technologies can be used to publish applications over the network.

Publishing is the terminology used to make applications available for installation

from over the network. The Software Installation and Maintenance component

can also automatically install applications based on certain predefined criteria on

computers. For instance, applications can be automatically installed on computers

based on specific users or groups or it can be automatically installed on specified

computers. The Software Installation and Maintenance component can also be

used to uninstall applications. To make these capabilities available, the Software

Installation and Maintenance component of the IntelliMirror technologies

interrelates with Group Policy and the Active Directory directory service.

In order to deploy software with Group Policy, the following conditions apply:

The organization must be running a Windows 2000 or Windows Server

2003 Active Directory domain.

Client computers must be running Windows 2000 Professional or later.

When using Group Policy to deploy software in an Active Directory domain, users

basically need to edit an existing Group Policy Object (GPO) or create a new GPO.

The GPO needs to be linked to a site, domain, or organizational unit (OU). A GPO

that is linked to one these components has a Software Installation node located

under the Computer Configuration node and a software installation node located

under the User Configuration node. Users can access a GPO linked to a site,

domain, or OU through the Group Policy Editor console. The Software Installation

node in the Group Policy Object Editor console can be considered the main tool

http://www.tech-faq.com/group-policy.html

http://www.tech-faq.com/object.html


used to deploy software. The Software Installation node also enables the

centralized management of the initial deployment of software and the removal of

software. Users can also centrally manage software upgrades, hotfixes, and

patches from this location.

Deploying software through Group Policy encompasses two types of software

deployment:

Assigning applications: the user should assign applications if certain users

should have the applications available, irrespective of the actual computer

the user is logged on to. Applications that are assigned are advertised to

the user on the Start menu and are installed on initial use. Users can specify

that the application be installed when someone next logs on to the

workstation. Advertising is the process by which the application is prepared

for installation. When Group Policy is used to deploy software and the

software is included in the GPO linked to a site, domain, or OU, the

software is referred to as being advertised to the user and computer. If

assigning the application to a user, use the Software Installation node

under User Configuration node, Software Settings. If assigning the

application to a computer, use the Software Installation node under

Computer Configuration, Software Settings.

The process for assigning applications is listed below:

1. When the user logs on to the client computer, the WinLogon process

advertises the application(s) on the Start menu or on the user’s

desktop.

2. The user selects the application from either one of these locations.

3. The Windows Installer service obtains the Windows Installer package

for the selected application.

4. The request for the software is next passed on to the software

distribution point (SDP).

5. The Windows Installer service initiates then installs the Windows

Installer package for the requested software.

6. The Windows Installer service opens the application for the user.


Publishing applications: When an application is published in Active

Directory, the application is advertised to users in Control Panel, in the

Add/Remove Programs applet. What this means is that the application is

not automatically installed for the user and the user actually controls

whether and when the application is installed. The user also controls the

uninstallation of the application.

The process for publishing applications is listed below:

1. The user logs onto the client computer and opens the Add Or

Remove applet in Control Panel.

2. The Add Or Remove applet gets its information on which software is

available for installation from Active Directory.

3. The user proceeds to select which application to install.

4. The Add Or Remove applet obtains the software’s location from

Active Directory.

5. The request for the software is passed on to the software distribution

point (SDP).

6. The Windows Installer service initiates then installs the Windows

Installer package for the requested software.

7. The user is now able to access the installed application.

In Group Policy, Software Installation utilizes the Windows Installer service to

maintain and manage the state of software installation. The service runs in the

background and enables the operating system (OS) to manage software

installation based on information stored in the Windows Installer package.

Group Policy Software Installation Components

The components involved in deploying software through Group Policy are

discussed next.


Windows Installer package: This is a file with an .msi file extension that

holds the instructions for installing, configuring, and removing software.

The types of Windows installer packages are:

o Native Windows Installer package files: This type of Windows

installer package is developed as a software component. The

Windows Installer service can be fully utilized. The Native Windows

Installer package files include one product that has numerous

features that can be installed individually.

o Repackaged application files: The difference between the two

packages is that repackaged application files include one product

that is installed as one feature.

Transforms: Another term used for transforms is modifications. A transform

is basically a record of changes that were made to the original package file.

Transforms enable users to customize Windows Installer packages and the

installation features when they publish or assign the application. Through

transforms, users can include and exclude features for the installation. The

types of customization files that can be configured are listed below.

Transform files have a .mst file extension:

o Transform files: Transform files enable users to customize the

installation of the application.

o Patch Files: These files have a .msp file extension, are used to update

existing Windows Installer packages with additional information, and

are used for the following purposes:

Software patches

Service Packs

Software Updates

Application files: These are text files with a .zap file extension that include

instructions on how to publish an application. Because .zap files do not

support Windows Installer features, they deploy and install applications

using its original Setup.exe or Install.exe program.


Planning for Deploying Software using Group Policy

When planning to deploy software through Group Policy, include the following:

Encompass the organization’s software requirements into the strategy.

Assess the organizational structure in Active Directory and identify the

available GPOs.

Define the manner in which the applications are going to be deployed to

users or computers. Are the applications going to be published in Active

Directory or assigned to users and computers?

Test the manner in which the applications are going to be assigned to be

published.

A few best practices and strategies to consider are listed below:

Software can be deployed at the site level, domain level, or organizational

unit level in Active Directory. It is recommended that users deploy software

as high in the Active Directory hierarchy or tree as possible. Software

should be deployed close to the root in the Active Directory tree because it

allows users to use one GPO to deploy software to multiple users.

Deploy multiple applications with a single GPO because it is easier to

administer multiple applications from the same GPO than to manage

multiple GPOs. User logon time is also accelerated because less GPOs need

to be processed.

If there are different users and computers that need different applications

deployed, create OUs according to these software management

requirements, place the necessary users or computers in the OU, then

apply the GPO containing the software that should be deployed.

The Process for Deploying Software through Group Policy

The general process necessary to deploy software through Group Policy is

summarized below:


Create software distribution points (SDPs): One of the steps in deploying

software is to ensure that users are able to access the necessary files. SDPs

are the shared folders on the network that contain the files needed to

install the deployed applications. Each user that will need to deploy

software should be able to access the SDP. The NTFS permissions should be

Read and Execute for the SDP and the necessary subfolders, so that users

have permissions to access the folder that contains the software

installation package.

Create a GPO for software deployment and a GPO console for software

deployment: When deploying software through Group Policy, the Group

Policy Object Editor is used for the following tasks:

o Configure software deployment installation options.

o Assign applications

o Publish applications

o Upgrade applications

o Remove managed applications.

Configure the software deployment installation properties for the GPO: The

Software Installation Properties dialog box contains four tabs that are used

to set configuration options for the software that should be deployed:

o General tab: This is where users set the default location of all

packages, set the default value for publishing or assigning, and set

installation user interface options.

o Advanced tab: This tab includes options such as automatically

uninstalling applications when the GPO no longer applies to the user

or computer, storing Object Linking and Embedding (OLE)

information in Active Directory, and enabling 64-bit Windows clients

to install 32-bit Windows Installer applications.

o File Extensions tab: Users configure which file extensions should be

accessed by applications on the File Extensions tab.

o Categories tab: Applications categories serve a useful purpose when

an organization has a large quantity of published applications. The

Categories tab allows users to create and organize applications by


categories so users are able to easily locate the applications in the

Add/Remove Programs applet of Control Panel.

Add the installation packages to the GPO: In this step, add the installation

packages to the GPO and specify whether the application is to be assigned

or published to users and computers.

Configuring Windows Installer package properties: Once a WindowsInstaller

package is added to a GPO, users can change the properties of the package

to modify the category of the application, whether the application is

assigned or published, configures security settings, and adds or removes

transforms (modifications). The Properties dialog box for the Windows

Installer package is where users configure Windows Installer package

properties with the tabs listed below.

o General tab: This is where users change the package’s default name.

Users can also select a support URL to direct users to a support Web

page. Users can choose the support URL from the Add Or Remove

Programs applet.

o Deployment tab: On the Deployment tab, select settings for the

following:

Deployment type

Deployment options

Installation user interface options

o Upgrades tab: The Upgrades tab is not available for packages that

were created from application files or .zap files. The tab is used to

install upgrades. The first step is to create a Windows Installer

package that contains the upgrade. The second step is to configure

settings for the upgrade in the Upgrades tab.

o Categories tab: This is where application categories are set so that

users can easily locate the application in the Add Or Remove

Programs applet in Control Panel.

o Modifications tab: This is where users customize an installation

package by adding or removing transforms.


o Security tab: configure the users or groups that should be able to

access the application on the Security tab.

How to Create a Software Distribution Point (SDP)

1. Log on to the file server to be used as an SDP.

2. Create the network share and the necessary folders for the software.

3. The permissions that should be configured are listed below:

o Administrators: Full Control

o Everyone or Authenticated Users: Read

o Domain Computers: Read

4. Copy the software, including all necessary files and components, to the

SDP.

How to Create or Open a GPO and a GPO Console for Software Deployment

To create a new GPO:

1. Open the Active Directory Sites And Services. To create and link a GPO to a

domain or OU, open the Active Directory Users and Computers console.

2. Right click the site, domain, or OU then click Properties on the shortcut

menu.

3. When the Properties dialog box of the site, domain, or OU opens, click the

Group Policy tab.

4. Click New and enter a name for the GPO.

5. Click Close. The GPO is by default linked to the site, domain, or OU in which

it was created.

To open an existing domain level GPO or OU level GPO:

1. Open the Active Directory Users and Computers console.

2. Right click the domain or OU in the left console pane and click Properties on

the shortcut menu.

3. Click the Group Policy tab.


4. In the Group Policy Object Links list, select the GPO and click Edit.

5. The GPO is opened in the Group Policy Object Editor console.

To open an existing site level GPO:

1. Open the Active Directory Sites and Services console.

2. Expand the Sites node.

3. Right click the site in the details pane and click Properties on the shortcut

menu.


5. In the Group Policy Object Links list, select the GPO and click Edit.

6. The GPO is opened in the Group Policy Object Editor console.

To create an MMC for a GPO:

1. Click Start, Run, enter mmc in the Run dialog box, and click OK.

2. On the File menu, click Add/Remove Snap-In.

3. Click Add in the Add/Remove Snap-In dialog box to access the Add/Remove

Snap-In dialog box. Click Add.

4. Select Group Policy Object Editor and click Add.

5. Click Browse to find the GPO.

6. Click the All tab in the Browse For A Group Policy Object dialog box.

7. Select the GPO. Click OK.

8. Close all open dialog boxes then click Save As in the MMC on the File menu.

9. Provide a name in the File Name box. Click Save.

10. The Group Policy Object Editor for the GPO can now be accessed under the

Administrative Tools menu.

How to Open the Software Installation Snap-in

The Software Installation snap-in is a Group Policy Object Editor component.

1. Open either the Active Directory Users and Computers console or the

Active Directory Sites and Services console.


2. Right click the site, domain, or OU then click Properties from the shortcut

menu.


4. Either create a new GPO or edit an existing GPO.

5. Click the Properties button then click the Security tab. Set the appropriate

permissions for the GPO. Click OK.

6. Choose the GPO and click Edit.

7. In the console tree, choose Computer Configuration to assign applications

to computers or choose User Configuration to assign or publish applications

to users.

How to Configure Software Deployment Installation Properties for the GPO

Using Group Policy to deploy software allows users to configure numerous

settings and options to control the manner in which software packages are

deployed and administered within an organization. To perform one of the

administrative tasks listed below, use the configuration steps detailed after the

listed administrative task:

Modify the default location for the installation packages.

Configure the default action that should be performed when new packages

are added to the GPO.

Define how much installation information is displayed to users during the

installation process.

Modify the quantity of control that users have over installing applications.

Configure the automatic uninstallation of applications when the GPO no

longer applies to users and computers.

1. Open the appropriate GPO for the software deployment.

2. In the console tree, proceed to expand either the User Configuration node

or the Computer Configuration node.

3. Right click the Software Installation node and click Properties on the

shortcut menu.


4. When the Software Installation Properties dialog box opens, in the Default

Package Location box of the General tab, enter the Uniform Naming

Convention (UNC) path to the SDP for the Windows Installer packages.

5. Configure the default action that should be performed on new packages in

the New Packages section of the General tab. Choose one of the options

listed below:

o Display The Deploy Software Dialog Box: This is the default

configuration setting. The Deploy Software dialog box will be

displayed when new packages are added to the GPO. On this dialog

box, choose whether to assign or publish the application or configure

the properties of the package.

o Publish: Remember that applications can only be published to users,

not computers. Therefore, this setting is only available for User

Configuration. When the option is selected, the application is

automatically published with the default package properties or

settings.

o Assign: When the Assign option is selected, any new software

installation packages added to the GPO are automatically assigned

with the default package properties or settings

o Advanced: When a new software installation package is added to the

GPO, the package’s properties dialog box is displayed. Configure the

properties for the installation package.

6. In the Installation User Interface Options section of the General tab, choose

one of the following options:

o Basic: When selected, users are shown limited information on the

installation process.

o Maximum: When selected, users are shown all the installation

messages and screens on the installation process.

7. Click the Advanced tab.

8. Select the Uninstall The Applications When They Fall Out Of The Scope Of

Management checkbox to automatically remove the application if the GPO

no longer applies to users or computers.


9. Select the Include OLE Information When Deploying Applications checkbox

if information on Component Object Model (COM) components should be

included with the package.

10. Select the Make 32-Bit X86 Windows Installer Applications Available To

Win64 Machines checkbox to enable 64-bit Windows client computers to

install 32-bit Windows Installer applications.

11. Select the Make 32-Bit X86 Down-Level (ZAP) Applications Available To

Win64 Machines checkbox to enable 64-bit client computers to install

applications published using a .zap file (application files).

How to Configure the Default Application for the Specified File Extension

A user would normally need to associate a file extension with an application when

he/she has multiple applications that can use a specified file format.

1. Open the appropriate GPO console.

2. In the console tree, expand either the User Configuration node or the

Computer Configuration node.


shortcut menu.

4. When the Software Installation Properties dialog box opens, click the File

Extensions tab.

5. Use the Select File Extension list to check which applications are associated

with the file extension.

6. Use the Up or Down buttons of the Application Precedence list box to move

an application that should be the default application for the particular

extension to the top of the list.

7. Click OK.

How to Create Application Categories for Applications that are Published

1. Open the appropriate GPO console.


Computer Configuration node.



shortcut menu.

4. When the Software Installation Properties dialog box opens, click the

Categories tab.

5. Click Add to add a new application category.

6. In the Enter New Category dialog box, specify a name for the new category

in the Category box. Click OK.

7. To remove an existing application category, select the category in the

Categories tab then click Remove.

8. To change the name of an existing application category, select the category

in the Categories tab then click Modify.

9. Click OK.

How to Change the Default Software Installation Behavior Over Slow Network

Links

Group Policy considers all network connections that are slower than 500 Kbps as

slow links (default). At this point, the policies listed below are disabled:

Disk Quotas

Folder Redirection

Scripts

Software Installation And Maintenance

However, users can change the speed that Group Policy considers slow to change

the default software installation behavior over slow network links. In addition to

this, enable or disable the processing of policies listed below over a slow link:

Disk Quota, EFS Recovery, Folder Redirection, Internet Explorer

Maintenance, IP Security, Scripts, Software Installation, and Security.

To change the default speed that Group Policy considers slow:

1. Open the GPO console.



Computer Configuration node then expand Administrative Templates,

System, and Group Policy.

3. Double-click Group Policy Slow Link Detection in the details pane.

4. When the Group Policy Slow Link Detection Properties dialog box opens,

select Enabled and enter the speed that should be used to define whether a

connection is slow. Entering a value of 0 disables slow link detection.

5. Click OK.

How to Add the Windows Installer Packages to the GPO


2. In the console tree, expand either the User or Computer Configuration

node then expand the Software Installation node.

3. Right click the Software Installation node and click New then Package on

the shortcut menu.

4. In the Files Of Type list, choose Windows Installer Package or choose ZAW

Down-Level Application Packages (.ZAP).

5. Choose the package that should be deployed. Click Open.

6. In the Deploy Software dialog box, specify how the package should be

deployed. Choose one of the following options:

o Published: The Windows Installer package is published to users in

Active Directory with the default settings.

o Assigned: The Windows Installer package is assigned to users or

computers with the default settings.

o Advanced: The option allows users to configure properties for the

Windows Installer package.

7. Click OK.


How to Configure Windows Installer Package Properties

Change the Windows Installer package properties after the package is added to

the GPO. To change the category of the application, the deployment type, and

security settings:




3. In the details pane, right click the software package to be modified and

select Properties on the shortcut menu.

4. On the General tab, enter a new name for the package in the Name box

and enter a support URL for users in the URL box.

5. Click the Deployment tab in order to change the existing manner in which

the package is deployed.

6. In the Deployment Type section of the Deployment tab, select the

Published or Assigned option.

7. In the Deployment Options section of the Deployment tab, select the

following checkboxes:

o Auto-Install This Application By File Extension Activation: The

application is automatically installed when a user opens a file that is

associated with the application.

o Uninstall This Application When It Falls Out Of The Scope Of

Management: The application is uninstalled when the associated

GPO is no longer applicable for the user or computer.

o Do Not Display This Package In The Add/Remove Programs Control

Panel: The application is not displayed in the Add/Remove Programs

applet in Control Panel.

o Install This Application At Logon: The application is installed when

the user next logs on to the computer.

8. In the Installation User Interface Options section of the Deployment tab,

choose either the Basic option or the Maximum option.


9. Click the Advanced button on the Deployment tab to open the Advanced

Deployment Options dialog box.

10. Set the options listed below under Advanced Deployment Options:

o Ignore Language When Deploying This Package: Deploys the package

even when the language in the package is in a different language.

The option basically ignores the language settings when the package

is deployed.

o Make This 32-Bit X86 Application Available To Win64 Machines:

Enables 64-bit Windows client computers to install 32-bit Windows

Installer applications.

o Include OLE Class And Product Information: Information on

Component Object Model (COM) components is included with the

package.

11. Click OK.

12. Click the Categories tab to assign the application to an application category.

13. Click the Security tab to configure the users or groups that should be able

to access the application.

14. Click OK.

How to Deploy Package Upgrades


2. In the console tree, expand either the User or the Computer Configuration


3. In the details pane, right click the upgrade package then select Properties

on the shortcut menu.

4. Click the Upgrades tab.

5. Click Add.

6. In the Add Upgrade Package dialog box, select whether a package from the

current GPO or from a specific GPO will be chosen.

7. Choose the package that should be upgraded from the Package To Upgrade

list.


8. If the existing application should be removed before the new application is

installed, click the Uninstall The Existing Package then Install The Upgrade

Package option.

9. If the new package should upgrade the existing package, click the Package

Can Upgrade Over The Existing Package option. This option does not

overwrite the user’s existing settings.

10. Click OK on the Add Upgrade Package dialog box.

11. Use the Add button and Remove button on the Upgrade tab to specify the

packages that the new package should upgrade.

12. Enable the Required Upgrade For Existing Packages checkbox to force users

to upgrade to the new package.

13. Click OK.

How to Apply Package Modifications




3. Right click the Software Installation node and select New then Package

from the shortcut menu.

4. Choose the base package for the application that should be deployed. Click

Open.

5. Use the My Network Places icon to locate this package.

6. Choose either Published or Assigned in the Deploy Software dialog box.

Click OK.

7. Click the Modifications tab.

8. Click Add and choose the Windows Installer transform package that should

be added in the Open dialog box. Click Open. Users can add multiple

modifications.

9. Use the Move Up and Down buttons on the Modifications tab to place the

packages in the appropriate order. Use the Add and Remove buttons to add

or remove transforms.

10. Click OK.


How to Remove Applications Deployed with Group Policy




3. Right click the package to be removed in the details pane, select All Tasks,

then Remove from the shortcut menu.

4. When the Remove Software dialog box opens, select one of the options

listed below:

o Immediately Uninstall The Software From Users And Computers to

immediately remove the software when the computer is restarted or

the next time when the user logs on to the computer.

o Allow Users To Continue To Use The Software, But Prevent New

Installations: This option prevents new instances of the application

from being installed, while still permitting users who have already

installed the application to continue using it.

5. Click OK.

Best Practices for Deploying Software Through Group Policy

A few best practices specific to deploying software through Group Policy are listed

below:

Test all software installation packages before deploying them.

Use and enforce standard configurations for applications if possible.

It is recommended that users deploy software as high in the Active

Directory hierarchy or tree as they can. Software should be deployed close

to the root in the Active Directory tree because it allows users to use one

GPO to deploy software to multiple users.

A Windows Installer package should be assigned/published only once in the

identical GPO.


Create application categories when there is a large quantity of published

applications within an organization. This makes it easier for users to find

applications in Add Or Remove Programs in Control Panel.


Configure account policies.

Given enough time and potential to try multiple username and password

combinations an attacker might eventually succeed in compromising the security

of a server or other computer. Account lockout policies allow you to set

thresholds to automatically shut down an account if too many incorrect username

and password combinations are attempted in order to protect the machine.

Sometimes you, or other users of a server or workstation, have a hard time

remembering the correct username and password. It may be from a simple typo

while entering the information or it may be a result of having too many different

usernames and passwords to remember. Whatever the reason, there are times

when incorrect authentication information will be entered when someone is

trying to log in. You don't need to be alarmed by a single failed attempt. You

probably don't even need to be concerned about two or three attempts.

At some point though you have to figure that it is no longer an honest mistake

and is either a program or individual systematically trying to guess different

username or password combinations to gain unauthorized access to the machine.

Windows offers a way to protect the machine from such attempts through the

Account Lockout Policies. By configuring the operating system to lock the account

and bar access after a certain number of failed login attempts you allow the

system to proactively block such attempts.

You can open the Local Security Settings console by following the following steps:

1. Click on Start

2. Click on Control Panel

3. Click on Administrative Tools


4. Click on Local Security Policy

You can also get to the same place by typing "secpol.msc" at a command prompt.

Once you have the Local Security Settings interface open you should click on

Account Policies and then click on Account Lockout Policy. You will see three

policies in the right pane along with the current status of each. The three policies

are the Account Lockout Threshold, Reset Account Lockout Counter After and

Account Lockout Duration. Here is a brief synopsis of each.

Account Lockout Threshold: The Account Lockout Threshold policy specifies the

number of failed login attempts allowed before the account is locked out. If the

threshold is set at 3 the account will be locked out after a user enters incorrect

login information 3 times within a specified timeframe.

Reset Account Lockout Counter After: This policy defines a timeframe for

counting the incorrect login attempts. If the policy is set for 1 hour and the

Account Lockout Threshold is set for 3 attempts a user can enter the incorrect

login information 3 times within 1 hour. If they enter the incorrect information

twice, but get it correct the third time the counter will reset after 1 hour has

elapsed (from the first incorrect entry) so that future failed attempts will again

start counting at 1.

Account Lockout Duration: The Account Lockout Duration policy allows you to

specify a timeframe after which the account will automatically unlock and resume

normal operation. If you specify 0 the account will be locked out indefinitely until

an administrator manually unlocks it.

Again, users may at times enter incorrect information for innocent reasons such

as a typo or simply forgetting what the password is. For a typical server or

workstation you don't want to configure the policy settings so tight that users are

locked out frequently for honest mistakes. For most computers I would

recommend using settings within the following parameters:


Account Lockout Threshold: A number between 3 and 5 should suffice to account

for honest mistakes and typographical errors.

Reset Account Lockout Counter After: Using a timeframe between 30 and 60

minutes is sufficient to deter automated attacks as well as manual attempts by an

attacker to guess a password.

Account Lockout Duration: Once the threshold is triggered and the account is

locked out you want to leave it locked long enough to block or deter any potential

attacks, but short enough not to interfere with productivity of legitimate users. A

lockout duration of 1 hour to 90 minutes should work well.

Maintaining the Active Directory environment

Active Directory forms the heart of Windows Server 2003. One of the keys to

making Windows Server 2003 really function well is to do a good job designing

and maintaining Active Directory. The problem for a new Windows

administrator, or one who is moving from Windows NT to Windows Server

2003, is how to go about designing an effective Active Directory structure.

Active Directory design

The philosophy behind a good Active Directory design doesn't differ very much

between Windows 2000 and Windows Server 2003. The best advice that I can

give anyone on organizing an Active Directory is to take into account both your

current needs and any growth that may occur in the foreseeable future.

Windows Server 2003 is very flexible in the ways that it allows you to

reorganize an Active Directory. However, the reorganization process tends to


be much easier if you have a good Active Directory design to start with.

Initial design considerations

When you initially begin designing your Active Directory structure, there are

several things that you need to consider. First, is there an existing network?

Second, if there is an existing network, is it Windows Server-based, and, if so

what version is being used?

Other important considerations include how many different locations your

company has and how many users are at each location. Finally, you also need

to think about who will be responsible for administering and maintaining each

portion of the network. Will the IT staff administer the entire thing centrally or

will some departments manage their own resources?

Preexisting networks

For the purposes of this article, I will assume that you don't have a network in

place yet and that you will be designing Active Directory structure from

scratch. If you do currently have a network in place, though, you can still use

most of my techniques. The biggest thing that you must remember is that as

you make the transition to an Active Directory environment, within each

Windows NT domain, the PDC must be the first domain controller to be

upgraded to Windows Server 2003. I also recommend carefully reading the

section on functionality levels later on.

Active Directory Integrated DNS


The first step in planning your Active Directory environment is to plan your

organization's DNS implementation. As you probably know, a DNS server

translates domain names and URLs into IP addresses. Without a DNS server,

domain names and URLs can't be resolved and, therefore, your computers will

have no idea how to contact other computers on your network or on the

Internet.

If you currently have Internet access, you may be confused as to how Internet

access can work when you don't have a DNS server. Normally, your ISP should

have a DNS server, and this server's address is entered into your computer's

TCP/IP configuration.

However, your ISP's DNS server is insufficient for running an Active Directory.

Not only is a DNS server an absolute requirement for Active Directory, the DNS

server that you use must be able to support Active Directory Integrated Zones.

This means that the DNS server must be running on either Windows 2000

Server or on Windows 2003 Server.

Because Windows requires a DNS server that supports Active Directory

Integrated Zones, the first domain controller that you bring online must also

double as a DNS server. For larger networks, you will eventually want to bring

one or more dedicated DNS servers online and then point all of your servers

and workstations at the dedicated DNS servers. However, if you have a smaller

network, then there's no reason in the world that you can't continue to run

the DNS services on your first domain controller.


The only way to really tell whether or not your domain controller will work as a

long term DNS server solution is to go ahead and install any other server

applications that may be required on the server and do some performance

monitoring. By using performance monitoring, you will be able to tell whether

or not the server has adequate resources for all of the workload being placed

on it.

Site planning

Once you have figured out which server will act as your first domain controller

and as a DNS server, the next step in the planning process is to plan your

organization's site structure. Implementing sites are a way of cutting down on

replication-related network traffic over slow WAN links. Generally, the site

structure should mimic your network's geographic boundaries. Each WAN link

should usually have a corresponding site link.

This doesn't necessarily mean that you have to go crazy creating a million sites,

though. Windows 2000 Server had a tendency to bog down after you created

about 200 sites. Windows Server 2003 has fixed this problem, but Microsoft

has actually started reducing the number of sites on their own network by

combining a lot of smaller sites to form a bigger site. Even so, I still think that

creating a site structure that mimics your WAN structure is a good idea.

The reason for this is that normally, when you make an administrative change

such as creating a user account, the change is written to a domain controller.


Through the process of replication, the domain controller must synchronize

that update with every other domain controller in the organization.

Imagine that you had a remote office with ten domain controllers. If someone

in the main office made a small administrative change, the change would have

to be written to each of the ten domain controllers in the remote location. This

means passing the exact same information over the WAN link ten different

times. Obviously, this doesn't make for an efficient use of bandwidth.

Now, suppose that you implemented a site between the two offices. When

you do, Windows designates one domain controller in each location as a

bridgehead server. When someone makes a change in the main office, the

change is replicated only to the servers in the main office.

The domain controller acting as the bridgehead for the main office collects the

changes and then sends them to the bridgehead server in the remote office at

a scheduled time. The remote office bridgehead then receives the changes and

distributes them to the domain controllers in the remote office.

This example is a little oversimplified, but, as you can see, the information

related to Active Directory update is only passed over the WAN link once as

opposed to ten times. Generally speaking, implementing sites works really

well. The biggest thing to remember is that you must have at least one domain

controller in each site.


Furthermore, if there are Windows 2000 domain controllers within a site, then

I recommend designating your bridgehead server to act as a global catalog

server. Otherwise, if the WAN link goes down, users within the disconnected

site may not be able to log in. If your domain controllers within the site are all

Windows Server 2003-based, then you won't experience this problem.

Domain structure planning

In Windows, a domain is simply a collection of user and computer accounts

that are often located in close geographic proximity and administered by a

common user or group. Domains are also completely independent of the site

structure. Normally, a site will span a WAN link, and it's also common for each

facility to use its own independent domain. This often gives the illusion that

the domain and the site structures are somehow related. The reality, though,

is that there is no reason why a domain can't span a site link.

It would be easy to write an entire article on domain planning, but since I have

a limited amount of space to work with, I will give you the basics of domain

design.

Normally, when you create a domain, the domain should reflect some type of

structure within your organization. It is common to base domains on users,

resources, or geographic proximity.

When a domain is based on geographic proximity, the domain will contain

both users and resources (such as computers, printers, file servers, etc.). A


geographic domain structure may relate to the company's physical location.

For example, you might have separate domains for offices in Miami, Las Vegas,

and New Orleans. However, geographic domains can exist on a much smaller

scale. For example, within an individual office you might have domains for

various departments, such as accounting, marketing, and sales.

In addition to geographic or departmental domains, you may also have

domains that are based on users or resources. I have seen several companies

in which all of the user accounts exist within one domain while all of the file

servers and printers exist within a separate domain. The idea behind this type

of organizational structure is that one administrative team can handle shared

resources while another only worries about managing user accounts.

To be perfectly honest, however, domain planning isn't nearly as important in

Windows Server 2003 and in Windows 2000 Server as it was in Windows NT.

Although domain planning is still important, much of the management that

previously occurred at the level is now performed at the OU level.

When I set up a network that is entirely Active Directory-based (no Windows

NT domain controllers), I tend to use a geographic domain model. The only

reason for this is because doing so greatly reduces the amount of replication-

related network traffic outside of an individual office or department. In the

end, though, every office is going to be different, and you really just have to

figure out what kind of domain plan makes sense for each individual company.


OU planning

The next Active Directory structure that I want to discuss is the Organizational

Unit or OU. An OU is yet another organizational structure within Active

Directory. An OU is independent of the organization's site structure, and exists

at the domain level. An OU provides a mechanism for better managing Users

And Computers within a domain.

To see how an OU works, imagine that there is a company with a thousand

users and all thousand users and their workstations exist within a single

domain. In the old days, it would have been a major hassle for the

administrative staff to manage such an organization. Password resets alone

would probably be a fulltime job. Of course, the administrative staff would

probably also have to deal with a lot of office politics. There is always at least

one department that seems to want to take control away from the IT staff and

manage the network themselves.

A few years back, this situation would have presented some major problems.

After all, imagine if the "problem department" took their case to the president

of the company and you were forced to turn over the administrative password

to the idiot who was running the department.

This is where OUs come into play. Suppose that the department that was

trying to take over the network was the finance department. In such a

situation, you could create an OU called Finance. You could then move all of

the user accounts and computer accounts that were related to the finance


department into this OU.

Now, rather than handing over the administrative password, you could simply

delegate someone from finance as having full permissions to administer that

OU. By doing so, you have kept the finance department and the president of

the company happy but have preserved the integrity of the network. If the

people in the finance department were to mess something up, their mistakes

would be limited to the OU that they have been delegated control over and

could not damage the rest of the network.

Although OUs are often created for the purpose of delegating authority, they

can be used as a mechanism for implementing a group policy as well. For

example, suppose that you had a group of computers that were publicly

accessible. You would probably want to apply a tighter security policy to these

computers than to the rest of the computers in the domain. In this situation,

you would want to create an OU and move those computers into it.

The reason is that Windows takes a hierarchical approach to security. Group

policies can be applied at the computer, site, domain, and OU levels. The

various group policies are combined to form the effective policy. Policy

settings in a higher-level group policy override settings in a lower-level policy.

Since the OU is the highest level, any settings that you apply to an OU will

override security settings applied elsewhere. As you can see, creating multiple

OUs and corresponding security policies allows you to implement tougher

security where it is needed most without overly restricting other areas of your


network.

Delegation

Now that you know what an OU is and have a general understanding of how it

works, I want to talk a bit about delegation. In my last example, I discussed the

possibility of creating a dedicated OU for the finance department and

delegating someone from finance control over the OU. However, delegation

isn't an all or nothing operation. There are various levels of delegation. In fact,

delegation doesn't necessarily even have to be applied to an OU.

When I was setting up my last example, I said that just handling password

resets for my fictitious organization would probably be a fulltime job. In

Windows NT, anyone who was responsible for resetting passwords required

administrative permissions. However, Windows 2000 and Windows 2003 allow

you to delegate the right to reset passwords to someone. That person will then

be able to reset passwords without having any other administrative authority

granted to him. The person's account has the same rights that it always did,

with the exception of being able to reset passwords.

Delegating authority is done through Active Directory Users And Computers

console. You can delegate authority either at the domain level or at the OU-

level. Simply right-click the desired location, and then select the All Tasks |

Delegate Control commands from the resulting shortcut menu. This will launch

a wizard that you can use to specify who you are delegating control to and

what level of control you wish to delegate.


Functional levels

Functional levels are another one of those topics that it would be easy to write

an entire article on, but I want to give you the Readers Digest version.

Basically, each version of Windows Server has its own capabilities. In an Active

Directory environment, the entire Active Directory's capabilities are limited by

the oldest operating system on a domain controller. For example, if you have a

Windows 2000 network, you won't be able to use universal groups and several

other features until all domain controllers are upgraded to Windows 2000 and

each domain has been switched to native mode.

In Windows 2000, native mode refers to a domain running entirely Windows

2000 domain controllers and mixed mode refers to a domain that also contains

Windows NT domain controllers.

In Windows 2003, the concept is extended a bit. The concept of mixed mode

and native mode still exists, but now it is called the functional level. In

Windows 2003, you can set the functional level to support NT, 2000, and 2003,

or just 2000 and 2003, or 2003 only. You can only use the Windows 2003 only

mode once all domains have been upgraded to Windows Server 2003. The

primary advantage of switching to the Windows Server 2003 functionality level

is that, after doing so, you will be able to rename domains.


Configure backup and recovery.

A good backup and recovery plan is important for any size environment. Windows

Server Backup is a feature in Windows Server 2008 R2 that provides a set of

wizards and other tools for you to perform basic backup and recovery tasks for

the server on which it is installed. Windows Server Backup consists of a Microsoft

Management Console (MMC) snap-in, command-line tools, and Windows

PowerShell commands that provide a complete solution for your day-to-day

backup and recovery needs. You can use Windows Server Backup to back up a full

server (all volumes), selected volumes, the system state, or specific files or

folders, and to create a backup that you can use to rebuild your system.

You can recover volumes, folders, files, certain applications, and the system state.

And, for disasters like hard disk failures, you can rebuild a system either from

scratch or by using alternate hardware. To do this, you must have a backup of the

full server or just the volumes that contain operating system files and the

Windows Recovery Environment. This restores your complete system onto your

old system or onto a new hard disk.

A key feature of Windows Server Backup is the ability to schedule backups to run

automatically.

Use the following procedure to set up the type of backup you require.

To configure backups using Windows Server Backup

1. At the command prompt, type mmc to open Microsoft Management

Console (MMC).

2. In the navigation pane, right-click the Windows Server Backup node.

3. Choose one of the following backup options:

o Backup Schedule


o Backup Once

4. Follow the prompts in the wizard.


Perform offline maintenance.

Compact the directory database file (offline defragmentation)

As part of the offline defragmentation procedure, check directory database

integrity.

Performing offline defragmentation creates a new, compacted version of the

database file in a different location. This location can be either on the same

computer or a network-mapped drive. However, to avoid potential problems

related to network issues, perform this procedure using a local mass storage

device. You can use locally attached external mass storage devices, such as

Universal Serial Bus (USB), IEEE 1394, and Serial Advanced Technology

Attachment (SATA), to provide additional disk space for defragmentation of the

database.

After you compact the file to the temporary location, copy the compacted

Ntds.dit file back to the original location. If possible, maintain a copy of the

original database file that you have either renamed in its current location or

copied to an archival location.

Note

To perform this procedure, the domain controller must be started in Directory

Services Restore Mode (DSRM).

Administrative Credentials

To perform this procedure, you must provide the Directory Services Restore

Mode password for the local administrator account. At the remote location, you

must have Read and Write permissions on the destination drive and the shared

folder.


Disk Space

Current database drive. Free space (on the drive that contains the

Active Directory database file) equivalent to at least 15 percent of the

current size of the database (Ntds.dit) for temporary storage during the

index rebuild process.

Destination database drive. Free space equivalent to at least the current

size of the database for storage of the compacted database file.

Note

These disk space requirements mean that if you compress the Active Directory

database on a single drive, you should have free space equivalent to at least

115 percent of the space that the current Active Directory database uses on that

drive.

To perform offline defragmentation of the directory database

1. In DSRM, compact the database file to a local directory or remote shared

folder, as follows:

o Local directory: Go to step 2.

o Remote directory: If you are compacting the database file to a

shared folder on a remote computer, establish a network connection

to the shared folder as shown below. Because you are logged on as

the local administrator, unless permissions on the shared folder

include the built-in Administrator account, you must provide a

domain name, user name, and password for a domain account that

has Write permissions on the shared folder. In the example below,

\\SERVER1\NTDS is the name of the shared folder, and K: is the drive

that you are mapping to the shared folder. After typing the first line

and pressing ENTER, you are prompted for the password. Type the

password and then press ENTER.


H:\>net use K: \\SERVER1\NTDS /user:domainName\userName *

Type the password for \\SERVER1\NTDS:

Drive K: is now connected to \\SERVER1\NTDS

The command completed successfully.

2. Type the following command at a command prompt, and then press ENTER:

ntdsutil

3. At the ntdsutil: prompt, type files, and then press ENTER.

4. At the file maintenance: prompt, type compact to drive:\

LocalDirectoryPath (where drive:\ LocalDirectoryPath is the path to a

location on the local computer), and then press ENTER.

If you have mapped a drive to a shared folder on a remote computer, type

the drive letter only (for example, compact to K:\).

Note

When compacting to a local drive, you must provide a path. If the path

contains any spaces, enclose the entire path in quotation marks (for

example, compact to "c:\new folder"). If the directory does not exist,

Ntdsutil.exe creates it and creates the file named Ntds.dit in that location.

5. If defragmentation completes successfully, type quit, and then press ENTER

to quit the file maintenance: prompt. Type quit again, and then press

ENTER to quit Ntdsutil.exe. Go to step 6. If defragmentation completes with

errors, go to step 9.


Caution

Do not overwrite the original Ntds.dit file or delete any log files.

6. If defragmentation succeeds with no errors, follow the Ntdsutil.exe

onscreen instructions to:

1. Delete all of the log files in the log directory by typing:

del drive:\pathToLogFiles\*.log

Note

You do not have to delete the Edb.chk file.

2. You should make a copy of the existing Ntds.dit file if at all possible, even if

you have to store that copy to a secured network drive. If the compaction of the

database does not work properly, you can then easily restore the database by

copying it back to the original location. Do not delete the copy of the Ntds.dit file

until you have at least verified that the domain controller starts properly. If space

allows, you can rename the original Ntds.dit file to preserve it or else copy it to a

different location. Avoid overwriting the original Ntds.dit file.

3. Manually copy the compacted database file to the original location,

as follows:

copy temporaryDrive:\ntds.dit

originalDrive:\pathToOriginalDatabaseFile\ntds.dit

7. Type ntdsutil and then press ENTER.

8. At the ntdsutil: prompt type files and then press ENTER.

9. At the file maintenance: prompt type integrity and then press ENTER.


If the integrity check fails, the likely cause is that an error occurred during

the copy operation in step 6.c. Repeat steps 6.c through step 9. If the

integrity check fails again:

o Contact Microsoft Product Support Services.

-or-

o Copy the original version of the Ntds.dit file that you preserved in

step 6.b. to the original database location and repeat the offline

defragmentation procedure.

10. If the integrity check succeeds, proceed as follows:

o If the initial compact to command failed, go back to step 4 and

perform steps 4 through 9.

o If the initial compact to command succeeded, type quit and presses

ENTER to quit the file maintenance: prompt, and then type quit and

press ENTER again to quit Ntdsutil.exe.

11. Restart the domain controller normally. If you are connected remotely

through a Terminal Services session, be sure that you have modified the

Boot.ini file for normal restarting before you restart the domain controller.

If errors appear when you restart the domain controller:

1. Restart the domain controller in Directory Services Restore Mode.

2. Check the errors in Event Viewer.

If the following events are logged in Event Viewer on restarting the domain

controller, respond to the events as follows:

o Event ID 1046. “The Active Directory database engine caused an

exception with the following parameters.” In this case, Active


Directory cannot recover from this error and you must restore from

backup media.

o Event ID 1168. “Internal error: An Active Directory error has

occurred.” In this case, information is missing from the registry and

you must restore from backup media.

3. Check database integrity and then proceed as follows:

If the integrity check fails, try repeating step 6.c through step 9 above, and

then repeat the integrity check. If the integrity check fails again:

o Contact Microsoft Product Support Services.

-or-

o Copy the original version of the Ntds.dit file that you preserved in

step 6.2. To the original database location and repeat the offline

defragmentation procedure.

If the integrity check succeeds, perform semantic database analysis

with fixup.

4. If semantic database analysis with fix up succeeds, quit Ntdsutil.exe and

restart the domain controller normally.

If semantic database analysis with fixup fails, contact Microsoft Product Support

Services.


Monitor Active Directory.

Monitoring the distributed Active Directory service and the services that it

relies upon helps maintain consistent directory data and the needed level of

service throughout the forest. You can monitor important indicators to

discover and resolve minor problems before they develop into potentially

lengthy service outages. Most large organizations with many domains or

remote physical sites require an automated monitoring system such as

Microsoft Operations Manager 2000 (MOM) to monitor important indicators.

An automated monitoring system provides the necessary consolidation and

timely problem resolution to administer Active Directory successfully.

Benefits for End-Users

Monitoring Active Directory helps resolve issues in a timely manner, and users

experience the following benefits:

Improved reliability of productivity applications that rely on back-end

servers, such as e-mail.

Quicker logon time and more reliable resource usage.

Decreased help desk support issues.

Benefits for Administrators

Monitoring Active Directory provides administrators with a centralized view of

Active Directory across the entire forest. By monitoring important indicators,

administrators can realize the following benefits:

Higher customer satisfaction, because issues can be resolved before users

notice problems.


Increased service levels, due to improved reliability and system

understanding.

Greater schedule flexibility and ability to prioritize workload, due to early

notification of problems, allowing resolution of issues while they are still a

lower priority.

Increased ability for the system to cope with periodic service outages.

Monitoring Active Directory also assures administrators that:

All necessary services that support Active Directory are running on each

domain controller.

Data is consistent across all domain controllers and end-to-end replication

completes in accordance with your service level agreements.

Lightweight Directory Access Protocol (LDAP) queries respond quickly.

Domain controllers do not experience high CPU usage.

The central monitoring console collects all events that can adversely affect

Active Directory.

Risks of not Monitoring Active Directory

Systematic monitoring is necessary to ensure consistent service delivery in a large

environment with many domain controllers, domains, or physical sites. As a

distributed service, Active Directory relies upon many interdependent services

distributed across many devices and in many remote locations. As you increase

the size of your network to take advantage of the scalability of Active Directory,

monitoring becomes more important. It helps you avoid potentially serious

problems, including:

Logon failure. Logon failure can occur throughout the domain or forest if a

trust relationship or name resolution fails, or if a global catalog server

cannot determine universal group membership.

Account lockout. User and service accounts can become locked out if the

PDC emulator is unavailable in the domain or replication fails between

several domain controllers.


Domain Controller failure. If the drive containing the Ntds.dit file runs out

of disk space, the domain controller stops functioning.

Application failure. Applications that are critical to your business, such as

Microsoft Exchange or another e-mail application, can fail if address book

queries into the directory fail.

Inconsistent directory data. If replication fails for an extended period of

time, objects (known as lingering objects and re-animated objects) can be

created in the directory and might require extensive diagnosis and time to

eliminate.

Account creation failure. A domain controller is unable to create user or

computer accounts if it exhausts its supply of relative IDs and the RID

master is unavailable.

Security policy failure. If the SYSVOL shared folder does not replicate

properly, Group Policy objects and security policies are not properly applied

to clients.

Levels of Monitoring

Use a cost-benefit analysis to determine the degree or level of monitoring that

you need for your environment. Compare the cost of formalizing a monitoring

solution with the costs associated with service outages and the time that is

required to diagnose and resolve problems that might occur. The level of

monitoring also depends on the size of your organization and your service level

needs.

Organizations with few domains and domain controllers, or that do not provide a

critical level of service, might only need to periodically check the health of a single

domain controller by using the built-in tools provided in Windows 2000 Server.

Larger organizations that have many domains, domain controllers, sites, or that

provide a critical service and cannot afford the cost of lost productivity due to a

service outage, need to use an enterprise-level monitoring solution such as MOM.


Enterprise-level monitoring solutions use agents or local services to collect the

monitoring data and consolidate the results on a central console. Enterprise-level

monitoring solutions also take advantage of the physical network topology to

reduce network traffic and increase performance. In a complex environment,

directory administrators need enterprise-level monitoring to derive meaningful

data and to make good decisions and analysis. For more information about MOM,

see

Active Directory Monitoring During the Deployment Phase

As a best practice, deploy monitoring with the first domain controller. By

integrating monitoring into the design and deployment process, you can avoid

many of the problems that arise during deployment. Because monitoring

solutions require network connectivity between the monitored servers and the

management consoles, you must account for particular TCP/IP ports and

bandwidth usage.

As with any sophisticated service, implement a monitoring solution such as MOM

in a lab before you deploy it in a production environment.

Service-Level Baseline

A baseline represents service level needs as performance data. By setting

thresholds to indicate when the baseline boundaries are exceeded, your

monitoring solution can generate alerts to inform the administrator of degraded

performance and jeopardized service levels. For example, you can use

performance indicators to set a baseline and monitor for low disk space on the

disk drives that contain the Active Directory database and log files, and you can

monitor CPU usage of a domain controller. You can also monitor critical services

running on a domain controller. Monitoring these indicators allows the

administrator to ensure adequate performance.

To determine an accurate baseline, monitor and collect data for a time period

that is long enough to represent peak and low usage. For example, monitor during


the time in the morning when the greatest number of users log on. Monitor for an

interval that is long enough to span your password change policy and any month-

end or other periodic processing that you perform. Also, collect data when

network demands are low to determine this minimal level. Be sure to collect data

when your environment is functioning properly. To accurately assess what is

acceptable for your environment, remove data caused by network outages or

other failures when you establish your baseline.

The baseline that you establish for your environment can change over time as you

add new applications, users, hardware, and domain infrastructure to the

environment, and as the expectations of users change. Over time, the directory

administrator might look for trends and changes that occur, and take actions

designed to meet the increased demands on the system and maintain the desired

level of service. Such actions might include fine-tuning the software configuration

and adding new hardware.

Determining the thresholds when alerts are generated to notify the administrator

that the baseline has been exceeded is a delicate balance between providing

either too much information or not enough. The vendor of your monitoring

solution, such as MOM, can provide general performance thresholds, but you

must periodically adjust these thresholds to meet your service level requirements.

To adjust these thresholds, first collect and analyze the monitoring data to

determine what is acceptable or usual activity for your environment. After you

gather a good data sample and consider your service level needs, you can set

meaningful thresholds that trigger alerts.

To determine thresholds:

For each performance indicator, collect monitoring data and determine the

minimum, maximum and average values.

Analyze the data with respect to your service level needs.

Adjust thresholds to trigger alerts when indicators cross the parameters for

acceptable service levels.


As you become more familiar with the monitoring solution you choose, it

becomes easier to correlate the thresholds that trigger the alerts to your service

level delivery. If you are uncertain, it is usually better to set the thresholds low to

view a greater number of alerts. As you understand the alerts you receive and

determine why you receive them, you can increase the threshold at which alerts

are generated, thereby reducing the amount of information that you receive from

your monitoring solution. MOM uses thresholds that are a reasonable starting

point and work for the majority of medium-sized customers. Larger organizations

might need to increase the thresholds.

Requirements for Monitoring

Managing an enterprise-level directory requires monitoring many important

indicators. Failure to monitor all of the important indicators can create gaps in

coverage. Use any monitoring solution that best suits your needs, but monitor the

necessary important indicators to ensure that all aspects of Active Directory are

functioning properly. MOM monitors all of the important indicators.

Relationship between Monitoring and Troubleshooting

The goal of a comprehensive monitoring solution is to monitor all of the

important indicators and provide alerts that are concise, highly relevant, and lead

an operator to resolve the problem. Ideally, the monitoring solution alerts the

operator only when a problem requires action. In this case, monitoring alerts are

the first indicator that a problem exists. If the operator cannot easily resolve the

problem that generated an alert, you might want to create a help desk ticket to

begin troubleshooting and root-cause analysis. Your monitoring solution can

initiate your troubleshooting processes or flowcharts.

Monitoring helps ensure that the Active Directory service is available for service

requests. Active Directory is designed to be fault tolerant and can continue to

operate if individual servers are unavailable for periodic maintenance or while

operators troubleshoot them. You can assure a high-degree of reliability by


monitoring the distributed services that make up Active Directory, and resolving

issues as they develop.

In addition to providing increased service availability, the relationship between

monitoring and troubleshooting increases your understanding of the root causes

of most problems that arise. As your environment becomes more reliable,

monitoring alerts more precisely indicate the cause of new problems that arise.

Reports

Many important problems do not cause alerts, but they still require periodic

attention. Your monitoring solution might generate reports that display data over

time and present patterns that indicate problems. Review the reports to resolve

issues before they generate alerts.

Frequency of Monitoring Tasks

You can perform the daily, weekly, and monthly tasks as specified in the following

tables, but you must adjust the frequency to meet the needs of your particular

environment and monitoring solution.

Daily Monitoring Tasks

Table 1.5 Daily Tasks and Their Importance

Tasks Importance

Verify that all domain controllers are

communicating with the central

monitoring console or collector.

Communication failure between the

domain controller and the monitoring

infrastructure prevents you from

receiving alerts so you can examine and

resolve them.

View and examine all new alerts on each

domain controller, resolving them in a

timely fashion.

This precaution helps you avoid service

outages.


Resolve alerts indicating the following

services are not running: FRS, Net Logon,

KDC, W32Time and ISMSERV. MOM

reports these as Active Directory

Essential Services.

Active Directory depends on these

services. They must be running on every

domain controller.

Resolve alerts indicating SYSVOL is not

shared.

Active Directory cannot apply Group

Policy unless SYSVOL is shared.

Resolve alerts indicating that the domain

controller is not advertising itself.

Domain controllers must register DNS

records to be able to respond to LDAP

and other service requests.

Resolve alerts indicating time

synchronization problems.

The Kerberos authentication protocol

requires that time be synchronized

between all domain controllers and

clients that use it.

Resolve all other alerts in order of

severity. If alerts are given error,

warning, and information status similar

to the event log, resolve alerts marked

error first.

The highest priority alerts indicate the

most serious risk to your service level..

Weekly Monitoring Tasks

Table 1.6 Weekly Tasks and Their Importance

Tasks Importance

Review the Time Synchronization Report

to detect intermittent problems and

resolve time-related alerts.

The Kerberos authentication protocol

requires that time be synchronized

between all domain controllers and

clients that use it.

Review the Authentication Report to

help resolve problems generated by

Expired passwords must be reset to

allow the computers to authenticate


computer accounts with expired

passwords.

and participate in the domain.

Review the Duplicate Service Principal

Name Report to list all security principals

that have a service principal name

conflict.

User or computer accounts cannot be

authenticated or log on if they share an

SPN with another account.

Review a report of the top alerts

generated by the Active Directory

monitoring indicators and resolve those

items that occur most frequently.

Report shows alerts that occur most

often. Focusing on the top alert

generators significantly reduces the

number of alerts seen by the operator.

Review the report that lists all trust

relationships in the forest and check for

obsolete, unintended, or broken trusts.

Authentication between domains or

forests requires trust relationships.

Monthly Monitoring Tasks

Table 1.7 Monthly Tasks and Their Importance

Tasks Importance

Verify that all domain controllers are

running with the same service pack and

hot fix patches.

Potential issues can arise if distributed

services are running with different

versions of software.

Review all Active Directory reports and

adjust thresholds as needed. Examine each

report and determine which reports, data,

and alerts are important for your

environment and service level agreement.

Examining the data that is relevant to

your environment allows you to

determine the thresholds that trigger

the alerts to your service level

delivery.

Review the Replication Monitoring Report

to verify that replication throughout the

forest occurs within acceptable limits

Timely replication helps assure that

you meet your service level

agreements.

Review the Active Directory response time

reports.

Services must respond quickly for the

system to function properly and


applications such as e-mail to work

properly.

Review the domain controller disk space

reports.

The drives containing the Active

Directory database and log files must

have sufficient free space to

accommodate growth and routine

processing.

Review all performance-related reports.

These reports are called Health Monitoring

reports in MOM.

These reports can help you determine

the baseline for your environment

and adjust thresholds.

Review all performance-related reports for

capacity planning purposes to ensure that

you have enough capacity for current and

expected growth. These reports are called

Health Monitoring reports in MOM.

These reports help you track growth

trends in your environment and plan

for future hardware and software

needs.

Adjust performance counter thresholds or

disable rules that are not applicable to

your environment or that generate

irrelevant alerts.

Monitoring indicators must be

adjusted to suit your environment.

The goal is to provide alerts that are

concise, highly relevant, and lead an

operator to resolve the problem.


Configuring Active Directory Certificate Services

This step-by-step guide describes the steps needed to set up a basic configuration

of Active Directory® Certificate Services (AD CS) in a lab environment.

AD CS starting in Windows Server® 2008 provides customizable services for

creating and managing public key certificates used in software security systems

that employ public key technologies.

Important

By installing Active Directory Certificate Services (AD CS), you are either creating

or extending a Public Key Infrastructure (PKI). A PKI that meets the requirements

of most organizations is a multi-tier Certification Authority (CA) hierarchy that

implements an Offline Root CA

(http://social.technet.microsoft.com/wiki/contents/articles/2900.aspx). For more

information, see PKI Design Brief Overview

(http://social.technet.microsoft.com/wiki/contents/articles/pki-design-brief-

overview.aspx). Additional step-by-step information is available in the TechNet

Wiki article AD CS and PKI Step-by-Steps, Labs, Walkthroughs, HowTo, and

Examples (http://social.technet.microsoft.com/wiki/contents/articles/4797.aspx).

This document includes:

A review of AD CS features

Requirements for using AD CS

Procedures for a basic lab setup to test AD CS on a minimum number of

computers

Procedures for an advanced lab setup to test AD CS on a larger number of

computers to more realistically simulate real-world configurations

AD CS Technology Review

http://social.technet.microsoft.com/wiki/contents/articles/2900.aspx

http://social.technet.microsoft.com/wiki/contents/articles/pki-design-brief-overview.aspx




Using the Active Directory Certificate Services option of the Add Roles Wizard,

you can set up the following components of AD CS:

Certification authorities (CAs). Root and subordinate CAs are used to issue

certificates to users, computers, and services, and to manage their validity.

CA Web enrollment. Web enrollment allows users to connect to a CA by

means of a Web browser in order to:

o Request certificates and review certificate requests.

o Retrieve certificate revocation lists (CRLs).

o Perform smart card certificate enrollment.

Online Responder service. The Online Responder service implements the

Online Certificate Status Protocol (OCSP) by decoding revocation status

requests for specific certificates, evaluating the status of these certificates,

and sending back a signed response containing the requested certificate

status information.

Important

Online Responders can be used as an alternative to or an extension of CRLs

to provide certificate revocation data to clients. Microsoft Online

Responders are based on and comply with RFC 2560

Network Device Enrollment Service. The Network Device Enrollment

Service allows routers and other network devices to obtain certificates

based on the Simple Certificate Enrollment Protocol (SCEP) from Cisco

Systems Inc.

Note


SCEP was developed to support the secure, scalable issuance of certificates

to network devices by using existing CAs. The protocol supports CA and

registration authority public key distribution, certificate enrollment,

certificate revocation, certificate queries, and certificate revocation

queries.

Requirements for Using AD CS

CAs can be set up on servers running a variety of operating systems, including

Windows® 2000 Server, Windows Server® 2003, Windows Server 2008. Windows

Server® 2008 R2. However, not all operating system versions support all features

or design requirements, and creating an optimal design requires careful planning

and lab testing before you deploy AD CS in a production environment. Although

you can deploy AD CS with as little hardware as a single server for a single CA,

many deployments involve multiple servers configured as root, policy, and issuing

CAs, and other servers configured as Online Responders.

Note

A limited set of server roles is available for a Server Core installation of Windows

Server 2008 and for Windows Server 2008 for Itanium-based Systems.

The following table lists the AD CS components that can be configured on

different editions of Windows Server 2008.

Components Web Standard Enterprise Datacenter

CA No Yes Yes Yes

Network Device Enrollment Service No No Yes Yes

Online Responder service No No Yes Yes


The following features are available on servers running Windows Server 2008 that

have been configured as CAs.

AD CS features Web Standard Enterprise Datacenter

Version 2 and version 3 certificate

templates No No Yes Yes

Key archival No No Yes Yes

Role separation No No Yes Yes

Certificate Manager restrictions No No Yes Yes

Delegated enrollment agent restrictions No No Yes Yes

AD CS Basic Lab Scenario

The following sections describe how you can set up a lab to begin evaluating

AD CS.

We recommend that you first use the steps provided in this guide in a test lab

environment. Step-by-step guides are not necessarily meant to be used to deploy

Windows Server features without accompanying documentation and should be

used with discretion as a stand-alone document.

Steps for Setting up a Basic Lab

You can begin testing many features of AD CS in a lab environment by using as

few as two servers running Windows Server 2008 and one client computer

running Windows Vista®. The computers for this guide are named as follows:

Test_DC1: This computer will be the domain controller for your test

environment.


TEST_PKI1: This computer will host an enterprise root CA for the test

environment. This CA will issue client certificates for the Online Responder

and client computers.

Note

Enterprise CAs and Online Responders can only be installed on servers running

Windows Server 2008 Enterprise or Windows Server 2008 Datacenter.

TEST_CLI1: This client computer running Windows Vista will autoenroll for

certificates from TEST_PKI1 and verify certificate status from TEST_ PKI1.

To configure the basic lab setup for AD CS, you need to complete the following

prerequisite steps:

Set up a domain controller on TEST_DC1 for contoso.com, including some

organizational units (OUs) to contain one or more users for the client

computer, client computers in the domain, and for the servers hosting CAs

and Online Responders.

Install Windows Server 2008 on TEST_PKI1, and join TEST_PKI1 to the

domain.

Install Windows Vista on TEST_CLI1, and join TEST_CLI1 to contoso.com.

After you have completed these preliminary setup procedures, you can begin to

complete the following steps:

Step 1: Setting Up an Enterprise Root CA

Step 2: Installing the Online Responder

Step 3: Configuring the CA to Issue OCSP Response Signing Certificates

Step 4: Creating a Revocation Configuration

http://technet.microsoft.com/en-us/library/cc772393%28v=WS.10%29.aspx#BKMK_AS1





Step 5: Verifying that the AD CS Lab Setup Functions Properly

Step 1: Setting Up an Enterprise Root CA

An enterprise root CA is the anchor of trust for the basic lab setup. It will be used

to issue certificates to the Online Responder and client computer, and to publish

certificate information to Active Directory Domain Services (AD DS).

Note



To set up an enterprise root CA

1. Log on to TEST_PKI1 as a domain administrator.

2. Click Start, point to Administrative Tools, and then click Server Manager.

3. In the Roles Summary section, click Add roles.

4. On the Select Server Roles page, select the Active Directory Certificate

Services check box. Click Next two times.

5. On the Select Role Services page, select the Certification Authority check

box, and then click Next.

6. On the Specify Setup Type page, click Enterprise, and then click Next.

7. On the Specify CA Type page, click Root CA, and then click Next.

8. On the Set Up Private Key and Configure Cryptography for CA pages, you

can configure optional configuration settings, including cryptographic

service providers. However, for basic testing purposes, accept the default

values by clicking Next twice.

9. In the Common name for this CA box, type the common name of the CA,

RootCA1, and then click Next.



10. On the Set the Certificate Validity Period page, accept the default validity

duration for the root CA, and then click Next.

11. On the Configure Certificate Database page, accept the default values or

specify other storage locations for the certificate database and the

certificate database log, and then click Next.

12. After verifying the information on the Confirm Installation Options page,

click Install.

13. Review the information on the confirmation screen to verify that the

installation was successful.

Step 2: Installing the Online Responder

An Online Responder can be installed on any computer running Windows

Server 2008 Enterprise or Windows Server 2008 Datacenter. The certificate

revocation data can come from a CA on a computer running Windows

Server 2008, a CA on a computer running Windows Server 2003, or from a non-

Microsoft CA.

Note

IIS must also be installed on this computer before the Online Responder can be

installed.

To install the Online Responder

1. Log on to TEST_PKI1 as a domain administrator.

2. Click Start, point to Administrative Tools, and then click Server Manager.

3. Click Manage Roles. In the Active Directory Certificate Services section,

click Add role services.

4. On the Select Role Services page, select the Online Responder check box.


You are prompted to install IIS and Windows Activation Service.

5. Click Add Required Role Services, and then click Next three times.

6. On the Confirm Installation Options page, click Install.

7. When the installation is complete, review the status page to verify that the

installation was successful.

Step 3: Configuring the CA to Issue OCSP Response Signing Certificates

Configuring a CA to support Online Responder services involves configuring

certificate templates and issuance properties for OCSP Response Signing

certificates and then completing additional steps on the CA to support the Online

Responder and certificate issuance.

Note

These certificate template and autoenrollment steps can also be used to

configure certificates that you want to issue to a client computer or client

computer users.

To configure certificate templates for your test environment

1. Log on to TEST_PKI1 as a CA administrator.

2. Open the Certificate Templates snap-in.

3. Right-click the OCSP Response Signing template, and then click Duplicate

Template.

4. Type a new name for the duplicated template, such as OCSP Response

Signing 2.

5. On the Security tab, under Group or user name, click Add to open the

Select Users, Computers or Groups dialog box.

6. Click Object Types, select the Computers check box, and then click OK.


7. Enter the name of the computer hosting the Online Responder service,

TEST_PKI1, and click OK.

8. On the Security tab, under Group or user name, select the computer name,

TEST_PKI1, and in the Permissions box, select the Read, Enroll, and

Autoenroll check boxes.

9. While you have the Certificate Templates snap-in open, you can configure

certificate templates for users and computers by substituting the desired

templates in step 3, and repeating steps 4 through 7 to configure

permissions for TEST_CLI1 and your test user accounts.

To configure the CA to support Online Responders, you need to use the

Certification Authority snap-in to complete two key steps:

Add the location of the Online Responder to the authority information

access extension of issued certificates.

Enable the certificate templates that you configured in the previous

procedure for the CA.

To configure a CA to support the Online Responder service

1. Open the Certification Authority snap-in.

2. In the console tree, click the name of the CA.

3. On the Action menu, click Properties.

4. Click the Extensions tab. In the Select extension list, click Authority

Information Access (AIA), and then click Add.

5. In the Location box, type http://test_pki1/ocsp, and click OK.

6. In the Select extension list, click the location you entered, and then select

the Include in the online certificate status protocol (OCSP) extension

check box. Click OK, and then click Yes to restart AD CS.

7. After AD CS has restarted, in the console tree of the Certification Authority

snap-in, right-click Certificate Templates, and then click New Certificate

Templates to Issue.


8. In the Enable Certificate Templates dialog box, select the duplicate OCSP

Response Signing 2 template you created previously. Select any other

certificate templates that you configured previously, and then click OK.

9. In the console tree, click Certificate Templates, and verify that the modified

certificate templates appear in the list.

Step 4: Creating a Revocation Configuration

A revocation configuration includes all of the settings that are needed to respond

to status requests regarding certificates that have been issued by using a specific

CA key.

These configuration settings include the CA certificate, the signing certificate for

the Online Responder, and the locations to which clients are directed to send

their status requests.

To manually force enrollment for the signing certificate (Optional)

1. Start or restart TEST_PKI1 to enroll for certificates.

Important

The Group Policy settings for the domain must have an autoenrollment

policy enabled. Use the Group Policy Management Console (GPMC) to

verify the Certificate Services Client – Autoenrollment setting in Computer

Configuration\Policies\Software Settings\Windows Settings\Security

Settings\Public Key Policies. Verify that Configuration Mode is set to

Enabled and that the Renew expired certificates and Update certificates

check boxes are selected

2. Log on to the Online Responder computer as a CA administrator.


3. Open the Certificates snap-in for the computer account. Open the Personal

certificate store for the computer, and verify that it contains a certificate

with the intended purpose of OCSP Signing.

4. Right-click this certificate, and then click Manage Private Keys.

5. Click the Security tab. In the User Group or user name dialog box, click

Add, enter Network Service to the Group or user name list, and then click

OK.

6. Click Network Service, and in the Permissions dialog box, select the Full

Control check box.

7. Click OK.

Creating a revocation configuration involves the following tasks:

Identify the CA certificate for the CA that supports the Online Responder.

Identify the CRL distribution point for the CA.

Select a signing certificate that will be used to sign revocation status

responses.

Select a revocation provider, the component responsible for retrieving and

caching the revocation information used by the Online Responder.

To create a revocation configuration

1. Open the Online Responder snap-in.

2. In the Actions pane, click Add Revocation Configuration to start the Add

Revocation Configuration wizard, and then click Next.

3. On the Name the Revocation Configuration page, type a name for the

revocation configuration, such as TEST_RC1, and then click Next.

4. On the Select CA certificate Location page, click Select a certificate from an

existing enterprise CA, and then click Next.


5. On the Choose CA certificate page, click Browse CA certificates published

in Active Directory, and then click Browse. The name of the CA, TEST_PKI1,

should appear in the Select Certification Authority dialog box.

o If it appears, click the name of the CA that you want to associate with

your revocation configuration, and then click OK.

o If it does not appear, click Cancel, and on the Choose CA Certificate

page, click Browse for a CA by Computer name, type TEST_PKI1 (the

name of the computer hosting the Online Responder), and then click

OK.

o After choosing a CA certificate, click Next.

Note

You can also select the CA certificate from the local certificate store

or import it from removable media in step 4.

6. On the Select Signing Certificate page, accept the default option,

Automatically select signing certificate, and select the Autoenroll for an

OCSP signing certificate check box.

Note

With this option selected, the Online Responder will obtain the certificate

automatically from the issuing CA. This is necessary if you skipped the

optional step to manually force enrollment for the signing certificate.

7. Click Browse to open the Select Certification Authority dialog box, click the

CA that issues OCSP Signing certificates, and then click OK.

8. Ensure that the Certificate Template box displays the duplicate OCSP

Response Signing template that you created previously, and then click

Next.

9. On the Revocation Provider page, click Provider.


10. In the Revocation Provider Properties dialog box, verify that all locations in

the Base CRLs list are valid, and then click OK.

11. Click Finish.

12. Using the Online Responder snap-in, select the revocation configuration,

and then examine the status information to verify that it is functioning

properly. You should also be able to examine the properties of the signing

certificate to verify that the Online Responder is configured properly.

Step 5: Verifying that the AD CS Lab Setup Functions Properly

You can verify the setup steps described previously as you perform them.

After the installation is complete, you should verify that your basic test setup is

functioning properly by confirming that you can autoenroll certificates, revoke

certificates, and make accurate revocation data available from the Online

Responder.

To verify that the AD CS test setup functions properly

1. On the CA, configure several certificate templates to autoenroll certificates

for TEST_CLI1 and users on this computer.

2. When information about the new certificates has been published to AD DS,

open a command prompt on the client computer and enter the following

command to start certificate autoenrollment:

certutil -pulse

3. On TEST_CLI1, use the Certificates snap-in to verify that the certificates

have been issued to the user and to the computer, as appropriate.

4. On the CA, use the Certification Authority snap-in to view and revoke one

or more of the issued certificates by clicking Certification Authority


(Computer)/CA name/Issued Certificates and selecting the certificate you

want to revoke. On the Action menu, point to All Tasks, and then click

Revoke Certificate. Select the reason for revoking the certificate, and click

Yes.

5. In the Certification Authority snap-in, publish a new CRL by clicking

Certification Authority (Computer)/CA name/Revoked Certificates in the

console tree. Then, on the Action menu, point to All Tasks, and click

Publish.

6. Remove all CRL distribution point extensions from the issuing CA by

opening the Certification Authority snap-in and then selecting the CA. On

the Action menu, click Properties.

7. On the Extensions tab, confirm that Select extension is set to CRL

Distribution Point (CDP).

8. Click any CRL distribution points that are listed, click Remove, and then click

OK.

9. Stop and restart AD CS.

10. Repeat steps 1 and 2 above, and then verify that clients can still obtain

revocation data. To do this, use the Certificates snap-in to export the

certificate to a file (*.cer). At a command prompt, type:

certutil -url <exportedcert.cer>

11. In the Verify and Retrieve dialog box that appears, click From CDP and

From OCSP and compare the results.

AD CS Advanced Lab Scenario

The following sections describe how you can set up a lab to evaluate more

features of AD CS than in the basic lab setup.

Steps for Setting Up an Advanced Lab


To test additional features of AD CS in a lab environment, you will need five

computers running Windows Server 2008 and one client computer running

Windows Vista. The computers for this guide are named as follows:

TEST_DC1: This computer will be the domain controller for your test

environment.

TEST_CA_ROOT1: This computer will host a stand-alone root CA for the test

environment.

TEST_CA_ISSUE1: This enterprise CA will be subordinate to

TEST_CA_ROOT1 and issue client certificates for the Online Responder and

client computers.

Note



TEST_ORS1. This server will host the Online Responder.

TEST_NDES. This server will host the Network Device Enrollment Service

that makes it possible to issue and manage certificates for routers and

other network devices.

TEST_CLI1: This client computer running Windows Vista will autoenroll for

certificates from TEST_CA_ISSUE1 and verify certificate status from

TEST_ORS1.

To configure the advanced lab setup for AD CS, you need to complete the

following prerequisite steps:

1. Set up a domain controller on TEST_DC1 for contoso.com, including some

OUs to contain one or more users for TEST_CLI1, client computers in the

domain, and for the servers hosting CAs and Online Responders.


2. Install Windows Server 2008 on the other servers in the test configuration

and join them to the domain.

3. Install Windows Vista on TEST_CLI1, and join TEST_CLI1 to contoso.com.


Install Active Directory Certificate Services.

Install and configure Microsoft Active Directory Certificate Services (AD CS) using

Windows Server 2008 R2

Microsoft Active Directory Certificate Services (AD CS) in the Windows Server 2008 provides customizable services for creating and managing public key (PKI) certificates. You can use AD CS to enhance and implement security by binding the identity of a person, device, computers or services to a corresponding private key. AD CS also includes features that allow you to manage certificates enrolment and revocation if necessary. Applications supported by AD CS include Secure/Multipurpose Internet Mail Extensions (S/MIME), secure wireless networks, virtual private network (VPN), Internet Protocol security (IPsec), Encrypting File System (EFS), smart card logon, Secure Socket Layer/Transport Layer Security (SSL/TLS), and digital signatures.

Standard hardware works for windows 2008 AD CS server. Depending on individual needs and capacity of spending, you may virtualise or use separate AD CS server. If you have more then one domain controller, you can configure one of them as CS server. It doesn’t hurt anybody. AD CS requires Windows Server 2008/2003 and Active Directory 2008/2003 Domain Services (AD DS). Here, I am going to talk about Windows 2008 AD CS. Although AD CS can be deployed on a single server, many deployments will involve multiple servers configured as CAs, other servers configured as Online Responders, and others serving as Web enrollment portals. Creating an optimal design will require careful planning and testing before you deploy AD CS in a production environment. Microsoft Windows XP, Windows 7 and Apple Mac OSX 10.5.x (Key Chain) can request and enrol in Microsoft Enterprise certificates.

Features in AD CS

By using Administrative Tool>Server Manager in windows server 2008, you can set up the following components of AD CS:

Certification authorities (CA) Root and subordinate CAs are used to issue certificates to users, computers, and services, and to manage certificate validity.

Web Enrollment Web enrolment (http://servername/certsrv) allows users to connect to a CA

by means of a Web browser in order to request certificates.


Online Responder. The Online Responder service decodes revocation status requests for

specific certificates, evaluates the status of these certificates, and sends back a signed response

containing the requested certificate status information.

Network Device Enrollment Service. The Network Device Enrollment Service allows routers and

other network devices that do not have domain accounts to obtain certificates.

.

http://araihan.files.wordpress.com/2009/10/1.jpg























Upgrading or Migrating Active Directory Certificate Services

Individual will have different situation while upgrading or migrating certificate services to

existing server or new server respectively. But there are common tasks involve during this

process. they are:

ry cleanup (If you change host name)upgrading Active Directory CS in existing server.

Steps required:







from 2008 standard to 2008 enterprise otherwise not)DC+CA situation. If you intend to demote your

domain controller, however existing Certificate Authority is installed in DC. you want to move CA in

separate domain member. Steps required:

p

Performing a CA BackupTo use the Certification Authority snap-in to create a backup of the

CA database and, optionally, the CA certificate and private key

p location and attach media, if necessary.

-in.

-click the node with the CA name, point to All Tasks, and then click Back Up CA.

he Welcome page of the CA Backup wizard, click Next.

certificate database log check boxes, enter the backup location, and then click Next.

elect a Password page, enter a password to protect the CA private key, and click Next.

Exporting Registry Configuration

\SYSTEM\CurrentControlSet\Services\CertSvc, right-click Configuration, and

then click Export.

configuration information for your CA.Migrating CA to a Windows 2008 Server


Start, click Run, type servermanager.msc, and then press ENTER to open Server Manager.

Roles.

On the Action menu, click Add Roles.

Next.

Active Directory Certificate Services check box, and click

Next twice.

Certification Authority is selected, and click Next.

-alone CA, and click Next.

Root or Subordinate CA, depending on the source CA, and click Next.

Use the second option for a migration.

To create a new CA certificate and key, select Create a new private key.

For a migration, on the Set Up Private Key page, select Use existing private key.

Select a certificate and use its associated private key, and click Next.

Certificates box.

Otherwise, click Import to import a certificate from the .pfx file created by exporting the CA certificate

and private key from the source CA.

Browse, and locate and select the file containing the certificate and private key exported from

the source CA.

http://araihan.files.wordpress.com/2009/10/migrate.jpg


password you selected when exporting the CA certificate and key from the source CA, and

click OK.

Yes to accept the warning to overwrite AD DS. (This appears only if you are installing an

enterprise CA.)

the distinguished name suffix, and click Next.

ificate generated on the CA, and click

Next. Otherwise, skip this step.

Next.

directly to the CA, and click Next.

Install.

Restoring the CA Database

To import the CA database from the source CA to the target CA by using the Certification

Authority snap-in

-in.

-click the node with the CA name, point to All Tasks, and then click Restore CA. Click OK to

confirm stopping the CA service.

Welcome page, click Next.

Items to Restore page, select Certificate database and certificate database log. Click Browse,

and navigate to the location of the Database folder that contains the CA database export files created

when you previously exported the CA database.

requested.

Finish, and then click Yes to confirm restarting the CA.

To import the registry settings from the .reg file to the target CA

-in to stop the CA service.


-click the .reg file previously edited to open the Registry Editor.

previous steps

tion Authority snap-in to verify the following settings. Right-click the

node with the CA name, and click Properties.

Managing AD CS

AD CS role services are managed by using Microsoft Management Console (MMC) snap-ins.

· To manage a CA, use the Certification Authority snap-in. To open Certification Authority, click

Start, click Run, type mmc, click File, click Add/Remove Snap-in, click Certification Authority,

click Add, click OK, and then double-click Certification Authority.

· To manage certificates, use the Certificates snap-in. To open Certificates, click Start, click Run,

type mmc, click File, click Add/Remove Snap-in, click Certificates, click Add, click OK, and then

double-click Certificates.

· To manage certificate templates, use the Certificate Templates snap-in. To open Certificate

Templates, click Start, click Run, type mmc, click File, click Add/Remove Snap-in, click Certificate

Templates, click Add, click OK, and then double-click Certificate Templates.

· To manage an Online Responder, use the Online Responder snap-in. To open Online

Responder, click Start, click Run, type mmc, click File, click Add/Remove Snap-in, click Online

Responder, click Add, click OK, and then double-click Online Responder.

Certificate Services Command References

To run all these you must log on to CA as administrator and open command prompt

Backup Cert database certutil –backupdbBackupDirectory

backup private key certutil -f –backupkeyBackupDirectory

determine the CSP and hash algorithm certutil -getreg ca\csp\*


Query the list of serial numbers of all certificates that have an archived key associated with

them.

certutil -view -restrict “KeyRecoveryHashes>0″ -outSerialNumber | findstr /C:”SerialNumber:

” >sn.txt

To convert the binary large object files created in the step above into .pfx files

for %i in (*.bin) do certutil -p YourPassword -recoverkey %i %i.pfx

Disable web enrolment after uninstalling cert srv

certutil -vroot delete

Shutdown CA certutil –shutdown

Find Database location certutil -databaselocations

restore db certutil –F –restoredbBackupDirectory

Assign templete certutil –setcatemplates +templatelist

enable the use of version 2 and version 3 certificates on an upgraded enterprise CA

certutil -setreg ca\setupstatus +512

net stop certsvc

net start certsvc

Resetting the CRL Publishing Period

certutil –delreg CA\CRLNextPublish

certutil –delreg CA\CRLDeltaNextPublish

restore encryption keys

certutil –setreg ca\KRAFlags +KRAF_ENABLEFOREIGN

Certificate database and log file location


%WINDIR%\system32\certlog and %WINDIR%\system32\certsrv


Configure CA server settings.

Setting Up a Certificate Authority

[This topic covers a procedure for working with the XML digital signatures

support implemented in MSXML 5.0 for Microsoft Office Applications. XML digital

signatures are not supported in MXSML 6.0 and later.]

To request a digital certificate, you must either create a certificate authority (CA)

or have access to one. For testing purposes, you might want to set up a private

certificate authority to issue certificates for code signing. The following steps

outline the procedure for doing this on a Windows 2000 Server or Windows

Server 2003 machine.

To set up a certificate authority (CA)

1. Select a Windows 2000 Server or Windows Server 2003 machine to host the

CA.

2. From the CA host, open Control Panel.

3. Double click Add/Remove Programs.

4. Click Add/RemoveWindows Components.

5. Check Certificate Services and then click Next.

6. On the Certification Authority Types page of the wizard, select Stand-alone

root CA. Also check the Advanced options box, and then click Next.

7. On the Public and Private Key Pair page, highlight "Microsoft Enhanced

Cryptographic Provider v1.0". You might want to set "1024" as the value in

the Key length drop-down box. Click Next.

8. On the CA Identifying Information page, fill out the blanks as appropriate.

Click Next.

9. On the Data Storage Location page, use the default locations. Click Next.

10. Click Finish.


Configuring Certificate Authority Server Settings

The CA server you use can be owned and operated by an independent CA or by

your own organization. If you use an independent CA, you must contact them for

the addresses of their CA and CRL servers (for obtaining certificates and certificate

revocation lists), and for the information they require when submitting certificate

requests. When you are your own CA, you determine this information yourself.

On the ScreenOS Enforcer, you can use the Web UI to configure CA server

settings. Select Objects > Certificates and navigate to the proper certificate.

You can configure the following options:

X509 Certificate Path Validation Level: Within X509 is a specification for a

certificate that binds an entity's distinguished name to its public key

through the use of a digital signature. Select Full to validate the certificate

path all the way back to the root, or select Partial to validate it only part of

the way. The CRL distribution point extension (.cdp) in an X509 certificate

can be either an HTTP URL or an LDAP URL.

Certificate Revocation Check settings:

o CRL (Certificate Revocation List): Enables the Juniper security device

to use only the CRL to check the certificate status.

o OCSP (Online Certificate Status Protocol): Enables the Juniper

security device to use only OCSP to check the certificate status.

o None: Disables CRL certificate checking. If you are not using CRL

certificate checking, be sure to disable it in the CA Server Settings

dialog box.

o Best Effort: Enables the Juniper security device to use CRL to check

the certificate status. If there is no indication that the certificate is

revoked, accept the certificate.

CRL settings:

o URL Address: Specifies the internal Web-based URL of the LDAP

server managing your CRL.


o LDAP Server: Specifies the IP address or domain name of the LDAP

Root CA server that manages the CRL.

o Refresh Frequency: Applies only to the CRL only. From the list, select

whether you want to update the CRL daily, weekly, monthly, or

according to the default setting (which updates the CRL shortly after

the next scheduled update).

OCSP settings:

o URL Address: Specifies the internal Web URL of the OCSP server.

o Advanced Settings: Specifies a CA with which the Juniper security

device verifies the OCSP response.

SCEP (Simple Certificate Enrollment Protocol) settings:

o RA CGI (registration authority certificate generation information):

Specifies the RA URL where the Juniper security device will request a

CA certificate.

o CA CGI (certificate authority certificate generation information):

Specifies the CA URL.

o CA IDENT: Specifies the name of the CA for purposes of certificate

ownership, if necessary.

o Challenge: Specifies the challenge word sent to you by the CA that

prove your identity to the CA.

o Advanced Settings: Configures Advanced SCEP settings, such as

polling interval and certificate authentication.


Manage enrollment

The administrator of a certification authority (CA) can manage certificate

enrollment by:

Configuring certificate enrollment and autoenrollment options on

certificate templates. For more information, see Issuing Certificates Based

on Certificate Templates (http://go.microsoft.com/fwlink/?LinkId=142333).

Enabling certificate autoenrollment options in Group Policy. For more

information, see Configure Certificate Autoenrollment.

Configuring the default request handling options for the CA. For more

information, see Set the Default Action Upon Receipt of a Certificate

Request.

Note

You can specify whether a stand-alone CA will hold incoming certificate

requests as pending or automatically issue the certificate. In most cases, for

security reasons, all incoming certificate requests to a stand-alone CA

should be marked as pending.

Selecting whether to allow certificates to be published to the file system.

Actual publication will only occur if the certificate request specifies a file

system location where the certificate is to be published. For more

information, see Publish Certificates to the File System.

Evaluating and acting on pending certificate requests. For more

information, see Review Pending Certificate Requests.


Configure Certificate Autoenrollment

Many certificates can be distributed without the client even being aware that

enrollment is taking place. These can include most types of certificates issued to

computers and services, as well as many certificates issued to users.

To automatically enroll clients for certificates in a domain environment, you must:

Configure a certificate template with Autoenroll permissions. For more

information, see Issuing Certificates Based on Certificate Templates (

Configure an autoenrollment policy for the domain.

Membership in Domain Admins or Enterprise Admins, or equivalent, is the

minimum required to complete this procedure. For more information, see

To configure autoenrollment Group Policy for a domain

1. On a domain controller running Windows Server 2008 R2 or Windows

Server 2008, click Start, point to Administrative Tools, and then click Group

Policy Management.

2. In the console tree, double-click Group Policy Objects in the forest and

domain containing the Default Domain Policy Group Policy object (GPO)

that you want to edit.

3. Right-click the Default Domain Policy GPO, and then click Edit.

4. In the Group Policy Management Console (GPMC), go to User

Configuration, Windows Settings, Security Settings, and then click Public

Key Policies.

5. Double-click Certificate Services Client - Auto-Enrollment.

6. Select the Enroll certificates automatically check box to enable

autoenrollment. If you want to block autoenrollment from occurring, select

the Do not enroll certificates automatically check box.

7. If you are enabling certificate autoenrollment, you can select the following

check boxes:


o Renew expired certificates, update pending certificates, and

remove revoked certificates enables autoenrollment for certificate

renewal, issuance of pending certificate requests, and the automatic

removal of revoked certificates from a user's certificate store.

o Update certificates that use certificate templates enables

autoenrollment for issuance of certificates that supersede issued

certificates.

8. Click OK to accept your changes.


Manage certificate revocations.

In windows server 2008 the certificates are usually revoked because of the following reasons.

When the Key has been compromised

In the event when the certification authority (CA) issues a compromised certificate

When the certificate is not valid any longer or for the intended purpose

When the certificate has been superseded by another certificate

When a client does not qualify for the certificate any more.

It is important to note that the basic requirement for you to manage the certificate revocation begins by you being a Certification Authority. This is a vital requirement for the windows server 2008.

Implementing the Role Based Administration

You can use role-based administration to organize certification authority (CA)

administrators into separate, predefined CA roles, each with its own set of tasks.

Roles are assigned by using each user's security settings. You assign a role to a

user by assigning that user the specific security settings that are associated with

the role. A user that has one type of permission, such as Manage CA permission,

can perform specific CA tasks that a user with another type of permission, such as

Issue and Manage Certificates permission, cannot perform.

The following table describes the roles, users, and groups that can be used to

implement role-based administration. To assign a role to a user or group, you


must assign the role's corresponding security permissions, group memberships, or

user rights to the user or group. These security permissions, group memberships,

and user rights are used to distinguish which users have which roles.

Roles and

groups Security

permission Description

CA administrator

Manage CA

Configure and maintain the CA. This is a CA role and includes the ability to assign all other CA roles and renew the CA certificate. These permissions are assigned by using the Certification Authority snap-in.

Certificate manager

Issue and Manage Certificates

Approve certificate enrollment and revocation requests. This is a CA role. This role is sometimes referred to as CA officer. These permissions are assigned by using the Certification Authority snap-in.

Backup operator

Back up file and directories

Restore file and directories

Perform system backup and recovery. Backup is an operating system feature.

Auditor Manage auditing and security log

Configure, view, and maintain audit logs. Auditing is an operating system feature. Auditor is an operating system role.

Enrollees Read

Enroll

Enrollees are clients who are authorized to request certificates from a CA. This is not a CA role.

All CA roles are assigned and modified by members of local Administrators, Enterprise Admins, or Domain Admins. On enterprise CAs, local administrators, enterprise administrators, and domain administrators are CA administrators by default. Only local administrators are CA administrators by default on a stand-alone CA. If a stand-alone CA is installed on a server that is joined to an Active Directory domain, domain administrators are also CA administrators.


The CA administrator and certificate manager roles can be assigned to Active Directory users or local users in the Security Accounts Manager (SAM) of the local computer, which is the local security account database. As a best practice, you should assign roles to group accounts instead of individual user accounts.

Only CA administrator, certificate manager, auditor, and backup operator are CA roles. The other users described in the table are relevant to role-based administration and should be understood before assigning CA roles.

Only CA administrators and certificate managers are assigned by using the Certification Authority snap-in. To change the permissions of a user or group, you must change the user's security permissions, group membership, or user rights.

To set CA administrator and certificate manager security permissions for a CA

1. Open the Certification Authority snap-in. 2. In the console tree, click the name of the CA. 3. On the Action menu, click Properties. 4. Click the Security tab, and specify the security permissions.

Roles and activities

Each CA role has a specific list of CA administration tasks associated with it. The following table lists all the CA administration tasks along with the roles in which they are performed.

Activity CA

administrator Certificate

manager Auditor

Backup

operator Local

administrator Notes

Install CAs X

Configure policy and exit modules

X

Stop and start the Active Directory

X


Certificate Services (AD CS) service

Configure extensions

X

Configure roles

X

Renew CA keys

X

Define key recovery agents

X

Configure certificate manager restrictions

X

Delete a single row in the CA database

X

Delete multiple rows in the CA database (bulk deletion)

X X

The user must be both a CA administrator and a certificate manager. This activity cannot be performed when role separation is enforced.

Enable role separation

X

Issue and approve

X


certificates

Deny certificates

X

Revoke certificates

X

Reactivate certificates that are placed on hold

X

Renew certificates

X

Enable, publish, or configure certificate revocation list (CRL) schedules

X

Recover archived keys

X

Only a certificate manager can retrieve the encrypted key data structure from the CA database. The private key of a valid key recovery agent is required to decrypt the key data structure and generate a PKCS #12 file.

Configure X By default, the


audit parameters

local administrator holds the system audit user right.

Audit logs X

By default, the local administrator holds the system audit user right.

Back up the system

X

By default, the local administrator holds the system backup user right.

Restore the system

X

By default, the local administrator holds the system backup user right.

Read the CA database

X X X X

By default, the local administrator holds the system audit and system backup user rights.

Read CA configuration information

X X X X

By default, the local administrator holds the system audit


and system backup user rights.

Additional considerations

Enrollees are allowed to read CA properties and CRLs, and they can request certificates. On an enterprise CA, a user must have Read and Enroll permissions on the certificate template to request a certificate. CA administrators, certificate managers, auditors, and backup operators have implicit Read permissions.

An auditor holds the system audit user right.

A backup operator holds the system backup user right. In addition, the backup operator has the ability to start and stop the Active Directory Certificate Services (AD CS) service.

Assigning roles

The CA administrator for a CA assigns users to the separate roles of role-based administration by applying the security settings required by a role to the user's account. The CA administrator can assign a user to more than one role, but the CA is more secure when each user is assigned to only one role. When this delegation strategy is used, fewer CA tasks can be compromised if a user's account becomes compromised.

Administrator concerns

The default installation setting for a stand-alone CA is to have members of the

local Administrators group as CA administrators. The default installation setting

for an enterprise CA is to have members of the local Administrators, Enterprise

Admins, and Domain Admins groups as CA administrators. To limit the power of

any of these accounts, they should be removed from the CA administrator and

certificate manager roles when all CA roles are assigned.

As a best practice, group accounts that have been assigned CA administrator or

certificate manager roles should not be members of the local Administrators

group. Also, CA roles should only be assigned to group accounts and not individual

user accounts.


You must be a CA administrator or certificate manager to complete this

procedure.

To revoke a certificate


2. In the console tree, click Issued Certificates.

3. In the details pane, click the certificate you want to revoke.

4. On the Action menu, point to All Tasks, and click Revoke Certificate.

5. Select the reason for revoking the certificate, adjust the time of the

revocation, if necessary, and then click Yes.

The following reason codes are available:

Unspecified

Key Compromise

CA Compromise

Change of Affiliation

Superseded

Cease of Operation

Certificate Hold

If you specify "Certificate Hold" as the reason for revoking the certificate, it

typically means that you may want to unrevoke the certificate at a future time.

Only certificates that have been revoked with the reason of "Certificate Hold" can

be unrevoked.

You must be a CA administrator or certificate manager to complete this

procedure.

To unrevoke a certificate



2. In the console tree, click Revoked Certificates.

3. In the details pane, click the certificate you want to unrevoke.

4. On the Action menu, point to All Tasks, and click Unrevoke Certificate.

5. Select the reason for unrevoking the certificate, adjust the time of the

revocation, if necessary, and then click Yes.

To be meaningful, certificate revocation must be combined with the publication

and distribution of certificate revocation data.

A certificate manager can approve certificate enrollment and revocation requests, issue certificates, and manage certificates. This role can be configured by assigning a user or group the Issue and Manage Certificatespermission.

When you assign this permission to a user or group, you can further refine their ability to manage certificates by group and by certificate template. For example, you might want to implement a restriction that they can only approve requests or revoke smart card logon certificates for users in a certain office or organizational unit that is the basis for a security group.

This restriction is based on a subset of the certificate templates enabled for the certification authority (CA) and the user groups that have Enroll permissions for that certificate template from that CA.

You must be a CA administrator or a member of Enterprise Admins, or equivalent, to complete this procedure. For more information, see

To configure certificate manager restrictions for a CA

1. Open the Certification Authority snap-in, and right-click the name of the CA.

2. Click Properties, and then click the Security tab. 3. Verify that the user or group that you have selected has Issue and Manage

Certificates permission. If they do not yet have this permission, select the Allow check box, and then click Apply.

4. Click the Certificate Managers tab.


5. Click Restrict certificate managers, and verify that the name of the group or user is displayed.

6. Under Certificate Templates, click Add, select the template for the certificates that you want this user or group to manage, and then click OK. Repeat this step until you have selected all certificate templates that you want to allow this certificate manager to manage.

7. Under Permissions, click Add, type the name of the client for whom you want the certificate manager to manage the defined certificate types, and then click OK.

8. If you want to block the certificate manager from managing certificates for a specific user, computer, or group, under Permissions, select this user, computer, or group, and click Deny.

9. When you are finished configuring certificate manager restrictions, click OK or Apply.


Examination Questions for Practice

These are some of the exam questions that have been discussed and answered in other websites. They are a reflection of the kind of question s that you should expect in your 70-640 exams.

Question 1

Objective: Maintaining the Active Directory Environment Sub-Objective: Configure backup and recovery

Single Answer, Multiple Choices

You are the systems administrator for your company. You install Windows Server 2008 on a computer and configure it as a file server, named FileSrv. The FileSrv computer contains four hard disks that are configured as basic disks. You want to configure Redundant Array of Independent Disks (RAID) 0+1 on FileSrv for performance and fault tolerance of data.

To achieve this, you need to convert the basic disks in FileSrv to dynamic disks. Which command should you use?

A. Diskpart.exe B. Chkdsk.exe C. Fsutil.exe D. Fdisk.exe

Answer:

A. Diskpart.exe

Tutorial: You should use the Diskpart.exe command. RAID is commonly implemented for both performance and fault tolerance. There are various RAID levels that you can choose from to provide fault tolerance, performance or both. RAID 0 uses disk striping and offers the fastest read and write performance, but it does not offer any fault tolerance. If a single disk in a RAID 0 array is lost, all data is lost and will need to be recovered


from backup. RAID 1 uses disk mirroring with two disks. This configuration produces slow writes, but relatively quick reads, and it provides a means to maintain high data availability on servers because a single disk can be lost without any loss of data. RAID 0+1 combines RAID 0 and RAID 1 and offers the performance of RAID 0 and the fault tolerance of RAID 1. To be able to configure RAID 0+1, you must have dynamic disks. If your disks are configured as basic disks, you can convert them to dynamic disks with the Diskpart.exe utility. The Diskpart utility enables a superset of the actions that are supported by the Disk Management snap-in. You can use the Diskpart convert dynamic command to change a basic disk into a dynamic disk.

The Chkdsk.exe command cannot be used to convert a basic disk to dynamic disk. Chkdsk.exe is a command-line utility that creates and displays a status report for a disk based on the file system. The Chkdsk utility also lists and corrects errors on the disk.

You should not use the Fsutil.exe command. Fsutil.exe is a command-line utility that can be used to perform many FAT and NTFS file system related tasks, such as managing reparse points, managing sparse files, dismounting a volume or extending a volume. The Fsutil utility cannot be used to convert a basic disk to dynamic disk.

The Fdisk.exe command cannot be used to convert a basic disk to dynamic disk. Fdisk.exe is a command-line utility that can be used to partition a hard disk. You can use the Fdisk utility to create, change, delete or display current partitions on the hard disk and to assign a drive letter to each allocated space on the hard disk.

Source http://www.certmag.com/read.php?in=3197

Question 2

Windows Server 2008 Active Directory, Configuring

Self Test Software Practice Test

Objective: Create and maintain Active Directory objects.

Sub-objective: Configure GPO templates.

http://www.certmag.com/read.php?in=3197


Single answer, multiple-choice

You are the network administrator of your company. All servers on the network

run Windows Server 2008. The company's network consists of a single Active

Directory domain, and the client computers all run Windows Vista.

You create some custom ADMX language-specific files on your Windows Vista

administrative workstation. You want to copy all language-specific ADML files to

the central store on the domain controller to ensure the ADML files are

automatically available to all Group Policy administrators in the domain. Which

tool can you use to perform this task?

A. Ntdsutil.exe.

B. Group Policy Object Editor.

C. Xcopy.exe.

D. Group Policy Management Console.

Answer:

C. Xcopy.exe.

Tutorial:

You can use the Xcopy.exe tool to copy ADML files from your Windows Vista

administrative workstation to the central store on the domain controller. The

ADMX files are language-neutral resource files. The other type of registry-based

policy settings are known as ADML files, which are language-specific resource

files. ADMX and ADML files replace the ADM files that were used in earlier

versions of Windows. To ensure ADMX files are recognized by Group Policy tools,

such as GPMC and Group Policy Object Editor, you must be running a Windows

Vista-based or Windows Server 2008-based computer. ADMX files are not stored

in individual Group Policy Objects (GPOs).

If you have a domain environment, you can create a central store location of

ADMX files that can be accessed by anyone with permission to create or edit

GPOs. The central store is a folder created in the SYSVOL folder of an Active


Directory domain controller and is used to provide a centralized storage location

for ADMX and ADML files for the domain. In addition to storing the ADMX files

shipped in the operating system in the central store, you also can share a custom

ADMX file by copying the file to the central store, which makes it automatically

available to all Group Policy administrators in a domain. The default location for

.ADML files on a domain controller is the

%systemroot%sysvoldomainpoliciesPolicyDefinitions[MUIculture] folder. For

example, the United States English ADMX language-specific file will be stored in

the %systemroot%sysvoldomainpoliciesPolicyDefinitionsen-us folder.

Windows Vista does not contain any user interface for populating the central

store in Windows Vista. You can use the Xcopy.exe command-line tool to copy all

ADMX language resource files from your Windows Vista administrative

workstation to the central store on your domain controller. You should use the

following syntax: xcopy %systemroot%PolicyDefinitionsEN-US*

%logonserver%sysvol%userdnsdomain%policiesPolicyDefinitionsEN-US

The options stating Ntdsutil.exe, Group Policy Object Editor and Group Policy

Management Console are incorrect because these tools cannot be used to copy

all ADMX language resource files from your Windows Vista administrative

workstation to the central store on your domain controller.

Date post:	21-Jul-2016
Category:	Documents
Upload:	karthikrajdg
View:	14 times
Download:	2 times