转一遍文档。
How to Setup Windows PowerShell Remote v 2.0
The ability to create a remote connection is the most important difference between PowerShell v 1.0 and 2.0. However, setting up remoting for the first time, is one of the most difficult tasks in PowerShell, especially in non-domain environments. But no worries, I will lead through the steps and anticipate some of the potential problems with WinRm and TrustedHosts.
PowerShell Remoting Tutorial Topics
- Introduction to PowerShell Remote
- Our PowerShell 'Remoting' Mission
- Two Types of Remote PowerShell
- WinRm - The Pre-requisite for Remote PowerShell
- Create a PowerShell Remote Session
- Troubleshooting PowerShell Remote Problems
- Two Types of Remote PowerShell
?
Introduction to Windows PowerShell Remote
PowerShell 1.0 is easier to learn than v 2.0, largely because there are few cmdlets and certainly no ability to create a remote session. However, for those who mastered the basics of v 1.0, this inability to run scripts against another machine soon becomes a severe limitation. Furthermore, once you have a working knowledge of PowerShell, then setting up remoting is not so hard after all. It's almost as though PowerShell 2.0 has this built in hurdle, you won't be able to use remoting until your good enough to find, and then control, the TrustedHosts configuration.
In many ways my remote PowerShell tutorial reminds me of learning Telnet. Sitting at our own keyboard, yet running the wonderful PowerShell commands against another machine transforms what we can achieve in terms of configuring settings and collecting data about your network empire.
Our Mission - To Enable Remoting in PowerShell v 2.0
The crucial component for this mission to get remote PowerShell working is WinRm. If you have used a command line program such as NetSh then the techniques for configuring WinRm will be vaguely familiar.
I have divided this Remote PowerShell tutorial into four sections, this breakdown is particularly handy for troubleshooting.
- Install WinRm
- Enable PowerShell Remoting
- Set TrustedHosts *
- Create a Remote Session with PSSession
Goal - To Install the WinRm Service
The problem in explaining how to install WinRm is that each operating system has a different requirement. Windows 7 and Server 2008 R2 already have WinRm, so there is no need worry about installing this service. However, for Vista, XP and Windows Server 2008 you need to download the files from Microsoft and install WinRm. Any doubts on what your machine already has installed either check the Services mmc, or better still use PowerShell and try: Get-Service winrm.
Goal - To Enable PowerShell Remoting
Launch PowerShell v 2.0 as an administrator then try this:
Enable-PSRemoting
Note that unlike PSSession commands, this function only has one 'S' - PSRemoting. Actually, the underling cmdlet is Enable-PSSessionConfiguration. Running Enable-PSRemoting cmdlet achieves the following:
Starts the WinRM service and sets the startup type to Automatic. Enables a firewall exception for WS-Management communications. Creates a listener to accept requests on any IP address.
Guy Recommends: Free WMI Monitor for PowerShell
Windows Management Instrumentation (WMI) is one of the hidden treasures of Microsoft operating systems. Fortunately, SolarWinds have created a Free WMI Monitor so that you can discover these gems of performance information, and thus improve your PowerShell scripts. Take the guess work out of which WMI counters to use when scripting the operating system, Active Directory or Exchange Server. Give this WMI monitor a try - it's free.
Download your free copy of WMI Monitor
Goal - To Check TrustedHosts for * (All)
First let us digress and check for PowerShell 'providers'.
Get-PsProvider
The point of the other command is to show the existence of the WSMan namespace which maps to WinRm. Next we can check its config settings in general and TrustedHosts in particular.
# PowerShell Remoting
cd wsman:
cd localhost\client
dir
Note 1: Beware, plain 'cd wsman' fails, we need that colon.
Note 2: You can usually omit the line 'cd localhost\client'.
Crucial Goal - Set TrustedHosts *
The concept is straightforward; on the 'Victim' machine, the one you are connecting to, you must specify which servers are allowed to connect, these are known as the trusted hosts. Thus if you are on a server called 'BigServe', before you can remote to 'LittleComputer' you must set TrustedHosts on LittleComputer.
Important: this script will not work unless you are in the localhost\client folder of the WSMan namespace, see above instruction. This method comes into its own in non-domain situation. If you have an Active Directory domain then you can configure TrustedHosts via Group Policy.
# Remote PowerShell Set TrustedHosts
cd wsman:
set-Item TrustedHosts *
# Please remove the # from the next line
# Restart-Service winrm
Note 3: You could simplify the above command to:
Set-Item WSMan:\localhost\Client\TrustedHosts *
?
Note 4: For PowerShell to recognise the new TrustedHosts settings you need to restart the WinRm service. It's satisfying to use PowerShell itself to achieve this with:
Restart-Service winrm
Note 5: Here is a rare plural - TrustedHosts. All the PowerShell cmdlets are singular, but TrustedHosts is plural.
Note 6: If this command gives trouble, revert to DOS! Run winrm -? in a CMD box As Administrator, specifically:
winrm get winrm/config/client
or
winrm set winrm/config/client/ @{TrustedHosts="*"}
Note 7: Once the euphoria of success wears off you may want to limit * and substitute the names of servers on your network.
Note 8: Managing TrustedHosts is a classic case for employing PowerShell's 'Get' and 'Set' verbs in tandem. After you Set-Item, then you Get-Item
Final Goal - To Complete Our Mission and Create a PowerShell Remote Session
# PowerShell Remoting
# Requires -version 2.0
Enter-PSSession IpAddress or FQDM
# When you have finished remove # from:
# Exit-PSSession
Note 9: Enter-PSSession requires a fully.quallified.domain.name, for example, BigServer.domain.local Plain BigServer would NOT work, however the IP address is always good in this situation.
An alternative PSSession method:
# PowerShell PSSession
New-PSSession -computername testMachine2
Get-PSSession
# Remove # On next line if you want to delete a Session
# Get-PSSession | Remove-PSSession
Tip: If you want to test remoting but don't have a second machine, then create a 'Remote Session' to your own own machine. Explicitly, if your machine is called 'KingMachine', then try:
New-PSSession -computername KingMachine. Weird - yes, illogical - maybe, but this technique will give you a taste of PowerShell remoting.
Guy Recommends: A Free Trial of the Network Performance Monitor (NPM)
SolarWinds' Network Performance Monitor will help you discover what's happening on your network. This utility will also guide you through troubleshooting; the dashboard will indicate whether the root cause is a broken link, faulty equipment or resource overload.
Perhaps the NPM's best feature is the way it suggests solutions to network problems. Its second best feature is the ability to monitor the health of individual VMware virtual machines. If you are interested in troubleshooting, and creating network maps, then I recommend that you try Solarwinds NPM now.
Download a fully functional free trial of the Network Performance Monitor.
Where Next With PowerShell Remoting v 2.0?
With the remote pipeline in place, you are ready to run PowerShell commands as though you were at the keyboard of the second machine, indeed, this is the whole point of creating remote shells. For example,
Set-Location c:\ | Get-childitem
As my mission in this remoting tutorial is solely to get you started, now it's up to you to devise PowerShell commands to interrogate and even configure your remote computer.
Tip: If any of your remote commands don't seem to work, test them on your local computer first.
Once remoting is working then there is no barrier to employing PowerShell to manage network computers, you can now run scripts against other machines. Many cmdlets support the -computerName parameter, but remoting also enables you to use the PSSession family of cmdlets and also invoke-Command.
# PowerShell v 2.0
Enter-PSSession -ComputerName OtherMachine
Troubleshooting PowerShell Remote Problems
- One common problem is ERROR: Access is denied.
Solution: Launch PowerShell with elevated rights, in simple language: Run as administrator. - Try setting TrustedHosts * on BOTH machines, that is the machine acting as the client as well as the server to which you are trying to establish a session.
- Remember that for once this is a plural TrustedHostS.
- Remember to restart the WinRm service, otherwise changes won't take effect, try:
Restart-Service WinRm - Keep your eye on the difference between the namespace WSMan and the Windows service winrm.
- Bizarre and wacky. Try connecting using Remote Desktop. Bizarrely this may fail on the first attempt but succeed on the second attempt. Now for the good news, re-try:
Remote Connection Problem: 'Couldn't connect to remote machine'
# Problem Couldn't connect to remote machine
Get-Process : Couldn't connect to remote machine.
At line:1 char:1
+ Get-Process -computer Win7
+ ~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Get-Process], InvalidOperationException
+ FullyQualifiedErrorId : System.InvalidOperationException,Microsoft.PowerShell.Commands.GetProcessCommand
Solution: Start the Remote Registry Service
Start-Service RemoteRegistry
Wacky Solution: Try the old trick of using an IP address rather than the hostname name.
Firewalls, PowerShell and "The rpc server is unavailable"
- Security experts will hold up the hands in horror at this suggestion, but if you get the error message: "The rpc server is unavailable", then I suggest that you turn off the firewall on both machines.
- Now if that works, then great, but follow-up by testing which ports are involved (135, 445), then try configuring the firewall with exceptions that allow PowerShell remoting, but retain firewall protection from other threats.
- P.S. I have read that Enable-PSRemoting is supposed to take care of the firewall settings automatically, but in my experience this was not always the case.
- See how to disable Windows 8 firewalls with a Group Policy.
Guy Recommends: SolarWinds' Free Bulk Import Tool
Import users from a spreadsheet. Just provide a list of the users with their fields in the top row, and save as .csv file. Then launch this FREE utility and match your fields with AD's attributes, click and import the users.
Optionally, you can provide the name of the OU where the new accounts will be born. Download your FREE bulk import tool.
If you need more comprehensive application analysis software,
Download a free trial of SAM (Server & Application Monitor)
Two Types of Remote PowerShell
It's time to point out that there are two varieties of Microsoft PowerShell remoting. Firstly, the more sophisticated variation, which employs cmdlets that create a persistent pipe to the second machine. These commands contain the aptly named noun PSSession, check what's available with this cmdlet:
Get-Command -Noun PSSession.
Secondly, there is also a more basic form of remote PowerShell which merely extends local commands by appending the -computerName parameter; the result is that your instructions run against another named machine on the network. For example:
Get-Process -computerName machine2
For a list of cmdlets that support this simple remote behaviour try:
Get-Command | where { $_.parameters.keys -contains "ComputerName"}
For the full list you need to add: -and $_.parameters.keys -notContains "Session".
