3

Using Win Server 2012 R2 test machine (not in domain) I was able to get it triggering with the setup:

  • General:

    • When running the task, use the following user account: built in admin account
    • Run whether user is logged on or not: checked (do not store password not checked)
    • Run with highest privileges: checked

  • Triggers:

    • On disconnect from user session (Any user, Connection from remote computer and Enabled all checked)

  • Actions:

    • Start a program: Powershell (Add arguments: -ExecutionPolicy Bypass -File "C:\Scripts\Awesome_Script.ps1"; Start In: C:\Scripts)

  • Conditions:

    • Nothing checked

  • Settings:

    • Allow the task to be run on demand: checked
    • Stop if the task runs longer than: 1 hour
    • If the running task does not end when requested, force it to stop: checked

When I copied everything over (same location and imported the task) to Win Server 2016 test machine (in domain) then the same setup fails to trigger. No errors in History and "Last Run Result" tells me that The task has not yet run.

And of course I updated the “When running the task, use the following user account” to the Server 2016 local admin account. I tried also to run it from Admin group, SYSTEM account, my own (admin) account but nothing helped (these failed also on the 2012 R2).

Does anyone have any ideas why the trigger fails on the Server 2016 (in domain) while the only thing that changed is the Account? What am I missing here?

K6R
  • 41
  • 1
  • 5
  • Can you confirm that your account you use to run task with on Server 2016 has profile already in place (and not a temp one)? Also what is happening if you run task manually? – Mikhail Nov 05 '16 at 19:46
  • Yes, profile is in place. Tested with different accounts and groups by separate admins but still the same result. Manually running the task activates my script without any errors or obstructions. – K6R Nov 10 '16 at 14:38
  • I'm seeing the same sort of issue on windows 10. I can't get the scheduled task to trigger when disconnecting a remote session... – aggieNick02 Jan 26 '17 at 20:55
  • This is going to sound strange but leave the rule in place and sleep on it :D ... We saw positive results after 24 hours passing after the rules creation and activation. Not sure why and if there were contributing factors (i.e. restarts, gpupdates etc.) so I'm hesitant to call it resolved but we were able to get it working as we required and hopefully it will stay that way. – K6R Jan 27 '17 at 06:53

1 Answers1

1

Update: We saw positive results after 24 hours passing after the rules creation and activation. Not sure why and if there were contributing factors (i.e. restarts, gpupdates etc.) so I'm hesitant to call it resolved but hopefully this info can help someone else too.

K6R
  • 41
  • 1
  • 5