none
Task doesn't run when "Start in" contains a UNC path

    General discussion

  • We have a central scripts repository on a servershare \\fileserver\scripts$. That directory also contains all the functions and libraries we use in our scripts. On Windows 2008 (R2) this has always worked as a charm. But now we have our first Windows Server 2012, and now it doesn't work.

    We get 2 errors:

    Event ID: 101

    Task Scheduler failed to start "\Simpel test" task for user "Domain\Serviceaccount". Additional Data: Error Value: 2147942667.

    Event ID: 203
    Task Scheduler failed to launch action "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" in instance "{6e09d300-4d0e-4e13-80de-d7091384e939}" of task "\Simpel test". Additional Data: Error Value: 2147942667.

    When I search for this error, I find numerous hits that the path on "Start in" shouldn't contain quotes "". But we don't have quotes in that line, it's just \\fileserver\scripts$. When I run the script from the command line, it workes like a charm, so it has nothing to do with rights. I've also tried the FQDN, and added it to the Trusted Sites.

    If tried everything to my knowledge, and the only times it works, is when I don't use a UNC path but a local path or no path at all. But then the script fails because it can't access the functions and libraries.

    I hope someone has a solution.


    Monday, October 07, 2013 1:35 PM

All replies

  • Not even one suggestion??
    Wednesday, October 09, 2013 6:03 AM
  • Hi,

    Regarding the current issue, I suggest you could try to refer to the following similar thread to see if it could help.

    running a scheduled task in windows 2008 r2

    http://social.technet.microsoft.com/Forums/windowsserver/en-US/6f830896-2370-49db-924a-6caf87deaf6e/running-a-scheduled-task-in-windows-2008-r2?forum=winservergen

    In addition, I suggest we could try to disable UAC and reboot the server to see if the issue persists.

    Hope this helps.

    Best Regards,

    Andy Qi


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time.
    Thanks for helping make community forums a great place.

    Wednesday, October 09, 2013 11:54 AM
    Moderator
  • The topic you refer to is the one talking about quotes. Like I said: I'm not using quotes in the "Start in (optional)" field. Also UAC is disabled for that user, and the server has rebooted a lot of times since.

    When I run the script manually from a dos box running in the context of that user (runas...), the script runs without any problems. Also when I run the script from the scheduler without a UNC path in te "Start in" field, or a local resource (C:\) it also start correctly. Only the script will fail because it cannot access the correct functions and libraries.

    So file- and sharepermission, UAC and execution policy should all be correct. To me it seems a problem in Windows Server 2012.

    PS: If you think I should continue in that thread let me know. I started a new thread just because the solution in the other thread doesn't apply to me.

    Wednesday, October 09, 2013 12:54 PM
  • Am I just the only one in the whole wide world with this problem?

    I can't imagine that no-one else uses "Start-in" with an UNC path. Tried it on several 2012 servers, and it seems that's just a bug in Windows Server 2012...

    Wednesday, October 23, 2013 7:48 AM
  • Hmm...
    It really seems that I'm the only one with this problem...
    And have no idea what more I can do.

    I guess the only solution is to open a solution case at Microsoft Support. :(

    Friday, November 01, 2013 12:09 PM
  • I had the same issue. When I remove the text from 'start in' text box and ran the task it ran just fine. i had given the path explicitly in the 'program/script' box itself. so i was covered and it worked for me...

    Monday, November 04, 2013 6:56 PM
  • I had given the path explicitly in the 'program/script' box itself.

    That's what I experienced also. As long as it isn't a UNC path, it works. Unfortunately our scripts rely on functions in the scripts$ share. I can't access them from the program/script box.

    But it's something with Windows Server 2012, with 2008(R2) it allways ran fine.
    So why isn't there anyone from Microsoft's Server 2012 team who can help me??

    Tuesday, November 05, 2013 9:05 AM
  • I am experiencing the same problem :-( 

    I need to "start in" using UNC (has no quotes), and I get the 2147942667 error code

    As I have recently switched to Windows 8.1, could it be due to this?

    • Edited by RixNox Monday, December 02, 2013 4:07 PM
    Monday, December 02, 2013 3:03 PM
  • As a workaround, for Windows 8.1 users, what once didn't work now does:

    - cut the path in "start in"

    - paste the path in the "program/script" field (Windows 8.1)

    Basically the command has a fully qualified path

    Monday, December 02, 2013 4:30 PM
  • I don't know what you exactly mean? Because I'm pointing at powershell.exe, I can't past that in the program/script field, it has to start from the system root?

    And I don't have Windows 8.1, I'm running Windows Server 2012. And it's quite a critical server, I can't just upgrade it to R2....

    Tuesday, December 03, 2013 6:42 AM
  • I'm experiencing the same problem, but only on a Windows 2012 server configured as DC. I don't have this issue on a member server 2012 - Very strange.

    My current workaround is to run the task from a local path, making sure that this path is in sync with the UNC.

    Thursday, December 26, 2013 11:22 AM
  • I have the same issue on a Windows Server 2008 R2 box and I have discovered that my script fails to run when the scheduled task is running as a user that has not logged onto the computer locally. (IOW, no profile in C:\Users).

    I do not have a solution for this yet.

    Tuesday, April 15, 2014 8:02 PM
  • I have ran the script multiple times with user account under which the script should run. And when ran interactively there is no problem. It's only when it's scheduled, and only when there's an UNC path in the "Start in".
    Wednesday, April 16, 2014 6:26 AM
  • I got a similar issue where I wanted to schedule a program that was found under C:\Program Files(x86)\.
    Task Scheduler failed to start "<Task name>" task for user "<my user>". Additional Data: Error Value: 2147942667.

    I solved it by using the %programfiles(x86)% system variable in both 'program/script' and 'start in'.

    Friday, May 09, 2014 9:37 AM
  • For most UNC pathing cases, whether the UNC pathing is the scheduled task command line, or whether the script itself contains a line having a UNC path,
    you need to specify the DOMAIN credentials in the scheduled task configuration:
    - On the scheduled task, set [tab GENERAL] "Security Options" area, "RUN WHETHER USER IS LOGGED ON OR NOT" and do not check "Do not store password" and click OK -- at the popup, INPUT THE USER'S DOMAIN PASSWORD (ex. \mybusinessdomain\administrator). 
    *Keep in mind, if you change the user password in the future you will NEED to come back here to task scheduler and be sure to change it there as well, or else your jobs will thereafter fail to run.

    If your task runs and then stays in state of status "RUNNING" when you expected it to have completed, it is likely that your script is trying to write to a UNC path resulting in Windows asking for credentials in the background (you can't see it asking).   You could try passing credentials via your script.  Or, within the script you can first map the drive with credentials (ex. net use x: \\my\network\path\directory thepassword ) and then use the drive letter instead of the UNC path - both of these are a security hole, however, as your script will contain the network password, so I don't suggest this.   The best solution is just to assign that network drive full security permissions for user "EVERYONE"

    John Neumann

    Monday, July 21, 2014 2:10 PM