A Specified Logon Session Does Not Exist – Scheduled Task | Quick Fix Steps

When this message appears while you create or save a task, Task Scheduler is unable to keep the account details it needs to run that job in the background.
On current Windows versions, Task Scheduler relies on Credential Manager and local security policies to store those details safely.
If a policy blocks storage, or the account behind the task no longer signs in in a valid way, you see the logon session error and the task will not save or run.

This guide walks you through what the error really means, why it often links to the “Network access: Do not allow storage of passwords and credentials for network authentication” setting, and how to fix it without weakening your security more than necessary.
You will see step-by-step changes in Task Scheduler, Local Security Policy, and Group Policy, plus safer alternatives when policy changes are not allowed.

Understanding The Logon Session Error In Task Scheduler

A Windows logon session is the context Windows creates when an account signs in.
That session carries the user’s identity, permissions, and credentials.
Background tasks that run “whether the user is logged on or not” rely on stored credentials so Windows can create a special logon session at run time, even while nobody is at the console.

The classic text of this issue reads “A specified logon session does not exist. It may already have been terminated. (0x80070520 or 0x520).”
In the scheduled task case, the problem usually appears at the moment you press OK after entering a user name and password in the task properties window.
Instead of accepting the password, Windows shows the error and refuses to save the task.

Behind the scenes, Task Scheduler calls into Credential Manager to store a secret that lets it recreate the logon session later.
When a security policy tells Windows not to cache passwords or credentials, that storage step fails.
As a result, the scheduler cannot create the background session it needs, and it reports that the logon session does not exist.

Why “A Specified Logon Session Does Not Exist – Scheduled Task” Appears

In most modern Windows builds, this error shows up due to a small set of causes.
Some relate to security policy, others to the account or to how the task itself is configured.

• Blocked credential storage policy — The security option “Network access: Do not allow storage of passwords and credentials for network authentication” is enabled through Local Security Policy or Group Policy, so Credential Manager is not allowed to keep secrets for scheduled tasks.
• “Run whether user is logged on or not” selection — On the General tab of the task, the radio button for running the task whether the user is logged on or not requires stored credentials. With the storage policy enabled, this combination fails every time.
• Changed or disabled user account — The account chosen for the task may have been disabled, deleted, or removed from the domain. That can stop Windows from creating a fresh logon session when the task runs.
• Password changes without task updates — If the task stores a password and the account’s password changes, the stored secret may no longer match. Task Scheduler then fails to start the job and can throw the same logon session message.
• Missing batch logon rights — If the account no longer holds “Log on as a batch job” rights, the background sign-in tied to the task can fail during creation of the session.

On managed networks, the first item is by far the most frequent.
Many security benchmarks recommend enabling the policy that blocks local storage of passwords and credentials, so administrators often turn it on at the domain level.
That setting boosts protection but makes unattended scheduled tasks harder to configure unless you adjust how those tasks run.

Fixing The “A Specified Logon Session Does Not Exist” Scheduled Task Error

If you control the machine’s security options and the risk profile allows it, you can clear the error by changing the password storage policy and then saving the task again.
This method keeps the “Run whether user is logged on or not” behavior, which many maintenance jobs need.

1. Open Local Security Policy — Press Windows+R, type secpol.msc, and press Enter on the affected server or PC.
2. Browse to Security Options — In the left pane, expand Local Policies, then select Security Options.
3. Locate the credential storage policy — In the right pane, find Network access: Do not allow storage of passwords and credentials for network authentication.
4. Change the policy to Disabled — Double-click it, set it to Disabled, and apply the change. You may need a reboot before every component respects the new value.
5. Re-create or edit the task — Open Task Scheduler, edit your job, keep “Run whether user is logged on or not” selected, re-enter the account and password, and save.

After this sequence, Task Scheduler should accept the password without the logon session error, because Credential Manager can now store the secret again.
The next scheduled run then creates a background logon session with that account and runs the task normally.

The trade-off is clear: allowing credential storage gives scheduled tasks freedom to run, but it also increases the amount of cached secrets on the machine.
On shared or high-risk servers, many security teams prefer to keep the policy enabled, so the next sections cover options that keep the stricter setting while still letting you automate work.

Changing Task Settings When You Cannot Store Passwords

