Triggering Manual Replication in Active Directory

Hi Guys this post let you how to trigger the manual replication in Active Directory…
So we all know in Active directory replication is very important without replication data will not be sync throughout the AD environment.  When  you troubleshooting AD replication issue, you may wish to manually force replication between two domain controllers in an attempt to correct any inconsistencies or errors that you have found. You may also wish to force replication to occur when you make changes, such as disabling user accounts that you wish to replicate immediately throughout the enterprise without waiting for the next replication interval.

 

In this kind of scenario you can Force Manual Replication, below are the steps you can perform so before going force manual replication you should log on to the domain controller or an administrator workstation that has the Active Directory Administrative Tools installed.

 

Steps:
1.Start---> Run--->  in the Run box you can type dssite.msc then hit enter you will see Active Directory sites and Services (This is shortcut)    or   Click Start--->     Administrative Tools ---> Active Directory Sites and Services will open.
2.Expand the Sites, followed by the site that contains the connection for which you wish to force replication.
3.Locate the server in the Servers container that provides the connection object.
4.Click NTDS Settings in the console tree.
5.In the details pane, right-click the connection for which you want replication to occur and Select Replicate Now

Now you can log in to the remote site DC to check the replication weather that accounts are replicated or not. If changes are replicated successfully then there is no problem at all in your environment, If changes are not replicated then you need to troubleshoot the error based on the event logs, take the DC Diag, check the DNS connectivity, check the FRS, check ADDS services, Need to check Sysvol and netlogon shares and dependent Services. Once you correct the error it should work otherwise there is a problem in environment.
 

Note : When you manually replicating you should not see the errors or warnings if you see any errors or warnings  it seems there is problem with remote site connection or remote site Domain controller problem, The connection object must be pingable and name resolution has to be resolve. Otherwise manual replication will not allow you to replicate. In the step no.5 when you select replicate now it will not replicate it will pop with errors message, if everything is good then it will pop with successful message. When you troubleshoot this kind of problems the major thing you need to check DNS connectivity, Site links and DC status with DC Diag tool.  If you not able to troubleshoot the problem let me know guys I will help you to correct the problem. We have command line tool to trigger the force replication also that will discuss in the next post. Guys let me know if you have any questions or comments on this post.
 

Bridgehead Server Role in Active Directory

Bridgehead Server : 

Hey guys lets discuss about Bridgehead Server in Active Directory, What is Bridgehead Server ? What exactly the bridgehead server responsible in Active Directory ?

So We all know that all domain controllers within the same site will participate in the replication process with each other, not all domain controllers will replicate with other sites simultaneously. This is because replicating Active Directory data between sites using all available domain controllers can be an extremely bandwidth-intensive operation. To further minimize the bandwidth implications of Inter-site replications, Active Directory will designate a bridgehead server within each site.

All traffic within a site is replicated to that site's bridgehead server. The bridgehead server is then responsible for replicating all changes that have taken place within that site to other bridgehead servers in remote sites. The Inter-site Topology Generator ( ISTG ) automatically assigns one server in each site as the bridgehead server unless you override this by establishing a list of preferred bridgehead servers. The advantage of administratively assigning a preferred bridgehead server list is that you can determine which servers have the best processing power and available network bandwidth for handling replication traffic. We should remember that intersite replication traffic is compressed by default, so the bridgehead servers will be responsible for decompressing, compressing, sending and receiving all replication traffic within the site and between sites. Configuring more than one preferred bridgehead server allows administrative control over the task of replicating between sites using the most efficient machines. When more than one preferred bridgehead server is configured and the preferred bridgehead server fails, the KCC will choose another server from the list.

When planning the use of bridgehead servers, we must consider the following guidelines: 

--> Configure a list of preferred bridgehead servers to assist in better performance from site to site. Servers should be chosen based on processing capabilities. Bridgehead servers must compress and decompress replication data efficiently. The server with the slowest processor on your network would not be the best choice for the role of bridgehead server.

--> Configure multiple bridgehead servers for multiple partitions.

--> If a server that has been designated by the ISTG as a preferred bridgehead server fails, the ISTG will assign a new bridgehead server from the configured list. This assumes that you have configured more than one server in the list. It is, therefore, recommended that you configure multiple preferred bridgehead servers whenever possible.

The simple definition of Bridgehead Server is :

" Bridgehead Server is automatically designated by KCC as the contact point for transferring/exchanging  the directory information between sites. And KCC dynamically chooses a server from each site to handle the replication and to minimize the bandwidth usage during Intersite replication or communication". 

