Windows PowerShell实战指南（第3版）

版权信息

书名：Windows PowerShell实战指南（第3版）

ISBN：978-7-115-47098-0

本书由人民邮电出版社发行数字版。版权所有，侵权必究。

您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。

我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。

如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。

•　著　　　　[美] Don Jones Jeffery Hicks

　 译　　　　宋沄剑

　 责任编辑　王峰松

•　人民邮电出版社出版发行　　北京市丰台区成寿寺路11号

　 邮编　100164 　电子邮件　315@ptpress.com.cn

　 网址　http://www.ptpress.com.cn

•　读者服务热线：(010)81055410

　 反盗版热线：(010)81055315

版权声明

Original English language edition, entitled Learn Windows PowerShell in a Month of Lunches, 3rd Edition by Don Jones & Jeffery Hicks, published by Manning Publications, USA. Copyright © 2017 by Manning Publications. Simplified Chinese-language edition, Copyright © 2017 by Posts & Telecom Press. All rights reserved.

本书中文简体字版由Manning Publications 授权人民邮电出版社独家出版。未经出版者书面许可，不得 以任何方式复制或抄袭本书内容。 版权所有，侵权必究。

内容提要

PowerShell已经是一门开源、跨平台的脚本语言与管理Shell。在DevOps流行的今天，PowerShell无疑是最好的实现语言之一。本书几乎涵盖了PowerShell所涉及技术的方方面面，提供了大量实战案例，同时还包含了PowerShell v5最新功能的内容。只需要一个月、每天一小时，读者就能够轻松掌握PowerShell的实战技能。本书作者是PowerShell界泰斗Don Jones与Jeffery Hicks。他们都是多年的PowerShell MVP，并以简洁、易入门的培训与写作风格而著称。

序言

我们已经从事PowerShell教学和写作很长时间。当Don Jones开始规划本书的第1版时，他意识到大多数PowerShell作者和讲师——包括他自己——会强迫学生将Shell作为一门编程语言学习。大多数PowerShell书籍都会通过第3章或者第4章进入“脚本”主题，而现在越来越多的PowerShell学习者对面向编程的学习方法避之不及。这些学生只是想将Shell作为Shell使用，至少在一开始是这样的。我们只是希望提供符合该要求的学习体验。

所以Don Jones希望尝试这种方法。通过在Windows IT Pro网站发布本书的目录，来自博客读者的大量反馈最终让本书更好地出版。他希望每一章短小、目的明确且短时间内就可以掌握——他知道管理员们并没有多少闲暇时间，通常他们都是在需要的时候才会去学习。当PowerShell v3发布后，这明显是更新本书的最好时机。Don Jones最终找到他的长期合作伙伴Jeffery Hicks共同完成本书。

我们希望本书专注于PowerShell本身，而不是大量PowerShell可以应用到的诸如Exchange Server、SQL Server、System Center等技术。我们认为只要学会正确使用Shell，你就可以通过自学掌握所有这些可以通过PowerShell操作的服务器级别产品。所以本书重点是使用PowerShell所需的核心技能。即使你还使用了“cookbook”风格的书（该类书中为特定管理任务提供了直接可以上手使用的答案），本书也可以帮助你理解那些书中实例的原理。对例子的理解能够帮助你更容易修改这些示例，从而完成其他任务，最终你可以从无到有构建你自己的命令。

我们希望本书不是你学习PowerShell的唯一工具。我们还共同编著了Learn PowerShell Toolmaking in a Month of Lunches。该书同样以一天一次的学习方式提供了学习PowerShell脚本以及工具制作的能力。你还能够找到我们在YouTube上录制的视频，并阅读我们为Petri IT知识库与Windows IT Pro等网站撰写的文章，以及我们在Pluralsight上的课程。

如果你还需要其他额外帮助，我们希望你登录www.PowerShell.org。我们在该网站的多个讨论组中回答问题。我们会非常高兴在你被任何问题难住时来帮助你。该网站还是强大、活跃的PowerShell社区入口——你可以找到免费的电子书、线下的PowerShell与DevOps峰会，以及一年中各个区域及本地用户组举行的PowerShell相关的活动。请参与这些社区——这会使得PowerShell成为你的职业生涯中强大的一部分。

请享受本书——在学习使用Shell的过程中祝你好运！

前言

关于本书中大多数你所需知道的内容都在第1章中进行描述，但有一些事需要提前告知。

首先，如果你计划跟随我们的示例并完成动手实验，你需要一台运行Windows 8.1或Windows Server 2012以及更新版本的计算机或虚拟机。我们在第1章中进行了更详细的阐述。你也可以在Windows 7上运行这些示例，但在动手实验中有一些知识点无法进行实验。

其次，请准备好从头到尾，按照章节先后顺序阅读本书。同样，我们在第1章中会进行详细解释，但背后的思想是每一章都会介绍一些新的内容，这些内容都会在下一章中被用到。请不要尝试一次性完成对整本书的阅读——请坚持每天一章的方式。人的大脑一次只能理解有限的信息，通过将PowerShell分解为小的片段，你实际上可以更快、更彻底地学习PowerShell。

再次，本书包含大量的代码段。大多数代码段较短，因此你可以很容易地输入这些代码。实际上，我们推荐你手工输入一遍代码，这样做可以巩固核心PowerShell技能：准确地输入！较长的代码段也同样在代码清单中或通过网站https://www.manning.com/ books/learn-windows-powershell-in-a-month-of-lunches-third-edition进行下载。

也就是说，还有一些需要注意的惯例。代码总是以特殊字体进行显示，例子如下。

Get-WmiObject –class Win32_OperatingSystem
➥ –computerName SERVER-R2

本示例还描述了在本书中使用的行继续符。这意味着这两行在PowerShell中实际上是作为一行进行输入。换句话说，不要在Win32_OperationSystem后按回车键或返回键，而是在该语句右侧继续进行输入。PowerShell允许较长的行，但本书的纸张大小却不能容纳那么长的代码。

有时，你还能在本书中看到代码字体，如当我们写Get-Command时。这只是为了让你知道你正在查看的是一个命令、参数或其他你将会在Shell中输入的元素。

然后是一个我们在很多章节使用的有点让人难以琢磨的主题：重音符（ `）。下面是示例：

Invoke-Command –scriptblock { Dir } `
-computerName SERVER-R2,localhost

该字符在第一行的最后，它并不是洒出来的墨水，而是你需要输入的实际符号。在美式键盘中，重音符（或者称为沉音符）通常位于键盘的左上部分，在Esc键下面，和波浪号（~）位于同一个键位。当你在代码清单中看到重音符时，请按照原样输入它。此外，当该字符出现于行尾时，正如之前示例所示，请确保该字符是行的最后一个字符。如果在该字符之后又存在任何空格或Tab符号，重音符则无法正常生效。在本书代码段的重音符之后不会存在空格或者Tab符号。

最后，我们将会偶尔将你导向到Internet资源上。这些URL会很长并难以输入。我们会将这些URL替换为基于Manning出版社的短链接，看上去就像http://mng.bz/S085（你会在第1章中看到该链接）。

作者在线

购买本书还包含了访问由Manning出版社运营的专用论坛。在该论坛中，你可以对本书进行评价、提出技术问题并得到作者和其他用户的帮助。通过浏览https://www. manning.com/books/learn-windows-powershell-in-a-month-of-lunches-third-edition并单击Book Forum链接来访问和订阅论坛。该页面提供了在注册后如何访问论坛的信息，以及可以得到的帮助的类型与论坛行为规范。

Manning出版社对读者的承诺是提供一个交流的场所。在该场所，读者和读者以及读者和作者之间可以进行有价值的对话。但并不承诺作者需要花多少时间在论坛中，作者参与论坛都是志愿的（且不收报酬）。我们建议你尝试问作者一些有挑战性的问题，从而使他们保持兴趣。

作者在线论坛以及之前讨论内容的存档，在本书出版时，就可以通过Manning出版社的网站进行访问。

作者简介

由于Don Jones在Windows PowerShell方面的工作，他多年连续获得微软公司最有价值专家（MVP）奖项。他为微软TechNet杂志写过5年Windows PowerShell专栏，现在的博客位于PowerShell.org。他还负责“Decision Maker”专栏，并为Redmond杂志写博客。Don Jones是一名多产的技术作者，自2001年以来出版了超过12本书。他现在是Pluralsight（一个在线视频培训平台）IT运维内容的课程总监。Don Jones使用的第一个Windows脚本语言是KiXtart，该语言可追溯至20世纪90年代中期。很快他就在1995年转而使用VBScript。他还是最早期使用微软代码名称为“Monad”产品—该产品后来成为Windows PowerShell的IT专家之一。Don Jones住在拉斯维加斯，当这里的天气太热时，会去位于犹他州的Duck Creek度假村。

Jeffery Hicks是一个微软认证讲师以及拥有25年经验的“IT老兵”，大多数精力花在微软服务器技术的咨询上，并强调自动化与效率。他还是多年微软PowerShell方向MVP奖项的获得者。现在他作为独立作者、培训师、顾问，为全世界的客户提供服务。Jeffery已经为多个在线站点与杂志撰写大量文章，他还是Petri IT知识库的编辑以及Pluralsight的作者。他还频繁作为演讲嘉宾出席技术大会以及用户组线下活动，你可以在Jeffery的博客http://jdhitsolutions.com/blog以及他的Twitter（@JeffHicks） 中查看他的最新状态。

译者简介

宋沄剑，微软Data Platform MVP，数据库大会、TechED、Ignite特约讲师，精通SQL Server与MySQL，并擅长使用PowerShell与Python编写自动化运维工具。他目前就职于易车网，负责开源大数据平台基础架构的构建与自动化运维工作。同时，他还经常兼职帮助客户设计数据平台架构、私有云架构、数据库调优以及解决大型生产环境中的棘手问题。大家可以在他的个人技术博客http://www.cnblogs.com/careyson看到他的最新动态。

致谢

