23、配置管理与故障排查指南

tensorflowjs6

于 2025-11-10 12:19:54 发布

阅读量19

点赞数

CC 4.0 BY-SA版权

分类专栏：三十天精通ConfigMgr 文章标签： ConfigMgr 客户端合规性 DNS

本文链接：https://blog.youkuaiyun.com/tensorflowjs6/article/details/154727917

三十天精通ConfigMgr 专栏收录该内容

25 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

配置管理与故障排查指南

1. 客户端合规性管理

首先，我们需要对客户端进行一些配置，以确保系统的合规性。以下是具体的操作步骤：
1. 导航到“计算机代理”部分，将“PowerShell执行策略”更改为“绕过”（在生产环境中，建议对脚本进行签名）。
2. 返回“合规性基线”，右键单击“所有实验室客户端”的合规性基线（CB），选择“部署”。
3. 使用以下属性部署基线：
- 集合：所有Windows 10客户端
- 简单计划：每天一次
4. 在CLIENT01上运行机器策略检索，使系统获取更改。

部署基线后，我们可以模拟打印问题，观察ConfigMgr如何处理和修复：
1. 登录到CLIENT01，启动Configuration Manager客户端，导航到“配置”选项卡，应能看到分配给设备集合的合规性基线。
2. 基线将根据部署时指定的计划（每天一次）进行评估，也可以手动强制评估。高亮显示基线并选择“评估”，基线属性将改变，应显示为“合规”。可以通过DCMAgent.log和DCMReporting.log文件监控代理的合规性活动。
3. 返回CM01，进入“合规性基线”，已部署的基线应显示合规计数为1，表示至少有一个客户端已检查合规且该客户端确实合规。若未显示，可从工具栏选择“运行汇总”并刷新控制台。
4. 模拟故障：在CLIENT01上，打开提升权限的PowerShell窗口，输入 Stop-Service –Name Spooler 停止打印假脱机程序服务；输入 Get-Service –Name Spooler 验证服务状态，“状态”应为“已停止”；再次评估基线，结果应为“不合规”；回到CM01，刷新基线，合规计数变为0，不合规计数变为1。
5. 配置自动修复：在CM01上，导航到“配置项”，右键单击“Windows打印假脱机程序服务”的配置项（CI），选择“属性”；进入“合规性规则”选项卡，选择单个规则并删除；进入“设置”选项卡，编辑“打印假脱机程序运行状态”设置；添加一个修复脚本，脚本语言选择“Windows PowerShell”，代码为 Start-Service –Name Spooler ；点击“确定”，返回“合规性规则”选项卡，创建一个新规则，名称为“打印假脱机程序服务正在运行”，脚本返回值“等于”“正在运行”，勾选“运行修复脚本”；点击“确定”并关闭配置项；在CLIENT01上触发另一次机器策略更新；评估基线，合规性应变为“合规”。
6. 验证修复结果：选择“查看报告”并滚动到报告末尾，会看到合规性脚本返回“已停止”，触发修复脚本运行，之后返回“正在运行”，表示基线再次合规；在PowerShell中使用 Get-Service –Name Spooler 验证服务是否再次运行；在CM01上检查合规计数是否已恢复。

2. 实验室操作

可以通过导入Microsoft Security Compliance Manager（SCM）的合规性基线来评估生产环境的安全性和配置情况，具体步骤如下：
1. 下载Microsoft Security Compliance Manager并安装在CM01上（可使用现有的SQL Server实例）。
2. 启动SCM，从Microsoft下载最新的基线。
3. 将Win8.1计算机安全合规性基线导出为SCCM 2007 DCM CAB文件（目前没有Windows 10的合规性基线，但Windows 8.1的基线可用）。
4. 将CAB文件作为合规性数据导入ConfigMgr。
5. 验证合规性项和合规性基线是否已成功创建。
6. 将Win8.1计算机安全合规性基线部署到“所有Windows 10客户端”集合（不启用修复）。
7. 评估并报告已部署的基线。

3. 评估站点健康

ConfigMgr会持续监控和评估层次结构内的所有角色和组件，可通过以下方式快速了解环境的健康状况：
1. 在ConfigMgr控制台中，导航到“监控”>“系统状态”>“站点状态”，此窗格显示当前安装在层次结构中的所有站点系统角色的健康状况。
2. 若要查看每个角色的底层状态，右键单击角色并选择“显示消息”>“所有”，将启动Configuration Manager状态消息查看器。可显示特定时间范围内的消息或全部消息，由于显示全部消息会返回大量数据，建议使用“视图”>“筛选”选项根据消息严重性、ConfigMgr组件等缩小结果范围。
3. 也可以导航到“监控”>“系统状态”>“组件状态”，此窗格会详细列出整个层次结构中所有ConfigMgr组件的状态，包括已监控和未监控的组件。

