Part1
Chapter 1: Introduction to remoting
Traditional remoting in PowerShell
A few cmdlets in PowerShell support accessing information on a remote system. These cmdlets have a – ComputerName parameter. For example the following cmdlets support the computername parameter and hence can be used to access information from a remote computer.
The remoting capability of these cmdlets is independent of PowerShell. It is up to the cmdlet author to implement the remote access using methods such as remote procedure call (RPC), etc. This method of remoting can be called traditional remoting or classic remoting.
One obvious disadvantage is that not all PowerShell cmdlets implement this type of remoting. So, for example, if you want to execute Get-PSDrive or Get-ChildItem remotely on a different computer, it is not possible. This is where the new PowerShell 2.0 remoting feature plays an important role. So, throughout this guide, whenever we refer to remoting, we refer to the new remoting technology but not traditional or classic remoting methods.
Overview of PowerShell 2.0 remoting
One of the most exciting and important features of PowerShell 2.0 is the remoting capability. PowerShell remoting enables management of computers from a remote location. Remoting is built on top of Windows remote management (WinRM) 1 . WinRM is Microsoft’s implementation of WS-Management2 protocol.
This feature enables what is known as Universal Code Execution Model 3 in Windows PowerShell 2.0. UCEM means that whatever runs locally should run anywhere. PowerShell remoting also lets you import remote commands in to a local session — a feature known as implicit remoting and also enables you to save or export these imported commands to local disk as a module for later use. There are bunch of other features such as interactive sessions, etc. We will look in to all these features -- one thing at a time.
PowerShell remoting allows for multiple ways of connecting. These ways include interactive (1:1), fanout (1: many), and fan-in (many: 1 by using the IIS hosting model, for example, Quest Software’s MobileShell 4 ). This guide will walk though each of these ways and explain how to configure your system for these scenarios.
PowerShell 2.0 remoting requirements
To enable PowerShell remoting, all computers participating in remote management should have the following software
1. Windows PowerShell 2.0
2. NET framework 2.0 SP1 or later
3. Windows Remote Management (WinRM) 2.0
All of the above are installed by default on Windows 7 and Windows Server 2008 R2. However, earlier versions of Windows will require you to download the updates from Microsoft website and install them yourself.
PowerShell 2.0 and WinRM 2.0 are included as a part of Windows Management Framework download and are available for Windows XP, Windows Server 2003, Windows Vista and Windows Server 2008. WinRM 2.0 and PowerShell 2.0 can be installed on the following supported operating systems
1. Windows Server 2008 with Service Pack 1
2. Windows Server 2008 with Service Pack 2
3. Windows Server 2003 with Service Pack 2
4. Windows Vista with Service Pack 2
5. Windows Vista with Service Pack 1
6. Windows XP with Service Pack 3
7. Windows Embedded POSReady 2009
8. Windows Embedded for Point of Service 1.1
PowerShell 2.0 remoting is supported only on the operating systems listed above.
To be able run scripts and commands on remote computers, the user performing remote script execution must be
For a complete discussion on PS Session configurations refer to chapter << >>.
Also, on client OS versions of Windows such as Windows Vista and Windows 7, network location must be set either to Home or Work. WS-Management may not function properly if the network location for any of the network adapters is set to public.
Overview of remoting cmdlets
This section provides a quick overview of some of the important cmdlets that are used in PowerShell remoting. This list will also include cmdlets that are not directly used within remoting but help configure various aspects of remoting. The knowledge of some of these cmdlets such as WSMan cmdlets is not mandatory for basic usage of PowerShell remoting. Subsequent chapters will discuss these cmdlets in detail.
Enable-PSRemoting
The Enable-PSRemoting cmdlet configures the computer to receive Windows PowerShell remote commands that are sent by using the WS-Management technology. This cmdlet will be the first one to run if you want to use PowerShell 2.0 remoting features and needs to be run just once. This cmdlet internally calls Set-WSManQuickConfig to configure WinRM service, enable firewall exceptions for WS Management and finally enables all registered PowerShell configurations.
Note: You need to enable PowerShell remoting only if you want the computer receive commands from a remote machine. To only send commands to a remote machine, you don’t need to enable PowerShell remoting.
Disable-PSRemoting
The Disable-PSRemoting cmdlet disables all PowerShell session configurations on the local computer to prevent the computer from receiving any remote commands. You will have to manually stop the WinRM service if you don’t want the service to be running after you disable PowerShell remoting.
Invoke-Command
The Invoke-Command cmdlet runs commands on a local or remote computer and returns all output from the commands, including errors. With a single Invoke-Command command, you can run commands on multiple computers. This cmdlet — in its default form — opens a session for running a command against a remote computer and closes it once the execution is complete. This method may be slow and can be worked around by specifying pre-defined session information.
New-PSSession
Invoke-Command cmdlet supports specifying an existing session to enhance the speed of overall command execution. By specifying an existing session, we eliminate the need for creating/destroying the sessions on the fly. New-PSSession cmdlet can be used to create a persistent connection to a remote computer. By creating a persistent session, we will be able to share data, such as a function or the value of a variable between different commands executing within the PSSession.
Enter-PSSession
Enter-PSSession cmdlet starts an interactive session with a single remote computer. During the session, the commands that you type run on the remote computer, just as though you were typing directly on the remote computer. You can have only one interactive session at a time. You can specify the PSSession you created using New-PSSession as a parameter to this cmdlet.
Exit-PSSession
Exit-PSSession exits an interactive PS Session created using Enter-PSSession cmdlet.
Get-PSSession
The Get-PSSession cmdlet gets the Windows PowerShell sessions (PSSessions) that were created in the current session. This cmdlet gets all the PSSessions returns all the PSSessions in to a variable when no parameters are specified. You can then use the session information with other cmdlets such as InvokeCommand, Enter-PSSession, Remove-PSSession, etc.
Remove-PSSession
The Remove-PSSession cmdlet closes PS session(s). It stops any commands that are running in the PSSessions, ends the PSSession, and releases the resources that the PSSession was using. If the PSSession is connected to a remote computer, Remove-PSSession also closes the connection between the local and remote computers.
Import-PSSession
Import-PSSession cmdlet uses the implicit remoting feature of PowerShell 2.0. Implicit remoting enables you to import commands from a local/remote computer in to an existing PS session and run those commands as if they were local to the session.
Export-PSSession
The Export-PSSession cmdlet gets cmdlets, functions, aliases, and other command types from another PSSession on a local or remote computer and saves them to local disk as a Windows PowerShell module. We can now use the Import-Module cmdlet to add the commands from the saved module to a PS Session.
Register-PSSessionConfiguration
Any PS session created using Invoke-Command or New-PSSession or any other PowerShell remoting cmdlet for that matter uses the default PS Session configuration as specified in the $PSSessionConfigurationName variable. PS Session configuration determines which commands are available in the session, and it can include settings that protect the computer, such as those that limit the amount of data that the session can receive remotely in a single object or command. So, you can use the Register-PSSessionConfiguration cmdlet creates and registers a new session configuration on the local computer.
Unregister-PSSessionConfiguration
The Unregister-PSSessionConfiguration cmdlet deletes registered session configurations from the computer. It is possible to delete the default PSSession configurations (Microsoft.PowerShell or Microsoft.PowerShell32) using this cmdlet. In such a case, you can use Enable-PSRemoting cmdlet to recreate and register the default PS Session configurations.
Disable-PSSessionConfiguration
Disable-PSSessionConfiguration disables a registered PS Session configuration. Remember, this only disables the configuration but not un-register or delete the information from local computer. These disabled session configurations cannot be used to establish a remoting session.
Enable-PSSessionConfiguration
The Enable-PSSessionConfiguration cmdlet re-enables registered session configurations that have been disabled by using the Disable-PSSessionConfiguration cmdlet.
Get-PSSessionConfiguration
The Get-PSSessionConfiguration cmdlet gets the session configurations that have been registered on the local computer.
Set-PSSessionConfiguration
The Set-PSSessionConfiguration cmdlet changes the properties of the registered session configurations on the local computer.
Test-WSMan
PowerShell remoting requires WinRM service to be running on the remote machines. You can use Test- WSMan cmdlet to quickly check if you can establish a remoting session with other computers. If WinRM is not enabled on remote machine, you can safely assume that PowerShell remoting is not enabled. However, you cannot assume that PowerShell remoting is enabled just by verifying that WinRM service is running. Remember, this cmdlet checks only for WinRM service and remoting requires many other components to function.
Enable-WSManCredSSP
PowerShell remoting supports CredSSP authentication and the same can be enabled by using Enable- WSManCredSSP cmdlet. The Enable-WSManCredSSP cmdlet enables CredSSP authentication on a client or on a server computer. When CredSSP authentication is used, the user’s credentials are passed to a remote computer to be authenticated. This type of authentication is designed for commands that create a remote session from within another remote session. For example, you use this type of authentication if you want to run a background job on a remote computer.
Disable-WSManCredSSP
The Disable-WSManCredSPP cmdlet disables CredSSP authentication on a client or on a server computer.
There are other WSMan cmdlets introduced in PowerShell 2.0 such as Connect-WSMan, DisconnectWSMan, Get-WSManInstance, New-WSManInstance, New-WSManSessionOption, RemoveWSManInstance and Set-WSManInstance. These cmdlets are not really meant for PowerShell remoting but we will discuss them as required.