Updating PowerShell Core should be simpler

[doctordns]

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?

[kvprasoon]

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

[kilasuit]

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

[doctordns]

Thank you for the comment @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:

1. 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
2. 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?
3. 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.

[MaximoTrinidad]

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.

:)

[iSazonov]

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 @joeyaiello and @SteveL-MSFT could add more.

[kilasuit]

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 @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 @joeyaiello & @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.

[Bartolomeus-649]

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.!

[ExE-Boss]

See also https://github.com/PowerShell/PowerShell/issues/6118, which is about adding automatic update support to the MSI installer.

[kilasuit]

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

[kkbruce]

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

[jemiller0]

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.

[jemiller0]

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>

[fluffynuts]

@jemiller0 this is one of the reasons I've been using scoop for pwsh from day 1. Turns out there's a lot of other useful things in there. Perhaps one day winget will allow third-party repos and I'll consider that, but for now, scoop is the best I've tried (better than chocolatey)

[jemiller0]

One thing worth noting about Powershell 7.0.2: I'm pretty sure the reason it was released is because there was a security vulnerability in it. A good reason to have it updated by Windows Update automatically. Of course .NET Core isn't handled either, which also had a vulnerability. That is kind of the whole reason there was a system-wide install of .NET Framework. So, you only had to patch one install (or a few of different versions). .NET Core does away with that. As a developer, if you aren't careful, you end up with tens of versions of .NET Core on your system (though I think Microsoft tries to uninstall old minor versions now by default).

[iSazonov]

I think it is not real to do something for 7.0 but for next 7.1 version PowerShell MSFT team could sync with .Net team - I guess they are thinking about distribution of security updates for self-contained applications too because a popularity of .Net Core is growing.

[MaximoTrinidad]

So, since PowerShell 7.0.0 (released 3/4/2020) .NET Core 3.1.2.

PowerShell 7.0.1 (released 5/14/2020) needs "Microsoft Windows Desktop Runtime 3.1.3 (x64)" components for our products to work.

Then, the recent release of PowerShell 7.0.2 (released 6/11/2020), needs "Microsoft Windows Desktop Runtime 3.1.5 (x64)" which breaks out products again.

This is impacting in our effort to keep improving our products as our customers are suffering from these GA updates.

Is there going to be monthly GA updates?

:)

[joeyaiello]

@jemiller0 I totally get where you're coming from, but you have to understand that there are significant IT workflows already in place for Windows admins to keep software updated and their environments compliant. To that end, we're still working very hard in the 7.1 timeframe to integrate with the Microsoft Download Catalog so that we're integrated with SCCM, WSUS, and Microsoft Update workflows.

That being said, you should also check out winget. We already have a package there, and it works very much like apt. Eventually, we expect for winget to be more tightly integrated with the aforementioned IT workflows, but today it already works great as an interactive package install/update tool.

Similarly, you can use .NET Global Tools to keep PowerShell up-to-date if you're already keeping a .NET Core SDK up-to-date on your box.

@MaximoTrinidad I'm still not totally understanding that issue, as 3.1.3 and 3.1.5 should be backwards/forwards compatible....would you mind filing another issue?

[doctordns]

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.

:)

Totally agree Windows Update is a great answer for the Windows Platform. But the legal issues over minor things like support are likely to be major barriers in the short term. I am certain Microsoft's legal team can find a long term resolution that would allow Windows Update to be used. But Max, you and I have been around long enough to know the challenge here. :-) If there is any way we can do to support @joeyaiello over this??

As I said earlier, I'd like an Update-PowerShell command built into PowerShell 7. If that command can be made more cross-platform so much the better (but given the nature of Linux that is probably harder than it would be for Windows). We have Update-Help. Yes I agree there are, as is so typical in the PowerShell world, many ways to do this and I have my own hand crafted solutions.

I come back to the point that warnings should be easily actionable - just telling me I should update is less useful than giving me a simple solution (ie run UPdate-PowerShell).

And as for WInget - I am loath to use any tool that does not honour the sacred vow. Winget is just a powertoy for developers - call me when it's a serious IT Pro and Enterprise Management tool.

[tolgabalci]

I don't think which command / package-manager does the actual updating matters, but there should be something included in the default PowerShell install that updates to at least the latest minor version. It should also support the switches mentioned by @doctordns.

It should not have to be something like Winget that the user would then have to install yet another tool so that they can install the PowerShell update.

If we are going to have a nagger reminder to update, the reminder should give you the built-in command to run to update and get rid of the nag.

[BrandonBoone]

At a minimum, it would be nice if the upgrade notification made it clear that there is no built-in "Upgrade" feature and you have to go to the GitHub release page.

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

