Best Practices for Virtualizing Active Directory Domain Controllers (AD DC), Part II

EMC logo


Virtualized Active Directory is ready for Primetime, Part II!

In the first of this two-part blog series, I discussed how virtualization-first is the new normal and fully supported; and elaborated on best practices for Active Directory availability, achieving integrity in virtual environments, and making AD confidential and tamper-proof.

In this second installment, I’ll discuss the elements of time in Active Directory, touch on replication, latency and convergence; the preventing and mediating lingering objects, cloning and of much relevance, preparedness for Disaster Recovery.

Proper Time with Virtualized Active Directory Domain Controllers (AD DC)

Time in virtual machines can easily drift if they are not receiving constant and consistent time cycles. Windows operating systems keep time based on interrupt timers set by CPU clock cycles. In a VMware ESXi host with multiple virtual machines, CPU cycles are not allocated to idle virtual machines.

To plan for an Active Directory implementation, you must carefully consider the most effective way of providing accurate time to domain controllers and understand the relationship between the time source used by clients, member servers, and domain controllers.

The Domain Controller with the PDC Emulator role for the forest root domain ultimately becomes the “master” timeserver for the forest – the root time server for synchronizing the clocks of all Windows computers in the forest. You can configure the PDC to use an external source to set its time. By modifying the defaults of this domain controller’s role to synchronize with an alternative external stratum 1 time source, you can ensure that all other DCs and workstations within the domain are accurate.

Why Time Synchronization Is Important in Active Directory

Every domain-joined device is affected by time!

Ideally, all computer clocks in an AD DS domain are synchronized with the time of an authoritative computer. Many factors can affect time synchronization on a network. The following factors often affect the accuracy of synchronization in AD DS:

  • Network conditions
  • The accuracy of the computer’s hardware clock
  • The amount of CPU and network resources available to the Windows Time service

Prior to Windows Server 2016, the W32Time service was not designed to meet time-sensitive application needs. Updates to Windows Server 2016 allow you to implement a solution for 1ms accuracy in your domain.

Figure 1: How Time Synchronization Works in Virtualized Environments

See Microsoft’s How the Windows Time Service Works for more information.

How Synchronization Works in Virtualized Environments

An AD DS forest has a predetermined time synchronization hierarchy. The Windows Time service synchronizes time between computers within the hierarchy, with the most accurate reference clocks at the top. If more than one time source is configured on a computer, Windows Time uses NTP algorithms to select the best time source from the configured sources based on the computer’s ability to synchronize with that time source. The Windows Time service does not support network synchronization from broadcast or multicast peers.

Replication, Latency and Convergence

Eventually, changes must converge in a multi-master replication model…

The Active Directory database is replicated between domain controllers. The data replicated between controllers called ‘data’ are also called ‘naming context.’ Only the changes are replicated, once a domain controller has been established. Active Directory uses a multi-master model; changes can be made on any controller and the changes are sent to all other controllers. The replication path in Active Directory forms a ring which adds reliability to the replication.

Latency is the required time for all updates to be completed throughout all domain controllers on the network domain or forest.

Convergence is the state at which all domain controllers have the same replica contents of the Active Directory database.

Figure 2: How Active Directory Replication Works

For more information on Replication, Latency and Convergence, see Microsoft’s Detecting and Avoiding Replication Latency.”

Preventing and Remediating Lingering Objects

Don’t revert to snapshot or restore backups beyond the TSL.

Lingering objects are objects in Active Directory that have been created, replicated, deleted, and then garbage collected on at least the Domain Controller that originated the deletion but still exist as live objects on one or more DCs in the same forest. Lingering object removal has traditionally required lengthy cleanup sessions using various tools, such as the Lingering Objects Liquidator (LoL).

Dominant Causes of Lingering Objects

  1. Long-term replication failures

While knowledge of creates and modifies are persisted in Active Directory forever, replication partners must inbound replicate knowledge of deleted objects within a rolling Tombstone Lifetime (TSL) # of days (default 60 or 180 days depending on what OS version created your AD forest). For this reason, it’s important to keep your DCs online and replicating all partitions between all partners within a rolling TSL # of days. Tools like REPADMIN /SHOWREPL * /CSV, REPADMIN /REPLSUM and AD Replication Status should be used to continually identify and resolve replication errors in your AD forest.

  1. Time jumps

