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

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: Its 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 its
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 havent 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 its 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 doesnt
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, routers
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
Lets 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 its 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. Its about security incompatibility between NT4 and 2008/2008R2,
so lets 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 dont 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. Its 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 its 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.
Its 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 dont 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 doesnt exist right now, dont 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, thats 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 its 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, its 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 companys 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, lets 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, Ill 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.

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.

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.

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.

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 rightnow lets 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.

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. Lets go further and say that Pat attempts to authenticate
to the dev.corp.com domain by specifying his/her user principal name (UPN) of
pat@core.corp.com.
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 domains domain
directory partition. Thus, the Global Catalog can resolve Active Directory name
references across the entire multi-domain forestisnt that great?
To return to the previous scenario, when our user Pat submits his/her
pat@core.corp.com 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 groups 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 cant
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
environments 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 users universal group membership(s)
to a local domain controller during that users first logon. After the initial lookup
to the remote Global Catalog server, subsequent logons wont require that
communication with the GC except during refresh intervals.
We enable UGMC in a site by modifying the properties of a sites 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

domains 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
domains 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.

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?


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).

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 directoryrather than a database, flat file,
or other data storage structureto 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 directorysuch 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 installationAD FS is included in Windows Server 2008 as a
server role, and there are new server validation checks in the installation
wizard.
Improved application supportAD 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 partnersin this case, initiated by the
administrator in the account partner organizationcan 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 pageswhich are
prepopulated as a result of the policy importare 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 pageswhich are prepopulated as
a result of the policy importare 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
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

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 users
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 softwares 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 organizations 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 packages 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 packages 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 users 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

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

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 doesnt 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.
.




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.

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
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.

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.

70 640

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

70 640

Hochgeladen von

Copyright:

Verfügbare Formate

PRACTICE TO PERFECT MCITP 70-640 TRAINING COURSE

Das könnte Ihnen auch gefallen