On systems where you must leave the “Do not allow storage of passwords and credentials” policy enabled, you can still use Task Scheduler with a few adjustments.
The idea is to pick settings that do not depend on cached passwords or to shift the work to an account type designed for unattended use.

1. Run only when the user is logged on — Edit the task, go to the General tab, and choose Run only when user is logged on. Task Scheduler no longer needs to store a password, since the account already has a live session on the desktop.
2. Use a dedicated service account — Create a domain or local account for automation, assign “Log on as a batch job,” and sign in interactively once to confirm it works. For tasks that only run during working hours, keeping that account signed in on a locked session is often enough.
3. Avoid mapped drives in the task — If your script depends on mapped letters, change it to use UNC paths with credentials handled inside the script, or rely on access permissions granted to the task account rather than separate stored secrets.
4. Check for expired or locked accounts — If the message appears even with less strict policy settings, confirm that the task account is not locked out and that its password has not expired.

These changes shift the error from “cannot create a session” to “session already present.”
For basic maintenance tasks on a single server, setting the job to run only while a specific admin account is logged on can be a simple, low-risk option.
For larger setups, service accounts give you more control over which jobs run where, without sharing personal accounts.

Group Policy, Domain Setups, And Safer Workarounds

Many administrators first see the a specified logon session does not exist – scheduled task message right after a security hardening project in a domain.
A new Group Policy Object often enables the password storage restriction on all servers or workstations under an organizational unit, breaking tasks that used to save credentials without complaint.

If your machine receives settings from Active Directory, changing Local Security Policy alone may not stick, because the domain GPO resets the value.
In that case, you either adjust the Group Policy configuration or move the machine or task to a part of the domain where a more relaxed policy is acceptable.

• Use a separate GPO for automation servers — Place servers that host unattended jobs in an OU with a slightly different security policy that allows credential storage while still keeping other hardening rules.
• Adopt group managed service accounts (gMSA) — On newer domain levels, gMSA accounts let Windows handle password rotation for services and scheduled tasks, avoiding manual secret storage while keeping strong authentication.
• Document exception reasons — When you must turn off the password storage block on a set of machines, write down which tasks depend on it, who owns them, and how often the exception will be reviewed.

Aligning scheduled tasks with domain policy takes a bit of planning, but it prevents a long list of per-machine tweaks that nobody tracks over time.
You reduce surprise breakage when security baselines change, and it stays clearer which tasks are allowed to hold cached secrets.

Quick Reference Table For Common Scenarios

The table below summarizes common situations that trigger this Task Scheduler error and which approach usually works best.
It gives you a fast way to pick a fix that fits both your automation needs and your security level.

Scenario	Recommended Fix	Notes
Single admin PC, local maintenance scripts	Disable credential storage block and save task with stored password	Low exposure; document the change and restrict admin access to the device.
Shared server with strict security baseline	Keep storage blocked; run tasks only when a service or admin account is logged on	Avoid extra cached secrets; use service accounts and locked sessions.
Domain with many unattended jobs	Use gMSA or a separate OU/GPO that balances automation and password storage rules	Centralizes control, keeps logs clear, and simplifies future reviews.

Treat this logon session problem as a hint that your scheduled task pattern and your security policy need to match.
When those two line up, the error disappears and you keep a clear view of where credentials live.

Preventing The Logon Session Error In New Scheduled Tasks

Once you have fixed existing jobs, a few habits can stop the same logon session problem from returning as you add new automation.
Planning how each task authenticates, and where its secrets live, keeps Task Scheduler stable through policy changes.

1. Define the run context early — Decide whether the task truly needs to run while nobody is logged on. If not, prefer “Run only when user is logged on” and avoid stored passwords entirely.
2. Standardize on service or gMSA accounts — Use named automation accounts instead of personal user accounts for scheduled jobs. This keeps tasks running smoothly when staff leave or change roles.
3. Keep tasks free of hidden credential prompts — Design scripts and tools so they do not pop up sign-in dialogs. Rely on access that the task account already has, or on secure secret storage built for automation.
4. Review tasks after policy changes — When your security team updates baselines or GPOs, quickly scan critical scheduled jobs to confirm they still save and run without the logon session message.

Over time, these practices lower the chance that you will run into the a specified logon session does not exist – scheduled task error on a busy day when an urgent job needs to run.
Tasks keep their required access, security policies stay aligned with guidance from Microsoft and industry benchmarks, and your maintenance scripts remain predictable.