Posts Tagged ‘Replication’

This source server failed to generate the changes

Posted: January 16, 2014 in Active Directory, Domain Controller, Registry, Replication, Server, Server 2003, Server 2008
Tags: , , , , , , , ,
0

Alert: This source server failed to generate the changes

Description: This directory service failed to retrieve the changes requested for the following directory partition. As a result, it was unable to send change requests to the directory service at the following network address.

1479

Event ID: 1479

Active Directory Domain Services could not update the following object in the local Active Directory Domain Services database with changes received from the following source directory service. Active Directory Domain Services does not have enough database version store to apply the changes.

User Action

Restart this directory service. If this does not solve the problem, increase the size of the database version store. If you are populating the objects with a large number of values, or the size of the values is especially large, decrease the size of future changes.

 

Additional Data

Error value:

8573 The database is out of version store.

 

Resolution:

{MS has provided the resolution in this Link}

Note: Take Backup of Registry before changing

 

Registry Location:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

 

You need to add the Registry value “EDB max ver pages” with 32 Bit DWord Decimal value as you need with reference below:

9600 = 152 MB
12800 = 202 MB
16000 = 252 MB
19200 = 302 MB

Reboot the Server once the changes have been done.

Check the Event viewer after restart; you need to get event 1394 in ADS Logs

1394

Advertisement

How do you view replication properties for AD partitions and DCs?

Posted: September 6, 2012 in Active Directory, Replication, Server, Server 2003, Server 2008
Tags: , , ,
0

 

By using replication monitor 

Go to start > run > type repadmin

Go to start > run > type replmon

The Replmon graphical user interface (GUI) tool is included when you install Windows Server 2003 Support Tools from the product CD or from the Microsoft Download Center

Replmon.exe: Active Directory Replication Monitor

This GUI tool enables administrators to view the low-level status of Active Directory replication, force synchronization between domain controllers, view the topology in a graphical format, and monitor the status and performance of domain controller replication.

The Replmon graphical user interface tool was removed from Windows Server 2008 and later. Repadmin is still available for troubleshooting replication.

Repadmin.exe: Replication Diagnostics Tool

This command-line tool assists administrators in diagnosing replication problems between Windows domain controllers.

Administrators can use Repadmin to view the replication topology as seen from the perspective of each domain controller. In addition, Repadmin can be used to manually create the replication topology, to force replication events between domain controllers, and to view both the replication metadata and up-to-date vectors.

Repadmin.exe can also be used for monitoring the relative health of an Active Directory forest. The operations replsummary, showrepl, showrepl /csv, and showvector /latency can be used to check for replication problems.

 

What Are Site Links?

Posted: August 28, 2012 in Active Directory, DNS, Replication, Server 2003, Server 2008
Tags: , , , , ,
0

Introduction

In order for two sites to exchange replication data, they must be connected by a site link. A site link is a connection that enables replication traffic to travel between sites. Site links represent the physical connections available between sites.

 

Why to create Site Link?

When you create additional sites, you must select at least one site link for each site. Unless a site link is in place, connections cannot be made between computers at different sites, and replication between sites cannot take place. Additional site links are not created automatically; you must use Active Directory Sites and Services to create them.

 

Default Site Link

When you create the first domain in a forest, a default site link named DEFAULTIPSITELINK is also created. It includes the first site, and is located in the IP container in Active Directory. The site link can be renamed.

 

Site link attributes

When you create a site link, you must select the transport protocol it will use, give it a name, and add two or more sites to it. The sites are then connected. The characteristics of this connection are determined by the site link attributes, which can be configured. The connection characteristics are configured on the link, so all sites connected by a single site link will use the same replication path and transport. Configuring site link attributes is one part of configuring replication between sites. Site link attributes determine the characteristics of the connection in terms of the cost, frequency of replication traffic, and the protocols used.

 

Site link cost

Site link cost is a dimensionless number that represents the relative speed, reliability and preference of the underlying network. The lower the site link cost, the higher the priority for that link. For example, your organization has a site in Denver and a site in Paris with two connections between them: a high-speed connection and a dial-up connection in case the high-speed connection fails. You would configure two site links, one for each connection. Because the high-speed connection is preferable to a dial-up connection, you would configure the site link representing it with a lower cost than the site link for the dial-up line. Because the site link representing the high-speed connection has a lower cost, it has a higher priority, and that site link will always be used if possible. Setting site link cost enables you to determine the relative priority for each site link. The default cost value is 100, with possible values from one to 99999.

 

