You hit this error. It's annoying but easy to fix.
The culprit here is almost always an Active Directory object whose name — specifically the Relative Distinguished Name (RDN) — exceeds 64 characters. AD enforces this limit per component of the Distinguished Name (DN). For example, CN=verylongdepartmentnamewithalotofextrainformation,DC=contoso,DC=com where that CN part is over 64 chars. I've seen this most often when someone migrates a system from Exchange 2007 and the mailbox display name is a monster.
The Quick Fix: Rename the Object
Open Active Directory Users and Computers (ADUC). Find the object triggering the error. Right-click it, select Rename, and shorten the name to 64 characters or fewer. That's it. The error goes away immediately. If you're dealing with a computer object, you can rename it via PowerShell too:
Get-ADComputer OldComputerName | Rename-ADComputer -NewName NewShortNameFor user objects, use:
Set-ADUser username -SamAccountName shortname -UserPrincipalName shortname@domain.com -DisplayName shortnameDon't bother with restarting AD services or rebooting domain controllers. That rarely helps here.
Why This Happens
The Active Directory schema defines the RDN attribute (usually CN for users and groups, OU for OUs, CN for computers) as a Unicode string with a maximum length of 64 characters per DN component. When you try to create or rename an object with a longer value, the directory service rejects it with the ERROR_DS_NAME_TOO_MANY_PARTS error. The error message literally means the DN has more parts than allowed, but in practice it's almost always about a single part being too long. The spec allows a total DN of up to 255 bytes, but each part is individually capped at 64 characters.
Less Common Variations
Sometimes the problem isn't the RDN length but the total DN length across multiple OUs. If you have a deeply nested OU structure like OU=reallylongou1,OU=reallylongou2,OU=reallylongou3,DC=domain,DC=com, and the sum exceeds ~255 bytes, you'll see this error when creating objects inside that OU. The fix is to flatten your OU structure or rename OUs to shorter names. Another edge case: Exchange Online hybrid setups where proxy addresses get concatenated into an alias that pushes the total DN over the limit. Strip unnecessary proxy addresses from the user's attributes.
How to Prevent This
Set naming conventions that limit object names to 32 characters or fewer. That gives you breathing room for future nesting. For OUs, keep names under 20 chars. I've seen companies with OUs named OU=FinanceDepartment-EastRegion-ExtendedSupport — that's asking for trouble. Use abbreviations or codes instead. For user accounts, enforce a SamAccountName length cap via Group Policy or your provisioning scripts. If you're automating account creation, add a validation step that checks RDN length before submission.
One last thing: if you're still seeing this error after renaming, check for hidden objects (like system accounts or Exchange recipients) that may be using the same long name. Use dsquery with a filter to find all objects with long CNs:
dsquery * -filter "&(objectClass=user)(name=*?????????????????????????????????????????????????????????*)"That's 64 question marks — adjust as needed. Run it against each OU to catch stragglers.