System time jump more than TSL # of days in the past or future can cause deleted objects to be prematurely garbage collected before all DCs have inbound replicated knowledge of all deletes. The protection against this is to ensure that:

  • The forest root PDC is continually configured with a reference time source (including following FSMO transfers).
  • All other DCs in the forest are configured to use NT5DS hierarchy.
  • Time rollback and roll-forward protection has been enabled via the maxnegphasecorrection and maxposphasecorrection registry settings or their policy-based equivalents.
  • The importance of configuring safeguards can’t be stressed enough.
  1. USN rollbacks

USN rollbacks are caused when the contents of an Active Directory database move back in time via an unsupported restore. Root causes for USN Rollbacks include:

  • Manually copying previous version of the database into place when the DC is offline.
  • P2V conversions in multi-domain forests.
  • Snapshot restores of physical and especially virtual DCs. For virtual environments, both the virtual host environment AND the underlying guest DCs should be compatible with VM Generation ID. Windows Server 2012 or later, and vSphere 5.0 Update 2 or later, support this feature.
  • Events, errors and symptoms that indicate you have lingering objects.

Figure 3: USN Rollbacks – How Snapshots Can Wreak Havoc on Active Directory

Cloning

You should always use a test environment before deploying the clones to your organization’s network.

DC Cloning enables fast, safer Domain Controller provisioning through clone operation.

When you create the first domain controller in your organization, you are also creating the first domain, the first forest, and the first site. It is the domain controller, through group policy, that manages the collection of resources, computers, and user accounts in your organization.

Active Directory Disaster Recovery Plan: It’s a Must

Build, test, and maintain an Active Directory Disaster Recovery Plan!

AD is indisputably one of an organization’s most critical pieces of software plumbing and in the event of a catastrophe – the loss of a domain or forest – its recovery is a monumental task. You can use Site Recovery to create a disaster recovery plan for Active Directory.

Microsoft Active Directory Disaster Recovery Plan is an extensive document; a set of high-level procedures and guidelines that must be extensively customized for your environment and serves as a vital point of reference when determining root cause and how to proceed with recovery with Microsoft Support.

Summary

There are several excellent reasons for virtualizing Windows Active Directory. The release of Windows Server 2012 and its virtualization-safe features and support for rapid domain controller deployment alleviates many of the legitimate concerns that administrators have about virtualizing AD DS. VMware® vSphere® and our recommended best practices also help achieve 100 percent virtualization of AD DS.

Please reach out to your Dell EMC representative or checkout Dell EMC Consulting Services to learn how we can help you with virtualizing AD DS or leave me a comment below and I’ll be happy to respond back to you.

Sources

Virtualizing a Windows Active Directory Domain Infrastructure

Related Blog

Best Practices for Virtualizing Active Directory Domain Controllers (AD DC), Part I

The post Best Practices for Virtualizing Active Directory Domain Controllers (AD DC), Part II appeared first on InFocus Blog | Dell EMC Services.


Update your feed preferences


   

   


   


   

submit to reddit
   

Related:

  • No Related Posts

Error adding a Directory Junction, “A NETBIOS name could not be found for this Directory Junction”

The process of verifying the AD junction can be seen in web.log. When you click the Create Directory Junction button at the end, we load several pieces of data from AD through the LDAP connection you have just built, including the NetBIOSName parameter.

Specifically, we are doing this:

2018-10-02 14:24:46,418 INFO [766] CDJCH LDAPService: Searching under ‘CN=Partitions,CN=Configuration,DC=domain,DC=dom’ using ‘(&(objectcategory=Crossref)(netBIOSName=*)(nCName=DC=sub1,DC=domain,DC=dom))’

That is, we are searching, under the root domain “domain.dom”, the Configuration contained, and in that, the Partitions container, and inside that, sub1..domai.dom. (If there is no “sub1”, then we’re simply looking for domain.dom here). We’re retrieving the NetBISName attribute of the selected domain.

