ERROR_DS_OBJ_TOO_LARGE 0x2078: Fix AD Object Too Large

Quick answer: An AD object (nearly always a security or distribution group) exceeded the 1 MB per-attribute replication limit. Either trim the membership back under the ceiling or raise dsReplicaMaxObjSize on every DC — but trimming is the real fix.

What's actually going on

Active Directory stores each object as a set of attributes, and replication ships those attributes between DCs. There's a hard cap on how big any single write can be — 1 MB when it's counted across all the attributes on the object. Go over that and the DC refuses the write with ERROR_DS_OBJ_TOO_LARGE, hex 0X00002078. You'll usually see it dressed up as replication error 8524, event ID 1079 in the Directory Service log on the receiving DC, or as The specified object is too large in whatever tool you were using when you tried to add that 40,000th user to a group.

The trigger I've seen more than any other: someone (or a script) dumps 20k+ members into a distribution or security group, and the member attribute alone crosses the line. It also shows up after a messy Exchange migration where you end up with a group carrying tens of thousands of mail and proxyAddresses values. Occasionally it's a schema attribute you extended yourself — a custom attribute you accidentally set to Directory String with no upper bound, and someone dumped a 2 MB XML blob into it.

The other thing worth knowing: the default group member limit for Exchange distribution groups is 5,000 members. That's a separate, softer limit set in Exchange, not AD. The 1 MB replication limit is a different beast entirely and it applies to every AD object, not just groups.

Fix 1: Shrink the object (do this first)

Nine times out of ten this is the whole fix. Find the offending group and break it up.

Open an elevated PowerShell on a DC (or any machine with RSAT).
Pull the member counts for every group over a few thousand, sorted descending:

Get-ADGroup -Filter * -Properties member -Server dc01.contoso.com |
  Select-Object Name, DistinguishedName, @{N='Count';E={$_.member.Count}} |
  Where-Object Count -gt 2000 |
  Sort-Object Count -Descending |
  Format-Table -AutoSize

Pick the fat one and check what's actually in it:

Get-ADGroupMember -Identity "BigGroupName" -Recursive |
  Measure-Object | Select-Object Count

If it's a distribution group, split it into several child groups and point the parent at them. Nested groups count toward the size, but each child stays under the ceiling.

If it's a security group and you truly need everyone in it, stop. You don't. Use a Universal group at the forest root for members, then nest that single universal group into your domain-local groups. Replication of universal groups is cached differently and the membership attribute stays small on the D-L groups.

Force replication and confirm:

repadmin /replicate dc02 dc01 "DC=contoso,DC=com"
repadmin /showrepl dc02

If repadmin /showrepl comes back clean and the 8524 events stop in the Directory Service log, you're done. Don't touch the registry.

Fix 2: Raise the replication object size limit

Only do this if you genuinely can't trim the object — and honestly, you almost always can. Raising the limit is a band-aid that kicks the problem down the road and increases replication latency because every DC now has to shuffle a bigger blob every time the object changes.

That said, here's how, if you're stuck.

On every DC in the replication topology, add this registry value. Miss one and replication still fails on the one you skipped:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" /v "Replicator max object size" /t REG_DWORD /d 2097152 /f

2097152 is 2 MB. Don't go higher unless you've consulted Microsoft — the ceiling they support is capped and going past it voids the warranty on your support case.
Reboot the DCs. There's no service restart that picks this up cleanly, in my experience.
Force replication again with repadmin /replicate as above and watch the Directory Service log.

Worth knowing: this registry value exists in Windows Server 2008 R2 and later, but the exact key name has been stable. If you don't see Replicator max object size accepted, check you didn't typo it — it's case-sensitive for the value name in some builds.

Fix 3: The LDIFDE / CSVDE "too many values" variant

Sometimes the error fires during an import, not replication. You're running ldifde -i or csvde -i and it chokes on a group with a member list that's a mile long. The import tool builds the whole attribute in one write, so it hits the limit before AD does.

Split the LDIF into chunks of 5,000 members per file and import them sequentially. LDIFDE does add semantics on existing attributes if you use add: in a modify operation — use that, not replace:, or you'll zero the attribute every time.

Fix 4: The `maxValRange` red herring

People sometimes find MaxValRange referenced in the same KB articles and crank it. Don't. That value controls how many values of a multi-valued attribute the DC returns to a client in a single LDAP response. It has nothing to do with the storage or replication limit. Bumping it won't fix 0x2078, it just makes your LDAP queries return more data per response. Skip it.

Prevention

Set a group size policy and actually enforce it. Anything over 5,000 members should be a nested construct — a Universal group holding the users, nested into domain-local groups. Monitor with a weekly scheduled task that runs the Get-ADGroup snippet above and emails you anything over 3,000 members before it becomes an incident. And if you're extending the schema for a custom attribute, cap it with a maximum length in the schema definition. That's the one people forget, and it's the one that bites you six months later when an intern dumps a JSON blob into description.