Chapter 5: Implicit remoting in PowerShell
In chapter 4 on interactive remoting sessions, we looked at how we can enter a remote session and then execute commands as if they were local. However, if you’d observed it more closely, we were actually sitting in the remote session than local session. The change in PowerShell prompt indicates this fact clearly.
In this chapter, we will look at implicit remoting feature in PowerShell. This feature makes it possible to run the commands / scripts on the remote computer while in the local session. Just read on if that statement sounds confusing.
Why implicit remoting?
We use interactive remoting to overcome a few disadvantages of using Invoke-Command. This method too has its own drawbacks. Within interactive remoting, you explicitly enter/exit a remote session. This also means that you are connected only to one remote computer and you have access only to the cmdlets or modules available on that remote computer. What if you want to access different cmdlets available on different computers?
For example, let us say you have two different computers one with Exchange 2010 and other with SharePoint 2010. Now, if you want to access cmdlets available to manage both these technologies from a “single computer” and in the “local session”. Take a note, “single computer” and “local session” is the key to understand the concept of implicit remoting. The important thing to understand is that we need to manage multiple computers / technologies without ever the need to go out of local PowerShell session.
Using Invoke-Command is certainly not the choice because it involves setting up a session to the remote computer and then sending a script block to execute in that session. This is quite tedious. Although interactive remoting can eliminate the drawbacks of Invoke-Command, it is specific one remote session. So, if you are connected to the Exchange 2010 remote session, your SharePoint 2010 session is not available. This is where implicit remoting becomes important.
Implicit remoting can be used to bring remote commands to a local session. In implicit remoting, once you import remote commands in to a local session, you don’t have to worry about the PS session details. You can import any number of remote sessions in to the local session making it possible to access cmdlets from different product technologies in the same local session. PowerShell will take care of that for you in the background.
Creating an implicit remoting session
Well, we have to first create a persistent PS session using New-PSSession and then use that to import remote commands in to local session. You can do it as shown here
$s = New-PSSession -ComputerName SP2010-WFE
Import-PSSession -Session $s
By default, Import-PSSession imports all commands except for commands that have the same names as commands in the current session. To import all the commands, use the -AllowClobber parameter. You will see a progress bar on top of the console window showing the progress of the import.
If you import a command with the same name as a command in the current session, the imported command hides or replaces the original commands. This is because import session converts the cmdlets to functions before importing and functions take precedence over cmdlets. So, imported commands take precedence over the local commands with same name -- irrespective of the fact whether those commands are loaded after importing a session or before.
To know more about the command precedence, read about_Command_Precedence.
However, aliases are an exception. Original aliases in the local session take precedence over imported aliases.
Avoiding name conflicts while importing a remote session
Import-PSSession provides a -Prefix parameter which adds the specified prefix to the nouns in the names of imported commands. For example,
Import-PSSession -Session $s -Prefix RS
This will prefix RS to all the cmdlets imported from a remote computer. So, if Get-Command was imported using this method, the local session will have Get-RSCommand and when you use this cmdlet, PowerShell implicitly runs this command inside the remote session.
As we discussed earlier in this chapter, PowerShell manages implicit remoting in the background. So, the behavior of Invoke-Command, creating/destroying a PS session every time we execute a remote command, exists with implicit remoting too. Hence, you will see that executing remote commands over this method a bit slow. To work around this, import-PSSession adds a -asJob parameter to all the commands imported in to the local session.
For example,
$s = New-PSSession -ComputerName Ravi-Dev
Import-PSSession -Session $s -Prefix RS
Get-RSProcess -asJob
This will run Get-RSProcess on the remote computer as a background job. Make a note that the original Get-Process has no -asJob parameter.
Importing modules and snap-ins to local session
$s = New-PSSession -ComputerName Ravi-Dev
Invoke-Command -Session $s -ScriptBlock {Import-Module ActiveDirectory}
Import-PSSession -Session $s -Module ActiveDirectory
In the above example we first create a PS session, import active directory module using InvokeCommand and then import the session in to the local session. This makes all the active directory cmdlets available in the local session.
Now, we can connect do a different remote session and import cmdlets from that session also.
$s = New-PSSession -ComputerName SP2010-WFE
Invoke-Command -Session $s -ScriptBlock {Add-PSSnapin Microsoft.SharePoint.PowerShell}
Import-PSSession -Session $s
Now, within the local session, we have access to AD cmdlets from one computer and SharePoint 2010 cmdlets from another machine. This makes it easy to manage both from the same computer and local session without worrying much about creating / destroying sessions.
Limitations of implicit remoting
Using implicit remoting you cannot import variables or Windows PowerShell providers. You cannot start a program with user interface or requires access to interactive desktop. Since, import-PSSession uses Invoke-Command to run the remote commands, it may be slow. Hence, all imported commands get support for –asJob parameter to run them as background jobs on the remote computer.
Summary
Implicit remoting is about bringing remote commands to local session. This technique can be used to import modules/snap-ins for commands that aren’t available natively to PowerShell. In this chapter, we looked at how to create implicit remoting sessions and a few parameters used along with ImportPSSession cmdlet.