Tài liệu Windows Server 2008 Inside Out- P23 ppt

Over time, Windows Server 2008 replicates the changes made to Active Directory on one domain controller to all domain controllers as necessary.. This has the following advantages: No Ac

OU Design: Geographic Model

With a geographic model, you use OUs to refl ect geographic location In this model, top-level OUs represent the largest geographic units, such as continents, and the lower-level OUs represent successively smaller geographic units, such as countries (see Fig ure 31-3)

There are several advantages to this model A geographic structure is fairly stable

Many companies reorganize internally frequently, but only rarely change geographic structure Additionally, when you use a geographic model, it is easy to determine where accounts and resources are physically located

The disadvantages to this model have to do with its scope For a global company, this design would put all accounts and resources in a single domain As a result, changes made to Active Directory at any location would be replicated to every offi ce loca-tion Additionally, the OU structure doesn’t relate to the business structure of the organization

cpandl.com

Figure 31-3 The geographic model

OU Design: The Cost Center Model

With a cost center model, you use OUs to refl ect cost centers In this model, top-level OUs represent the major cost centers within the organization and the lower-level OUs represent geographic locations, projects, or business structures, as shown in Figure 31-4 In a company where budget is the top priority, the cost center model may be an effective way to refl ect this priority Cost centers could also be independent divisions or business units within the company that have their own management and cost controls

cohowinery.com

Figure 31-4 The cost center model

The ability to represent costs and budgets in this way is a defi nite advantage but could also be a disadvantage Cost center structure is not a structure well known to most administrators, and it may be confusing

OU Design: The Administration Model

With an administration model, you use OUs to refl ect the way resources and accounts are managed As this model refl ects the business structure of a company, it is very simi-lar to the division or business unit model The key difference is that the top-level OU is for administrators and second-level OUs are for business structure (see Figure 31-5) If successive levels are needed, they can be organized by resource type, geographic loca-tion, project type, or some combination of the three

Figure 31-5 The administration model

In a large company, you may use multiple implementations of this model for each sion or business unit In this case, the top-level administrative group would be for the division or business unit and the second-level OUs would be for groups within the division

The advantage to this model is that it is designed around the way administrators work and represents the business structure of the company The disadvantage to this model

is that when the company or divisions within the company restructure, you may need

to redesign the OU structure

As part of the design of Active Directory Domain Service, you should examine the network topology and determine if you need to manage network traffi c between subnets or business locations To manage network traffi c related to Active Directory, you use sites, which can be used to refl ect the physical topology of your network Every Active Directory implementation has at least one site An important part of understand-ing sites involves understandunderstand-ing Active Directory replication Active Directory uses two replication models: one model for replication within sites and one model for replication between sites You need a solid understanding of these replication models to plan your site structure

Working with Active Directory Sites

A site is a group of Transmission Control Protocol/Internet Protocol (TCP/IP) subnets

that are implemented to control directory replication traffi c and isolate logon authen-tication traffi c between physical network locations Each subnet that is part of a site should be connected by reliable, high-speed links Any business location connected over slow or unreliable links should be part of a separate site Because of this, indi-vidual sites typically represent the sets of local area networks (LANs) within an orga-nization, and the wide area network (WAN) links between business locations typically mark the boundaries of these sites However, sites can be used in other ways as well Sites do not refl ect the Active Directory namespace Domain and site boundaries are separate From a network topology perspective, a single site can contain multiple TCP/

IP subnets as well However, a single subnet can be in only one site This means that the following conditions apply:

A single site can contain resources from multiple domains

A single domain can have resources spread out among multiple sites

A single site can have multiple subnets

As you design site structure, you have many options Sites can contain a domain or a portion of a domain A single site can have one subnet or multiple subnets It is impor-tant to note that replication is handled differently between sites than it is within sites

Replication that occurs within a site is referred to as intrasite replication Replication

Working with Active Directory Sites 1071

Understanding Active Directory Replication 1075

Replication Rings and Directory Partitions 1091

Developing or Revising a Site Design 1096 Confi guring Active Directory Sites

and Replication

Figure 32-1 shows an example of an organization that has one domain and two sites at the same physical location Here, the organization has an East Campus site and a West Campus site As you can see, the organization has multiple domain controllers at each site The domain controllers in the East Campus site perform intrasite replication with each other, as do the domain controllers in the West Campus site Designated servers

in each site, referred to as site bridgehead servers, perform intersite replication with

each other

cpandl.com

West Campus site East Campus site

Figure 32-1 Multiple sites at the same location

Figure 32-2 shows an example of an organization that has two different physical locations Here, the organization has decided to use two domains and two sites The Main site is for the cohowinery.com domain and the Seattle site is for the sea.coho-winery.com domain Again, replication occurs both within and between the sites

Single Site vs Multiple Sites

One reason to create additional sites at the same physical location is to control tion traffi c Replication traffi c between sites is automatically compressed, reducing the amount of traffi c passed between sites by 85 to 90 percent of its original size Because network clients try to log on to network resources within their local site fi rst, this means that you can use sites to isolate logon traffi c as well

cohowinery.com

Figure 32-2 Multiple sites at different locations

In most cases, you’ll want to optimize sites for Active Directory replication control

Here, it is recommended that each site have at least one domain controller and one global catalog for client authentication For name resolution and IP address assignment,

