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
Anonymous
October 27, 2010
Perfect! Just what I was looking for.Anonymous
December 12, 2010
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?Anonymous
December 13, 2010
Sounds like a permissions or group policy issue. I'd check with your admin.Anonymous
January 13, 2011
What are the security considerations here - I assume Microsoft leaves that enabled for good reason.Anonymous
February 25, 2011
Exactly i would like to know the security considerations for this one! If anyone could throw some light it would be of great helpAnonymous
February 25, 2011
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.Anonymous
March 02, 2011
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.Anonymous
March 20, 2011
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.Anonymous
April 06, 2011
The comment has been removedAnonymous
April 06, 2011
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.Anonymous
July 22, 2011
Thanks Doug!Anonymous
September 26, 2011
Worked like a charm!!!Anonymous
October 11, 2011
Thanks, its working and saved my time.Anonymous
November 11, 2011
Thanks!Anonymous
December 01, 2011
Thank you!Anonymous
December 11, 2011
Network access: Do not allow storage of credentials or .NET Passports for network authenticationI managed to disable it. However, the next day, it auto enable it back. Any idea to solve this problem?Anonymous
December 11, 2011
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).Anonymous
December 20, 2011
It resolved it.Anonymous
May 30, 2012
Thank you!! It works perfect for me.Anonymous
August 29, 2012
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.Anonymous
January 03, 2013
This has bitten me twice as well and this blog posting has bailed me out each time.Thanks, Doug!Anonymous
February 05, 2013
Just what I am looking for. Thanks.Anonymous
April 28, 2014
Thank you!!Anonymous
January 14, 2015
Thank You :-)Anonymous
January 21, 2015
The comment has been removedAnonymous
March 27, 2015
so many insecure servers. passwords should not be stored in clear text. setting should be enabled, period.Anonymous
July 14, 2016
Awesome! Thank you for your help! It worked!