Active Directory cmdlets and Implicit Remoting
1
PEOPLE
I've worked out what may be one of the coolest and most useful things about PowerShell v2.
First, some background: You may be aware that Win7 and Win2008R2 can use a new ActiveDirectory module, which includes cmdlets for managing AD. These cmdlets are pretty cool and pretty effective. However, the cmdlets ONLY run on Win7 or Win2008R2.
The cmdlets can manage any domain controller running Win2008R2, Win2008RTM, or Win2003; Win2008RTM and Win2003 need a free Management Gateway Service installed, but you DO NOT need any Win2008R2 domain controllers in your environment.
Of course, you can get Windows PowerShell v2 for WinXP, Win2008RTM, Win2003, and Vista, but having PowerShell v2 still doesn't necessarily mean you can run the AD cmdlets. Or does it?
Do this: Get at least one Win7 or Win2008R2 machine in your environment. Win7 will need the remote administration pack, because that contains the AD cmdlets. Set up WinRM and Windows Remote Shell - you can do this via Group Policy, or by running Set-WSManQuickConfig on the Win7 or Win2008R2 computer. Finally, get Windows PowerShell v2 running on an older version of Windows - WinXP or Vista, for example. Launch Windows PowerShell v2 on the older machine - this will be your "client." The Win7 or Win2008R2 machine, where the AD cmdlets exist (in c:\windows\system32\windowspowershell\v1.0\modules) is the "remote machine."
On your client, run:
$session - new-pssession -computername remote-machine-name
This creates a remote shell session and saves it in the $session variable. Next, run this on your client:
invoke-command -command { import-module activedirectory } -session $session
This tells the remote machine to load the ActiveDirectory module into its runspace. Then, again on your client:
export-pssession -session $session -commandname *-AD* -outputmodule RemoteADCommands - allowclobber
This creates a module named RemoteADCommands in /Documents/WindowsPowerShell/Modules, on your local client. The above steps only need to be done once. From now one, whenever you open the shell on your client, just run:
import-module RemoteADCommands -prefix Rem
This will make all of the AD cmdlets from the remote machine available on your local machine. Now, the commands will NOT execute locally - although it looks like they're doing so. You haven't "installed" the cmdlets locally; you've created "pointers" to the cmdlets on the remote machine. To help distinguish them, the "Rem" (for "Remote") prefix has been added to the cmdlets' noun. So now instead of:
New-ADUser
You would run - on your client:
New-RemADUser
Once you run the first command, your local shell will re-establish the remote session. At that point, you'll be able to ask for help on the remote commands:
Help New-RemADUser
This is a crazy powerful technique. It means you can literally reach out and run commands that don't - or even can't - exist on your local computer, so long as you have at least one computer in your environment that CAN host the cmdlets, and so long as you have configured PowerShell remoting.
Tagged with:
activedirectory ad administration environment free implicit powershell remote remoting vista win7Replies
Very slick although it seems that when I import the module and the implicit remoting starts, the AD module still needs to get loaded on the remote host. It doesn't seem like the exported session handles that piece. When I start a new PowerShell session locally. load the module and try to run a command I get an error about an unrecognized command.
Also, the Invoke-Command parameter should be -ScriptBlock instead of -command.







