MCITP Windows Server 2008 Course

Practice 2 Perfect

MCITP 70-640

Windows

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:

Course Outline

PART 1

Configuring Domain Name System (DNS) for Active Directory







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

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

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.

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.



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



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.

when the computer attempts to update its record, and when

other network services attempt a fresh.



Record update: This occurs when a dynamic update is processed

and other characteristics are modified in addition to its time

stamp.



Scavenging servers: It’s possible to restrict scavenging to a

specific list of DNS servers, identified by their IP address.

Aging and scavenging can be described as features that are

available for DNS and are only useful when you are deploying

your server with primary zones. DNS console can alternatively

be used to perform similar tasks for the DNS server and other

directory integrated zones. There are a number of things that

can be done with the scavenging and the configuration settings

can be set as follows;

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

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

DNS server.

3. Modify the no-refresh interval, either as a server default or by

specifying an overriding value at selected zones.

4. Modify the refresh interval, either as a server default or by

specifying an overriding value at selected zones.

5. Specify whether periodic scavenging occurs automatically at the

DNS server for any of its eligible zones, and how often these

operations are repeated.

7. View other related properties, such as the time stamp for

individual resource records or the start scavenging time for a

specified zone.

Normally only dynamically updated records are configured to be

scavenged because in most cases when you configure a static record it’s

for a server that is going to be sharing resources for a relatively long

time. By default static records are given a time stamp of zero which

exempts them from aging and scavenging. You can change this by

modifying the records individually to permit them to use a current time

stamp instead.

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

1. Right-click on the zone and select Properties.

2. Click Aging on the General tab of the dialog box.

3. Select the Scavenge stale resource records check box.

4. Modify the other properties as appropriate.

To configure aging and scavenging for a zone from a command prompt

enter the following command:

dnscmd

<ServerName>

/Config

<ZoneName>

{/Aging

<Value>|/RefreshInterval <Value>|/NoRefreshInterval <Value>}



External trusts: These one-way trusts are individual trust

relationships set up between two domains in different forests, as

can be done in Windows 2000. The forests involved may be

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.

Configure Zone Transfers and Replication.

Configuring Zone Transfers and Replication

Zone transfers were once the most common way to replicate DNS database updates between servers, in recent years other replication mechanisms have become increasingly popular. There are two types of zone transfers: full and incremental. The DNS Server service in Windows Server 2008 supports zone transfers as well as AD DS replication. This section explorers each of these features.

Configuring Zone Transfers

A full zone transfer is fairly simple, the client, also called the “secondary” or “slave” server requests a copy of the zone from the server, also called the “primary” or “master.” The transfer initiates with the SOA resource record. Since the serial number of the SOA RR is incremented each time there is a change to the zone the client can compare the serial number for the

current version of the SOA with its own copy, if they are identical then the client concludes that there haven’t been any changes to the zone and the transfer is terminated. If the serial

numbers differ the client requests all of the remaining records for the zone. An incremental zone transfer differs in that the client sends its own copy of the SOA RR to the server, the server then compares the serial number with that of its own copy and only sends changes that have occurred since that version of the SOA RR.

Active Directory-integrated zones rely on AD DS for replication between domain controllers; whenever feasible it’s the preferred method. However, when file-based zone transfers are used incremental zone transfers consume less network bandwidth than full transfers and therefore they are the next best choice. For this reason the DNS Server service in Windows Server 2008 requests incremental zone transfers when retrieving a zone from a primary server. To configure zone transfers using DNS Manager do the following:

1. Right-click on the desired zone, and then select Properties. 2. Click the Zone Transfers tab.

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

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

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

Configuring the Active Directory infrastructure

Configure a Forest or a Domain.

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.

Production architecture could be as complex as the example, or even more complex, or it could be a simple as a single domain within a single forest. What is suitable will vary from one organization to another, however designing an

optimum domain and forest structure is beyond the scope of this book, review the references section at the end of the chapter. for resources on exploring this topic. Each domain has at least one domain controller (DC) that hosts the AD DS database, best practices dictate that each domain have at least two DCs to provide redundancy in case one of them fails. There are several additional roles assigned to DCs, these are discussed later in this chapter. The objects and

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

Active Directory Objects.

Configuring a forest root domain on Windows Server 2008 R2

This scenario is suitable mostly for test environments because it is very rarely that someone wants to do that in production (because it already exists). But of course, maybe you start creating domain environment for new company which doesn’t have it. Then this article is also for you.

This article describes only single forest, single domain scenario. We need some details before we will start configuration.

 _{Company name - which will be helpful in choosing forest/domain name}  Network configuration - valid IP addresses range for our company, router’s

IP (as default gateway)

 ISP DNS servers on any public DNS servers - to be able to access the Internet resources from our company

 Services we need to run - what additional services will be required to fulfill a company requirements

Let’s start to prepare them all.

 Network configuration – IP addresses range 192.168.1.0/24; the last available IP address is a router (default gateway)

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

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

Now, we can install our first Windows Server 2008 R2 and configure it. After that we will be able to promote this box as a Domain Controller.