I saw this message thinking I should run some command and went searching for how to do this (that's how I found this issue). IMO, the ", or" makes this confusing.

Upgrade now by going to https://aka.ms/PowerShell-Release?tag=v7.0.3

or something similar would remove/reduce the confusion.

[smj0x]

use this work around mean while iex "& { $(irm https://aka.ms/install-powershell.ps1) } -UseMSI"

https://www.thomasmaurer.ch/2019/07/how-to-install-and-update-powershell-7/

Thomas Maurer

How to Install and Update PowerShell 7 - Thomas Maurer

This blog post covers how you can simply install or update PowerShell 7 with a single command line One-liner. Check it out right now!

[krokofant]

Having an autoinstaller that keeps the old settings would be nice. Now the right click to open feature is disabled via upgrades from choco. Using the install-powershell.ps1 seems a bit easier by specifying the option for each install/upgrade:

iex "& { $(irm https://aka.ms/install-powershell.ps1) } -UseMSI -AddExplorerContextMenu -Quiet"

[iSazonov]

@krokofant Please open new issue with repro steps.

[Yaron-Jack]

I saw this at a different website and It helped me-Cheers!

Update-Help -ErrorAction SilentlyContinue

[lauxjpn]

Hmm, getting the following message in PowerShell:

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

However, executing iex "& { $(irm https://aka.ms/install-powershell.ps1) } -UseMSI" still tries to install 7.1.0:

VERBOSE: About to download package from 'https://github.com/PowerShell/PowerShell/releases/download/v7.1.0/PowerShell-7.1.0-win-x64.msi'

A simple Update-PowerShell command that reliably works is long overdue.

[iSazonov]

@lauxjpn Please open new issue for your report.

[doctordns]

I think that the issue seen by @lauxjpn is a timing one. I saw similar issues in the past. I can duplicate the issue but can wait a day or two.

The joys of release management.

To assist, I have s short script that gets the GitHub metadata:

Function Get-PWSH7ReleaseInformation {
# Get details of overall PowerShell 7 information
  $FR = 'https://raw.githubusercontent.com/' +
  'PowerShell/PowerShell/master/tools/metadata.json'
  $MetaFullRelease   = Invoke-RestMethod $FR
# Get details of latest preview
  $MetaPreview       = Invoke-RestMethod 'https://aka.ms/pwsh-buildinfo-Preview'
# Get details of the latest daily build
  $MetadataDaily     = Invoke-RestMethod 'https://aka.ms/pwsh-buildinfo-daily'

# Display  this information
  'PowerShell 7 Status:'
  $MetaFullRelease
  'Preview information:'
  $MetaPreview
  'Daily Build information'
  $MetadataDaily
}
Get-PWSH7ReleaseInformation

If I run this script today, I see this:

PS C:\foo> .\get-PWSH7Info.ps1
PowerShell 7 Status:

StableReleaseTag    : v7.1.0
PreviewReleaseTag   : v7.2.0-preview.2
ServicingReleaseTag : v7.0.3
ReleaseTag          : v7.1.0
LTSReleaseTag       : {v7.0.3}
NextReleaseTag      : v7.2.0-preview.3
LTSRelease          : False

Preview information:
ReleaseDate : 2020-12-15T21:33:47Z
BlobName    : v7-2-0-preview-2
ReleaseTag  : v7.2.0-preview.2

Daily Build information
ReleaseDate : 15/01/2021 01:39:33
BlobName    : v7-2-0-daily-20210115
ReleaseTag  : v7.2.0-daily.20210115

My advice: be patient grasshopper.

[lauxjpn]

My advice: be patient grasshopper.

No, when the PowerShell notifies you of an available update, then all the ways to update PowerShell to the latest release need to already work.

I saw similar issues in the past.

In that case, this issue needs to be fixed, verified with tests and automated, so that it will not happen again in the future.

[taikulawo]

How to disable annoying A new PowerShell stable release is available: v7.1.1 Upgrade now showing again and again when I open terminal. I don't want to be forced to update :(

[iSazonov]

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

[markolbert]

use this work around mean while iex "& { $(irm https://aka.ms/install-powershell.ps1) } -UseMSI"

https://www.thomasmaurer.ch/2019/07/how-to-install-and-update-powershell-7/

Thomas MaurerHow to Install and Update PowerShell 7 - Thomas MaurerThis blog post covers how you can simply install or update PowerShell 7 with a single command line One-liner. Check it out right now!

Just did this -- twice -- and it doesn't work. Or rather, it completes with no errors...but I still get the helpful prompt "there's a new version" the next time I open a Terminal window. Even after rebooting.

Thomas Maurer

How to Install and Update PowerShell 7 - Thomas Maurer

This blog post covers how you can simply install or update PowerShell 7 with a single command line One-liner. Check it out right now!

[jdhitsolutions]

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.

[Viajaz]

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.

https://github.com/PowerShell/PowerShell/discussions/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,

[Luk164]

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

[XMuli]

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

[kilasuit]

@SteveL-MSFT / @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?

[doctordns]

I kind of disagree.

1. 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(.
2. 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.

[rkeithhill]

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

[fluffynuts]

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

[TravisEz13]

Marking as answered per this comment

[BrandonBoone]

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.

[ghost]

This issue has been marked as answered and has not had any activity for 1 day. It has been closed for housekeeping purposes.

[kilasuit]

@doctordns 1) 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. 2) 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.

[TravisEz13]

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

@BrandonBoone Please open another issue about the language/function of the update prompt.