Powershell: Task Scheduler Compatibility Problem

[ghost]

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)

[bergmeister]

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.exe and name pwsh (the name itself actually does not matter) in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment would 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]

You can use full path in Task Schedule C:\Program Files\PowerShell\6.0.0\pwsh.exe

[al-ign]

1) You should not use short names in Task Scheduler for obvious security reasons
2) 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' 

3) Concerning updating installer to support updating PATH and/or App Paths... well, it should.

[ghost]

@iSazonov Bad idea, won't 6.0.0 change?

@al-ign Yes, installer should be fixed!

[iSazonov]

@sundarchi1 Feel free create new Issue for enhancing installer to update PATH. We already add $Home to %PATH% since #5101.

[lwsrbrts]

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]

What is output where.exe pwsh.exe?

[lwsrbrts]

C:\Program Files\PowerShell\6.0.1\pwsh.exe

[MaximoTrinidad]

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]

@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?

[ghost]

So what's the preferred fix here? Is the team going to make some changes?

[lwsrbrts]

@sundarchi1 @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.

[ghost]

Ok I'll check this out when the next version releases..

[ghost]

What's the latest on this as of the v6.0.2 "releaes"? (someone spelled that wrong here!)

[lwsrbrts]

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 up cmd.exe and enter pwsh.exe I get: 'pwsh.exe' is not recognized as an internal or external command, operable program or batch file.

If however I do $env:path inside 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.2 to the system PATH manually, reboot and see what happens.

[lwsrbrts]

Once added to the system PATH (and after a reboot) the scheduled task executes as expected.

[ghost]

Will the next version add to PATH automatically?

[iSazonov]

We'll use standard install path. Please feedback in https://github.com/PowerShell/PowerShell-RFC/pull/115

[ghost]

Surprised to see this still unfixed in 6.1.0 preview4 released today.
pwsh.exe still does not work in Task Scheduler without full path!
Note: I installed with "Add PowerShell to Path Environment Variable" checked, but it doesn't look like that actually did anything. Clean Windows Server 2016 install.

Please reopen.

[TravisEz13]

@sundarchi1 Did you follow the instructions here: https://github.com/PowerShell/PowerShell/issues/5919#issuecomment-373817293

[lwsrbrts]

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?

[ghost]

@TravisEz13

1. Install clean Windows Server 2016.
2. Install preview4 release with default options ("Add PowerShell to Path Environment Variable" checked).
3. Reboot.
4. Set up new task in Task Scheduler that launches pwsh.exe, result is: The system cannot find the file specified. (0x80070002)

In fact, it doesn't look like the installer did anything with my environment variables, so that is probably why this isn't working. So, this bug still is present in preview4. Could I add to PATH manually? Yes.. but I shouldn't have to. The installer should do it as it indicates.

Also a note, using PowerShell.exe continues to work fine.

[TravisEz13]

@sundarchi1 The previews don't add themselves to the path by design. Only Stable builds do, we are considering adding pwsh-preview to the path as we did on Linux and Mac.

[ghost]

@TravisEz13 Oh ok, so this should be fully resolved in 6.1 final.. will retest when that comes out.
Any hint when the final release comes out?

[bergmeister]

In the last community call, it was said that August will be the target for the final release.

[SteveL-MSFT]

@sundarchi1 https://github.com/PowerShell/PowerShell/pull/7345 should address your issue

[ghost]

I have found success with the RC1 release.😃 Thanks to everyone involved.
pwsh-preview works in Task Scheduler, and I assume pwsh will work the same upon final release.
Note to anyone reading this later, rebooting after installing PowerShell is important, otherwise you will get 0x80070002 in Task Scheduler.