it is also recommended that each site have at least one Domain Name System (DNS) server and one Dynamic Host Confi guration Protocol (DHCP) server Then, by creating multiple sites in the same physical location and establishing a domain controller, global catalog, and DNS and DHCP server within each site, you can closely control the logon process

You can also design sites with other network resources in mind, including distributed

fi le system (DFS) fi le shares, certifi cate authorities, and Microsoft Exchange servers

Generally speaking, you want to confi gure sites so that clients’ network queries can

be answered within the site If every client query for a network resource has to be sent

to a remote site, there could be substantial network traffi c between sites, which could

be a problem over slow WAN links As part of your site design, you should also sider site-aware applications and services These applications and services will use site boundaries to ensure that clients don’t select resources across a WAN link when a local resource is available and preferable

Enterprises often have branch offi ces where each branch offi ce is defi ned as a separate site to control traffi c for high-bandwidth–consuming applications rather than Active Directory replication Here, traffi c for high-bandwidth–consuming applications, such

as DFS or software control and change management (SCCM), is carefully managed but authentication and global catalog traffi c is allowed to cross the WAN because it is less bandwidth-intensive

Replication Within and Between Sites

Most organizations implementing Active Directory have multiple domain controllers The domain controllers may be located in a single server room where they are all con-nected to a fast network or they may be spread out over multiple geographic locations, from which they are connected over a WAN that links the company’s various offi ce locations

All domain controllers in the same forest—regardless of how many domain controllers there are and where domain controllers are located—replicate information with each other either directly or indirectly Although more replication is performed within a domain than between domains, replication between domains occurs nonetheless The same replication model is used in both cases

When a change is made to a domain partition in Active Directory, the change is cated to all domain controllers in the domain If the change is made to an attribute of

repli-an object tracked by the global catalog, the chrepli-ange is replicated to all global catalog servers in all domains of the forest Similarly, if you make a change to the forest-wide confi guration or schema partitions, these changes are replicated to all domain control-lers in all the domains of the forest

Authentication within and between domains is also handled by domain controllers If

a user logs on to his or her home domain, the local domain controller authenticates the logon If a user logs on to a domain other than the home domain, the logon request is forwarded through the trust tree to a domain controller in the user’s home domain Active Directory’s replication model is designed for consistency, but the consistency is loosely defi ned By loosely defi ned, I mean that at any given moment the information on one domain controller can be different from the information on a different domain con-troller This can happen when Windows Server 2008 has not yet replicated the changes

on the fi rst domain controller to the other domain controller Over time, Windows Server 2008 replicates the changes made to Active Directory on one domain controller

to all domain controllers as necessary

When multiple sites are involved, the replication engine uses the Site model to store and then forward changes as necessary between sites In this case, a domain controller

in the site where the changes were originally made forwards the changes to a domain controller in another site This domain controller in turn stores the changes, and then forwards the changes to all the domain controllers in the second site In this way, the

Note

Enterprises often have branch offi ces where each branch offi ce is defi ned as a separate site to control traffi c for high-bandwidth–consuming applications rather than Active Directory replication Here, traffi c for high-bandwidth–consuming applications, such

as DFS or software control and change management (SCCM), is carefully managed but authentication and global catalog traffi c is allowed to cross the WAN because it is less bandwidth-intensive.

domain controller on which a change is made doesn’t have to replicate directly with all the other domain controllers It can instead rely on the store-and-forward technique to ensure that the changes are replicated as necessary

Determining Site Boundaries

When trying to determine site boundaries, you should confi gure sites so that they refl ect the physical structure of your network Use connectivity between network seg-ments to determine where you should locate site boundaries Areas of the network that are connected with fast connections should all be part of the same site, unless you have specifi c requirements for controlling replication or the logon process Areas of the net-work that are connected with limited bandwidth or unreliable links should be part of different sites

As you examine each of the organization’s business locations, determine whether ing domain controllers and other network resources at that location is necessary If you elect not to place a domain controller at a remote location, you can make the location a part of a separate site This has the following advantages:

No Active Directory replication between the business locations

No remote domain controllers to manage

No additional site infrastructure to manage There are also several disadvantages to this approach:

All logon traffi c must cross the link between the business locations

Users may experience slow logon and authentication to network resources

In the end, the decision to establish a separate site may come down to the user ence and the available bandwidth If you have fast connections between sites—which should be dedicated and redundant—you may not want to establish a separate site for the remote business location If you have limited bandwidth between business loca-tions and want to maintain the user experience, you may want to establish a separate site and place domain controllers and possibly other network resources at the site This speeds up the logon and authentication process and allows you to better control the network traffi c between sites

experi-Understanding Active Directory Replication

When you are planning site structure, it is important that you understand how tion works As discussed previously, Active Directory uses two replication models, each

replica-of which is handled differently The intrasite replication model is used for replication within sites and is optimized for high-bandwidth connections The intersite replica-tion model is used for replication between sites and is optimized for limited-bandwidth connections Before I get into the specifi cs of replication and the replication models,

Replication Enhancements for Active Directory

The replication model used for Microsoft Windows Server 2003 and now Windows Server 2008 has changed in several important ways from the model in Windows 2000

In Windows 2000, the smallest unit of replication is an individual attribute At fi rst examination, this seems to be what is wanted; after all, you don’t want to have to rep-licate an entire object if only an attribute of that object has changed The problem with this approach is that some attributes are multivalued That is, they have multiple values

An example is the membership attribute of a universal group This attribute represents all the members of the universal group

