Repository navigation
Task Scheduler Compatibility Problem #5919
Description
Activity
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 valueC:\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).You can use full path in Task Schedule
C:\Program Files\PowerShell\6.0.0\pwsh.exe- You should not use short names in Task Scheduler for obvious security reasons
- Proper way to call any program by short name is adding it's location to PATH environment variable, or using 'App Paths' registry key.
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:
new-item 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths' -Name pwsh.exe -Value 'C:\Program Files\PowerShell\6.0.0\pwsh.exe'- Concerning updating installer to support updating PATH and/or App Paths... well, it should.
@sundarchi1
Feel free create new Issue for enhancing installer to update PATH.We already add $Home to %PATH% since #5101.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.
What is output
where.exe pwsh.exe?C:\Program Files\PowerShell\6.0.1\pwsh.exeKeep 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.
:)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?
@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.
Reacted by Maximo TrinidadI'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.
Once added to the system PATH (and after a reboot) the scheduled task executes as expected.
Reacted by ScribbleGhostWe'll use standard install path. Please feedback in PowerShell/PowerShell-RFC#115
@sundarchi1 Did you follow the instructions here: #5919 (comment)
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?
@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.In the last community call, it was said that August will be the target for the final release.
@sundarchi1 #7345 should address your issue
Reacted by Travis Plunk
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)