HOWTO: 使用 SetupDiag Tool 诊断 Windows 10 升级故障
HOWTO: 使用 SetupDiag Tool 诊断 Windows 10 升级故障
之前我们已经了解如何使用 Windows 10 安装程序 Setup.exe 执行升级验证，并学习了如何分析 Windows 10 安装日志，如果你无法专注于那些错误信息，那么不要气馁！微软为我们带来了 SetupDiag 工具，它是一个独立的诊断工具，可获取有关 Windows 10 升级失败原因的详细信息。（PS：微软真是太贴心了，记住这款诊断工具是免费的！）
SetupDiag 支持 Windows 7 SP1 to Windows 10；Windows 8.1 同 Windows 10；以及 Windows 10 to Windows 10。
SetupDiag 会检查 Windows 安装程序的相关日志，并识别出导致 Windows 10 安装或升级失败的关键日志信息。此外，SetupDiag 还支持离线模式，对于那些已经遭遇安装或升级失败的设备，我们也可以使用 SetupDiag 找出失败的根因。
SetupDiag 需要 .NET Framework 4.6，如果你在为满足需求的环境下执行，则会遇到错误提示，所以请先确保您的系统环境已经安装了 dotNET4，对于 Windows 7 是需要额外安装该组件的。
从微软官方下载：SetupDiag，可直接双击运行，但 gOxiA 建议你以管理员模式在 CMD 下手工执行，如下图所示：
SetupDiag 会从相关的目录下查找日志以进行自动化的诊断，如果找到匹配的信息，则会给出诊断结果，在本例中 SetupDiag 找到了“Processing rule: CompatScanOnly”，并给出了相关的建议和参考信息，最后还会生成名为 SetupDiagResults.log 的日志文件，以供我们事后参考。此外，还会生成一个 Logs.zip 的压缩包，其中包含了相关的日志文件。
如果要执行脱机诊断，需要收集相关的日志到一个文件下，并为 SetupDiag 附加命令参数，参考如下：
SetupDiag.exe /LogsPath:c:\setuplog
在 SetupLog 文件夹下应该包含相关的日志文件，你可以从以下位置复制。
\$Windows.~bt\sources\panther
\$Windows.~bt\sources\rollback
\Windows\panther
\Windows\Panther\NewOS
HOWTO: 分析 Windows 10 安装日志
HOWTO: 分析 Windows 10 升级安装日志
如果你在关注 gOxiA 前几天分享的日志“HOWTO: 使用 Windows 10 安装程序 Setup.exe 执行升级验证”，那么应该已经收集到了相关的日志，我们会重点分析“MoSetup”下的“BlueBox”日志，以及“Panther”下的“setuperr”和“setupact”日志。
如下面截图中 BlueBox 日志记录了 0xC190010A，它表示“MOSETUP_E_UNKNOWN_CMD_LINE”，即命令行未知，排查后发现是 gOxiA 执行的 Setup.exe 命令行参数存在错误。
当然以上的错误并不常见，只是为了本文说明，但是在遇到具体的升级故障时我们还需要分析 setuperr.log，该日志中包含了很多错误信息，但并不是所有的错误都会导致升级失败，如下图所示：
虽然包含了很多错误日志，但并不会真正影响 Windows 10 升级安装，所以我们需要查找那些会导致“Shell 应用程序请求终止”，或“由于对象的错误而放弃应用”的错误，此外 IT 人员还需要根据实际情况对 setupact.log 进行分析。这些日志通常包含四个等级的日志：Info, Warning, Error, Fatal Error；组件主要包含：CONX (Compatibility Information), MOUPG (Modern Upgrade), PANTHR, SP (Setup Platform), IBSLIB, MIG (Migration Engine), DISM, CSI, CBS。
HOWTO: 使用 Windows 10 安装程序 Setup.exe 执行升级验证
HOWTO: 使用 Windows 10 安装程序 Setup.exe 执行升级验证
当我们要在 Windows 7 或 Windows 8.1 系统环境上升级安装 Windows 10 时，可能会因为现有系统环境的一些兼容性问题，导致升级安装失败，这会耗费很多的时间和精力。所以，建议先使用 Windows 10 的安装程序 - Setup.exe 执行升级验证，以便在未正式升级安装 Windows 10 前进行评估，并对发生的错误进行分析和排错。
Setup.exe 位于 Windows 10 安装源根目录下，我们可以附加一系列的命令参数执行升级验证，为此请执行如下指令：
setup.exe /auto upgrade /quiet /noreboot /dynamicupdate disable /compat scanonly
其中 upgrade 表示以就地升级的方式来执行 Windows 10 安装；而 scanonly 则表示 Windows 安装程序通过兼容性扫描运行，然后退出并带有退出代码，以指示是否存在兼容性问题。如果返回的退出代码是 0xC1900210，则表示没有发现兼容性问题；如果发现兼容性问题将返回 0XC1900208，或其他代码。
那么我们该如何获取退出代码呢？！最为简单的办法就是编写一个批处理脚本，执行升级验证命令行，然后输出退出代码，如下图所示：
在本例中，执行升级验证后得到的退出代码是“-1047526896”，其代表“0xC1900210”。如果得到的是其他异常代码则需要进行分析和排错，所以建议使用如下的命令行收集日志，当然我们也可以直接查找相关目录下产生的日志文件进行分析。
setup.exe /auto upgrade /quiet /noreboot /dynamicupdate disable /compat scanonly /copylogs c:setuplog
命令执行完成后会在指定的目录收集相关日志，我们便可以做进一步的分析，有关如何分析日志的方法将在下次与大家分享。
Windows 10 Setup.exe 命令参数：https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-setup-command-line-options
本文参考了 Michael Niehaus 的文章：“Windows 10 Pre-Upgrade Validation using SETUP.EXE”
Windows Update 组件重置及更新常见问题解决方法
Windows Update 组件重置及更新常见问题解决方法
Microsoft 将于 2020年1月14日对 Windows 7 终止支持，虽然您的电脑还可以继续工作，但是将不再提供以下内容：
- 任何问题的技术支持
- 软件更新
- 安全更新或修复
对于 Windows 7 专业版和 Windows 7 企业版的用户，可以购买到 2023年1月为止的扩展安全更新。所以国内的很多企业还在苦苦挣扎……
最近连发的几起安全公告使企业 IT 更加重视 Windows 更新，随之而来的是 Windows 在安装更新中所遇到的各种问题，而这些问题的根源通常还是来自日常的 IT 管理，但是今天 gOxiA 要与大家分享的不是管理方面的经验。
当 Windows 更新发生故障问题通常可分为两类，一种是获取更新时发生问题；另一种是安装更新时发生问题。这两点在具体排错时需要注意。但通常部分问题是可以通过重置 Windows Udpate 组件来解决的，下面 gOxiA 将顺序列出重置组件以及相关问题的解决方法。
- 如果客户端有加入域，可重新获取组策略，可以删除客户端上组策略相关的目录：GroupPolicyUsers 和 GroupPolicy，根据实际情况还可考虑删除注册表对应键值。之后使用命令“gpupdate /force”重新更新组策略。
- 停止 Windows Update 服务（wuauserv），重新注册 Windows Update 相关组件。
regsvr32.exe atl.dll
regsvr32.exe urlmon.dll
regsvr32.exe mshtml.dll
regsvr32.exe shdocvw.dll
regsvr32.exe browseui.dll
regsvr32.exe jscript.dll
regsvr32.exe vbscript.dll
regsvr32.exe scrrun.dll
regsvr32.exe msxml.dll
regsvr32.exe msxml3.dll
regsvr32.exe msxml6.dll
regsvr32.exe actxprxy.dll
regsvr32.exe softpub.dll
regsvr32.exe wintrust.dll
regsvr32.exe dssenh.dll
regsvr32.exe rsaenh.dll
regsvr32.exe gpkcsp.dll
regsvr32.exe sccbase.dll
regsvr32.exe slbcsp.dll
regsvr32.exe cryptdlg.dll
regsvr32.exe oleaut32.dll
regsvr32.exe ole32.dll
regsvr32.exe shell32.dll
regsvr32.exe initpki.dll
regsvr32.exe wuapi.dll
regsvr32.exe wuaueng.dll
regsvr32.exe wuaueng1.dll
regsvr32.exe wucltui.dll
regsvr32.exe wups.dll
regsvr32.exe wups2.dll
regsvr32.exe wuweb.dll
regsvr32.exe qmgr.dll
regsvr32.exe qmgrprxy.dll
regsvr32.exe wucltux.dll
regsvr32.exe muweb.dll
regsvr32.exe wuwebv.dll 建议删除 SoftwareDistribution 目录，它位于 Windows 目录。
修复 BITS 服务，删除所有任务，为此执行“bitsadmin /reset /allusers”，然后可停止 BITS 服务（bits），重新设置服务的安全性描述符。
sc.exe sdset bits D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)
sc.exe sdset wuauserv D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)如果怀疑网络组件异常，可执行“Netsh winsock reset”重置 WinSock。
使用“Chkdsk /f /c:” 对执行磁盘检查，并修复可能出现的逻辑错误。
执行“sfc /scannow” 对系统组件执行检查和修复，如果存在错误，应分析 CBS.log 对具体错误进行修复。
常见错误：
- 8007FFFF，该问题需要安装服务栈更新，可参阅 KB3177467。
- 80240037，该问题通常是使用了不支持 Windows 7 的硬件导致的。
- 80070005，典型的拒绝访问故障，可尝试关闭安全软件。
- 80073712，系统存在组件问题，需执行“系统更新准备工具”，即 KB947821，但该工具也不是万能的，如果遇到错误，需要具体分析具体处理。
最后，友情提示企业 IT 人员，如果未执行持续和完善的 Windows 更新管理工作，那么客户端将会出现严重的碎片化问题，gOxiA 建议企业应该尽快开始到 Windows 10 的升级工作，以减少不必要的维护成本。
Windows 10 排错 PHASE1_INITIALIZATION_FAILED
Windows 10 排错 PHASE1_INITIALIZATION_FAILED
一台 Windows 10 计算机在启动过程中发生 Bug Check，提示“PHASE1_INITIALIZATION_FAILED”，且没有任何参数。微软官方资料也未对该错误有更多的解释，但可以肯定这是非常罕见的启动故障类型，因为即使通过“安全模式”也无法正常启动系统。
用户反馈在发生故障前使用 USB 端口插入过华为手机拷贝过资料（PS：我为什么要重点提牌子呢？！），那么应该与驱动程序或系统文件损坏有关，目前只能使用 WinPE 引导进行脱机修复。
考虑到故障是“PHASE1_INITIALIZATION_FAILED”，那么问题应该发生在“内核初始化”或“会话初始化”阶段，可参考下图（PS：虽然是 Windows 7 Boot Process，但也适用于 Windows 10）。
在内核初始化阶段，内核将初始化数据结构和组件，启动 PnP 管理器，该管理器初始化在 OSLoader 阶段加载的 Boot_START 类型驱动程序。当内核将控制传递给会话管理器进程（smss.exe）时，SMSSInit 子阶段开始，在此子阶段期间，系统将初始化注册表，加载并启动未标记为 Boot_START 的设备和驱动程序，并启动子系统进程，当控件传递给 Winlogon.exe 时 SMSSInit 结束。
所以，我们需要确认当前系统中安装的驱动程序，这也包含一些安全软件的逻辑驱动。如果系统是在线模式，我们可以使用设备管理器，或 Driverquery.exe 查询这些驱动程序。对于离线系统，如果你没有微软的 DaRT，那么只能使用注册表编辑器离线加载系统注册表（C:\Windows\System32\config\SYSTEM）。
然后逐个审查“HKLM\SYSTEM\CurrentControlSet\Services”下的项，要识别启动类型则需要通过“Start”键值，这是一个 DWORD 值，具体表示如下：
- 0x00000000: SERVICE_BOOT_START
- 0x00000001: SERVICE_SYSTEM_START
- 0x00000002: SERVICE_AUTO_START
- 0x00000003: SERVICE_DEMAND_START
- 0x00000004: SERVICE_DISABLED
此外，我们还可以从“HKLM\SYSTEM\CurrentControlSet\Control\ServiceGroupOrder”获得完整的加载顺序。参考资料：https://docs.microsoft.com/en-us/windows-hardware/drivers/ifs/what-determines-when-a-driver-is-loaded
可疑的设备驱动没发现，倒是发现了 360 相关的，以及另一个可疑的驱动，果断干掉，重启后可能会遇到 0xc0000001 故障，可以忽略重启，之后就能够进入桌面。
简单总结一下，在 Windows 登录界面未启动前如果发生异常，则可以重点检查系统加载的驱动程序。当然，也可以对磁盘做一次扫描检测，最好再对系统组件也做一次扫描修复。
Surface 蓝屏故障分析 PDC WATCHDOG TIMEOUT 14F
Surface 蓝屏故障分析 PDC WATCHDOG TIMEOUT 14F
PDC WATCHDOG TIMEOUT 14F 蓝屏故障已在环境中多个型号的 Surface 上复现，包括 Surface Pro 4 和 Surface Laptop 2，且从 1803 至 1903 的 Windows 10 都未能幸免，如果继续使用 1607 肯定是很不现实，现在不管怎样，重点都先转回蓝屏分析上！
对三台 Surface 设备的 7 个蓝屏文件进行了分析，发现均为 PDC_WATCHDOG_TIMEOUT 14F 蓝屏，且“A resiliency client failed to respond.” 生翻这句话，貌似是一个具有恢复能力的客户端发生了响应失败。
引发蓝屏的驱动组件是 dam.sys，该驱动即桌面活动审查器，是 Windows 的一个内核模式驱动程序，如果当前系统支持 Connected Standby，则会在系统引导时加载并初始化。
DAM 会将进程添加为系统管理的作业对象：
- 如果在会话0中创建了进程，则 DAM 会将该进程添加到受限制的作业对象。
- 如果该进程是在交互会话（会话1或更高）中创建的，则 DAM 会将该进程添加到要暂停的作业对象。
可以理解为，当屏幕打开时，DAM 将脱离，且不会影响系统上的任务进程。当系统处于 Connected Standby 状态时，DAM会限制或暂停进程。
综上，并结合栈的轨迹，导致 DAM.sys 引发蓝屏的原因应该是系统上的某些应用与 Connected Standby 发生冲突，出现了兼容性问题。在设备激活 Connected Standby 时，DAM 无法正确的限制或暂停某些进程，通常安全类应用都会有守护机制防止其他进程限制或挂起自己，所以最终导致 DAM 操作超时，引发蓝屏保护。
解决和缓解方案：
- 卸载或更新最近安装的应用，尤其是安全软件。
- 如果受企业安规影响，无法卸载存在兼容性的安全软件，那么缓解办法就是禁用 Connected Standby。为此，可修改注册表“HKLM\SYSTEM\CurrentControlSet\Control\Power”，将 CsEnabled 值改为 0。
Windows 10 在兼容性方便是有目共睹的，令人满意！只是一些安全软件厂商实在是不给力，未能跟上 Windows 10 的节奏，更新底层的存在兼容问题的 API 调用，所以如果您所在的企业正在更新至 Windows 10，且发生了莫名其妙的问题，多半都是由于老旧的安全软件版本导致的。
微软发布 Windows 7 等多平台版 Microsoft Edge
微软于今日发布了面向 Windows 7/8/8.1 版的 Microsoft Edge 预览，至此 Microsoft Edge 已完成了全平台版本的发布，不论您是移动设备用户，使用的是 Android 或 iOS；还是 PC 设备用户，使用的是 Windows 家族（7 ~ 10）或 macOS，现在都可以免费享用这款全新的 Microsoft Edge 浏览器。
虽然目前还是预览版，但是对于日常使用几乎是没有影响的，而且在最近发布的版本上，已经提供了中文界面的支持。
任何人只要您愿意，就可以加入到 Microsoft Edge Insider，即可访问网址：http://www.microsoftedgeinsider.com，以下是各系统版本的下载地址：
for Windows 10:
https://www.microsoftedgeinsider.com/en-us/download/
for Windows 8.1:
https://www.microsoftedgeinsider.com/en-us/download/?platform=win8dot1
for Windows 8:
https://www.microsoftedgeinsider.com/en-us/download/?platform=win8
for Windows 7:
https://www.microsoftedgeinsider.com/en-us/download/?platform=win7
for macOS:
https://www.microsoftedgeinsider.com/en-us/download/?platform=macos
for Android:
https://app.adjust.com/k50nf8b
for iOS:
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 格式保存到指定位置。
执行过程可参考下图：
Windows 10 1903面向 IT 专业人员的新功能
Windows 10 1903 面向 IT 专业人员的新功能
Windows 10 1903 （Windows 10 May 2019 Update）于2019年5月21日正式发布，用户可通过 Windows Update 获取到更新，对于商业用户可通过 WSUS 推送该版本。
如果你正打算全新安装该版本的系统，可从以下三个途径获取安装源：
- MSDN订阅用户，可从 Visual Studio 订阅中心下载 ISO。
- 普通消费者，可从Windows 软件下载中心，下载媒体创作工具。
- 企业用户，可从批量许可服务中心 下载 ISO。
截至发稿的当前内部版本号为：18362.116，其生命周期将于2020年12月08日结束。微软建议企业可以开始在整个组织中分阶段部署 Windows 10 1903，以确保在广泛部署前够能验证应用程序、设备和基础架构是否与新版本配合良好。
对于企业中的 IT 专业人员，有必要了解 Windows 10 1903 如下的更新信息，使之能够从智能安全性，简化更新，灵活管理和提升生产力中受益。
智能安全
Microsoft Defender Advanced Threat Protection (ATP) - Defender 高级威胁防护：
- 减少攻击层面 - IT 管理员可以配置具有高级 Web 保护的设备，使其能够为特定 URL 和 IP 地址定义允许和拒绝列表。
- 下一代保护 - 控制已扩展到防止勒索软件，凭证滥用，以及通过移动存储传输的攻击。
- 完整性强制执行功能 - 启用 Windows 10 平台得以u安城运行时证明。
- 防篡改功能 - 使用基于虚拟化的安全性将关键的 ATP 安全功能与操作系统和攻击者进行隔离。
- 平台支持 - 端点检测（EDR）和端点保护平台（EPP）功能现已支持 Windows 7 和 8.1 环境。
- 先进的机器学习 - 通过先进的机器学习和 AI 模型进行改进，使其能够防御使用新的漏洞利用技术、工具和恶意软件的攻击者。
- 紧急疫情保护 - 当发现新疫情时，将自动向设备更新情报。
- 符合 ISO 27001 标准 - 确保云服务能够分析威胁、漏洞和影响，并确保风险管理和安全控制措施到位。
- 地理定位支持 - 支持样本数据的地理定位和主权，以及可配置的保留策略。
Threat Protection - 威胁防护：
- Windows Sandbox - 隔离的桌面环境，您可以在其中运行不受信任的软件，而不必担心会对设备造成持久影响。
- 麦克风隐私设置 - 通知区域中会出现麦克风图标，让您可以看到哪些应用正在使用麦克风。
- Windows Defender Application Guard 功能增强 - 独立用户可以安装和配置其 Windows Defender Application Guard 设置，而无需更改注册表。企业用户可以检查其设置，以查看其管理员为计算机配置的内容，以便更好地了解其行为。
Identity Protection - 身份保护：
- Windows Hello FIDO2 认证 - Windows Hello 现在是 FIDO2 认证的身份验证器，可为支持 FIDO2 身份验证的网站（如：Microsoft Account 和 Azure Active Directory）启用无密码登录。
- 简化的 Windows Hello PIN 重置体验 - Microsoft Account 用户将获得改进的 Windows Hello PIN 重置体验，其外观与 Web 上登录相同。
- 使用无密码的 Microsoft Account 登录 -支持使用电话号码登录 Windows 10，然后使用 Windows Hello 获得更轻松的登录体验。
- 具有生物识别功能的远程桌面 - 使用 Windows Hello for Business 的 Azure Active Directory 和 Active Directory 用户可以使用生物识别技术对远程桌面会话进行身份验证。
Security management - 安全管理：
- 适用于 WSL 的 Windows Defender Firewall，它允许用户为 WSL 过程添加规则，就像 Windows 一样。
- Windows 安全应用程序 - 包含保护历史记录，包括有关威胁和可用操作的详细且易于理解的信息，受控文件夹访问现在位于保护历史记录，Windows Defender 脱机扫描工具操作，以及任何待处理的建议。
- 防篡改 - 可以防止他人篡改重要的安全功能。
简化更新
- 交付优化 - 提高具有复杂网络的企业和教育机构的同行效率（通过一系列新政策）。现在支持 Office 365 ProPlus 更新和 Microsoft Intune 内容; System Center Configuration Manager 内容即将推出
- 预留存储 - 预留存储留出了更新，应用程序，临时文件和系统缓存使用的磁盘空间，通过确保关键操作系统功能始终可以访问磁盘空间来改善 PC 的日常功能。此功能将在预安装了Windows 10 1903 以及全新安装的新 PC 上自动启用。（从以前版本的Windows 10更新时不会启用此功能。）
- 自动重新启动登录（ARSO） - 对于 Azure Active Directory 加入的设备，Windows 将自动以用户身份登录并锁定设备以完成更新，从而确保当用户返回并解锁设备时更新已完成。
- Windows Update for Business - 现在将有一个统一的分阶段部署开始日期（不再有SAC-T指定）。此外，还将为最终用户提供新的通知和重新启动计划体验，实施更新安装和重新启动截止日期的能力，以及在特定时间段内为重新启动提供最终用户控制的能力。
- 更新回滚改进 - 如果在安装驱动程序或每月质量更新后设备无法正常启动，Windows 将自动卸载更新以将设备恢复到正常运行状态。
- 暂停更新 - 所有版本的 Windows 10（包括Windows 10 Home）用户都可以暂停功能更新和每月更新。
- 智能活动时间 - 用户现在可以选择让 Windows Update 根据设备特定的使用模式智能地调整活动时间。
- 改进的更新编排 --Windows 10 1903 通过智能地协调 Windows 更新和 Microsoft Store 更新来提高系统性能，以便在用户远离其设备时才开始运作，从而最大限度地减少中断。
- 改进的更新通知 - 当需要重新启动设备的更新时，用户将在“开始”菜单中的“电源”按钮和任务栏中的Windows图标上看到彩色圆点。
- SetupDiag - 使用此命令行工具对失败的功能更新进行故障排除。
灵活管理
- Windows Autopilot - 注册状态页面（ESP）增强功能提供企业就绪设备，其中包括跟踪通过 Intune Management Extensions 提供的 Win32 应用程序。您现在还可以选择在注册期间通过 Intune 阻止哪些应用。此外，Windows Autopilot 功能和关键更新将在开箱即用体验（OOBE）期间自动开始下载。现在，对于 Windows 10 Pro 以及 OOBE 中的 SKU，默认情况下禁用 Cortana 配音。而且，通过 Windows Autopilot 白手套部署，合作伙伴或 IT 人员可以预先配置 Windows 10 PC，以便在交付给 新的Microsoft Mechanics视频 之前进行完全配置和业务就绪。
- 移动设备管理策略 - Windows 10 1903 提供了用于管理 Microsoft Edge 的新组策略和移动设备管理（MDM）策略。您可以为标准 Azure Active Directory 加入的用户静默启用 BitLocker。您还可以使用 Microsoft 365 管理中心更轻松地为用户管理整个 Microsoft 365 体验。
- Intune安全基准（预览） - 现在包括 Intune 支持的许多设置，您可以使用这些设置来帮助保护和保护您的用户和设备。您可以自动将这些设置设置为安全团队建议的值。
提高生产力
- 更智能地工作 - Windows Shell 现在允许您搜索 WSL 发行版中包含的Linux文件。此外，当您在搜索栏中单击时，将显示热门应用程序和最近的文件。我们还将 搜索和 Cortana 分开，允许 Cortana 充当数字助理，同时使用 Windows 搜索文件，图片，文档等。新的Chrome扩展程序将Google Chrome 活动添加到时间轴视图中。
- 增强工作方式 - 新的辅助功能包括讲述者改进，更多声音和阅读控制，以及易于访问改进，如11个新的鼠标指针大小。Windows 10 1903 还包括 Narrator QuickStart，这是一个新用户的简短教程。此外，您可以点击WINDOWS + .或 ；号，访问新的 kaomojis 和 emojis 表情符号。
- Windows Virtual Desktop - 作为公共预览版提供，Windows Virtual Desktop 允许您提供多会话 Windows 10 体验，Office 365 ProPlus 优化以及对 Windows Server 远程桌面服务（RDS）桌面和应用程序的支持。
以上内容引用自：