书当然不会自行书写、编辑和出版。Don Jones希望感谢在Manning出版社那些决定在PowerShell不同种类书籍都碰碰运气的所有人，以及那些努力帮助完成本书的人。Jeffery希望感谢Don Jones邀请他参与完成本书，并感谢所有的PowerShell社区的激情与支持。Don Jones和Jeffery都对Manning出版社让他们继续本书第3版心怀感激。

也感谢所有在书写阶段阅读手稿并参与审阅的同仁——Bennett Scharf、Dave Pawson、David Moravec、Keith Hill、Rajesh Attaluri，还有Erika Bricker、Gerald Mack、Henry Phillips、Hugo Durana、Joseph Tingsanchali、Noreen Dertinger、Olivier Deveault、Stefan Hellweger、Steven Presley以及Tiklu Ganguly提供的宝贵建议。

最后，还要感谢James Berkenbile与Trent Whiteley在本书写作过程中对手稿和代码的技术审阅。

第1章 背景介绍

自从2006年Windows PowerShell（第1版）面世以来，我们就一直在致力于对该技术进行教学推广。那时候，PowerShell的大部分使用者都是长期使用VBScript的用户，而且他们也非常期待能以VBScript作为基础学习PowerShell。于是，开展培训以及编写PowerShell书籍的作者都采用了一种和其他编程语言教学一样的方式来教学PowerShell。

但是从2009年开始发生了一些改变。越来越多没有VBScript经验的人开始学习PowerShell这门语言。因为之前我们主要关注于脚本的编写，所以对PowerShell的教学不再那么卓有成效。也就是在那个时候，我们意识到PowerShell并不仅仅是一门脚本语言，其实是一种运行命令行工具的命令行Shell。和其他优秀的Shell一样，虽然PowerShell可以通过脚本实现很复杂的功能，但脚本仅是使用PowerShell的一种方式，因此学习PowerShell并不一定需要从脚本开始。之后，我们在每年的技术演讲会议上逐渐改变了我们的教学方式，同时也将这些教学方式的变化体现在我们的教学课程中。最后，我们出版了这本书，这也是我们想出的针对非编程背景的人员教学PowerShell的最好方式。但是在开始学习之前，我们需要了解一下背景。

1.1　为什么要重视PowerShell

从Batch、KiXtart、VBScript到现在，可以看到Windows PowerShell并不是微软（或者其他公司）首次为Windows管理员提供自动化管理的工具。我们认为，有必要让你们了解为什么需要关注PowerShell这个工具。因为当你们这样做的时候，会发现花费一定的时间去学习PowerShell是值得的。想象一下，在没有使用PowerShell之前我们的工作是怎样的？在使用该工具后又有哪些变化？

1.1.1　没有PowerShell

Windows操作系统管理员总是喜欢通过单击用户图形化界面去完成他们的工作。用户图形化界面（GUI）是Windows操作系统的最大特点——毕竟这个操作系统的名字并不是“Text”。因为GUI总是让我们很轻易找到我们能做的一切，所以它是那么强大。作者仍然记得第一次展开活动目录下的用户和计算机的场景。通过单击各种按钮、阅读工具栏提示信息、选择下拉菜单、右键单击某些图标来查看用户与计算机中的各项功能。GUI是使得我们能够更容易学习的一种工具。但是不幸地是，GUI并不能带来任何效率提升上的回报。如你花费5分钟在活动目录中创建一个新的用户（合理地设想一下，需要填写大量的信息），之后再新建用户时，也不会更快。那么新建100个新用户就会花费500分钟来完成——没有其他任何办法使得我们输入信息以及单击操作更快，从而加快该过程。

微软之前也尝试去解决该问题，VBScript可能算是其中最成功的一次尝试。你可能需要花费一小时编写一条VBScript语句将CSV文件中的新用户导入到活动目录中，但在此之后你可能只需要花费几秒钟就可以完成同样的工作。VBScript的问题在于微软没有全心全意地对其提供支持，微软需要确保各种对象都可以通过VBScript访问、调用，而如果开发人员因为时间的原因或者是忘记这块知识，那么你就只能卡在那儿了。例如，想通过VBScript修改网卡IP，没问题。但是，想检查网络连接的速度，那就不行了，因为没人记得可以把这个功能设置为VBScript可访问的形式。这也算是一种遗憾。Jeffery Snover，Windows PowerShell的架构师，称之为“最后一英里”。你可以通过VBScript（或者其他类似的技术）来做很多事情，但是在某些时刻总会让人失望，从来不会让我们顺利通过“最后一英里”完成之后的工作。

Windows PowerShell正是微软公司试图改善这一缺陷的尝试，让你顺利通过“最后一英里”，进而完成工作。目前来看，该尝试非常成功。微软的多个产品组都采用了PowerShell，第三方生态系统扩展也是基于PowerShell，并且全球的社区专家与爱好者也都帮助PowerShell变得越来越好。

1.1.2　拥有PowerShell

微软对Windows PowerShell的定位是我们可以通过该Shell管理Windows系统中的所有功能。微软仍然继续开发GUI的控制台，但是底层运行的仍然是PowerShell命令。通过这种方式，微软保证我们可以在该Shell中完成Windows系统中任意的工作。如果需要自动化一个重复性的任务或者完成在GUI中不支持的工作，那么你可以使用该Shell来达成所愿。

很多微软的产品都已经采用了这种开发方法，如Exchange Server 2007以及之后版本、Sharepoint Server 2010以及之后版本、大部分System Center产品、Office 365以及Windows系统中大量的组件。接下来，越来越多的产品和Windows系统中组件会采用这个Shell。Windows Server 2012（首次引入PowerShell V3）甚至可以完全通过PowerShell或者使用基于PowerShell的GUI工具来进行管理。这也就是为什么我们要重视PowerShell。在接下来的几年，PowerShell会成为越来越多的管理功能的底层实现。PowerShell已经成为大量高层技术的基础，包括Desired State Configuration（DSC），PowerShell Workflow以及更多。PowerShell无处不在！

此时，我们仔细想想：如果你正在管理一个拥有很多IT工程师的团队，你希望谁的职级更高，希望谁能拿更多的薪水，是每次都要花费几分钟使用GUI来完成一个任务的人，还是一个可以通过脚本花费几秒钟自动化完成的人？无论你是来自哪个领域的IT从业人员，我们都知道应该如何选择。询问一个思科的管理员、AS/400的操作员或者Unix管理员，他们都会回答“我更希望选择可以借助命令行更有效率地完成工作的人员”。以后的Windows系统工程师可以简单分为两类，一部分会使用PowerShell，另一部分则不会。正如Don在微软2010TechEd会议上著名的言论：我们的选择是“学习PowerShell”，还是“来包炸薯条”？

我们很欣慰，你已经决定学习PowerShell。

1.2　现在只剩下“PowerShell”，而不是“Windows PowerShell”

在2016年中期，微软迈出了在此之前不敢想象的一步，那就是完整开源了Windows PowerShell。同时，还发布了非Windows版本的PowerShell，包含macOS与大量Linux发行版。太棒了！现在，这个面向对象的Shell在多种操作系统上可用，并且可以被世界范围内的社区共同提升。对本书的第3版来讲，我们决定确保主要所讲述的PowerShell不仅仅是基于Windows平台。我们认为PowerShell最大的受众是Windows用户，但我们也希望确保你能够理解PowerShell是如何在其他操作系统上工作的。

1.3　本书适用读者

这本书并不是适合所有人。实际上，微软PowerShell团队已经定义了三类适用PowerShell的人群：

• 主要使用命令行以及采用第三方开发工具的管理员；
• 能将命令行和工具集成为一个更复杂的工具（之后那些缺乏经验的成员可以立即使用该工具完成相关工作）的管理员；
• 开发可重复使用的工具或者程序的管理员或者开发人员。

本书主要是针对第一类人编写的。所有人，即使是开发人员在内的所有人，也有必要理解如何使用Shell运行命令。毕竟，如果你正准备去开发一个工具或者编写一些命令，那么你应该知道这个Shell的运行机制，这样可以确保开发出来的工具或者命令能像在Shell中运行得那么顺畅。

使用你有兴趣通过创建脚本自动化复杂的流程，比如新建一个用户，在学习完本书后，你可以学习到如何实现该功能，甚至可以编写自己的脚本，并且该脚本可以让其他管理员使用。但是本书并不会深入地讲解PowerShell的每项功能。我们的宗旨是让你能够使用Shell，并立即应用到生产环境。

我们也会使用多种方法来演示如何将PowerShell关联到其他的管理工具。在后续章节中，我们会以WMI（Windows Management Instrumentation）以及常用的命令作为示例。大体上，我们仅会介绍PowerShell可以与哪些技术进行关联，并讲解它们之间如何进行关联。其实，这些主题甚至都可以单独出书介绍（我们会在本书适当的地方给出对应的建议）。在本书中，我们仅仅介绍与PowerShell相关的部分。如果你对更深入地学习这部分技术感兴趣，我们将会提供针对后续学习的建议。简而言之，本书并不是你学习PowerShell所用的最后一本书，本书的定位是第一本PowerShell入门书。

1.4　如何使用本书

本书的理念是每天完成一章的学习。我们不需要在用餐时间阅读本书，因为我们只需要接近40分钟就可以完成对一章的阅读，之后再花20分钟去享用剩余的三明治以及进行对应的练习。

1.4.1　主要章节

第2～25章为本书的主要内容，算下来差不多只要花费24顿午餐的时间完成阅读。这也就意味着你可以预期在一个月内完成对本书主要章节的阅读。你需要尽可能严格地遵守该学习计划，不要感觉需要一天内阅读其他额外章节。更为重要的是，我们需要花费一定的时间完成每个章节之后的练习题，用以巩固学习成果。当然，并不是每个章节都需要花费完整的一小时，所以有时你在上班之前有更多的时间进行练习（或者吃午餐）。我们发现很多人坚持每天只学习一章会学得更快，这是因为这使得你可以有更多的时间动脑思考新主意，以及更多的时间进行练习。请不要揠苗助长，你会发现自己的学习进度会比想象得更快。

1.4.2　动手实验

