I’ve used the following to gain insight into what might be going on.

start-transcript C:\windows\temp\worklet-transcript.txt

stop-transcript

Could also try to fallback to net commands.

net localgroup Administrators user.name /DELETE

Thank you so much! 

The net command worked. Just confused as to why it didn’t like the the other command. 

It could have something to do with this

The Microsoft.PowerShell.LocalAccounts module is not available in 32-bit PowerShell on a 64-bit system.

from

https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.localaccounts/remove-localgroupmember?view=powershell-5.1

Which if you find that to be true I’d encourage you check-out the 64-bit registry workaround here https://support.automox.com/help/enforce-windows-registry-settings-worklet. Keep in mind when using this method, EDR tools might pick it up as suspicious traffic as this executes the code as an encoded command. I’ve had fun building filters for Automox commands issued this way as this is very handy for some registry keys.

#### 64-bit code

$scriptBlock = {
    Remove-LocalGroupMember -Group Administrators -Member chnlocaladmin
}

$64bit = & "$env:SystemRoot\sysnative\WindowsPowerShell\v1.0\powershell.exe" -ExecutionPolicy Bypass -WindowStyle Hidden -NoProfile -NonInteractive -Command $scriptBlock

Thanks for the info. 

Unfortunately, our EDR already flags the commands being run regardless. I’ve set up the worklet to run on a schedule, so we’ll be monitoring the alerts and then we’ll tinker with the detections if need be.

Thanks again!

@jack.smith  After doing some more testing, it seems as though the users are unable to sign into their pre-existing local user accounts after restarting and now defaults to the new local admin account. 

I have a worklet that adds a local administrator account:

$Username = "chnlocaladmin"
$Password = "password"

$group = "Administrators"

$adsi =  adsi]"WinNT://$env:COMPUTERNAME"
$existing = $adsi.Children | where {$_.SchemaClassName -eq 'user' -and $_.Name -eq $Username }

if ($existing -eq $null) {

    Write-Host "Creating new local user $Username."
    & NET USER $Username $Password /add /y /expires:never

    Write-Host "Adding local user $Username to $group."
    & NET LOCALGROUP $group $Username /add

}
else {
    Write-Host "Setting password for existing local user $Username."
    $existing.SetPassword($Password)
}

Write-Host "Ensuring password for $Username never expires."
& WMIC USERACCOUNT WHERE "Name='$Username'" SET PasswordExpires=FALSE

I then remove the administrators group from their existing local user accounts using the net commands you suggested that looks like this:

net localgroup Administrators "Firstname Surname" /DELETE

When the user restarts their machine, it presents them with the ‘chnlocaladmin’ account and doesn’t give them the option to switch to their other user account. Have I mistaken ‘/DELETE’ as a command that actually removes the entire local account or just the administrators group? 

From my testing, I saw the local admin account created and also removed the administrators group from my test local user account. After restarting, I had no problems. So very confused as to why these users don’t have the option to sign into their normal user accounts now? 

These machines are not domain joined, just standard Win 10 build with local user account in a WORKGROUP. 

Any ideas? 

Disregard, the users were not part of the ‘Users’ group so when it removed their admin, it left them with no assigned group. A mistake made by their local IT but I have managed to resolve this now.