Struggling with the common ‘cannot find an object with identity’ error when using PowerShell’s New-ADGroup? A senior engineer breaks down why it happens and provides three practical, real-world solutions to get your scripts working.

From the Trenches: Decoding the Annoying `New-ADGroup` ‘ManagedBy’ Error

I still remember it. It was 2 AM, and I was pushing a new automated onboarding script for our sales department. A simple script, really. A new manager gets hired, the script creates a new AD group for their team, and sets the new hire as the group’s manager. Easy. Except it wasn’t. The script kept crashing with a cryptic error: New-ADGroup : Cannot find an object with identity: 's.jenkins'. For an hour, I stared at that line, convinced I had a typo. But `s.jenkins` was right there in Active Directory. It’s one of those infuriating problems that isn’t about logic, it’s about understanding how PowerShell *thinks*. This isn’t just a syntax error; it’s a rite of passage for anyone scripting against Active Directory.

The “Why”: It’s Not You, It’s the Object Type

Here’s the deal. When you use the -ManagedBy parameter in New-ADGroup, PowerShell isn’t just looking for a name. You’re giving it a simple string of text, like “s.jenkins”, but the cmdlet is expecting an entire ADPrincipal object. It needs the whole package—the user’s SID, their Distinguished Name, all of it. When you just pass the name, PowerShell makes a guess and tries to find that user for you. But in a complex environment, or even on a bad day, that lookup fails, and it throws its hands up with that “Cannot find an object” error. The fix is to stop letting PowerShell guess and to give it exactly what it wants.

Three Ways to Slay the Beast

I’ve seen this problem dozens of times, both in my own scripts and when mentoring junior engineers. Here are the three ways we get around it, from the quick fix to the proper, production-ready solution.

Solution 1: The Quick & Dirty Inline Fix

This is the solution you’ll find plastered all over the internet, and for good reason: it’s a simple, effective one-liner. You basically tell PowerShell, “Hey, before you run this command, go find the user object I’m talking about.”

Here’s the command that’s probably failing you:

New-ADGroup -Name "Finance-Auditors-Q4" -GroupScope Global -Path "OU=Groups,OU=Finance,DC=techresolve,DC=local" -ManagedBy "s.jenkins"

And here’s the fix. We force PowerShell to resolve the identity by wrapping it in a Get-ADUser call:

New-ADGroup -Name "Finance-Auditors-Q4" -GroupScope Global -Path "OU=Groups,OU=Finance,DC=techresolve,DC=local" -ManagedBy (Get-ADUser -Identity "s.jenkins")

Pro Tip: The parentheses () are critical. They create a sub-expression, forcing PowerShell to execute Get-ADUser *first* and then use its object output as the value for the -ManagedBy parameter. Without them, it won’t work.

Solution 2: The “Do It Right” Method for Scripts

The inline fix is fine for a quick command in the console, but in a real script, it’s sloppy. If Get-ADUser fails, the whole command just crashes. A much more robust and readable approach is to fetch the user object first, store it in a variable, and then use that variable. This also gives you a chance to add error handling.

This is how I’d write it for a production script:

# First, try to find the manager and store their object in a variable
$managerObject = Get-ADUser -Identity "s.jenkins" -ErrorAction SilentlyContinue

# Check if we actually found the manager
if ($managerObject) {
    # If we found them, proceed with creating the group
    Write-Host "Found manager: $($managerObject.Name). Creating group..."
    New-ADGroup -Name "Finance-Auditors-Q4" -GroupScope Global -Path "OU=Groups,OU=Finance,DC=techresolve,DC=local" -ManagedBy $managerObject
} else {
    # If not, throw a clear error and stop
    Write-Error "FATAL: Could not find manager with identity 's.jenkins'. Group creation aborted."
}

See the difference? This code is self-aware. It checks its work. If you’re running this as part of a larger automation, this kind of logging and error handling is non-negotiable.

Solution 3: The ‘Nuclear’ Option (Using the Distinguished Name)

Every now and then, you’re in a real bind. Maybe you’re in a multi-domain forest and the SamAccountName is ambiguous, or a domain controller is being slow to replicate. In these edge cases, you can be hyper-specific by using the user’s full Distinguished Name (DN). The DN is the user’s absolute, unique address in the Active Directory tree.

First, you’d get the DN:

(Get-ADUser s.jenkins).DistinguishedName
# Output might be: CN=Sarah Jenkins,OU=Managers,OU=Finance,DC=techresolve,DC=local

Then, you can often pass that entire string to the -ManagedBy parameter. PowerShell is usually smart enough to resolve a DN string correctly.

New-ADGroup -Name "Finance-Auditors-Q4" -ManagedBy "CN=Sarah Jenkins,OU=Managers,OU=Finance,DC=techresolve,DC=local" -Path "OU=Groups,OU=Finance,DC=techresolve,DC=local" -GroupScope Global

Warning: I call this the ‘nuclear’ option for a reason. It’s extremely rigid. If Sarah Jenkins ever moves to a different OU, her DN changes, and this script instantly breaks. Use this as a last resort for troubleshooting, not as a go-to scripting practice.

Final Thoughts

Don’t feel bad for getting stuck on this. We’ve all been there. This error is a classic “welcome to PowerShell” moment where you learn the critical difference between a simple piece of text (a string) and a rich, data-filled object. My advice? Make Solution 2 your default habit. It will force you to write cleaner, more resilient, and more professional code. Happy scripting.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions