ScriptRunner 2020PS7 – 发布

在 2020 年版本中，我们的客户将收到重大功能更新，重点是 PowerShell 7、PowerShell Remoting 和 ScriptRunner 增强以及基础设施自动化。以下部分提供了概述。对于各个主题，我们参考单独的博客文章、视频和我们的文档。有关所有新功能的详细列表，请查看 ScriptRunner 知识库中的发行说明。

ScriptRunner 中的 PowerShell 7

新的 PowerShell 7 是流行自动化语言的独立于平台的版本。它基于独立于平台的 .NET Core 运行时。

PowerShell 7 适用于许多平台，使 IT 专业人员能够使用单一脚本语言来实现异构基础设施的统一管理。

ScriptRunner 是领先的 Powershell 管理一体化解决方案，支持 PowerShell 7 与 Windows PowerShell 5.1 的自动化和委派方案。

如果您想尝试或使用 PowerShell 7，可以使用 ScriptRunner 安装程序中的 PowerShell7pwsh.zip 包。

• 首先在ScriptRunner Server上安装.NET Core 3.1 Runtime

• 完全解压zip文件并将文件复制到目录中

  C:\ProgramFiles\ScriptRunner\Service\Pwsh

• PowerShell 7 的脚本由 SRXPSCoreHost.exe 进程环境中的 ScriptRunner 执行。它们是在 PowerShell 选项的管理 Web 应用程序的操作配置中选择的（图 1）。

图1：在Admin Web App操作配置中选择“PowerShell 7 Host（实验）”进程环境以在ScriptRunner中运行PowerShell 7脚本

在 PowerShell 7 中本地执行脚本不需要采取进一步的预防措施。如果要在远程系统（例如 Linux 或 MacOS）上运行 PowerShell 7 中的脚本，则必须在远程系统上安装和配置 PowerShell 7。您可以在 PowerShell GitHub 存储库上找到适当的安装包。

SSH 设置并与 PowerShell 7 一起使用

随着 PowerShell 7 的推出，SSH 远程处理现在成为焦点。 PowerShell SSH 远程处理在 SSH 客户端（在 ScriptRunner 服务器上）和 SSH 服务器（在目标系统上）之间使用 SSH 协议。

要在 ScriptRunner 中使用 SSH 和 PowerShell 7，需要执行以下步骤：

• 在各自的系统上安装 SSH 客户端和 SSH 服务器。在 Windows Server 2019 中，它作为可选功能提供；对于其他平台，可以使用相应的实现。
• 在系统上安装 PowerShell 7（请参阅 ScriptRunner 中的 PowerShell 7 部分）
• 配置 SSH 以使用 PowerShell 7
• 配置SSH认证

更多信息可以在这里找到：

通过 SSH 进行 PowerShell 远程处理 - PowerShell |微软文档

在 PowerShell 7 中启用 PowerShell SSH 远程处理 - Thomas Maurer

要将 SSH 连接与 ScriptRunner 结合使用，您需要相应的目标系统配置（图 2）。

图 2：在 Target Configuration 选项卡中，选择选项“SSH”以与 ScriptRunner 建立 SSH 连接

通过选择适当的目标系统类型、分配存储的 SSH 凭据并在操作配置中选择 PowerShell 7 选项，您可以使用 PowerShell 7 通过 SSH 管理远程目标系统。

要在目标系统上设置 SSH 身份验证，请创建 SSH 凭据并输入 SSH 用户的帐户（图 3）。该用户必须在目标系统上获得授权。

图 3：要在特定目标系统上为用户设置 SSH 身份验证，您必须首先创建相应的凭据。所需的 SSH 密钥文件从默认目录中检索，如图所示（选项“使用 -/.ssh/ 中的默认用户密钥文件。”）

ScriptRunner 可以使用现有用户配置文件中的现有 SSH 密钥文件，也可以在 ScriptRunner 服务器本身上管理它们。

ScriptRunner服务器上用户现有的密钥文件默认位于用户目录下。您可以简单地启用默认目录 (-/.ssh/.) 或指定不同的目录（图 4）。

图 4：作为 -/.ssh/ 下默认目录的替代。您还可以为现有 SSH 密钥文件指定自定义目录

如果您希望将 SSH 密钥文件集中在 ScriptRunner 中，而不是集中在各个用户目录中的 SSH 密钥文件，请使用“SSH 密钥文件内容”选项（图 5）。

此选项允许您将 SSH 密钥文件内容复制到 ScriptRunner 凭据配置中。 ScriptRunner 一次创建并自动管理一个 SSH 密钥文件。

与标准相比，此过程提供了更多的控制、安全性和集中性。

图 5：“SSH 密钥文件内容”选项允许将 SSH 密钥文件的内容复制到 ScriptRunner 凭据配置中

Office365 Power Automate 的工作流程

