2016 scheduled tasks

This topic contains 2 replies, has 2 voices, and was last updated by  John Curtiss 2 weeks, 4 days ago.

  • Author
    Posts
  • #83198

    John Curtiss
    Participant

    I just exported three scheduled tasks from a 2012 r2 server and imported them to a 2016 server. all three of them have Actions in the format of:

    Start a Program
    program/script: Powershell
    Add arguments: &'\\server\share\script.ps1'

    the script.ps1 part is different on all three, but the folder path is the same.

    two of the tasks run as the local system account. one of them runs as a domain account. they all worked fine on 2012r2. on 2016, the two running as the local system account still run fine, but the domain account one will not run. the result is 0x1, and the return code is 2147942401.

    I've also tried changing the argument to:

    -file "\\server\share\script.ps1"

    with similar results.

    if I remove the arguments, the task runs. presumably it just opens powershell in the background somewhere, because it runs until I kill it. but it doesn't throw the 0x1 error. also, if I change the action to "program/script:net" "add arguments:start" (net start) the script again runs fine.

    so the issue seems to be specifically with passing arguments to powershell.exe with domain credentials, rather than running any scheduled task with domain credentials, which is what I found when I searched the interwebs for "scheduled task return code 2147942401".

  • #83450

    Alex Aymonier
    Participant

    What PowerShell commands have you tried so far?

  • #83507

    John Curtiss
    Participant

    i figured it out. \\server\share\script.ps1 isn't signed, and the executionpolicy is remotesigned. so I had to add "file://server" to the intranet sites in internet explorer on the 2016 server. I have a group policy that is supposed to handle this, but I think 2016 uses a different registry location for its IE zone maps (also I lied, the original server where the script worked was a 2008 R2 server, not a 2012 R2 server).

    I thought I had tested running the script from a command prompt window on the 2016 before I posted this thread, but I guess I hadn't. doing so told me about the executionpolicy issue.

You must be logged in to reply to this topic.