Site link replication Schedule

Replication schedule is another site link attribute that can be configured. When you configure the link’s schedule, you specify the times when the link is available for replication. Often, replication availability is configured for times when there is little other network traffic, for example from 1:00 A.M. to 4:00 A.M. The fewer hours a link is available for replication, the greater the latency between sites that are connected by that link. The need to have replication occur at off-peak hours should be balanced against the need for up-to-date information at each site connected by the link.

 

Site link replication frequency

When you configure the frequency of replication, you specify how many minutes Active Directory should wait before using the link to check for updates. The default value for replication frequency is 180 minutes, and the value you choose must fall between 15 minutes and one week. Replication frequency only applies to the times when the link is scheduled to be available. Longer intervals between replication cycles reduce network traffic and increase the latency between sites. Shorter intervals increase network traffic and decrease latency. The need to reduce network traffic should be balanced against the need for up-to-date information at each of the sites connected by the link.

 

Site link transport protocols

A transport protocol is a common language shared by computers to communicate during replication. Within a single site, there is only one protocol used for replication. When you create a site link, you must choose to use one of the following transport protocols:

1. Remote procedure call (RPC) over IP. RPC is an industry standard protocol for client/server communications, and provides reliable, high speed connectivity within sites. Between sites, RPC over IP enables replication of all Active Directory partitions. RPC over IP is the best transport protocol for replication between sites.

2. Simple mail transfer protocol (SMTP). SMTP supports intersite and interdomain replication of the schema, configuration, and global catalog. This protocol cannot be used for replication of the domain partition. This is because some domain operations, for example Group Policy, require the support of the File Replication service (FRS), which does not support an asynchronous transport for replication. If you use SMTP, you must install and configure a certificate authority to sign the SMTP messages and ensure the authenticity of directory updates. Additionally, SMTP does not provide the same level of data compression that RPC over IP enables.

 

SITES in Active Directory

Posted: August 28, 2012 in Active Directory, Domain Controller, Server, Server 2003, Server 2008
Tags: , , , , , , , ,
2

Introduction

Replication ensures that all information in Active Directory is current on all domain controllers and client computers across your entire network. Many networks consist of a number of smaller networks, and the network links between these networks may operate at varying speeds. Sites in Active Directory enable you to control replication traffic and other types of traffic related to Active Directory across these various network links. You can use subnet objects, site links, and site link bridges to help control the replication topology when configuring replication between sites. An efficient, reliable replication topology depends on the configuration of site links and site link bridges.

 

What Are Sites and Subnet Objects?

 

Introduction

You use sites to control replication traffic, logon traffic, and requests to the Global Catalog server.

 

Sites

In Active Directory, sites help define the physical structure of a network. A site is defined by a set of Transmission Control Protocol/Internet Protocol (TCP/IP) subnet address ranges. Sites are used to define a group of domain controllers that are well-connected in terms of speed and cost. Sites consist of server objects, which contain connection objects that enable replication.

 

Subnet Objects

The TCP/IP subnet address ranges are represented by subnet objects that group computers. For example, a subnet object might represent all the computers on a floor in a building, or on a campus. Subnet objects are associated with sites and, because the subnet objects map to the physical network, so do the sites. For example, if you have three subnets that represent three campuses in a city, and these campuses are connected by high-speed, highly available connections, you could associate each of those subnets with the same site. A site can consist of one or more subnets. For example, on a network with three subnets in London and two in Boston, the administrator can create a site in London, a site in Boston, and then add the subnets to the respective sites.

 

Default Site

A default site is set up automatically when you install Windows Server on the first domain controller in a forest. This site is called Default-First-Site- Name. This site can be renamed. When you create your first domain in a forest it is automatically placed in the default site.

GLOBAL CATALOG SERVER

Posted: August 28, 2012 in Active Directory, DNS, Domain Controller, Server, Server 2003, Server 2008
Tags: , , , , ,
2

Introduction

A global catalog server is a domain controller that stores two forest-wide partitions, schema and configuration, a read/write copy of the partition from its own domain, and also a partial replica of all other domain partitions in the forest. These partial replicas contain a read-only subset of the information in each domain partition.

 

How does replication affect the global catalog server?

