Windows 应用程序的用户默认值和计算机默认值
是时候写一篇日志进行这个问题的总结了，毕竟拖得时间太久，久到连 gOxiA 自己都要遗忘掉!背景是这样的，在某个案例中需要使用“start apps”调用某个应用，也就是说某个程序内部会通过 Windows 的 Start 命令调用一个应用程序，这个应用程序可能是 chrome 也可能是 msedge，这里以msedge 早期版本为例进行说明。
当我们在 cmd 命令提示符下使用“start msedge”后，正常情况应该会默认启动基于 Chromium 开发的 Edge 浏览器，但是却遇到了错误提示，内容为“Windows 找不到文件 'msedge'，请确定文件名是否正确，再试一次”。当然现在的版本已经解决了这个问题，但是在某些极端环境下，不论是 msedge 还是 chrome ，甚至其他应用，也都可能会遭遇到该问题。
起初发现这个问题时，首先想到的分析方法就是抓取轨迹进行分析。确实有所收获，gOxiA 发现在执行“Start msedge”时会遍历注册表，并最终读取“HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\msedige.exe”路径下定义的值，而结果是未能找到该值。
此时，问题已经很明朗了，修复该路径定制的值，问题即可解决！但其实该问题却引出了更底层的一些知识，而且非常有价值。
在早先的排错过程中，gOxiA 尝试了重装应用程序，排除了安装问题。由于最早遇到的类似案例就是基于 Chrome 的，所以是先对 Chrome 进行了分析。下图是当时对 Chrome 分析时的截图，会发现执行“Start chrome”后，会遍历注册表但最终会以“HKCU\Software\MicrosoftWindows\CurrentVersion\App Paths\chrome.exe”定义的值为准。
此时，不论 HKLM 下如何定义都不会生效，但是 msedge 的情况却正好相反，HKCU 下有定义的数据，也无法被正常调用。
难道是因为安装应用程序的模式导致的？！我们知道，常见的 msi 安装包默认都会以计算机配置模式进行安装，所以需要以管理员权限执行 msi 安装包，默认应用程序会被安装在 ProgramFiles 目录下，如果你下载了 chrome 的脱机安装包，那么你会发现其安装格式为 msi。
而如果安装包是 exe 格式，以 chrome 和 msedge 为例，通过云下载数据到本地后，会启动一个真正的安装过程，而这个安装过程是面向用户配置的，也就是说当前用户即使不是管理员，也能够正常安装它们，因为应用程序数据写入到了当前用户配置文件下，而涉及注册表的部分会写入到 HKCU 下。
那么两者的区别是什么呢？其实显然易见，排除目录不谈，重点说说注册表，面向用户配置的在 HKCU 下，面向计算机配置的在 HKLM 下。
看起来执行"start msedge"时发生错误是因为它要去读 HKLM 下的定义数据，而 HKLM 下无数据，也就说明当先 msedge 应用实例是安装在计算机配置下，那么也论证了这是 msedge 的一个 bug。（PS：该问题仅发生在 msedge 早期的开发版本中，gOxiA 已经向产品组提交了 bug，目前已经修复！）
而对于之前在 Chrome 上遭遇的此类问题，可论证不是产品 bug，因为该应用程序实例是安装在用户配置下的，所以会依据 HKCU 下的定义数据执行，而发生故障是因为 HKCU 下的定义数据被“流氓”软件破坏导致的，所以必须修复 HKCU 下的定义数据。
综上，貌似这些执行机制是一个规范设计，那么就需要找出微软官方的依据进行论证。功夫不负有心人，在 Windows Shell 的官方文档中确实有相关的说明。
"Per-user default settings are specific to an individual user account on the system. If per-user default settings are present, they take precedence over corresponding per-computer defaults for that account."
具体可参考：https://docs.microsoft.com/en-us/windows/desktop/shell/vista-managing-defaults
HOWTO: 收集 DeviceID 用于测试 Windows Autopilot
HOWTO: 收集 DeviceID 用于测试 Windows Autopilot
时代在进步，技术在发展，日新月异，所有的事务都不可能长青永驻。Modern Desktop 已经到来，作为传统桌面 IT 人员，是时候开始转变，跟上大局步伐，迎接这个以服务为核心的云时代！
在未来一段时间，gOxiA 将撰写一系列有关 Microsoft Intune 以及 Windows Autopilot 相关的内容，通过自身的了解和学习，与大家一同进步和提高，并分享和交流其中的心得体会。
在系列的开篇，gOxiA 想先分享的是在测试和体验 Windows Autopilot 前，需要做的一些准备，而这项准备就是提取 DeviceID（设备标识）。
DeviceID（设备标识）是什么？！
在微软的官方文档中对设备标识的说明是这样的：“若要将设备添加到 Windows Autopilot，需要捕获设备的唯一硬件ID并将其上传到服务。虽然此步骤应由硬件供应商（OEM、经销商）或CSP（云解决方案合作伙伴）完成，但用户也可以从运行的 Windows 10 中收集设备的设备标识。”
所以用户手动收集设备标识，应仅适用于测试和评估环境。此外，还需要注意，硬件哈希还包含有关何时生成的详细信息，因此它将在每次生成时进行更改。当 Windows Autopilot 尝试匹配某个设备时，它会考虑所作的更改，并仍能够成功匹配。但对硬件的重大更改无法匹配时，将需要重新生成并上传设备标识。
以上的信息包含一些重要的细节，这对于日后我们在遇到问题时排错至关重要！
为了方便用户手动收集硬件标识，微软的 Michael Niehaus 编写了一个 PowerShell 脚本，用户能够很方便地在当前 Windows 10 上获取到，并执行它。
首先，为了确保我们能够在当前系统环境下运行获取到的脚本，需要对 PowerShell 的执行安全策略进行调整，为此进入 PowerShell 环境，并执行如下命令。
然后，从 PowerShell Gallery 获取这个脚本，其名称为“Get-WindowsAutoPilotInfo.ps1”，我们可以使用 Install-Script 来安装这个脚本，在获取前请确保我们能够访问互联网。
最后，执行脚本将获取到的设备标识以 csv 格式保存到指定位置。
执行过程可参考下图：
