Using PowerShell implicit remoting

• Author
• Recent Posts

Adam Bertram

Adam Bertram is a 20-year IT veteran, Microsoft MVP, blogger, and trainer.

Latest posts by Adam Bertram (see all)

• Create a certificate-signed RDP shortcut via Group Policy - Fri, Aug 9 2019
• Monitor web server uptime with a PowerShell script - Tue, Aug 6 2019
• How to build a PowerShell inventory script for Windows Servers - Fri, Aug 2 2019

A commonly used feature in PowerShell is PowerShell remoting. Using cmdlets like Invoke-Command is commonplace when executing commands on a remote computer. For example, let's say you need to query some Active Directory users but haven't gone through the rigmarole to install Remote Server Administration Tools. You can run Get-AdUser on a domain controller by running Invoke-Command to find the users you're looking for.

Invoke-Command -ComputerName LABDC -ScriptBlock { Get-AdUser -Filter * }

It's clear when you run that command that you're running the Get-AdUser cmdlet on the remote computer LABDC. You could say that you're using PowerShell Remoting explicitly. PowerShell, though, has another way to run remote commands through a feature called implicit remoting. Implicit remoting, as the name implies, is a way to invoke remote commands in the background that makes it seem like the commands aren't being invoked remotely at all!

Instead of using the Invoke-Command command to find AD users, you could create a new session, import the necessary modules in that session, and then export the commands available in that session locally. This, in a sense, creates "proxy" commands which can then be run just as they would be if the commands were loaded locally. To do that, I first need to create the session using the New-PSSession cmdlet.

$s = New-PSSession -ComputerName LABDC

Next, I'll need to be sure that the modules I need are loaded in that remote session. In this case, I need the ActiveDirectory module, so I'll go ahead and import that.

Invoke-Command -Session $s -ScriptBlock { Import-Module ActiveDirectory }

Exporting cmdlets with Export PSSession

At this point, I can then export all of the loaded commands in that remote session to my local session using the Export-PSSession cmdlet. Notice that I don't have to export all of the commands in that remote session. Instead, I'm specifying a wildcard search pattern to bring in only those commands that match -AD.

I'm also using the OutputModule parameter here so that I can define what local module these commands will be a part of. This module won't be an actual module, but instead will be a placeholder to contain all of these commands.

Export-PSSession -Session $s -CommandName *-AD* -OutputModule RemAD -AllowClobber
Export-PSSession

At this point, I can run Get-AdUser just as if that command were available on my local computer. When running Get-Command, you can't even tell that I don't have the ActiveDirectory module installed!

PS> Get-Command -Name Get-AdUser

CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Cmdlet          Get-ADUser                                         1.0.0.0    ActiveDirectory

When you're done, it's always a good idea to remove your open session using Remove-PSSession.

$s | Remove-PSSession

Once you have the remoting session exported to your local session, the only way you can tell that the commands you're running aren't local is that they may take a few more seconds to run.

Other than that, and the occasional dependency such as a .NET assembly or some other ancillary file the commands may be referencing, implicit remoting is a great way to run commands without installing modules.