When a new domain is added to a forest, the information about the new domain is stored in the configuration partition, which is replicated to all domain controllers, including global catalog servers, through normal forest-wide replication. Then each global catalog server becomes a partial replica of the new domain by contacting a domain controller for that domain and obtaining the partial replica information. The configuration partition also contains a list of all global catalog servers in the forest and provides this information to the domain controllers. Global catalog servers register special DNS records in the DNS zone that correspond to the Forest Root domain. These records, which are registered only in the Forest Root DNS zone, help clients and servers locate global catalog servers throughout the forest.

Automatic Generation of Replication Topology

Posted: August 24, 2012 in Active Directory, DNS, Server, Server 2003, Server 2008
Tags: , , , , , , ,
0

Introduction

When you add domain controllers to a site, Active Directory uses the Knowledge Consistency Checker (KCC) to establish a replication path between domain controllers.

 

What is Knowledge Consistency Checker?

The KCC is a built-in process that runs on each domain controller and generates the replication topology for all directory partitions contained on that domain controller. The KCC runs at specified intervals (every 15 minutes by default) and designates replication routes between domain controllers that are the most favorable connections available at the time.

 

How KCC works?

To automatically generate a replication topology, the KCC evaluates information in the configuration partition on sites, the cost of sending data between these sites, any existing connection objects, and the replication protocols that can be used between the sites. Next, the KCC calculates the best connections for a domain controller’s directory partitions to other domain controllers. Additionally, if replication within a site becomes impossible or has a single point of failure, the KCC automatically establishes new connection objects between domain controllers to maintain Active Directory replication.

Sites and Directory Replications

Posted: August 24, 2012 in Active Directory, DNS, Server, Server 2003, Server 2008
Tags: , , , ,
4

Partitions:-

Introductions

The Active Directory database is logically separated into directory partitions, a schema partition, a configuration partition, domain partitions, and application partitions. Each partition is a unit of replication, and each partition has its own replication topology. Replication is performed between directory partition replicas. All domain controllers in the same forest have at least two directory partitions in common: the schema and configuration partitions. All domain controllers in the same domain, in addition, share a common domain partition.

 

Schema Partition:

There is only one schema partition per forest. The schema partition is stored on all domain controllers in a forest. The schema partition contains definitions of all objects and attributes that can be created in the directory, and the rules for creating and manipulating them. Schema information is replicated to all domain controllers in the forest, so all objects must comply with the schema object and attribute definitions.

 

Configuration Partition:

There is only one configuration partition per forest. The configuration partition is stored on all domain controllers in a forest. The configuration partition contains information about the forest-wide Active Directory structure, including what domains and sites exist, which domain controllers exist in each, and which services are available. Configuration information is replicated to all domain controllers in a forest.

 

Domain Partition:

There can be many domain partitions per forest. The domain partitions are stored on all of the domain controllers of the given domain. A domain partition holds information about all domain-specific objects created in that domain, including users, groups, computers, and organizational units. The domain partition is replicated to all domain controllers of that domain. All objects in every domain partition in a forest are stored in the Global Catalog with only a subset of its attribute values.

 

REPLICATIONS:

The replication process occurs between two domain controllers at a time. Over time, replication synchronizes information in Active Directory for an entire forest of domain controllers. To create a replication topology, Active Directory must determine which domain controllers replicate data with other domain controllers.

 

What is the SYSVOL folder?

Posted: January 23, 2012 in Active Directory, Server, Server 2003, Server 2008
Tags: , , , , ,
10

All active directory data base security related information store in SYSVOL folder and it’s only created on NTFS partition.

In Microsoft Windows, the System Volume (Sysvol) is a shared directory that stores the server copy of the domain’s public files that must be shared for common access and replication throughout a domain. The term SYSVOL refers to a set of files and folders that reside on the local hard disk of each domain controller in a domain and that are replicated by the File Replication service (FRS). Network clients access the contents of the SYSVOL tree by using the NETLOGON and SYSVOL shared folders.

The Sysvol folder on a Windows domain controller is used to replicate file-based data among domain controllers. Because junctions are used within the Sysvol folder structure, Windows NT file system (NTFS) version 5.0 is required on domain controllers throughout a Windows distributed file system (DFS) forest.

ReplMon

Posted: January 23, 2012 in Active Directory, Server, Server 2003, Server 2008
Tags: , , , ,
2