在主要章节的结尾都布置了需要完成的实验题目。我们会给你对应的说明，甚至可能是一两个提示。这些动手实验的答案，我们会放在每章节的末尾，但是建议你在查看这些答案之前尽力独立完成这部分实验。

1.4.3　代码示例

贯穿全书你会遇到代码清单。有一些比较长的PowerShell示例。但无需手动输入。如果你查看www.manning.com并找到本书的页面，就会找到本书所有代码的下载链接了。

1.4.4　进一步学习

Don的YouTube频道，YouTube.com/PowerShellDon，包含大量为本书的第一版制作的免费视频——现在仍然是100%适用。这种方式是获得一些短小、快速入门demo的捷径。他还是一些工作室的视频主播，这些视频都值得一看。我们还建议登入PowerShell.org频道，YouTube.com/powershellorg，这里包含了大量的视频内容。你会　 发现大量来自PowerShell + DevOps全球峰会、在线社区研讨会以及其他活动的视频，全部免费！

Jeff为Petro IT知识库（www.petri.com）撰写过大量的文章，这里你可以发现大量的内容，涵盖PowerShell的各方面主题。你还可以在Jeff的Youtube频道：http://YouTube. com/jdhitsolutions发现他的最新动态。

1.4.5　补充说明

在学习PowerShell的时候，有些时候我们可能会钻入死胡同，去研究为什么会这样或那样运行。如果这样学习，我们就不会学到很多实用的技能，但我们会对这个Shell到底是什么及其工作原理有更深入的了解。我们在“补充说明”章节中会提供这方面的信息。这些信息只需要花费几分钟就可以读完。如果你是那种喜欢钻研原理部分的人，这部分信息也可以提供一些有用的材料。如果你觉得该小节会使得你分心而不能很好地完成实践学习，那么你可以在首次阅读时忽略该小节。当然，如果你掌握了所有章节部分的主要内容，建议再返回阅读这部分。

1.5　搭建自己的实验环境

在本书的学习过程中，你会进行大量的PowerShell的动手实验，那么你必须构建一个属于你自己的实验环境（请记住，不要在公司的生产环境中进行测试）。

你需要在带有PowerShell v3或更新版本的Windows中运行本书中大部分示例以及完成每章节的动手实验。我们建议的环境是Windows 8.1或更新版本，或者是Windows Server 2012 R2或更新版本，这两个版本都带有PowerShell v4。但是需要注意的是，某些版本（如简易版）的操作系统中可能不存在PowerShell。如果你对PowerShell学习抱有很大的兴趣，那么你必须找到一个带有PowerShell的Windows系统。同时，有些动手实验是基于Windows 8 或者Windows Server 2012中PowerShell的新特性才能完成的。如果你使用的是老版本的操作系统，那么最终结果可能会有不同。在每个动手实验开始时，我们都会特别说明你需要在什么操作系统中去完成这部分实践。

在本书中，我们都是以64位（x64）操作系统为环境进行学习的。我们知道有两个版本：Windows PowerShell以及特定版本的图形化Windows PowerShell 集成脚本环境（ISE）。在开始菜单（Windows 8中是“开始”界面），这两个组件的64位版本显示为“Windows PowerShell”和“Windows PowerShell ISE”。32位版本的在快捷方式中会显示“x86”字样。在使用x86版本PowerShell时，在窗口栏中也会看到x86字样。如果操作系统本身就是32位的，那么你只能安装32位的PowerShell，并且不会显示x86字样。

本书中的示例基于64位版本的PowerShell和对应的ISE。如果你并不是使用的64位环境，那么有些时候运行示例时可能和我们得出的结果不一致，甚至某些动手实验部分根本无法正常进行。32位版本的PowerShell主要是针对向后兼容性。例如，一些Shell扩展程序只存在于32位PowerShell中，并且也只能导入到32位（或者x86）的Shell中。除非你确实需要使用这部分扩展程序，否则我们建议你在64位操作系统上使用64位的PowerShell。微软后续主要的精力会放在64位PowerShell上；如果你现在因为使用的32位操作系统而无法进行下去，那么很遗憾，以后仍然会无法继续进行。

提示：

　

我们完全可以在一个独立操作系统的PowerShell环境中完成本书的所有学习。但是如果使用同一个域的两台或者三台计算机的PowerShell环境联合起来进行测试，那么某些动手实验可能会变得更有趣。在本书中，我们在CloudShare（CloudShare.com）上创建多个虚拟机来解决该问题。如果你对这种场景感兴趣，你可以了解一下这个服务或者其他类似的一些服务。但是需要注意，并不是在所有国家都可以访问CloudShare.com。另一种解决方案是使用Windows 8或更新版本的操作系统中的Hyper-V功能来承载几台虚拟机。

如果使用的是非Windows版本的PowerShell，你需要考虑几个选项。首先是从http://github.com/PowerShell/PowerShell的上获取适合你的操作系统（MacOS或Linux等）的发行版，然后就可以开始了。但请记住，本书示例中大量的功能只有在Windows下可用。例如，你无法获得Linux的服务列表，这是由于Linux没有服务的概念（Linux有守护进程，类似Windows的服务，但略有区别）。

1.6　安装Windows PowerShell

从Windows Server 2008、Windows Server 2008 R2、Windows 7操作系统开始，我们已经可以使用第3版的Windows PowerShell。Windows Vista操作系统无法支持第3版，但是可以使用第2版PowerShell。最近发布的几个操作系统中已经预装了Windows PowerShell。如果采用老版本的操作系统，那么必须手动安装PowerShell。PowerShell v4在Windows 7或Windows Server 2008 R2以及更新版本的操作系统上可用。虽然这些版本的Windows上并不是所有的组件都与PowerShell“关联”，这也是为什么我们推荐使用Windows 8或Windows 2012作为最低版本。当然，新版本的操作系统可能会采用更新版本的PowerShell，当然这没什么坏处。

提示：

　

你可以采用如下方法来检查安装的PowerShell版本：进入PowerShell控制台，输入$PSVersionTable，然后按回车键。如果返回错误或者输出结果并未显示为“PSVersion 4.0”，那么你安装的版本就不是PowerShell第4版。

如果你想要检查最新的PowerShell可用版本或下载PowerShell，请访问http://msdn. microsoft.com/owershell。该官方PowerShell主页有一个指向最新版本Windows管理框架（WMF）安装包的链接，该安装包用于安装PowerShell与其相关功能。再次声明，由于本书的内容是入门级，你不会发现太多v3版本之后的变更，但使用最新版PowerShell总是很有乐趣。

PowerShell包含两个应用程序组件：基于文本的标准控制台（PowerShell.exe）和集成了命令行环境的图形化界面（ISE；PowerShell_ISE.exe）。我们大部分时间都会使用基于文本的控制台。当然，如果你更喜欢ISE，也可以使用ISE。

注意：

　

PowerShell ISE组件并没有预装到Server版操作系统中。如果你需要使用，那么你需要进入Windows的功能（使用“服务器管理器”），然后手动添加ISE功能（你也可以打开PowerShell的控制台，再运行Add-WindowsFeaturePowerShell-ise）。在未包含完整GUI模式的操作系统（如Server Core或Nano Server版本的系统）对应的安装程序中并没有包含ISE的安装程序。

在你继续学习PowerShell之前，建议花几分钟设置Shell的显示界面。如果你使用基于文本的控制台，那么强烈建议你修改显示的字体为Lucida（固定宽度），不要使用默认的字体。假如使用默认字体，我们会很难去区分PowerShell使用的一些特殊字符。可以参照下面的步骤修改显示字体。

（1）右键单击控制台界面上侧边框（PowerShell字符位于控制台界面的左上方），选择目录中的属性。

（2）在弹出的会话框中，可以在几个标签页中修改字体、窗口颜色、窗口大小和位置等。

提示：

　

强烈建议窗口大小和屏幕缓冲器使用相同的宽度。

另外，需要注意的是，当应用对默认控制台的修改之后，后续所有新开的窗口都会使用变更之后的设置。当然，所有这些设置仅仅应用于Windows：在非Windows操作系统中，你通常会安装PowerShell，打开操作系统的命令行（例如，一个Bash shell），然后运行powershell。控制台窗口会控制颜色、屏幕布局等，因此请调整命令行从而满足你的需求。

1.7　联系我们

我们对帮助向你一样学习Windows PowerShell的人充满激情，我们会尽可能地提供我们所知道的资源。我们同时也期望你的反馈，因为这会帮助我们为新的资源想出新的主意，然后我们就可以把这部分资源放到网站上，这也是一种帮助我们提升本书下一版的方式。你可以在Twitter的@concentratedDon找到Don以及@JeffHicks找到Jeff。我们还经常会在http://PowerShell.org上回答问题。http://PowerShell.org也是一个寻找资源的好地方，这些资源包括免费的电子书、年度现场会议、免费的在线研讨会等。我们也为这两个地方添砖加瓦，在你完成本书之后，这两个地方是我们推荐给你继续学习PowerShell最好的地方。

1.8　赶紧使用PowerShell吧

“可以立即使用”是我们编写本书的一个主要目标。我们在每一章中尽可能仅关注某一部分的知识，并且你在学习之后，可以立即在生产环境中使用。这就意味着，在开始的时候，我们可能会避开一些细节的讨论，但是在必要时，我们承诺后续会回到这些问题并给出详细说明。在很多情形下，我们必须在首先给出20页的理论或者直接讲解并完成某些部分的学习（暂不解释、分析其中的细微差别或者详细情况）中做出选择。当需要做出这类选择时，我们总是选择第二个，以便使得你可以立即使用起来。但是之前的那些细节，我们会在另外一个时间进行分析讲解。

好了，背景知识大概就介绍到这里。下面就开始第2章课程的学习。

第2章　初识PowerShell

本章将协助读者选择一种最适合的PowerShell界面（不错，你可以做出选择）。如果你曾经使用过PowerShell，可以直接跳过本章，但是你依旧可以从本章中找到一些对你有帮助的信息。

同时，本章仅仅关注Windows版本的PowerShell，非Windows版本的PowerShell没有这么多选项，如果你使用的是非Windows版本的PowerShell，请跳过本章。