In Windows 2000, by adding or removing a single user from the group, you caused the entire group membership to be replicated In large organizations, a signifi cant amount

of replication traffi c was often generated because universal groups might have several thousand members Windows Server 2003 and Windows Server 2008 resolve this prob-lem by replicating only the attribute’s updated value With universal group member-ship, this means that only the users you’ve added or removed are updated, rather than the entire group membership

As discussed in “Extensible Storage Engine” on page 993, Active Directory uses actional processing When there are many changes, Active Directory processes the changes in batches of 5,000 at a time This means that Active Directory processes a single transaction or multiple transactions in sequence until it reaches 5,000 changes, then it stops and checks to see if other processes are waiting for the CPU Because a transaction must complete before processing stops in this way, this places a practical limit on the number of changes that can be made in a single transaction—that number

Note

When a forest is running at Windows Server 2003 or higher functional level, the bers of the forest can take advantage of the previously discussed replication enhance- ments For Windows Server 2003 or higher functional level, this means that all domain controllers in all domains within the forest must be running Windows Server 2003 or higher

mem-Other replication enhancements involve intersite replication Windows Server 2003 and later versions of Windows Server introduce the ability to turn off compression for intersite replication and to enable notifi cation for intersite replication They also have

an improved knowledge consistency checker (KCC), which allows Active Directory to

Note

When a forest is running at Windows Server 2003 or higher functional level, the bers of the forest can take advantage of the previously discussed replication enhance- ments For Windows Server 2003 or higher functional level, this means that all domain controllers in all domains within the forest must be running Windows Server 2003 or higher.

support a greater number of sites These changes affect intersite replication in the lowing key ways:

fol-In Windows 2000, Windows Server 2003, and Windows Server 2008, all intersite replication traffi c is compressed by default Although this signifi cantly reduces the amount of traffi c between sites, it increases the processing overhead required

on the bridgehead servers to replicate traffi c between sites Therefore, if processor utilization on bridgehead servers is a concern, and you have adequate bandwidth connections between sites, you may want to disable compression, which

Windows Server 2003 and Windows Server 2008 allow you to do

In Windows 2000, Windows Server 2003, and Windows Server 2008, replication between sites occurs at scheduled intervals according to the site link confi gura-tion With Windows Server 2003 and Windows Server 2008, you can enable notifi cation for intersite replication, which allows the bridgehead server in a site

to notify the bridgehead server on the other side of a site link that changes have occurred This allows the other bridgehead server to pull the changes across the site link and thereby get more frequent updates

In Windows 2000, the maximum number of sites you can have in a forest is greatly infl uenced by the knowledge consistency checker (KCC) As a result, the KCC has a practical limit of about 100 sites per forest Because the KCC in Win-dows Server 2003 and Windows Server 2008 has been revised, the KCC itself is

no longer the limiting factor This means that you can have many hundreds of sites per forest

When a domain is running at Windows Server 2008 functional level, domain

FRS and DFS are replication services that use the Active Directory replication topology

to replicate fi les and folders in the Sysvol shared folders on domain controllers The way this works is that the replication service checks with the KCC to determine the replication topology that has been generated for Active Directory replication, and then uses this replication topology to replicate Sysvol fi les to all the domain controllers in a domain Because DFS has been signifi cantly enhanced, you’ll want to use DFS instead

of FRS whenever possible

When used with Active Directory, DFS has several advantages over FRS DFS was enhanced for Windows Server 2003 Release 2 Not only did these enhancements make DFS easier to manage, they also introduced new replication and compression technolo- gies With Windows Server 2003 Release 2 and later, DFS Replication (DFS-R) and Remote Differential Compression (RDC) are used instead of Rsync version 2.6.2 to provide up

to 300 percent faster replication and 200 to 300 percent faster compression tional overhead for managing content and replication also was reduced by 40 percent Additionally, DFS-R supports automated recovery from database loss or corruption, replication scheduling, and bandwidth throttling Together these features make DFS-R signifi cantly more scalable than FRS

Opera-RDC is the secret ingredient associated with enhanced DFS that allows for granular cation of changes when using Active Directory with Windows Server 2008—this is what’s referred to when you read a vague statement that says DFS allows for granular replica- tion of the Sysvol RDC enables granular replication by accurately identifying changes within and across fi les and transmitting only those changes to achieve signifi cant band- width savings More specifi cally, RDC detects insertions, removals, or rearrangements

repli-of data in fi les, enabling DFS-R to replicate only the changed fi le blocks when fi les are updated Changes within or across fi les are called fi le deltas

In addition to calculating fi le deltas and transferring only the differences, RDC also can copy any similar fi le from any client or server to another using data that is common to both computers This further reduces the amount of the data sent and the overall band- width requirements for fi le transfers Local differencing techniques are used to transform the old version into a new version The differences between two versions of the fi le are calculated on the source domain controller and then sent to the DFS client on the target domain controller

The storage techniques and replication architectures for DFS and FRS are decidedly ferent Figure 32-3 shows a conceptual view of how File Replication Service is used with Active Directory on a domain controller The File Replication Service (Ntfrs.exe) stores FRS topology and schedule information in Active Directory and periodically polls Active Directory to retrieve updated information using Lightweight Directory Access Protocol (LDAP) Most administrator tools that work with FRS use LDAP as well Inter-nally, FRS makes direct calls to the fi le system using standard I/O FRS uses the Remote Procedure Call (RPC) protocol when communicating with remote servers

