Adding Users to a Windows VPS: Accounts, RDP Access, and Profile Fixes

Adding a second person to a Windows VPS is not a matter of creating a “profile” — it is a matter of creating a local user account, granting it the right group membership, and making sure it can pass Remote Desktop’s two gates: the Remote Desktop Users group and, if Network Level Authentication is enforced, the credential that NLA requires before a session is even negotiated. This guide walks through account creation, group assignment, profile management, and the failure modes (temporary profiles and “the connection was denied”) that trip people up most often.

Local Accounts vs. Microsoft Accounts vs. Profiles

Three concepts get blended together constantly. Keep them separate:

• Local user account: the credential (username + password) stored on that specific server. This is what you create for VPS access. Windows Server does not support Microsoft account sign-in the way Windows 11 does, and you should not try to force it.
• User profile: the folder tree under C:\Users\<name> plus the registry hive loaded at HKEY_USERS. It is created automatically on first logon, not manually.
• Group membership: what actually determines privilege. Being in Administrators is different from being in Remote Desktop Users, and confusing the two is the root of most access problems.

Creating the Account from PowerShell

Work in an elevated session. The two cmdlets you need are New-LocalUser and Add-LocalGroupMember:

# Create the account with a password that meets the local policy
$pw = Read-Host -AsSecureString "Password for new user"
New-LocalUser -Name "deployuser" `
    -Password $pw `
    -FullName "Deploy Account" `
    -Description "RDP access for deployments" `
    -PasswordNeverExpires:$false `
    -AccountNeverExpires

# Grant RDP access (the group that controls Remote Desktop logon)
Add-LocalGroupMember -Group "Remote Desktop Users" -Member "deployuser"

# Only if this person truly needs admin rights
Add-LocalGroupMember -Group "Administrators" -Member "deployuser"

Verify the result before handing over credentials:

Get-LocalUser -Name "deployuser" | Select-Object Name, Enabled, LastLogon
Get-LocalGroupMember -Group "Remote Desktop Users"

The Two Gates Every RDP Logon Must Pass

A user in the right group can still be refused. Remote Desktop enforces two independent checks:

• Remote Desktop Users membership: grants the “log on through Remote Desktop Services” right. Without it, logon is refused outright.
• Network Level Authentication: when NLA is on (the default on modern Server builds), the client must authenticate before the server allocates a session. If the account password has expired or the credential is wrong, the user sees “the credentials that were supplied are not valid” before any desktop appears.

You can confirm the group policy side with secpol.msc under Local Policies → User Rights Assignment, looking at “Allow log on through Remote Desktop Services.” If a hardened baseline has removed the Remote Desktop Users group from that policy, adding the account to the group alone will not help. For related hardening controls that keep you from locking yourself out, the reference material on windows-vps.org is worth reading alongside this guide.

Dealing with Temporary Profiles

The classic symptom is a user logging in and getting an empty desktop with default wallpaper, and a notice that a temporary profile was loaded. It happens when Windows cannot load the registry hive for the profile — usually because the profile is locked by a stale session or corrupted. The fix:

# Find and clear any orphaned sessions for the user
query user
logoff <sessionID>

# If the profile hive is damaged, back it up and remove the ProfileList entry
# Check HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

In the registry, look for a subkey whose name ends in .bak. Windows renames a corrupt profile key to <SID>.bak and creates a fresh one. Renaming the .bak key back to the bare SID, after confirming the path in ProfileImagePath is correct, restores the original profile on the next logon. Always export the key before editing it.

Designing Access for More Than Two Users

Windows Server ships with a two-session administrative license. If you need three or more people logged in simultaneously for real work, you are outside that allowance and need Remote Desktop Session Host with RDS CALs. For small teams the practical split is: keep two administrative sessions for admins and one shared service account for deployments, and avoid having users “share” the same login, because concurrent interactive sessions of one account behave unpredictably.

Finally, audit accounts quarterly. Disable rather than delete accounts for people who leave, so their profile and file ownership stay intact, and use Get-LocalUser with the Enabled property as a fast health check. A tidy account list is a security control, not just housekeeping — an enabled account nobody remembers is exactly the door an attacker wants.

Testing Access Before You Hand Over the Login

Before you give a new user their credentials, prove the path end to end from a machine outside your network. Connect with mstsc using the new account, confirm the desktop loads rather than a temporary profile, then open an elevated prompt and check whoami /groups to verify exactly which privileges came through the logon token. If the user is supposed to be an administrator you should see BUILTIN\Administrators; if they are a standard user, its absence is correct. Catching an over-provisioned account at this stage is far easier than revoking rights later. Pair the test with a short access register — who was added, on what date, by whom, and why — so that when someone leaves you can disable the right account immediately. On multi-user servers the two-session administrative limit and RDS CAL rules set a hard ceiling that surprises teams mid-project, and the licensing notes on windows-vps.org explain where that boundary sits before you commit to a plan.