Title: Designing Replication and Disaster Recovery
1Chapter 11
- Designing Replication and Disaster Recovery
2Learning Objectives
- Explain how Active Directory replication works,
including the use of the Knowledge Consistency
Checker - Design the Active Directory replication topology
for an organization - Design Dfs for folder and file replication
- Plan disaster recovery methods, including backing
up and restoring Active Directory and other
critical system data
3Using Active Directory Replication
- Replication
- The process of creating a copy of specific Active
Directory data (data store) on domain controllers - Each copy is regularly synchronized to ensure
that it is identical to every other copy on
domain controllers in the same domain
4Using Active Directory Replication
- Vital elements in Active Directory that are
replicated in the multimaster topology - Domain partition namespace
- Schema namespace
- Configuration container namespace
- Global catalog
- DNS namespace (when DNS is integrated with Active
Directory)
5Domain Partition Namespace Replication
6(No Transcript)
7(No Transcript)
8The Replication Process
- Tracking Active Directory changes
- Track every change in sequence
- Place a timestamp on each change
- Providing fault tolerance
- Packaging changes to match the site topology
9Knowledge Consistency Checker (KCC)
- Purpose to guarantee that Active Directory
replication takes place - Establishes network connections between DCs
- Ensures that replication services take place
- Obtains site and site link information from the
configuration container - Assesses locations of DCs, site link costs, and
the replication strategy of server administrators - Determines replication partners
10How the KCC WorksWithin a Site
- Establishes connections between domain
controllers and polls those connections every 15
minutes to determine if - The connection needs to be reestablished
- A new DC needs to be added for replication
- A DC has been removed from the network
- Ensures efficient replication and establishes the
replication ring by using information about sites
and site links that it obtains from the
configuration container
11How the KCC WorksWithin a Site
12How the KCC WorksWithin a Site
13How the KCC WorksWithin a Site
- Information about all of the replicating DCs in a
site, including global catalog servers, is
contained in an Active Directory child object
under a site called NTDS Site Settings - Child objects in the Servers folder are the DCs
in the site each DC has a child object called
NTDS Settings
14NTDS Site Settings Container
15Replication Partners
16How the KCC WorksWithin a Site
- Remote procedure call (RPC) protocol
- Transport protocol used by the replication
process within a site - Carried over another transport protocol, TCP/IP
- Enables one computer to run a program process or
procedure called a remote procedure call on
another computer
17How the KCC WorksOver Site Links
- Establishes one bridgehead server at each site
- Each bridgehead server replicates Active
Directory to other DCs on the same site using
ring-based replication topology - You can establish a cost with a site link and
determine replication frequency
18Setting Replication Frequency over a Site Link
19How the KCC WorksOver Site Links
- Uses PRC protocol for replication between sites
- Carried over TCP/IP or SMTP
- Transitive replication
- Can go in any direction through a site link
bridge
20Using Site Link Bridges
21Review of Replication Factors
- The KCC checks every 15 minutes for changes to
site topology - Intrasite replication occurs when a change is
made to Active Directory - Intersite replication occurs by default every 180
minutes, 24 hours/day, 7 days/week, but the
replication interval can be manually configured
at other intervals - Replication between two sites occurs only if a
site link is configured between them
continued
22Review of Replication Factors
- If two or more site links exist between the same
site, configure each site link with a cost
replication goes over the link with lowest cost - Replication between sites is performed by one
bridgehead server designated per site - Configuring site link bridges enables two or more
sites to replicate transitively (in multiple
directions)
23Guidelines for Designing a Replication Topology
- Small network
- Use two or more domains so replication can take
place - Dividing a single domain network
- Locate at least one domain controller and global
catalog server at each site (provides offsite
backup) - Consider placing a DNS server that is integrated
with Active Directory at each site
continued
24Guidelines for Designing a Replication Topology
- Multiple domain network with 2 or more sites
- Locate two or more DCs in each domain, at least
one DC in each site, and at least one global
catalog server at each site - Place a NDS server integrated with Active
Directory in each domain and at each site - Two or more site links between two adjoining
sites - Configure the cost of each site link so the KCC
will direct replication traffic over the site
link that has the lowest cost
continued
25Guidelines for Designing a Replication Topology
- For each site link
- Configure replication frequency so that
replication does not interfere with regular
business use of the site link - For small and medium-sized networks
- Configure site links that use the same protocol
so that all site links are in the same site link
bridge - For some medium-sized and large networks
- Disable setting to link all site links into a
single bride - Configure individual site link bridges on basis
of analysis of network traffic over site links
continued
26Guidelines for Designing a Replication Topology
- Use TCP/IP as the main RPC host transport
protocol - For site links within and between domains,
whenever possible - Use SMTP as the main RPC host protocol
- When replicating between two different domains
over an e-mail and Internet-based site link
27Designing a Replication Topology Sample
28Advantages of the Previous Design
- There is offsite replication of the domain
partition, configuration container, schema, and
global catalog, in case there is a disaster that
damages servers in one of the buildings - Replication over the site link it compressed to
reduce traffic - Replication traffic over the site link can be
scheduled so that it does not interfere with
regular business operations over the site link
29Designing a Replication Topology Sample
30Advantages of the Previous Design
- There is offsite replication at five different
sites at each site, there is replication of the
domain partition, configuration container,
schema, and global catalog - The bridge all sites links option ensures that
replication occurs in any direction among site - Assigning lowest cost to X.25 links ensures that
replication goes over the links that have the
least important network traffic
31Designing a Replication Topology Sample
32Advantages of the Previous Design
- Domain partition replication occurs across
multiple servers within the same domain - Offsite domain partition replication is set up
for sites in the same domain that are in
different physical locations - Global catalog server replication occurs between
all domains, providing offsite replication of
global catalog server information
33Using Dfs for File Replication and Disaster
Recovery
- Distributed File System (Dfs)
- Protects critical user files enables you to
- Simplify access to shared folders on a network
- Replicate shared folder information to multiple
DCs on a network - Load balance access to shared folders
- Provides a way to automatically replicate vital
information in shared folders - Enables fault tolerance
- Can be a source of disaster recovery
34Dfs Models
35Standalone Dfs Model
- No Active Directory implementation to help manage
shared folders - Only a single or flat-level share
- Main Dfs shared folder does not contain a
hierarchy of other shared folders - Does not have Dfs folders that are linked to
other computers through a Dfs container that has
a main root and a deep, multilevel hierarchical
structure - Does not implement fault tolerance and load
balancing for shared folders
36Domain-based Dfs Model
- Takes full advantage of Active Directory
- Available only to servers and workstations that
are members of a domain - Enables a deep root-based hierarchical
arrangement of shared folders that is published
in Active Directory - Shared folders are replicated for fault tolerance
and load balancing
37Dfs Topology
- The hierarchical structure of Dfs in the
domain-based model - Three elements
- Dfs root
- Dfs link
- Servers on which the Dfs shared folders are
replicated as replica sets
38Dfs Topology
39Creating a Dfs Implementation Plan
- When Active Directory is installed, plan to use
the domain-based model it provides the most
options and enables you to mange resulting
network traffic - Place Dfs shared folders on disks that are
formatted using NTFS ensures strong security
options
continued
40Creating a Dfs Implementation Plan
- Use more than one Dfs root to reflect the
particular needs of an organization
continued
41Creating a Dfs Implementation Plan
- Use upper-level subfolders under a root to
reflect other elements of an organization (Figure
11-15) - Determine the impact that Dfs will have on
network traffic use domain-based model with load
balancing to help equally disperse network traffic
continued
42Creating a Dfs Implementation Plan
43Creating a Dfs Implementation Plan
- When designing a domain-based model, create the
first Dfs root and links to that root before
creating additional Dfs roots - In the domain-based model, develop a
synchronization schedule that will take into
account the existing network traffic along
different routs (segments) on which
synchronization will occur - Review all Dfs shared folders on a regular basis
purge folders no longer in use
44Setting Up Dfs
- Dfs is configured using either
- The Distributed File System tool in the
Administrative Tools menu, or - The Distributed file system MMC snap-in
45Planning Disaster Recovery
- In addition to carefully planning Active
Directory replication and Dfs - Develop a backup strategy and perform regular
backups - Back up system state data and system protected
files - Create boot disks
- Create and regularly update emergency repair disks
46Developing a Backup Strategy
47Developing a Backup Strategy
- Backup media rotation plan should include
- At least two complete sets of media
- A media rotation method
- Offsite storage of backup media
48Disaster Recovery for System State Data
- Critical elements are backed up as a group
because many are interrelated - System and boot files
- Active Directory
- SYSVOL folder
- Registry
- COM Class Registration information
- DNS zones
- Certificate information
- Server cluster data
49Disaster Recovery for System Protected Files
- System protected files are vital for booting a
server - Ntldr
- Bootsect.dos
- Boot.ini
- Ntdetect.com
- Ntbootdd.sys
- Ntoskrnl.exe
- Hal.dll
50Disaster Recovery for System Protected Files
51Creating Boot Disks
- Vital if you cannot boot from a hard drive or a
CD-ROM drive - Needed to boot the computer and use the emergency
repair disk
52Creating and Using an Emergency Repair Disk
- Enables you to fix several kinds of problems
- Create a new ERD each time you
- Install software
- Make a server configuration change
- Install a new adapter
- Add a NIC
- Restructure a partition
- Upgrade the operating system
53Starting the ERD
54Chapter Summary
- How Active Directory replication works and how to
design your network to take full advantage of
replication - How Dfs can be used to replicate information that
is not in Active Directory, for faster access and
fault tolerance - How to back up and restore critical system data
for extra disaster recovery insurance