How to get Windows Remote Management (WinRM) version? - powershell

PowerShell 4.0.
From the get-help about_Remote_Requirements:
To run remote sessions on Windows PowerShell 3.0, the local and remote
computers
must have the following:
-- Windows PowerShell 3.0 or later
-- The Microsoft .NET Framework 4.0 or later
-- Windows Remote Management 3.0
How can I get the Windows Remote Management (WinRM) version? I don't see this info in the output of the $PSVersionTable variable:
UPD
The winrm id result:

If WinRM is Running:
`winrm id' Check the Stack Version
If WinRM is Not Running, check the Version number for %Windir%\System32\wsmsvc.dll
(Get-Item C:\Windows\System32\wsmsvc.dll).VersionInfo.FileVersion
Or: $PSVersionTable.BuildVersion.ToString() (Has the same result)
if it can help you, This will work until version 2
Function Get-WinRMVersion
{
$WinRM = ((Get-Item C:\Windows\System32\wsmsvc.dll).VersionInfo.FileVersion -Split '\s')[0]
Switch -Wildcard ($WinRM)
{
"5.2.3790.2075" {0.5}
"6.0.6000.16386" {1.0}
"5.1.2600.3191" {1.1}
"5.2.3790.2990" {1.1}
"5.2.3790.4131" {1.1}
"6.0.6001.18000" {2.0}
"6.1.7600.16385" {2.0}
"6.2.*" {return "Greater then v2"}
}
}

Related

how to get winrm to use powershell 7 for remote sessions by default

With the release of powershell 7, seems like it is time to move past ps 5.1 so I have installed in on a couple of servers to give it a go.
However I when I create a session to these servers from my pc with ps7 I am always running ps5.1 on the remote machine.
Invoke-Command -ComputerName name -ScriptBlock {
Write-Host $env:COMPUTERNAME
$PSVersionTable.PsVersion
}
Which outputs 5.1.17763.316. Any ideas how to get the remote session to use version 7.0.0 preferably by default?
Update
making some progress with this, so though I would share.
On the remote machine in powershell 7 run the following command
Enable-PSRemoting
This will create some PsSessionConfigurations which you can see with the following command..
Get-PSSessionConfiguration
Now you can do the following to create sessions from powershell 7
Invoke-Command -ComputerName ServerName -ScriptBlock { $PsVersionTable.PSVersion } -ConfigurationName Powershell.7
$session = New-PSSession ServerName -ConfigurationName Powershell.7
Invoke-Command -Session $session -ScriptBlock { $PsVersionTable.PSVersion }
This now uses ps 7 on the remote session, happy days. Now how to make this happen by default...? From this github issue :
set the default microsoft.powershell endpoint to any PowerShell they
choose
Which I think is what I want to do so switched back to ps 5.1 and tried this command:
Get-PSSessionConfiguration -Name microsoft.powershell | Set-PSSessionConfiguration -PSVersion 7.0
Only to get the following output:
Set-PSSessionConfiguration : Cannot bind parameter 'PSVersion' to the
target. Exception setting "PSVersion": "The value 7.0 is not valid for
the PSVersion parameter. The available values are 2.0, 3.0, 4.0, 5.0,
5.1."
though I would try this in ps7 so switched back by running pwsh and ran the same command again to get he following...
Write-Error: No session configuration matches criteria
"microsoft.powershell".
So still not quite sure how to make ps7 the default... :(
Note:
It is the remoting client that determines what remoting endpoint (session configuration) to connect to on the server machine - see below.
Therefore, your own attempt,
# WRONG
Get-PSSessionConfiguration -Name microsoft.powershell |
Set-PSSessionConfiguration -PSVersion 7.0
is ineffective, because Set-PSSessionConfiguration modifies endpoint configurations on the server machine, it doesn't control the client's behavior.
Note that the fundamental prerequisite is that PowerShell remoting must be enabled on the server machine, which can be achieved either by opting to do so during installation via the MSI GUI installer, or by running Enable-PSRemoting - with admin privileges - later.Tip of the hat to Lars Fosdal.
Doing so from PowerShell (Core) creates the standard session configuration(s) named PowerShell.<version> that clients can opt to connect to - see below.
To list all configurations defined on a server, run Get-PSSessionConfiguration with admin privileges.
On a client machine, you can set a default for what session configuration defined on the server (remote machine) to connect to, via the $PSSessionConfigurationName preference variable.
E.g., to target PowerShell 7 by default:
# When remoting, default to running PowerShell Core v7.x on the
# the target machines:
$PSSessionConfigurationName = 'PowerShell.7'
If you add the above to your $PROFILE file, future sessions will target PowerShell 7 by default.
See this answer for more information, which also shows how to target a given server configuration in the context of individual commands.
Note: Changing what endpoint PowerShell [Core] targets by default - which as of 7.2 is still Window PowerShell - is being considered: see GitHub issue #11616.

How to get Log On As account for Windows Service via PowerShell

New to powershell and I'm guessing this exists but I cannot find. I am looking for a powershell command that will show me the account being used to run a Windows Service? I am first as going to check it is running, then make sure it is running using the correct AD account. I have the following so far...
$serviceName = '<my service name>'
If (Get-Service $serviceName -ErrorAction SilentlyContinue) {
If ((Get-Service $serviceName).Status -eq 'Running') {
$status = "$serviceName found and is running."
} Else {
$status = "$serviceName found, but it is not running."
}
#Here is where I should check Log On As name
} Else {
$status = "$serviceName not found."
}
write-host "Status: $status`n"
pause
Most of my searches lead me to Get-WmiObject, but I did not find what I was looking for. Thanks in advance for any help.
(Get-WmiObject Win32_Service -Filter "Name='$serviceName'").StartName. (Yes, the name of this property is rather counter-intuitive, but the docs don't lie).
You could also use the more recent CIM cmdlets. Which is which is really where MS wants and is directing folsk to use.
Get-CimInstance -ClassName CIM_Service | Select-Object Name, StartMode, StartName
What is CIM and Why Should I Use It in PowerShell?
https://blogs.technet.microsoft.com/heyscriptingguy/2014/01/27/what-is-cim-and-why-should-i-use-it-in-powershell
Update for WMI
In Windows PowerShell 4.0 and Windows PowerShell 3.0, Microsoft offered an updated method for interacting with WMI: the CIMCmdlets module for Windows PowerShell. With this new Windows PowerShell module release, Microsoft also released an entirely new Application Programming Interface (API) for Windows called Management Infrastructure (MI).
The new MI API more closely aligns to the DMTF standards, as laid out on MSDN in Why Use MI? MI allows software developers and hardware manufacturers to expose information, and it allows IT professionals to interact with hardware, using standards-based mechanisms. As this technology continues to evolve, I believe that we will see more cross-platform integration between Microsoft Windows and competing platforms.
Should I use CIM or WMI with Windows PowerShell?
https://blogs.technet.microsoft.com/heyscriptingguy/2016/02/08/should-i-use-cim-or-wmi-with-windows-powershell
Get-WmiObject is one of the original PowerShell cmdlets. (As a quick quiz, how many of the 137 original cmdlets can you name?). It was enhanced in PowerShell 2.0 when the other WMI cmdlets were introduced. In PowerShell 1.0, Get-WmiObject was the only cmdlet with the option to access another system.
The big drawback to the WMI cmdlets is that they use DCOM to access remote machines. DCOM isn’t firewall friendly, can be blocked by networking equipment, and gives some arcane errors when things go wrong.
The CIM cmdlets appeared in PowerShell 3.0 as part of the new API for working with CIM classes, which is more standards based. The CIM cmdlets were overshadowed by PowerShell workflows, but they are (to my mind) the most important thing to come out of that release.
The other major CIM-related advance was the introduction of CDXML, which enables a CIM class to be wrapped in some simple XML and published as a PowerShell module. This is how over 60% of the cmdlets in Windows 8 and later are produced.
With Powershell 7, you can retrieve the logon as user like this:
(Get-Service $serviceName).username

Active Directory Module

I have written a PowerShell script, an application that allow PC Refresh to set Company, DepartmentNumber, etc. on an AD object. In development everthing works fine. Obviously I have AD installed on my machine. I have compiled my app to a .exe and placed it on a network share where the techs will execute it from there as they start up a new computer or refresh from Windows 7 to Windows 10 mostly.
The problem is the new PC will not have Active Directory installed at this point in time. I need to find a way to have my app intall, import and run Active Directory as on start up of new or refreshed computers. How do I accomplish this?
Below is some relevant code I use to import the module if it exist on the machine.
$RestoreForm_Load = {
# Load the ActiveDirectory module if it's available
# Check if the ActiveDirectory module is installed
if ((Get-Module -ListAvailable | where { $_.Name -eq 'ActiveDirectory' }) -eq $null) {
$labelDialogRedRestore.Text += "You need to install the ActiveDirectory module!`n"
} else {
# Check if the ActiveDirectory module is allready Imported
if ((Get-Module ActiveDirectory) -eq $null) {
Import-Module ActiveDirectory -ErrorAction 'SilentlyContinue'
$labelDialogGreenRestore.Text += "ActiveDirectory module imported`n"
} else {
$labelDialogGreenRestore.Text += "ActiveDirectory allready imported`n"
}
}
Only the Windows Server versions have the AD module, or any other part of the RSAT (Remote Server Administration Tools) for that matter, available for installation out of the box. You can use Add-WindowsFeature (or Install-WindowsFeature, which replaced the former in Windows 2012 and newer) to install the module on a server:
Import-Module ServerManager
$os = (Get-WmiObject Win32_OperatingSystem).Caption
switch -wildcard ($os) {
'Windwos Server 2008*' {
Add-WindowsFeature RSAT-AD-PowerShell -IncludeAllSubFeatures
}
'Windows Server 2012*' {
Install-WindowsFeature RSAT-AD-PowerShell -IncludeAllSubFeatures
}
}
Windows client versions don't come with the RSAT. You need to install the correct RSAT package first before you can install the AD PowerShell cmdlets. The link list in the KB article is a little outdated, though. The link for the Windows 10 Preview RSAT package doesn't work anymore. Here is the download link for the release version.
Once you have installed the update on the clients, you can install the module for instance via dism:
dism /Online /Enable-Feature /FeatureName:RemoteServerAdministrationTools-Roles-AD-Powershell
Note that (at least on the client versions) the feature name may differ between versions (the feature is named RemoteServerAdministrationTools-Roles-AD-Powershell in the Windows 7 RSAT, but RSATClient-Roles-AD-Powershell in the Windows 10 RSAT), so you may need to use a switch statement on the clients as well:
$os = (Get-WmiObject Win32_OperatingSystem).Caption
$name = switch -wildcard ($os) {
'Windows 7*' { 'RemoteServerAdministrationTools-Roles-AD-Powershell' }
'Windows 8*' { '???' }
'Windows 10*' { 'RSATClient-Roles-AD-Powershell' }
}
& dism /Online /Enable-Feature /FeatureName:$name
Also, beware that regardless of which system you're installing the module on (server or client) you must have .NET framework 3.5.1 or 4.5 installed, otherwise the module won't work (if you can even install it in the first place).
You could install the module in your script with the following command:
Add-WindowsFeature RSAT-AD-PowerShell
Note that this feature requires the .NET Framework 3.5.1 feature too which can be installed with the following command:
Add-WindowsFeature net-framework-core
While you can install Active Directory on these machines just to run your code, I'd suggest setting up a session to a computer that already has it installed instead. If the Techs are hands on and have credentials to access AD then this will work better.
$Session = New-PSSession -ComputerName DC -Credential (Get-Credential) -Name AD
Enter-PSSession -Session $Session
Import-Module ActiveDirectory
Doing-AD -Stuff
...
Disconnect-PSSession
With this approach, the Tech will be prompted for their credentials, the script will run your AD stuff, and the client machine won't have RSAT tools enabled or installed.

Get status of service on a remote server

I need to find the status of a service on a remote computer. Though I can use the following command:
Write-Host (Get-Service -ComputerName "remoteServerName" -Name "serviceName").Status
which would give me correct status of service. However I have PowerShell 1.0 installed on the server where i need to run this script. -ComputerName parameter doesn't work for PowerShell 1.0. Currently I'm not supposed to install higher version of PowerShell.
Any idea how to get the status of a service in PowerShell 1.0?
First and foremost (and I can't stress this point enough): If the operating system supports it you should upgrade to at least PowerShell v2.0. No exception. If the system doesn't support PowerShell 2 or newer it's already out of support and should have been replaced/upgraded months ago.
With that said, you can use either WMI (as suggested by #vonPryz):
Get-WmiObject -Computer 'remoteServerName' -Class Win32_Service -Filter "DisplayName='ServiceName'"
or sc.exe (as suggested by #Kayasax):
& sc.exe \\remoteServerName query 'ServiceName'
Of these two WMI is the more PoSh approach, as it doesn't require parsing text output.

Determine installed PowerShell version

How can I determine what version of PowerShell is installed on a computer, and indeed if it is installed at all?
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 reflect
the version of the host only, not the engine. PowerGUI,
PowerShellPLUS, etc. are all hosting applications, and
they will set the host's version to reflect their product
version — which is entirely correct, but not what you're looking for.
PS C:\> $PSVersionTable.PSVersion
Major Minor Build Revision
----- ----- ----- --------
4 0 -1 -1
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.
get-host
Name : ConsoleHost
Version : 2.0
InstanceId : d730016e-2875-4b57-9cd6-d32c8b71e18a
UI : System.Management.Automation.Internal.Host.InternalHostUserInterface
CurrentCulture : en-GB
CurrentUICulture : en-US
PrivateData : Microsoft.PowerShell.ConsoleHost+ConsoleColorProxy
IsRunspacePushed : False
Runspace : System.Management.Automation.Runspaces.LocalRunspace
$PSVersionTable
Name Value
---- -----
CLRVersion 2.0.50727.4200
BuildVersion 6.0.6002.18111
PSVersion 2.0
WSManStackVersion 2.0
PSCompatibleVersions {1.0, 2.0}
SerializationVersion 1.1.0.1
PSRemotingProtocolVersion 2.1
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.
1 > $psversiontable
Name Value
---- -----
CLRVersion 2.0.50727.4927
BuildVersion 6.1.7600.16385
PSVersion 2.0
WSManStackVersion 2.0
PSCompatibleVersions {1.0, 2.0}
SerializationVersion 1.1.0.1
PSRemotingProtocolVersion 2.1
To determine if PowerShell is installed, you can check the registry for the existence of
HKEY_LOCAL_MACHINE\Software\Microsoft\PowerShell\1\Install
and
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\3
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
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\PowerShellEngine\PowerShellVersion
and
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\3\PowerShellEngine\PowerShellVersion
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.
$isV2 = test-path variable:\psversiontable
The same site also gives a function to return the version:
function Get-PSVersion {
if (test-path variable:psversiontable) {$psversiontable.psversion} else {[version]"1.0.0.0"}
}
You can directly check the version with one line only by invoking PowerShell externally, such as from Command Prompt
powershell -Command "$PSVersionTable.PSVersion"
According to #psaul you can actually have one command that is agnostic from where it came (CMD, PowerShell or Pwsh). Thank you for that.
powershell -command "(Get-Variable PSVersionTable -ValueOnly).PSVersion"
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:
Click Start, click All Programs, click Accessories, click Windows PowerShell, and then click Windows PowerShell.
In the Windows PowerShell console, type the following command at the command prompt and then press ENTER:
Get-Host | Select-Object Version
You will see output that looks like this:
Version
-------
3.0
http://www.myerrorsandmysolutions.com/how-to-verify-the-windows-powershell-version-installed/
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_MACHINE\SOFTWARE\Microsoft\PowerShell\1
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_MACHINE\SOFTWARE\Microsoft\PowerShell\1\PowerShellEngine
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:
C:\Users\MyUser>powershell
Windows PowerShell
Copyright (C) 2009 Microsoft Corporation. All rights reserved.
PS C:\Users\MyUser>
You can then check the version from the PowerShell prompt by typing $PSVersionTable.PSVersion:
PS C:\Users\MyUser> $PSVersionTable.PSVersion
Major Minor Build Revision
----- ----- ----- --------
2 0 -1 -1
PS C:\Users\MyUser>
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.
$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.
The easiest way to forget this page and never return to it is to learn the Get-Variable:
Get-Variable | where {$_.Name -Like '*version*'} | %{$_[0].Value}
There is no need to remember every variable. Just Get-Variable is enough (and "There should be something about version").
Use:
$psVersion = $PSVersionTable.PSVersion
If ($psVersion)
{
#PowerShell Version Mapping
$psVersionMappings = #()
$psVersionMappings += New-Object PSObject -Property #{Name='5.1.14393.0';FriendlyName='Windows PowerShell 5.1 Preview';ApplicableOS='Windows 10 Anniversary Update'}
$psVersionMappings += New-Object PSObject -Property #{Name='5.1.14300.1000';FriendlyName='Windows PowerShell 5.1 Preview';ApplicableOS='Windows Server 2016 Technical Preview 5'}
$psVersionMappings += New-Object PSObject -Property #{Name='5.0.10586.494';FriendlyName='Windows PowerShell 5 RTM';ApplicableOS='Windows 10 1511 + KB3172985 1607'}
$psVersionMappings += New-Object PSObject -Property #{Name='5.0.10586.122';FriendlyName='Windows PowerShell 5 RTM';ApplicableOS='Windows 10 1511 + KB3140743 1603'}
$psVersionMappings += New-Object PSObject -Property #{Name='5.0.10586.117';FriendlyName='Windows PowerShell 5 RTM 1602';ApplicableOS='Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2 SP1, Windows 8.1, and Windows 7 SP1'}
$psVersionMappings += New-Object PSObject -Property #{Name='5.0.10586.63';FriendlyName='Windows PowerShell 5 RTM';ApplicableOS='Windows 10 1511 + KB3135173 1602'}
$psVersionMappings += New-Object PSObject -Property #{Name='5.0.10586.51';FriendlyName='Windows PowerShell 5 RTM 1512';ApplicableOS='Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2 SP1, Windows 8.1, and Windows 7 SP1'}
$psVersionMappings += New-Object PSObject -Property #{Name='5.0.10514.6';FriendlyName='Windows PowerShell 5 Production Preview 1508';ApplicableOS='Windows Server 2012 R2'}
$psVersionMappings += New-Object PSObject -Property #{Name='5.0.10018.0';FriendlyName='Windows PowerShell 5 Preview 1502';ApplicableOS='Windows Server 2012 R2'}
$psVersionMappings += New-Object PSObject -Property #{Name='5.0.9883.0';FriendlyName='Windows PowerShell 5 Preview November 2014';ApplicableOS='Windows Server 2012 R2, Windows Server 2012, Windows 8.1'}
$psVersionMappings += New-Object PSObject -Property #{Name='4.0';FriendlyName='Windows PowerShell 4 RTM';ApplicableOS='Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2 SP1, Windows 8.1, and Windows 7 SP1'}
$psVersionMappings += New-Object PSObject -Property #{Name='3.0';FriendlyName='Windows PowerShell 3 RTM';ApplicableOS='Windows Server 2012, Windows Server 2008 R2 SP1, Windows 8, and Windows 7 SP1'}
$psVersionMappings += New-Object PSObject -Property #{Name='2.0';FriendlyName='Windows PowerShell 2 RTM';ApplicableOS='Windows Server 2008 R2 SP1 and Windows 7'}
foreach ($psVersionMapping in $psVersionMappings)
{
If ($psVersion -ge $psVersionMapping.Name) {
#{CurrentVersion=$psVersion;FriendlyName=$psVersionMapping.FriendlyName;ApplicableOS=$psVersionMapping.ApplicableOS}
Break
}
}
}
Else{
#{CurrentVersion='1.0';FriendlyName='Windows PowerShell 1 RTM';ApplicableOS='Windows Server 2008, Windows Server 2003, Windows Vista, Windows XP'}
}
You can download the detailed script from How to determine installed PowerShell version.
PowerShell 7
The accepted answer is only appropriate if one version of PowerShell is installed on a computer. With the advent of PowerShell 7, this scenario becomes increasingly unlikely.
Microsoft's documentation states that additional registry keys are created when PowerShell 7 is installed:
Beginning in PowerShell 7.1, the [installer] package creates registry keys
that store the installation location and version of PowerShell. These
values are located in
HKLM\Software\Microsoft\PowerShellCore\InstalledVersions\<GUID>. The
value of <GUID> is unique for each build type (release or preview),
major version, and architecture.
Exploring the registry in the aforementioned location reveals the following registry value: SemanticVersion. This value contains the information we seek.
On my computer it appears like the following:
Path Name Type Data
---- ---- ---- ----
HKLM:\SOFTWARE\Microsoft\PowerShellCore\InstalledVersions\31ab5147-9a97-4452-8443-d9709f0516e1 SemanticVersion String 7.1.3
As you can see, the version of PowerShell 7 installed on my computer is 7.1.3. If PowerShell 7 is not installed on the target computer, the key in its entirety should not exist.
As mentioned in the Microsoft documentation, the registry path will be slightly different dependent on installed PowerShell version.
Part of the key path changing could pose a challenge in some scenarios, but for those interested in a command line-based solution, PowerShell itself can handle this problem easily.
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):
PS> Get-ItemPropertyValue -Path "HKLM:\SOFTWARE\Microsoft\PowerShellCore\InstalledVersions\*" -Name "SemanticVersion"
7.1.3
Just a simple one-liner.
To check if PowerShell is installed use:
HKLM\Software\Microsoft\PowerShell\1 Install ( = 1 )
To check if RC2 or RTM is installed use:
HKLM\Software\Microsoft\PowerShell\1 PID (=89393-100-0001260-00301) -- For RC2
HKLM\Software\Microsoft\PowerShell\1 PID (=89393-100-0001260-04309) -- For RTM
Source: this website.
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.
#echo off
echo Checking powershell version...
del "%temp%\PSVers.txt" 2>nul
powershell -command "[string]$PSVersionTable.PSVersion.Major +'.'+ [string]$PSVersionTable.PSVersion.Minor | Out-File ([string](cat env:\temp) + '\PSVers.txt')" 2>nul
if errorlevel 1 (
echo Powershell is not installed. Please install it from download.Microsoft.com; thanks.
) else (
echo You have installed Powershell version:
type "%temp%\PSVers.txt"
del "%temp%\PSVers.txt" 2>nul
)
timeout 15
I needed to check the version of PowerShell and then run the appropriate code. Some of our servers run v5, and others v4. This means that some functions, like compress, may or may not be available.
This is my solution:
if ($PSVersionTable.PSVersion.Major -eq 5) {
#Execute code available in PowerShell 5, like Compress
Write-Host "You are running PowerShell version 5"
}
else {
#Use a different process
Write-Host "This is version $PSVersionTable.PSVersion.Major"
}
The below cmdlet will return the PowerShell version.
$PSVersionTable.PSVersion.Major
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
powershell "exit $PSVersionTable.PSVersion.Major"
if %errorlevel% GEQ 5 (
echo Do some fancy stuff that only powershell v5 or higher supports
) else (
echo Functionality not support by current powershell version.
)
Real world example
powershell "exit $PSVersionTable.PSVersion.Major"
if %errorlevel% GEQ 5 (
rem Unzip archive automatically
powershell Expand-Archive Compressed.zip
) else (
rem Make the user unzip, because lazy
echo Please unzip Compressed.zip prior to continuing...
pause
)
I tried this on version 7.1.0 and it worked:
$PSVersionTable | Select-Object PSVersion
Output
PSVersion
---------
7.1.0
It doesn't work on version 5.1 though, so rather go for this on versions below 7:
$PSVersionTable.PSVersion
Output
Major Minor Build Revision
----- ----- ----- --------
5 1 18362 1171
EDIT
As of PowerShell 7.2.5, you can now do:
pwsh -v
Or
pwsh --version
Output
PowerShell 7.2.5
You can also call the "host" command from the PowerShell commandline. It should give you the value of the $host variable.
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.
reg query "HKLM\SOFTWARE\Microsoft\PowerShell\1" /v Install >nul 2>&1
if %ERRORLEVEL% EQU 0 (
:: Default to PowerShell 5 if both are installed
set PSEXE=powershell
) else (
set PSEXE=pwsh
)
echo Using %PSEXE%
%PSEXE% -ExecutionPolicy bypass -command "& { ... ; exit $LASTEXITCODE }"
There are other hints you can get by inspecting environment variables, but I think testing the registry for 'Windows' PowerShell is the safest.
Extending the answer with a select operator:
Get-Host | select {$_.Version}
I have made a small batch script that can determine PowerShell version:
#echo off
for /f "tokens=2 delims=:" %%a in ('powershell -Command Get-Host ^| findstr /c:Version') do (echo %%a)
This simply extracts the version of PowerShell using Get-Host and searches the string Version
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.