The commenter is correct that you cannot start an application in another session from remote. However, this is a security restriction that prevents cross-session contamination and shatter attacks. It is a (security) limitation of Windows, not of PowerShell.
Under Windows, all services run in session 0, the interactive user run in session 1, and if more users log on (e.g. remotely through PowerShell) they are each created in their own session. Windows put severe restrictions on what programs can do cross-session - even if the processes run under the same user account: They cannot send messages, interact with the desktop windows, inject code, start threads etc.
The commenter also alludes to other security settings that you'll encounter when you first start using PowerShell:
- Execution of script files are disabled by default. You need to use the Set-ExecutionPolicy cmdlet to allow script execution, and for desktop editions you need to enable remote management. Both has secure-by-default values.
To enable script execution:
Set-ExecutionPolicy RemoteSigned LocalMachine
I.e. scripts that originates from the Internet (downloaded through a browser or received through mail/IM/etc) or other untrusted zones require digital signatures to run; locally authored scripts are allowed to run with no digital signatures.
To enable remote management run this command:
Enable-PSRemoting
On Windows Server versions it is now assumed that the administrator will want to use remote management, so it is enabled by default for servers. For desktops you'll need to set it through a group policy or with the command above.
The only attribute you contrasted was how they compare to powershell on the axis of better or worse, and I just stated my belief that it's hard to compare them accurately due to fundamental differences. That's not a strong basis for me to make assumptions about those shells.
By asking if inferno-shell and friends were easily comparable with C-like shells I was attempting to determine if they were additionally hard to compare with powershell, and infer from that your unfamiliarity with powershell. That, obviously, was a stretch.
If you want to run a script simultaneously on a number of hosts, you use the Invoke-Command cmdlet (or it's alias icm).
If you want to stop a process, you use Stop-Process (or it's alias kill).
To copy files or directories you use the Copy-Item cmdlet (or one of it's aliases cp and copy).
Hence, to stop WINWORD on a host1, host2 and host3 and then copy a directory from host0 to each of them, you would write:
As simple as it should be!The commenter is correct that you cannot start an application in another session from remote. However, this is a security restriction that prevents cross-session contamination and shatter attacks. It is a (security) limitation of Windows, not of PowerShell.
Under Windows, all services run in session 0, the interactive user run in session 1, and if more users log on (e.g. remotely through PowerShell) they are each created in their own session. Windows put severe restrictions on what programs can do cross-session - even if the processes run under the same user account: They cannot send messages, interact with the desktop windows, inject code, start threads etc.
The commenter also alludes to other security settings that you'll encounter when you first start using PowerShell: - Execution of script files are disabled by default. You need to use the Set-ExecutionPolicy cmdlet to allow script execution, and for desktop editions you need to enable remote management. Both has secure-by-default values.
To enable script execution:
I.e. scripts that originates from the Internet (downloaded through a browser or received through mail/IM/etc) or other untrusted zones require digital signatures to run; locally authored scripts are allowed to run with no digital signatures.To enable remote management run this command:
On Windows Server versions it is now assumed that the administrator will want to use remote management, so it is enabled by default for servers. For desktops you'll need to set it through a group policy or with the command above.