PowerShell Implicit Remoting: Never Install a Module Again

Here's a scenario: You're running Windows XP on your admin workstation. You've installed PowerShell v2, and you want to use some of the cool new cmdlets that ship with Windows Server 2008 R2 - like the ActiveDirectory module. But that module won't run on XP, not even a little. So are you forced to upgrade to Windows 7? Well, that wouldn't be a bad thing - I mean, XP is so eight years ago - but you do have other options.

You'll need a Win2008R2 machine somewhere in your environment, with the ActiveDirectory module (or whatever module you're after) installed on it. Enable remoting on that computer by running Enable-PSRemoting on it. Let's say the computer's name is Win2008R2.

From your XP workstation, run this:

$s = new-pssession -computer "Win2008R2"

This establishes a remoting session to the computer. Now, tell it to load the module you want to utilize:

Invoke-Command -session $s -script { Import-Module ActiveDirectory }

Now, here's the magic part, called Implicit Remoting: Import the commands from that module into your local shell, giving them a prefix to help you remember that they're remote (the prefix bit is optional, but I like it):

Import-PSSession -session $s -module ActiveDirectory -prefix Rem

Now, so long as that session remains active, you can run the commands from that module as if they were local:

Get-RemADUser -filter * -searchbase "cn=users,dc=company,dc=pri"

Just add the "Rem" prefix to the cmdlets' noun. The command will feel like it's running locally, but in fact it'll be running on the remote server, and the results will be transmitted over the wire to your computer. When you're all done:

$s | Remove-PSSession

And the connection will close, and the cmdlets will no longer be available. This is a great trick for using modules that exist on other computers, but which cannot be installed on your workstation. In fact, someday we might live in a world where we NEVER install management tools on our workstations. Tools install on a server when you install the related role (like the ActiveDirectory module being installed when you install Active Directory Domain Services on a server). We'll just consume the management tools as a service, remotely. Someday, those modules might even register a record in DNS, so that we could just type a single command and be connected to a server that can provide us with the module we want. Wouldn't that be cool?

Want more PowerShell articles, along with FAQs and more? Visit http://windowsitpro.com/go/DonJonesPowerShell.

Discuss this Blog Entry 3

on May 30, 2010
Link is working okay for me - should go to http://www.windowsitpro.com/categories/category/Scripting/DonJonesonPowerShell.aspx.
Argus Tuft (not verified)
on May 28, 2010
Your link to http://windowsitpro.com/go/DonJonesPowerShell on page http://www.windowsitpro.com/blogs/PowerShellwithaPurpose/tabid/2248/entryid/12855/Default.aspx is broken

Cheers

jony (not verified)
on Jun 30, 2010
Hi Don, I followed your steps but still no luck.
Right now, I'm using 2 PCs, one running windows 7 and the other running windows xp. When using windows 7, I can connect to windows 2003 domain using powershell.
I tried to connect to windows 7 first on my windows xp machine, to connect to windows 2003 domain (using the steps above) but still cant connect.

The error was:

WARNING: Error initializing default drive: 'Unable to contact the server. This
may be because this server does not exist, it is currently down, or it does not
have the Active Directory Web Services running.'.

Am I missing something here?

thanks











Please or Register to post comments.

What's PowerShell with a Purpose Blog?

Don Jones demystifies Windows PowerShell.

Blog Archive

Sponsored Introduction Continue on to (or wait seconds) ×