0

I'm trying to create a scheduled task on Server 2012 R2 to run as a domain service account. I select "Run whether the user is logged on or not", and select the domain service account, click on OK, enter the credentials, and then I get this error message:

An error has occurred for task LPAEmail. Error message: The following error was reported: A specified logon session does not exist. It may have already been terminated.

Things I've already tried:

  • Checked that Network access: Do not allow storage of passwords and credentials for network authentication policy is disabled.
  • Logging on to the server as the user.
  • A different domain account.
  • Tried using the local administrator account.
  • Adding the domain account to the local Administrators group.
  • Changing "Configure for" to Vista, Windows 7, and Server 2012 R2. None of them made a difference.
  • Setting to a local account, and then entering credentials for a domain account when prompted.
  • Verified "Password never expires" is checked for the service account.
  • Tried creating a completely new task.

Does anyone have any suggestions on what else to try?

Note: I discovered if I check "Do not store password. The task will only have access to local computer resources.", it works. But this is not an acceptable solution, because the task needs to access remote resources.

Drew Chapin
  • 631
  • 7
  • 16
  • Would anyone care to explain why this was down voted? – Drew Chapin Sep 27 '16 at 16:23
  • Did you verify the `storage of password` setting with GPEdit or RSOP? GPEdit will show the local setting. RSOP will be the effective setting. Downvote was not me. – Clayton Sep 27 '16 at 17:49
  • @Craig620, through RSOP. – Drew Chapin Sep 27 '16 at 17:55
  • Create an new empty task, and try tu put again that user in. I wonder if the task's config are corrupted. (Strange error happen when the file (where the task is saved) got invalid/corrupted entry) – yagmoth555 Sep 27 '16 at 18:01
  • @yagmoth555, I already tried that. Same error. Thanks though. – Drew Chapin Sep 27 '16 at 18:25
  • Does the problem occur with another server in the same OU? – Bill_Stewart Sep 27 '16 at 18:41
  • Did you try enabling the job option to `run with highest privileges`? Is the LPAEmail service account or any groups it belongs to listed beneath: User Rights Assignment / Deny logon as batch job? Try using a dif service account to run a simple test job `echo "hello world" > c:\temp\hello.log` Does that work? – Clayton Sep 27 '16 at 18:44
  • @Craig620, Run with highested privelages results in the same error. Looking under User Rights Assignment in RSOP has all options (including Deny logon as batch job) set to `Not Defined`. I have another Server 2012 R2 instance that also has all of it's User Rights Assignments set to `Not Defined` and it works on that server. Different service account with simple test job also results in the same error. – Drew Chapin Sep 27 '16 at 18:51
  • @druciferre - does the problem occur with another server in the same OU? – Bill_Stewart Sep 27 '16 at 19:30
  • @Bill_Stewart, yes. Both are in the same OU, and both are only members of the Domain Computers group. As far as I've been able to tell they have the same RSOP. – Drew Chapin Sep 27 '16 at 19:34
  • Try this: `Control Panel / Credential Manager / Windows Credentials / Generic Credentials` Remove the credentials the problem task uses. Then Reconfigure the credentials on the task. – Clayton Sep 27 '16 at 19:54
  • @Craig620, after clicking on Windows Credentials, I get the same error... "A specified logon session does not exist..." – Drew Chapin Sep 27 '16 at 19:56
  • Is the `Credential Manager` service running? Do the NTFS perms at `C:\ProgramData\Microsoft\Vault` on the broken system resemble the perms on the working system? – Clayton Sep 27 '16 at 20:31
  • As @Craig620 notes, this must be a problem related to the credential manager on the broken server. – Bill_Stewart Sep 27 '16 at 20:44
  • @Craig620, the Credential Manager service is running on both servers, and the permissions on the Vault folder match on both. – Drew Chapin Sep 28 '16 at 12:00

1 Answers1

0

Turns out the issue was the Credential Manager was disabled via the following registry settings: 

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
"DisableCredMan"=dword:00000000
"disabledomaincreds"=dword:00000000

Both values must be set to 0 in order for the Credential manager to work with domain accounts.

Drew Chapin
  • 631
  • 7
  • 16