评估质量功能是对以前的先决条件边栏选项卡的改进。
按需评估评估质量功能
评估结果仅与收集的用于评估这些结果的数据一样好。 不成功的发现和数据收集会降低评估结果的价值，并可能导致质量较差的认知。 有时，这些问题甚至不会发现，也没有能力把问题提出来，并提供可操作的指导来解决这些问题。 记住，对 Azure Log Analytics 评估仪表板上的现有系统必备重点领域边栏选项卡的这一重大改进已制定出以下两个目标：
- Surface 评估质量问题，以便您有机会更正和重新运行评估，以确保良好的评估质量。
- 通过提供具体可操作的补救内容，最大限度地减少筹集支持票证以解决数据提交质量问题的需要。
具体来说，增强了市场上现有的必备重点区域边栏选项卡的功能，包括：
将潜在故障状态分类到初始评估执行阶段，其中包括发现和收集先决条件。
评估质量索引以直观地表示评估数据收集的成功率%。
更新的环形图形直观地表示类别和评估质量索引。
"评估质量索引" 代表什么？
AssessmentQualityIndex = 已通过的先决条件工作流/先决条件工作流总数
进行评估时，我们会运行各种收集器，然后对这些收集器的结果运行分析器。 如果任何收集器失败（由于对目标的 WMI 远程处理失败），则不会有任何内容供运行分析。 这将导致评估结果不完整，从而降低我们交付给您的结果的质量。
最初创建先决条件是为了纠正这种情况。 在运行收集器之前，我们在“先决条件模式”下运行收集器，以测试是否满足特定的先决条件（我们验证目标上是否已启用 WMI 远程处理）。 如果任何先决条件失败，我们会在 Azure 门户的 "先决条件" 边栏选项卡下介绍这些失败；但前提条件的初始实施并不能很好地向最终用户展示评估质量的总体状况。
请考虑以下场景。 您运行的是 ADAssessment，在发现过程中确定了 100 目标。 我们在先决条件模式下运行收集器，以确认已启用 WMI 远程处理，但这无法针对每个目标，因为你在其环境中未启用 WMI 远程处理。 在评估质量之前，Azure 中出现有关“未启用 WMI 远程处理”的单个先决条件失败。但实际上，有 100 个失败的先决条件工作流，并且评估几乎没有做任何分析，从而导致评估质量差。 这并不一定明显，因为您只能在 Azure 中看到单个先决条件失败。
现在，通过“评估质量”功能，我们提供了评估质量索引，这只是合格的先决条件工作流/总必备工作流的百分比。 因此在以上示例中，你将看到评估质量指数为 0% 或 1%，这清楚地表明，由于先决条件失败，总体评估质量极差。
备注
在现实生活中，ADAssessment 可能会运行更广泛的必备工作流，而不仅仅是 WMI 远程处理，因此我们更有可能会看到更高的评估质量索引。
发现失败、重要先决条件失败和其他先决条件失败之间有什么区别？
此评估在运行时将经历各个阶段。 首先，我们运行发现以查找将评估的各种节点。 接下来，我们在先决条件模式下运行各种收集器。 最后，我们将正常运行收集器，然后运行分析。
先决条件主要涉及前两个阶段：在先决条件模式下运行发现和收集器。
先决条件输出文件现在将指定发生每个先决条件故障的阶段，我们将在 Azure 中进行介绍。
为什么重要的先决条件失败密钥有时只在环形图/图例中展示？
当 IP 作者创建评估时，可以选择将工作流标记为重要。 这表明工作流对评估质量至关重要。 如果评估未定义任何重要工作流，我们将不会在 Azure 中的环形图/图例中显示重要的先决条件失败。
为什么我们有时在 Azure 中只显示 "发现失败"，而不显示其他类别？
如果 MVE （最小可行环境）测试在发现期间失败，则表明某些基础先决条件未得到满足（在 SQLAssessment 中，找不到任何 SQL 服务器）。 在这种情况下，收集器甚至不会在先决条件模式下运行——导致提早从评估运行中退出。 发生这种情况时，我们仅在 Azure 中显示发现失败。
为什么我会看到空白的评估质量边栏选项卡？
并非所有将数据提交到此 Log Analytics 工作区的数据收集计算机/计划任务都将使用新的评估质量位重新运行评估。 将在如下情况下自动解决：
- 这些计算机上的所有数据收集计算机和计划任务都使用新位重新运行评估，或
- 数据保留期（默认 30 天）会导致清除旧数据，只保留在发布评估质量功能后生成的 “优良” 数据。
"成功/失败" 功能需要我们向评估输出文件添加一个新的 CustomData，新 UX 分析该新的 CustomData 列以生成在新的评估质量边栏选项卡中显示的静态。
这对向后兼容性带来了棘手的麻烦。 仅当您使用新 ODA 客户端更改将填充 CustomData 列的内容运行评估时，新 UX 才起作用。 因此，我们的 UX 中有一些代码，用于确定 Log Analytics 工作区是否有任何表明已使用新位运行评估的 CustomData 填充记录。 如果情况并非那样，我们将回退到旧的先决条件边栏选项卡。 如果 CustomData 确实存在，我们将显示新的评估质量边栏选项卡。
但是，多个数据收集计算机（甚至同一数据收集计算机上的多个计划任务）可能会将数据提交到单个 Log Analytics 工作区，并且该边栏选项卡是所有数据收集计算机连接到工作区的必备结果聚合。 那么，如果某些计算机已经使用新的 "CustomData" 列提交数据，但有些计算机尚未提交，会发生什么？ 我们显示旧 UX 还是新 UX？
此时，您将在屏幕截图中看到空白边栏选项卡。 此处没有很好的解决方案，因此在所有数据收集计算机使用新位提交数据之前，您将会看到此中断的中间状态。
此处存在一些不幸的边缘事例，可能会给客户带来痛苦的体验：
我们了解到，某些评估（例如 Windows 客户端评估）通常会在同一台数据收集计算机上设置多个计划任务，并且将这些任务设置为在不同日期运行。 假设您有两项任务，一项在星期一，一项在星期三。 任务在星期一运行后，你将看到空白边栏选项卡，直到星期三运行第二个任务，此时客户应开始查看新的“评估质量”边栏选项卡。
如果 3 个数据收集计算机都在运行 SQL 评估并且指向同一 Log Analytics 工作区，但其中一台计算机已在 2 周前取消运行，则会发生什么问题？ 其他两台计算机将使用我们的新位运行评估，但由于第三台计算机已退出运行，因此它无法使用新位运行评估。 在这种情况下，客户将看到空白边栏选项卡。
我们在一些测试工作区中看到了该问题，其中有大量人员正在运行评估并将数据提交到同一 Log Analytics 工作区。 在这种情况下，很难（或不可能）跟踪每个人，并让他们使用新位重新运行评估。
但是，一旦出现以下两种情况之一，该问题就会自动自行解决：
这些计算机上的所有数据收集计算机和计划任务都使用新位重新运行评估，或
数据保留期（默认 30 天）会导致清除旧数据，只保留在发布评估质量功能后生成的 “优良” 数据。
因此，我们认为这是可接受的忍受扰动量。
最坏情况下，客户始终可以创建新的 Log Analytics 工作区，或使用数据清除器 API，然后重新运行评估，这将产生清洁的评估质量边栏选项卡。