Updating PowerShell Core should be simpler

So we have another update of PowerShell core. Excellent that - but to do the update I need to go to GitHub. This is fine but is more work than it should be for most IT Pros. In my case, I just want the latest version on my workstation. While GitHub is a wonderful place, for a lot of more traditional IT Pros who are not into DevOps - it's overhead to what should be a simple process.

Today, we just use Update-Help to get the latest help content. It just works. So can we get an Update-PowerShell that just works?

And how about an installation mode for updates that does not destroy Taskbar pinned shortcuts?

Thomas Lee (@doctordns)

Thomas Lee (@doctordns) This was discussed earlier here

There are few scripts in PowerShell scripts to do this in PowerShell gallery. PSReleaseTools is one of the best one.

I've asked for a long time for the PowerShell team to take ownership of the Chocolatey package as in #2708

My reasoning for this is that Chocolatey can be combined with SCCM so it gives the largest possible surface for implementations of self updating manners

Ryan Yates (@kilasuit)

Thank you for the comment Ryan Yates (@kilasuit).

Yes, I know that you can do just about anything in PowerShell. I could certainly write a function or download the Chocolately package. My point is that it could be an easy fix for the PowerShell team and a reflection that the release cadence of PowerShell is now very different from Windows PowerShell (which is, of course, a good thing in and of it self).

The IT Pro, for whom PowerShell is just a tool, needs a very simple way to keep up to date. This could include:

Automatically ship the updated versions of PWSH to the relevant repos (Linux/Mac/Windows). And convincing the in-box update mechanisms to download updates as a package in the 'normal' way (i.e. on Windows, ship optionally by Windows Update, on Ubuntu enable apt-get) so that IT pros get updates just like other updates. And if you can't enable Windows Update to take the updates, at least put it out onto the PS Gallery
Ship an in-box Update-PowerShell cmdlet that updates 'this' version of Pwsh with the latest version if one exists. Of course, for completness, let it have a -Version parameter to allow me to choose if I need to, and PLEASE: a -NoSideBySide switch which would allow the installer to install into the existing folder so as to not invalidate pinned taskbar shortcuts (I, and I am sure others find having to have to re-create shortcuts after each update a sub-optimal experience). And maybe making side x side vs overwrite an installation option in the Installation GUI?
Finally, during the initial PWSH installation, offer to create a scheduled task or cron job that checked for and updated that version of PWSH.

As I have said, we have Update-Help which is a nice way to get updates - if they exist. I'd like to make updating PowerShell as easy. When I set up a new box, or sit down to do some work on my main workstation, I just run Update-Help to update the version of Pwsh should I there be one. I just want to simplify the tasks involved with taking more regular updates to Pwsh.

I would expect to see Windows Update to take care of the PowerShell Core update process down-the-line. The product is getting very stable. So, why not just let the update handle it!

It the Linux side, all updates are working Great!!

BTW, I agree on not destroying the shortcuts in the Windows task bar.

:)

Joey Aiello (@joeyaiello)

I think a root problem here is standardization of servicing model (in RFC). If PowerShell Core was installed from a package then the updater should use the same channel otherwise it will destroy the previous installation.
I believe that we are still far from standardization here.
We could design a version manifest and publish it like Office 365 does where enumerate all current versions with indication package type, platform, arch and repository. This will allow customers integrate PowerShel Core servicing into their systems.
Perhaps Joey Aiello (@joeyaiello) and Steve Lee (@SteveL-MSFT) could add more.

Joey Aiello (@joeyaiello)

Some further comments

My point is that it could be an easy fix for the PowerShell team

You'd think if it was an easy fix it would have happened by now - but the reality is that it's not easy & currently the easiest method would, on windows, be Chocolatey at this current time

The IT Pro, for whom PowerShell is just a tool, needs a very simple way to keep up to date.
Again for packages this is Chocolatey which is the windows equivalent version of the *nix package managers

Or perhaps as was recently asked the Windows store if it could be made available there #7730 as that would just auto update seemlessly and not be tied into Windows Update

Ship an in-box Update-PowerShell
I strongly disagree with this as this ties the PowerShell team to maintaining a solution that could change in future, that and I disagree that this should even be considered for the above 2 reasons so far

Finally, during the initial PWSH installation, offer to create a scheduled task or cron job that checked for and updated that version of PWSH.
Scheduled task / cron job may be feasible but again ties the team into something to be supported down the line that could very well end up changing drastically anyway as time goes by - this is something however that you could investigate yourself and add as a simple additonal task after install

I would expect to see Windows Update to take care of the PowerShell Core update process down-the-line.

