The password change took two minutes. The lockouts have lasted three days. A service account's old password does not live in one place — it lives in a dozen, and every single one of them is still knocking on the door.
Service accounts are the repeat-lockout champions of any server room, because a password change only updates the account in Active Directory — it does not reach into the places where that password was typed over the years: services, scheduled tasks, application pools, backup jobs, scanners. Each of those keeps presenting the old password, on a schedule, forever. The result is depressingly predictable: lockouts that return like clockwork after every unlock. This page gives you the complete hunt list, in the order real incidents unfold, and ends with the permanent cure — managed service accounts, whose passwords nobody types at all.
Windows could not start the Backup Agent service on Local Computer. Error 1069: The service did not start due to a logon failure.
Start where every lockout investigation starts: Event 4740 on the domain controller names the locked account and the Caller Computer. For service accounts the caller is usually a server — note which one. Then, on that server, filter Event 4625 for the account and read the Logon Type: type 5 means a service tried to start, type 4 means a scheduled task (batch logon). One glance separates "the backup service" from "the 2 AM task" before you open a single console. Match the lockout times to schedules — a lockout always at :15 past the hour is a task; one that follows server reboots is a service set to automatic start with a stale password.
Check each location on the caller machine (and any sibling servers using the same account):
services.msc, sort by the "Log On As" column, open each service using the account and re-enter the new password on the Log On tab.net use mappings and Credential Manager entries on admin workstations.The professional version of a service-account password change looks like this: inventory first (use the hunt list above, before the change, while everything still works), then change the password in AD, then update every location in one maintenance window, then restart the services and tasks deliberately to prove they start cleanly. Verify with the logs: no new 1069 errors, no fresh 4625 failures for the account, and Search-ADAccount -LockedOut staying empty through a full schedule cycle — including the nightly and weekly jobs people always forget. Skipping the inventory step is how a "two-minute password change" becomes a three-day lockout mystery; the hour of preparation is the entire trick.
There is a class of account designed to end this problem forever: group Managed Service Accounts (gMSA). With a gMSA, Active Directory itself generates a long, complex password (240 characters), stores it, and — the magic part — rotates it automatically every 30 days, updating the services that use it. No human ever knows the password, so no human ever types it into a service, a task and a scanner and forgets two of the three. Services, scheduled tasks and IIS app pools on modern Windows Server all support gMSA identities (the account name ends with a $ sign, and the password field is simply left blank). Migrating your worst offenders — backup, monitoring, the app pool that locks monthly — to gMSA converts an eternal chore into a non-event. Until then, keep a written register of every place each service account's password lives; future-you, mid-incident, will be grateful.
The complete lockout policy walkthrough and all 3 recovery methods, shown live on a real Windows system — this is the video this guide is based on.
▶️ Watch Full VideoBecause something runs at that time with the old password — most often a scheduled task, a backup job or a monitoring check. Match the lockout time in Event 4740 to task and job schedules on the caller machine, and check the Logon Type in Event 4625: type 4 means a task, type 5 a service.
Error 1069 means the service could not log on with its configured credentials — almost always because the account password changed and the service still holds the old one. Open the service properties, Log On tab, and re-enter the current password, then start the service.
A group Managed Service Account is an Active Directory account whose password is created and automatically rotated by the domain itself — nobody knows it or types it. Services, tasks and IIS pools can use it, which removes the entire class of 'old password stored somewhere' lockouts.