为了观察状态监控的工作原理，我们可以模拟一个组件故障：
1. 在CM01上，启动“SQL Server Reporting Services配置管理器”。
2. 连接到CM01上的ReportServer实例，在主页面选择“停止”，停止SQL Reporting服务器，同时保持主SQL数据库服务运行。
3. 返回ConfigMgr控制台，导航到“监控”>“系统状态”>“组件状态”。
4. 右键单击“SMS_SRS_REPORTING_POINT”，选择“显示消息”>“所有”，会看到警告状态以及一些关于问题的信息消息，并建议解决步骤。
5. 打开srsrp.log文件，会看到定期记录的错误，因为每分钟都会检查依赖于SQL Reporting Services的报表服务点的健康状况。滚动到第一个错误实例，会看到以“STATMSG: ID=7403”开头的日志条目，这就是步骤4中看到的状态消息的来源。
6. 在控制台中刷新“组件状态”页面，“SMS_SRS_REPORTING_POINT”组件应显示为“警告”状态。如果服务保持离线且记录了足够多的错误状态消息，状态将变为“错误”，报表服务点角色也将被标记为不健康。
7. 修复问题：打开ReportServer服务，检查srsrp.log文件确保更改已被获取；在“组件状态”中，右键单击“SMS_SRS_REPORTING_POINT”，选择“重置计数”>“错误”，将该组件的错误记录数重置为零，几分钟后组件状态应恢复为“正常”。

4. 常见环境问题及解决方法

4.1 磁盘空间

ConfigMgr服务器磁盘空间不足会导致严重问题，虽然ConfigMgr有内置警报监控承载站点数据库文件的磁盘，但它不会对其他磁盘的低空间情况发出警报。可以通过以下步骤让ConfigMgr自动监控磁盘空间：
1. 在控制台中，导航到“管理”>“客户端设置”。
2. 修改现有客户端策略或创建新策略。
3. 选择“硬件清单”>“设置类”。
4. 展开“逻辑磁盘（SMS_LogicalDisk）”，选择“可用空间（MB）”。
5. 保存并应用策略。

ConfigMgr现在会在定期的硬件清单扫描中收集每个磁盘的可用空间信息，可以使用这些信息构建设备集合，或使用“监控”>“报告”>“报告”>“硬件”>“磁盘”中的内置可用空间报告。需要注意的是，在服务器操作系统上安装ConfigMgr代理需要特定许可证，也可以使用System Center 2012 Operations Manager R2（SCOM）进行更快速的实时监控。

4.2 Active Directory

在域加入的系统上安装ConfigMgr客户端时，客户端默认会在Active Directory中特定位置检索相关信息。ConfigMgr需要将这些信息写入Active Directory，因此每个发布服务器需要有相应权限。可以通过以下步骤查看权限设置：
1. 登录到DC01，启动“Active Directory用户和计算机”。
2. 选择“视图”>“高级功能”。
3. 展开mol.sccmlab.net>“系统”>“系统管理”，可以看到该容器中已存在mSSMSSite和mSSMS-ManagementPoint条目，这些是由CM01添加的。
4. 右键单击“系统管理”，选择“属性”，进入“安全”选项卡，找到ConfigMgr服务器的AD计算机对象（如CM01$），该对象应具有对该容器的完全控制权限，这是主站点服务器向Active Directory发布信息所必需的。

默认情况下，“系统管理”容器在Active Directory中不存在，需要手动（或通过编程）创建，并且AD架构需要扩展以容纳ConfigMgr特定的条目。如果域加入的客户端无法与应关联的站点/管理点通信，可以考虑以下问题：主站点服务器是否向“系统管理”容器发布信息；如果没有，主站点服务器是否有相应权限；“系统管理”容器是否已创建。受影响客户端上的ClientLocation.log文件也能提供详细信息。

4.3 DNS

ConfigMgr是一个域加入的系统，Active Directory高度依赖域名解析（DNS），因此DNS问题可能会导致ConfigMgr出现更广泛的问题。可以通过以下方法检测DNS问题：
1. 在CM01上，打开命令窗口，输入 PING REMOTE01.mol.sccmlab.net 。
2. 在REMOTE01上，打开命令窗口，输入 PING CM01.mol.sccmlab.net 。

每个本地服务器应能够使用DNS将远程服务器的名称解析为其分配的IP地址。如果无法解析IP地址或解析到错误的IP地址，则存在DNS问题，可能是DNS服务器本身的问题，也可能是一台或多台服务器上的DNS配置错误。

另外，如果DNS清理功能未启用，ConfigMgr可能会出现混淆。可以通过以下步骤检查DNS清理是否启用：
1. 登录到DC01，启动DNS管理单元。
2. 展开DC01，选择mol.sccmlab.net。
3. 在正向查找区域下，右键单击“mol.sccmlab.net”，选择“属性”。
4. 在“常规”选项卡上，选择“老化”。
5. 应启用“清理陈旧资源记录”，若未启用则启用它。

