How to Manage Users in Windows Server 2019: Administrator’s Guide

To manage users in Windows Server 2019, use Local Users and Groups (lusrmgr.msc) for accounts on one server and Active Directory Users and Computers (dsa.msc) for domain accounts. A small office with a handful of servers, and you need to manage users in Windows Server 2019. One domain controller, a file server, an old standalone machine. Somebody new starts on Monday. For that, you pick one of two places. Which one depends on the server and the domain.

• Local accounts: Local Users and Groups, one server only.
• Domain accounts: Active Directory Users and Computers, every joined machine.
• Bulk jobs: PowerShell, for both kinds.

Local accounts live in Local Users and Groups, on that one server. Domain accounts live in Active Directory Users and Computers and work on every joined machine.

PowerShell does the same jobs from the command line. That’s where we end up for anything bigger than two accounts.

Local and domain accounts: two ways to manage users in Windows Server 2019

A local user is stored in the Security Accounts Manager database, the SAM, of one server. It can sign in to that server only.

A domain user is stored in Active Directory, on a domain controller. It can sign in to any computer joined to the domain.

Standalone and workgroup servers use local users. Domain environments manage almost everyone centrally.

Even in a domain, a few local accounts usually stay. On a file server we’d keep one local admin account, with a long password in the password manager.

If the server ever loses its trust relationship with the domain, that account is the way back in.

Domain controllers are the exception. Once a server is promoted to a DC, it has no local SAM accounts of its own. Everything happens in Active Directory.

Not on a domain yet? Our guide to joining Windows Server to a domain covers that step.

Opening the tools to manage users in Windows Server 2019

For local accounts, press Win+R and run lusrmgr.msc. Or right-click Start, open Computer Management and expand Local Users and Groups.

For domain accounts, open Server Manager, then Tools, then Active Directory Users and Computers.

On a member server or an admin workstation, the Active Directory consoles come with the Remote Server Administration Tools. On Server 2019 you add them through Server Manager.

1. Open Add Roles and Features.
2. Go to Features, then Remote Server Administration Tools.
3. Tick AD DS and AD LDS Tools.

Most of this work happens over Remote Desktop. If that isn’t set up yet, see how to enable RDP on Windows Server.

How to create a local user

1. Press Win+R, type lusrmgr.msc and press Enter.
2. Select Users, then right-click it and choose New User.
3. Fill in User name, Full name and Description.
4. Enter the password twice.
5. Choose the options from the table below. Click Create, then Close.
6. To make the user a local admin, open Groups and double-click Administrators. Click Add and type the user name.

The account works at once and joins the local Users group. More detail in our guide to adding a user in Windows Server.

The full name is optional. It saves time when you read security logs later.

By default Windows Server enforces password complexity. A short or simple password is rejected.

Each exception you tick weakens the defaults a little. So we’d write down why it exists, in the Description field.

Name service accounts with a prefix such as svc-, and put the application name in the description. Six months later, nobody remembers what “backup2” was for.

Manage users in Windows Server 2019 with PowerShell

PowerShell 5.1 on Server 2019 ships the LocalAccounts module. Its cmdlets for local accounts work out of the box. For domain accounts, the ActiveDirectory module adds its own set. Run the console as administrator.

A local user, created with no password typed into the script, then added to the local Administrators group:

$Password = Read-Host -AsSecureString
New-LocalUser -Name "TechSupport" -FullName "Technical Support" -Description "Local admin for emergency repairs" -Password $Password
Add-LocalGroupMember -Group "Administrators" -Member "TechSupport"

A domain user in a specific organizational unit:

New-ADUser -Name "John Smith" -GivenName "John" -Surname "Smith" -SamAccountName "jsmith" -UserPrincipalName "jsmith@yourdomain.com" -Path "OU=Sales,DC=yourdomain,DC=com" -AccountPassword (Read-Host -AsSecureString "Password") -ChangePasswordAtLogon $true -Enabled $true

Old versions of this page converted a plain-text password into a secure string. It works. The password then sits in plain text in the script. In your PowerShell history too.

Test passwords have a way of turning up in transcript files. The Read-Host approach asks for the password and stores nothing.

Other commands for every week:

Get-LocalUser
Set-LocalUser -Name "jsmith" -Password $Password
Disable-LocalUser -Name "jsmith"
Remove-LocalUser -Name "jsmith"

Get-ADUser -Filter *
Set-ADAccountPassword -Identity jsmith -Reset
Disable-ADAccount -Identity jsmith
Unlock-ADAccount -Identity jsmith
Remove-ADUser -Identity jsmith

For bulk work, use a CSV with one row per person. Piped from Import-Csv into New-ADUser, it creates a whole department in seconds.

The parameter list for local accounts is on Microsoft Learn: New-LocalUser.

Adding domain users in Active Directory Users and Computers

1. Run dsa.msc on the domain controller, or on a machine with RSAT.
2. Expand the domain and click the target OU, for example Sales.
3. Right-click the OU and choose New, then User.
4. Enter the names and the User logon name.
5. Set the initial password and the options. Click Next and Finish.
6. Open the account, go to the Member Of tab and add the department groups.

Three notes on those steps.

• The right OU from the start. Then the right Group Policy applies at first sign-in.
• One naming rule for the whole company. jsmith, john.smith, whatever you pick.
• A temporary password. Tick “User must change password at next logon”.

Admin accounts need extra care. Never do daily work, email or browsing with a Domain Admins account.

We’d run two accounts per admin. A normal one for everyday tasks, and a separate admin account used only for changes on servers. A phishing link then only catches the everyday one.

Password rules for domain accounts are set in Group Policy. Our guide to password policies in Windows Server 2019 walks through length, complexity and lockout settings.

