How can I determine what version of PowerShell is installed on a computer, and indeed if it is installed at all?

1. How To Tell What Version Of Powershell
2. Latest Powershell Version
3. Powershell Version 6

Check PowerShell Version. Are you using the most current PowerShell version? If you don’t, you miss out on bug fixes and features, and maybe you cannot run all scripts. Let’s find out your PowerShell version. The release number of the PowerShell version can be found in many ways: Registry, Skripts and of course in PowerShell itself. Checking version of PowerShell (localhost) Open Windows PowerShell with administrative privileges. Run Get-Host with Select-Object. Get-Host Select-Object Version Simplified: (Get-Host).Version More simplified. Jul 18, 2016 - Thanks to several other sites for assistance but mostly.

MagicAndiMagicAndi

19 Answers

Use $PSVersionTable.PSVersion to determine the engine version. If the variable does not exist, it is safe to assume the engine is version 1.0.

Note that $Host.Version and (Get-Host).Version are not reliable - they reflectthe version of the host only, not the engine. PowerGUI,PowerShellPLUS, etc. are all hosting applications, andthey will set the host's version to reflect their productversion — which is entirely correct, but not what you're looking for.

I would use either Get-Host or $PSVersionTable. As Andy Schneider points out, $PSVersionTable doesn't work in version 1; it was introduced in version 2.

SimonThomas BrattThomas Bratt

You can look at the built in variable, $psversiontable. If it doesn't exist, you have V1. If it does exist, it will give you all the info you need.

SimonAndy SchneiderAndy Schneider

To determine if PowerShell is installed, you can check the registry for the existence of

and

and, if it exists, whether the value is 1 (for installed), as detailed in the blog post Check if PowerShell installed and version.

To determine the version of PowerShell that is installed, you can check the registry keys

and

To determine the version of PowerShell that is installed from a .ps1 script, you can use the following one-liner, as detailed on PowerShell.com in Which PowerShell Version Am I Running.

The same site also gives a function to return the version:

hichris123MagicAndiMagicAndi

Just want to add my 2 cents here.

You can directly check the version with one line only by invoking powershell externally, such as from Command Prompt

EDIT:

According to @psaul you can actually have one command that is agnostic from where it came (CMD, Powershell or Pwsh), thank you for that.

I've tested and it worked flawlessly on both CMD and Powershell

You can verify that Windows PowerShell version installed by completing the following check:

1. Click Start, click All Programs, click Accessories, click Windows PowerShell, and then click Windows PowerShell.

2. In the Windows PowerShell console, type the following command at the command prompt and then press ENTER:

You will see output that looks like this:

TylerHEclipsesEclipses

Microsoft's 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.

According to the linked page:

Depending on any other registry key(s), or version of PowerShell.exe or the location of PowerShell.exe is not guaranteed to work in the long term.

To check if any version of PowerShell is installed, check for the following value in the registry:

