Fix STATUS_NO_SUCH_ALIAS 0xC0000151 Windows Error

That 0xC0000151 error means a script or policy is referencing a local group that doesn't exist on the machine. Here's how to find the missing alias and fix it.

Nothing's more annoying than a Group Policy or install script blowing up because Windows can't find a group that should be there. Let's get you sorted.

The fix

0xC0000151 hits when something — a startup script, an MSI, a GPO preference, an SDDL string — tries to reference a local group (an alias) by name or SID and Windows can't resolve it. The group either got deleted, was never created, or lives on a different machine than the one running the command.

First, confirm the group truly isn't there. Open an elevated Command Prompt and list every local group:

net localgroup

If you're expecting something like Remote Desktop Users, IIS_IUSRS, or a custom group your ERP installer created, and it's not in that list, you've found your problem. Check for a specific one like this:

net localgroup "Backup Operators"

If you get "The specified local group does not exist" back, that's your 0xC0000151 confirmed.

Now the fix depends on what made the group disappear:

The group was deleted. Recreate it with the same name and members. For a custom group:

net localgroup "MyApp Users" /add
net localgroup "MyApp Users" "DOMAIN\svc_appaccount" /add

A built-in group went missing. This is rarer and usually means someone ran a script that nuked Users or Administrators. You can't just net localgroup those back — the SID won't match. Restore from a system restore point, or rebuild the group with the correct well-known SID using wmic or by copying from a healthy machine. Honestly, on a workstation, reinstalling is often faster.
A GPO is pointing at a group that doesn't exist here. This is the most common cause I see in the wild. Check the Group Policy operational log:

Event Viewer → Applications and Services Logs → Microsoft → Windows → GroupPolicy → Operational. Look for Event ID 1202 or 7016. The message will name the missing group or the SID it couldn't translate.

Once you know which GPO, either create the group on the target machine, or edit the GPO to reference a group that exists. In GPMC: right-click the policy → Edit → find the setting referencing the bad alias → point it at the correct group.

An SDDL entry references a missing SID. If you're seeing this during a service install or file permission set, dump the SDDL and look for an unresolved S-1-5-... value:

icacls "C:\Path\To\Folder"

Any (SID) that won't render as a name is suspect. Fix with:

icacls "C:\Path\To\Folder" /remove:g *S-1-5-21-XXXX

Why this happens

Windows stores local groups in the SAM registry hive, and every group has a unique SID that starts with S-1-5-21- (for non-built-ins) or a well-known SID like S-1-5-32-544 for Administrators. When a script, GPO, or installer hands Windows a name or SID to look up, the Local Security Authority goes hunting through the SAM. If nothing's there, you get STATUS_NO_SUCH_ALIAS.

The tricky part: a script that worked on Server 2019 might fail on Server 2022 because the alias it references (like IIS_IUSRS) doesn't exist until the IIS role is installed. Same story after a sysprep image if those groups were cleaned up. I had a client last month whose software deployment GPO tanked every Windows 11 machine because the vendor's MSI added a local group on install but the GPO tried to grant permissions before the MSI ran. Chicken and egg.

Less common variations

Domain controller quirks

On a DC, "local groups" are really domain local groups, and net localgroup behaves differently. If you're running the same command on a DC and a member server and only the DC fails, that's why. Use Get-ADGroup instead:

Get-ADGroup -Filter {Name -like "*App*"}

Nested group SID translation failures

If the group exists but a member SID doesn't resolve, you'll still get 0xC0000151 in some tools. That's stale SID history from a domain migration. Clean up with sidhist.vbs or the ADMT SID cleanup tool, or remove the orphaned SID manually:

net localgroup "MyGroup" "DOMAIN\olduser" /delete

Installer failing on a fresh image

Custom-built images often strip groups the installer expects. Check your unattend.xml or your reference image for a net localgroup ... /delete line someone added "for security." I've seen that cause a week of ticket churn.

MSI custom action errors

If your install log shows 0xC0000151 in a custom action, the installer is trying to add a user to a group that hasn't been created yet. Reorder the custom actions, or add a prerequisite step that runs net localgroup first.

Prevention

Never delete built-in local groups. If a hardening guide tells you to, find a different guide.
Version-control your startup scripts and GPO preferences. Most of these errors trace back to an edit someone made six months ago and forgot.
Test GPO changes in a staging OU first. Always.
Before shipping a custom image, run net localgroup on it and compare against a known-good reference.
Enable Group Policy operational logging by default. You'll thank yourself the next time this happens.
If you're deploying MSIs that create local groups, gate any permission-granting steps to run after the group-creation step. MSI custom actions are sequenced for a reason.

Nine times out of ten, this error is a missing group you can recreate in thirty seconds with net localgroup. The tenth time, it's a GPO edit that someone needs to undo. Either way, you now know where to look.