Windows PowerShell: Implicit Remoting

Don Jones

There’s a little-known feature in Windows PowerShell 2.0 that can easily add an incredible amount of flexibility to your environment. Imagine that your client computers primarily run Windows XP—still a common-enough scenario. Your domain controllers are using Windows Server 2003.

You can get Windows PowerShell 2.0 for both of these OSes, but you might not be able to use some of the newer Windows PowerShell cmdlet modules, like the Active Directory module included with Windows Server 2008 R2. Those modules won’t run on older versions of Windows.

That’s no problem. Just install Windows 7 or Windows Server 2008 R2 on one computer in your environment (the Active Directory module will run on either of those). For example, you could install a single Windows Server 2008 R2 domain controller, because that will provide you with both the Active Directory module and the Active Directory management gateway service with which the module communicates. Download the gateway service and install it on Windows Server 2008 and Windows Server 2003.

Enable remoting and WinRM on that new domain controller by running Enable-PSRemoting in Windows PowerShell. Then, fire up Windows PowerShell 2.0 on your Windows XP client computer, and get ready to make some magic.

Making a Module

Start by establishing a remoting session to the new domain controller:

$session = New-PSSession -computerName my-new-dc

Provide the correct computer name in place of “my-new-dc,” of course. You can specify additional parameters, such as alternate credentials or alternate WinRM ports. Run help new-pssession for details.

Next, tell that remote instance of Windows PowerShell to load the Active Directory cmdlets:

Invoke-command { import-module activedirectory } -session $session

Here’s the cool part: Have your local instance of Windows PowerShell export the Active Directory cmdlets from the remote session into a local module on your client computer:

Export-PSSession -session $session -commandname *-AD* -outputmodule RemAD -allowclobber

This command creates a new Windows PowerShell module, stored in your Documents folder under WindowsPowerShell\Modules\RemAD. Only the cmdlets whose names match the pattern “*-AD*” will be included. That’s one of the biggest reasons most add-in cmdlets use some kind of prefix like “AD” as part of the cmdlet’s name. Doing so makes it easier to grab only those cmdlets.

The cmdlets aren’t actually copied to your local computer. Instead, the locally created module serves as a kind of shortcut. The cmdlets will always be executed on the remote domain controller, but the cmdlets will seem to be running locally.

Use the Cmdlets

Start by removing that session to the remote domain controller:

Remove-PSSession -session $session

Now load the new module:

Import-Module RemAD -prefix Rem

This command loads the new module into memory, and appends a “Rem” prefix to the name of every cmdlet in that module. The prefix is a good way to remind you that these cmdlets will be executing remotely. You can choose any prefix you like, but I usually use something like “R” or “Rem” to stand for “Remote.”

Try asking for help on a remote cmdlet:

Help New-RemADUser

You’ll see an error, because a current remoting session isn’t established between your computer and the domain controller where these cmdlets live. You don’t need to explicitly start that session. You can implicitly do so by trying to execute one of the remoted cmdlets:

Get-RemADUser -filter "Name -like 'D*'"

This will re-instantiate the remote connection to the domain controller, submit the command for execution and run the command on the domain controller. Then every user whose name starts with “D” will be serialized into XML and transmitted across the network to your computer. There they’ll be de-serialized back into objects you can work with in the Windows PowerShell pipeline. Now you can ask for help because the remote session is active:

Help New-RemADUser

The session remains active until you close the shell instance or remove the module:

Remove-Module RemAD

Reach Out and Administer Something

Implicit remoting makes it easier to use cmdlets that are only available on a remote computer. The implicitly remoted cmdlets behave pretty much the same way they would if they were installed locally. This makes them available whenever you need them. The remoting session requires little overhead on your computer or on the remote computer, so this is an extraordinarily practical way to distribute computing.

Don Jones is a founder of Concentrated Technology, and answers questions about Windows PowerShell and other technologies at ConcentratedTech.com. He’s also an author for Nexus.Realtimepublishers.com, which makes many of his books available as free electronic editions.

Email Don JonesDon Jonesis a founder of Concentrated Technology, and answers questions about Windows PowerShell and other technologies at ConcentratedTech.com. He’s also an author for Nexus.Realtimepublishers.com, which makes many of his books available as free electronic editions.