Copying an existing user with right-click, Copy carries over group memberships and some profile fields. We’d use it for a new hire who does the same job as a colleague.

Organizing people into groups

Give access to groups, not to individual users. Create security groups that match job roles or departments. Grant folder and app permissions to those groups, then add people to them.

When someone changes roles, you change group membership once. No editing of permissions on every share. That single habit saves the most admin time in Windows Server.

A three-level setup typically works for small and mid-sized offices.

Access to a folder is then granted by nesting. Never by adding a person directly to a share.

Growing companies typically add one more layer for divisions, and that’s fine. What hurts is the opposite: dozens of shares with single names on their permission lists.

Cleaning that up later? Every share, one by one, permission by permission. Groups from day one avoid it.

When someone leaves: disable, then delete

Disable the account first. Delete it later. Many teams wait 30 to 90 days.

One detail people miss. Disabling doesn’t throw out a session that’s already open. That user stays signed in, only new sign-ins fail. Hence the password reset in step 2, and a sign-out on the user’s PC if it matters.

1. Disable the account. Right-click it and choose Disable Account, or use the cmdlet from the listing above.
2. Reset the password, so no cached session continues to work.
3. Move the account to a “Disabled Users” OU and write the leave date in the description.
4. Hand over the person’s files and mailbox. Then remove the group memberships.
5. Delete the account after your retention period.

The Active Directory Recycle Bin gives you a way back even after a deletion. You turn it on in Active Directory Administrative Center. It has to be enabled before the account was removed. A Windows Server backup is the other safety net.

When a user can’t sign in

The cause is usually one of four things.

• The account is locked after too many wrong passwords.
• The password expired.
• The account is disabled, or past its expiry date.
• The user lacks the right to sign in to that machine.

Open the account properties and check the Account tab first.

Repeated lockouts often come from an old password saved somewhere. A phone, a mapped drive or a scheduled task.

In Active Directory Administrative Center, the account view shows the lockout state and the last bad password time. The older console makes that harder to see.

If the admin password itself is the problem, see how to change a Windows Server password.

Add a user in Windows Server 2016, 2022, 2025 and 2012

The steps above aren’t tied to 2019. The consoles look and work the same across releases. What differs is PowerShell.

Why the gap on 2012? Its PowerShell predates the LocalAccounts module. Windows Management Framework 5.1 brings the PowerShell of Server 2016 to 2012 and 2012 R2, and the local user cmdlets come with it.

On Server Core, any release, the GUI rows drop out. PowerShell then, or the old command-line tool further down this page. Or manage the accounts remotely from a machine with RSAT.

Built-in groups worth knowing

Every Windows Server comes with local groups already set up. Adding a user to one of them is often all the access a person needs.

Backup Operators deserves a second look. Restore rights reach every file on the server, so we’d treat that group almost like Administrators.

The built-in Guest account is disabled by default. Leave it that way.

Windows Server versions this user guide covers

The consoles and cmdlets are the same in the newer releases. So the page applies to them as well.

Need a key? Our Windows Server 2019 Standard key comes as a genuine license. Delivery is instant to email.

The old net user command

It still works on every current release, from an administrator Command Prompt. Simple, with fewer options than PowerShell.

net user jdoe * /add /fullname:"John Doe" /comment:"Accounts team"
net localgroup "Remote Desktop Users" jdoe /add

The asterisk in place of the password makes the command ask for it. So the password doesn’t end up in your command history.

Add the /domain switch on a domain-joined machine, and the account gets created in Active Directory. For quick batch files on old servers, we’d still reach for it.

CALs for the people you add

Creating the account is free. Using the server legally is another matter. The Standard and Datacenter editions use the core plus CAL model.

• Every user or device that connects needs a Windows Server client access license.
• Remote Desktop sessions need an RDS CAL on top.
• Essentials editions work differently. They cover a small business of up to 25 users without separate CALs.

Windows Server itself sets no practical limit on the number of accounts. Licensing does.

Our guide to managing CAL licenses in Windows Server 2022 explains user versus device CALs, and how to install them.

Need a key? We sell a genuine Windows Server 2025 Standard license. Delivery is instant to email.

Security habits when creating accounts

• Give each person their own named account.
• Use a naming convention that identifies the person or purpose without revealing sensitive details.
• Apply least privilege. Membership in Administrators is the exception, not the default.
• Give administrators a normal account for daily work and a separate admin account.
• Force a password change at first sign-in.
• Avoid “password never expires”, except for documented service accounts.
• Document every service and emergency account, including who knows the password.
• Audit accounts every quarter. Disable unused ones before deleting them.
• Disable leavers the same day they go.
• Split duties where you can. The person who creates accounts shouldn’t always be the one who grants privileges.

Passwords in scripts

Avoid them. A plain-text password in a script or a CSV can be read by anyone with access to the file. Read it as a secure string, or use Get-Credential. And force a change at the next logon.

Password complexity on standalone servers

Complexity is enforced by default on domain controllers and member servers, through Group Policy. A standalone workgroup server is different. Microsoft lists complexity as disabled there by default. Check the local policy with secpol.msc, at this location:

Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy

Microsoft’s reference for the password complexity setting lists the defaults per server type. Forgot an admin password along the way? Follow our steps to change a Windows Server password.

A checklist for a new starter

1. Create the account in the right place. Local or domain, and the right OU.
2. Set a temporary password with a forced change at first sign-in.
3. Add the groups the job needs, and nothing more.
4. Check that a CAL is available for the person.
5. Note the account in your documentation, with the date.

Five minutes when done by hand. Less when it’s a script, and we’d write that script after the third new starter.

Related guides

• How to Rename a Domain in Windows Server 2019