dif-SIDE OUT Why DFS instead of FRS?

When used with Active Directory, DFS has several advantages over FRS DFS was enhanced for Windows Server 2003 Release 2 Not only did these enhancements make DFS easier to manage, they also introduced new replication and compression technolo- gies With Windows Server 2003 Release 2 and later, DFS Replication (DFS-R) and Remote Differential Compression (RDC) are used instead of Rsync version 2.6.2 to provide up

to 300 percent faster replication and 200 to 300 percent faster compression tional overhead for managing content and replication also was reduced by 40 percent Additionally, DFS-R supports automated recovery from database loss or corruption, replication scheduling, and bandwidth throttling Together these features make DFS-R signifi cantly more scalable than FRS.

Opera-RDC is the secret ingredient associated with enhanced DFS that allows for granular cation of changes when using Active Directory with Windows Server 2008—this is what’s referred to when you read a vague statement that says DFS allows for granular replica- tion of the Sysvol RDC enables granular replication by accurately identifying changes within and across fi les and transmitting only those changes to achieve signifi cant band- width savings More specifi cally, RDC detects insertions, removals, or rearrangements

repli-of data in fi les, enabling DFS-R to replicate only the changed fi le blocks when fi les are updated Changes within or across fi les are called fi le deltas.

In addition to calculating fi le deltas and transferring only the differences, RDC also can copy any similar fi le from any client or server to another using data that is common to both computers This further reduces the amount of the data sent and the overall band- width requirements for fi le transfers Local differencing techniques are used to transform the old version into a new version The differences between two versions of the fi le are calculated on the source domain controller and then sent to the DFS client on the target domain controller.

FRS stores various types of data in the NTFS fi le system, including transactions in the FRS Jet database (Ntfrs.jdb), events and error messages in the FRS Event log (NtFrs.evt), and debug logs stored in the debug log folder (%SystemRoot%\Debug) Esent.dll is

a dynamic link library used by the Jet database to store transactions Ntfrsres.dll is a dynamic-link library used by FRS to store events and error messages

FRS Jet Database Replica Tree USN Journal Staging Folder FRS Event Log FRS Debug Logs

NTFS File System

Administrator Tools

LDAP

Registry APIs

Figure 32-3 A conceptual view of how File Replication Service works

The contents of the replica tree determine what FRS replicates The replica tree for Active Directory is the Sysvol The Sysvol contains domain, staging, staging areas, and sysvol folders The USN journal is a persistent log of changes made to fi les on an NTFS volume NTFS uses the USN journal to track information about added, deleted, and modifi ed fi les FRS in turn uses the USN journal to determine when changes are made

to the contents of the replica tree FRS then replicates changes according to the ule in Active Directory FRS stores confi guration data in the Registry

Figure 32-4 shows a conceptual view of how the Distributed File System (DFS) service

is used with Active Directory on a domain controller The DFS service (Dfssvc.exe) stores information about stand-alone namespaces in the Registry and information about domain-based namespaces in Active Directory

The actual replica root begins at the %SystemRoot%\Sysvol\domain folder, but the folder that is actually shared is the %SystemRoot%\Sysvol\sysvol folder These folders appear

to contain the same content because Sysvol uses junction points (also known as reparse points) A junction point is a physical location on a hard disk that points to data that is located elsewhere on the hard disk or on another storage device

The Sysvol\domain folder contains policies and scripts in separate subfolders The Sysvol\ Staging folder acts as a queue for changed fi les that need to be replicated Within the Sysvol\Staging Areas folder, the DomainName folder is a junction point to the Sysvol\

staging\domain folder Within the Sysvol\sysvol folder, the DomainName folder is a

junction point to the Sysvol\domain folder

After a user or the operating system changes a Sysvol fi le and the fi le is closed, FRS creates the fi le in the staging folder using the backup application programming inter- faces (APIs) and replicates the fi le according to a schedule set in Active Directory The same backup APIs are used to ensure that Volume Shadow Copy service-compatible backup programs, such as Windows Backup, can make point-in-time, consistent backups

of the replica tree Before such a program takes a shadow copy of a replica tree, the gram instructs FRS to stop requesting new work items After all currently active items are complete, FRS enters a pause state during which no new items can be processed

pro-The stand-alone DFS metadata contains information about the root, root get, links, link targets, and confi guration settings defi ned for each stand-alone namespace This metadata is maintained in the Registry of the root server at HKLM\SOFTWARE\Microsoft\Dfs\Roots\Standalone

tar-Domain-based root servers have a Registry entry for each root under WARE\Microsoft\Dfs\Roots\Domain, but these entries do not contain the domain-based DFS metadata When the DFS service starts on a domain controller using Active Directory with DFS, the service checks this path for Registry entries that correspond

HKLM\SOFT-to domain-based roots If these entries exist, the root server polls the PDC emulaHKLM\SOFT-tor master to obtain the DFS metadata for each domain-based namespace and stores the metadata in memory

In the Active Directory data store, the DFS object stores the DFS metadata for a based namespace The DFS object is created in Active Directory when you install a domain at or raise a domain to the Windows Server 2008 domain functional level Active Directory replicates the entire DFS object to all domain controllers in a domain

domain-SIDE OUT The replica root

The actual replica root begins at the %SystemRoot%\Sysvol\domain folder, but the folder that is actually shared is the %SystemRoot%\Sysvol\sysvol folder These folders appear

