PowerShell : A deep dive into remoting - Part 6

Implicit remoting is a powerful feature of PowerShell remoting that enables you to import remote commands into your local session, or store the imported commands on the local disk for later use and use them as if they  are available on the local computer. With implicit remoting it’s possible to use the commands available in a PowerShell module added to a remote computer to execute on the local machine. Even though the commands are invoked from the local machine and looks like they are executed locally, in reality they are shortcuts/ proxies to the actual commands and will execute on the remote machines. After execution the results are transferred to the local computer via remoting.
To understand the details of implicit remoting and how it works, let’s look into the sample scenario given below.

What I’ve done here is imported a module (PSSQL) using a session that was created before and then imported that session to the local computer with the module PSSQL so that I can use the commands that are available as part of that module on my computer. To easily identify the commands that are imported as part of the Import-PSSession I’ve prefixed the commands REMSQL.

Now I can execute the cmdlets that are listed by the Get-Command –Noun REMSQL* command in the screenshot as if I execute any local commands. Please note that the behavior of the execution is the same as for other commands that are executed remotely. The objects that are returned as part of the execution will not have any methods attached to them as they are actually serialized objects from the remote machine. If you have imported a module from a computer, you need to remember that the commands run on the remote computer. If you run Get commands, they will get data from the remote computer. If you run Set commands, they change data on the remote computer. The commands look and feel local, but they're remote commands.

Persisting the imported commands

The commands that you have imported using Import-PSSession option will only stay in the local computer till the session is active. That means as soon as the remote session is closed or exited, you'll lose the commands. If you still want to keep the imported commands for later use even after the session is closed, then you need to persist the commands on the local machine.

The Export-PSSession cmdlet will help you persist the imported commands from another session and saves them in a Windows PowerShell module.

Unlike Import-PSSession, which imports commands from another PSSession into the current session, Export-PSSession saves the commands in a module. The commands are not imported into the current session. By default, Export-PSSession exports all commands, except for commands that exist in the current session, but you can use the CommandName parameters to specify the commands to export.

The Export-PSSession cmdlet uses the implicit remoting feature of Windows PowerShell. When you import commands into the current session, they run implicitly in the original session or in a similar session on the originating computer.

For e.g the above command will export the commands available in the module SQLPS to a module REMSQLPS on the local machine and can be used later for execution. Export-PSSession command support multiple arguments that can be used to customize the export, like –CommandName, -CommandType etc. Once you have exported the commands and persisted on the local computer, you can later use the Import-Command to load these modules whenever needed and work on the commands like any other powershell commands. While executing these commands, PowerShell will take care of creating a new remote session and managing it.

PowerShell : A deep dive into remoting - Part 5

PowerShell sessions are the core components of PowerShell remoting. So let’s spend some more time understanding the details of PowerShell sessions and the configurations. Every time we execute the Invoke-Command with the -ComputerName argument, a temporary session is created to execute the remote command and then released after the command is executed. A PowerShell session or PSSession represents a connection between the computer that invokes a remote command and the remote computer. A good practice to follow when you are planning to connect to a remote computer several times and executing commands is to create a PSSession and reuse this session for the work. This way, you can manage a single connection to a PowerShell host instance and have a persisted session in use.

When using a persistent connection, the commands that are executed against the session will remain in effect till the session is removed. For e.g. You can add snapins and load modules at the beginning and then use the cmdlets or functions from these snapins/ modules later in the session.

Creating and using sessions
To create a persistent session, you can use the New-PSSession command as given below
$session = New-PSSession -ComputerName COMP1

The command creates a session object and assigns it the the $session variable. The New-PSSession command also allows -Credential parameter to use to connect to the remote computer as a specific user.

$session = New-PSSession -ComputerName COMP1 -Credential (Get-Credential)

By default PowerShell uses the port 5985 for HTTP and 5986 for HTTPS connections. If the remote computer has the WinRM configured on a different port, you can mention that Port using the -Port argument for the New-PSSession command.

Every time a session is created PowerShell automatically uses the default session configuration unless you specify a different session configuration or have secured session configurations. If you want to override this behavior then you need to create a Session configuration and use the –ConfigurationName argument to use this configuration for the session.

After the session is created you can initiate a one-one connection to the remote computer using an Enter-PSSession cmdlet by using the –Session argument

Enter-PSSession –Session $session

The session object that is created will remain open till it is closed explicitly. You can use the Get-PSSession cmdlet to check the currently available sessions that is created.

Get-PSSession | fl *

Disconnect and connect to sessions
If you want to execute a long running process like configuring a SharePoint farm on a remote computer by using a remote session and you don't want to connect to the session from the current computer, but later connect from a different machine, you can use the Disconnet-PSSession and Connect-PSSession cmdlets.