• Key Location: HKEY_LOCAL_MACHINESOFTWAREMicrosoftPowerShell1
• Value Name: Install
• Value Type: REG_DWORD
• Value Data: 0x00000001 (1

To check whether version 1.0 or 2.0 of PowerShell is installed, check for the following value in the registry:

• Key Location: HKEY_LOCAL_MACHINESOFTWAREMicrosoftPowerShell1PowerShellEngine
• Value Name: PowerShellVersion
• Value Type: REG_SZ
• Value Data: <1.0 2.0>

I found the easiest way to check if installed was to:

• run a command prompt (Start, Run, cmd, then OK)
• type powershell then hit return. You should then get the PowerShell PS prompt:

You can then check the version from the PowerShell prompt by typing $PSVersionTable.PSVersion:

Type exit if you want to go back to the command prompt (exit again if you want to also close the command prompt).

To run scripts, see http://ss64.com/ps/syntax-run.html.

SharpCSharpC

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

Peter Mortensenx0nx0n

Use:

You can download the detailed script from How to determine installed PowerShell version.

Peter Mortensen

To check if PowerShell is installed use:

To check if RC2 or RTM is installed use:

Source: this website.

Aliaksandr BelikDaniel ElliottDaniel Elliott

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

Test Powershell Version.cmd

or similar.

Peter MortensenPecos BillPecos Bill

The easiest way to forget this page and never return to it is to learn the Get-Variable:

There is no need to remember every variable. Just Get-Variable is enough (and 'There should be something about version').

Roman PokrovskijRoman Pokrovskij

The below cmdlet will return the PowerShell version.

Peter Mortensen

I needed to check the version of PS and then run the appropriate code. Some of our servers run v5, others v4. This means that some functions, like compress, may or may not be available.

This is my solution:

Atron SeigeAtron Seige

You can also call the 'host' command from the PowerShell commandline. It should give you the value of the $host variable.

Peter MortensenPeter MortensenHaBoHaBo

How To Tell What Version Of Powershell

This is the top search result for 'Batch file get powershell version', so I'd like to provide a basic example of how to do conditional flow in a batch file depending on the powershell version

generic example

real world example

So many answers here. I thought I'd put mine in here because it's fairly short, and says both the major and minor versions together.

protected by Bo PerssonJan 24 '12 at 17:38

Latest Powershell Version

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged powershell or ask your own question.

Back with the first few releases of Exchange, product updates were made available via service packs. This continued into the Exchange 2000 and Exchange 2003 days. It seems like an eternity ago, and dinosaurs were still roaming the Earth, when Exchange 2003 SP2 was released in October of 2005 as a whopping 109 MB download.

Exchange 2007 moved to a different servicing strategy which added a predictive scheduling element to the underlying Service Pack cycle so customers had a vehicle to receive fixes faster than wait for the next service pack. Exchange 2010 does the same. These updates that we speak of are the Update Rollups, Rollups, URs or RUs.

Update: 4-3-2015 Updated links to new home for Exchange build information.

One issue with this though is that Exchange 2007/2010 tools show the currently installed Service Pack version, as they did in Exchange 2003, and not what RU is currently installed. So when you look at the below screenshot of an Exchange 2010 organisation you can see that it is running SP2 as the build is 14.2 but you cannot state what RU is currently installed. If service pack 3 was installed then the build would start with14.3.

And the same information is mirrored in the GUI:

How can we find out what RU is currently installed?

The simplest way we can check it to look for installed updates in Add/Remove programs (or whatever it’s called nowadays)

Or by going help –> About in the Exchange Management Console.

Note that the Help –> About method does not give you a text based description of the installed RU, and a link to the relevant KB article. We need to use the techniques described below to map the build information to the released products.

Tom Kern originally addressed this back in 2010 with his post to the Exchange team blog. As with Exchange 2003 checking the version of key files is a great way to determine the current build of Exchange. As an added bonus this can be automated and scripted. Party on Wayne!

In its simplest form Tom demonstrates how to check the version of Exsetup.exe locally on a server:

GCM Exsetup.exe % {$_.FileVersionInfo}

Expanding this out, '”GCM” is an alias of Get-Command and “%” is an alias to ForEach-Object, which then retrieves the FileVersionInfo attribute of the file passed down the pipeline which is Exsetup.exe. So this could be written out fully as follows:

Get-Command Exsetup.exe ForEach-Object {$_.FileVersionInfo}

To prove they are aliases run Get-Alias GCM and review the output. You also may be thinking about the location of Exsetup.exe and why this is not specified in the above command. This is because Exchange setup adds the Exchange bin folder to the path environment variable. To check this out in PowerShell we can use:

Get-Item ENV:Path FL

Taking a sidebar, we can use the same technique to show the version information of all the .exe files in the C:Windows folder:

Dir C:Windows *.exe GCM % {$_.FileVersionInfo} FT -AutoSize

As Tom mentions, you then correlate the exsetup.exe version number you find with the released builds. Take a look at Exchange Server and Update Rollups Build Numbers on TechNet.

So looking at the Exsetup.exe version on a lab server:

We can see that version 14.2.309.2 is Exchange 2010 SP2 RU3.

We can now get a local server’s build, but what about remote machines and checking the entire organisation? Scripting to the rescue! As with most things scripting there are a few different ways to achieve the same result. Bhargav has a script on his blog to determine the build version information using remote registry and also Get-Content.

As an alternative, if you have WinRM Remoting enabled you can then use the Invoke-Command cmdlet to remotely access servers if they have the necessary build of WinRM, PowerShell and .Net Framework. Exchange 2010 servers already have the necessary components installed as the underlying prerequisites to install Exchange 2010 include NET Framework 3.51, PowerShell 2.0 and Windows Remote Management (WinRM) 2.0. These prerequisites can be installed easily by Exchange 2010 setup, using a feature introduced by Exchange 2010 SP1.

Sample code to illustrate getting the Exchange version using PowerShell remoting:

Update 5-11-2013: Updated ForEach loop

$ExchangeServers = Get-ExchangeServer Sort-Object Name

ForEach ($Server in $ExchangeServers)
{

Invoke-Command -ComputerName $Server.Name -ScriptBlock {Get-Command Exsetup.exe ForEach-Object {$_.FileversionInfo}}

}

Note that the Invoke-Command is a single line that may be displayed on multiple lines due to word wrapping.

One other thing that is good to discuss is a detail around ForEach and ForEach-Object. Be sure to avoid confusing the ForEach keyword with the ForEach-Object cmdlet. If that is done then the above code will fail to run and you will get this error:

Unexpected token 'in' in expression or statement

Back to Powershell remoting now!

Note that it did say *IF* you have WinRM Remoting enabled above. If this is not the case then you will likely see this lovely error which will no doubt brighten up your day!

Connecting to remote server failed with the following error message : The WinRM client cannot complete the operation within the time specified. Check if the machine name is valid and is reachable over the network and fire wall exception for Windows Remote Management service is enabled. For more information, see the about_Remote_Troubleshooting Help topic.
+ CategoryInfo : OpenError: (:) [], PSRemotingTransportException
+ FullyQualifiedErrorId : PSSessionStateBroken

To quickly check to see the configuration of WinRM:

Winrm enumerate winrm/config/listener

If enabled you should see something similar to this:

We are providing Milkshake Font here for free that includes free fonts, banana milkshake font, script font, fancy fonts, free sans-serif & typefaces. May 11, 2016 - Download and install the Milkshake free font family by Laura Worthington as well as test-drive and see a complete character set. Apr 11, 2019 - License: To know more about the font family, click here. Milkshake font download free. Free Font: Milkshake. By TheHungryJPEG in Fonts / Script. Additional Information. License: Complete License. File types: OTF,TTF. Apr 3, 2017 - We're talking about the Milkshake font that comes with a lot of extras. Each character comes with up to 8. Comes with a commercial license! Download it here: https://thehungryjpeg.com/freebie/61113-milkshake-free-font/thj/.

Listener
Address = *
Transport = HTTP
Port = 5985
Hostname
Enabled = true
URLPrefix = wsman
CertificateThumbprint
ListeningOn = 10.0.2.11, 127.0.0.1, 169.254.1.65, 192.168.2.11, ::1

If there is currently no listener, then use Enable-PSRemoting or the winrm quickconfig command.

Note that in WinRM 2.0 and newer the listener is created on port 5985 TCP for HTTP and HTTPS is port 5986 TCP. To Configure WINRM for HTTPS the winrm command can changed to:

winrm quickconfig -transport:https

To configure a HTTPS listener via PowerShell, specify the –UseSSL parameter on the Set-WSManQuickConfig cmdlet.

For more fun and games that you can have with PowerShell remoting, please see:

Chances are that you don’t fancy logging on to each server and running Enable-PSRemoting. If that does excite you, then you need help! For the others who want to save time and ensure a consistent management strategy is applied to all of their servers then we can enable and configure PowerShell remoting using Group Policy.

Leaving on a happy thought, this issue is resolved in Exchange 2013. When Cumulative Updates (CUs) are installed on an Exchange 2013 server the version information displayed will be updated to reflect the update.

The Exchange 2013 build numbers are also documented on the TechNet wiki.

Cheers,

Rhoderick

Powershell Version 6

>>>