to contain the same content because Sysvol uses junction points (also known as reparse points) A junction point is a physical location on a hard disk that points to data that is located elsewhere on the hard disk or on another storage device.

The Sysvol\domain folder contains policies and scripts in separate subfolders The Sysvol\ Staging folder acts as a queue for changed fi les that need to be replicated Within the Sysvol\Staging Areas folder, theDomainName folder is a junction point to the Sysvol\

staging\domain folder Within the Sysvol\sysvol folder, theDomainName folder is a

junction point to the Sysvol\domain folder.

After a user or the operating system changes a Sysvol fi le and the fi le is closed, FRS creates the fi le in the staging folder using the backup application programming inter- faces (APIs) and replicates the fi le according to a schedule set in Active Directory The same backup APIs are used to ensure that Volume Shadow Copy service-compatible backup programs, such as Windows Backup, can make point-in-time, consistent backups

of the replica tree Before such a program takes a shadow copy of a replica tree, the gram instructs FRS to stop requesting new work items After all currently active items are complete, FRS enters a pause state during which no new items can be processed.

DS APIs

DFS Metadata Cache Domain Name Referral Cache

DC Referral Cache Domain-Based Root Referral Cache Client Site Cache Target Site Cache Site Cost Cache

Memory Cache DFS Tools

Root and Link Folders

NTFS Volume DFS.SYS SRV.SYS

NETAPI32.DLL

DFS Object

Active Directory

DFS Service (DFSSVC.EXE)

LDAP

LDAP to DFS

on other servers

CIFS to DFS Clients

Registry APIs

DFS Metadata

Registry

Figure 32-4 A conceptual view of how the DFS service works

DFS uses a client-server architecture A domain controller hosting a DFS name space has both the client and the server components, allowing the domain controller to perform local lookups in its own data store and remote lookup in data stores on other domain controllers DFS uses the Common Internet File System (CIFS) for communica-tion between DFS clients, root servers, and domain controllers CIFS is an extension of the Server Message Block (SMB) fi le sharing protocol

When a domain controller receives a CIFS request, the SMB Service server driver (Srv.sys) passes the request to the DFS driver (Dfs.sys) and this driver in turn directs the request to the DFS service Dfs.sys also handles the processing of links when they are encountered during fi le system access

When a client requests a referral for a domain-based namespace, the domain controller

fi rst checks its domain-based root referral cache for an existing referral If the referral cache exists, the domain controller uses the cache to create the referral If the referral cache does not exist, the domain controller locates the DFS object for that namespace

and uses the metadata in the object to create the necessary referral A referral contains

a list of UNC paths that the client can use DFS uses LDAP to retrieve metadata about the domain-based namespace from Active Directory and stores this information in its in-memory cache Various types of in-memory cache are used:

Domain Name Referral Cache contains the host names and fully qualifi ed names

of the local domain, all trusted domains in the forest, and domains in trusted forests

Domain Controller Referral Cache contains the host names and fully qualifi ed names of the domain controllers for the list of domains it has cached

Domain-Based Root Referral Cache contains a list of root targets that host a given domain-based namespace

Client Site Cache stores information about the site in which a client is located (as determined using a DSAddressToSiteNames lookup)

Target Site Cache stores information about the site in which a target UNC path is located (as determined using a DSAddressToSiteNames lookup)

Site Cost Cache contains a mapping of sites to their associated cost information

as defi ned in Active Directory

After this information is cached, DFS can provide this to clients that are requesting information about DFS namespaces The physical structures and caches on a domain controller vary according to the type of namespace the server hosts (domain-based

or stand-alone) Each root and link in a namespace has a physical representation on

an NTFS volume on each domain controller The DFS root for Active Directory sponds to the Sysvol shared folder If a domain controller hosts additional namespaces, the domain controller will have additional roots and links

corre-Replication Architecture: An Overview

Active Directory replication is a multipart process that involves a source domain troller and a destination domain controller From a high level, replication works much

con-as shown in Figure 32-5

The step-by-step procedure goes like this:

implemented as an LDAP write to the appropriate directory partition

partner For the initial lookup or when the destination DNS record has expired, the source domain controller does this by querying the primary DNS server Subsequent lookups can be done using the local resolver cache

3 The source and destination domain controllers use Kerberos to mutually

authenticate each other

domain controller using RPC over IP

over IP, including information that allows the source domain controller to determine if those changes are needed

domain controller determines what changes (if any) need to be sent to the destination domain controller, and then sends the required changes using RPC over IP

the changes to the directory database

Source DC

DNS server

6a Determines the changes that need

to be sent based

on the control information Sends a request for changes and

includes control information

Change made to directory 1

Destination DC DCs mutually authenticate

using Kerberos 3

7 Writes the changes

to the directory database Sends the necessary changes

Table 32-1 Ports Used During Active Directory Replication Service/Component Port

UDP TCP

LDAP 389 389 LDAP Secure Sockets Layer (SSL) 686 Global catalog (LDAP) 3268 Kerberos version 5 88 88 DNS 53 53 RPC with FRS Dynamic RPC endpoint mapper with DFS 135 Server Message Block (SMB) over IP 445 445

Active Directory’s multimaster replication model is designed to ensure that there is no single point of failure In this model, every domain controller can access changes to the database, and can replicate those changes to all other domain controllers When replica- tion occurs within a domain, the replication follows a specifi c model that is very different from the replication model used for intersite replication

With intrasite replication, the focus is on ensuring that changes are rapidly distributed

