Cmdlet

By default, Cmdlet’s (Command-Let) are specific commands and they have Verb-Noun naming patterns (eg Get-Service, GetProcess). They are different from normal commands because Cmdlets are .NET Framework Classes, not standalone executables.

If you want to see what the Cmdlets are available in PowerShell or if you want to call any desired Cmdlets, you can accomplish that by executing the command “Get-Command” with “name of Cmdlet” as an argument. The following screenshot shows the use of command.

Pipeline

Pipeline is a set of data processing elements connected in series, where the output of one element is the input of the next one. PowerShell supports the pipelining

Remoting

The Remoting feature comes with PowerShell v2 which allows system administrators to access and manage other systems from a central point through PowerShell. With PowerShell v3, the Remoting feature has been renewed and improved. This feature does not only cover Windows systems, it also covers Linux and Mac OS X operating systems. Once PowerShell has been open source, it has also become available for the relevant operating systems.

To have Remoting abilities, Remoting feature must be enabled and allowed on the target system.

PowerShell’s Remoting feature allows you to run scripts on remote systems. Many Cmdlets in PowerShell also have additional features such as working in remote systems and getting the results. Instead of providing this feature for each cmdlet, Microsoft has developed the Remoting feature so that all infrastructure can communicate over one secure protocol.

Enabling Remoting

The Enable-PSRemoting Cmdlet can be used to activate the remoting feature. When running the cmdlet with-Force parameter, Remoting service will be activated directly without any confirmation and the necessary settings will be made. When the cmdlet is used without the-Force parameter, confirmation will be prompt. It starts the WinRM service and sets it to run automatically at startup. Then It sets up the listener, and starts listening to connections from any IP addresses. It concludes the process with activating Firewall rules for the ports of Remoting feature.

How Remoting Feature Works?

In Figure 4 below, the infrastructure of the PowerShell Remoting feature has been tried to be schematized. In our scenario, we have two different systems thats are named as “Client 1” and “Client 2”. System named as “Client 1” wants to connect to the system named as “Client 2” system via PowerShell’s Remoting feature.

The Infrastructure of PowerShell Remoting Feature

1- The system named as “Client 1”, communicates with its own WSMan (Web Services for Management) service. WSMan is an HTTP (S)-based protocol with the ability to encapsulate many other protocols. By default the remoting feature uses the HTTP protocol, however the connection can be encrypted easily by using the HTTPS protocol.

2- The system named as “Client 2”, the WinRM Service is running. This service can have one or more Listeners, and each Listener waits for WSMan traffic for a specific IP address and a specific port number from a specific protocol (HTTP or HTTPS). Listeners are created to identify the any received traffic by the WinRM service. We are talking about PowerShell here and a PowerShell session will start on the system of “Client 2”.

In Figure 4, thepowershell.exeprocess seems to be starting in the system of Client 2, but this is done only for easy understanding. Under normal conditions, the process namedwsmprovhost.exewill start, notpowershell.exe.

Execution Policy

Execution Policy, are the policies that determine how it should work in which conditions for PowerShell. Execution Policy; can be set for the local system, any user or any PowerShell session.

Execution Policy is not a security measure as it is known and can be easily overcome. It has been developed to prevent the damage they cause users run the script by accident.

Restrictedis the most trusted policy because it allows only interactive PowerShell access. This means that you can only run commands individually. This policy is not concerned with where the scripts come from (via the local network or the internet), whether they are signed or not, and is not allowed to run any scripts.

AllSigned,in this policy, only scripts signed by trusted authorities on PowerShell are allowed. In addition, when a signed script is executed, confirmation is requested.

RemoteSignedcan run scripts on the local system in this policy but must be signed by trusted authorities for scripts downloaded over the internet. Also, there is no need to get any confirmation while scripts are running.

Unrestricted,no restrictions; all Windows PowerShell scripts can be run. The warning will only be displayed if the script is downloaded from the internet.

Bypass,there is no restriction, no warning, or a confirmation mechanism in this policy. Every script can be run.

Undefined,no Execution Policy is assigned. If no Execution Policy is assigned for the specified scopes, the Restriced policy will be assigned by default.

The Get-ExecutionPolicy Cmdlet can be used to find the Execution Policy level in PowerShell. If you want to change the level of Execution Policy, in PowerShell session running on Administrator rights; The Set-ExecutionPolicy Cmdlet can be run.

At the same time, Execution Policy change without the need for any extra rights when starting a new PowerShell session-executionpolicy parameter is used. The value of the parameter can be set to whatever level is desired, the Execution Policy for the new PowerShell session to be started will be set as desired. The sample operation is shown in the following screen image.