2.1　选择你的“武器”

在Windows中，微软提供了两种（如果你是很严谨的人，可以认为是4种）使用PowerShell的方式。图2.1显示了【开始】菜单中的【所有程序】界面，其中包含四种PowerShell图标。可以通过图中划线部分快速找到这些图标。

提示：

　

在旧版本的Windows中（本书环境基于Windows Server 2012），这些图标位于【开始】菜单中，可以通过依次选择【所有程序】→【附件】→【Windows PowerShell】来找到它们。除此之外，还可以在【开始】菜单中运行“PowerShell.exe”，然后单击【确认】，打开PowerShell的控制台应用程序。在Windows 8和Windows Server 2012或更新版本中，使用Windows键（通常是位于Ctrl键和Alt键之间的Windows图标）加R打开运行对话窗口，或者单击Windows键，然后在输入框中输入PowerShell，即可快速打开PowerShell图标。

在32位操作系统中，最多只有两个PowerShell图标。在64位系统中，最多有4个。它们分别是：

• Windows PowerShell——64位系统上的64位控制台和32位系统上的32位控制台。
• Windows PowerShell(x86)——64位系统上的32位控制台。
• Windows PowerShell ISE——64位系统上的64位图形化控制台和32位系统上的32位图形化控制台。
• Windows PowerShell(x86)——64位系统上的32位图形化控制台。

图2.1　你可以选择四种PowerShell启动方式的其中一种

换句话说，32位操作系统仅有32位的PowerShell应用程序，而64位操作系统可以有32位和64位两个版本的PowerShell应用程序，其中32位应用程序在图标名中会包含“x86”字样。需要注意的是，有些扩展程序只支持32位环境，不支持64位。微软现在已经把全部精力放到64位系统中，而32位仅用于向后兼容。

提示：

　

在64位系统中，人们经常会错误地打开32位应用程序，此时应该注意窗体的标题，如果显示“x86”，证明你在运行32位程序。另外，64位扩展程序不能运行在32位应用程序中，所以建议用户把64位应用程序以快捷方式的形式固定在【开始】菜单中。

2.1.1　控制台窗口

图2.2展示了PowerShell控制台窗口界面，这是大多数人第一次见到的PowerShell界面。

接下来，从使用简单的PowerShell控制台命令和参数开始本小节。

• PowerShell不支持双字节字符集，也就是说，大部分非英语语言不能很好地展示出来。
• 剪切板操作（复制和粘贴）使用的是非标准键，意味着使用起来较为不便。
• PowerShell在输入时会提供少量帮助信息（这个相对于ISE而言，在下面即将介绍），在PowerShell v5中有很大的提升。在Windows 10中，微软修改了命令行Shell，解决了一些我们提到过的长期问题，因此你的使用体验在v5中会略有不同。

图2.2　标准的PowerShell控制台窗口：PowerShell.exe

综上所述，PowerShell控制台应用程序将是你在没有安装GUI Shell的服务器上运行PowerShell的唯一选择（如Server Core与Nano Server版本，或者Windows Server中服务器GUI Shell功能被移除或未安装的情景）。其优点是：

• 控制台程序非常轻量，可以快速加载且不需要太多内存。
• 不需要任何非PowerShell自身必需的.NET Framework之外的资源。
• 可以在黑色背景中设置绿色字体，正如在20世纪70年代的机器上工作一样。

如果你打算使用控制台应用程序，在你配置时有些建议可供参考。可以通过单击窗体左上角的图标，并选择【属性】实现，如图2.3所示。在Windows 10中该窗口看上去会略有不同，因为该版本增加了一些选项，但这里提到的主旨并无不同。

在【选项】标签页，可以调大“命令记录”的缓冲区大小。这个缓冲区可以记住你在控制台输入的命令，并且通过键盘的上、下键重新调用它们。你也可以通过按F7键弹出命令列表。

在【字体】标签页，选择稍微大于默认12像素的字体。不管你是否拥有1.5的视力，稍微提高一下字体大小也没什么坏处。PowerShell需要你能快速区分相似的字符，比如’（撇号或单引号）和`（重音符）。

如果使用小像素字体，区分这类字符将比较困难。

图2.3　配置控制台应用程序的属性　

在【布局】标签页，把所有“宽度”设为相同的数值，并且确保输出结果窗体能适合你的显示屏。如果设置不合理，会导致PowerShell窗体下方出现水平滚动条。这可能导致一部分输出结果被挡住，这会导致你忽略这些输出结果。作者的学生就曾经花了半小时运行命令，他们以为没有任何输出结果，实际上输出结果被隐藏在右边。

最后，在【颜色】标签页，强烈建议不要修改，保持高度反差将有助于阅读。如果你不喜欢默认的蓝底白字，可以考虑灰底黑字的形式。

需要记住一件事：这个控制台应用程序并不是真正的PowerShell，仅仅是你和PowerShell交互的界面。控制台应用程序本身可以追溯到大约1985年，所以你不要指望能从中得到流畅的体验。

2.1.2　集成脚本环境（ISE）

图2.4展示了PowerShell 集成脚本环境，也称为ISE。

提示：

　

如果你不经意打开了标准控制台应用程序，可以输入“ise”并按回车键，从而打开ISE。

图2.4　PowerShell ISE（PowerShell_ISE.exe）　

表2.1列出了ISE的优缺点，从中可以得到大量背景信息。

表2.1　ISE的优缺点

下面从一些基本定位开始。图2.5展示了ISE的3个主要区域，图中划线部分即为ISE的工具栏。

在图2.5中，最上方的区域是【脚本编辑窗格】，直到本书最后才会用到。在它的右上角，可以看到一个蓝色的小箭头，单击它可以最小化【脚本编辑窗格】并最大化【控制台窗格】。控制台窗口是我们将要使用的地方。右边是【命令管理器】，可以通过它最右上方的“×”打开或者关闭这个窗口。除此之外，可以通过工具栏倒数第二个按钮来浮动【命令管理器】。如果你已经关闭【命令管理器】又想让它重新出现，可以单击工具栏的最后一个按钮。工具栏中的前3个按钮用于控制【脚本编辑器】和【控制台窗格】的布局。可以通过这些按钮把窗体设置为【在顶部显示脚本窗格】【在右侧显示脚本窗格】和【最大化显示脚本窗格】。

在ISE窗口的右下角，可以发现用于改变字体大小的滚动条。在【工具】菜单中，可以找到一个【选项】项用于配置定制化的颜色方案和其他显示配置——这完全根据你的喜好而定。

图2.5　ISE的3个主要区域及控制它们的工具栏　

动手实验：

　

首先我们假设读者在需要编写脚本时，将会在余下章节中只使用ISE，然后隐藏【脚本编辑窗格】。如果你愿意，也可以把【命令管理器】隐藏。把字体大小设置到你喜欢的样子。如果你不能接受默认的颜色方案，请自行选择。如果你更喜欢控制台应用程序，请放心使用，本书的绝大部分内容同样能在控制台中运行。一些仅在ISE中才能使用的功能将会额外标注。

2.2　重新认识代码输入

PowerShell是一个命令行接口，意味着你需要大量输入代码。然而输入命令就可能出现错误，例如拼写错误。幸运的是，这两种PowerShell应用程序都提供了帮助减少打错的方式。

动手实验：

　

接下来的例子在本书中可能显得不太实际，但是在本节看来却很炫。读者可以在自己的环境中尝试一下。

控制台应用程序支持4种“Tab键补全”。

• 输入“Get-S”，然后按几下Tab键，再按Shift+Tab组合键。PowerShell会循环地显示以Get-S开头的所有命令。然后不停按Shift+Tab组合键，直到出现你期望的命令为止。
• 输入“Dir”，按空格键，然后输入“C:\”，再按Tab键，PowerShell会从当前文件夹开始循环遍历所有可用的文件和文件夹名。
• 输入“Set-Execu”，按Tab键，然后输入一个空格和横杠（-），再开始按Tab键，可以看到PowerShell循环显示当前命令的所有可用参数。另外，也可以输入参数名的一部分，例如-E，然后按Tab键，开始循环匹配的参数名。按Esc键可以清空命令行。
• 再次输入“Set-Execu”，按Tab键，再按空格键，然后输入“-E”，再次按Tab键，然后按一次空格键，再按Tab键。PowerShell会循环显示关于这些参数的合法值。这个功能仅对那些已经预设了可用值（称为枚举）的参数有效。按Esc键同样可以清空命令行。

PowerShell ISE提供了类似功能，甚至可以说比“Tab键补全”功能更好的功能:智能提示。该功能在上面提到的4种场景下都能运行。图2.6演示了如何通过弹出菜单实现你在使用Tab键时完成的功能。可以使用上下箭头按钮来滚动菜单，找到你想要的选项，然后按Tab键或者按回车键选择，再继续输入剩余代码。

图2.6　在ISE中类似Tab键自动补全功能的智能提示功能　

智能提示可以在ISE的控制台窗格和脚本编辑窗格中工作。

警告：

　

当你在PowerShell中输入时，请极其小心。在某些情况下，一个错位的空格、引号或者单引号都会带来错误或者失败。如果出现了错误，请再三检查你的输入内容。

2.3　常见误区

接下来，让我们快速回顾一些会影响你享受PowerShell旅途的绊脚石。

• 在控制台应用程序中的水平滚动条——从多年的教学经验中我们得知，正如前面提到过的，配置控制台的窗口，使其不出现水平滚动条非常重要。
• 32位VS64位——建议你使用64位的Windows并使用64位的PowerShell应用程序（没有出现“x86”字样的应用程序）。虽然对于某些人来说，购买64位的计算机和64位的Windows可能是件大事，但是如果你希望PowerShell高效运行，那么这些投资还是必需的。虽然在本书中我们尽可能覆盖32位环境，但是这些内容在64位的生产环境上将带来很大的差异。
• 确保PowerShell应用程序的窗体标题显示“管理员”——如果你发现打开的窗体上没有“管理员”字样，关闭窗体并右键单击PowerShell图标，选择“以管理员身份运行”。在生产环境中，不一定总是要这样。本书后面将演示如何使用特定的凭据运行命令。但是通常情况下，为了避免运行时出现一些问题，最好确保以管理员身份运行PowerShell。

2.4　如何查看当前版本

在很大程度上，找出当前使用的PowerShell版本不是件容易的事，因为每个发布版本都安装在“1.0”的目录下面（1.0是引用的Shell引擎语言版本，即所有版本都向后兼容到v1）。针对PowerShell v3或更新版本，有一种简单的方式检查版本。输入“$PSVersionTable”并按回车键。

PS C:\> $PSVersionTable 
Name                           Value
----                           ----
PSVersion                      3.0
WSManStackVersion              3.0
SerializationVersion           1.1.0.1
CLRVersion                     4.0.30319.17379
BuildVersion                   6.2.8250.0
PSCompatibleVersions           {1.0, 2.0, 3.0}
PSRemotingProtocolVersion      2.2

可以看到每个PowerShell相关技术的版本号，包括PowerShell自身的版本号。如果命令不能运行，或者显示最少需要PSVersion 3.0等字样，则需要使用第1章中展示的方式安装最新版本的PowerShell。

动手实验：

　

现在就开始使用PowerShell，首先检查你的PowerShell版本是否满足最低的3.0版本，如果不是，请先至少升级到v3版本。

PowerShell v3（以及更新版本）可以与v2同时安装。实际上，你可以通过命令PowerShell.exe–version 2.0显式指定运行v2版本。你可以在代码与v3版本不兼容时（非常罕见）运行v2版本。PowerShell v3的安装包并不会自动安装v2。只有在v2已经安装的情况下才能运行v2。如果已经安装了v1，v2与v3的安装包会覆盖v1；它们不能同时并存。同时，诸如v4等新版本也可以在v2模式下运行，但没有任何其他模式。因此v4无法以v3模式运行。

提示：

　

新版本的Windows默认会安装新版的PowerShell，但可能会包含PowerShell v2引擎。如果需要，可以在PowerShell中运行Add-WindowsFeature powershell–v2来安装v2引擎。如果powershell v2功能在你的Windows版本中不可用，那就无法再安装v2，但通常来讲，此时你也不会再需要v2。

2.5　动手实验

因为这是本书第一个实验，所以我们会花一些时间去描述该机制。对于后续的每个实验，我们会给出一些任务，以便你可以自己动手尝试和完成。一般我们只给出一些提示或者方向性指引。所以从现在开始，你只能靠自己了。

我们保证所有需要用于完成实验的知识仅限于当前章节或之前的章节（对于之前章节的知识，我们一般采用提示的方式给出）。我们不会把答案说得太明显，更多地，当前章节会告诉你如何发现你所需要的信息，你需要自己去发现这些问题的答案。虽然看起来有点让人沮丧，但强迫自己去完成，从长远来说绝对可以让你在PowerShell的世界里面走得更远。

顺带提醒，你可以在每章的末尾中找到示例答案。这些答案不一定完全匹配你的问题，但是当我们一步一步地深入之后，答案将变得越来越准确。实际上，我们会发现PowerShell针对几乎所有的问题都能提供几种甚至更多的解决方式。我们会尽可能地使用最常用的方式，但是如果你尝试使用另外一些不同的方式，并不代表你是错误的。任何能实现结果的方式都是正确的。

注意：

　

本实验需要PowerShell v3或以上版本。

我们从简单的例子开始：希望你能从控制台和ISE的配置中实现相同的结果。然后按照下面五步进行。

（1）选择适合你自己的字体和颜色。

（2）确保控制台应用程序下方没有水平滚动条。（本章中已经第三次提到，可见其　 重要性。）

（3）在ISE中，最大化控制台窗格，移除或最小化命令管理器。

（4）在所有应用程序中，输入一个单引号（'）和一个重音符（`），确保你可以轻易区分它们。在美式键盘中，重音符位于左上角，在“Esc”键下面，和波浪号（~）位于同一个键中。

（5）同样输入括号（（）），中括号（[]），尖括号（<>）和花括号（{}），确保你所选择的字体和大小能很好地展示这些符号，足以让你马上区别他们。否则，请选择其他字体或者加大字体大小。

前面已经提到过如何实现这些步骤，所以本章并没有提供对应答案，你要做的只是完成这5个步骤。

第3章　使用帮助系统

在这本书的第1章，我们提到由于图形用户界面具有更强的可发现性，所以更容易学习和使用。但对于像PowerShell这样的命令行接口-CLIs（command-line interfaces）的学习却往往要困难一些，因为它们缺乏可发现性这个特性。事实上，PowerShell拥有出色的可发现性，但是它们并不是那么明显。其中一个主要的可发现性的功能是它的　帮助系统。

3.1　帮助系统：发现命令的方法

请忍受1分钟的时间让我们走上讲台给你讲述下面的内容。

我们工作在一个不是特别重视阅读的行业，但是我们有一个缩写RTFM（Read The Friendly Manual）。当我们希望他们可以“阅读易于使用的手册”时，就能巧妙地把命令传递给用户。大多数管理员更加倾向于直接上手、依赖于GUI工具的提示和上下文菜单等这些GUI的可发现性工具领会如何操作。这也是我们工作的方式。我们假设你也是以同样的方式进行工作的。但是我们来认清一点：

如果你不愿意花时间去阅读PowerShell的帮助文档，那么你就无法高效使用PowerShell，也很难进一步学习如何使用它，更不用说使用它管理类似Windows或Exchange等产品，最终你无法摆脱使用GUI的方式。

让我们澄清一下，虽然上面一段看上去很无趣，但绝对是真理。想象一下，当你使用活动目录和计算机或是其他管理控制台时没有帮助提示、菜单、上下文菜单会怎么样。学习PowerShell而不去花时间去学习帮助文件也是如此。这就好像你去宜家不阅读手册就组装家具，那么你必然会经历挫折、困惑以及感到无能为力。为什么呢？

• 如果你需要执行一项任务，但是却不知道应该使用什么命令，帮助系统就可以帮助你找到这个命令，而无需使用Google或者Bing。
• 如果你在运行一个命令的时候返回错误信息，帮助系统就可以告诉你如何正确运行命令，因此不再出现错误。
• 如果你想将多个命令组合在一起来执行一项复杂的任务，帮助系统就可以帮你找到哪些命令是可以和其他命令结合使用。你不需要在Google或者Bing搜索示例，只需要学习如何使用他们，以便你可以创建出自己的示例和解决方案。

我们意识到我们的讲解过于关注动手实践，但我们看到学生在课堂上或者在工作中面临的问题：如果他们能腾出几分钟坐下来、深呼吸，然后阅读帮助，90%的问题都能迎刃而解。阅读这一章，将帮助大家理解PowerShell的帮助文档。

从现在开始，我们鼓励你阅读帮助文档有下面几个原因。

• 虽然我们将在我们的示例中展示多个命令（我们几乎从未展示一个命令的完整功能和选项），但是你也应该阅读我们展示每个命令的帮助，这样你才会熟悉每个命令所能够完成的其他工作。
• 在本书的实验里，我们将提示你使用哪个命令完成任务，但是我们不会提示语法细节。为了完成这些实验，你必须自己使用帮助系统找到相应命令的语法。

我们向你保证，掌握帮助系统是成为PowerShell专家的一个关键。但你不会在帮助文档中找到每一个细节。很多高级资料并没有在帮助系统中留下文档，但为了有效的日常管理，你需要掌握帮助系统。本书会帮助你深入理解该系统以及在帮助文档中没有具体解释的部分，但只有在与帮助系统结合的情况下才会这么做。

是时候走下讲台了。

Command对比Cmdlet

　

PowerShell包含了多种类型的可执行命令，有些叫作Cmdlet，有些叫作函数，还有一些被称为工作流等。它们的共同点都是命令，所有这些命令都在帮助系统囊括的范围内。Cmdlet的概念是PowerShell中独有的，你运行的大多数命令都属于Cmdlet。但在谈论更通用的可执行工具时，我们会使用“命令”表示，从而保证一致性。

3.2　可更新的帮助

当你第一次使用帮助时，你也许会很惊讶，因为里面什么都没有。不要着急，我们会为你讲解。

微软在PowerShell v3中加入了一个新的功能，叫作“可更新的帮助”。PowerShell可以通过互联网下载帮助文件的更新、修正和扩展。不过，为了做到可更新，微软不能把任何帮助放到安装包中。当你需要查看一个命令的帮助时，你可以得到一个自动生成的简易版的帮助，以及如何更新帮助文档的信息，如下：

PS C:\> help Get-Service  
NAME
    Get-Service  
SYNTAX
    Get-Service [[-Name] <string[]>] [-ComputerName <string[]>] 
    [-DependentServices] [-RequiredServices] [-Include <string[]>] 
    [-Exclude <string[]>] [<CommonParameters>]  

    Get-Service -DisplayName <string[]> [-ComputerName <string[]>] 
    [-DependentServices] [-RequiredServices] [-Include <string[]>] 
    [-Exclude <string[]>] [<CommonParameters>]  

    Get-Service [-ComputerName <string[]>] [-DependentServices]  
    [-RequiredServices] [-Include <string[]>] [-Exclude <string[]>] 
    [-InputObject <ServiceController[]>] [<CommonParameters>]  

别名
    gsv 

备注
    Get-Help 在本机无法找到关于这个Cmdlet命令对应的帮助文档。
    这只显示了部分帮助信息。
        -- 可使用Update-Help下载和安装包含这个Cmdlet模板的帮助文档。
        -- 可输入"Get-Help Get-Service -Online"命令或者
    输入网址http://go.microsoft.com/fwlink/?LinkID=113332 
        查看关于帮助主题的在线文档。

提示：

　

一个容易被忽略的事实是通常本地并没有安装帮助，在你第一次使用帮助的时候，PowerShell会提示你更新帮助系统。

更新PowerShell的帮助文档应该是你的首要任务。这些文件存储在System32这个目录下，这意味着你的Shell必须在更高特权下运行。如果在PowerShell 的标题中没有出现“管理员”的字眼，你将会获得一个错误信息。

