The essentials
Quick reference
One focused task per row. Jump to the related section for complete, working examples.
| Use | Syntax | Examples |
|---|---|---|
| List local users | Get-LocalUser | Sort-Object Name | View examples |
| Get one local user | Get-LocalUser -Name 'ReportRunner' | View examples |
| Resolve by SID | Get-LocalUser -SID 'S-1-5-21-...-1002' | View examples |
| List local groups | Get-LocalGroup | Sort-Object Name | View examples |
| Inspect group membership | Get-LocalGroupMember -Group 'Remote Desktop Users' |
Select-Object Name, SID, ObjectClass, PrincipalSource | View examples |
| Preview user creation | New-LocalUser -Name 'ReportRunner' -Password $password `
-Description 'Runs local reports' -WhatIf | View examples |
| Preview a disabled account | New-LocalUser -Name 'StagedUser' -NoPassword `
-AccountNeverExpires -UserMayNotChangePassword -WhatIf | View examples |
| Preview disabling a user | Disable-LocalUser -Name 'ReportRunner' -WhatIf | View examples |
| Preview enabling a user | Enable-LocalUser -Name 'ReportRunner' -WhatIf | View examples |
| Preview an account update | Set-LocalUser -Name 'ReportRunner' -Description `
'Runs signed reporting jobs' -WhatIf | View examples |
| Preview a password change | Set-LocalUser -Name 'ReportRunner' -Password $password `
-WhatIf | View examples |
| Preview group creation | New-LocalGroup -Name 'Report Operators' -Description `
'May run approved reports' -WhatIf | View examples |
| Preview adding a member | Add-LocalGroupMember -Group 'Report Operators' -Member `
'.\ReportRunner' -WhatIf | View examples |
| Preview removing a member | Remove-LocalGroupMember -Group 'Report Operators' `
-Member '.\ReportRunner' -WhatIf | View examples |
| Preview user removal | Remove-LocalUser -Name 'ReportRunner' -WhatIf | View examples |
| Preview group removal | Remove-LocalGroup -Name 'Report Operators' -WhatIf | View examples |
| Check module availability | Get-Module -ListAvailable `
Microsoft.PowerShell.LocalAccounts | View examples |
Local accounts and groups affect access to one Windows computer. Resolve identities by name, SID, and principal source before changing membership, preview supported changes with WhatIf, and prefer disabling an account while ownership and service dependencies are investigated. Domain and Microsoft Entra identities require different administration tools.
Step by step
Detailed examples
Confirm identity with names and SIDs
A name is readable but can be reused after deletion; the SID is the security identity used by access-control entries. Inspect Enabled, LastLogon, PasswordRequired, and PrincipalSource where available, but do not treat LastLogon as a complete audit record. The LocalAccounts module is unavailable in 32-bit PowerShell on a 64-bit system.
Get-LocalUser |
Select-Object Name, Enabled, SID, LastLogon, PasswordRequired, PrincipalSource |
Sort-Object Name
Get-LocalGroup |
Select-Object Name, SID, Description, PrincipalSource |
Sort-Object NameCollect passwords without exposing plaintext
Read-Host -AsSecureString avoids placing a plaintext password in source or ordinary command history. New-LocalUser accepts the SecureString and account policy parameters. A no-password account is disabled when created; set a compliant password before enabling it. Prefer managed domain or service identities for broader automation when available.
$password = Read-Host 'Enter a unique password for ReportRunner' -AsSecureString
$params = @{
Name = 'ReportRunner'
Password = $password
Description = 'Runs approved local reports'
AccountNeverExpires = $true
}
New-LocalUser @params -WhatIfNote: Remove WhatIf only after checking local password policy, ownership, and the exact target computer.
Prefer reversible containment while investigating dependencies
Disabling an account blocks sign-in but preserves the SID and account object, making it safer than immediate deletion during incident response or offboarding. Before enabling, confirm password and expiration state. Set-LocalUser updates selected properties; resolve the user immediately beforehand so a reused name does not silently target a different SID.
$user = Get-LocalUser -Name 'ReportRunner'
$user | Select-Object Name, SID, Enabled, LastLogon, Description
Disable-LocalUser -SID $user.SID -WhatIf
# Preview a description update by stable identity:
Set-LocalUser -SID $user.SID -Description 'Disabled pending service review' -WhatIfGrant access through purpose-specific groups
Groups make access review easier than scattering permissions across individual users. Membership can include local, domain, and other principals, so inspect PrincipalSource and SID before adding or removing. Prefix a local member with `.\` to distinguish it from a similarly named external principal, and avoid broad built-in groups when a narrower custom group will work.
$group = Get-LocalGroup -Name 'Report Operators' -ErrorAction SilentlyContinue
if (-not $group) {
New-LocalGroup -Name 'Report Operators' -Description 'May run approved reports' -WhatIf
}
Get-LocalGroupMember -Group 'Report Operators' -ErrorAction SilentlyContinue |
Select-Object Name, SID, ObjectClass, PrincipalSource
Add-LocalGroupMember `
-Group 'Report Operators' `
-Member '.\ReportRunner' `
-WhatIfRemove accounts only after SID-based dependency review
Deleting a user does not delete its profile or files and leaves its old SID on ACLs. A newly created account with the same name receives a different SID and does not inherit that access. Disable first, find services, tasks, encrypted data, profiles, and permissions tied to the SID, transfer ownership where authorized, then preview and record deletion.
$user = Get-LocalUser -Name 'ReportRunner'
$user | Select-Object Name, SID, Enabled, Description |
Format-List
Get-ScheduledTask |
Where-Object { $_.Principal.UserId -in @($user.Name, $user.SID.Value) } |
Select-Object TaskPath, TaskName
Disable-LocalUser -SID $user.SID -WhatIf
Remove-LocalUser -SID $user.SID -WhatIfNote: The dependency scan is illustrative, not exhaustive; services, ACLs, profiles, credentials, and encrypted files need separate review.
Use the module only for local Windows principals
Microsoft.PowerShell.LocalAccounts manages the current computer's local account database; it is not an Active Directory or Microsoft Entra administration module. Run elevated only for operations requiring it and confirm the target computer at the start of a remote session. Avoid applying English built-in group names across localized systems; resolve well-known groups by SID where automation must cross locales.
$env:COMPUTERNAME
Get-Module -ListAvailable Microsoft.PowerShell.LocalAccounts |
Select-Object Name, Version, Path
Get-Command -Module Microsoft.PowerShell.LocalAccounts |
Sort-Object Noun, Verb |
Select-Object NameSources and further reading
References
Authoritative documentation used to verify and expand this cheat sheet.
Help us improve
Found a typo or missing example?
Tell us what would make this cheat sheet clearer, more complete, or more useful.