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 (27)

  1. Thomas K says:

    Perfect!  Just what I was looking for.

  2. Mike 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. Mike D says:

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

  5. Addy 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. WC 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. WolfPack1953 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. tarnrevick 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. Joshiu says:

    Thanks Doug!

  12. Jerz Mike says:

    Worked like a charm!!!

  13. Suresh Nayak says:

    Thanks, its working and saved my time.

  14. Jerry 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?

  15. 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).

  16. TulsaJoe says:

    It resolved it.

  17. Willy says:

    Thank you!! It works perfect for me.

  18. Scott 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.

  19. Karl says:

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

    Thanks, Doug!

  20. Roja.Potti says:

    Just what I am looking for. Thanks.

  21. Peter says:

    Thank You 🙂

  22. John Bittu A N 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.

  23. Tim says:

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

  24. Alex says:

    Awesome! Thank you for your help! It worked!

Skip to main content