通过以上步骤，我们可以有效地管理客户端合规性，评估站点健康状况，并解决常见的环境问题，确保ConfigMgr系统的稳定运行。

以下是一个简单的mermaid流程图，展示了模拟打印问题及修复的流程：

graph LR
    A[部署基线] --> B[模拟打印问题]
    B --> C[评估基线（不合规）]
    C --> D[配置自动修复]
    D --> E[再次评估基线（合规）]

配置管理与故障排查指南

5. 综合案例分析

为了更好地理解上述配置管理和故障排查的方法，我们来看一个综合案例。假设在一个企业环境中，使用ConfigMgr进行客户端管理，突然出现部分客户端无法正常获取软件更新的问题。我们可以按照以下步骤进行排查：

5.1 初步评估

首先，我们需要对整个环境的健康状况进行初步评估。
- 进入ConfigMgr控制台，导航到“监控”>“系统状态”>“站点状态”，查看各个站点系统角色的健康状况，确认是否有角色处于异常状态。
- 检查“组件状态”，查看是否有与软件更新相关的组件出现警告或错误状态。

5.2 检查常见环境问题

磁盘空间 ：查看ConfigMgr服务器的磁盘空间，确保承载站点数据库和相关文件的磁盘有足够的空间。可以通过前面提到的方法，让ConfigMgr代理收集磁盘空间信息，或者使用SCOM进行实时监控。
Active Directory ：检查主站点服务器是否有向Active Directory的“系统管理”容器发布信息的权限，确认“系统管理”容器是否存在且配置正确。查看受影响客户端的ClientLocation.log文件，获取更详细的信息。
DNS ：对相关服务器进行名称解析测试，确保DNS正常工作。检查DNS清理功能是否启用，避免因陈旧的DNS记录导致问题。

5.3 深入排查

如果初步评估和常见环境问题检查都没有发现问题，我们需要进一步深入排查。
- 查看软件更新相关的日志文件，如WUAHandler.log等，检查是否有错误信息。
- 检查软件更新的部署设置，确认是否正确配置了更新源、部署计划等。
- 在受影响的客户端上，手动触发软件更新检查，观察是否能正常获取更新。

5.4 解决问题

根据排查结果，采取相应的解决措施。
- 如果是磁盘空间不足，清理磁盘或增加磁盘容量。
- 如果是Active Directory权限问题，调整权限设置。
- 如果是DNS问题，修复DNS服务器或配置。
- 如果是软件更新部署设置问题，进行相应的调整。

6. 最佳实践总结

在使用ConfigMgr进行配置管理和故障排查的过程中，以下是一些最佳实践建议：

6.1 定期监控

定期查看站点状态和组件状态，及时发现潜在的问题。
利用ConfigMgr的内置报告功能，生成磁盘空间、合规性等方面的报告，进行数据分析。

6.2 备份和恢复

定期备份ConfigMgr的数据库和相关配置文件，确保在出现问题时能够快速恢复。
测试备份的恢复流程，确保恢复操作的可行性。

6.3 权限管理

合理分配ConfigMgr的管理权限，避免不必要的权限滥用。
定期审查权限设置，确保权限的合理性和安全性。

6.4 日志分析

建立日志分析机制，定期查看关键日志文件，及时发现异常信息。
利用日志分析工具，对日志进行更深入的分析。

7. 未来趋势展望

随着信息技术的不断发展，ConfigMgr也将面临新的挑战和机遇。以下是一些可能的未来趋势：

7.1 云集成

ConfigMgr可能会与云服务进行更深入的集成，例如利用云存储来存储软件更新包，提高更新的分发效率。

7.2 自动化运维

自动化运维将成为未来的发展方向，ConfigMgr可能会提供更多的自动化功能，如自动修复故障、自动调整配置等。

7.3 人工智能和机器学习

引入人工智能和机器学习技术，对大量的日志数据和监控数据进行分析，提前预测潜在的问题，实现更智能的运维管理。

8. 总结

通过本文的介绍，我们了解了客户端合规性管理、实验室操作、站点健康评估、常见环境问题解决等方面的知识。同时，通过综合案例分析和最佳实践总结，我们可以更好地运用这些知识来管理和维护ConfigMgr系统。在未来，我们需要关注ConfigMgr的发展趋势，不断学习和适应新的技术，以确保系统的稳定运行和高效管理。

以下是一个mermaid流程图，展示了综合案例的排查流程：

graph LR
    A[出现客户端无法获取更新问题] --> B[初步评估]
    B --> C[检查常见环境问题]
    C --> D{是否解决问题}
    D -- 是 --> E[问题解决]
    D -- 否 --> F[深入排查]
    F --> G[解决问题]
    G --> E