Active Directory Lightweight Directory Services (AD LDS) uses replication to provide fault tolerance and load balancing for directory services. AD LDS uses a type of replication called multimaster replication. Through replication, AD LDS copies directory data updates that are made to a directory partition on one AD LDS instance to other AD LDS instances that hold copies of the same directory partition. AD LDS instances that hold copies of the same directory partition or partitions form a logical grouping called a configuration set.
Multimaster replicationMultimaster replication simply means that you can make changes to directory data on any AD LDS instance. AD LDS replicates these changes to other members of the configuration set automatically. Multimaster replication is characterized by loose data consistency with convergence. When you make changes to data on a given directory partition at one AD LDS instance, replicas of that directory partition that are stored on other AD LDS instances become inconsistent with the most up-to-date replica of the directory partition (the partition where the changes were made). However, as changes get replicated through the configuration set, all partition replicas once again become identical; that is, they converge to the most recent data.
Configuration setsAD LDS instances replicate data based on participation in a configuration set. All AD LDS instances that are joined to the same configuration set must replicate a common configuration directory partition and a common schema directory partition. AD LDS instances in a configuration set can also replicate any number of application directory partitions. AD LDS instances in a configuration set are not required to replicate all application directory partitions in the configuration set. A single AD LDS instance can replicate all-or any subset of-the application directory partitions in its configuration set. An AD LDS instance cannot, however, replicate an application directory partition from a different configuration set.
Preventing replication conflictsWhat if two different users make changes to the same data on replicas of the same directory partition on two different AD LDS instances? In this case, each AD LDS instance attempts to replicate the changes, creating a conflict. To resolve this conflict, replication partners that receive these conflicting changes examine the attribute data that is contained in the changes, each of which holds a version and a time stamp. AD LDS instances accept the change with the higher version and discard the other change. If the versions are identical, AD LDS instances accept the change with the more recent time stamp.
If two or more values in a multivalued attribute on an object are updated simultaneously on two different AD LDS instances, only one of the updated values will be replicated. In other words, simultaneous updates to a multivalued attribute that occur on two different AD LDS instances are considered to be in conflict, even if the updates apply to different values within the multivalued attribute. The only exception to this rule is for linked-value attributes (such as group memberships), which do allow for simultaneous updates to different values within the linked-value attribute.
Replication topologyKnowledge Consistency Checker (KCC), a process that runs as part of each AD LDS instance, automatically constructs the most efficient topology for replication traffic to follow based on the network. The KCC regularly recalculates the replication topology to adjust for any network changes that occur in the environment.An AD LDS configuration set maintains its own replication topology, separate from any Active Directory Domain Services (AD DS) replication topology that might also exist. Directory partitions cannot be replicated between AD LDS instances and AD DS domain controllers.
Ensuring replication securityTo ensure replication security, AD LDS authenticates replication partners before replication, and replication authentication always occurs over a secure channel. AD LDS uses Security Support Provider Interface (SSPI) to establish the appropriate authentication security level between replication partners. The method that is used for replication authentication within a configuration set depends on the value of the msDS-ReplAuthenticationModeattribute on the configuration directory partition. After replication partners have successfully authenticated, all replication traffic between the two partners is encrypted.
The following table describes the security levels for replication authentication and the corresponding msDS-ReplAuthenticationMode attribute value for each security level. The default replication security level for a new, unique AD LDS instance is 1, unless a local workstation user account is specified as the AD LDS service account. If a local workstation account is specified as the AD LDS service account, the replication security level is set to 0
To help maintain AD LDS replication security, the following best practices are recommended:
only 2008 servers
In Windows Server 2011 it is called Active Directory.
only 2008 servers
Considerations when Installing a new Windows Server 2008 forestWhen you install AD to create the first domain controller in a new Windows Server 2008 forest, you must keep the following considerations in mind: You must make forest and domain functional level decisions that determine whether your forest and domain can contain domain controllers that run Windows 2000 Server, Windows Server 2003, or both. To read more about forest and domain functional levels please refer to the links below.Domain controllers running the Microsoft Windows NT Server 4.0 operating system are NOT supported with Windows Server 2008.Servers running Windows NT Server 4.0 are NOT supported by domain controllers that are running Windows Server 2008, meaning you MUST have additional DCs running Windows 2000/2003 to support older NT 4.0 servers.The first Windows Server 2008 domain controller in a forest must be a global catalog server and it cannot be an RODC.
In Windows Server 2008, unlike previous server operating Systems, there is an additional step that needs to be taken before running DCPROMO to promote the server to Domain Controller and installing Active Directory on it. This step is the installation of Active Directory Domain Services (AD-DS) role on the server.(dcpromo ad-ds) The AD-DS role is what enables the server to act as a Domain Controller, but you will still need to run DCPROMO from the run.
No, you do not. You only install Active Directory if the system is going to be a domain controller. If it is a member server or a standalone server Active Directory should not be installed.
win 2000 server win 2003 server versions( except web edition) win 2008
One of the new features receiving close attention in Windows 2008 is a new breed of domain controllers referred to as Read-Only Domain Controllers, also known as RODCs. The RODC hosts a copy of the Active Directory (AD) database like any other writable domain controller, but as its name implies, the contents replica of the domain database residing on the domain controller is read-only and write operations are not supported. It is equally important to mention that the RODCs do not participate in Active directory replication in the same fashion as writable domain controllers. The fundamental difference between RODC replication and the typical multimaster replication model between writable domain controllers is that RODCs replication is unidirectional. This means all changes from a writable domain controller are propagated to the RODCs. As a result, the RODC receives changes, but does not partake in or perform outbound replication with other domain controllers. Read-only domain controllers (RODCs) in Active Directory, intended for use in branch office or other scenarios where a domain controller may reside in a low physical security environment. The RODC holds a non-writeable copy of Active Directory, and redirects all write attempts to a Full Domain Controller. It replicates all accounts except sensitive ones.In RODC mode, credentials are not cached by default. Moreover, only the replication partner of the RODC needs to run Windows Server 2008. Also, local administrators can log on to the machine to perform maintenance tasks without requiring administrative rights on the domain.
One of the new features receiving close attention in Windows 2008 is a new breed of domain controllers referred to as Read-Only Domain Controllers, also known as RODCs. The RODC hosts a copy of the Active Directory (AD) database like any other writable domain controller, but as its name implies, the contents replica of the domain database residing on the domain controller is read-only and write operations are not supported. It is equally important to mention that the RODCs do not participate in Active directory replication in the same fashion as writable domain controllers. The fundamental difference between RODC replication and the typical multimaster replication model between writable domain controllers is that RODCs replication is unidirectional. This means all changes from a writable domain controller are propagated to the RODCs. As a result, the RODC receives changes, but does not partake in or perform outbound replication with other domain controllers.
Restartable Active Directory
The Restartable Active Directory, that allows you to have the ntds.dit in offline mode WITHOUT rebooting the domain controller.
Raise the Domain Functional Level for 2008 server Applies To: Windows Server 2008, Windows Server 2008 R2 When you install Active Directory Domain Services (AD DS) on a server running Windows Server 2008 R2, a set of basic Active Directory features is enabled by default. In addition to the basic Active Directory features on individual domain controllers, there are new domain-wide and forest-wide Active Directory features available when all domain controllers in a domain or forest are running Windows Server 2008 R2. For the new domain-wide features to be enabled, all domain controllers in the domain must be running Windows Server 2008 R2, and the domain functional level must be raised to Windows Server 2008 R2. Membership required: Domain Admins or Enterprise Admins To raise the domain functional level 1.Open Active Directory Domains and Trusts. To open Active Directory Domains and Trusts, click Start, click Administrative Tools, and then click Active Directory Domains and Trusts. 2.In the console tree, right-click the domain for which you want to raise functional level, and then click Raise Domain Functional Level. 3.In Select an available domain functional level, do one of the following: * To raise the domain functional level to Windows Server 2008, click Windows Server 2008, and then click Raise. * To raise the domain functional level to Windows Server 2008 R2, click Windows Server 2008 R2, and then click Raise. Caution Do not raise the domain functional level to a later version (such as Windows Server 2008 or Windows Server 2008 R2) if you have or will have any domain controllers running earlier versions of Windows Server. Important After you set the domain functional level to a certain value, you cannot roll back or lower the domain functional level, with one exception: when you raise the domain functional level to Windows Server 2008 R2 and if the forest functional level is Windows Server 2008 or lower, you have the option of rolling the domain functional level back to Windows Server 2008. You can lower the domain functional level only from Windows Server 2008 R2 to Windows Server 2008. If the domain functional level is set to Windows Server 2008 R2, it cannot be rolled back, for example, to Windows Server 2003.