PS C:\> update-help 

Update-Help : 无法更新以下模块的帮助: 
'Microsoft.PowerShell.Management， Microsoft.PowerShell.Utility， 
Microsoft.PowerShell.Diagnostics， Microsoft.PowerShell.Core， 
Microsoft.PowerShell.Host， Microsoft.PowerShell.Security， 
Microsoft.WSMan.Management' :  
命令无法更新 Windows PowerShell 核心模块或 $pshome\Modules 目录中任意模块的帮助主题。若要更新这些帮助主题，请使用“以管理员身份运行”命令启动 Windows PowerShell，然后重试运行 Update-Help。
所在位置 行:1 字符: 1 
+ update-help 
+ ~~~~~~~~~~~ 
      + CategoryInfo          : InvalidOperation: (:) [Update-Help]， Except 
    ion 
      + FullyQualifiedErrorId : UpdatableHelpSystemRequiresElevation，Micros 
    oft.PowerShell.Commands.UpdateHelpCommand 

我们将之前错误信息的重点部分用粗体进行标识，该信息告诉你问题所在并如何解决。以管理员身份运行Shell，再次运行Update-Help命令，几分钟内你就可以发现已经成功更新了帮助。

每隔一个月左右的时间重新获取帮助是一个很重要的习惯。PowerShell 甚至可以下载非微软发布命令的帮助文档，只要这些命令模块在合适的位置进行本地化之后加入到在线以供下载。

假如你的计算机不能连上互联网，那该怎么办呢？不要担心，首先找到一台可以上网的机器，并使用Save-Help命令把帮助文档下载一份到本地。然后把它放到一个文件服务器或者其他你可以访问的网络中。接着通过在Update-Help加上-SourcePath参数指向刚刚下载的那份帮助文档的地址。这可以让局域网内任何计算机从中心服务器获取更新后的帮助，无需再连接互联网。

帮助文件已经开源

　

微软的PowerShell帮助文件已经在http://github.com/powershell 开源。该网址是查看最新源码的好地方，该部分帮助可能在PowerShell中无法下载。

3.3　查看帮助

Windows的PowerShell提供了Get-Help这个Cmdlet命令访问帮助系统。你可能看到很多示例（特别是在互联网）都是使用“Help”或“Man”（来自UNIX，指代Manual）关键字来代替Get-Help。Man和Help都不是原生的Cmdlet命令，而是对核心Cmdlet命令进行封装后的函数。

macOS与Linux中的帮助

　

macOS与Linux中的帮助文件，都使用操作系统传统的Man（manual）功能进行显示，该命令会“接管”屏幕，从而显示帮助，在阅读完帮助后返回正常屏幕。

Help的工作原理类似Get-Help，但它可以把输出的信息通过管道传送给More命令。这样你就可以以分屏这样友好的方式来查看帮助的内容，而不是一次性打印出所有的帮助信息。运行Help Get-Content和Get-Help Get-Content，会返回相同的结果。前者是一次一页显示，你也可以使用Get-Help Get-Content | More分页显示，但这需要输入更多的字符，我们通常仅使用Help。但我们想让你知道底层实现。

注意：

　

从技术上来说，Help是一个函数，而Man是Help的一个别名，或者叫昵称。但是它们返回的结果相同。我们将会在下一章讨论别名。

顺便提醒一下，有些时候你可能会讨厌分页显示，因为你想一次性获取所有的信息，但是它却一次次让你输入空格键显示余下的信息。如果你遇到这样的情况，在Shell控制台窗口按Ctrl+C组合键取消命令并立即返回到Shell。Ctrl+C组合键总是表示“返回”的意思，而不是“拷贝到剪切板”的意思。而在图形化Windows PowerShell ISE中，Ctrl+C表示拷贝到剪切板。工具栏中有一个红色按钮“停止”，它可以用于停止正在运行的命令。

注意：

　

很多命令在图形化的ISE中不起作用，即使使用Help或Man时，它也会一次性返回所有的帮助信息，而不是一次返回一页。

帮助系统有两个主要的目标：一个是帮助你找到实现特定任务的命令，另一个就是找到命令后帮助你学会如何使用它们。

3.4　使用帮助系统查找命令

从技术上来说，帮助系统不知道Shell中存在哪些命令。它只知道有哪些可用的帮助主题。某些命令可能并没有帮助文档，这会导致帮助系统不能确认这个命令是否存在。幸好微软几乎发布的每个Cmdlet都包含一个帮助主题，这意味着你通常不会发现不同。另外，帮助系统也包含了除特定Cmdlet之外的其他信息，包括背景概念和其他基础信息。

与大多数命令一样，Get-Help（等同于Help）有几个参数。其中一个最为重要的参数是-Name。该参数指定你想要访问帮助的主题名称，并且它是一个位置参数，所以你无需输入-Name，只需提供所需查找的命令名称。它也支持通配符，这让帮助系统更加容易找到命令。

例如，你想操作系统事件日志，但是你却不知道使用哪个命令，你决定搜索包含事件日志的帮助主题，可以运行下面两个命令中的一个。

Help *log* 
Help *event*

第一个命令在你的计算机返回如下列表。

Name                            Category    Module
----                            --------    ------  
Clear-EventLog                  Cmdlet      Microsoft.PowerShell.M...
Get-EventLog                    Cmdlet      Microsoft.PowerShell.M... 
Limit-EventLog                  Cmdlet      Microsoft.PowerShell.M... 
New-EventLog                    Cmdlet      Microsoft.PowerShell.M... 
Remove-EventLog                 Cmdlet      Microsoft.PowerShell.M...
Show-EventLog                   Cmdlet      Microsoft.PowerShell.M...
Write-EventLog                  Cmdlet      Microsoft.PowerShell.M...
Get-AppxLog                     Function    Appx 
Get-DtcLog                      Function    MsDtc 
Reset-DtcLog                    Function    MsDtc
Set-DtcLog                      Function    MsDtc 
Get-LogProperties               Function    PSDiagnostics
Set-LogProperties               Function    PSDiagnostics
about_Eventlogs                 HelpFile
about_Logical_Operators         HelpFile

注意：

　

你可以注意到，前面的这个列表包含来自Appx、MsDtc模块的命令（和函数）等。即使你还没有将这些模块加载到内存，帮助系统也一样会显示所有模块。这可以帮助你发现电脑上被遗漏的命令。它可以发现那些安装在适当位置所有扩展中的命令。对此，我们会在第7章进行讨论。

前面的列表中有许多关于事件日志的函数，它们都基于“动词-名词”这个命名格式，但是最后出现了两个关于帮助主题的特殊Cmdlets命令却不是这种格式。这两个“about”主题提供了关于某个命令的背景信息。最后一个看起来跟事件日志没有什么关系，但是它被搜索到是因为其中有一个单词“logical”的其中一部分包含了“log”。只要有可能，我们尽量使用“*event*”或者“*log*”搜索，而不是使用“*eventlog*”，因为这样可以返回尽可能多的结果。

当发现一个Cmdlet有可能完成所需完成的工作时（比如说，后面示例中Get-EventLog看起来就是做这件事的），可以查看该Cmdlet的帮助文档进行确认。

Help Get-EventLog

不要忘记使用Tab键补全命令！它可以让你只输入部分命令名称，按下Tab键，接着Shell会完成与你刚刚输入最接近的命令。你可以连续按Tab键来选择其他匹配的命令。

动手实验：

　　

输入Help Get-Ev，接着按下Tab键。第一次匹配到的是Get-Event，这并不是你想要的；再次按下Tab键就匹配到Get-EventLog，这就是你想要的命令。你可以敲回车键接受该命令并显示这个命令对应的帮助信息。如果你使用ISE，你不需要敲Tab键。所有匹配的命令都会以列表的形式呈现，你可以选择其中一个并敲回车键，这样就完成了命令的输入。

你也可以使用最为重要的“*”通配符，它可以匹配Help后面零个到多个字符。如果PowerShell只找到一个匹配你输入的命令，它并不是以列表的形式返回这个单一项，而是直接显示这一单项的具体帮助内容。

动手实验：

　　

运行Help Get-EventL*命令，你应该可以看到关于Get-EventLog的帮助信息，而不是返回一个匹配的帮助主题列表。

如果你一直跟随本书的示例进行实验，那么现在你就应该在看Get-Eventlog的帮助文档了。这个文档被称为概要帮助，这意味着它只有简单的命令描述和语法提示。当你需要快速了解如何使用一个命令时，这些信息非常有用，我们通过该帮助文档来进行示例讲解。

补充说明

　

有些时候，我们想分享的信息虽然不错，但不是至关重要的Shell知识。我们将把这些信息放到“补充说明”部分，正如现在这个部分。如果你跳过这段，你并没有什么损失，但是如果你进行阅读，你通常会学会以另外一种方式解决问题，或者能够更深入地了解PowerShell。

我们前面提到过Help命令并不是为了搜索Cmdlet命令，而是为了搜索帮助主题。由于每个Cmdlet都有一个帮助文件，我们可以说，这些搜索到的结果集相同。但是你也可以直接使用Get-Command命令搜索Cmdlet命令（或者它的别名Gcm）。

与Help这个命令一样，Get-Command接受通配符，意味着你可以运行Gcm *event*查看所有名称包含“event”的命令。不管怎么样，这个返回的列表将不止包含Cmdlet命令，还会包含一些不一定有用的外部命令，如netevent.dll。

一个比较好的方式是使用“-名词”或者“-动词”参数。因为只有Cmdlet名的名称有名词和动词，返回的结果将会限制为Cmdlet命令。Get-Command -noun *event*将会返回一个关于事件命令的列表；Get-Command-verb Get将会返回一个具有检索能力的列表。你也可以使用-CommandType参数来指定命令的类型。比如，Get-Command *log* -type Cmdlet将会返回一个所有命令名称包含“log”的命令列表，并且这个列表不会包括任何其他扩展应用程序或者扩展命令。

3.5　帮助详解

PowerShell的Cmdlet帮助文件有一些特殊的约定。从这些帮助文件中提取大量信息的关键是你需要明白自己在寻找什么，并学会更高效地使用这些Cmdlet命令。

3.5.1　参数集和通用参数

大部分命令可以有多种使用方式，这依赖于你需要用它们来做什么。例如，下面是Get-EventLog的语法帮助部分。

SYNTAX 
    Get-EventLog [-AsString] [-ComputerName <string[]>] [-List][<CommonParameters>] 

    Get-EventLog [-LogName] <string> [[-InstanceId] <Int64[]>] [-After <DateTime>] 
    [-AsBaseObject] [-Before <DateTime>] [-ComputerName<string[]>] [-EntryType 
     <string[]>] [-Index <Int32[]>] [-Message<string>] [-Newest <int>] [-Source 
     <string[]>] [-UserName <string[]>] [<CommonParameters>]

注意，该命令在语法部分出现了两次，这表示这个命令提供了两个不同的参数集，你可以有两种方式使用该命令。你可能已经注意到，有些参数是这两个参数集共享的。例如，这两个参数集都包含-ComputerName参数。但是这两个参数集总会有些差异。在这个实例中，第一个参数集提供了-AsString和-List，这两个参数都没有出现在第二个参数集中；而第二个参数集包含许多第一个参数集中没有的参数。

下面来说明它们是如何工作的：如果你使用一个只包含在某个参数集中的参数，那么你就只能使用同一个参数集里的其他参数。如果你选择使用-List参数，那么你能够使用的其他参数就只能是-AsString和-ComputerName，因为存在-List的参数集中只剩这两个参数可选。你不能添加-LogName参数，因为它不存在于第一个参数集中。这意味着-List和-LogName是相互排斥的，即你不能同时使用它们，因为它们存在于不同的参数集中。

有些时候，可以只带有所有参数集中共有的参数运行命令。在这种情况下，Shell通常会选择第一个参数集。理解你运行的命令带有的参数属于哪个参数集非常重要，因为每个参数集意味着不同的功能。

你可能已经注意到，在每个PowerShell的Cmdlet参数的结尾都有[<Common- Parameters>]。不管你以何种方式使用Cmdlet，这泛指每个Cmdlet命令都是使用的一组包含8个参数的集合。现在暂时不讨论通用参数，我们会在本书后面章节真正使用它们的时候来讨论。不过，在本章后面，如果你有兴趣，我们会告诉你哪里可以学习到更多关于通用参数的知识。

注意：

　

聪明的读者现在已经能够识别出我们提供示例中的变化。读者会注意到基于PowerShell版本的不同，Get-EventLog的帮助布局也会不同。你甚至会看到一些新的参数，但我们所解释的基础与概念并没有变。不要因为你所看到的帮助与本书的帮助不同而卡在这里。

3.5.2　可选和必选参数

运行一个Cmdlet命令时，你无需提供全部参数。PowerShell的帮助文档把可选参数放到一个方括号中。例如，[-ComputerName <string[]>]表示整个-ComputerName参数是可选的。你可以不使用该参数，因为在没有为该参数指定一个具体值的时候，Cmdlet会默认为本地计算机。这也就是为什么[<CommonParameters>]在方括号内，你就可以在不使用任何通用参数的情况下运行该命令。

几乎所有的Cmdlet命令都最少有一个可选参数。你可能永远不会需要使用其中的一些参数，以及可能日常使用其他参数。记住，当你选择一个参数时，你只需输入足够的参数名称就可以让PowerShell明白你所需的参数是什么。例如，-L不能充分表示-List，因为-L可以表示-LogName。但是-Li是一个适合-List的的缩写，因为其他参数名称没有以-Li开头的。

如果运行命令时忘了指定必选参数，会发生什么呢？来看看Get-EventLog的帮助。例如，你可以看到-LogName参数是必选参数，该参数并不在方括号内。尝试在没有指定日志名称的情况下运行Get-EventLog。

动手实验：

　　

通过运行Get-EventLog命令而不提供任何参数。

PowerShell会提示你需要输入必选的LogName参数。如果你输入类似System或者Application的参数值之后敲回车键，该命令就能正常运行。你可以按下Ctrl+C组合键终止该命令。

3.5.3　位置参数

PowerShell设计者知道有些参数会被频繁地使用，而你不希望不断地输入参数名称。通常来说，参数是具有位置性的。这意味着只要你把参数值放在正确的位置，你就可以只提供这个参数值，而不需要输入具体的参数名。

有两种方式可以用于确定位置参数：通过语法概要或者通过详细的帮助文档。

在语法概要中找到位置参数

你可以在语法概要中找到第一种方式：只有参数名被方括号括起来的参数。比如，查看Get-EventLog的第二个参数集的前两个参数。

[-LogName] <string> [[-InstanceId] <Int64[]>]

第一个参数：-LogName。它是必选参数。我们可以识别出它是必选参数，是因为它的参数名称和参数值不在一个方括号里面。但是它的参数名称处在一个方括号内，这让它成了一个位置参数，所以我们可以只提供日志名称而不需要输入参数名称-LogName。并且由于该参数出现在帮助文档的第一个位置，所以我们知道这个日志名称是我们必须提供的第一个参数。

第二个参数：-InstanceId。它是可选的，因为它的参数名称与参数值位于同一个方括号内。在方括号内，-InstanceId本身又处在一个方括号里，意味着它同时还是一个位置参数。它出现在第二个位置，所以我们省略这个参数名称，就必须在该位置提供一个参数值。

参数-Before（出现在语法的后面，通过运行Help Get-EventLog命令自行查找）是一个可选参数，因为参数名和参数值同在一个方括号里面。-Before参数名没有单独放在方括号里，这告诉我们，当选择使用这个参数时，必须输入该参数名称（或者至少是它的别名）。

下面介绍使用位置参数时的几个技巧。

• 位置参数可以同时出现指定和不指定参数名称的情况，但是位置参数必须处在正确的位置。例如，Get-EventLog -newest 20 -Log Application是正确的；System会被匹配到-LogName参数，因为这是第一个位置的参数值，20将表示-Newest参数值，因为你已经指定了参数名称。
• 指定参数名称总是合法的。当你这样做了，输入的顺序就变得不重要。Get- EventLog- newest 20-Log Application是正确的，因为我们已经使用了参数名称（在这个示例中是-LogName，我们这里使用了缩写-Log）。
• 如果使用多个位置参数，不要忘了它们的位置。Get-EventLog Application 0可以运行，Application会附加到-LogName参数，0会附加到-InstanceId参数。Get-EventLog 0 Application会运行失败，因为0会附加-LogName参数名，但是却找不到名为“0”的日志。

我们将提供一个最佳实践：总是使用参数名，直到你能顺手地使用每个Cmdlet并厌倦了一遍一遍输入常用的参数。在此之后，使用位置参数来节省时间。当需要把一个命令以文件的形式存储在文本文件以方便重用时，通常使用完整的Cmdlet名称和完整的参数名称。这样做的目的是将来可以方便地阅读和理解，因为你不需要重复输入参数名称（这毕竟也是你把命令存储在一个文件的目的），这不会增加你太多额外的输入。

在详细的帮助文档中找到位置参数

我们说通常有两种方式来位置参数。第二种方式需要你使用Help命令指定-full参数来打开帮助文档。

动手实验：

　　

运行Help Get-EventLog-full命令。记得使用空格分页地查看帮助文档，如果你想停止查看，可以使用Ctrl+C组合键到达帮助文件的末尾。现在，可以通过滚动窗口重复查看整个页面。同时，如果不使用-full参数尝试使用-ShowWindow参数，该参数可以在客户端版本的Windows或带有GUI的Server版本Windows上执行。但是请注意成功使用-ShowWindow的前提是底层帮助XML文件的质量。如果文件格式不对，你可能无法查看所有内容。注意-ShowWindow参数无法在非Windows操作系统中使用。

分页查看，直到你看到类似下面关于-LogName参数的信息。

-LogName <string>
    指定事件日志。输入一个事件日志的日志名称（Log 属性的值；而非 LogDisplayName）。
    不允许使用通配符。此参数是必需的。

    是否必需?                  True 
    位置?                      1 
    默认值
    是否接受管道输入?            False 
    是否接受通配符?             False

在前面的例子中，你可以看到这是一个强制参数，并且是一个位置参数，同时，它出现在Cmdlet命令之后的第一个位置。

当学生开始使用一个Cmdlet命令的时候，我们总是鼓励他们把焦点放在阅读帮助上，而不只是缩写语法的提示上。阅读帮助可以让我们理解得更加详细，包括参数的使用描述。你可以看到该参数不接受通配符，这意味着你不能提供类似App*的参数值，你需要输入日志名称的全称，如Application。

3.5.4　参数值

帮助文档同样给你提供了每个参数的数据类型。有些参数被称为开关参数，无需任何输入值。在缩写语法中，它们看起来如下所示。

[-AsString]

在详细语法中，它们看起来如下所示。

-AsString [<SwitchParameter>] 
    以字符串而非对象的形式返回输出。 
　
    是否必需?                   False 
    位置?                      named 
    默认值                
    是否接受管道输入?            False 
    是否接受通配符?              False

通过[<SwitchParameter>]可以确认这是一个开关参数，并不需要任何输入值。开关参数的位置可以随意放置，你必须输入参数名（或者至少是一个缩写）。开关参数总是可选的，这可以让你选择是否使用它们。

其他参数希望获得的数据类型，通常会跟在参数名称之后，并使用空格与参数名称分开（不是冒号、等号或者其他字符，虽然你时不时可能会遇到错误）。在缩写语法里面，输入的类型使用尖括号表明（我们的朋友Jason称之为chi-hua-huas，在他说到这一点时带有手势比划），例如：

[-LogName] <string>

在详细语法中以相同的方式显示：

-Message <string> 

    获取其消息中具有指定字符串的事件。可以使用此属性来搜索包含特定单词或短语的消息。允许使用通配符。
    是否必需?                     False 
    位置?                        named 
    默认值
    是否接受管道输入?              False 
    是否接受通配符?                True

下面来看看通常的输入类型。