Intrasite replication traffi c is not compressed, and replication is designed so that changes are replicated almost immediately after a change has been made The main component

in Active Directory responsible for the replication structure is the KCC One of the main responsibilities of the KCC is to generate the replication topology—that is, the way repli- cation is implemented

As domain controllers are added to a site, the KCC confi gures a ring topology for intrasite replication with pull replication partners Why use this model? For the following reasons:

In a ring topology model, there are always at least two paths between connected network resources to provide redundancy Creating a ring topology for Active Directory replication ensures that there are at least two paths that changes can fol- low from one domain controller to another

In a pull replication model, two servers are used One is designated the push ner, the other the pull partner It is the responsibility of the push partner to notify the pull partner that changes are available The pull partner can then request the changes Creating push and pull replication partners allows for rapid notifi cation of changes and for updating after a request for changes has been made

part-The KCC uses these models to create a replication ring As domain controllers are added

to a site, the size and confi guration of this ring change When there are at least three domain controllers in a site, each domain controller is confi gured with at least two incoming replication connections As the number of domain controllers changes, the KCC updates the replication topology

When a domain controller is updated, it waits approximately 15 seconds before ing replication This short wait is implemented in case additional changes are made

initiat-The domain controller on which the change is made notifi es one of its partners, using

an RPC, and specifi es that changes are available The partner can then pull the changes

After replication with this partner completes, the domain controller waits approximately

3 seconds, and then notifi es its second partner of changes The second partner can then pull the changes Meanwhile, the fi rst partner is notifying its partners of changes as appropriate This process continues until all the domain controllers have been updated

SIDE OUT Intrasite replication essentials

Active Directory’s multimaster replication model is designed to ensure that there is no single point of failure In this model, every domain controller can access changes to the database, and can replicate those changes to all other domain controllers When replica- tion occurs within a domain, the replication follows a specifi c model that is very different from the replication model used for intersite replication.

With intrasite replication, the focus is on ensuring that changes are rapidly distributed

Intrasite replication traffi c is not compressed, and replication is designed so that changes are replicated almost immediately after a change has been made The main component

in Active Directory responsible for the replication structure is the KCC One of the main responsibilities of the KCC is to generate the replication topology—that is, the way repli- cation is implemented.

As domain controllers are added to a site, the KCC confi gures a ring topology for intrasite replication with pull replication partners Why use this model? For the following reasons:

In a ring topology model, there are always at least two paths between connected network resources to provide redundancy Creating a ring topology for Active Directory replication ensures that there are at least two paths that changes can fol- low from one domain controller to another.

In a pull replication model, two servers are used One is designated the push ner, the other the pull partner It is the responsibility of the push partner to notify the pull partner that changes are available The pull partner can then request the changes Creating push and pull replication partners allows for rapid notifi cation of changes and for updating after a request for changes has been made.

part-The KCC uses these models to create a replication ring As domain controllers are added

to a site, the size and confi guration of this ring change When there are at least three domain controllers in a site, each domain controller is confi gured with at least two incoming replication connections As the number of domain controllers changes, the KCC updates the replication topology.

When a domain controller is updated, it waits approximately 15 seconds before ing replication This short wait is implemented in case additional changes are made

initiat-The domain controller on which the change is made notifi es one of its partners, using

an RPC, and specifi es that changes are available The partner can then pull the changes.

After replication with this partner completes, the domain controller waits approximately

3 seconds, and then notifi es its second partner of changes The second partner can then pull the changes Meanwhile, the fi rst partner is notifying its partners of changes as appropriate This process continues until all the domain controllers have been updated.

The 15-second delay for replication applies to Windows Server 2003 and Windows Server

2008 For Windows 2000, the default delay is 300 seconds In either case, however, the delay is overridden to allow immediate replication of priority changes Priority (urgent) replication is triggered if you perform one of the following actions:

Lock out an account, change the account lockout policy, or if an account is locked out automatically due to failed logon attempts

Change the domain password policy Change the password on a domain controller computer account Change the relative ID master role owner

Change a shared secret password used by the Local Security Authority (LSA) for Kerberos authentication

Urgent replication means that there is no delay to initiate replication Note that all other changes to user and computer passwords are handled by the designated primary domain controller (PDC) emulator in a domain When a user changes a normal user or computer password, the domain controller to which that user is connected immediately sends the change to the PDC emulator This way, the PDC emulator always has the latest password for a user This is why the PDC emulator is checked for a new password if a logon fails initially After the new password is updated on the PDC emulator, the PDC emulator rep- licates the change using normal replication The only exception is when a domain con- troller contacts the PDC emulator requesting a password for a user In this case, the PDC emulator immediately replicates the current password to the requesting domain control- ler so that no additional requests are made for that password

Figure 32-6 shows a ring topology that a KCC would construct if there were three domain controllers in a site

As you can see from the fi gure, replication is set up as follows:

DC1 has incoming replication connections from DC2 and DC3

DC2 has incoming replication connections from DC1 and DC3

DC3 has incoming replication connections from DC1 and DC2

If you make changes to DC1, DC1 notifi es DC2 of the changes DC2 then pulls the changes After replication completes, DC1 notifi es DC3 of the changes DC3 then pulls the changes Because all domain controllers in the site have now been notifi ed, no addi-tional replication occurs However, DC2 still notifi es DC3 that changes are available DC3 does not pull the changes, however, because it already has them

SIDE OUT Replicating urgent changes

