Table of Contents
Picture this: You’re migrating a user from one Active Directory (AD) domain to another. All seems to be going well until you hit a roadblock: the dreaded error message “The maximum size of an object has been exceeded.” Let’s break down how to solve this, step by step, with a dash of humor and a ton of technical insight.
Identifying the Root Cause: SID History Strikes Again!
When dealing with Active Directory migrations, there’s one attribute that loves to throw a wrench in your well-oiled machine: SIDHistory. In this case, the error was triggered because the SIDHistory attribute had grown way too large, thanks to multiple migrations over the years. Think of it like your email inbox after 10 years without clearing out spam—it gets bloated!
- SIDHistory: This attribute stores the Security Identifiers (SIDs) of a user from their previous domains. Handy for keeping access during a migration but can quickly become oversized if left unchecked.
- The problem: Users with an excessively large SIDHistory attribute exceeded the maximum object size that AD could handle.
Access Denied: ADSIEdit and the Locked SIDHistory
Now, you might think, “No problem, I’ll just fire up ADSIEdit and clean up the SIDHistory manually.” But when you try, you get another lovely error:
“Operation failed. Error code: 0x5 Access is denied. PROBLEM 4003 INSUFF_ACCESS_RIGHTS”
Why? Well, SIDHistory is a system-controlled attribute. Even with administrative rights, AD locks you out from directly modifying this attribute.
The Power of PowerShell: Cleaning Up SIDHistory
Here’s how I resolved the issue:
- Set up the lab: Always a good practice when you’re testing something new or potentially destructive.
- Run the PowerShell command: To remove all the SIDs from the SIDHistory attribute, I used the following command:
Get-ADUser migUser -Properties sidhistory | ForEach-Object {Set-ADUser $_ -Remove @{sidhistory = $_.sidhistory.value}}- This command retrieves the user (in this case, migUser) and removes all SIDHistory entries.
- It works like a charm because it handles the system-controlled attribute in a way that AD approves of—no more access denied errors.
Mission Accomplished: Migrating Users with a Clean Slate
Once we removed the bloated SIDHistory, we were able to successfully migrate the user to the new domain without any issues. And since the customer wanted the users’ SIDs migrated to the new domain, we ensured that their SIDHistory was clear to start fresh.
Key Takeaways
- Watch out for large SIDHistory attributes: If a user has been migrated multiple times, this attribute can cause migration failures. There are other attributes that can also impact this, like mSMQSignCertificates, mSMQDigests, UserCertificates, etc.
- ADSIEdit isn’t always your friend: Don’t expect to edit system-controlled attributes like SIDHistory directly, even as an admin. There are other ways to edit system-controlled attributes that I will cover in a future blog post.
- PowerShell to the rescue: Use the right tools for the job. PowerShell is a powerful ally in dealing with AD challenges.
Next time you face an AD migration, remember to check the size of the SIDHistory attribute, especially for users with a complex migration history. Share your own war stories with Active Directory in the comments. Let’s learn together!
Happy migrating, fellow techies!
Leave a Reply