• string——一系列字母和数字，有些时候也会包含空格符。如果出现空格符，那么全部字符串必须包含在引号内。例如，类似C:\Windows的字符串不需要使用引号，但是C:\Program Files这样的字符串就需要，因为它包含了一个空格。现在，你可以交替使用单引号或者双引号，但是最好坚持使用单引号。
• Int、Int32或Int64——一个整数类型（整个数字不包含小数）。
• DateTime——通常，基于你本地计算机的时区配置，字符串被解释成的日期会有所不同。在美国，通过的日期格式为10-10-2010，即月-日-年。

关于更多类型，我们将在遇到的时候再做讨论。

你也许注意到有些值包含多个方括号：

[-ComputerName <string[]>]

string后面的方括号（我们的朋友Json称之为奶嘴）并不意味着某些东西是可选的。事实上，string[]意味着该参数可以接受数组、集合，或者是一个列表类型的字符串。在这种情况下，只提供一个值也符合语法。

Get-EventLog Security -computer Server-R2

但是指定多个值也符合语法。一个简单的方式是提供一个以逗号为分隔符的列表。PowerShell把以逗号为分隔符的列表作为数组值对待。

Get-EventLog Security -computer Server-R2，DC4，Files02

再次说明，任何一个单一值中如果包含了空格，就必须使用引号。但是作为一个整体的列表，不需要使用引号，只有单一值才需要使用引号。这一点非常重要。下面的命令符合语法。

Get-EventLog Security -computer 'Server-R2'，'Files02'

如果你想为每个值都加上引号，这也是可以的（即使这些值没有一个需要引号）。但是下面将会出错：

Get-EventLog Security -computer 'Server-R2，Files01'

在该示例中，Cmdlet命令会查找一个名称为Server-R2，Files01的计算机。这也许不是你想要的。

另外一种提供列表值的方式是把它们输入到一个文本文件中，每一个值一行。例如：

Server-R2 
Files02 
Files03 
DC04 
DC03

接着，你可以使用Get-Content这个Cmdlet命令来读取该文件的内容，并且发送这些内容到-computerName参数中。你可以强制Shell先执行Get-Content命令，这样就可以把结果送到这个参数了。

记得高中数学中()圆括号可以用来在数学表达式中指定操作的顺序。这同样适用于PowerShell。使用圆括号把命令括起来，就强制这些命令先执行。

Get-EventLog Application -computer (Get-Content names.txt)

前面一个示例展示了一个有用的技巧：我们可以把Web服务器、域名控制器和数据库服务器等不同类型的服务器放到一个文本文件中，接着使用这个技巧再次运行这个包含全部计算机集合的命令。

你也可以使用其他方式来输入一个列表值，包含从活动目录中读取计算机名称。这些技术会更加复杂。在学习一些 Cmdlet命令之后，便能玩转这些技巧，我们会在后面的章节学习到。

另一种为参数（假设它是一个强制参数）指定多个值的方式是不指定参数。与所有强制参数一样，PowerShell将提示你输入参数值。对于接受多个值的参数，你可以输入第一个值并按回车键，继续输入直到完成，最后空白处按回车键，这将告诉PowerShell你已经完成输入。像通常一样，如果你不想被提示输入项，可以按Ctrl+C组合键终止命令。

3.5.5　发现命令示例

我们倾向于通过示例学习，这就是在本书放置大量示例的原因。PowerShell的设计者知道大部分管理员都喜欢示例，这也是他们把大量的示例放置到帮助文档的原因。如果你滚动到Get-EventLog帮助文档的末尾，很可能发现大量如何使用该Cmdlet命令的例子。

如果你只想查看示例，我们有一个简单获取到这些示例的方法：在Help命令中加入-example参数，而不是使用-full参数。

Help Get-EventLog -example

动手实验：

　　

使用这个新的参数来获取一个Cmdlet 命令的示例。

我们喜欢这些示例，尽管其中一些会比较复杂。如果遇到一个对你来说太复杂的示例，请忽略它，并测试其他示例。或者通过一点点的尝试（总是在非生产机器上测试），看你是否知道该示例的用途以及这样用的原因。

3.6　访问“关于”主题

在本章的前面部分，我们提到PowerShell的帮助系统包含许多背景主题，可以用来帮助定位指定的Cmdlet命令。这些背景主题通常被称为“关于”主题，因为它们都是以“about_”开头的。你可能还记得在本章的前面，所有的Cmdlet命令都提供一个通用参数集。怎样才能更多了解这些常见的参数？

动手实验：

　　

在你继续读本书之前，确认你是否可以通过帮助系统列出公用参数。

先使用通配符。因为“common”在本书已经被多次使用，所以先从下面的关键字开始。

Help *common*

这真是一个好的关键字。事实上，这只会在帮助主题中匹配到一条记录：About_ common_parameters。该主题将会自动显示，因为只有唯一一条配置的主题。浏览显示的帮助主题，你会发现如下8个通用参数。

-Verbose
-Debug
-WarningAction 
-WarningVariable 
-ErrorAction 
-ErrorVariable
-OutVariable 
-OutBuffer

这个帮助文档提到两个额外的“风险缓解”参数，但是并不是每个Cmdlet命令都提供这两个参数。

在帮助系统中，“关于”这个主题非常重要。但是，因为它们没有关联到某个特定的Cmdlet命令，所以很容易被人忽略。如果你运行help about*列出所有信息，你也许会吃惊怎么有那么多额外的文档信息隐藏在Shell中。

3.7　访问在线帮助

PowerShell的帮助文档是由人编写的，这意味着它们并不一定准确无误。除了更新帮助文档（你可以运行Update-Help），微软也在其网站上发布帮助文档。PowerShell help命令的-online参数，使用它可以在网络中找到你所想要命令的帮助信息：

Help Get-EventLog -online

微软的TechNet 站点承载该帮助，并且它通常比安装PowerShell中帮助文档要更新。如果你认为在示例或者语法中发现了一个错误，尝试查看在线版本的帮助文档。PowerShell在线文档不会包含所有cmdlet的帮助信息，而是由各个产品团队负责（如Exchange团队、SQLServer团队、SharePoint团队等）共同提供帮助文档的更新。但PowerShell在线文档在可用的情况下，将会是内置帮助文档的补充。

我们喜欢在线帮助文档，是因为当我们在PowerShell输入脚本的时候，可以在另一个窗口上阅读文档（帮助文档在Web浏览器也能有良好的格式）。Don通过一个简单的设置就可以使用双屏显示，效果更佳。你也可以使用我们之前提到过的-ShowWindow这个开关参数而不是-Online参数，在另一个窗口中打开本地帮助文档。

3.8　动手实验

注意：

　

在本实验中，你需要在计算机中运行PowerShell v3或更高版本。

我们希望这一章已经帮你认识到在PowerShell中掌握帮助系统的重要性。现在是时候通过下面任务帮助你磨练技巧了。请记住示例答案在下一小节。使用Help命令寻找下面任务中的斜体字，并将它们作为提示。下面一部分步骤仅在Windows有效，我们会指出这些步骤。

1．运行Update-Help并确保它执行无误。这会让你的本机下载一份帮助文档。条件是你的电脑能连上互联网，并且需要在更高特权下运行Shell（这意味着必须在PowerShell的标题中出现“管理员”的字眼）。

2． 仅Windows：哪一个Cmdlet命令能够把其他Cmdlet命令输出的内容转换到HTML？

3．部分仅Windows：哪一个Cmdlet命令可以重定向输出到一个文件（file）或者到打印机（printer）？

4．哪一个Cmdlet命令可以操作进程（processes）？（提示：记住，所有Cmdlet命令都包含一个名词。）

5．你可以用哪一个Cmdlet命令向事件日志（log）写入（write）数据（该步骤仅在Windows系统有效，但你可以得到一个不同的答案）？

6．你必须知道别名是Cmdlet命令的昵称。哪一个Cmdlet可以用于创建、修改或者导入别名（aliases）？

7．怎么保证你在Shell中的输入都在一个脚本（transcript）中，怎么保存这个脚本到一个文本文件中？

8．仅Windows：从安全事件（event）日志检索所有的条目可能需要很长时间，你怎么只获取最近的100条记录呢？

9．仅Windows：是否有办法可以获取一个远程计算机上安装的服务（services）列表？

10．是否有办法可以看到一个远程计算机运行了什么进程（processes）（你可以在非Windows操作系统找到答案，但命令本身会有区别）？

11．尝试查看Out-File这个Cmdlet命令的帮助文档。通过该Cmdlet命令输出到文件每一行记录的默认宽度大小为多少个字符？是否有一个参数可以让你修改这个宽度？

12．在默认情况下，Out-File将覆盖任何已经存在具有相同的文件名。是否有一个参数可以预防Cmdlet命令覆盖现有的文件？

13．如何查看在PowerShell中预先定义所有别名（aliases）列表？

14．怎么使用别名和缩写的参数名称来写一条最短的命令，从而能检索出一台名称为Server1的计算机中正在运行的进程列表？

15．有多少Cmdlet命令可以处理普通对象？（提示：记得使用类似“object”的单数名词好过使用类似“objects”的复数名词。）

16．这一章简单提到了数组（arrays）。哪一个帮助主题可以告诉你关于数组的更多信息？

3.9　动手实验答案

1．Update-Help

或者同一天执行多次：

Update-Help –force

2．help html

或可以尝试使用Get-Command：

get-command –noun html

3．get-command -noun file,printer

4．Get-command –noun process

或：

Help *Process

5．get-command -verb write -noun eventlog

如果不确定名词部分是什么，使用通配符。

help *log

6．help *alias

或：

get-command –noun alias

7．help transcript

8．help Get-Eventlog –parameter Newest

9．help Get-Service –parameter computername

10．help Get-Process –parameter computername

11．Help Out-File –full

或：

Help Out-File –parameter Width

应该展示给你PowerShell默认的控制台宽度是每行80个字符。

12．如果你运行Help Out-File –full查看参数，你将会看到-NoClobber。

13．Get-Alias

14．ps –c server1

15．get-command –noun object

16．help about_arrays

或者可以使用通配符：

help *array*