The 15-second delay for replication applies to Windows Server 2003 and Windows Server

2008 For Windows 2000, the default delay is 300 seconds In either case, however, the delay is overridden to allow immediate replication of priority changes Priority (urgent) replication is triggered if you perform one of the following actions:

Lock out an account, change the account lockout policy, or if an account is locked out automatically due to failed logon attempts

Change the domain password policy Change the password on a domain controller computer account Change the relative ID master role owner

Change a shared secret password used by the Local Security Authority (LSA) for Kerberos authentication

Urgent replication means that there is no delay to initiate replication Note that all other changes to user and computer passwords are handled by the designated primary domain controller (PDC) emulator in a domain When a user changes a normal user or computer password, the domain controller to which that user is connected immediately sends the change to the PDC emulator This way, the PDC emulator always has the latest password for a user This is why the PDC emulator is checked for a new password if a logon fails initially After the new password is updated on the PDC emulator, the PDC emulator rep- licates the change using normal replication The only exception is when a domain con- troller contacts the PDC emulator requesting a password for a user In this case, the PDC emulator immediately replicates the current password to the requesting domain control- ler so that no additional requests are made for that password.

Site

DC3

DC2 DC1

Figure 32-6 Intrasite replication using a ring topology

Domain controllers track directory changes using Update Sequence Numbers (USNs)

Any time a change is made to the directory, the domain controller assigns the change a USN Each domain controller maintains its own local USNs and increments their val-ues each time a change occurs The domain controller also assigns the local USN to the object attribute that changed Each object has a related attribute called uSNChanged

The uSNChanged attribute is stored with the object and identifi es the highest USN that has been assigned to any of the object’s attributes

To see how this works, consider the following example The local USN for DC1 is 125

An administrator connected to DC1 changes the password on a user’s account DC1 registers the change as local USN 126 The local USN value is written to the uSN-Changed attribute of the user object If the administrator next edits a group account and changes its description, DC1 registers the change as local USN 127 The local USN value is written to the uSNChanged attribute of the Group object

With replication, there is sometimes a concern that replication changes from one domain controller may overwrite similar changes made to another domain controller However, as object changes are tracked on a per-attribute basis, this rarely happens It is very unlikely that two administrators would change the exact same attributes of an object at the exact same time By tracking changes on a per-attribute basis, Active Directory effectively minimizes the possibility of any confl ict Should such a confl ict occur, Active Directory resolves the confl ict using a last-write-wins algorithm

Each domain controller tracks not only its local USN but also the local USNs of other

domain controllers in a table referred to as an up-to-dateness vector During the

replica-tion process, a domain controller that is requesting changes includes its up-to-dateness vector The receiving domain controller can then compare the USN values to those it has stored If the current USN value for a particular domain controller is higher than the stored value, changes associated with that domain controller need to be replicated

If the current value for a particular domain controller is the same as the stored value, changes for that domain controller do not need to be replicated

As only necessary changes are replicated, this process of comparing up-to-dateness vectors ensures that replication is very effi cient and that changes propagate only when necessary The up-to-dateness vectors are in fact the mechanism that enables domain controllers with redundant connections to know that they’ve already received the nec-essary updates

Several types of replication changes have priority If you make changes to object butes in the schema, these changes take precedence over most other changes In this case, Active Directory blocks replication of normal changes and replicates the schema changes Active Directory continues to replicate schema changes until the schema confi guration is synchronized on all domain controllers in the forest This ensures that schema changes are applied rapidly Still, it’s a good idea to make changes to the schema during off-hours, because schema changes need to propagate throughout the forest before other changes such as resetting passwords can be made to Active Directory

attri-The Windows Server 2008 schema adds indexed attributes to the schema directory partition When you upgrade or install the fi rst Windows Server 2008 domain control- ler, these changes replicate throughout the forest Because of this, it is recommended that you plan your deployment carefully and use the Active Directory Preparation tool (adprep.exe) to perform updates to Active Directory to prepare a domain or forest for Windows Server 2008 installation See Chapter 2, “Planning for Windows Server 2008,” for more information

Note

With replication, there is sometimes a concern that replication changes from one domain controller may overwrite similar changes made to another domain controller However, as object changes are tracked on a per-attribute basis, this rarely happens It is very unlikely that two administrators would change the exact same attributes of an object at the exact same time By tracking changes on a per-attribute basis, Active Directory effectively minimizes the possibility of any confl ict Should such a confl ict occur, Active Directory resolves the confl ict using a last-write-wins algorithm.

SIDE OUT Schema changes have priority

Several types of replication changes have priority If you make changes to object butes in the schema, these changes take precedence over most other changes In this case, Active Directory blocks replication of normal changes and replicates the schema changes Active Directory continues to replicate schema changes until the schema confi guration is synchronized on all domain controllers in the forest This ensures that schema changes are applied rapidly Still, it’s a good idea to make changes to the schema during off-hours, because schema changes need to propagate throughout the forest before other changes such as resetting passwords can be made to Active Directory.

attri-The Windows Server 2008 schema adds indexed attributes to the schema directory partition When you upgrade or install the fi rst Windows Server 2008 domain control- ler, these changes replicate throughout the forest Because of this, it is recommended that you plan your deployment carefully and use the Active Directory Preparation tool (adprep.exe) to perform updates to Active Directory to prepare a domain or forest for Windows Server 2008 installation See Chapter 2, “Planning for Windows Server 2008,” for more information.

Intersite Replication Essentials

