Task Scheduler – A Specified Logon Session Does Not Exist

If you get this error when attempting to create a scheduled task:

Then check to make sure that your “Local Security Policy”  (under Security Settings – Local Policies – Security Options), “Network access: Do not allow storage of credentials or .NET Passports for network authentication” is Disabled:

I’ve now been bitten twice by this, and it’s time to get it down for posterity.

Comments (26)

  1. Anonymous says:

    Perfect!  Just what I was looking for.

  2. Anonymous says:

    I have this error, but when i want to change the local security policy "Network access: Do not allow storage of credentials or .NET Passports for network authentication".  I can't do it because its disabled. Any suggest?

  3. Sounds like a permissions or group policy issue.  I'd check with your admin.

  4. Anonymous says:

    What are the security considerations here – I assume Microsoft leaves that enabled for good reason.

  5. Anonymous says:

    Exactly i would like to know the security considerations for this one! If anyone could throw some light it  would be of great help

  6. As a app dev guy, I can't really speak to the security issues, except to say that I don't think it's enabled by default, and I know that in installing SharePoint 2010 in a plain vanilla environment it is set to DISABLED.  Otherwise, you wouldn't be able to run scheduled tasks (like profile import, etc.) as a specific user.

    From what I've seen it's only enabled in specific tightly secured network environments.

  7. Anonymous says:

    Doug is correct, this is not a default setting, the risk depends on the type of credentials you choose to store. The setting itself is not dangerous.

  8. Anonymous says:

    If your security requirements prevent you from making that change you can use the Domain Local Service Account.  Our systems have to meet very strict security requirements and we cannot disable that setting.  I have used the Local Service account and the task was created.

  9. Anonymous says:

    I am seeing this same issue. We do have a high security requirement, but the local system account will obviously not have credentials to run a scheduled task that calls a file to run against other servers… I am investigting to see what the most secure / accepted method to run a scheduled task on one server against other servers. (Back up Print Queues remotely using PrintBRM for instance…) Any ideas?

  10. Have you looked into putting a WCF service on the other server(s)?  It could be called securely from the "source" server via a scheduled task that's set to run under local permissions.

  11. Anonymous says:

    Thanks Doug!

  12. Anonymous says:

    Worked like a charm!!!

  13. Anonymous says:

    Thanks, its working and saved my time.

  14. Anonymous says:


  15. Anonymous says:

    Thank you!

  16. Anonymous says:

    Network access: Do not allow storage of credentials or .NET Passports for network authentication

    I managed to disable it. However, the next day, it auto enable it back. Any idea to solve this problem?

  17. Talk to whomever is responsible for group policy for your domain.  They'll have to make an exception to the policy that is enforcing this setting on your server(s).

  18. Anonymous says:

    It resolved it.

  19. Anonymous says:

    Thank you!! It works perfect for me.

  20. Anonymous says:

    I'm a systems administrator. The reason for this policy is a good one: SOX compliance. We also have the policy in place here, otherwise when you save the username/password in the task scheduler then you put the password in clear text in the registry (which is the thing that violates SOX compliance).

    Has anyone attempted running the task scheduler service as the account you want to use? If you do this, the password is not saved in the registry as clear text.

  21. Anonymous says:

    This has bitten me twice as well and this blog posting has bailed me out each time.

    Thanks, Doug!

  22. Anonymous says:

    Just what I am looking for. Thanks.

  23. Anonymous says:

    Thank you!!

  24. Peter says:

    Thank You 🙂

  25. Anonymous says:

    Thanks a lot !!!!

    Got this issue while transferring logs from web server to antiphishing server. By grace of god landed in this

    page and its working fine now.

  26. Anonymous says:

    so many insecure servers.   passwords should not be stored in clear text.   setting should be enabled, period.