Repository navigation
Task Scheduler Compatibility Problem #5919
Description
Just installed PowerShell 6.0. Was using 5.1 before.
I updated my scheduled tasks (in the Windows Server Task Scheduler) and I can't name the executable like before. The event gives a 0x80070002 (file not found) error when the task runs.
Checked Path variable, looks fine.
If I put in the full path to pwsh.exe, it works fine. But I'm concerned with doing that since it involves a 6.0.0 folder, which I assume will change.
Please update the installer to fix this shortcoming. (I used PowerShell-6.0.0-win-x64.msi)
Activity
bergmeister commentedon Jan 16, 2018
I briefly looked into it and this is not related to the recently found issue of registry keys being in HKCU in 6.0 since the same happens when using HKLM.
As a current workaround you can use
I found that adding a registry key with value
C:\Program Files\PowerShell\6.0.0\pwsh.exeand namepwsh(the name itself actually does not matter) inHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environmentwould enable your scenario. This is the place in the registry for environment variables.But just a word of warning: If you do not have a specific reason to upgrade to 6.0, then sticking to 5.x might be the better (more pain free) solution for Windows for the moment being (although it allows us at least to get more feedback). PowerShell Core was developed to be cross platform and contains many breaking changes and is not meant to replace Windows PowerShell (yet).
iSazonov commentedon Jan 17, 2018
You can use full path in Task Schedule
C:\Program Files\PowerShell\6.0.0\pwsh.exeal-ign commentedon Jan 17, 2018
To use PATH method, add executable location to global PATH, using sysdm.cpl
To use App Paths, create necessary subkey in 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths' key, for ex:
iSazonov commentedon Jan 26, 2018
@sundarchi1
Feel free create new Issue for enhancing installer to update PATH.We already add $Home to %PATH% since #5101.lwsrbrts commentedon Jan 27, 2018
I can see that my PATH variable ($env:Path) already contains the correct location for the pwsh.exe binary but I still get this issue, so adding it to the global PATH variable alone doesn't seem to be a suitable fix - at least not for me.
PowerShell.exe is located in the App Paths registry location though, so that is probably why that works.
iSazonov commentedon Jan 27, 2018
What is output
where.exe pwsh.exe?lwsrbrts commentedon Jan 27, 2018
C:\Program Files\PowerShell\6.0.1\pwsh.exeMaximoTrinidad commentedon Jan 27, 2018
Keep in mind, due to the upcoming new release update(s) to PSCore, the version number will keep changing in the Program Files PowerShell path.
So, whatever changes to the Environment Variable Path will become useless.
Now, we are at PSCore 6 version 6.0.1 and not 6.0.0.
Anything scheduled for PSCore6, the path will need to change manually.
:)
lwsrbrts commentedon Jan 27, 2018
Maximo Trinidad (@MaximoTrinidad) - yes, that is basically the exact reason for this issue and my subsequent opening of #6046. The issue has opened wider discussion about what goes in the PATH and/or App Path when there's a side-by-side installation and in the event there is, if the user types in "pwsh.exe" from "cmd.exe", which version is opened?
lwsrbrts commentedon Feb 4, 2018
@sundarchi1 Ilya (@iSazonov) wrote on #6046 that the App Path was actually already there but was using HKCU, instead of HKLM so registry changes were made to change App Path to be under HKLM in commit #5915 so I guess technically we're just waiting for the next release. The result of other discussions about possible SxS conflicts being that if someone is using SxS then they should really be using the zip and referencing that install manually, should they require it.
lwsrbrts commentedon Mar 16, 2018
I'm still seeing the problem in 6.0.2 but what is strange is that my system PATH (using cmd.exe) shows no mention at all of
C:\Program Files\PowerShell\6.0.2. If I fire upcmd.exeand enterpwsh.exeI get:'pwsh.exe' is not recognized as an internal or external command, operable program or batch file.If however I do
$env:pathinside PowerShell 6.0.2, the folder location is right there on the top line.In Windows PowerShell 5.1, I get the system path.
I'm going to post this then I'll add
C:\Program Files\PowerShell\6.0.2to the system PATH manually, reboot and see what happens.lwsrbrts commentedon Mar 16, 2018
Once added to the system PATH (and after a reboot) the scheduled task executes as expected.
iSazonov commentedon Mar 19, 2018
We'll use standard install path. Please feedback in PowerShell/PowerShell-RFC#115
TravisEz13 commentedon Jul 20, 2018
@sundarchi1 Did you follow the instructions here: #5919 (comment)
lwsrbrts commentedon Jul 22, 2018
Not sure if the same fix for 6.1.0 p4 was applied to 6.0.3 but right after installation of 6.0.3 and before a reboot, the scheduled task didn't run. A reboot later and it worked as expected.
The system path was updated by the installer (leaving behind the previous entry referring to 6.0.2 however). I imagine that with 6.1 this will no longer be a problem if the installs all go in the same place?
TravisEz13 commentedon Jul 23, 2018
@sundarchi1 The previews don't add themselves to the path by design. Only Stable builds do, we are considering adding
pwsh-previewto the path as we did on Linux and Mac.bergmeister commentedon Jul 23, 2018
In the last community call, it was said that August will be the target for the final release.
SteveL-MSFT commentedon Jul 24, 2018
@sundarchi1 #7345 should address your issue