When our server is installed, then we need to log on there on local administrator account and we can start its preparation.

Open Network Card configuration and set up static IP address for your server (in this case it’s 192.168.1.1 with 255.255.255.0 network mask)

This is very important part of network configuration before promoting server as a Domain Controller. In DNS preferred IP address type 127.0.0.1 (loopback interface) or the same IP address as server is configured 192.168.1.1 to point the server to DNS itself.

Network card configuration

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

You should see Active Directory Domain Services Installation wizard. Select “Use advanced mode installation” checkbox and follow with its instructions.

Active Directory Installation wizard

OS security incompatibility warning

At this point, we have to choose what we want to do with domain configuration. As this article is about forest root domain, we don’t have to consider another option, now. We are creating completely new domain in a new forest.

A forest root domain creation

You will see a window with question about forest root domain name. It’s good to set up name related with your company. This is so called FQDN (Fully Qualified Domain Name or also known as DNS Domain Name). Create internal domain name to separate it from your external (if it would be necessary, i.e. for e-mail) with .local or .private suffix. These suffixes suggest that DNS domain is for local resources and this is also connected with your local DNS zone name.

DNS domain name

now, specify NetBIOS domain name

NetBIOS domain name

Now, you need to choose Forest Functional Level

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

This is very important step in forest/domain configuration. This setting determines which operating systems can be promoted to Domain Controllers. As we are configuring the only single forest/domain environment it is not so difficult.

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

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

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

When you change DFL to Windows Server 2008 then only Windows Server 2008 and 2008 R2 can be promoted to be DCs. And the last choice is Windows Server 2008 R2 – the only possible operating system for Domain Controllers is Windows Server 2008 R2.

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

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

If you have more than one domain in a forest then you have to evaluate which one work in the lowest mode. The lowest Domain Functional Level in a forest determines the highest Forest Functional Level.

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

older operating system than it’s specified in FFL.

If your FFL is set up to Windows Server 2003 that means, all of Domain Controllers in a forest are based on at least Windows Server 2003.

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

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

mode, so be careful when you choose them. If you are not sure which functional level is adequate for you, choose the lower one. You can always raise it without any business continuity disruption later.

As we don’t want to use older OSes as DCs, we plan to use only Windows Server 2008 R2, we can change Forest Functional Level to Windows Server 2008 R2. Domain Functional Level will be set up on the same level automatically.

Forest Functional Level

This is our first domain and first Domain Controller, so we need to also set up new internal DNS server to be able to use Active Directory. Whole Active Directory services rely on DNS services, so they have to be always available.

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

DNS warning

Specify Active Directory database, logs location (you can leave defaults, those files are not so huge and if server act as AD,DNS only, that’s enough space)

Active Directory files location

Set up password for Directory Services Restoration Mode which will be used in case of non-authoritative/authoritative restore or other AD database maintenance. This password should be different than Domain Administrator password and should be also changed regularly.

DSRM password

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

Summary screen

After all, server reboot it’s required. You can do it manually, or select “Reboot on completion” checkbox and wait until promotion will be done

Active Directory:Directory Services installation

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

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

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.

Configure Trusts.

How to configure a DNS forwarder

DNS forwarders are necessary to get forest level trust relationships working

properly. Users can forward DNS between the two forests in the trust relationship in order to speed up lookups between the organizations and to allow them to act as one. This way, any domain on one side of the trust may access any resource on the other. A DNS forwarder is a server that receives requests for lookup from another server. For example, your company’s DNS server may have no idea who www.google.com actually is because it is not on your network. The request is sent to a forwarder on the Internet to resolve the name.

Follow these steps to configure a DNS forwarder:

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

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

2. In the console tree pane, open the Properties sheet for the DNS server you want to configure by right-clicking the server name and selecting

Properties.

3. Click the Forwarders tab.

4. Specify the domain names that require queries to be forwarded by clicking the New button and entering the DNS name for the domain. In this case, enter the domain for the fictitious partner company Cogswell Cogs.

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

6. Click Add.

7. Click OK to close the Forwarders tab.

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.

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.

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

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.

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.

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

Within each site we have one or more subnet objects that denote the areas of high-speed connectivity within each campus.

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

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

objectGuid: d2e3badd-e07a-11d2-b573-0000f87a546b Last attempt @ 1999-05-03 18:07.05 was successful. DC=support,DC=microsoft,DC=com

Redmond\DC2 via RPC

objectGuid: d2e3badd-e07a-11d2-b573-0000f87a546b Last attempt @ 1999-05-03 18:07.09 was successful.

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

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

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) If result=0 then MsgBox "Completed successfully." else MsgBox "Failed"

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)

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

If result=0 then MsgBox "Completed successfully." else MsgBox "Failed" 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

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

applications, such as Microsoft Exchange Server, also rely upon the Global Catalog for AD name resolution.

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

core.corp.com needs to access resources to which he has permissions in the dev.corp.com domain. Let’s go further and say that Pat attempts to authenticate to the dev.corp.com domain by specifying his/her user principal name (UPN) of [email protected].