I know that Joey Aiello (@joeyaiello) has hinted about whether this could happen or not, however that's seemingly still completely undecided although there is this long standing issue #6118 and some part of that may require PowerShell Core to be shipped in box with later Windows 10 installs before it could be feasible. That being said other Microsoft products have for a long time been able to tie into the Windows Update system, but IIRC other Products like Visual Studio and VS Code do not get updates this way, so there's not a unified way

It the Linux side, all updates are working Great!!
Well that's because Linux have had package management sorted for years. Windows has had SCCM for packages in enterprises but this doesn't help organisations that have not implemented SCCM or may never intend to.

All in all this issue really boils down to what Microsoft are doing about Package Management in Windows, just as much as it does about updating PowerShell going forward and I am 100% that this is not something that Joey Aiello (@joeyaiello) & Steve Lee (@SteveL-MSFT) and the team want to invest effort into this if there are possibly bigger changes coming around the corner, which would be the right decision even if it does mean that there is not a simple solution in the mean time.

I mean they already have the basics for Package Management in the OneGet Repository https://github.com/OneGet/oneget/ (a semi related team to the PowerShell team) as this is the is the underlying tech for PowerShellGet and already has some Package Management Support built in via Nuget Feeds anyway as well as MSI, MSU, Programs and experimental Chocolatey support.

I have searched all issues for any other similar issues to those already mentioned in this issue and also found the following #7864 #5477 that are also linked to the updating of PowerShell Core.

As long as we are talking about updating, patching, security patches, hotfixes and such, then they should obviously be delivered via Windows Update, because that's the way Windows and Microsoft has done it for decades, and it is the method that "just works" for everyone from end users to IT pros managing thousands of machines in an enterprise environment.

On Linux, Mac and so on, the same updates should obviously be delivered in the way which updates are delivered for that particular OS/device.

Don't go invent something new when we have an infrastructure that's in place which "just works". An infrastructure used by all systems dealing with installations, patching, updating and so on, like for example SCCM.
Have you talked to the SCCM guys? They are experts on how to get updating and patching to work in the real world...it's basically all they do, every day and al the time.

K.I.S.S.!

See also #6118, which is about adding automatic update support to the MSI installer.

See also #9827 where Windows Store install has been asked for again

Today get 7.0.1 update notification, then open VS Code (with PowerShell extension) then get auto download and setup function. :-p

OK, so, now 7.0.2 is out. And again, when opening a PowerShell window, you get the following nag screen.

PowerShell 7.0.1
Copyright (c) Microsoft Corporation. All rights reserved.

https://aka.ms/powershell
Type 'help' to get help.

   A new PowerShell stable release is available: v7.0.2
   Upgrade now, or check out the release page at:
     https://aka.ms/PowerShell-Release?tag=v7.0.2

PS C:\Windows\System32>

You really need an Upgrade command. It is ridiculous to have to download the update from Github and have scroll through a giant list of different releases from different platforms. One shouldn't have to rely on third-party scripts either. It should be built-in functionality.

This is kind of like .NET Core, where every time you install a new version, you get another copy. Then, Microsoft figured out it wasn't good for users that have 9 million different copies of .NET Core on there system and they changed it where it now removes minor versions.

Is PowerShell Core going to replace Windows PowerShell at some point? Microsoft is doing the same confusing business with this that they did with .NET Framework/.NET Core. In other words, a total disaster.

Also, speaking of Update-Help could someone at Microsoft fix that so it actually works. For years, on multiple different computers I have always had the problem where that command fails. I don't understand what is so difficult about this. It should just be a matter of downloading some files. If after years and years you can't get something basic like that working, something is wrong.

I would just assume Microsoft eliminate Windows Update in general and just switch to apt. Again, not sure why this stuff works so much better in the Linux world.

Case in point:

PS C:\Windows\System32> Update-Help                                                                                     Update-Help: Failed to update Help for the module(s) 'ConfigDefender, PSDesiredStateConfiguration, ThreadJob, WindowsUpdateProvider' with UI culture(s) {en-US} : One or more errors occurred. (Response status code does not indicate success: 404 (The specified blob does not exist.).).
English-US help content is available and can be installed using: Update-Help -UICulture en-US.
PS C:\Windows\System32>

I would never expect Microsoft to include such a command natively. What I would expect, and what I believe is already happening, is that updates be available through update services, SCCM, the Microsoft Store, and third-party repositories. There are locations where I am expecting enterprise-level admins are already managing software deployments. For all other use cases, I don't see a problem with existing community modules like PSReleaseTools or even tools like winget. We never had an update command in Windows PowerShell. We got new versions with new operating system releases, and they were available as downloads. I don't see why PowerShell 7.x needs to be any different.