Guys I hope your clear about the Bridgehead Server, Let me know if you have any questions and comments or feedback in the below comments section... I will get back to you...

  

Active Directory Replication in Depth

AD Replication In depth (Advanced Concept):

Hi Guys in continuation with my previous post ( Active Directory Replication Process ) Lets talk about replication in depth, so we know how Intra-site and Inter-site replication works, what topology, what protocols, default values and all. But we will have some questions like what happens if a object changes same time in different DCs with in site ?, what happens when a object last name or first name or attribute of object what ever changed in two or more different sites with same value and same time ?, which one actually get updated in the NTDS database ?. These all question will come on our mind.

So now will talk about this. AD needs to be able to track changes from different sources and determine which objects need to be replicated from one domain controller to another. So each domain controller maintains a local value called an update sequence number (USN) that keeps track of changes that are made at each domain controller and thus keeps track of which updates should be replicated to another domain controllers. Lets take small example here consisting of two domain controllers: DC-1 and  DC-2. Now DC-1 has a USN of  100 and DC-2 has USN of 200. An administrator logs on to DC-1 and changes the last name on SRobert's user account, thus incrementing DC-1's USN to 101. When DC-2 requests replication changes from DC-1, now DC-1 will transmit the change in SRobert's last name, which DC-2 will apply to its local copy of the ntds.dit file. Now if again Robert's first name edited on DC-2 then DC-2's USN will increase with 201 then that transmit to DC-1 then that applies to its local copy of ntds.dit file. 

In addition to the USN, each Active Directory attribute has a version ID associated with it, that keeps track of how many times that attribute has been changed. So, if the version ID of SRobert's last name attribute is 3 and an administrator changes it from Robert to Smith to Smith-Robert and back to Robert again, the new version ID of SRobert's last name attribute is now 6. If the same attribute is modified on two domain controllers at the same time, Active Directory will use the version ID as the first tie-breaker to determine which value to keep and which one to discard. So, if Robert's last name attribute n DC-1 has value of Robert and version ID of 6, while DC-2's copy of the SRobert object has been updated with a last name of Smith-Robert with version ID of 5, Active Directory will retain the value of Robert because it has the higher version ID.

If Active Directory cannot use the version ID as tie-breaker, the next tie-breaker is the timestamp, the time when the modification took place. In the case where two conflicting changes have the same version ID, the modification that took place later will be retained by Active Directory.

When replication information between sites, Active Directory will designate a bridgehead server in each site to act as a gatekeeper in managing site-to-site replication. This allows inter-site replication to update only one domain controller within a site. After bridgehead server is updated, it updates the remainder of its domain controller partners with the newly replicated information. For example, suppose the WAN link is down for several hours between two locations of a corporate network. During this time, changes are made to objects and attributes on both sides of the WAN link. When the WAN link comes back online, Active Directory compares the USNs, version IDs, and timestamps of the changes on the bridgehead server on both sides of the WAN link. After determining which updates "win" any tie-breakers that occurred, the bridgehead server in each site contacts its partner bridgehead servers and replicates the new Active Directory changes. After the bridgehead servers in each site have received all the latest replication updates, they will, in turn, continue to replicate the newly obtained information with other partner domain controllers in the same site. Active Directory convergence describes the amount of time that it takes for this process to take place so that all domain controllers in the environment contain the most up-to-date information.

So, in the extremely unlikely event that the version ID and the timestamp are the same, Active Directory will use the globally unique identifier (GUID) of the domain controller where the conflicting modifications took place. The domain controller with the lower GUID will win the third, and final, replication tie-breaker. 

So guys thats how Active Directory Replication work, let me know your comments, feedback and suggestion...

Active Directory Replication Process

Active Directory Replication , Hi.. Lets talk about Active Directory Replication how it works, what topology, protocols and types of replications used in active directory. So first what is replication. ?  Active Directory replication is a process where in a domain controller any creation, modification, deletions are happened to a objects ( Users, Computers, Groups, etc..) that will sync with  other domain controller this process is like  from originating domain controller to destination domain controller which they are connected as one to another  called connection object this process is called replication. This is for providing fault tolerance to active directory database.  

Active Directory creates a replication topology with the idea that all writeable domain controllers in domain should communicate active directory information to each other; in addition to communicating forest-wide information with other domains. Sites and subnets defined within active directory will dictate the path used by replication traffic on the network, as well as form the basis for how active directory information is distributed.