This parameter should always be set. However, if the service account you have specified has no permissions to view this area, then we may be unable to retrieve the NetBIOSName attribute, and the process will fail.

To see the attribute, you cannot use Active Directory Users and Computers. You need to use ADSI Edit. When connecting to your server, select “Select a well known naming context” and in that pulldown, select Configuration. Then you will be able to see Partitions, and the information inside it. Get Properties on your domain or subdomain and check for the NetBIOSName attribute.

Related:

  • No Related Posts

How do you generate AD_InvalidLogon_User_Accounts.csv with the ITCAM for Active Directory agent?

Need the steps to generate the AD_InvalidLogon_User_Accounts.csv
to get information about the locked users in AD via the ITCAM for Active Directory agent.

Related:

Event ID 1983 — Application Directory Partition Default Security

Event ID 1983 — Application Directory Partition Default Security

Updated: November 25, 2009

Applies To: Windows Server 2008

When you create a new application directory partition, a new security descriptor is calculated and assigned to the application directory partition object.

Event Details

Product: Windows Operating System
ID: 1983
Source: Microsoft-Windows-ActiveDirectory_DomainService
Version: 6.0
Symbolic Name: DIRLOG_SCHEMA_CLASS_EDC_ACE_CREATE_FAILURE
Message: AD_TERM failed to create an access control entry (ACE) for the Enterprise Domain Controllers group or the Enterprise Read-only Domain Controllers group on a newly created application directory partition. Application directory partition: %3 User Action Review the access control list (ACL) on the newly created application directory partition. Ensure the Replication Get Changes All access right is assigned to both the Enterprise Domain Controllers group and the Enterprise Read-only Domain Controllers group, and remove the right from the domain Domain Controllers group.

Resolve
Ensure that the ACL on the application directory partition is configured properly

To resolve this issue, ensure that the access control list (ACL) has the appropriate access control entries (ACEs) on the application directory partition that is referred to in the Event Viewer event text. Perform the following procedure on a domain member computer that has domain administrative tools installed.

To perform this procedure, you must have membership in Domain Admins, or you must have been delegated the appropriate authority.

To ensure that the ACL on the application directory partition is correct:

  1. Open ADSI Edit. To open ADSI Edit, click Start. In Start Search, type ADSIEdit.msc, and then press ENTER. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.
  2. Right-click ADSI Edit, and then click Connect to.
  3. In Connection Point, click Select or type a Distinguished Name or Naming Context. Type a properly formatted Lightweight Directory Access Protocol (LDAP) path to the application directory partition that is referred to in the event text, for example, dc=App,dc=contoso,dc=com.
  4. If you are not already connected to the server and domain that you want to manage, type the appropriate domain and server names under Computer.
  5. Click OK.
  6. In the console tree, expand the Default naming context object to which you connected in the previous steps.
  7. Right-click the application directory partition that is identified in the event text, and then click Properties.
  8. Click Security.
  9. In Group or user names, select the ENTERPRISE DOMAIN CONTROLLERS group, and ensure that the Allow check box is selected for the following permission entries: Replicating Directory Changes, Replicating Directory Changes All, Replicating Directory Changes In, and Replication synchronization.
  10. In Group or user names, select the Enterprise Read-only Domain Controllers group, and ensure that the Allow check box is selected for the permission entry Replicating directory changes.
  11. If the Domain Controllers group appears in Group or user names, select it, and ensure that the Allow check box is cleared (not selected) for the permission entry Replicating directory changes.
  12. Click OK.
  13. Close ADSI Edit.

Note: In ADSI Edit, the permission “Replicating Directory Changes All” may be missing the final letter in the word “All.” The permission Replicating Directory Changes In, should be Replicating Directory Changes In Filtered Set, as it is shown correctly in other interfaces.

Verify