But...all of these backend pieces need to be in place before the nag prompt appears. In fact, I'd like the nag prompt to be delayed for at least a week after the backend pieces have been deployed.

https://devblogs.microsoft.com/powershell/preview-updating-powershell-7-2-with-microsoft-update/ (June 16th, 2021)

But with Microsoft Update, you’ll get the latest PowerShell 7 updates directly in your traditional Windows Update (WU) management flow, whether that’s with Windows Update for Business, WSUS, SCCM, or the interactive WU dialog in Settings. With today’s announcement, you’ll soon be able to try this new update process for yourself on the latest PowerShell 7.2 previews.

#15510

PowerShell Team
Preview updating PowerShell 7.2 with Microsoft Update
Updating PowerShell 7 with Microsoft Update Today, we’re happy to announce that we’re taking the first steps to making PowerShell 7 easier than ever to update on Windows 10 and Server. In the past, Windows users were notified in their console that a new version of PowerShell 7 is available,

Did you try using winget? I use winget upgrade pwsh and it works pretty well
Edit: I see I am not first to suggest this, oh well...

@iamwwc You can set environment variable POWERSHELL_UPDATECHECK=LTS (or =Off).

Today it suddenly prompted me
But this answer helped me. I simply want either an easy upgrade or no prompt to upgrade for now.
Of course, if I had a free moment, I would want an easy command to automatically upgrade to "LTS/stable release"

Steve Lee (@SteveL-MSFT)

Steve Lee (@SteveL-MSFT) / Travis Plunk (@TravisEz13) I think with the fact that we now have the update process in place via MU and the required Registry Keys that this could be seen as closed as resolved?

I kind of disagree.

There is still no Update-PowerShell command to make the update simple. The IT Pro needs to go to github (as noted in the issue(.
MU takes a MONTH before it kicks in. Why does an IT Pro want to sit for a month being nagged each time they open a console?

This is not really simple enough. We can do better.

While there is no cmdlet to update PowerShell, most modern versions of Windows 10 (and all versions of Windows 11) come with winget. So upgrading an MSI or store-based installation of PowerShell is easy using winget:

winget upgrade Microsoft.PowerShell

scoop can also work here - both have their gotchas, eg microsoft/winget-cli#2123 and scoop breaking on updating pwsh even if all pwsh sessions are killed because it uses pwsh to do all the things :|

Marking as answered per this comment

I still stand by my original comment.

The prompt is still completely misleading.

How would I "Upgrade now"? What is the command? What is the process to do this right now? If this isn't on the roadmap, then at least change the prompt to send the user to the releases page only and call it a day.

Thomas Lee (@doctordns)

Thomas Lee (@doctordns)

should never happen because there is no need for a cmdlet to do this when a proper IT Pro would be making use of MU to update their tooling.
MU update time can & should be decreased, however that isn't an issue that can be resolved in this repository and will need other teams to make it happen.

Ryan Yates (@kilasuit)

Ryan Yates (@kilasuit)

MU update time can & should be decreased

The only way we (PowerShell) can decrease the time in MU is to build the update and delay the updates for 1-4 weeks. If we want faster times, we need to work with Windows to get the store version of PowerShell in parity with a traditionally installed PowerShell. Those conversations are happening.

Brandon J. Boone (@BrandonBoone) Please open another issue about the language/function of the update prompt.

Navigation Menu

Repository navigation

Updating PowerShell Core should be simpler #8663

19 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Updating PowerShell Core should be simpler #8663

Description

Activity

kvprasoon commented on Jan 17, 2019

kilasuit commented on Jan 17, 2019

doctordns commented on Jan 17, 2019

MaximoTrinidad commented on Jan 17, 2019

iSazonov commented on Jan 17, 2019

kilasuit commented on Jan 22, 2019

Bartolomeus-649 commented on May 12, 2019

ExE-Boss commented on May 12, 2019

kilasuit commented on Jun 21, 2019

kkbruce commented on May 15, 2020

jemiller0 commented on Jun 12, 2020

jemiller0 commented on Jun 12, 2020

19 remaining items

jdhitsolutions commented on Jun 14, 2021

Viajaz commented on Sep 8, 2021

Luk164 commented on Oct 17, 2021

XMuli commented on Apr 27, 2022

kilasuit commented on Apr 27, 2022

doctordns commented on Apr 27, 2022

rkeithhill commented on Apr 27, 2022

fluffynuts commented on Apr 27, 2022

TravisEz13 commented on Apr 29, 2022

BrandonBoone commented on Apr 29, 2022

kilasuit commented on May 3, 2022

TravisEz13 commented on May 3, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions