PowerShell远程管理秘籍：Don Jones & Tobias Weltner合著

需积分: 9 193 浏览量更新于2024-07-17 收藏 9.48MB PDF 举报

《2013年3月PowerShell远程管理的秘密》一书由Don Jones和Dr. Tobias Weltner合著，版权属于他们，根据Creative Commons Attribution-NoDerivs 3.0 Unported许可协议发布。这本书专注于Windows PowerShell Remoting（即PowerShell远程管理）的深度探讨，旨在解答和提供关于如何在各种场景下正确配置远程管理的权威指南。该书的初衷是针对当时大量用户对PowerShell远程管理技术的复杂问题感到困惑。作者Don Jones首先启动了这个项目，随后Dr. Tobias Weltner的加入为书籍增添了丰富的内容和改进。在整个编写过程中，PowerShell社区的许多技术专家积极参与，作为审阅者提供了宝贵意见，还提出了一些新的内容建议，使得本书成为了集体智慧的结晶。书中详尽地涵盖了PowerShell Remoting的核心概念、配置方法、网络架构、安全策略、性能优化以及常见问题解决策略。它不仅适合初学者了解远程管理的基础，也适合经验丰富的管理员深入学习和掌握如何在企业级环境中部署和管理PowerShell Remoting。如果你在阅读过程中遇到难题，可以访问官方资源http://PowerShellBooks.com和PowerShell.org的论坛，Don在那里监控并参与讨论，为你提供进一步的帮助和支持。《Secrets of PowerShell Remoting》是一本实用且全面的工具书，对于希望提升PowerShell远程管理技能的读者来说，无疑是一份不可或缺的参考资料。

Secrets of PowerShell Remoting

http://PowerShellBooks.com • http://PowerShell.org

Figure 1.5 Checking remoting connectivity from COMPANY.loc’s CLIENTA to the DCA domain controller.

Caution If you’re following along in your own test environment, don’t proceed until you’ve confirmed

Remoting connectivity between two computers in the same domain. No other scenario needs to work right

now; we’ll get to them in the upcoming sections.

Core Remoting Tasks

PowerShell provides for two principal Remoting use cases. The first, 1-to-1 Remoting, is similar in nature to the

SSH secure shell offered on UNIX and Linux systems. With it, you get a command-line prompt on a single remote

computer. The second, 1-to-Many Remoting, enables you to send a command (or a list of commands) in parallel to a

set of remote computers. There are also a couple of useful secondary techniques we’ll look at.

1-to-1 Remoting

The Enter-PSSession command connects to a remote computer and gives you a command-line prompt on that

computer. You can run whatever commands are on that computer, provided you have permission to perform that

task. Note that you are not creating an interactive logon session; your connection will be audited as a network logon,

just as if you were connecting to the computer’s C$ administrative share. PowerShell will not load or process profile

scripts on the remote computer. Any scripts that you choose to run (and this includes importing script modules) will

only work if the remote machine’s Execution Policy permits it.

Enter-PSSession –computerName DC01

Note While connected to a remote machine via Enter-PSSession, your prompt changes and displays the

name of the remote system in square brackets. If you have customized your prompt, all customizations will

be lost because the prompt is now created on the remote system and transferred back to you. All of your

interactive keyboard input is sent to the remote machine, and all results are marshaled back to you. This is

important to note because you cannot use Enter-PSSession in a script. If you did, the script would still run

on your local machine since no code was entered interactively.

Secrets of PowerShell Remoting

http://PowerShellBooks.com • http://PowerShell.org

1-to-Many Remoting

With this technique, you specify one or more computer names and a command (or a semicolon-separated list of

commands); PowerShell sends the commands, via Remoting, to the specified computers. Those computers execute

the commands, serialize the results into XML, and transmit the results back to you. Your computer deserializes the

XML back into objects, and places them in the pipeline of your PowerShell session. This is accomplished via the

Invoke-Command cmdlet.

Invoke-Command –computername DC01,CLIENT1 –scriptBlock { Get-Service }

If you have a script of commands to run, you can have Invoke-Command read it, transmit the contents to the remote

computers, and have them execute those commands.

Invoke-Command –computername DC01,CLIENT1 –filePath c:\Scripts\Task.ps1

Note that Invoke-Command will, by default, communicate with only 32 computers at once. If you specify more, the

extras will queue up, and Invoke-Command will begin processing them as it finishes the first 32. The –ThrottleLimit

parameter can raise this limit; the only cost is to your computer, which must have sufficient resources to maintain a

unique PowerShell session for each computer you’re contacting simultaneously. If you expect to receive large

amounts of data from the remote computers, available network bandwidth can be another limiting factor.

Sessions

When you run Enter-PSSession or Invoke-Command and use their –ComputerName parameter, Remoting creates a

connection (or session), does whatever you’ve asked it to, and then closes the connection (in the case of an

interactive session created with Enter-PSSession, PowerShell knows you’re done when you run Exit-PSSession).

There’s some overhead involved in that set-up and tear-down, and so PowerShell also offers the option of creating a

persistent connection – called a PSSession. You run New-PSSession to create a new, persistent session. Then, rather

than using –ComputerName with Enter-PSSession or Invoke-Command, you use their –Session parameter and pass

an existing, open PSSession object. That lets the commands re-use the persistent connection you’d previously

created.

When you use the -ComputerName parameter and work with adhoc sessions, each time you send a command to a

remote machine, there is a significant delay caused by the overhead it takes to create a new session. Since each call

to Enter-PSSession or Invoke-Command sets up a new session, you also cannot preserve state. In the example

below, the variable $test is lost in the second call:

PS> Invoke-Command –computername CLIENT1 –scriptBlock { $test = 1 }

PS> Invoke-Command –computername CLIENT1 –scriptBlock { $test }

PS>

When you use persistent sessions, on the other hand, re-connections are much faster, and since you are keeping and

reusing sessions, they will preserve state. So here, the second call to Invoke-Command will still be able to access the

variable $test that was set up in the first call

PS> $Session = New-PSSession -ComputerName CLIENT1

PS> Invoke-Command –Session $Session –scriptBlock { $test = 1 }

PS> Invoke-Command –Session $Session –scriptBlock { $test }

PS> Remove-PSSession -Session $Session

Secrets of PowerShell Remoting

http://PowerShellBooks.com • http://PowerShell.org

Various other commands exist to check the session’s status and retrieve sessions (Get-PSSession), close them

(Remove-PSSession), disconnect and reconnect them (Disconnect-PSSession and Reconnect-PSSession, which are

new in PowerShell v3), and so on. In PowerShell v3, you can also pass an open session to Get-Module and Import-

Module, enabling you to see the modules listed on a remote computer (via the opened PSSession), or to import a

module from a remote computer into your computer for implicit Remoting. Review the help on those commands to

learn more.

Note Once you use New-PSSession and create your own persistent sessions, it is your responsibility to do

housekeeping and close and dispose the session when you are done with them. Until you do that, persistent

sessions remain active, consume resources and may prevent others from connecting. By default, only 10

simultaneous connections to a remote machine are permitted. If you keep too many active sessions, you will

easily run into resource limits. This line demonstrates what happens if you try and set up too many

simultaneous sessions:

PS> 1..10 | Foreach-Object { New-PSSession -ComputerName CLIENT1 }

Remoting Returns Deserialized Data

The results you receive from a remote computer have been serialized into XML, and then deserialized on your

computer. In essence, the objects placed into your shell’s pipeline are static, detached snapshots of what was on the

remote computer at the time your command completed. These deserialized objects lack the methods of the originals

objects, and instead only offer static properties.

If you need to access methods or change properties, or in other words if you must work with the live objects, simply

make sure you do so on the remote side, before the objects get serialized and travel back to the caller. This example

uses object methods on the remote side to determine process owners which works just fine:

PS> Invoke-Command -ComputerName CLIENT1 –scriptBlock { Get-WmiObject -Class Win32_Process |

Select-Object Name, { $_.GetOwner().User } }

Once the results travel back to you, you can no longer invoke object methods because now you work with

"rehydrated" objects that are detached from the live objects and do not contain any methods anymore:

PS> Invoke-Command -ComputerName CLIENT1 –scriptBlock { Get-WmiObject -Class Win32_Process } |

Select-Object Name, { $_.GetOwner().User }

Serializing and deserializing is relatively expensive. You can optimize speed and resources by making sure that your

remote code emits only the data you really need. You could for example use Select-Object and carefully pick the

properties you want back rather than serializing and deserializing everything.

Secrets of PowerShell Remoting

http://PowerShellBooks.com • http://PowerShell.org

Accessing Remote Computers

There are really two scenarios for accessing a remote computer. The difference between those scenarios primarily

lies in the answer to one question: Can WinRM identify and authenticate the remote machine?

Obviously, the remote machine needs to know who you are, because it will be executing commands on your behalf.

But you need to know who it is, as well. This mutual authentication – e.g., you authenticate each other – is an

important security step. It means that when you type SERVER2, you’re really connecting to the real SERVER2, and

not some machine pretending to be SERVER2. Lots of folks have posted blog articles on how to disable the various

authentication checks. Doing so makes Remoting “just work” and gets rid of pesky error messages – but also shuts

off security checks and makes it possible for someone to “hijack” or “spoof” your connection and potentially capture

sensitive information – like your credentials.

Caution Keep in mind that Remoting involves delegating a credential to the remote computer. You’re doing

more than just sending a username and password (which doesn’t actually happen all of the time): you’re

giving the remote machine the ability to execute tasks as if you were standing there executing them yourself.

An imposter could do a lot of damage with that power. That is why Remoting focuses on mutual

authentication – so that imposters can’t happen.

In the easiest Remoting scenarios, you’re connecting to a machine that’s in the same AD domain as yourself, and

you’re connecting by using its real computer name, as registered with AD. AD handles the mutual authentication and

everything works. Things get harder if you need to:

•

Connect to a machine in another domain

•

Connect to machine that isn’t in a domain at all

•

Connect via a DNS alias, or via an IP address, rather than via the machine’s actual computer name as

registered with AD

In these cases, AD can’t do mutual authentication, so you have to do it yourself. You have two choices:

•

Set up the remote machine to accept HTTPS (rather than HTTP) connections, and equip it with an SSL

certificate. The SSL certificate must be issued by a Certification Authority (CA) that your machine trusts;

this enables the SSL certificate to provide the mutual authentication WinRM is after.

•

Add the remote machine’s name (whatever you’re specifying, be it a real computer name, an IP address, or a

CNAME alias) to your local computer’s WinRM TrustedHosts list. Note that this basically disables mutual

authentication: You’re allowing WinRM to connect to that one identifier (name, IP address, or whatever)

without mutual authentication. This opens the possibility for a machine to pretend to be the one you want, so

use due caution.

In both cases, you also have to specify a –Credential parameter to your Remoting command, even if you’re just

specifying the same credential that you’re using to run PowerShell. We’ll cover both cases in the next two sections.

Note Throughout this guide, we’ll use “Remoting command” to generically refer to any command that

involves setting up a Remoting connection. Those include (but are not limited to) New-PSSession, Enter-

PSSession, Invoke-Command, and so on.

Setting up an HTTPS Listener

This is one of the more complex things you can do with Remoting, and will involve running a lot of external

utilities. Sorry – that’s just the way it’s done! Right now there doesn’t seem to be an easy way to do this entirely

from within PowerShell, at least not that we’ve found. Some things, as you’ll see, could be done through

PowerShell, but are more easily done elsewhere – so that’s what I’ve done.

Your first step is to identify the host name that people will use to access your server. This is very, very important,

and it isn’t necessarily the same as the server’s actual computer name. For example, folks accessing

Secrets of PowerShell Remoting

http://PowerShellBooks.com • http://PowerShell.org

剩余85页未读，继续阅读

ViniJack

粉丝: 243
资源: 23

PowerShell远程管理秘籍：Don Jones & Tobias Weltner合著

Secrets of PowerShell Remoting.epub

The_SECRETS_OF_POWER_NEGOTIATING_－_ROGER_DAWSON2.pdf

信息安全_数据安全_Unlocking secrets of the Proxmar.pdf

_OceanofPDF.com_Smarter_Faster_Better__The_Secrets_of_Bein_-_Charles_Duhigg.pdf

信息安全_数据安全_Five_Secrets_to_Attract_and_Reta.pdf

secrets_of_javascript_closures.pdf

Python库 | find_known_secrets-1.0.30.tar.gz

信息安全_数据安全_Extracting Secrets from Locked P.pdf

AWS_Certified_Developer-Associate_Sample_Questions_v2.0_FINAL.pdf

Undocumented_Secrets_of_MATLAB_Java_Programming.part2

最新资源