Windows PowerShell：Windows PowerShell 工作流环境
在今年的每个月，Don Jones 将分期介绍有关 Windows PowerShell 工作流的教程，它分为 12 部分。 我们鼓励您通过一系列的顺序，读开头 2013 年 1 月列。
Don Jones
上月述 Windows PowerShell 工作流是 Windows 管理框架第 3 版中的新功能。 它是预装 Windows 服务器 2012年和 Windows 8。 它也是可用于 Windows 7、 Windows Server 2008 和 Windows Server 2008 R2。 您将需要这些操作系统运行工作流之一。 您还可以让工作流目标 — 也就是说，执行打击任务 — 任何版本的 Windows 中，根据你想要完成的任务。
有两个主要前提条件使用 Windows PowerShell 工作流，除了 Windows PowerShell 版本 3 的标准的系统要求。 首先，您需要使用捆绑的 PSWorkflow 模块，使壳内部的工作流功能。 第二，您需要有您计划目标与 Windows PowerShell 工作流的计算机上启用 Windows PowerShell 远程处理。
远程处理不一定非要将您在执行工作流，但您计划库存、 配置或以其他方式管理任何机器将需要有启用远程计算机上运行。 Windows PowerShell 工作流作为其主要通信协议使用远程处理。 有可能某些工作流可以写，不需要远程处理，但这些是少之又少。
远程处理是 Windows PowerShell 大大误解的组件。 以上几个组织 IT 安全人员采取做不部署的方法。 这一种误导和不幸。 那些相同的安全意识有没有问题，让一大批其他管理通信协议 （如远程桌面协议 (RDP)、 远程过程调用 (Rpc) 和 HTTP。
远程处理是在 Windows 环境中管理通信的未来路向。 微软将很快开始将这些较旧的协议整合到远程处理。 远程处理使用 HTTP 和 HTTPS，是高度可配置的、 易于管理，并可以集中锁定它与组策略对象 (GPO)。 它也是一般更安全、 更可审核和更加可控，比那些较旧的协议。 为远程处理和其体系结构的安全问题更全面的讨论，考虑下载免费的电子书，"PowerShell 远程处理的秘密."
内部工作流程
你得在接近 Windows PowerShell 工作流时的最大挑战是要记住它看起来像一个 Windows PowerShell 脚本 （具体而言，函数），但它不是。 "Windows PowerShell 语言"你写被翻译成一种外部的语言 (XAML)。 然后它由非 Windows PowerShell 技术执行。
其结果是，有几个不同的规则。 有些人是纯粹的语法。 一般来说，您需要使用您所运行的 cmdlet 的充分 cmdlet 名称。 另外，不允许位置参数和截断的参数名称。 您必须使用完整参数名称。
什么会更令人困惑是工作流中的整体环境。 工作流的整点是您可以中断和故意恢复工作流或这样做对事错在您环境中 （如功率损失) 的反应。
这意味着在工作流中的每个命令必须基本上重叠。 它必须有没有认识其他命令所做的事和没有本机命令之间保持数据的手段。 它还意味着您不能设置一个变量来保存一个命令的输出，然后将该变量传递给另一个命令的输入。 它不会工作。 此外，您无法加载模块包含其他命令。 没有持续的环境，在其中加载模块。
现在可以走到工作流中的特殊 InlineScript {} 块将成为你最好的朋友。 每个 InlineScript 基本上是作为一个单元运行的。 副本的 Windows PowerShell，堵塞在整个 InlineScript，向上自旋的 Windows 工作流基金会 （WWF） 和它运行。 InlineScript 的内容类似于传统的 Windows PowerShell 脚本。
也是隐式的 InlineScript。 世界自然基金会实际上不能运行 Windows PowerShell 命令 InlineScript 之外。 当您在您的工作流中使用 Windows PowerShell cmdlet 时，Windows PowerShell 检查如果本机的世界自然基金会等效可用，并且告诉世界自然基金会，改为运行的。
Windows PowerShell 团队写了许多本机 Windows PowerShell 命令，世界自然基金会等效项，但当您尝试使用 cmdlet，没有世界自然基金会的本机版本，Windows PowerShell 隐式地环绕在 InlineScript 块中您的命令。 这将导致世界自然基金会启动 Windows PowerShell，运行您的命令，然后关闭该实例的 Windows PowerShell。
这种缺乏持久性命令之间是什么可帮助使您的脚本可恢复 Windows PowerShell 工作流。 为什么 Windows PowerShell 工作流可以并行化脚本中的命令，这是很大一部分。 它变成他们多线程的自动化机器。 然而，缺乏恒心是如何正常 Windows PowerShell 脚本的重大偏离，及职能工作。 它需要很多的额外的规划，使正常工作的脚本。
不会很不寻常，请参阅工作流由一群 InlineScript 块组成。 也不会看到的只不过是一个单一的、 长的 InlineScript 块的工作流不寻常。
这种工作流将有有限的 （或不存在的） 的并行化或恢复功能。 InlineScript 是工作的一个单个单元。 你可能只是选择此类脚本作为运行正常功能，使用远程处理，而不是工作流。 你会得到很少的 Windows PowerShell 工作流实际好处反正。
保持这些方便
Windows PowerShell 工作流明显缺乏的一件事是坚持两个命令之间的工作流的数据的一种手段。 这将使它在更广范围的情况下非常有用。 如果中断工作流并将其恢复，命令可以轻松地重新创建状态信息，如 IP 地址、 计算机名称、 用户名称或任何其他，并继续运行。
正是鉴于此本机缺点，您可能要创建您自己的东西。 设置一个 SQL Server 实例 （甚至免费快递实例） 并创建您的工作流可以在其中保存数据的数据库表。 工作流将需要一些方法来唯一地标识本身，例如工作流的名称以及针对每个工作流实例的计算机名称。
然后，您的工作流可能的离散 InlineScript 块的数量由组成。 每个将从数据库中读取的当前状态、 执行某些任务，和，如果有必要，使用新信息更新数据库。 它是 Windows PowerShell 工作流功能不能帮助自动化这一种耻辱。 也许"$ 工作流： 变量"体系结构，使用 XML 文件或 SQL Server 引擎盖下可以帮助，但这也是为将来的版本。
好消息是它是很容易的使用 SQL Server 的"掷自己"持久性。 SQL Server 是优于 XML 文件，因为它是可扩展性更强，您可以访问它更方便地从多个网络位置，和它支持多个实例更好的并发访问一次。
Microsoft.NET 框架 System.Data.Sql.SqlClient 类是简单易用。 有的例子我"月午餐学习 PowerShell 工具"电子书。 事实上，我论文的作者之一，并创建整个模块，您可以重新使用和免费下载作为这本书的示例脚本的一部分。
与这些预赛的方式，我们准备开始审查基本工作流程是什么样子。 这将是专栏的下个月的主题。
.jpg)
Don Jones Windows PowerShell MVP 奖得主、 TechNet 杂志 》 的特约编辑。 他合著了有关 Windows PowerShell 版本 3，包括在 Windows PowerShell 和 Windows PowerShell 远程处理中创建 HTML 报表上的几个免费标题的四本书。 找到它们都在 PowerShellBooks.com，或问你问题在讨论论坛上的琼斯 PowerShell.org。