After you create an application directory partition, check Event Viewer for the following Event IDs: 1979, 1980, 1981, 1982, and 1983. If you find these events after you create an application directory partition, the attempt to create the partition failed. For more information about extending the schema properly, see Security Descriptor String Format (http://go.microsoft.com/fwlink/?LinkId=96260).

To perform this procedure, you must have membership in Domain Admins, or you must have been delegated the appropriate authority.

To verify the creation of an application directory partition by using Event Viewer:

  1. Open Event Viewer. To open Event Viewer, click Start. In Start Search, type eventvwr.msc, and then press ENTER. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.
  2. Expand Applications and Services Logs, and then click Directory Service.
  3. Click Find, type 1979, and then click Find Now.
  4. Click Find Next to search for additional events as necessary.
  5. Repeat steps 2 through 4 to search for Event IDs 1980, 1981, 1982, and 1983.

Related Management Information

Application Directory Partition Default Security

Active Directory

Related:

Event ID 1982 — Application Directory Partition Default Security

Event ID 1982 — Application Directory Partition Default Security

Updated: November 25, 2009

Applies To: Windows Server 2008

When you create a new application directory partition, a new security descriptor is calculated and assigned to the application directory partition object.

Event Details

Product: Windows Operating System
ID: 1982
Source: Microsoft-Windows-ActiveDirectory_DomainService
Version: 6.0
Symbolic Name: DIRLOG_SCHEMA_CLASS_DDC_REMOVE_FAILURE
Message: AD_TERM was unable to delete the access control entry (ACE) for the domain Domain Controllers security group on the newly created application directory partition. This ACE gave the domain Domain Controllers security group the Replication Get Changes All right for the following newly created application directory partition. Application directory partition: %3 User Action Review the access control list (ACL) on the newly created application directory partition. Ensure the right Replication Get Changes All is given to both the Enterprise Domain Controllers group and the Enterprise Read-only Domain Controllers group, and remove that right from the domain Domain Controllers group. Additional Data Error value: %1 %2

Resolve
Ensure that the ACL on the application directory partition is configured properly

To resolve this issue, ensure that the access control list (ACL) has the appropriate access control entries (ACEs) on the application directory partition that is referred to in the Event Viewer event text. Perform the following procedure on a domain member computer that has domain administrative tools installed.

To perform this procedure, you must have membership in Domain Admins, or you must have been delegated the appropriate authority.

To ensure that the ACL on the application directory partition is correct:

  1. Open ADSI Edit. To open ADSI Edit, click Start. In Start Search, type ADSIEdit.msc, and then press ENTER. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.
  2. Right-click ADSI Edit, and then click Connect to.
  3. In Connection Point, click Select or type a Distinguished Name or Naming Context. Type a properly formatted Lightweight Directory Access Protocol (LDAP) path to the application directory partition that is referred to in the event text, for example, dc=App,dc=contoso,dc=com.
  4. If you are not already connected to the server and domain that you want to manage, type the appropriate domain and server names under Computer.
  5. Click OK.
  6. In the console tree, expand the Default naming context object to which you connected in the previous steps.
  7. Right-click the application directory partition that is identified in the event text, and then click Properties.
  8. Click Security.
  9. In Group or user names, select the ENTERPRISE DOMAIN CONTROLLERS group, and ensure that the Allow check box is selected for the following permission entries: Replicating Directory Changes, Replicating Directory Changes All, Replicating Directory Changes In, and Replication synchronization.
  10. In Group or user names, select the Enterprise Read-only Domain Controllers group, and ensure that the Allow check box is selected for the permission entry Replicating directory changes.
  11. If the Domain Controllers group appears in Group or user names, select it, and ensure that the Allow check box is cleared (not selected) for the permission entry Replicating directory changes.
  12. Click OK.
  13. Close ADSI Edit.

Note: In ADSI Edit, the permission “Replicating Directory Changes All” may be missing the final letter in the word “All.” The permission Replicating Directory Changes In, should be Replicating Directory Changes In Filtered Set, as it is shown correctly in other interfaces.

Verify

After you create an application directory partition, check Event Viewer for the following Event IDs: 1979, 1980, 1981, 1982, and 1983. If you find these events after you create an application directory partition, the attempt to create the partition failed. For more information about extending the schema properly, see Security Descriptor String Format (http://go.microsoft.com/fwlink/?LinkId=96260).

To perform this procedure, you must have membership in Domain Admins, or you must have been delegated the appropriate authority.

To verify the creation of an application directory partition by using Event Viewer:

  1. Open Event Viewer. To open Event Viewer, click Start. In Start Search, type eventvwr.msc, and then press ENTER. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.
  2. Expand Applications and Services Logs, and then click Directory Service.
  3. Click Find, type 1979, and then click Find Now.
  4. Click Find Next to search for additional events as necessary.
  5. Repeat steps 2 through 4 to search for Event IDs 1980, 1981, 1982, and 1983.

Related Management Information

Application Directory Partition Default Security

Active Directory

Related:

Event ID 1979 — Application Directory Partition Default Security

Event ID 1979 — Application Directory Partition Default Security

Updated: November 25, 2009

Applies To: Windows Server 2008

When you create a new application directory partition, a new security descriptor is calculated and assigned to the application directory partition object.

Event Details

Product: Windows Operating System
ID: 1979
Source: Microsoft-Windows-ActiveDirectory_DomainService
Version: 6.0
Symbolic Name: DIRLOG_SCHEMA_CLASS_DEFAULT_MOD_FAILED
Message: AD_TERM was unable to correctly create the default security descriptor for the following application directory partition. Application directory partition: %3 User Action Review the access control list (ACL) on the newly created application directory partition. Ensure the Replication Get Changes All access right is assigned to both the Enterprise Domain Controllers group and the Enterprise Read-only Domain Controllers group, and remove the right from the domain Domain Controllers group. Additional Data Error value: %1 %2

Resolve
Ensure that the ACL on the application directory partition is configured properly

To resolve this issue, ensure that the access control list (ACL) has the appropriate access control entries (ACEs) on the application directory partition that is referred to in the Event Viewer event text. Perform the following procedure on a domain member computer that has domain administrative tools installed.

To perform this procedure, you must have membership in Domain Admins, or you must have been delegated the appropriate authority.

To ensure that the ACL on the application directory partition is correct:

  1. Open ADSI Edit. To open ADSI Edit, click Start. In Start Search, type ADSIEdit.msc, and then press ENTER. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.
  2. Right-click ADSI Edit, and then click Connect to.
  3. In Connection Point, click Select or type a Distinguished Name or Naming Context. Type a properly formatted Lightweight Directory Access Protocol (LDAP) path to the application directory partition that is referred to in the event text, for example, dc=App,dc=contoso,dc=com.
  4. If you are not already connected to the server and domain that you want to manage, type the appropriate domain and server names under Computer.
  5. Click OK.
  6. In the console tree, expand the Default naming context object to which you connected in the previous steps.
  7. Right-click the application directory partition that is identified in the event text, and then click Properties.
  8. Click Security.
  9. In Group or user names, select the ENTERPRISE DOMAIN CONTROLLERS group, and ensure that the Allow check box is selected for the following permission entries: Replicating Directory Changes, Replicating Directory Changes All, Replicating Directory Changes In, and Replication synchronization.
  10. In Group or user names, select the Enterprise Read-only Domain Controllers group, and ensure that the Allow check box is selected for the permission entry Replicating directory changes.
  11. If the Domain Controllers group appears in Group or user names, select it, and ensure that the Allow check box is cleared (not selected) for the permission entry Replicating directory changes.
  12. Click OK.
  13. Close ADSI Edit.

Note: In ADSI Edit, the permission “Replicating Directory Changes All” may be missing the final letter in the word “All.” The permission Replicating Directory Changes In, should be Replicating Directory Changes In Filtered Set, as it is shown correctly in other interfaces.

Verify

After you create an application directory partition, check Event Viewer for the following Event IDs: 1979, 1980, 1981, 1982, and 1983. If you find these events after you create an application directory partition, the attempt to create the partition failed. For more information about extending the schema properly, see Security Descriptor String Format (http://go.microsoft.com/fwlink/?LinkId=96260).

To perform this procedure, you must have membership in Domain Admins, or you must have been delegated the appropriate authority.

To verify the creation of an application directory partition by using Event Viewer:

  1. Open Event Viewer. To open Event Viewer, click Start. In Start Search, type eventvwr.msc, and then press ENTER. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.
  2. Expand Applications and Services Logs, and then click Directory Service.
  3. Click Find, type 1979, and then click Find Now.
  4. Click Find Next to search for additional events as necessary.
  5. Repeat steps 2 through 4 to search for Event IDs 1980, 1981, 1982, and 1983.

Related Management Information

Application Directory Partition Default Security

Active Directory

Related:

Event ID 1980 — Application Directory Partition Default Security

Event ID 1980 — Application Directory Partition Default Security

Updated: November 25, 2009

Applies To: Windows Server 2008

When you create a new application directory partition, a new security descriptor is calculated and assigned to the application directory partition object.

Event Details

Product: Windows Operating System
ID: 1980
Source: Microsoft-Windows-ActiveDirectory_DomainService
Version: 6.0
Symbolic Name: DIRLOG_SCHEMA_CLASS_DEFAULT_SD_MISSING
Message: The default access control list (ACL) on the following Domain-DNS object class has been previously removed. All subsequently created domain and application directory partitions will permit insecure access. User Action To secure access to domain and application directory partitions created in the future, revert the default security descriptor on the Domain-DNS object class in the schema back to the default setting.

Resolve
Revert the default security descriptor on the Domain-DNS object class

Security checks on the application directory partiton are disabled because the default security descriptor on the Domain-DNS object class is empty. To resolve this issue, you must revert the default security descriptor on the object class to its default setting. Perform the following procedure on the computer that is logging the event to be resolved.

To perform this procedure, you must have membership in Domain Admins and Schema Admins, or you must have been delegated the appropriate authority.

To revert the default security descriptor on the Domain-DNS object class:

  1. Open ADSI Edit. To open ADSI Edit, click Start. In Start Search, type ADSIEdit.msc, and then press ENTER. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.
  2. Right-click ADSI Edit, and then click Connect to.
  3. In Select a well known Naming Context, click Schema. The default action of the tool is to connect to the local domain. If you want to connect to another domain or server, you can do that under Computer in the Connection Settings dialog box.
  4. Click OK.
  5. In the console tree, expand the Schema object.
  6. Click the object that starts with CN=Schema, CN=Configuration.
  7. In the middle pane, a three-column list of attribute names, classes, and distinguished names appears. In the Name column, right-click the CN=Domain-DNS class, and then click Properties.
  8. In the list of attributes that appears in the Domain-DNS Properties box, select the defaultSecurityDescriptor attribute, and then click Edit.
  9. In String Attribute Editor, insert a correctly formatted security descriptor in the Value box. For information about formatting a security descriptor, see Security Descriptor String Format (http://go.microsoft.com/fwlink/?LinkID=96260).
  10. Click OK.
  11. Close ADSI Edit.
  12. Restart the computer.

Verify

After you create an application directory partition, check Event Viewer for the following Event IDs: 1979, 1980, 1981, 1982, and 1983. If you find these events after you create an application directory partition, the attempt to create the partition failed. For more information about extending the schema properly, see Security Descriptor String Format (http://go.microsoft.com/fwlink/?LinkId=96260).

To perform this procedure, you must have membership in Domain Admins, or you must have been delegated the appropriate authority.

To verify the creation of an application directory partition by using Event Viewer:

  1. Open Event Viewer. To open Event Viewer, click Start. In Start Search, type eventvwr.msc, and then press ENTER. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.
  2. Expand Applications and Services Logs, and then click Directory Service.
  3. Click Find, type 1979, and then click Find Now.
  4. Click Find Next to search for additional events as necessary.
  5. Repeat steps 2 through 4 to search for Event IDs 1980, 1981, 1982, and 1983.

Related Management Information

Application Directory Partition Default Security

Active Directory

Related:

Event ID 1977 — Replication Changes

Event ID 1977 — Replication Changes

Updated: November 25, 2009

Applies To: Windows Server 2008

The replication process in Active Directory Domain Services (AD DS) ensures that domain controllers are able to maintain a consistent and updated Active Directory database. Because the Active Directory database holds essential information about user, group, and computer accounts, as well as other resources and services and the network configuration, keeping this information consistent on all the domain controllers is important. Failure of the Active Directory replication process can result in the following problems:

  • Failure of applications that rely on consistent Active Directory information to function properly
  • Logon rejections
  • Password change failures
  • Network service failures
  • Incorrect or outdated information retrieval

For more information, see How Active Directory Replication Topology Works (http://go.microsoft.com/fwlink/?LinkID=93526).

Event Details

Product: Windows Operating System
ID: 1977
Source: Microsoft-Windows-ActiveDirectory_DomainService
Version: 6.0
Symbolic Name: DIRLOG_DRA_REPLICATION_ALL_ACCESS_DENIED_DC
Message: The following directory service made a replication request for a writable directory partition that has been denied by the local directory service. The requesting directory service does not have access to a writable copy of this directory partition.
Requesting directory service: %2
Directory partition: %1
User Action
If the requesting directory service must have a writable copy of this partition, verify that the security descriptor on this directory partition has the correct configuration for the Replication Get Changes All access right. You may also get this message during the transition period after a child partition has been removed. This message will cease when knowledge of the child partition removal has replicated throughout the forest.
.

Resolve
Ensure that the security descriptors are set correctly on the directory partition

To perform this procedure, you must have membership in Domain Admins, or you must have been delegated the appropriate authority.

To ensure that the security descriptor is set correctly on the directory partition:

  1. On any domain controller in the domain, open ADSI Edit. To open ADSI Edit, click Start. In Start Search, type ADSIEdit.msc, and then press ENTER. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.
  2. If the directory partition from the error message does not appear, in the console tree, right-click ADSI Edit, and then click Connect to. In Connection Point, type the Lightweight Directory Access Protocol (LDAP) path of the partition from the error message into Select or type a Distinguished Name or Naming Context (for example, DC=cpandl,DC=com), and then click OK.
  3. In the console tree, expand the object that represents the naming context of the partition from the error message. You should see another object with the LDAP path (for example, DC=cpandl,DC=com) that was identified in the event message text.
  4. Right-click the object that has the name of the LDAP path from the event message text, and then click Properties.
  5. On the Security tab, in the Group or user names box, click Enterprise Read-only Domain Controllers. If the Enterprise Read-only Domain Controllers group, or any other group that is mentioned in the following steps, does not appear in the Group or user names box, click Add. Type the name of the group, and then click OK.
  6. In Permissions for Enterprise Read-only Domain Controllers, ensure that the Allow check box is selected for the permission Replicating directory changes. If you are configuring permissions on the Schema partition, also ensure that the Allow check box is selected for the permissions Replicating Directory Changes In and Replicating directory changes all.
  7. In Group or user names, click ENTERPRISE DOMAIN CONTROLLERS.
  8. In Permissions for ENTERPRISE DOMAIN CONTROLLERS, ensure that the Allow check box is selected for the following permissions: Replicating directory changes, Replicating Directory Changes In, Replicating directory changes all, and Replication synchronization.

    If you are configuring a domain partition, proceed with the next step. If you are not configuring a domain partition, you may skip the next two steps.

  9. In the Group or user names box, click Domain Controllers.
  10. In Permissions for Domain Controllers, ensure that the Allow check box is selected for the permission Replicating directory changes all.
  11. Click OK.
  12. Close ADSI Edit.

Note: In ADSI Edit, the permission “Replicating Directory Changes All” may be missing the final letter in the word “All.” The permission Replicating Directory Changes In, should be Replicating Directory Changes In Filtered Set, as it appears correctly in other interfaces.

Verify

Perform the following tasks using the domain controller from which you want to verify that Active Directory replication is functioning properly.

To perform this procedure, you must have membership in Domain Admins, or you must have been delegated the appropriate authority.

To verify that Active Directory replication is functioning properly:

  1. Open a command prompt as an administrator. To open a command prompt as an administrator, click Start. In Start Search, type Command Prompt. At the top of the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.
  2. Run the command repadmin /showrepl. This command displays the status reports on all replication links for the domain controller. Active Directory replication is functioning properly on this domain controller if all status messages report that the last replication attempt was successful.

If there are any indications of failure or error in the status report following the last replication attempt, Active Directory replication on the domain controller is not functioning properly. If the repadmin command reports that replication was delayed for a normal reason, wait and try repadmin again in a few minutes.

Related Management Information

Replication Changes

Active Directory

Related: