How to Set Up Windows Server Update Services (WSUS) on Windows Server 2022

Introduction to Local User and Group Management

Windows Server 2022 supports two distinct categories of accounts: local accounts, which are stored in the local Security Account Manager (SAM) database on the server itself, and domain accounts, which are managed through Active Directory. This article focuses entirely on local accounts — when to use them, how to create and manage them, and the security best practices that apply to them.

Local accounts are appropriate for standalone servers, workgroup environments, or for service accounts that do not need domain access. On domain-joined servers, local accounts are typically used only for emergency recovery access or for specific services that must run independently of the domain infrastructure.

Built-in Local Accounts

Windows Server 2022 ships with several built-in local accounts that you need to understand before creating your own.

Administrator — The original built-in administrative account. It cannot be deleted, but it can be renamed and disabled. When Active Directory Domain Services (AD DS) is installed, the local Administrator account is effectively superseded by domain admin accounts, but it remains important for recovery scenarios.

Guest — A limited account for users without a regular account on the machine. It is disabled by default and should remain disabled in virtually all production scenarios. Enabling it creates a significant security risk because any unauthenticated user can log in with minimal privilege.

DefaultAccount — A managed account used by the operating system. Do not modify or use this account.

WDAGUtilityAccount — Used by Windows Defender Application Guard. It is managed automatically and should not be modified.

As a baseline security practice, rename the built-in Administrator account to something non-obvious, set a strong password on it, and then disable it. Create a separate named administrative account for daily use. This reduces the attack surface against brute-force attempts targeting the well-known “Administrator” username.

Opening Local Users and Groups with lusrmgr.msc

The graphical tool for local user and group management is the Local Users and Groups snap-in, launched via the Run dialog or from a terminal:

lusrmgr.msc

From here you can expand the Users or Groups node in the left pane. Right-clicking either node reveals options to create new objects. Double-clicking an existing user opens its properties sheet, where you can set the full name, description, password options (user must change at next logon, user cannot change password, password never expires, account is disabled), and group memberships.

Note that lusrmgr.msc is not available on domain controllers. On a DC, all accounts are managed through Active Directory Users and Computers (dsa.msc) instead.

Managing Users with the net user Command

The classic net user command has been present in Windows since the NT era and remains fully functional on Server 2022. It is ideal for quick tasks and batch scripts.

List all local users:

net user

Display details about a specific user:

net user johndoe

Create a new user with a password:

net user johndoe P@ssw0rd!2024 /add

Set a user’s full name and comment:

net user johndoe /fullname:"John Doe" /comment:"Finance department"

Force the user to change their password at next logon:

net user johndoe /logonpasswordchg:yes

Disable an account:

net user johndoe /active:no

Enable an account:

net user johndoe /active:yes

Delete a user account:

net user johndoe /delete

Set an account expiration date:

net user johndoe /expires:12/31/2024

Add a user to the local Administrators group via net localgroup:

net localgroup Administrators johndoe /add

Remove a user from the local Administrators group:

net localgroup Administrators johndoe /delete

List members of a group:

net localgroup Administrators

Managing Users with PowerShell LocalAccounts Module

The Microsoft.PowerShell.LocalAccounts module, available on Server 2022, provides a modern, scriptable interface for managing local accounts. All cmdlets support the pipeline, -WhatIf, and -Confirm parameters, making them safer than batch scripts for automation.

List all local users:

Get-LocalUser

Get properties of a specific user:

Get-LocalUser -Name "johndoe" | Select-Object *

Create a new user with a secure password string:

$Password = ConvertTo-SecureString "P@ssw0rd!2024" -AsPlainText -Force
New-LocalUser -Name "johndoe" -Password $Password -FullName "John Doe" -Description "Finance department" -PasswordNeverExpires $false -UserMayNotChangePassword $false

Modify an existing user’s properties:

Set-LocalUser -Name "johndoe" -FullName "John A. Doe" -Description "Senior Finance Analyst"

Disable a user account:

Disable-LocalUser -Name "johndoe"

Enable a user account:

Enable-LocalUser -Name "johndoe"

Remove a user account permanently:

Remove-LocalUser -Name "johndoe"

Rename a user account (for example, renaming the built-in Administrator):

Rename-LocalUser -Name "Administrator" -NewName "SrvAdmin"

Managing Local Groups with PowerShell

Windows Server 2022 has several important built-in local groups: Administrators, Users, Backup Operators, Remote Desktop Users, IIS_IUSRS, and others. You can also create custom groups to organize permissions.

List all local groups:

Get-LocalGroup

Create a new local group:

New-LocalGroup -Name "AppDeployTeam" -Description "Users authorised to deploy applications"

Add a local user to a group:

Add-LocalGroupMember -Group "AppDeployTeam" -Member "johndoe"

Add a domain user to a local group (on a domain-joined server):

Add-LocalGroupMember -Group "Remote Desktop Users" -Member "CONTOSOhelpdesk"

