There are several features of Windows Powershell that are not supported in Powershell Core. Since Powershell Core is being actively developed in favor of Windows Powershell, on a Windows platform can Powershell Core use Windows Powershell modules that have not yet been ported to Powershell Core?
Most notably I am concerned with making sure Powershell Core can work with COM objects and Powershell Remoting (over WinRM).
To answer your specific questions first
PowerShell Core CAN use WinRM remoting for Windows to Windows remoting scenarios. Use it in exactly the same way as Windows PowerShell. WinRM remoting is available from Linux machines to Windows machines but is still a work in progress. if your remoting scenario involves a Linux system you're better off using SSH remoting
You can use COM objects (on Windows systems only) for instance this works:
$xl = New-Object -comobject 'Excel.Application'
$xl.visible = $true
$xlbooks =$xl.workbooks
$wkbk = $xlbooks.Add()
$sheet = $wkbk.WorkSheets.Item(1)
With regard to modules some modules will work under PowerShell core - for instance the networking modules and the storage modules. if its a binary module such as Active Directory then it won't work. At least some of the binary modules, including AD, are being converted to work with PowerShell core. if you look in the module folder and it has CDXML files it should work under PowerShell core.
You could also use implicit remoting to get a module to work. Create a powershell remoting session to the local machine and import the module through the remoting session.
PowerShell core is still very much a work in progress and the number of modules that work with it will increase with time. If in doubt you'll have to test
We have one script server running Windows Server 2012 with PowerShell 4.0 and multiple other servers that run Windows Server 2008R2 with PowerShell 4.0.
What we're trying to do is use the function Get-FSRMQuota from the module FileServerResourceManager found on Server 2012 on the 2008R2 file servers. When in an RDP session on the 2008R2 file server, this can be easily done:
# From PowerShell on the file server:
New-PsSession $ScriptSever
Invoke-Command -Computer $ScriptSever {Import-Module FileServerResourceManager}
Invoke-Command -Computer $ScriptSever {Get-FSRMQuota}
However, all our scripts launch from the script server and are managed there. So we have a job that's initiated on the script server (2012) to run on the 2008R2 servers using PS Remoting. But from within this job it's not possible to import a module from the script server that initiated the job.
So my question, is there a way to import the module FileServerResourceManager from the script server into the remote session on the file server?
I hope I made it clear, as it's a bit difficult to explain. Thank you for your help.
It's not possible. According to https://technet.microsoft.com/en-us/library/jj900651(v=wps.620).aspx, FileServerResourceManager is only available as of Windows 2012.
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 found a technet article to set the display resolution using powershell and Windows Server Core Cmdlets. http://technet.microsoft.com/en-us/library/jj603036.aspx
However when I try to run the cmd PS C:\> Set-DisplayResolution -Width 1920 -Height 1200 I get an error saying the Set-DisplayResoluton is a unknown cmd. I know this cmd is for administering server core functionlaity but can it be used in Windows 8.1. And if so, how do I load the cmdlet in Powershell?
Are you trying to run this on Windows 8.1? It looks like the command might only be available on Windows Server 2012 R2 Server Core. I understand that the article says otherwise, but I just checked on my Windows 8.1 computers, and do not have the command in the session.
Get-Command -Name *resolu*;
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: