0X0000219E

Fix ERROR_DS_INSUFFICIENT_ATTR_TO_CREATE_OBJECT (0X0000219E)

This Active Directory error pops up when you try to create an object without required attributes. You'll fix it by pre-staging the object with the mandatory fields.

That error code is a real pain, especially when you're in the middle of a user rollout and the clock's ticking. But it's fixable, and I'll show you the exact steps that work every time.

The Quick Fix: Pre-Stage the Object

The error means Active Directory got a request to create an object, but the request didn't include all the mandatory attributes. The most common trigger is trying to create a user or computer without the sAMAccountName attribute set, but it can happen with other object types too.

Here's the direct fix — use ADUC (Active Directory Users and Computers) to create the object manually, fill in the required fields, and then apply your automation or script afterward.

  1. Open Active Directory Users and Computers (dsa.msc). If you're on Windows Server 2016 or 2019, you can find it in the Tools menu of Server Manager.
  2. Right-click the OU where you want the object, then choose New > User or New > Computer.
  3. Fill in the fields. For a user, you must provide the first name, last name, and user logon name — those are the non-negotiable ones.
  4. Click Next, then set the password. Don't skip this even if your script is supposed to set it later.
  5. Click Finish. You should see the new object appear in the OU.

That's it. The object now exists with all required attributes, and you can run your script or import process that was failing.

Why This Works

When you create an object programmatically — say with a PowerShell script or a CSV import tool — the process sometimes doesn't include every mandatory attribute. The error 0X0000219E is Active Directory's way of saying "I don't have enough info to build this thing." By manually creating the object first, you're giving AD what it needs. Then your script can modify attributes without trying to create from scratch.

In technical terms, the schema defines mustContain attributes for each object class. For a user, that's typically sAMAccountName and cn (common name). If your creation request doesn't provide those, you get this exact error. ADUC always prompts for them, so it won't happen there.

Less Common Variations

Sometimes the error appears even when you're using ADUC, and that's usually because you're creating an object in a specific container that has additional requirements. For instance:

  • Creating a computer account via ADUC: Make sure the computer name you type matches the hostname rules — no spaces, no special characters, and it should be 15 characters or less.
  • Creating an inetOrgPerson object: This class is less forgiving. You might need to set the sn (surname) attribute manually if it's not being pulled from the display name.
  • Using a script with a non-standard attribute set: If your script uses the Set-ADUser cmdlet, you might be using -OtherAttributes to set custom fields. The error can occur if one of those custom fields is marked as mandatory in your schema but you're not providing it.

In all cases, the fix is the same: create the object with the minimum required attributes first, then add the extras.

PowerShell Alternative

If you can't use ADUC for some reason, you can use PowerShell to create the object with the right attributes. This is the command I use when I need to create a user without the GUI:

New-ADUser -Name "Jane Doe" -GivenName "Jane" -Surname "Doe" -SamAccountName "jdoe" -UserPrincipalName "jdoe@yourdomain.com" -Path "OU=Users,DC=yourdomain,DC=com" -AccountPassword (Read-Host -AsSecureString -Prompt "Password") -Enabled $true

Notice that I'm explicitly setting -SamAccountName and -UserPrincipalName. If you leave those out, you'll get the same 0X0000219E error.

Prevention: Stop It From Happening Again

The root cause is almost always a script or import process that doesn't handle required attributes. Here's how I keep it from recurring:

  • Check your import files. If you're using a CSV to bulk-create users, make sure every row has a value for sAMAccountName. A blank cell will trigger this error.
  • Validate before you create. In your PowerShell script, add a simple check: if (-not $user.sAMAccountName) { Write-Error "Missing sAMAccountName"; continue }. That catches the problem before AD does.
  • Use the same schema version. If you've recently updated your Active Directory schema, some attributes might have become mandatory that weren't before. Review your object creation scripts after any schema change.
  • Test in a lab. I know it's tempting to go straight to production, but a quick test in a non-production domain will save you from this headache. I've seen this error more times than I can count because someone skipped the test step.

When it does happen, just remember: manually create the object first, then let your automation do its thing. It's not a workaround — it's the proper way to handle a schema that demands completeness.

Related Errors in Windows Errors
0X00002144 FIX: ERROR_DS_GLOBAL_CANT_HAVE_LOCAL_MEMBER (0X00002144) – Global Groups Can't Nest Local Groups 0X000000C5 Fix ERROR_IOPL_NOT_ENABLED (0x000000C5) on 64-bit Windows 0X000000C1 Fix ERROR_BAD_EXE_FORMAT 0xC1: Not a Valid Win32 App 0X80280014 TPM_E_OWNER_SET (0X80280014) – Quick Fix Guide

Was this solution helpful?

EP
Erropedia Team
Tech Support Editors
The Erropedia editorial team researches and documents real-world tech errors from across Windows, Linux, macOS, networking, databases, cloud platforms, and more. Every solution is reviewed for accuracy and updated as software and systems evolve.