List all members of a group:

Get-LocalGroupMember -Group "Administrators"

Remove a member from a group:

Remove-LocalGroupMember -Group "AppDeployTeam" -Member "johndoe"

Remove a group entirely:

Remove-LocalGroup -Name "AppDeployTeam"

Configuring Local Password Policies

Local password policies on a standalone server are configured through the Local Security Policy editor. Open it with:

secpol.msc

Navigate to Security Settings > Account Policies > Password Policy. Key settings include:

Enforce password history — Prevents users from reusing recent passwords. A value of 24 is the CIS benchmark recommendation.

Maximum password age — The number of days before a password must be changed. Common values are 60 or 90 days, though many modern security frameworks recommend longer or no-expiry policies combined with breach detection.

Minimum password age — Prevents users from cycling through the history limit immediately. Setting this to 1 day enforces that users must wait before changing a password again.

Minimum password length — Set this to at least 14 characters for administrative accounts.

Password must meet complexity requirements — Enforces that passwords contain characters from at least three of: uppercase, lowercase, digits, and special characters.

You can also configure these settings with secedit or through Group Policy Objects if the server is domain-joined. For scripted deployment, export the current policy to an INF file, edit it, and reimport:

secedit /export /cfg C:Securitylocal_policy.inf
# Edit the file, then reimport:
secedit /configure /db secedit.sdb /cfg C:Securitylocal_policy.inf /areas SECURITYPOLICY

Configuring Account Lockout Policy

Account lockout policy limits the damage from brute-force password attacks. In secpol.msc, navigate to Security Settings > Account Policies > Account Lockout Policy.

Account lockout threshold — The number of invalid logon attempts before the account is locked. A value of 5 is widely recommended.

Account lockout duration — How long in minutes an account remains locked before automatically unlocking. Setting this to 0 requires an administrator to manually unlock the account.

Reset account lockout counter after — The number of minutes after which the failed attempt counter resets. This should be equal to or greater than the lockout duration.

To manually unlock a locked account with net user:

net user johndoe /active:yes

Or with PowerShell (re-enabling re-activates a locked account when the lockout duration is 0):

Enable-LocalUser -Name "johndoe"

To check if an account is currently locked out:

Get-LocalUser -Name "johndoe" | Select-Object Name, Enabled, LastLogon, PasswordLastSet

Bulk User Creation with PowerShell

When you need to create multiple local accounts at once, a PowerShell script combined with a CSV file is the most reliable approach.

Create a CSV file (C:Scriptsnew_users.csv) with the following columns:

Name,FullName,Description,Group
svc_backup,Backup Service Account,Runs scheduled backups,Backup Operators
svc_monitor,Monitor Service Account,System monitoring agent,Users
appuser1,Application User 1,App deployment team,AppDeployTeam

Then run the following script to create each user with a default password and force a password change on first logon:

$DefaultPassword = ConvertTo-SecureString "Welcome1!" -AsPlainText -Force
$Users = Import-Csv -Path "C:Scriptsnew_users.csv"

foreach ($User in $Users) {
    New-LocalUser -Name $User.Name `
                  -Password $DefaultPassword `
                  -FullName $User.FullName `
                  -Description $User.Description `
                  -PasswordNeverExpires $false
    Add-LocalGroupMember -Group $User.Group -Member $User.Name
    Write-Host "Created user: $($User.Name)"
}
Write-Host "All users created successfully."

Security Best Practices for Local Accounts

Local accounts, when improperly managed, are a common vector for lateral movement attacks. Follow these guidelines to minimise risk on Windows Server 2022:

Rename and disable built-in accounts. The built-in Administrator account is a prime target. Rename it to something non-obvious and disable it after creating a separate named admin account. The Guest account should always be disabled.

Apply the principle of least privilege. Do not add service accounts or application accounts to the Administrators group unless absolutely necessary. Create custom groups with only the specific permissions each role requires.

Use Managed Service Accounts where possible. For services that require domain authentication, Group Managed Service Accounts (gMSA) automatically rotate passwords and do not require manual management.

Audit account changes. Enable auditing for account management events in secpol.msc under Local Policies > Audit Policy > Audit account management. This records all create, delete, enable, disable, and group membership changes to the Security event log.

Do not share local accounts. Every person and every service should have its own account. Shared accounts make auditing impossible and complicate incident response.

Regularly review group membership. Run the following to get a quick audit of all non-default local group members:

Get-LocalGroup | ForEach-Object {
    $GroupName = $_.Name
    Get-LocalGroupMember -Group $GroupName -ErrorAction SilentlyContinue |
    Select-Object @{N='Group';E={$GroupName}}, Name, PrincipalSource, ObjectClass
} | Format-Table -AutoSize

By applying consistent naming conventions, strong password policies, and least-privilege group assignments, you ensure that local accounts on Windows Server 2022 do not become an unnecessary liability in your environment.