Powershell Download Version 7

[Alexia Borson]

Microsofts recommended forward compatible method for checking if PowerShell is installed and determining the installed version is to look at two specific registry keys. I've reproduced the details here in case the link breaks.

Beginning in PowerShell 7.1, the [installer] package creates registry keysthat store the installation location and version of PowerShell. Thesevalues are located inHKLM\Software\Microsoft\PowerShellCore\InstalledVersions\. Thevalue of is unique for each build type (release or preview),major version, and architecture.

The PowerShell cmdlet used to query the data in this registry value is the Get-ItemPropertyValue cmdlet. Observe its use and output as follows (note the asterisk wildcard character used in place of the part of the key path that is likely to change):

$host.version is just plain wrong/unreliable. This gives you the version of the hosting executable (powershell.exe, powergui.exe, powershell_ise.exe, powershellplus.exe etc) and not the version of the engine itself.

The engine version is contained in $psversiontable.psversion. For PowerShell 1.0, this variable does not exist, so obviously if this variable is not available it is entirely safe to assume the engine is 1.0, obviously.

Since the most helpful answer didn't address the if exists portion, I thought I'd give one take on it via a quick-and-dirty solution. It relies on PowerShell being in the path environment variable which is likely what you want. (Hat tip to the top answer as I didn't know that.) Paste this into a text file and name it

Very old question but still relevant, it's just that the nature of the problem is different now in 2023. Finding the version is easy, but first we have to launch the right executable. For that, we're basically back to looking in the registry.

When the line with the version is found, it uses the for command to extract the version. In this case we are saying that the delimiter is a colon and search next the first colon, resulting in my case 5.1.18362.752.

The installation commands in this article are for the latest stable release of PowerShell. Toinstall a different version of PowerShell, adjust the command to match the version you need. Thefollowing links direct you to the release page for each version in the PowerShell repository onGitHub.

Winget, the Windows Package Manager, is a command-line tool enables users to discover, install,upgrade, remove, and configure applications on Windows client computers. This tool is the clientinterface to the Windows Package Manager service. The winget command-line tool is bundled withWindows 11 and modern versions of Windows 10 by default as the App Installer.

Windows Server 2025 Preview Build 26085 and later includes winget for Windows Server withDesktop Experience only. For more information, seeAnnouncing Windows Server Preview Build 26085.

On Windows systems using X86 or X64 processor, winget installs the MSI package. On systems usingthe Arm64 processor, winget installs the Microsoft Store (MSIX) package. For more information,see Installing from the Microsoft Store.

PowerShell 7.4 installs to a new directory and runs side-by-side with Windows PowerShell 5.1.PowerShell 7.4 is an in-place upgrade that removes previous versions of PowerShell 7. Previewversions of PowerShell can be installed side-by-side with other versions of PowerShell.

PowerShell 7.2 and newer has support for Microsoft Update. When you enable this feature, you'll getthe latest PowerShell 7 updates in your traditional Microsoft Update (MU) management flow, whetherthat's with Windows Update for Business, WSUS, Microsoft Endpoint Configuration Manager, or theinteractive MU dialog in Settings.

Enabling updates may have been set in a previous installation or manual configuration. UsingENABLE_MU=0 doesn't remove the existing settings. Also, this setting can be overruled by GroupPolicy settings controlled by your administrator.

MSI packages can be installed from the command line allowing administrators to deploy packageswithout user interaction. The MSI package includes the following properties to control theinstallation options:

Depending on how you download the file you may need to unblock the file using the Unblock-Filecmdlet. Unzip the contents to the location of your choice and run pwsh.exe from there. Unlikeinstalling the MSI packages, installing the ZIP archive doesn't check for prerequisites. Forremoting over WSMan to work properly, ensure that you've met the prerequisites.

The dotnet tool installer adds $HOME\.dotnet\tools to your $env:PATH environment variable.However, the currently running shell doesn't have the updated $env:PATH. You can start PowerShellfrom a new shell by typing pwsh.

By default, Windows Store packages run in an application sandbox that virtualizes access to somefilesystem and registry locations. Changes to virtualized file and registry locations don't persistoutside of the application sandbox.

This sandbox blocks all changes to the application's root folder. Any system-level configurationsettings stored in $PSHOME can't be modified. This includes the WSMAN configuration. This preventsremote sessions from connecting to Store-based installs of PowerShell. User-level configurations andSSH remoting are supported.

Beginning in PowerShell 7.2, the PowerShell package is now exempt from file and registryvirtualization. Changes to virtualized file and registry locations now persist outside of theapplication sandbox. However, changes to the application's root folder are still blocked.

For best results when upgrading, you should use the same install method you used when you firstinstalled PowerShell. If you aren't sure how PowerShell was installed, you can check the value ofthe $PSHOME variable, which always points to the directory containing PowerShell that the currentsession is running.

When upgrading, PowerShell won't upgrade from an LTS version to a non-LTS version. It onlyupgrades to the latest version of LTS, for example, from 7.2.3 to 7.2.22. To upgrade from anLTS release to a newer stable version or the next LTS, you need to install the new version withthe MSI for that release.

Windows 10 IoT Core adds Windows PowerShell when you include IOT_POWERSHELL feature, which we canuse to deploy PowerShell 7. The steps defined above for Windows 10 IoT Enterprise can be followedfor IoT Core as well.

Microsoft supports the installation methods in this document. There may be other third-party methodsof installation available from other sources. While those tools and methods may work, Microsoftcan't support those methods.

The first thing to do when getting ready to install anything is to run Windows Update. I go to Control Panel/Security and run Windows Update (after using Windows 8 for so long, this seems a bit strange). I am lucky the old laptop is basically up-to-date, and it only needs to install a single update as shown here.

When I am finished running Windows Update, I reboot the computer (even if it does not specifically request a reboot) because often laptops hibernate (or sleep0, and they go for weeks without a proper reboot.

Windows PowerShell 3.0 requires.NET Framework 4.0. If I do not install it first, and I try to install Windows PowerShell 3.0 without.NET Framework 4.0, a rather generic error appears: This update does not apply to your system. It is safest to install .NET Framework 4.0.

The easiest way to find the Windows PowerShell 3.0 download package is to access it directly from the Microsoft TechNet Script Center. I have a link to Windows PowerShell 3.0 under the Downloads section as shown in the following screenshot.

In determining which version of the package to download, I also need to know the version of computer I have (for example, is it 64-bit or x86). I get this information from Windows PowerShell. The command I use is:

After I know the version of the download package to obtain, I click the big red download button, and I am presented with a check box to select the version. I do this, click Next, and then tell it to run (rather than download and Save).

When the installation completes, it requests a reboot. Following the reboot, Windows does a bit of configuration that will take a couple of minutes. The following screen displays during the configuration.

Following the reboot, I sign in, and I want to immediately see if it worked. The first thing I do is open the Windows PowerShell console and type $psversiontable. The following data returns:

Well, the Scripting Guys booth looks cool, and I think it is time to head to the French Quarter and catch up with some PowerShell Tweeps. TechEd kicks off tomorrow bright and early, and it will be awesome! Hope to see you there.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scri...@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

When I install Powershell Engine 2.0 I was expecting a new .exe to show up somewhere or the current .exe located at C:\Windows\System32\WindowsPowerShell\v1.0 to at least change versions or any sort of new file to show up. This way I can take a hash of the file and use the only tool at my disposal to search hundreds of servers for that exact hash to determine what systems have Powershell 2.0 installed. It sounds like installing the Powershell Engine 2.0 does not change much in the file system, if anything, therefore this approach will not work for me. For instance, I have used this approach to take a hash of Sysmon64.exe file version X to locate all servers with version X so I could upgrade them to version Y. My tool can search for specific files or hashes. Either will work if I know what I am looking for on a system with PS 2.0 installed. Thanks for your reply.

I'm a PowerShell fan and have recently adopted PowerShell Core as my version of choice. If you are not familiar with PowerShell Core, it is a cross platform (Windows, Linux, and macOS) version of PowerShell based on .NET Core. That said, I sometimes need to work in PowerShell for Windows or use both side by side.

3a8082e126