The Disconnect-PSSession cmdlet disconnects a PSSession, from the current session. As a result, the PSSession is in a disconnected state. You can connect to the disconnected PSSession from the current session or from another session on the local computer or a different computer. Note that Disconnect-PSSession cmdlet disconnects only open PSSessions that are connected to the current session. Disconnect-PSSession cannot disconnect broken or closed PSSessions, or interactive PSSessions started by using the Enter-PSSession cmdlet, and it cannot disconnect PSSessions that are connected to other sessions.

You have to explicitly perform the action of disconnecting the session. A good practice is to start a session from one computer, disconnect it, and then reconnect to that session from another computer.

Get-PSSession -Session $session | Disconnect-PSSession

Once you have disconnected the session from the current host, you can later use the Connect-PSSession to reconnect the session from another computer by specifying the ComputerName that the session is available.

Connect-PSSession -ComputerName COMP1

Using the session options
There are a number of other cmdlets for the advanced configuration of remote PowerShell sessions. The first and most obvious of these is the New-PSSessionOption cmdlet, which enables an administrator to configure advanced options for use with the New-PSSession cmdlet. For instance, if you want to change the default culture to nl-nl and set the maximum object size that can be recived to 10 MB, you can use the

$nlSession = New-PSSessionOption -Culture "nl-nl" -MaximumReceivedObjectSize 10MB

To persist a session option created to use later, you can export the object to xml using the Export-CliXml cmdlet and then later import the object when creating a new session.

$nlSession | Export-CliXml c:\PSSessions\nlSession.xml

New-PSSession -ComputerName COMP1 -SessionOption (IMport-CliXml c:\PSSessions\nlSession.xml)

Desired State Configuration - Introduction to CIM

PowerShell 4.0 introduces desired state configuration (DSC), a powerful new feature that makes it easier than ever to manage your Windows infrastructure, whether on premise or in the cloud. DSC is built on the Common Information Model (CIM) standard developed by the Desktop Management Task Force (DMTF) and uses Windows Remote Management (WinRM) technology as a communication mechanism. In this post we will look at what Windows Remote Management is and how it is used in the Windows OS world to enable standards-based management. In the upcoming posts I'll explain how CIM cmdlets in PowerShell use WinRM to work with management data from remote systems and the role of DSC in managing remote machines.

Windows Remote Management is the Microsoft implementation of the WS-Management Protocol. It uses SOAP (Simple Object Access Protocol) for exchanging control information and data between capable devices over HTTP and HTTPS. The main goal of WS-Management-based implementation is to provide a common way for these systems or components to access and exchange information.

The WinRM sevice enables remote management of windows systems. You can use the cmdlet given below to check the status of the service on the computer.

Get-Service -ComputerName 'MyComputerXXX' -Name WinRM

If the service is not enabled on the computer, you can create a listener based on HTTP or HTTPS protocol on the desired port. To setup a WinRM listener you can use the Set-WSManQuickConfig cmdlet. Once WinRM listener is set and working, you can use the infrastructure to access management information from remote servers.

The CIM cmdlets introduced as part of PowerShell 3.0 makes it easier to work with Windows Management Instrumentation.  CIM - Common Information Model is the DMTF standard for describing the structure and behavior of managed resources such as storage, network, or software components. The CIM standard defines two parts:

• Schema: Provides the actual model descriptions
• Infrastructure: Defines the standards for integrating multiple management models using OOPS constructs and design.

The CIM cmdlets support multiple ways of exploring WMI. They work well when you are working in an interactive fashion. For example, Tab expansion expands the namespace when you use the CIM cmdlets; thereby permitting exploring namespaces that might not otherwise be very discoverable. You can even use this technique to drill down into namespaces. For e.g if you want to find all the classes in the root/Microsoft namespace. use the cmdlet. You can try out tab completion after typing in the –Namespace option for the cmdlet.

Get-CimClass -Namespace root/Microsoft

To create an instance of a class, you can use the Get-CimInstance cmdlet. For example, the below given command, exposes all properties for the class MSFT_WmiError

Get-CimClass -ClassName MSFT_WmiError | ForEach-Object {$_.CimClassProperties}

You can also use the –ComputerName or –CimSession parameters to manage remote machines. Its recommended to use the CimSession and reuse the session if you are trying to perform a large set of operations on the remote server.

For e.g. you can use the commands given below to get the details of the processes running on the remote server:

$session = New-CimSession –ComputerName XXX

Get-CimInstance –ClassName Win32_Process –CimSession $session

Once we have the CIM sessions set up and the command execution is complete, we can remove the existing CIM sessions, by using the Remove-CimSession cmdlet.