HOWTO: 在 Intune 中创建 Windows Autopilot 配置文件
HOWTO: 在 Intune 中创建 Windows Autopilot 配置文件
回顾：
“HOWTO: 收集 DeviceID 用于测试 Windows Autopilot”
"HOWTO: 将收集的 Windows Autopilot DeviceID 添加到 Intune"
"HOWTO: 在 Intune 中为 Windows Autopilot 部署创建设备组"
在之前我们已经了解了如何在 Intune 中 为 Windows Autopilot 部署创建设备组，当基本工作完成后，我们也将进入 Windows Autopilot 配置主要环节 —— 创建和分配 Deployment Profiles，当这一步完成后，我们便可以通过 Windows 10 客户端来体验 Windows Autopilot。
首先，登录 Azure Portal，在 Intune 中找到 Device enrollment，进入后便能看到一系列的注册项，选择 Windows enrollment，就能看到位于"Windows Autopilot Deployment Program" 下方的 "Deployment Profiles"。
点击"Create profile"，开始创建 Windows Autopilot 的配置文件。
因为改版，配置文件的创建页面改为了引导式，对于用户来说虽然步骤显得繁琐，但更为清晰明了。首先我们需要输入配置文件的名称，本例命名为 UserDriven。
目前 Windows Autopilot 提供了两种部署模式：User Driven（用户驱动）和 Self-Deploying（自助部署），简单理解后者的自动化程度更高，将会自动跳过"工作或家庭使用选项"，"OEM注册和OneDrive配置"，以及"OOBE 中的用户身份验证"，此外还可自动配置语言及键盘等设置。但是自助部署的需求也更高，从目前最新的文档看需要 Windows 10 的 1903，之前 gOxiA 在实际测试时发现 1809 对一些设备的 TPM 设备证明存在支持问题，并得到了产品组的证实。所以如果你打算测试自助部署还需要了解更多的先决条件，本例我们将使用“用户驱动”模式。
在"User Driven"下我们可以隐藏软件许可条款，以及隐私设置等需要人工干预的界面，我们还可以指定登录到设备上的用户账户类型，例如将其分配为标准用户权限。
在当前更新版本中还提供了"Allow White Glove OOBE"的选项，允许 IT 人员在不使用用户账号配置和登录的情况下对设备进行 Windows Autopilot 预配。只需要在配置阶段按下 5次 Windows 键即可激活该功能选项。
此外，我们还可以配置设备名称模板，通过一系列变量生成有序的计算机名。
配置文件的选项设置完毕后，就需要将其分配给指定组，还记得我们在之前创建的组吗，参考下图找到并选择这个 UserDriven 组。
最后在 Review 界面可以对配置进行确认，无误后可点击“Create”确定创建。
Windows Autopilot 配置文件创建后便可在之前已经添加到 Intune 中的设备上，使用 1903 的 Windows 10 进行测试。
HOWTO: 在 Intune 中为 Windows Autopilot 部署创建设备组
HOWTO: 在 Intune 中为 Windows Autopilot 部署创建设备组
回顾：
“HOWTO: 收集 DeviceID 用于测试 Windows Autopilot”
"HOWTO: 将收集的 Windows Autopilot DeviceID 添加到 Intune"
如果之前跟随 gOxiA 完成了上面的学习和动手操作，可以继续跟随 gOxiA 完成今天的内容，否则建议您从头开始了解。今天的内容将会非常轻松，会了解如何在 Intune 中创建“设备组”，这部分虽然很轻松，但它也是重点之一，因为在实施 Autopilot 部署时配置文件只能分配给组。
我们可以创建两种类型的设备组，即：动态设备组 和 静态设备组，两者区别在于前者可通过定义规则自动将设备加入到组，或从组删除；而后者则需要由管理员进行分配。
要为 Windows Autopilot 创建设备组，可登录 Auzre门户，定位到“Intune”，会看到“Group”，如下图所示：
进入 “Group” 后在 “All groups” 下点击 “New group”。
在 “New Group” 中，会看到一些选项，带有 * 号的是必须填写的信息。其中“Group Type”表示组的类型，在预定义中包括了“Security” 和 “Office 365”。
- Security，它通常用于管理用户和设备的共享资源的访问权限，也可以为特定的策略创建安全组，这样一来我们就不用为每个成员单独设置权限。
- Office 365，主要是提供对共享邮箱，日历，文件以及SharePoint站点等的访问权限。
本例中，我们要为 Windows Autopilot 创建设备组，所以这里的类型应该是“Security”。“Group name”很好理解，这里命名为了“UserDriven”。“Membership type”便是我们前面提到的静态和动态的组类型，包含了“Assigned”、“Dynanmic User” 和 “Dynamic Device”，是的动态组除了支持设备外，也适用于账户。
当我们选择“Assigned”后，就可以手动添加账户或设备，这里我将添加之前导入的设备。
我们也可以使用动态组，利用一些规则自动将设备添加到组中，这样就不需要手动添加那么麻烦。动态成员规则非常强大，提供了多种属性，可利用各种运算符，根据属性的值，创建具有多个表达式的规则。
来看一个简单的例子“(device.accountEnabled -eq ture)”，还是很容易理解的，当设备账户启用状态是“真”时，那么便会设备便会自动加入到这个组，如果组中的设备账户启用状态为“假”时会将设备从组中删除。下图可看到当前动态设备组提供的可用属性。
有关动态组的详细规则，强烈推荐学习官方文档：https://docs.microsoft.com/zh-cn/azure/active-directory/users-groups-roles/groups-dynamic-membership，随着准备工作的就绪，我们离正式实施 Windows Autopilot 也越来越近！
HOWTO: 将收集的 Windows Autopilot DeviceID 添加到 Intune
HOWTO: 将收集的 Windows Autopilot DeviceID 添加到 Intune
在 6月份 gOxiA 分享了“HOWTO: 收集 DeviceID 用于测试 Windows Autopilot”，如果您已经学习了这篇日志，会发现收集硬件标识信息其实是非常简单的事情，但是需要注意它并不适用在生产环境，应仅用于评估和测试。
今天要分享的是如何将收集的 Windows Autopilot DeviceID 添加到 Intune 中，因为后续我们将实践 Windows Autopliot 的用户驱动模式和自部署模式，所以需要将 DeivceID 事先添加到 Intune 的设备列表中，为此我们需要执行下述的操作步骤：
1. 首先访问 Azure Portal，使用拥有权限的账号密码登录。
2. 在左侧的导航列表中点击“Dashboard”，搜索 Intune，可以将其收藏到导航列表中便于后续访问。
3. 进入 Microsoft Intune 后，点击“Device enrollment”
4. 在“Deive enrollment”下点击“Windows enrollment”，并选择“Windows Autopilot Deployment Program”下的“Devices”，它便是我们要导入 DeviceID 的位置。
5. 进入“Deives”后，点击“Import”来导入我们之前拿到的硬件标识信息文件，它是一个 CSV 格式的文件，在上传后 Intune 会进行校验，如果格式无误便可以导入。
DevicesID 的 CSV 格式应该遵循如下格式内容：
<Serial NUmber>,<Windows Product ID>,<Hardware Hash>,(optional <Group Tag>)
至此，DeviceID 便添加到了 Intune，在设备还没有注册到 Autopilot 上时设备使用序列号作为设备名称，我们可以在 “ Azure Active Driectory”中的“Devices - All devices”下找到它们。
虽然我们在 Intune 中添加了设备的硬件标识信息，但是该设备还未受当前 Intune 的管控，也就是如果我们开机进入 OOBE 阶段，仍可以进行自定义的配置，或者使用其他组织的账号绑定设备。
Intel 存储控制器驱动版本引发的 Windows 蓝屏故障 0xC0000098
Intel 存储控制器驱动版本引发的 Windows 蓝屏故障 0xC0000098
最近在评估一款 PC 设备，由于通过 WDS 部署评估映像，并使用了 DDP（Dynamic Driver Provisioning）注入驱动，发现在部署操作系统后第一次启动时会发生 0xC0000098 故障，提示由 iaStorAC.sys 文件引起。
iaStorAC.sys 文件很常见，是 Intel 存储控制器的驱动模块，经查隶属于 iaAHCIC.inf，随即排查 WDS 驱动库，发现包含两个版本的 iaAHCIC，分别是16.8.0.1000 和 15.2.0.1020。
其中 16.0.8.1000 包含的驱动模块为：iaStorAC.sys
而 15.2.0.1020 包含的驱动模块为：iaStorA.sys 和 iaStorF.sys
猜测 DDP 注入了当前匹配硬件的驱动后，发现还有该硬件的新版本驱动，并包含旧版以外的文件，所以也一同安装了这个新版驱动。在实际排错过程中 gOxiA 也发现系统同时加载了 iaStorA、iaStorF 和 iaStorAC，可预料 iaStorAC 与当前系统不兼容，所以引发 0xC0000098 故障，之后尝试禁用 iaStorAC 发现会导致系统蓝屏，看来要彻底解决只能卸载该驱动。
在脱机状态下，使用 DISM 维护映像，通过 get-drivers 参数获取该驱动分别对应 OEM2.inf 和 OEM16.inf，此时除了对比两个驱动的版本外，也可使用 get-driverinfo 来获取驱动程序的详细信息。当确认影响系统的驱动是 OEM16.inf 后，可通过 remove-driver 将该驱动从脱机系统中移除。
现在重新启动，系统会先执行短暂的初始化，之后便能正常引导系统完成后续的安装。
现在很多品牌机的驱动交付质量都已经大大不如从前，也可能驱动程序更加复杂，导致经常以标准化方式注入驱动后，发现系统出现故障，或驱动未能正常安装的情况，这对于桌面标准化交付来说确实是一个挑战，因为每一批设备可能都需要进行完整的评估和测试。
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，且发生了莫名其妙的问题，多半都是由于老旧的安全软件版本导致的。