So Lets discuss about Replication types..Active Directory has  two types of replications models..

1. Intrasite Replication  and  2. Intersite Replication. 

1. Intrasite Replication :- Intrasite replication happens between domain controllers with in the same site. Each domain controller uses an internal process called the KCC Knowledge Consistency Checker to map the logical network topology between the domain controllers. For each domain controller in the site, the KCC will select one or more replication partners for that domain controller and will create connection objects between the domain controller and its new replication partners. Each connection object is a one-way connectioni. Therefore, in a site with threee domain controllers, DCA might have a connection object to DCB, but DCB might not have connection ohject with DCA. 

Note: KCC only creates the connection objects but it will not replicate. Replication will happen with the help of RPC (Remote Procedure Call) protocol.

The KCC is a service that runs on domain controllers as part of the Local Security Authority(LSA) service. It cannot be deactivated or removed.

Little bit in depth about KCC:-

The KCC's selection of replication partners and its creation of replication objects is the "Rule of Three", which states that no single domain controller should be more than three network hops away from any domain controller that can originate a change to the Active directory database to minimize the amount of time required for a change to reach all DCs. The KCC is fully automated and does not require administrator intervention unless you have a definite business reason for manually configuring the KCC topology. In fact, there is a significant disadvantage to configuring Active Directory replication links manually.

If we add domain controllers to a site, they become part of the intrasite replication within that site. The KCC will adjust the intrasite replication topology by creating new connection objects to reflect the addition of the newly added DC. We can view these connection objects within the NTDS settings section within the Active Directory sites and Services snap-in for each server object.

The KCC runs every 15 minutes and analyzes the best path and placement for connection objects. If a domain controller or a link between domain controllers has failed, the KCC automatically updates the topology by removing this connection from the list of possible replication paths. Lets take simple example  Consider a single domain containing 2 sites: Site-A and Site-B. Site-A contains two DCs: DC1 and DC2. Site-B contains a single DC, DC3, with a replication connection between DC2 and DC3. In this example, if DC2 fails, the KCC will detect this failure and create a new connection object between DC1 and DC3. By default, intrasite replication is configured to minimize latency to allow changes t take place quickly. Latency is the amount of time or delay it takes for changes to be replicated to all participating domain controllers. The KCC minimizes latency in intrasite replication in a number of ways, 

-- The KCC creates a dual counter-rotating ring for the replication path. If one domain controller in the ring fails, traffic is routed in the opposite direction to allow replication to continue.

--As the site grows, additional connection objects are created to ensure that no more than three hops for replication exist between domain controllers.

--Intrasite replication traffic is not compressed, resulting in fewer CPU cycles at each domain controller during a replication event.

--Domain controllers use change notification to inform one another when changes need to be replicated. Each domain controller will hold a change for 15 seconds before forwarding it, after which it will transmit the changes to each of its replication partners in 3-second intervals. Because the maximum number of hops between domain controllers is three, the maximum replication latency for changes to reach their final destination is 15 seconds plus 3 seconds per replication partners. Certain operations, such as password change or an account lockout, will be transmitted using urgent replication, which means that the change will placed at the "beginning of the line" and will be applied before any other changes that are waiting to be replicated.

Although the KCC process of creating a replication path is fully automatic, it is nonetheless possible to create manual connection objects between domain controllers within the same domain. Creating manual replication connections will allow you t override the replication topology created by the KCC. However, once a manual connection object is created, all automatic connection objects are ignored. Creating manual connection objects also removes the KCC's ability to perform on-the-fly modifications to the replication topology if a domain controller or site link becomes unavailable.

2. Intersite Replication:- In a single word Intersite replication happens between sites like from Site-A to Site-B. Here site represents physical locations. Example : Site-A is USA and Site-B is Australia like that.

If Active Directory information were only replicated within a single site, there would be no way to share object information in the global network. The enterprise network would be made up of many separate LANs that could not share resources, and the idea of centralized administration and single sign-on from anywhere on the network would not be feasible. Recalling that each site consists of one or more IP subnets connected by fast and reliable links.

