Updating Remote Scheduled Task Credentials via PowerShell

Question

How can I update credentials for automated system administration jobs across remote scheduled tasks using PowerShell so that each scheduled task automatically uses the updated custom domain service account password so that the tasks stop failing with error 0x8007052E (Logon Failure) after a mandatory password rotation?

Answer 1

Try using PowerShell's Set-ScheduledTask. You can enumerate the tasks that run under the service account, then update each task's Principal with the account name and its new password. For remote computers, use Invoke-Command so the change is made locally on each target machine.

For example, the basic operation is Set-ScheduledTask -TaskName "TaskName" -User "DOMAIN\ServiceAccount" -Password $NewPassword. For multiple remote machines, you can loop through the computer names with Invoke-Command and perform the update on each machine.

For a large environment don't hard-code the password in the script. Store the new credential securely (for example, retrieve it from a password-management system or prompt for it as a SecureString) and have the script update all affected tasks immediately after the service account password is rotated.

Note that Windows does not automatically propagate a service-account password change to scheduled tasks that have that account's password stored in their task definition.

$Credential = Get-Credential "DOMAIN\ServiceAccount"

$Computers = @(
    "SERVER01",
    "SERVER02",
    "SERVER03"
)

$TaskNames = @(
    "\MyTask1",
    "\MyTask2",
    "\MyTask3"
)

foreach ($Computer in $Computers) {
    Invoke-Command -ComputerName $Computer -ScriptBlock {
        param($TaskNames, $UserName, $Password)

        foreach ($TaskName in $TaskNames) {
            Set-ScheduledTask `
                -TaskName $TaskName `
                -User $UserName `
                -Password $Password
        }

    } -ArgumentList `
        $TaskNames,
        $Credential.UserName,
        $Credential.GetNetworkCredential().Password
}

---

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcinpro

Answer 2

Marcin's approach is the right foundation — Set-ScheduledTask with -User/-Password via Invoke-Command is the standard pattern. A few additions that matter once you're doing this across more than a handful of servers, especially right after a forced password rotation:

1. Validate the new credential before you touch anything

The worst outcome is rolling out a typo'd password to 50 tasks and turning one failure into fifty. Test the credential against AD first:

powershell

Add-Type

2. Don't assume every task on every box uses that account

Instead of hardcoding task names, discover them dynamically so you don't miss one that was added after your list was written:

powershell

Invoke-Command

This also protects you from updating tasks you didn't mean to touch.

3. Wrap each update so one bad task doesn't kill the loop, and log results

powershell

$

4. Confirm the fix actually took

Set-ScheduledTask can return success even when the underlying "last run result" doesn't clear until the task fires again. After updating, force a run and check the result code:

powershell

Invoke-Command

A LastTaskResult of 0 confirms it ran clean; 0x8007052E reappearing means the password didn't take (often because the task's "Run whether user is logged on or not" flag requires the account to also have "Log on as a batch job" rights — worth checking on any box that still fails after the update).

5. Root cause, not just remediation

Since this is tied to mandatory rotation, it's worth pairing this script with a scheduled trigger (Task Scheduler event, or a step in whatever rotates the account) so the task-credential sync runs automatically right after rotation — otherwise you're doing this manually every cycle. If the account is a gMSA, this whole class of problem goes away since Windows manages the password automatically and scheduled tasks never store it — worth considering as a longer-term fix if the account only serves these tasks.