Windows - Security - Enable Local Administrator

What the built-in Administrator enabler does

This Automox Worklet™ enables the built-in local Administrator account on Windows workstations and servers. The Worklet uses PowerShell CIM cmdlets to query Win32_UserAccount, read the Disabled property of the target account, and flip that property back to $false when the account is currently switched off. The default target is the well-known Administrator account (RID 500, SID ending in -500), but the $accountName variable in evaluation.ps1 and remediation.ps1 accepts any local account name, so the same logic enforces enablement on a renamed Administrator or a secondary break-glass account.

The evaluation phase first confirms the account name exists on the endpoint. If Get-CimInstance returns $null, the script writes "The account <name> was not found" to stdout and exits 0 so the policy does not loop on machines where the target account is renamed or removed. When the account exists and Disabled is already $false, the Worklet writes a compliant message and exits 0. Only the disabled-and-present case returns exit 2 to schedule remediation.

The remediation phase pipes the queried CIM instance through Set-CimInstance, sets LocalAccount to $true and Disabled to $false, and then re-queries the account to confirm the change took. A successful flip returns exit 0; a failure path returns exit 2 with the captured exception message in stdout for Automox activity log review. The evaluation logic short-circuits on endpoints where Disabled is already $false, so a recurring policy reads the CIM instance, sees the account in the expected state, and exits without re-running Set-CimInstance.

Why enforce Administrator account state on the fleet

Hardening baselines routinely disable the built-in Administrator account because CIS Windows 10/11 Benchmark control 2.3.1.1, NIST 800-53 AC-2, and most insurer-driven hardening checklists call for it. The problem starts when that same Administrator account is the only break-glass path left when an MDM-managed account locks out, an Entra ID outage prevents cloud sign-in, or a misapplied GPO removes domain accounts from the local Administrators group. Imaging scripts, Sysprep audits, and provisioning tools also disable the account inconsistently, so a fleet that should be uniformly closed ends up partially open and partially locked out.

Sysprep audits, vendor hardening templates, and GPO refreshes have a habit of toggling the Administrator account back to Disabled on machines that should be left open as a break-glass path. The CIM-based check finds the regression on the next run, Set-CimInstance flips Disabled back to $false during remediation, and the next agent check-in confirms the change without a Domain Admin opening RDP on a recovery endpoint at 2 a.m.

How Administrator account enablement works

1. Evaluation phase: The Worklet runs Get-CimInstance -ClassName Win32_UserAccount -Filter "Name='$accountName'" against the endpoint. When the returned object is $null, the script writes "The account <name> was not found" and exits 0. When the account exists and its Disabled property is already $false, the script writes a compliant message and exits 0. When the account exists and Disabled is $true, the script writes "Flagging for remediation" and exits 2 so Automox schedules the remediation script.

2. Remediation phase: The remediation script re-queries the account with Get-CimInstance, pipes the instance through ForEach-Object to set LocalAccount to $true and Disabled to $false, and writes the change back with Set-CimInstance -CimInstance $_. The script then runs a second Get-CimInstance lookup against the same account name and inspects the Disabled property on the refreshed object. A confirmed flip exits 0 with a success message; a refresh that still shows Disabled as $true exits 2; any thrown exception is caught and exits 2 with the exception message in stdout.

Built-in Administrator enable requirements

• Windows 10, Windows 11, or Windows Server 2016 or later with the Automox agent installed

• PowerShell 3.0 or later (CimCmdlets module ships in the box with this version range)

• The Automox agent runs as LocalSystem, which already has the rights needed for Set-CimInstance against Win32_UserAccount; no extra credential configuration is required

• $accountName variable in both evaluation.ps1 and remediation.ps1 set to the local account you want enabled (default is Administrator)

• FixNow compatible, so the policy can be run on demand against a single endpoint for emergency recovery scenarios

• Pair this Worklet with a separate password-reset or LAPS rotation policy before the account is used; enabling the account does not change or set its password

Expected Administrator account state after remediation

After a successful remediation run, the built-in Administrator account on the endpoint reports Disabled = False under Win32_UserAccount and appears as an enabled account in the Local Users and Groups MMC snap-in (lusrmgr.msc). Subsequent Automox policy runs report the endpoint as compliant during the evaluation phase and skip remediation, because the Disabled property reads $false on the first lookup. The account remains enabled across reboots and updates; it is only switched off again by a manual Disable-LocalUser call, a hardening Worklet that explicitly disables it, or a group policy that reapplies the disabled state at the next gpupdate cycle.

Validate the change on a single endpoint with Get-CimInstance -ClassName Win32_UserAccount -Filter "Name='Administrator'" | Select-Object Name, Disabled, SID, in PowerShell. The SID field confirms the well-known -500 suffix, and the Disabled column should read False. For audit evidence, capture the Automox activity log entry from the remediation run alongside the post-change Get-LocalUser Administrator output; both records carry the endpoint identifier and the timestamp the change landed. If your hardening policy requires the account to stay disabled in steady state and only be enabled during a declared incident, schedule this Worklet through a FixNow run scoped to the affected endpoint group rather than a recurring policy, then run the matching disable Worklet once the incident is closed.