You need a local account on a machine you cannot walk to, and often one with administrator rights — a technician login, a service account for an agent, a break-glass account before a laptop leaves the building. This does it on a remote workstation from your own command line, with no RDP session and nobody logged off.
With PsExec
Download PsTools from Sysinternals, then from your own machine:
cd Downloads\PSTools
psexec \\<ComputerName> -h -u username cmd
PsExec prompts for the password and drops you at a command prompt on the remote workstation. Everything below runs there:
net user "new_username" new_password /add /passwordreq:yes /fullname:"Firstname Lastname" /PASSWORDCHG:NO
net localgroup Administrators "new_username" /add
A detail worth knowing about that psexec line: -u username with no DOMAIN\ prefix authenticates as a local account on the target, which is exactly the case that runs into the UAC problem below.
-h asks PsExec to run with the account's elevated token if one is available. With a domain account that is a local administrator on the target it usually is, and net localgroup Administrators works. With a local account it usually is not, and you get Access is denied whatever flags you pass — the same elevated-token trap that bites when taking folder ownership recursively on Windows. Keep -h; just do not expect it to fix the workgroup case on its own.
What has to be true on the remote workstation
PsExec is not magic: it copies a service to the admin share and starts it. So the target needs File and Printer Sharing allowed through its firewall (that is what exposes ADMIN$), the account you connect with must be a local administrator there, and TCP 445 must be reachable.
Then there is the invisible one. When you authenticate with a local account rather than a domain account, UAC strips the administrative token off the network logon. Everything connects and privileged commands still fail. The fix is a registry value on the target:
reg add \\<ComputerName>\HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f
That form sets it remotely if the Remote Registry service is running; otherwise apply it by GPO, by Intune, or at the console. It takes effect immediately, no reboot. Domain accounts are not affected — if PsExec works everywhere except your workgroup machines, this is why.
It is also a real reduction in that machine's defences, not a formality. With it set, a leaked local administrator credential becomes usable against the machine over the network, which is precisely what Windows blocks by default. Set it where you need it, and remove it when you are done.
The modern equivalent
WMIC has been deprecated for years and is absent or disabled on current Windows builds, so the old WMIC USERACCOUNT ... SET PasswordExpires=FALSE line may simply not run — check with wmic /? before you rely on it. And there is no net user flag that replaces it: /expires:never sets account expiry, not password expiry, which is the mistake everyone makes next. The replacement is PowerShell.
If the remote workstation has PowerShell remoting enabled — on a domain it usually does — the whole thing is two cmdlets and no third-party tool:
$pw = Read-Host -AsSecureString "Password for the new account"
Invoke-Command -ComputerName <ComputerName> -ScriptBlock {
New-LocalUser -Name "new_username" -FullName "Firstname Lastname" `
-Password $using:pw -PasswordNeverExpires -UserMayNotChangePassword
Add-LocalGroupMember -SID S-1-5-32-544 -Member "new_username"
}
Prompting on your machine and passing the value in with $using: keeps the password out of your command history — which net user cannot do, since there the password sits in the console buffer and in any transcript logging you have enabled. -SID S-1-5-32-544 is the built-in Administrators group; use the SID, because on a German or French Windows the group has a different name and net localgroup Administrators fails outright.
Verify
psexec \\<ComputerName> net user new_username
psexec \\<ComputerName> net localgroup Administrators
PsExec errors: Access is denied, Couldn't install PSEXESVC service, The network path was not found
- Access is denied after a successful connection — remote UAC filtering. The registry value above.
- Couldn't install PSEXESVC service — the account is not an administrator on the target, or
ADMIN$is not shared. - The network path was not found — TCP 445 blocked, or File and Printer Sharing is off.
PsExec is also routinely quarantined by Defender and other endpoint products, which is a further argument for the PowerShell path on a managed fleet.
Undo it
net localgroup Administrators "new_username" /delete
net user "new_username" /delete
reg delete HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /f
Deleting the registry value restores the Windows default.
Do not leave this behind
A local administrator account with the same password on every remote workstation is one stolen laptop away from working on the next machine too. For a fleet, use Windows LAPS, which manages and rotates a unique password per device. Note what it does not cover: it backs up to Active Directory or Microsoft Entra ID only, so it is no help on the workgroup machines from the section above — and those are exactly where this recipe is hardest to retire.
