How to Create Local Users in Windows Using PowerShell

To create a local user in Windows with PowerShell, open PowerShell as administrator and run New-LocalUser with a name and a secure password:

$password = Read-Host 'Password for mlopez' -AsSecureString
New-LocalUser -Name 'mlopez' -Password $password -FullName 'Maria Lopez'

Then add the account to a group with Add-LocalGroupMember. Below I cover options, name rules, bulk creation from a CSV file, and the Access denied error.

Create a local user account with New-LocalUser

New-LocalUser ships in the Microsoft.PowerShell.LocalAccounts module, so there’s nothing to install. It works in Windows PowerShell 5.1 and PowerShell 7, as long as you use 64-bit PowerShell. The module isn’t available in 32-bit PowerShell on 64-bit Windows.

Pass -Password with a SecureString, or -NoPassword for an account without one. If you pass neither, it prompts you.

I won’t create real accounts on my PC for a blog post, so the tested runs use -WhatIf, which reports what would happen and changes nothing:

$password = ConvertTo-SecureString 'Spring#2026!Denver' -AsPlainText -Force
New-LocalUser -Name 'mlopez' -Password $password -FullName 'Maria Lopez' -Description 'Front desk, Denver office' -WhatIf
New-LocalUser -Name 'kiosk01' -NoPassword -Description 'Lobby check-in kiosk' -WhatIf

Output:

What if: Performing the operation "Create new local user" on target "mlopez".
What if: Performing the operation "Create new local user" on target "kiosk01".

In an elevated window without -WhatIf, the cmdlet returns the new account. Microsoft Learn documents this output for a -NoPassword account:

Name    Enabled  Description
----    -------  -----------
User02  True     Description of this account.

Read-Host -AsSecureString keeps the password out of your script and your credential objects can supply one too. To confirm the result, list the local users on the PC with Get-LocalUser.

Why does New-LocalUser say Access denied?

Creating accounts needs administrator rights. In a normal, non-elevated window the cmdlet fails, and nothing gets created. Here’s a check plus the call:

$me = [Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()
"Elevated: $($me.IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator))"
New-LocalUser -Name 'psfaqs-demo' -NoPassword -Disabled

PowerShell 7 prints a single line under the elevation check:

Elevated: False
New-LocalUser: C:\psfaqs\denied.ps1:3
Line |
   3 |  New-LocalUser -Name 'psfaqs-demo' -NoPassword -Disabled
     |  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Access denied.

Windows PowerShell 5.1 shows the full error block, with AccessDeniedException in the CategoryInfo line:

Right-click PowerShell or Windows Terminal and pick Run as administrator. Running as a different user helps only if that account is an administrator and the window is elevated.

Set a password, expiration date and other options

Splatting a hashtable keeps the call readable when you set several parameters:

$params = @{
    Name                     = 'tbaker'
    Password                 = ConvertTo-SecureString 'Temp#2026-Austin' -AsPlainText -Force
    FullName                 = 'Tom Baker'
    Description              = 'Contractor, Austin, ends Dec 2026'
    AccountExpires           = Get-Date '2026-12-31 17:00'
    UserMayNotChangePassword = $true
}
New-LocalUser @params -WhatIf

try {
    New-LocalUser -Name 'tbaker' -NoPassword -AccountExpires (Get-Date '2026-12-31') -AccountNeverExpires -ErrorAction Stop
}
catch { "Failed. $($_.Exception.Message)" }

Output:

What if: Performing the operation "Create new local user" on target "tbaker".
Failed. Parameter AccountExpires and parameter AccountNeverExpires may not be used together.

AccountExpires disables sign-in after that date, which suits contractors. You can build the value with Get-Date or by adding days to a date. -AccountNeverExpires is the opposite, so PowerShell refuses to take both.

Other useful switches are -Disabled, -UserMayNotChangePassword and -PasswordNeverExpires. The last one only works with -Password, and setting a password to never expire covers changing it later.

The two parameter sets don’t mix either. Passing -Password and -NoPassword together gives a binding error, and the wording differs by version:

$password = ConvertTo-SecureString 'Temp#2026-Austin' -AsPlainText -Force
try { New-LocalUser -Name 'tbaker' -NoPassword -Password $password -WhatIf -ErrorAction Stop }
catch { "Failed. $($_.Exception.Message)" }

Output:

Failed. Parameter set cannot be resolved using the specified named parameters. One or more parameters issued cannot be used together or an insufficient number of parameters were provided.

That’s PowerShell 7, which adds a second sentence. Windows PowerShell 5.1 stops after “cannot be resolved using the specified named parameters.”

What are the rules for a local user name?

According to Microsoft Learn, a user name can have up to 20 characters. It can’t contain ” / \ [ ] : ; | = , + * ? < > @, can’t be only periods or spaces, and can’t match another user or group name.

Descriptions are capped at 48 characters.

-WhatIf catches the length limits, because those are parameter validation. It doesn’t catch bad characters, so I check names myself with the -match operator before creating anything:

function Test-LocalUserName ([string]$Name) {
    if ($Name.Length -gt 20) { return "too long ($($Name.Length) characters)" }
    if ($Name -match '["/\\\[\]:;|=,+*?<>@]') { return "invalid character '$($Matches[0])'" }
    if ($Name -match '^[. ]+$') { return 'only periods or spaces' }
    'OK'
}

foreach ($name in 'mlopez', 'dana.reyes', 'm/lopez', 'seattle-frontdesk-02a', '...') {
    '{0,-22} {1}' -f $name, (Test-LocalUserName $name)
}

New-LocalUser -Name 'm/lopez' -NoPassword -WhatIf

Output:

mlopez                 OK
dana.reyes             OK
m/lopez                invalid character '/'
seattle-frontdesk-02a  too long (21 characters)
...                    only periods or spaces
What if: Performing the operation "Cre