ReplMon can do the following:

  • See when a replication partner fails.
  • Display changes that have not yet replicated from a given replication partner.
  • Trigger the Knowledge Consistency Checker (KCC) to recalculate the replication topology.
  • View the history of successful and failed replication changes for troubleshooting purposes.
  • Find all direct and transitive replication partners on the network.
  • View the properties of directory replication partners.
  • Display the metadata of an Active Directory object’s attributes.
  • Poll replication partners and generate individual histories of successful and failed replication events.
  • Create your own applications or scripts written in Microsoft Visual Basic Scripting Edition (VBScript) to extract specific data from Active Directory.
  • View a snapshot of the performance counters on the computer, and the registry configuration of the server.
  • Generate status reports that include direct and transitive replication partners, and detail a record of changes.
  • Display replication topology.
  • Force replication.
  • Display a list of the trust relationships maintained by the domain controller being monitored.

Intrasite and Intersite Replication

Posted: August 1, 2011 in Active Directory, Server 2008, System Information
Tags: , , , ,
3

The description of how AD DS replication works applies to both intrasite and intersite replication. In both cases, the domain controllers use the same processes to optimize the replication process. However, one of the main reasons to create additional sites in AD DS is to manage replication traffic. Because all of the domain controllers within a site are assumed to be connected with fast network connections, replication between these domain controllers is optimized for maximum speed and reduced latency. However, if the replication traffic has to cross a slow network link, conserving network bandwidth is a much more significant issue. Creating multiple sites allows for this conservation of network bandwidth by enabling features such as data compression and scheduled AD DS replication.

 

Intrasite Replication

 

The primary goal for replication within a site is to reduce replication latency, that is, to make sure that all domain controllers in a site are updated as quickly as possible. To accomplish this goal, intrasite replication traffic has the following characteristics:

 

  • The replication process is initiated by a notification from the sending domain controller. When a change is made to the database, the sending computer notifies a destination domain controller that changes are available. The changes are then pulled from the sending domain controller by the destination domain controller using a remote procedure call (RPC) connection. After this replication is complete, the domain controller notifies another destination domain controller, which then pulls the changes. This process continues until all the replication partners have been updated.
  • Replication occurs almost immediately after a change has been made to the AD DS information. By default, a domain controller will wait for 15 seconds after a change has been made and then begin replicating the changes to other domain controllers in the same site. The domain controller will complete replication with one partner, wait 3 seconds, and then initiate replication with another partner. The reason the domain controller waits 15 seconds after a change is to increase the efficiency of the replication in case additional changes are made to the partition information.
  • The replication traffic is not compressed. Because all the computers within a site are connected with fast network connections, the data is sent without compression. Compressing the replication data adds an additional load on the domain controller server. Uncompressed replication traffic preserves server performance at the expense of network utilization.
  • Replication traffic is sent to multiple replication partners during each replication cycle. Whenever a change is made to the directory, the domain controller will replicate the information to all direct replication partners, which might be all or some of the other domain controllers in the site.

 

Intersite Replication

 

The primary goal of replication between sites is to reduce the amount of bandwidth used for replication traffic. This means that intersite replication traffic has the following characteristics:

 

  • Replication is initiated according to a schedule rather than when changes are made. To manage replication between sites, you must configure a site link connecting the two sites. One of the configuration options on the site link is a schedule for when replication will occur. Another is the replication interval setting for how often replication will occur during the scheduled time. If the bandwidth between company locations is limited, the replication can be scheduled to happen during nonworking hours.
  • Replication traffic is compressed down to about 40 percent of the noncompressed size when replication traffic is more than 32 KB in size. To save bandwidth on the network connection, the bridgehead servers in each site compress the traffic at the expense of additional CPU usage.
  • Notifications are not used to alert a domain controller in another site that changes to the directory are available. Instead, the schedule determines when to replicate. Note You can disable compression for intersite replication and enable notifications.
  • Intersite replication connections can use either an Internet Protocol (IP) or a Simple Mail Transfer Protocol (SMTP) transport. SMTP can be used as a transport protocol only for the configuration, schema, and application directory partitions, not for the domain partition. The connection protocol you use is determined by the available bandwidth and the reliability of the network that connects company locations.
  • Replication traffic is sent through bridgehead servers rather than to multiple replication partners. When changes are made to the directory in one site, the changes are replicated to a single bridgehead server (per directory partition) in that site, and the changes are then replicated to a bridgehead server in the other site. The changes are replicated from the bridgehead server in the second site to all the domain controllers in that site.
  • You can easily modify the flow of replication between sites. Almost every component of intersite replication can be changed.