Active Directory Replication error 8304: "The maximum size on an object has been exceeded"

Applies to: Windows Server 2019, all editionsWindows Server 2016Windows Server 2012 R2


This article discusses the causes and solutions for the Active Directory replication error 8304 (0x2070): "The maximum size on an object has been exceeded".

Note You can get the friendly text of the error code by running the "net helpmsg 8304" command.


Symptom 1

The dcdiag command reports that the Active Directory replication test failed and generated error 8304: "The maximum size of an object has been exceeded."

Symptom 2

When you right-click a connection object from a source domain controller (DC), and then you select Replicate now, the replication is unsuccessful and generates the following error message:

Symptom 3

Various repadmin.exe commands fail and generate error 8304. These commands include, but are not limited to, the following:

  • repadmin /add
  • repadmin /replsum
  • repadmin /showrepl
  • repadmin /showrepl
  • repadmin /syncall

Symptom 4

Event ID 1084 is logged in the Directory Service event log of DCs that are trying to replicate Active Directory objects inbound.

You may also see an event 1093:


Error 8304 is logged when the domain controller tries to replicate an object that exceeds the maximum size.

The most commonly cause is having a non-linked attribute with a big number of values. Because of the internal structure of the Active Directory database together with the Active Directory database record size of 8KB, this limit of the values is about 1200-1300 values, depending on the population of other non-linked attributes.

On the source server, when you use a tool like LDP or run the "repadmin /showattr /allvalues /extended" command on the object, the output resembles the following:

The following are the attributes that you may encounter issue:

  • proxyAddresses
  • userCertificate
  • msExchSmtpReceiveRemoteIPRanges
  • dnsRecord
  • msiFileList
  • msTSProperty01, msTSProperty02, …
  • registeredAddress

Note This issue may happen for any multi-valued non-linked attribute. Attribute with syntax linked or linked with data are not affected by this problem.

Depending on the available resources and actual local database page population, the limit may be hit at different number of values. This is why a certain change can be taken by some Domain Controller or LDS instances, but not on others.


This limit is independent of the Microsoft LDAP Server OS version. There is no workaround for this limitation. You need to potentially revise your application and how it uses this attribute.

The 1084 event will list the object that has exceeded the maximum size. If the object is an alive object, identify the attribute that has too many values and remove some of the values on the source domain controller.

If the object is a deleted object, and the Active Directory recycle bin is enabled, the best method to correct the issue is to force the object to become a recycled object. When the object is recycled, Active Directory removes most attributes. This typically reduces the size of the object enough so that it can be replicated successfully. This process will truly delete the object and make it unrecoverable from the recycle bin. If the object is a security principal such as a user account, we recommend that you do not undelete the object. If a sufficiently large object is undeleted, it may prevent some attributes from being correctly set. This can cause the object to be damaged and may prevent the object from being used or even deleted.

The following PowerShell command can be used to force the object into the recycled state.

Note The following command must be run on the DC listed in the 1084 event as the source domain controller. The event will also list the object distinguished name.

Get-ADObject <dn of object> -IncludeDeletedObjects | Remove-ADObject

For example:

Get-ADObject "CN=john\0ADEL:2549ea14-27f7-4891-abaf-d0098c117e79,CN=Deleted Objects,dc=contoso,dc=com" | Remove-ADObject

After the object is recycled, use Active Directory Sites and Services to try to force replication.

Suggestions to avoid the limit from past Microsoft issues


Each IP address or SRV name target is an additional value of the dnsRecord attribute. By default, each domain controller in Active Directory registers a series of names with DNS, some are based on the sites the domain controller covers, some are site-less.

When you approach a lot of domain controllers in a domain, like 1200 domain controllers, there may be issues updating the DNS objects for the names with the additional values. In such a domain, it is also often not desired to have this many entries for site-less names. To avoid this limit, you can create a registry value “DnsAvoidRegisterRecords” on the domain controllers that should not be present in site-less names.

Dynamic Host Configuration Protocol (DHCP) Server activation

In order to avoid rogue DHCP servers, Windows DHCP servers that are members of a domain must find their IP address on an Active Directory object before they return IP addresses from its scopes to clients. This IP address was stored as a value on an Active Directory object, this time forest-wide in the configuration Naming Context (NC).

Similar to the dnsRecord issue, in a forest that has many DHCP servers deployed, the limit may be hit and no more DHCP servers could be authorized. The solution was to have a separate Active Directory object per DHCP Server, with one IP address per object.