Although intrasite replication focuses on speed, intersite replication focuses on effi ciency The primary goal of intersite replication is to transfer replication information between sites while making the most effi cient use of the available resources With effi -ciency as a goal, intersite replication traffi c uses designated bridgehead servers and a default confi guration that is scheduled rather than automatic, and compressed rather than uncompressed

With designated bridgehead servers, the Inter-Site Topology Generator (ISTG) limits the points of replication between sites Instead of allowing all the domain controllers in one site to replicate with all the domain controllers in another site, the ISTG designates a limited number of domain controllers as bridgehead serv-ers These domain controllers are then the only ones used to replicate information between sites

With scheduled replication, you can set the valid times during which tion can occur and the replication frequency within this scheduled interval By default, when you confi gure intersite replication, replication is scheduled to occur every 180 minutes 24 hours a day When there’s limited bandwidth between sites, you might want to change the default schedule to better accommodate the users who also use the link For example, you might want to allow replication to occur every 180 minutes 24 hours a day on Saturday and Sunday, but during the week set the schedule to allow more bandwidth during the day For example, you might set replication to occur every 60 minutes from 6 A.M to 8 A.M and from 7 P.M to

replica-3 A.M Monday through Friday

With compression, replication traffi c is compressed 85 to 90 percent, meaning that it is 10 to 15 percent of its uncompressed size This means that even low-bandwidth links can often be used effectively for replication Compression is trig-gered when the replication traffi c is more than 32 kilobytes (KB) in size

As discussed previously, there are two key ways to change intersite replication, as follows:

Turn off automatic compression if you have suffi cient bandwidth on a link and are more concerned about the processing power used for compression

Enable automatic notifi cation of changes to allow domain controllers on either side of the link to indicate that changes are available Automatic notifi cation allows those changes to be requested rather than making domain controllers wait for the next replication interval

Regardless of the site link confi guration, replication traffi c is sent through designated bridgehead servers rather than through multiple replication partners When changes are made to the directory in one site, those changes replicate to the other site via the designated bridgehead servers The bridgehead servers then initiate replication of the changes exactly as was discussed in “Intrasite Replication Essentials” on page 1085, except that the servers can use SMTP instead of RPC over IP if you use SMTP as a

transport Thus, intersite replication is really concerned with getting changes from one site to another across a site link

Figure 32-7 shows an example of intersite replication using a single designated head server on each side of a site link In this example, DC3 is the designated bridge-head server for Site 1 and DC4 is the designated bridgehead server for Site 2

Figure 32-7 Replication between two sites

As you can see from the fi gure, replication is set up as follows:

DC1 has incoming replication connections from DC2 and DC3

DC2 has incoming replication connections from DC1 and DC3

DC3 has incoming replication connections from DC1 and DC2

DC4 has incoming replication connections from DC5 and DC6

DC5 has incoming replication connections from DC4 and DC6

DC6 has incoming replication connections from DC4 and DC5

If changes are made to DC1 in Site 1, DC1 notifi es DC2 of the changes DC2 then pulls the changes After replication completes, DC1 notifi es DC3 of the changes DC3 then pulls the changes Because all domain controllers in the Site 1 have now been notifi ed,

no additional replication occurs within the site However, DC2 still notifi es DC3 that

changes are available DC3 does not pull the changes, however, because it already has them

According to the site link confi guration between Site 1 and Site 2, DC3 notifi es DC4 that changes are available DC4 then pulls the changes Next DC4 notifi es DC5 of the changes DC5 then pulls the changes After replication completes, DC4 notifi es DC6 of the changes DC6 then pulls the changes Because all domain controllers in Site 2 have now been notifi ed, no additional replication occurs However, DC5 still notifi es DC6 that changes are available DC6 does not pull the changes, however, because it already has the changes

So far, I’ve talked about designated bridgehead servers but haven’t said how bridgehead servers are designated That’s because it is a rather involved process When you set up

a site, the knowledge consistency checker (KCC) on a domain controller that Active Directory has designated the Inter-Site Topology Generator (ISTG) is responsible for generating the intersite topology Each site has only one ISTG and its job is to determine the best way to confi gure replication between sites

The ISTG does this by identifying the bridgehead servers that are to be used tion between sites is always sent from a bridgehead server in one site to a bridgehead server in another site This ensures that information is replicated only once between sites As domain controllers are added and removed from sites, the ISTG regenerates the topology automatically

Replica-The ISTG also creates the connection objects that are needed to connect bridgehead servers on either side of a site link This is how Active Directory logically represents a site link The ISTG continuously monitors connections and will create new connections when a domain controller acting as a designated bridgehead server is no longer avail-able In most cases, there will be more than one designated bridgehead server, and I’ll discuss why in “Replication Rings and Directory Partitions” below

Note

You can manually confi gure intersite replication in several ways In addition to the niques discussed previously for scheduling, notifi cation, and compression, you can also confi gure site link costs, confi gure connection objects manually, and designate preferred bridgehead servers

tech-Replication Rings and Directory Partitions

The KCC is responsible for generating the intrasite replication topology, and the ISTG uses the KCC to generate the intersite replication topology The KCC always confi gures the replication topology so that each domain controller in a site has at least two incom-

Note

You can manually confi gure intersite replication in several ways In addition to the niques discussed previously for scheduling, notifi cation, and compression, you can also confi gure site link costs, confi gure connection objects manually, and designate preferred bridgehead servers.