gOxiA=苏繁=SuFan Blog

  

微软发布适用于 Windows 10 v1803 的远程服务器管理工具

  

        微软近日发布了适用于 Windows 10 v1803 版的远程服务器管理工具（RSAT），利用该工具可以在 Windows 10 PC 上远程管理Windows Server 的服务角色，如：DCHP、DNS、AD 等等。

  

        RSAT 区分 x86 和 x64，需要根据当前 Windows 10 架构选择下载和安装适当的 RSAT 版本，在下载页面提供有多个系统版本的 RSAT，请务必下载 1803 版。（PS：早期的 RSAT 存在已知问题，安装后缺少 DNS 服务器管理工具）

  

        RSAT 下载地址：https://www.microsoft.com/zh-CN/download/details.aspx?id=45520

  

        要卸载 RSAT 需通过“程序和功能”中的“查看已安装的更新”找到“KB2693643”，将其卸载即可。

  

  

        Windows FFU images 的全称是 Windows Full Flash Update images，字面上翻译是全闪存更新映像。早期用于微软移动设备的更新及系统的安装（刷机），当然也支持工厂模式快速部署 Windows PC 设备。FFU 格式与 Ghost 的特性很像，能够将物理驱动器的映像直接应用到其他驱动器上，这包括了：Windows、恢复分区和系统启动分区等信息。

  

        正如上面所述的特性，FFU 与 WIM 格式是不同的，WIM 是基于文件的，而 FFU 是基于扇区，它能够存储一个或多个分区。而基于扇区的映像意味着更短的部署时间，但缺点是一个 FFU 文件的容量要比 WIM 大。（PS：磁盘容量越来越大，对于企业部署来说，时间才是关键。）

  

        FFU 自 Windows 10 v1709 开始正式被支持（PS：之前虽有资料，但 gOxIA 从未成功过），DISM 具有捕获、部署和服务 FFU 的能力，但是 FFU 仍有以下限制：

  

  
• 应用 FFU 的驱动器容量必须与源驱动器容量相同或者大于后者。
    
• FFU 不支持捕获加密磁盘
    
• FFU 不支持启用了卷影复制服务（VSS）的磁盘
    
• FFU 不支持拆分和压缩
    
• FFU 仅支持 1709 或更高版本的 系统或 PE 环境
    
• 要捕获的 Windows PC 需经过 Sysprep

  

        此外，建议使用 USB3.0 驱动器来存储 FFU 映像，由于 FFU 不支持拆分，所以请务必确保驱动器的格式为 NTFS。

  

        下图展示了  FFU 格式，详细的说明请参考：

  

https://msdn.microsoft.com/zh-cn/library/windows/hardware/dn757539(v=vs.85).aspx

  

  

        为了更好的认识 FFU 格式，可参考 WIM、VHD 与 FFU 的比较：

                                                                                                                                                                                                                                                                                                                                                                                             

	Windows 映像 (.WIM)	虚拟硬盘 (.VHD/VHDX)	完整刷机更新 (.FFU)
常见用法	测试和修改 Windows 映像的最快方式。            快速装载和修改映像。	将 Windows 部署到虚拟电脑的最简单方式。            你可以直接从单个 VHD/VHDX 文件启动新的设备。	在工厂车间捕获和部署 Windows 的最快方式。            包含验证签名映像的内置安全功能。
映像样式	基于文件	基于扇区	基于扇区
压缩	支持多种类型的压缩	无	无
它捕获了哪些内容？	一组文件，最多为整个分区。	捕获完整的驱动器信息集，包括分区。	捕获完整的驱动器信息集，包括分区。
当应用映像时，会发生什么情况？	将文件和文件夹添加到分区。            如果现有的文件和文件夹具有相同名称，则将会替换它们。否则，将保留现有文件。	清理整个驱动器。	清理整个驱动器。
是否可以部署到不同大小的硬盘驱动器？	是。	是，不过新驱动器的大小必须等于或大于原始驱动器。	是，不过新驱动器的大小必须等于或大于原始驱动器。
是否可以修改映像？	是。通过使用 DISM 等工具，你可以装载、修改和卸载映像。	是，你可以将 VHD/VHDX 视为可移动介质来进行装载，并修改文件。	是，不过它仅限于添加程序包。
安全性			包括一个安全标头和一个映像标头，可标识安全的映像。            包括一个目录和一张哈希表，可在设备上进行刷机之前先验证签名。

  

HOWTO: 解决 Windows 10 Hyper-V Host Compute 启动故障 0x80070005

  

        今天微软为 Windows 10 v1709 发布了新的累计更新 KB4093105（16299.402），解决了不少的问题，于是 gOxiA 一早更新了这个补丁，但在更新完毕重启后发现 Hyper-V 无法使用，但在已知问题列表中未查询到有价值的信息。

  

  

        打开服务管理器（Services.msc）检查 Hyper-V 相关服务，发现 Hyper-V Host Compute Service 服务无法正常启动，提示 0x80070005 访问拒绝。而在事件查看器中也找到了这个事件的记录。

  

  

  

        抓包大概看了一下，在栈中比较可疑的是“mmunsecurevirtualmemory”，貌似因为传递了未加密的虚拟内存数据，难不成因为什么安全规则导致的？！但貌似这函数与Hyper-V也没有直接的关系，Bing 了一下也没什么参考资料，也许这个思路就是错误的！！！

  

  

        之后也想过用 WinDbg 附加到该服务上看看具体过程，但使用 gflags 附加 vmcompute.exe 未能成功启动 WinDbg，也没再深入研究为什么！！迷茫中，想起来同系统版本的其他机器也打了补丁，倒是没有发生这个故障，比较了两个系统设置，唯独是正常运行Hyper-V的机器禁用了 Defender，之后做了对比和测试找到了影响 Hyper-V 服务启动的根因——Control Flow Guard（CFG），Exploit protection 的一个子功能。有关 CFG 的介绍可以参考官方文档：“Control Flow Guard”。

  

  

        结论，当 CFG 为关闭状态时就会导致 Hyper-V Compute Service服务启动失败，所以必须将其设置为“On by default”。其中的“奥妙”也许只能期待以后微软方面能给出详细的说明！