PowerShell: Enabling PowerShell v2 Remotely

Looking for how to configure the local computer for remote management using Microsoft PowerShell?
Set-WSManQuickConfig

This command sets the required configuration to enable remote management of the local computer. By default, this command creates a WS-Management listener on HTTP.

Logo_PowerShell

Setting up the brand new PowerShell v.2 remotely in a domain environment is easy: simply run

Set-WSManQuickConfig

As long as you have proper privileges to run this command, it does everything automatically: it runs the WinRM service, sets up a PowerShell listener and a firewall exception. To play with remotely, run this on every computer you want to connect to as it is required on both ends. Then, run any command remotely like this:

Invoke-Command { Stop-Process Spooler -force -whatif } -computername test123

You should note  that remote by default requires Kerberos authentication, so it will only work in a domain environment. You learn how to configure WSMan appropriately to make it work in simple peer-to-peer environments, in another tip.

 

Here’s another Blog Post from Tobias @powershell.com

 

Test-Driving Remoting In Windows 7

 

Remoting is among one of the most popular and powerful new PowerShell V2 features. What this means is that starting with PowerShell V2 (and starting with Windows 7 only because downlevel OS will support V2 remoting only in a future update), you can connect to other PowerShell V2 machines and run commands, scripts and jobs remotely. Very cool.

Unless you work in a configured AD-Environment, setting up and test-driving remoting isn’t that easy, though. By default, in a peer-to-peer environment,  remoting is dead. I’d like to show you today in three easy steps how to set up a test peer-to-peer environment that you can use to play, show off and demo V2 remoting.

    * This will show you how to set up the "new" V2 remoting using WinRM which requires PowerShell V2 on both ends.
    * Yes, there are other remoting techniques such as the old DCOM which will continue to work and neither require WinRM nor PS V2 (for example, use Get-WMIObject -computerName 10.10.10.10 to connect to that machine using classic DCOM)

 

What you need to make it happen…

 

To play with V2 remoting in a peer-to-peer scenario, this is what you need:

Ingredients:

    * 2x Windows 7 (one of which can be running inside Windows Virtual PC if you like)
    * both machines may not be joined to a domain(!)

 

Things are turned off out-of-the-box…

 

First of all, figure out the IP addresses assigned to both machines and make sure they can reach each other via network. In this example, I will be using machine A with 192.168.2.105 and machine B with 192.168.2.107, so make sure you replace the IP addresses with yours.

If you’d like to establish a remote connection from machine A to machine B, you would use Enter-PSSession, but if you try like this:

Enter-PSSession 192.168.2.107

the cmdlet will bark at you and come up with all kinds of reasons in red letters stating why what you are trying to do is absolutely ridiculous.

The simple fact is: the mechanism behind remoting which is called WinRM has not yet been set up to accept a remoting connection nor is it likely that the WinRM service is running at all yet. WinRM is secure by default, so you need to start it and open doors manually. What it also means is that you and only you will be liable if things go wrong and you trash your corporate infrastructure. So to prevent this from becoming a career-limiting move, you should set up a separate test environment to play with.

 

Step 1: Enable WinRM on both machines

The first thing you want to do is call Set-WSManQuickConfig. This is actually your door-opener, and to successfully launch this command, you will need to (a) have admin privs and (b) be sure you do want to open the doors. Specifically, the command does the following:

    * It makes sure the WinRM service is running and sets the startmode to Automatic so WinRM will be started automatically in the future. This enabled the computer to be connected via WinRM
    * It sets up a WinRM "listener" which is listening to incoming WinRM requests via http: from any IP address
    * It sets up a firewall exception so incoming WinRM requests aren’t rejected by your firewall any longer and make it to the WinRM service

As you can see, these really are door-openers, and unless you are working with a test system  in your closet, you may want to find out more about the possible security implications. Note also that Set-WSManQuickConfig might return an Access Denied if you try and run it on a machine that is domain-joined. Everything you read here applies to a simple peer-to-peer scenario only. Domain-joined machines are a different ballgame because they use Kerberos to securely authenticate requests and chances are in a domain-based environment you do not need all of this anyway because your IT department has decided for you.

Once you ran Set-WSManQuickConfig on both machines, your Enter-PSSession command still fails because again, for security reasons, WinRM rejects requests unless they are guarded by Kerberos or an equally safe mechanism. However, if you did everything right, both machines can now at least use WinRM to talk to each other:

Test-WSMan 192.168.2.107

This should return some protocol information.

 

Step 2: Add Computers to TrustedHosts list

 

Next, since you are working in a basic peer-to-peer environment, you need to convince WinRM that it is actually safe to accept requests from the other machine. You do this by adding the machine IPs to the list of so called "trusted hosts" – or, if you want to open the door even more, simply add a "*" to that list and allow any IP to talk to the machine. So on both machines, execute this:

Set-Item WSMan:\localhost\client\trustedhosts * –force

Step 3: Enjoy!

 

Once you did this last step, you are up and running. When you now enter

Enter-PSSession 192.168.2.107

after a couple of seconds of finger crossing (while WinRM sets up the remote PS session), you see the PS prompt of the remote system and now can work remotely on  that machine. Everything is working fine now, and you can also explore all the other fine remoting features. Dunno which remoting features there are? Hang in, we’ll be back shortly with more examples!

Oh, by the way, this will only work if you have created the same user account with the same password on both machines (remember, we are in a peer-to-peer environment here). Of course, the user on machine A initiating the connection needs to have admin privs on the target machine. To authenticate as someone else, use -credential (Get-Credential) as parameter.

ff you are wondering how to leave the remoting session you just opened, simply type:

exit-pssession

 

Links

 

Set-WSManQuickConfig on Microsoft Technet

Test Driving Remoting in Windows 7

Leave a Reply

Your email address will not be published. Required fields are marked *