I was making a PowerShell script in Visual Studio Code that used the command Get-PSDrive, and to my surprise, it seemed like while using VS Code, a new drive identical to my C:\ drive called Temp appeared.
I was taken aback by this result as as far as I knew, I only had 2 other drives besides my main C:\ drive connected. I tried to replicate this on other terminals with no success except for PowerShell 7:
Windows Terminal PowerShell 5.1
PowerShell 5.1
PowerShell 5.1 (86x)
PowerShell 7 (86x)
Windows Terminal PowerShell 7
As I saw that it was replicated by PwSh 7, I decided to check the versions of each of the PowerShells with the $host variable and I saw something even more unexpected:
Version : 5.1.19041.1
Windows Terminal PowerShell 5.1
Version : 5.1.19041.1
PowerShell 5.1
Version : 5.1.19041.1
PowerShell 5.1 (86x)
Version : 7.0.2
PowerShell 7 (86x)
Version : 7.0.2
Windows Terminal PowerShell 7
which all seemed normal, but when I checked the VSCode $host, I got the result
Version : 2020.6.0
What is causing the differences in the outputs of
Get-PSDrive | Where-Object {$_.Provider.Name -eq "FileSystem"}
between PwSh 7, PowerShell 5.1, and VS Code PwSh?
That Temp: drive is not "a new drive identical to my C:\ drive"; its Root is $Env:Temp, not C:\.
According to PowerShell Team May 2020 Update, which actually describes PowerShell 7.1, this was added in PowerShell 7.0...
In PowerShell 7.0, we added a temp: PSDrive. This works on all platforms and automatically maps to your user temporary path.
By the way, the command you used to make those screenshots could be simplified to Get-PSDrive -PSProvider FileSystem.
Am I right in thinking that some of the newer Powershell commands related to the management of scheduled tasks (such as New-ScheduledTaskAction) are not available on Windows 7 or Server 2008 R2, even if Powershell 4 is installed?
Yes you right, some PowerShell cmdlet it depend on the windows kernel.
The command New-ScheduledTaskAction supported windows 8 / server 2012 and newer.
you can read about id in
https://technet.microsoft.com/en-us/library/jj649817.aspx .
In windows 7 / server 2008 R2 you can use the new-ScheduledJobOption and the Register-ScheduledJob cmdlet.
you can read more about it here https://msdn.microsoft.com/en-us/powershell/reference/5.1/psscheduledjob/psscheduledjob
Here you can see example:
New-ScheduledJobOption -RunElevated -ContinueIfGoingOnBattery
Register-ScheduledJob -FilePath C:\Users\User\Desktop\CreateFolderTest.ps1 -Name TestJob -RunNow
if you want to see the job in the Task Scheduler, go to `Task Scheduler Library -> Microsoft -> Windows -> PowerShell -> ScheduledJobs
for more option you can edit the Task in the "Task Schduler" and run the Get-ScheduledJobOption.
The last thing, the Get-ScheduledJob show only the jobs that you created with the Register-ScheduledJob!
I hope it will help you.
David,
Based on my own experience (I have the Server 2008 R2 and Powershell 4 is installed), the newer cmdlets for scheduled tasks (such as New-ScheduledTaskAction) are not recognizable by Server 2008 R2. I also tried to add the newer cmdlets into the system32\WindowsPowerShell\v1.0\Modules folder but it is still not working.
Other post I read said these Cmdlets are coming with server 2012 or Windows 8 or later.
thanks
Liang
I'm trying to execute a Powershell script which contains Sharepoint commands as part of my Jenkins job.
Seemingly, the Sharepoint snapin is only available to 64bit Powershell sessions. A 32bit session does not show the Sharepoint snapin.
64bit
PS C:\Users\user> Get-PSSnapin -Registered
Name : Microsoft.SharePoint.PowerShell
PSVersion : 1.0
Description : Register all administration Cmdlets for Microsoft SharePoint Server
Most suggestions to run a 64bit Powershell are to run from the following path. Even if I test this from a 32bit command prompt, I still get a 32bit Powershell instance
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
How can I execute 64bit (and therefore Sharepoint) Powershell commands via Jenkins?
Installing the 64bit JRE and starting Jenkins with that (edit jenkins.xml) resolved the issue.
In my environment I have a single server that has access to pretty much my entire network. That server is running Windows 2008 r2, and I have upgraded Powershell to version 4.0. The question I have is this... Can I run cmdlets from that machine on other machines that are version 4 specific?
For instance, when I am using Powershell, even though it is version 4, it doesn't give me an intellisense autocomplete for "Get-Volume" like it would on a 2012 r2 machine. I understand that it won't run on that machine because the infrastructure won't allow for it, but what about a 2012 r2 machine remotely?
I am looking to run batch scripts from there for various purposes.
First, this is probably a ServerFault-question as it's related to server-administration.
PowerShell 4.0 installed on 2008 R2 can't run 2012 cmdlets on a 2012 R2-machine like Get-Volume -ComputerName My2012Server, because the cmdlets doesn't exist on your 2008 R2 machine. However, you should be able to invoke the cmdlet on the 2012 R2-server, like:
Invoke-Command -ComputerName My2012Server -Scriptblock { Get-Volume }
Be aware that you would not get autocomplete support when writing it as the commands and help files aren't installed on your 2008 R2-server
Import-PSSession is also a possibility if your gonna run the commands interactively. For a script I would probably still use Invoke-Command.
Get-Volume in your example is available only on Windows Server 2012 and above. So, it won't auto-complete on a 2008 R2 system. You can use PowerShell implict remoting.
Using implict remoting, you can import all cmdlets from a remote system into a local session and use them as if they are available on the local system.
The situation. On a Windows 7 SP1 machine, I have updated with Windows6.1-KB2819745-x64-MultiPkg.msu. Furthermore, in PowerShell $PSVersionTable now reports ‘PSVersion 4.0’.
At present, my conclusion is that many PowerShell 4 cmdlets such Test-NetConnection, will only work on Windows 8.1. However, I was wondering if there was a work-around whereby I could import PowerShell 4 modules on my Windows 7 machine.
You cannot. They rely on the underlying features of the newer OS (8.0 or 8.1) and cannot be ported back to Windows 7 . The alternative is to write your own functions / modules to replicate the new cmdlets using .NET framework methods.
For instance, the Get-FileHash cmdlet is a one-liner in PowerShell 4.0, but to replicate in 2.0 we have to use .NET.
PowerShell v4
Get-FileHash -Algorithm SHA1 "C:\Windows\explorer.exe"
PowerShell v2
$SHA1 = new-object -TypeName System.Security.Cryptography.SHA1CryptoServiceProvider
$file = [System.IO.File]::Open("C:\Windows\explorer.exe",[System.IO.Filemode]::Open, [System.IO.FileAccess]::Read)
[System.BitConverter]::ToString($SHA1.ComputeHash($file)) -replace "-",""
$file.Close()
At least Test-NetConnection can be ported back to Windows 7. Just copy folders NetTCPIP, DnsClient, and NetSecurity from the supported Windows machine with the same PowerShell version (Windows 8.1, Windows 10, etc). Folder - C:\Windows\System32\WindowsPowerShell\v1.0\Modules. Then Import-Module -Name C:\Windows\System32\WindowsPowerShell\v1.0\Modules\NetTCPIP -Verbose
Alternatively, you can import a module from a remote machine (say win2012):
$rsession = New-PSSession -ComputerName win2012
Import-Module NetTCPIP -PSSession $rsession
I have had the same problem on my Windows 7 x64 and both solutions worked for me as of PowerShell 5.1.
Adding to Anton Krouglov's answer. PowerShell modules are cross-platform compatible. So a module copied from Windows Server 2012 R2 x64 can be imported to Windows 7 x86, and even if you are running as standard user without rights to copy them to C:\Windows\System32\WindowsPowerShell\v1.0\Modules you can copy it to any local folder, and run.
Assuming you copied the NetTCPIP, DnsClient, and NetSecurity modules from a Windows Server 2012 or higher machine, and save them to a folder you can import them using
Get-ChildItem -Directory .\psmodules | foreach { Import-Module -Name $_.FullName -Verbose}
Test-NetConnection -InformationLevel "Detailed"
As far as I know, Windows Server 2008 R2/Windows 7 simply doesn't have the counters that the .NET methods use to implement get-netstuff.
A new PowerShell version can implement hash compare, etc. since this is not related to anything, just a piece of code. But if you want to use, for example, Get-NetTCPConnection there is nothing to show.
I see several responses which assert portability, and my testing confirms their assertions:
Import all of the required modules, either from file, or via a PSSession to a host which has the required modules.
The architecture of PowerShell Console (x86 or x64) you run will determine which module architecture you import.
For those who are:
still unable to make this work
AND
do need a reliable TCP test, but may not need everything else provided by Test-NetConnection
AND
Need it all to work even on PowerShell v2.0
You may wish to try this.
# Create a TCP Client using .Net & attempt connection to target
$TCPClient = New-Object .net.sockets.tcpclient("[IP address or hostname]",[port])
# At the above point you may see familiar-looking Windows error messages in
# red text. (You may want to use "try/catch" if you intend to loop).
# Otherwise, check your new object's status to see if it worked
$TCPClient.Connected
# The response is either "True" or False"
# Now to avoid leaving idle connections, run:
$TCPClient.Close()
Naturally, it should be possible to create a loop which tests multiple connections, and outputs the results by selecting the properties of the $TCPClient.
My initial testing shows you would want to Select these properties
The address you tested
$TCPClient.Client.RemoteEndPoint.Address.IPAddressToString
The port you tested
$TCPClient.Client.RemoteEndPoint.Port
The result
$TCPClient.Connected
HIH
While PowerShell 4.0 is available on Windows 7, as Knuckle-Dragger states certain features rely on newer operating system functionality. Unfortunately Test-NetConnection is not available in Windows 7 as stated in the documentation.
Test-Connection, which is present, is basically ping. Test-NetConnection offers much more functionality, allowing a choice of things such as TCP ports, protocols, route tracing, and information levels.
There is a Send-Ping script available from the ScriptCenter in the TechNet gallery, but I think this is only really useful if you are stuck on PowerShell 3.0 for some reason.
I can only assume you installed the wrong package. Make sure you download the proper package from here.
Below you will see in running Windows 7 Service Pack 1 with PowerShell 4 using Test-Connection and Get-FileHash: