LargeObject and ExceededAllowedLength: Entra ID rejects an oversized object

Fix it now

Entra ID rejected an object because an attribute broke a size, length or count limit in its schema. Microsoft names the usual offenders: userCertificate, userSMIMECertificate, thumbnailPhoto and proxyAddresses. The object stops synchronising while everything else carries on, which is why these go unnoticed for months.

Start-ADSyncSyncCycle -PolicyType Delta

1. On the synchronisation server, open Synchronization Service Manager, select Operations and open the failed export to find which object and which attribute is at fault.
2. Check the certificate attribute first. Microsoft documents a hard limit of 15 certificates in userCertificate, and nothing on-premises objects to the pile growing past it.
3. Check proxyAddresses next. The documented limit is approximately 300 SMTP addresses, varying with what else is populated on the object.
4. Export the current values of the offending attribute to a file before you change anything, so the change can be undone.
5. Remove what is no longer required at source in Active Directory – revoked or expired certificates, outdated SMTP, X.400, X.500, MSMail or CcMail addresses – or exclude the attribute from synchronisation if no cloud service reads it.
6. Run the delta cycle above and confirm that object now exports cleanly.

If the export clears, you are done. If the failure is a validation error rather than a size one, the next section explains the difference, because they need different fixes.

Why it happens

Microsoft documents LargeObject and ExceededAllowedLength together: the error occurs when an attribute exceeds the allowed size limit, length limit or count limit set by the Entra schema, and it typically occurs for userCertificate, userSMIMECertificate, thumbnailPhoto or proxyAddresses. Three specific limits are published – a hard limit of 15 certificates in userCertificate, an approximate limit of 300 SMTP addresses in proxyAddresses that varies with the other attributes populated on the object, and up to 100 directory extensions of at most 250 characters each.

Certificates are the common one because nothing prunes them. Every smart card renewal, mail signing certificate and network authentication certificate can add another value to the user object, and Active Directory stores the pile happily. The cloud object has a ceiling, so at some point an export that worked last month stops working with no change anybody made deliberately. Photographs are the second: thumbnailPhoto is named for what it is meant to hold, and a bulk import that writes full-resolution portraits into it produces exactly this failure across a batch of people. Address lists are the third, accumulating through migrations, address policies and renamings.

The validation family sits alongside these and needs a different fix. Microsoft documents IdentityDataValidationFailed and DataValidationFailed as Entra ID enforcing data restrictions before allowing data to be written, with three common scenarios: the userPrincipalName has invalid or unsupported characters, the userPrincipalName does not follow the required format, or onPremisesObjectIdentifier changed as the result of a hard match operation. Those are shape problems, not size problems – trimming an attribute will not help, and the last of the three points back at a matching operation rather than at the object.

Full reference

The published limits, in one place

Working out which limit you hit

Clearing a certificate attribute is destructive if those certificates are in use for smart card sign-in, mail signing or network authentication. Export the current values to a file first, and confirm with whoever runs your certificate services before removing anything.

Trimming without breaking something

1. Export the attribute’s current values for the affected object to a file, and keep it somewhere you will find it again.
2. Identify which values are revoked, expired or superseded – those are the safe removals.
3. Remove them at source in Active Directory, not in the cloud copy.
4. Run a delta cycle and confirm the export clears for that object.
5. Decide whether to exclude the attribute from synchronisation altogether, so the same object does not come back next year.

Excluding an attribute rather than pruning it

If no cloud service you use reads an attribute, excluding it from synchronisation is a cleaner answer than pruning it repeatedly. The decision needs checking rather than assuming, because some certificate-based authentication and mail signing arrangements do read userCertificate from the directory. Establish what depends on it before you exclude it, not after – the failure mode is silent and turns up weeks later as an authentication problem nobody connects to a sync change.

On the two event IDs

Event ID 6803 and Event ID 6100 are frequently quoted next to these failures, and Microsoft publishes no meaning for either. They are not a diagnosis. The export result in Synchronization Service Manager names the object, the attribute and the limit, and Microsoft Entra Connect Health sync reports give the same information without opening a console on the server. Work from those.

Every code this article covers

Confirm the fix worked

1. The export run completes with no errors for the object you corrected.
2. The object’s attributes in the cloud reflect the values you expect.
3. A backup of anything you removed exists and is somewhere you can find it again.
4. The next scheduled cycle also runs clean, confirming the change was made at source.

Questions people ask about this