你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

了解 Azure 机器配置

项目
02/01/2024

注意

本文引用了 CentOS，这是一个接近生命周期结束 (EOL) 状态的 Linux 发行版。请相应地考虑你的使用和规划。有关详细信息，请参阅 CentOS 生命周期结束指导。

Azure Policy 的机器配置功能提供了将操作系统设置作为代码进行审核或配置的本机功能，同时适用于在 Azure 中运行的计算机和混合已启用 Arc 的计算机。可以直接在每台计算机上使用该功能，也可以使用 Azure Policy 进行大规模编排。

Azure 中的配置资源被设计为扩展资源。可以将每个配置想象为计算机的一组额外属性。配置可以包含如下设置：

操作系统设置
应用程序配置或状态
环境设置

配置不同于策略定义。机器配置利用 Azure Policy 将配置动态分配给计算机。还可以手动或使用其他 Azure 服务（例如 Automanage）为计算机分配配置。

下表中提供了每个场景的示例。

类型	描述	示例情景
配置管理	你需要服务器的完整表示形式，作为源代码管理中的代码。部署应包括服务器的属性（大小、网络、存储）和操作系统以及应用程序设置的配置。	“此计算机应为配置为托管我的网站的 Web 服务器。”
遵从性	你需要审核范围内所有计算机的设置，或者部署设置：要么是被动地部署到现有计算机，要么是在部署新计算机时主动部署到其中。	“所有计算机应使用 TLS 1.2。审核现有计算机，以便能够以受控方式大规模发布所需的更改。对于新计算机，在它们部署时强制实施设置。

可以在“来宾分配”页的配置中查看每项设置的结果。如果 Azure Policy 分配已编排配置，并且要对该分配进行编排，则可以在“合规性详细信息”页面上选择“最后评估的资源”链接。

提供本文档的视频演练。（即将推出更新）

启用计算机配置

若要管理环境中计算机（包括 Azure 中的计算机和已启用 Arc 的服务器）的状态，请查看以下详细信息。

资源提供程序

在使用 Azure Policy 的计算机配置功能之前，必须先注册 Microsoft.GuestConfiguration 资源提供程序。如果计算机配置策略的分配是通过门户完成的，或者如果订阅已在 Microsoft Defender for Cloud 内注册，则会自动注册该资源提供程序。可以通过门户、Azure PowerShell 或 Azure CLI 手动注册。

部署 Azure 虚拟机的要求

若要管理计算机内部的设置，需要启用虚拟机扩展，并且该计算机必须具有系统托管标识。该扩展下载适用的机器配置分配和相应的依赖项。该标识用于在计算机读取和写入计算机配置服务时对计算机进行身份验证。已启用 Arc 的服务器不需要该扩展，因为已连接 Arc 的计算机代理中包含该扩展。

重要

需要使用计算机配置扩展和托管标识来管理 Azure 虚拟机。

若要跨多个计算机大规模部署该扩展，请将策略计划分配到Deploy prerequisites to enable Guest Configuration policies on virtual machines 到包含你要管理的计算机的管理组、订阅或资源组。

如果你倾向于将扩展和托管标识部署到单个计算机，请参阅使用 Azure 门户在 VM 上为 Azure 资源配置托管标识。

要使用计算机配置包来应用配置，需要安装 Azure VM 来宾配置扩展版本 1.26.24 或更高版本。

对扩展设置的限制

为了限制扩展对计算机内部运行的应用程序的影响，计算机配置代理的 CPU 消耗不得超过 CPU 的 5%。对于内置和自定义的定义都存在此限制。对于已连接 Arc 的计算机代理中的计算机配置服务也是如此。

验证工具

在计算机内，计算机配置代理使用本地工具执行任务。

下表列出了每个受支持的操作系统上使用的本地工具。对于内置内容，计算机配置会自动处理这些工具的加载。

操作系统	验证工具	说明
Windows	PowerShell Desired State Configuration v2	侧加载到仅由 Azure Policy 使用的文件夹。不要与 Windows PowerShell DSC 冲突。 PowerShell 不会添加到系统路径。
Linux	PowerShell Desired State Configuration v3	侧加载到仅由 Azure Policy 使用的文件夹。 PowerShell 不会添加到系统路径。
Linux	Chef InSpec	在默认位置安装 Chef InSpec 版本 2.2.61，并将其添加到系统路径。此安装还会安装 InSpec 的依赖项，包括 Ruby 和 Python。

验证频率

计算机配置代理每 5 分钟检查一次新的或更改的来宾分配。在收到来宾分配后，将按 15 分钟的时间间隔重新检查该配置的设置。如果分配了多个配置，将按顺序评估每个配置。长时间运行的配置会影响所有配置的间隔，因为只有在前一个配置完成之后，才会运行下一个配置。

审核完成后，结果将发送到计算机配置服务。当策略评估触发器执行时，会将计算机状态写入到计算机配置资源提供程序。此更新会使 Azure Policy 评估 Azure 资源管理器属性。按需 Azure Policy 评估会从计算机配置资源提供程序检索最新值。但是，它不会在计算机中触发新活动。然后，状态将写入 Azure Resource Graph。

支持的客户端类型

计算机配置策略定义包含新版本。如果来宾配置客户端不兼容，则会排除 Azure 市场中提供的旧版操作系统。下表显示了 Azure 映像上支持的操作系统列表。 .x 文本是表示 Linux 发行版的新次要版本的符号。

发布者	名称	版本
Alma	AlmaLinux	9
Amazon	Linux	2
Canonical	Ubuntu Server	14.04 - 22.x
Credativ	Debian	8 - 10.x
Microsoft	CBL-Mariner	1 - 2
Microsoft	Windows 客户端	Windows 10
Microsoft	Windows Server	2012 - 2022
Oracle	Oracle-Linux	7.x - 8.x
OpenLogic	CentOS	7.3 - 8.x
Red Hat	Red Hat Enterprise Linux*	7.4 - 9.x
Rocky	Rocky Linux	9
SUSE	SLES	12 SP3-SP5、15.x

* 不支持 Red Hat CoreOS。

机器配置策略定义支持自定义虚拟机映像，但前提是它们必须是上表中的操作系统之一。

网络要求

Azure 虚拟机可以使用其本地虚拟网络适配器 (vNIC) 或 Azure 专用链接与计算机配置服务通信。

已启用 Azure Arc 的计算机使用本地网络基础结构连接到 Azure 服务并报告符合性状态。

以下是 Azure 和已启用 Azure Arc 的虚拟机与 Azure 中的计算机配置资源提供程序通信所需的 Azure 存储终结点列表：

oaasguestconfigac2s1.blob.core.windows.net
oaasguestconfigacs1.blob.core.windows.net
oaasguestconfigaes1.blob.core.windows.net
oaasguestconfigases1.blob.core.windows.net
oaasguestconfigbrses1.blob.core.windows.net
oaasguestconfigbrss1.blob.core.windows.net
oaasguestconfigccs1.blob.core.windows.net
oaasguestconfigces1.blob.core.windows.net
oaasguestconfigcids1.blob.core.windows.net
oaasguestconfigcuss1.blob.core.windows.net
oaasguestconfigeaps1.blob.core.windows.net
oaasguestconfigeas1.blob.core.windows.net
oaasguestconfigeus2s1.blob.core.windows.net
oaasguestconfigeuss1.blob.core.windows.net
oaasguestconfigfcs1.blob.core.windows.net
oaasguestconfigfss1.blob.core.windows.net
oaasguestconfiggewcs1.blob.core.windows.net
oaasguestconfiggns1.blob.core.windows.net
oaasguestconfiggwcs1.blob.core.windows.net
oaasguestconfigjiws1.blob.core.windows.net
oaasguestconfigjpes1.blob.core.windows.net
oaasguestconfigjpws1.blob.core.windows.net
oaasguestconfigkcs1.blob.core.windows.net
oaasguestconfigkss1.blob.core.windows.net
oaasguestconfigncuss1.blob.core.windows.net
oaasguestconfignes1.blob.core.windows.net
oaasguestconfignres1.blob.core.windows.net
oaasguestconfignrws1.blob.core.windows.net
oaasguestconfigqacs1.blob.core.windows.net
oaasguestconfigsans1.blob.core.windows.net
oaasguestconfigscuss1.blob.core.windows.net
oaasguestconfigseas1.blob.core.windows.net
oaasguestconfigsecs1.blob.core.windows.net
oaasguestconfigsfns1.blob.core.windows.net
oaasguestconfigsfws1.blob.core.windows.net
oaasguestconfigsids1.blob.core.windows.net
oaasguestconfigstzns1.blob.core.windows.net
oaasguestconfigswcs1.blob.core.windows.net
oaasguestconfigswns1.blob.core.windows.net
oaasguestconfigswss1.blob.core.windows.net
oaasguestconfigswws1.blob.core.windows.net
oaasguestconfiguaecs1.blob.core.windows.net
oaasguestconfiguaens1.blob.core.windows.net
oaasguestconfigukss1.blob.core.windows.net
oaasguestconfigukws1.blob.core.windows.net
oaasguestconfigwcuss1.blob.core.windows.net
oaasguestconfigwes1.blob.core.windows.net
oaasguestconfigwids1.blob.core.windows.net
oaasguestconfigwus2s1.blob.core.windows.net
oaasguestconfigwus3s1.blob.core.windows.net
oaasguestconfigwuss1.blob.core.windows.net

通过 Azure 中的虚拟网络进行通信

要与 Azure 中的机器配置资源提供程序通信，计算机需要对端口 443 上的 Azure 数据中心进行出站访问。如果 Azure 中的网络不允许出站流量，请使用网络安全组规则配置异常。可使用服务标记AzureArcInfrastructure 和 Storage 引用来宾配置和存储服务，而不必手动维护 Azure 数据中心的 IP 范围列表。这两个标记都是必需的，因为机器配置内容包由 Azure 存储托管。

通过 Azure 中的专用链接通信

虚拟机可以使用专用链接与计算机配置服务通信。应用名称为 EnablePrivateNetworkGC 且值为 TRUE 的标签以启用此功能。在将计算机配置策略定义应用到计算机之前或之后，可以应用该标记。

重要

要通过自定义包的专用链接进行通信，必须将指向包位置的链接添加到允许的 URL 列表中。

流量使用 Azure 虚拟公共 IP 地址进行路由，以便使用 Azure 平台资源建立经过身份验证的安全通道。

通过 Azure 外部的公共终结点进行通信

通过将位于本地或其他云中的服务器连接到 Azure Arc，可以使用计算机配置对其进行管理。

对于已启用 Azure Arc 的服务器，允许使用以下模式的流量：

端口：只需使用 TCP 443 即可进行出站 Internet 访问
全局 URL：*.guestconfiguration.azure.com

有关 Azure Connected Machine Agent 针对核心 Azure Arc 和计算机配置方案所需的所有网络终结点的完整列表，请参阅已启用 Azure Arc 的服务器网络要求。

通过 Azure 外部的专用链接进行通信

将专用链接与已启用 Arc 的服务器配合使用时，将通过专用链接自动下载内置策略包。无需在已启用 Arc 的服务器上设置任何标记即可启用此功能。

将策略分配给 Azure 之外的计算机

适用于计算机配置的审核策略定义包括 Microsoft.HybridCompute/machines 资源类型。将自动包括载入到策略分配范围内已启用 Azure Arc 的服务器的任何计算机。

托管标识要求

Deploy prerequisites to enable guest configuration policies on virtual machines 计划中的策略定义会启用系统分配的托管标识（如果不存在）。计划中有两个管理标识创建的策略定义。策略定义中的 if 条件基于 Azure 中计算机资源的当前状态确保行为正确。

重要

除了现有的用户分配的标识（若有）之外，这些定义还将在目标资源上创建系统分配的托管标识。对于现有应用程序，除非在请求中指定用户分配的标识，否则计算机将默认使用系统分配的标识。了解详细信息

如果计算机当前没有任何托管标识，则有效策略是：添加系统分配的托管标识，在没有标识的虚拟机上启用来宾配置分配

如果计算机当前具有用户分配的系统标识，则有效策略是：添加系统分配的托管标识，在具有用户分配的标识的 VM 上启用来宾配置分配

可用性

设计高度可用解决方案的客户应考虑虚拟机的冗余计划要求，因为来宾分配是 Azure 中计算机资源的扩展。将来宾分配资源预配到配对的 Azure 区域时，只要该对中至少有一个区域可用，就可查看来宾分配报告。如果 Azure 区域未配对且变得不可用，则无法访问来宾分配报告。可以在区域还原后再次访问报告。

最佳做法是，将具有相同参数的相同策略定义分配给解决方案中的所有计算机，以实现高可用性应用程序。这种方法对于在负载均衡器解决方案后面的可用性集中预配虚拟机的情况尤其适用。跨所有计算机的单个策略分配的管理开销最小。

对于受 Azure Site Recovery 保护的计算机，请确保主站点和辅助站点中的计算机处于相同定义的 Azure Policy 分配范围内。对两个站点使用相同的参数值。

数据驻留

机器配置会存储和处理客户数据。默认情况下，客户数据将复制到配对区域。对于新加坡、巴西南部和东亚区域，所有客户数据将在该区域中进行存储和处理。

计算机配置故障排除

有关对计算机配置进行故障排除的详细信息，请参阅 Azure Policy 故障排除。

多个分配

目前，只有某些内置的计算机加配置策略定义支持多个分配。但是，如果使用最新版本的 GuestConfiguration PowerShell 模块创建机器配置包和策略，则在默认情况下，所有自定义策略都支持多个分配。

下面是支持多个分配的内置机器配置策略定义列表：

ID	DisplayName
/providers/Microsoft.Authorization/policyDefinitions/5fe81c49-16b6-4870-9cee-45d13bf902ce	应在 Windows 服务器上禁用本地身份验证方法
/providers/Microsoft.Authorization/policyDefinitions/fad40cac-a972-4db0-b204-f1b15cced89a	应在 Linux 计算机上禁用本地身份验证方法
/providers/Microsoft.Authorization/policyDefinitions/f40c7c00-b4e3-4068-a315-5fe81347a904	[预览]：添加用户分配的托管标识，以在虚拟机上启用来宾配置分配
/providers/Microsoft.Authorization/policyDefinitions/63594bb8-43bb-4bf0-bbf8-c67e5c28cb65	：Linux 计算机应满足 Azure 计算的 STIG 合规性要求
/providers/Microsoft.Authorization/policyDefinitions/50c52fc9-cb21-4d99-9031-d6a0c613361c	[预览]：Windows 计算机应满足 Azure 计算的 STIG 合规性要求
/providers/Microsoft.Authorization/policyDefinitions/e79ffbda-ff85-465d-ab8e-7e58a557660f	：安装了 OMI 的 Linux 计算机应具有版本 1.6.8-1 或更高版本
/providers/Microsoft.Authorization/policyDefinitions/934345e1-4dfb-4c70-90d7-41990dc9608b	审核在受信任的根中不包含指定证书的 Windows 计算机
/providers/Microsoft.Authorization/policyDefinitions/08a2f2d2-94b2-4a7b-aa3b-bb3f523ee6fd	审核 DSC 配置不合规的 Windows 计算机
/providers/Microsoft.Authorization/policyDefinitions/c648fbbb-591c-4acd-b465-ce9b176ca173	审核没有指定的 Windows PowerShell 执行策略的 Windows 计算机
/providers/Microsoft.Authorization/policyDefinitions/3e4e2bd5-15a2-4628-b3e1-58977e9793f3	审核没有安装指定 Windows PowerShell 模块的 Windows 计算机
/providers/Microsoft.Authorization/policyDefinitions/58c460e9-7573-4bb2-9676-339c2f2486bb	审核未启用 Windows 串行控制台的 Windows 计算机
/providers/Microsoft.Authorization/policyDefinitions/e6ebf138-3d71-4935-a13b-9c7fdddd94df	审核未安装指定的服务且“正在运行”的 Windows 计算机
/providers/Microsoft.Authorization/policyDefinitions/c633f6a2-7f8b-4d9e-9456-02f0f04f5505	审核未设置为指定时区的 Windows 计算机

注意

请定期查看此页面，了解支持多个分配的内置机器配置策略定义列表的更新。

给 Azure 管理组的任务

当效果为 AuditIfNotExists 或 DeployIfNotExists 时，可以将“Guest Configuration”类别中的 Azure Policy 定义分配到管理组。

客户端日志文件

计算机配置扩展将日志文件写入以下位置：

Windows

Azure VM：C:\ProgramData\GuestConfig\gc_agent_logs\gc_agent.log
已启用 Arc 的服务器：C:\ProgramData\GuestConfig\arc_policy_logs\gc_agent.log

Linux

Azure VM：/var/lib/GuestConfig/gc_agent_logs/gc_agent.log
已启用 Arc 的服务器：/var/lib/GuestConfig/arc_policy_logs/gc_agent.log

远程收集日志

对计算机配置或模块进行故障排除的第一步应该是按照如何测试计算机配置包工件中的步骤使用 cmdlet。如果未成功，则收集客户端日志有助于诊断问题。

Windows

使用 Azure VM 运行命令从日志文件中捕获信息，下面的示例 PowerShell 脚本可能会很有帮助。

$linesToIncludeBeforeMatch = 0
$linesToIncludeAfterMatch  = 10
$params = @{
    Path = 'C:\ProgramData\GuestConfig\gc_agent_logs\gc_agent.log'
    Pattern = @(
        'DSCEngine'
        'DSCManagedEngine'
    )
    CaseSensitive = $true
    Context = @(
        $linesToIncludeBeforeMatch
        $linesToIncludeAfterMatch
    )
}
Select-String @params | Select-Object -Last 10

Linux

使用 Azure VM 运行命令从日志文件中捕获信息，下面的示例 Bash 脚本可能会很有帮助。

LINES_TO_INCLUDE_BEFORE_MATCH=0
LINES_TO_INCLUDE_AFTER_MATCH=10
LOGPATH=/var/lib/GuestConfig/gc_agent_logs/gc_agent.log
egrep -B $LINES_TO_INCLUDE_BEFORE_MATCH -A $LINES_TO_INCLUDE_AFTER_MATCH 'DSCEngine|DSCManagedEngine' $LOGPATH | tail

代理文件

计算机配置代理将内容包下载到计算机中并提取其内容。要验证已下载和存储的内容，请查看以下列表中的文件夹位置。

Windows： C:\ProgramData\guestconfig\configuration
Linux：/var/lib/GuestConfig/Configuration

开放源代码 nxtool 模块功能

新的开放源代码 nxtool 模块已经发布，以帮助 PowerShell 用户更轻松地管理 Linux 系统。

该模块将有助于管理常见任务，例如：

管理用户和组
执行文件系统操作
管理服务
执行存档操作
管理包

该模块包括用于 Linux 的基于类的 DSC 资源，以及内置的机器配置包。

要提供有关此功能的反馈，请在文档上打开问题。目前不接受此项目的 PR，尽力提供最大的支持。

计算机配置示例

以下位置提供了计算机配置内置策略示例：

后续步骤

设置自定义计算机配置包开发环境。
为计算机配置创建包项目。
从开发环境测试包项目。
使用 GuestConfiguration 模块创建 Azure Policy 定义，用于对环境进行大规模管理。
使用 Azure 门户分配自定义策略定义。
了解如何查看计算机配置策略分配的合规性详细信息。

了解 Azure 机器配置

启用计算机配置

资源提供程序

部署 Azure 虚拟机的要求

对扩展设置的限制

验证工具

验证频率

支持的客户端类型

网络要求

通过 Azure 中的虚拟网络进行通信

通过 Azure 中的专用链接通信

通过 Azure 外部的公共终结点进行通信

通过 Azure 外部的专用链接进行通信

将策略分配给 Azure 之外的计算机

托管标识要求

可用性

数据驻留

计算机配置故障排除

多个分配

给 Azure 管理组的任务

客户端日志文件

远程收集日志

Windows

Linux

代理文件

开放源代码 nxtool 模块功能

计算机配置示例

后续步骤

其他资源