ScriptRunner 是完全自动化 IT 中的重要构建块。实现这一点的基本先决条件是与整体解决方案的其他构建模块进行无差错的合作：工作流程、监控系统、ITSM 系统和其他专用自动化系统，例如：用于 SAP 或其他专业应用程序。

ScriptRunner 与工作流系统的集成从 2016 年开始就成为了固定的产品功能。Office 365 的流行使得许多公司考虑在各种应用场景中使用 Microsoft Power Automate。

特别是对于 IT 运营团队来说，使用 Power Automate 作为工作流系统并结合 ScriptRunner 作为 PowerShell 平台非常有吸引力。这使得具有审批程序的复杂流程能够作为工作流在 Power Automate 中实施。各个工作流程步骤（尤其是使用 PowerShell 的任务）由 ScriptRunner 作为工作流程参与者执行，并将结果传输到工作流程。

在新版本中，ScriptRunner 支持直接部署 ScriptRunner 操作，包括 Power Automate 中的参数。这使得任何 ScriptRunner 操作都可以用作工作流程中的构建块，而无需对复杂的 WebAPI 调用和参数传输进行编程。

必须采取以下步骤：

• 在 ScriptRunner 上设置 Microsoft 本地数据网关
• 为 O365 Power Automate 配置 ScriptRunner Web 服务连接器并分配工作流程中可用的 ScriptRunner 操作
• 使用管理 Web 应用程序从 ScriptRunner 导出 OpenAPI 文件
• 在 Power Automate 中创建“自定义连接器”并导入 OpenAPI 文件。
• 更改 ScriptRunner 操作后重新导入自定义 OpenAPI 文件

要导出 OpenAPI 文件，请选择先前配置的连接器并执行操作栏中的导出功能（图 6）。

图6：要导出OpenAPI文件，首先选择相关的Automation Connector，然后单击工具栏中的“导出OpenAPI”

现在在 Power Automate 中创建一个新的“自定义连接器”并从 ScriptRunner 导入 OpenAPI 文件。

如果已在 Power Automate 中成功创建自定义连接器，您必须设置连接到本地网关和 Windows 身份验证的选项以确保安全。

使用手动触发创建新的 Power Automate 流程后，现在可以创建工作流程步骤。

进一步配置需要配置的自定义连接器。这可以在“自定义”部分中找到。

自定义连接器用于在不同的操作之间进行选择。操作 - SR INTERNAL - 用于 Power Automate 和 ScriptRunner 之间的内部通信。它不能在流程中使用。

选择操作后，必须配置相应的连接。这里存储登录ScriptRunner服务器的用户名和密码。还必须选择之前配置的网关。

连接器完成配置后，现在可以根据所选操作直接使用参数并在工作流程中分配。

在脚本执行时选择目标系统

来自客户的越来越多的场景以及我们收到的反馈都被纳入我们的开发中。为服务台提供更大灵活性的一项功能是 Delegate Web App 中的新目标选择。

此功能使 Delegate App 的用户能够使用，例如在服务台中，在脚本执行时从先前定义的集合中选择要执行操作的目标系统。这开辟了许多用例。

管理其他 Office 365 服务

新的 ScriptRunner 版本还提供了使用 PowerShell 管理 Office 365 服务的新可能性。

已实施与 Exchange Online 连接的增强功能。从现在开始，可以使用新的 PowerShell 模块 Exchange Online V2 (EXOv2)（图 7）。

为此，必须首先在 ScriptRunner 服务器上安装 PowerShell 模块 ExchangeOnline Management。然后，ScriptRunner 使用 Microsoft 实施的新过程自动建立、验证和关闭连接。

借助 EXOv2，Azure Active Directory 模块现在也可用于 Exchange Online。旧的 MS Online 模块因此被完全取代。

图 7：现在可以在 ScriptRunner 管理应用程序的云连接配置中选择新的 PowerShell 模块 Exchange Online V2 (EXOv2) 作为选项。

对现在非常流行的 Microsoft Team 的直接管理支持是全新实现的（图 8）。整个连接和身份验证处理现在由 ScriptRunner 完成。 PowerShell 模块 Microsoft Teams 必须安装在 ScriptRunner 服务器上。

为了开始使用 Microsoft Teams PowerShell 管理，我们还在 GitHub 存储库上提供了免费的 Microsoft Teams ActionPack。

图 8：现在可以选择 Microsoft Teams 作为 ScriptRunner 管理应用程序的云连接配置中的选项。

Microsoft Teams 的 O365 服务允许基于证书登录 Azure AD 以建立连接。为此，您需要 ScriptRunner 服务器上的有效证书。该证书必须存储在 ScriptRunner 服务器上的本地证书存储中。

有关设置基于证书的 Azure AD 登录的信息，请参阅 Microsoft Docs：Azure Active Directory：基于证书的身份验证。

必须在目标系统的配置中输入证书指纹和应用程序 ID。

Azure 和其他云服务

使用 Az 模块的 Azure 管理还允许基于证书登录进行连接设置（图 9）。为此，您需要 ScriptRunner 服务器上的有效证书。该证书必须存储在 ScriptRunner 服务器上的本地证书存储中。

必须使用 Az 在目标系统的配置中输入证书指纹和应用程序 ID。

为了使用 PowerShell 管理其他云服务，我们实施了一种新的目标系统类型，即通用云目标（图 10）。这允许您输入 PowerShell 命令序列以建立和断开连接。此外，可以将特定模块加载到连接过程中。

在用于建立连接的 PowerShell 代码中，可以使用变量 $Cred。该变量分配有为目标系统配置的访问凭据。

图 10：新的目标系统类型“通用云目标”允许使用 PowerShell 和 ScriptRunner 管理其他云服务。

通过管理/跳转主机进行 PowerShell 远程处理

使用所谓的管理或跳转主机在基础设施管理方面有着悠久的传统。通常，此类系统上安装了许多管理工具，并且只有选定的管理员才有权访问机器和工具。主要优点是工具只需要在一个位置更新，并且可以控制从外部对工具的访问。

原则上，这个概念也适用于分布式环境中的PowerShell。例如，可以构建特定于站点的 PowerShell 跳转主机，在其上安装所有必需的 PowerShell 模块并可以执行脚本。

ScriptRunner 扩展了这一概念，使用跳转主机作为其他目标系统的“分发节点”（图 11）。这以策略驱动的方式绕过了经典的双跳问题。

除了纯粹的“分发节点”之外，现在还可以构建简单的混合目标场景，例如在远程目标系统上执行脚本并从那里直接访问 O365 或 Azure 客户端的资源。

还可以通过跳转主机链来寻址目标系统。

此功能还用于 PowerShell Direct 来管理 Hyper-V 主机中的虚拟机或 Windows 容器服务主机中的容器。

图 11：ScriptRunner 可以使用跳转主机作为其他目标系统的“分发节点”或通过跳转主机链寻址目标系统。

为了实际使用此功能，必须满足以下要求：

• Jump 主机配置为具有标准 PowerShell 远程处理的目标系统
• 实际的目标系统已配置。这些目标系统还可以是通过 PowerShell Direct 的云服务、虚拟机和容器。
• 使用“通过管理或跳转主机间接访问该目标”功能在实际目标系统上进行配置。必须选择适当的主机。
• 为了控制连接和执行脚本的访问权限以及使用“跳板”，需要使用存储在相应目标系统上的凭据。

提示：PowerShell 报告记录了通过跳转主机的连接。例如，如果要在测试期间记录详细信息，则必须激活 PowerShell 选项下 ScriptRunner 操作中的 Verbose 开关。

适用于 Hyper-V、容器和 CIM 的 PowerShell 远程处理

PowerShell 脚本可以在远程目标系统上执行。 ScriptRunner 从一开始就支持这种可能性，现在已经通过其他选项进行了扩展。创建新的 PowerShell 远程处理目标时可以设置其他选项。

PowerShell Direct 是微软开发的一种方法，旨在扩展 PowerShell 在虚拟化环境中的使用，并减少连接到 Windows 容器服务下的 Hyper-V 或 Docker 容器下的虚拟机的开销。它还有助于避免双跳问题。

在经典 PowerShell 远程处理中，必须与每个虚拟机或容器建立直接连接和 PowerShell 会话。使用 PowerShell Direct 时，可以建立与 Hyper-V 主机或容器主机的远程会话。然后可以直接使用虚拟机或容器的 ID 或名称来寻址。

CIM 会话选项使您能够设置和使用与标准化 CIM 端点的连接。 Windows Management Instrumentation 支持 CIM。

要设置 PowerShell Direct（如示例所示），必须在 Hyper-V 或容器主机上使用标准 PowerShell 远程处理设置目标系统（图 12）。虚拟机或容器通过 PowerShell Direct 选项以及 Hyper-V（对于虚拟机）或容器服务（对于 Docker 容器）设置为附加目标系统。

如示例中所示，VM 名称或 VM ID 可用于此目的。访问凭证需要虚拟机中相应的PowerShell执行权限。

图 12：在 ScriptRunner 中设置 VM 或容器作为目标系统。

为了能够使用 PowerShell Direct 通过主机控制虚拟机，必须在 ScriptRunner 的目标虚拟机配置中将 Hyper-V 主机指定为“间接通过管理或跳转主机”（图 13）。同样，容器目标系统是与容器主机一起设置的。

要获取配置的容器 ID，您可以在加载 PowerShell 模块容器后在容器主机上执行 Get-Container 命令。

图 13：为了能够使用 PowerShell Direct 通过主机控制虚拟机，必须在目标系统的配置中选择“通过管理或间接跳转主机访问此目标...”选项。

使用 PowerShell PSSession 的多目标场景

在 PowerShell 的实际使用中，特别是在自动化中，需要访问不同的系统来处理脚本，例如到内部 AD 和 Azure AD、到本地 Exchange 和 Exchange Online、到 Windows Server 和不同的共享或数据库。

这些场景的共同点是，必须在脚本运行时访问不同的系统，每个系统都有自己的系统权限。

为此，PowerShell 本身提供了会话的概念。例如，您可以使用 New-PSSession cmdlet 在命令行上创建不同会话并在不同会话之间切换。此外，前缀功能允许您自动检测应在哪个会话中运行特定命令。

现在，您可以直接在 ScriptRunner 中使用此 PowerShell 功能来实现多目标场景。您需要在 PowerShell 脚本的参数块中定义所需会话的参数。

Param
(
…
# PowerShell Remoting Session Type
[System.Management.Automation.Runspaces.PSSession]
$Session1,
[System.Management.Automation.Runspaces.PSSession]
$Session2,
# PowerShell CIM Session Type
[Microsoft.Management.Infrastructure.CimSession]
$cimsession,
…
)

在 ScriptRunner 操作的参数配置中，可以使用下拉选择将会话参数分配给目标系统（图 14）。

图 14：在 ScriptRunner 操作的参数配置中，您可以通过下拉列表将会话参数分配给目标系统。

每次启动脚本之前，ScriptRunner 都会在运行时建立与存储的目标系统的连接。关联的 PSSession 对象作为参数传递给脚本。执行脚本后，ScriptRunner 将自动终止会话。

会话在脚本本身中使用。要么用程序行

Invoke-Command -Session $Session1 -ScriptBlock { ... }
# or
Import-PSSession -Session $Session1 -Modules ...

这使得脚本开发更加容易。一方面，会话建立和终止不再需要编码，另一方面，可以在脚本中非常轻松地实现多目标场景。此外，使用不同的管理凭据时，安全性也会得到提高，因为脚本中只能使用会话，而不能使用用户名/密码或凭据。

在查询中使用 PowerShell 对象

自 2018R1 版本以来，查询是 ScriptRunner 中的一项重要功能。除了 Active Directory 查询的多功能用途之外，脚本查询已成为实现用例的非常灵活的工具。

在 UI 中提供用于参数选择的下拉菜单的基本思想现已扩展到脚本查询。除了单个字符串值之外，现在还可以传递 PowerShell 对象。

由于脚本查询和主脚本各自在自己的 PowerShell 进程中运行，因此对象值必须在两个单独的 PowerShell 进程之间传递。哈希表和 PowerShell 自定义对象都可以用于此目的。要使用它们，必须在查询脚本和主脚本中定义哈希表或自定义对象。各个值作为 base64 编码字符串从查询传递到主脚本。

查询脚本将哈希表的编码值填充到系统变量 $SRXEnv.ResultList 中，而不是单个字符串。

系统变量$SRXEnv.ResultList2存储要传递的对象的名称。因此，该过程类似于已知的脚本查询过程。如果使用自定义对象而不是哈希表，则过程类似。

# Declaration Hashtable in param block
$hasht = @{ Name = ''; Age = 0 }
# Function code of query with foreach loop
…
$hasht.Name = 'Paul'
$hasht.Age = 31
# Filling the hashtable 
	if ($SRXEnv) {
	$null = $SRXEnv.ResultList.Add($hasht)
	$null = $SRXEnv.ResultList2.Add($hasht.Name)
}

测试查询时，用字符串编码的值显示在表列“参数值”中。

在主脚本中，哈希表或自定义对象也在 param 块中声明。该声明必须与查询脚本中使用的形式相对应。此参数链接到操作中的查询，以便可以在运行时将编码的哈希表或自定义对象的值传递到主脚本。

当用户启动操作时，查询会在选择下拉列表中返回命名对象的列表。用户选择一个命名对象，并将编码值传递到主脚本。 ScriptRunner 使用主脚本中声明的参数类型来解码传输的字符串，并将各个值分配给哈希表或自定义对象中的相应属性。

可以直接访问属性。

….
# from declaration of the hashtable as above
$Age = $hasht.Age

PowerShell机密管理模块注意事项

新的 PowerShell Secrets Management 模块支持使用存储在 Windows 凭据存储中的凭据以及来自密码服务器的凭据请求。该模块仅在本地运行，即它必须安装在 ScriptRunner Server 上。

由于其架构的原因，它的使用仅限于本地脚本执行。

相反，在 ScriptRunner 环境中该模块没有任何附加价值。只有使用 ScriptRunner，才能远程执行脚本（甚至跨 Jump Host），同时在 ScriptRunner 和密码服务器中维护集中式凭证管理。