Local Powershell command works, but not via Automox.

  • 3 December 2021
  • 6 replies


I am trying to run the following command with Powershell to remove a specific user from the Administrators group:

Remove-LocalGroupMember -Group Administrators -Member chnlocaladmin

When I run this with elevated permissions (SYSTEM) in Powershell on the machine itself, it works perfectly fine. However, deploying it via a worklet in Automox does not work. 

My worklet:

Evaluation Code:

1. Exit 1

Remediation Code:

1. Remove-LocalGroupMember -Group Administrators -Member chnlocaladmin

When I run this manually, the local user is still part of the administrators groups. I gave it a few minutes to run and still nothing. Running the same command locally works fine. 

Any ideas what could be going wrong?


Best answer by jack.smith 9 December 2021, 21:13

View original

6 replies

Userlevel 5

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


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



Could also try to fallback to net commands.


net localgroup Administrators /DELETE

Thank you so much! 

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

Userlevel 5

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.



Which if you find that to be true I’d encourage you check-out the 64-bit registry workaround here 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."

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.