As I said Active Directory site names generally reflect the name of a physical location and include domain controllers that participate in the domain replication process. Each site contains one or more subnets contained within that site. Consider a company that has a network located in USA with four buildings connected by high speed links. The subnets within these buildings could all be part of the same site. If we add t this network a remote site located in Australia, you would need to create an additional site with subnets that reflect the location's IP address scheme. When we install a domain controller at the Australia location within the same domain as the USA domain controllers, you will need to create a site link in order fr replication to take place between USA and Australia. A site link is a logical, transitive connection between two sites that mirrors the routed connections between networks and allows replication to occur. To crate a replication topology in a multisite network, one domain controller within each site runs the Intersite Topology Generator (ISTG), which is a process that is responsible for selecting a bridgehead server and mapping the topology to be used for replication between sites.

With the exception of the DefaultIPSITELINK, which is created automatically when you install Active Directory, all Active Directory site links need to be created manually. All site link objects possess the following characteristics:

--Site links connect two sites that communicate using the same protocol.

--Site links objects are defined manually.

--Site link objects correspond t the WAN links connecting the sites.

--The ISTG uses site links to establish an intersite replication topology.

The primary goal f intersite replication is to minimize bandwidth usage. Unlike intrasite replication, intersite replication will compress data that is replicated between sites, thus reducing the amount of network traffic used by Active Directory replication.

When we create a site link object we should configure the following three attributes t control the behavior of replication traffic over the site link:

1. Cost,  2. Schedule  and 3. Frequency.

1.Cost:- Assigning a cost to a site link object allows the administrator t define the path that replication will take.If more than one path can be used t replicate information, cost assignments will determine which path is chosen first. A lower-numbered cost value will be chosen over a higher-numbered cost value. Cost values can use a value of 1 to 99,999. No absolute numbering scheme is used here. Instead, the values are chosen by the Active Directory administrator and are relational only to one another. The default cost of a newly crated site link object is 100.

2. Schedule:- The schedule of the site link object determines when the link is available to replicate information. For example :, you may configure a site link's schedule so that it can only transmit replication traffic between midnight and 5am Monday through Friday. You will typically configure this value t reflect off-peak business hours for slow or heavily utilized WAN links to ensure that link bandwidth is not bogged down by replication traffic. By default, newly created site link objects are available for replication 24/7.

3. Frequency:- A site link's frequency determines how often information will be replicated over a particular site link. Replication will take place only during scheduled hours. However, within that scheduled time it can take place as often as the frequency attribute permits. The default replication frequency for a new site link is 180 minutes, but it can be configured to take place as frequently as every 15 minutes and as infrequently as once per week.

The main points to be  noted....
1. Active Directory has two types of Replication model.
2. KCC creates the connection partners, It check every 15 minutes for connection partner if any new DC added or removed also.
3. KCC service runs on every domain controller.
4. Active Directory uses RPC and SMTP protocols for Replication.
5. The Default Intersite replication frequency is 180 minutes. We can configure it to 15 minutes so replication happens every 15 minutes.
6. Intrasite replication frequency is 15 seconds. When changes occurs in DCs it hold for 15 seconds then sends to the partner DCs. Any urgent replications it will not wait for 15 seconds immediately it will replicates.

So guys I hope your clear about the Active Directory replication. If you have any questions, feedback  or suggestions please let me know...The next Advanced replication concepts will discuss in next post.....   

Active Directory Schema

The Active Directory schema defines what different types of objects looks like within Active Directory. Whatt is a user ? what properties does a group have ? Active directory comes with a prepopulated base schema and it can be modified or extended to meet the needs of custom applications.

Every resource in Active Directory is represented as an object and each object has a set of attributes that are associated with it. In Active Directory, each object is defined within the Active Directory schema. The schema is a a master database that contains definitions of all objects in the Active Directory--in a way it defines what Active Directory is. The schema has two components: object classes and attributes. Each object that is represented in Active Directory--for example, the user smith and the printer Laserprinter- is an instance of the user and printer object classes, respectively.

Each object class in the schema is further defined according to a list of attributes that make the object class unique within the database. The list of attributes is defined only once in the schema, but the same attribute can be associated with more than one object class. Some attributes are required attributes that are necessary for the object to be created, such as a user account logon name. Other optional attributes, such as street address and phone number, provide additional details that can be published for user and administrative purposes.

When Active Directory is installed, a number of object classes are created automatically. Some of these object classes include:

Users, Groups, Computers, Domain controllers and printers etc..

All object classes have a common set of attributes that help to uniquely identify each object within the database. Some of these common attributes are as follows:

Unique Name: This name identifies the object in the database. A unique name is given to the object upon its creation and includes references to its location within the directory database. 

Globally unique Identifier (GUID):- This GUID is a 128-bit hexadecimal number that is assigned to every object in the Active Directory forest upon its creation. This number does not change, even when the object itself is renamed. The number is not used again, even if an object is deleted and recreated with the same display name.