In the absence of a Global Catalog, the domain controllers in dev.corp.com have absolutely no knowledge of who pat is, and thus authentication fails.

The bottom line, friends, is that domain controllers within a single domain contain a full, read/write copy of their own domain directory partition. The domain

partition contains all of the “good stuff” in Active Directory such as user names, group names, group memberships, and shared resources.

In a multidomain environment, domain controllers still have a copy of only their own domain directory partition. However, a domain controller that is also a Global Catalog will contain a read/only copy of every other domain’s domain directory partition. Thus, the Global Catalog can resolve Active Directory name references across the entire multi-domain forest—isn’t that great?

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

[email protected] UPN to a domain controller in dev.corp.com, that request results in a query to the GC in that domain. Because the Global Catalog contains directory information from core.corp.com, the user is identified and the

authentication process succeeds.

Before you even think about registering to take the 70-640 exam, please ensure that you are very comfortable with all of technologies and procedures that are referenced in this subobjective:

 Partial Attribute Sets

 Promotion to Global Catalog

Universal Group Membership Caching (UGMC)

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

 _{Directory information lookup}

 User principal name authentication

 _{Intra-forest object validation}

The notion of the universal group touches upon all three of these points. First of all, recall that the universal group’s scope is forest-wide and therefore universal groups are relevant only in multi-domain forests.

Second, we should know that the membership of universal groups for users throughout the entire forest is propagated to the Global Catalog. This means that domain logons will fail if a Global Catalog cannot be contacted. After all, we can’t very well authenticate a an Active Directory user without knowing which, if any, universal groups the user belongs to, right?

The potential problem with this Global Catalog presence requirement is that your environment’s Active Directory site topology might be such that a site does not have a local Global Catalog server and that the nearest one is located on the other side of a slow and/or expensive WAN link. What are we going do in this case? Enter Universal Group Membership Caching (UGMC) as a solution. UGMC does nothing else but force the storage of each user’s universal group membership(s) to a local domain controller during that user’s first logon. After the initial lookup to the remote Global Catalog server, subsequent logons won’t require that communication with the GC except during refresh intervals.

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

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)

domain’s domain directory partitions, but also a read/only copy of the domain directory partition from all other domains in the forest? Well, a GC would be pretty darned overburdened if it had to track every single schema attribute for every object in every domain.

To solve this issue, a Global Catalog tracks a partial attribute set (PAS) of each domain’s domain directory partition. In other words, while GCs do contain a reference to every single AD object in every domain, they store only selected schema attributes that Microsoft feels are most commonly searched for by users and applications.

The good news is that forest administrators can include additional schema attributes for use in the Global Catalog. For instance, your organization might have a line-of-business (LOB) application that extended the AD schema with new attributes. The forest admin would need to manually add the relevant new

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

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

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

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.

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

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

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

What does AD LDS do?

AD LDS gives organizations flexible support for directory-enabled applications. A directory-enabled application uses a directory—rather than a database, flat file, or other data storage structure—to hold its data. Directory services (such as AD LDS) and relational databases both provide data storage and retrieval, but they differ in their optimization. Directory services are optimized for read processing, whereas relational databases are optimized for transaction

processing. Many off-the-shelf applications and many custom applications use a directory-enabled design. Examples include:

 Customer relationship management (CRM) applications

 _{Human Resources (HR) applications}  Global address book applications

AD LDS provides much of the same functionality as AD DS (and, in fact, is built on the same code base), but it does not require the deployment of domains or domain controllers.

You can run multiple instances of AD LDS concurrently on a single computer, with an independently managed schema for each AD LDS instance or configuration set (if the instance is part of a configuration set). Member servers, domain

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

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

 Multimaster replication

 Support for the Active Directory Service Interfaces (ADSI) application programming interface (API)

 LDAP over Secure Sockets Layer (SSL)

AD LDS differs from AD DS primarily in that it does not store Windows security principals. While AD LDS can use Windows security principals (such as domain users) in access control lists (ACLs) that control access to objects in AD LDS, Windows cannot authenticate users stored in AD LDS or use AD LDS users in its ACLs. In addition, AD LDS does not support domains and forests, Group Policy, or global catalogs.

Who will be interested in AD LDS?

Organizations that have the following requirements will find AD LDS particularly useful:

 Application-specific directories that use customized schemas or that depend on decentralized directory management

AD LDS directories are separate from the domain infrastructure of AD DS. As a result, they can support applications that depend on schema

extensions that are not desirable in the AD DS directory—such as schema extensions that are useful to a single application. In addition, the local server administrator can administer the AD LDS directories; domain administrators do not need to provide administrative support.

 Directory-enabled application development and prototyping environments that are separate from the enterprise's domain structure

Application developers who are creating directory-enabled applications can install the AD LDS role on any server, even on stand-alone servers. As a result, developers can control and modify the directory in their

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

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

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

 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 Are there any special considerations?

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

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

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

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

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}

 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