Desktop Analytics仍然是最新产品，并且是一个小野兽，需要一些时间和反复试验才能开始。桌面分析的目的是在大规模推出新的Windows 10功能更新之前，先提供数据以了解您的环境。Desktop Analytics不是用于部署Windows 10功能更新的产品。ConfigMgr仍然是实际部署的主体。
在此博客文章中，我们将详细介绍有关在Windows 10功能更新部署过程中如何使用Desktop Analytics信息提供帮助的实际方案。
DESKTOP ANALYTICS WINDOWS 10更新要求
在阅读本文之前，请参阅我们以前的文章，该文章有关如何设置Desktop Analytics并将其连接到SCCM / ConfigMgr / MEMCM环境。
选择要由DESKTOP ANALYTICS评估的设备
以下是一些有助于确定应包括哪些设备的问题。
- 是否应包括Windows 7设备？
- 假设您已经很熟悉Windows 7到Windows 10的迁移，它可能只会给桌面分析中的报告添加不必要的干扰。
- 环境中是否有Windows 10 LTSB / LTSC？
- 是否有具有特定应用程序的设备是关键任务，需要从Windows 10功能更新中排除？
这对于简化Desktop Analytics中的信息量非常重要。导入Windows 7设备可能会带来大量不再使用的应用程序，这些应用程序只会创建其他工作进行分类。
服务器也应从集合中排除，以定义要包含在Desktop Analytics中的设备。
一旦根据您的条件建立了集合，就可以在以下位置指定它：
- 管理/云服务/ Azure服务/桌面分析
- 选择您的Target Collection Doe Desktop Analytics
重要信息
如果您已经在此处添加了一个收藏集，但是想要对其进行查看，则可以对其进行修改。请注意，大约需要2天的时间来处理这些更改并反映新的设备列表。
创建WINDOWS 10部署计划
对于我们的测试，我们将使用Windows 10 20H2版本。部署计划将：
- 自动推荐飞行员要包括哪些设备
- 确定兼容性问题并提出缓解措施
- 在更新之前，期间和之后评估部署的运行状况
- 跟踪部署进度
部署计划只能针对每个Windows 10构建。
- 在Microsoft Endpoint Manger门户中
- 在“所有服务”中，选择“桌面分析”
- 在管理下，选择部署计划
- 创建一个名为Windows 10 20h2的新部署计划，然后选择Windows 10的目标版本。
- 选择该计划要包括的设备组。例如，如果主要目的是从Windows 10的早期版本进行功能更新，则应选择设备组（在后台从ConfigMgr收集）。
- 在“就绪规则”上，指定设备是否正在从Windows Update获取驱动程序以及默认的低安装数量阈值。请仔细阅读该说明，因为这些应用程序将被分配较低的安装次数，从而使该应用程序处于就绪状态。
- 创建完成后，这将在ConfigMgr中的“设备收集/部署计划”下创建收集。
- 请注意，这些根本不能在ConfigMgr中进行修改。
- 这些集合成员资格将根据设备的就绪程度而发展。稍后我们将详细介绍。
应用分类
Desktop Analytics的目标是从您的应用程序中收集数据，以了解它们是否与下一个Windows 10版本兼容。现在，我们将对我们的应用程序进行分类以适应我们的需求。
这是2个步骤的分类：
- 通常，可以在Assets / Apps下对所有Desktop Analytics的应用程序进行分类。这对于以后的任何部署计划都是有用的。如果您从桌面分析开始，那么最好从这里开始。
- 使用此选项，可以定义应用程序的重要性级别和所有者。可以一次选择许多。
- 第二个选项是在创建部署计划后，在“计划资产/应用程序”下可以对应用程序进行分类。
- 为已确定的重要和重要应用程序分配升级决定尤其重要。使用此选项卡来分配的重要性是可能的，但将被限制在该部署计划只。
重要信息
不幸的是，对应用程序的任何修改都无法实时处理。通常需要24小时。在此之前，排序不会过滤任何进度。
定义飞行员设备
识别试验设备的第一种方法是从ConfigMgr定义一个特定的集合，该集合将被定位为Global Pilot。
- 首先，在ConfigMgr中创建一个集合，该集合将具有与Desktop Analytics的主要Target集合相关的限制集合
- 创建集合后，将集合添加到管理/云服务/ Azure服务/桌面分析中的“桌面分析连接”选项卡下
- 如果您在向导中看不到该集合，那是因为它与Desktop Analytics的主要目标集合无关。
- 同步后，可以在Desktop Analytics / Global Pilot中对集合进行检查。
- 要将这个集合作为全球试点，只需选择该集合并单击包括
全球试点
全局试验意味着此集合下的设备将成为任何部署计划的试验的一部分。
这些可能是用于早期测试的测试/实验室设备，对于IT用户而言，则可能是稍后阶段的测试设备，是最早的实时设备。
根据公司规模和试点测试的成熟程度，此处还应包括SME和一些高级用户，以确保测试应用程序的兼容性
以相同的实现方式，可以定义一个Exclude集合。如果存在不应该被控制的已知设备，那么这就是解决方案。收集要求相同，可以在Desktop Analitycs的“全局”试点部分中定义排除项。
在被确定为试验设备的设备之上，Desktop Analytics提供了将试验设备添加到试验设备的见解，从而使应用程序和硬件类型的覆盖率达到100％。可以在“部署计划/识别飞行员”下看到。
如果您想添加推荐的设备，请选择特定设备或单击全部添加到试用版
准备飞行员
定义好飞行员并将其同步回ConfigMgr集合后，就该准备飞行员了。
我们在这里看到了两种不同的影响：
- 功能更新期间受影响的应用程序或驱动程序。
- 下面的示例说明功能更新将从设备中删除以下应用程序/驱动程序。
- 仅供参考，以确保升级后工作正常。
重要的提示
升级决定不会影响试点设备有资格接收功能更新。毕竟，试验设备将以一种更加面向操作的方法实际测试应用程序的兼容性，而不是将其作为一个完整的项目进行管理。
批准关键和重要的应用
此时，试验设备开始接收Windows 10功能更新。现在是时候分配升级决定了，以便为功能更新的生产版本做准备。
在审查应用程序的重要性和就绪性时，请务必审查Microsoft分配的兼容性风险。
兼容性风险高
这一点非常重要，因为某些应用程序标记为“兼容性高”，实际上是Safeguard（硬块），由于对设备的关键影响，它们将阻止Windows 10功能更新运行。
在上面的示例中，有一个名为“ Safeguard”的“应用程序”。很难说出这里出了什么问题。下面的2，称为20h2的SQL Setup应用程序。有点清楚，它与在Windows 10设备上安装SQL有关，但是实际上这是Microsoft的保障措施。
不幸的是，Microsoft Docs上没有记录此保障措施。
为了识别这种保障措施，需要在AppRaiser数据库中进行外观检查。该主题本身在Adam Gross的博客文章中进行了介绍。
结合试行经验和飞行员的报告，将对“关键”和“重要”应用程序进行审核，以决定Windows 10功能更新的就绪状态。这需要在部署计划下实现。请注意，将来的部署计划也将需要此步骤。
这也强调了每个Windows 10版本制定一个部署计划的重要性。同一构建有多个副本将重复不必要的工作。
决定时间
做出这样的决定将直接影响许多设备的就绪状态。一旦设备没有任何尚未准备好升级的安全，关键或重要应用程序，它将被视为已准备好投入生产。
然后，设备将显示在ConfigMgr集合中，用于部署计划生产。
生产设备清单
如前所述，此列表将根据关键和重要应用程序的升级决定自动生成，并且不会受到Microsoft的保护。
从这一点开始，可以实现许多策略来部署功能更新。无论您使用任务序列还是服务方法，Desktop Analytics的帮助都将最可能简化您的部署并节省之前需要的一些测试时间。
由Desktop Analytics生成和管理的集合不需要将功能更新部署到它们。
您可以轻松构建集合的子集，以采用适合您的环境的部署策略。Desktop Analytics将对设备进行预筛选，以使它们可以随时使用，从那时开始，请根据需要使用此信息！
WINDOWS 10功能更新监视
功能更新一旦发生，Desktop Analytics还可以帮助提供报告。
- 作为部署计划的根本，仪表板提供了有关进度的高级视图，以及一些需要审查的区域。
- 有2个部署状态部分。一个用于试验，第二个用于生产。
- 最后，有一个监视运行状况，报告升级设备上的资产（读取的应用程序）状态。此处的目的是要使已批准应用程序的任何潜在故障高度重新考虑，以防止功能更新损坏其他设备的决定。转到“生产”卷展栏时，请密切注意。
桌面分析WINDOWS 10更新–报告
我们构建了2个 SSRS报告 ，这些报告将有助于显示Desktop Analytics的有用数据。