Required Object attributes:- These attributes are required for the object to function. In particular the user account must have a unique name and a password entered upon creation.

Optional object attributes:- These attributes add information that is not critical to the object in terms of functionality. This type of information is "nice to know" as opposed to "need to know". An example of an optional object attribute would be a phone number or street address for a user account.

As I said, the schema can be modified to include additional objects and attributes when necessary. Each object in the schema is protected by access control lists (ACLs) so that only authorized administrators can access and modify the schema. ACLs are implemented by the administrator and used by the directory to keep track of which users and groups have permission to access specific objects and to what degree they can use or modify them.

Active Directory Schema plays very important role in AD for object attributes extension. Administrator very carefully do the necessary modification for AD schema.  

Active Directory and Benefits.

What is Active Directory ?
" Active Directory is directory service, Microsoft developed and introduced in windows 2000 Server. It is only used in Microsoft windows domain network environment for security, easy administration and with set of process and services. It provides a centralized authentication service for Microsoft networks". Some of the benefits of Active Directory include a hierarchical organizational structure, Multi-Master authentication (the ability to access and modify AD from multiple points of administration) to create fault tolerance and redundancy, a single point of access to network resources.

Active Directory contains user, computers, groups, sites, organization units, servers, domain controllers, printers and applications. All these we can access from  Start --> Administrative tools
Active Directory Users and Computers,
Active Directory Domains and Trusts and
Active Directory Sites and Services.

A  Directory  Service allows businesses to define, manage, access, and secure network resources, including files, printers, people, and applications. Without the efficiency of a directory service, businesses would have difficulty keeping up with demands fr fast-paced data exchange. As corporate networks continue to grow in complexity and importance, businesses require more and more from the networks that facilitate this automation.

The Active Directory benefits are

1. Centralized resource and security administration

2. single logon for access to global resources

3. Fault tolerance and redundancy

4.Simplified resource location. 

Centralizing Resource and Security Administration:

 Active Directory provides a single point from which administrators can manage and access network resources and their associated security objects. An organization can administer Active directory based on an organizational model, a business model or the types of functions being administered. For example, an organization could choose to administer Active Directory by logically dividing the users according to the departments (by creating the OUs) in which they work, their geographical location (by creating the sites) or a combination of these characteristics.

Providing a Single Point of Access t Resources:

Prior to the introduction of directory services into corporate networks, all users were required t log n to many different servers in order t access a variety of different resources. This required users to enter their authentication information multiple times and an administrator had to maintain duplicate user accounts n every server in the organization. Imagine how enormous the tasks of managing a separate username and password n each server would be if your organization contained 10 servers and 10 users per server. Now imagine how much more difficult that would become with 10 servers and 500 users per server. You would have to create and maintain 5,000 user accounts, with all of the associated security assignments, if you were maintaining separate authentication for each individual server.

Fault Tolerance and Redundancy:

A system is said t be fault tolerant if it is capable of responding gracefully t a software or hardware failure. For example, a server is fault tolerant if it can continue to function when a power supply or a hard drive suffers a mechanical failure. An authentication system such as active Directory is considered fault tolerant when it has the ability to continue providing authentication service even if one or more servers that provide authentication services (in the case of AD DS domain controllers) experience hardware failure or a loss of network connectivity. In this way, Active Directory can offer a redundant solution which can continue to provide authentication services without any adverse effects noticed by users, workstations, or other applications or services. 

Active Directory builds in fault tolerance through its multimaster domain controllers design. This fault tolerance is created due t the fact that all domain controllers in an Active Directory domain share a common database file called ntds.dit; any change that is made on one domain controllers is replicated to all other domain controllers in the environment. This ensures that all domain controllers have consistent information about the domain.

Simplifying Resource Location:

Imagine you are a user in a 10-server environment, where every server has a different set of resources that you need to do your job. If you were in this situation, identifying which server provided each resource would not be an easy task. This is even more complicate4d when you have mobile users, such as an employee visiting from another site who needs to locate printers and other devices to become productive at the new site.

Active Directory simplifies this process by allowing file and print resources to be published on the network.  Publishing an object  allows users t access network resources by searching the Active Directory database for the desired resource.

We have many more benefits and feature of Active Directory based on Server versions and domain and forest functional levels.

Guys feel free to ask questions about active directory you can write below at comments section, I will get back to you as soon as possible....