HOWTO: 快速在 UEFI 启动的 Windows 10 中添加 Native VHD Boot
HOWTO: 快速在 UEFI 启动的 Windows 10 中添加 Native VHD Boot
今天又要与大家分享关于 Native VHD Boot 的小技巧了，搜索本站 gOxiA 已经写了不少关于 Native VHD Boot 的文章，虽然之前也有撰写“Windows 10 Native VHD Boot 案例分享”，但本文将向大家介绍如何在基于 UEFI 启动的 Windows 10 中添加一个 Native VHD Boot 实例，整个操作过程期间并不需要重启进入PE环境，完全就地解决。
准备一个准备添加 Native VHD Boot 的安装源，可以是 ISO 也可以是 WIM，前者需要先 Mount ISO 到当前系统，以便于访问其中的 WIM；之后在当前卷新建一个目录用于存放 Native VHD Boot 的 VHD 文件，例如“C:\VHDBoot\”;接下来使用磁盘管理器创建一个 VHD 文件WS2012R2.vhd，存储在前面的目录中，建议使用固定大小，注意请务必转换为GPT磁盘，根据需要进行分区，格式化为NTFS。固定大小的 VHD 虽然占用了不少空间容量，但可避免不必要的麻烦；然后再释放 WIM 映像到这个 VHD 中，方法相信大家已经轻车熟路，使用内置的 DISM 命令即可完成，命令行可参考“dism /apply-image /imagefile:G:\sources\install.wim /index:1 /applydir:V:\”，映像应用完毕即可unmount VHD，现在就差创建启动信息。
由于是系统在线环境，且引导卷处于隐藏状态，所以最为方便的添加 Native VHD Boot 启动信息的方案就是使用 BCDEdit 工具，基于默认启动项新建一个新的 Native VHD Boot 启动信息，修改 Device 和 OSDevice 选项指定到前面创建的 VHD 路径上，即可完成。为此参考如下命令行执行！
1. bcdedit /copy {default} /d "WS2012R2 Native VHD Boot"
2. bcdedit /set {GUID} device vhd=[c:]\VHDBoot\WS2012R2.vhd
3. bcdedit /set {GUID} osdevice vhd=[c:]\VHDBoot\WS2012R2.vhd
现在重新启动便可以出现多启动菜单，可选择 Native VHD Boot 来启动系统，UEFI 比较不人性化的是当选择另一个启动项后会再次重启计算机，这个没办法 UEFI 的设计使然。是不是非常简单，只要理解了相关的概念，命令能够做到得心应手，就能针对不同场景制定实现方案！
HOWTO: 使用 Windows 10 内置命令管理设备驱动
HOWTO: 使用 Windows 10 内置命令管理设备驱动
在 Windows 10 之前在线管理和维护设备驱动是相当困难的事情。对于IT专业人员如果需要批量导入并安装驱动，只能依赖第三方应用程序，或者事先编写执行脚本。虽然我们可以使用 DISM 来执行操作，但关键的操作命令还是只能对脱机系统映像有效，所以还是非常的繁琐！为什么会如此尴尬呢？因为 Windows 支持硬件设备的即插即用（PnP）特性，而这一特性是由本地系统映像中强大的驱动库（DriverStore）来支撑的，它位于 Windows 的 System32 目录下。当系统连接一个新的硬件后会从这个 DriverStore 中搜索驱动，当发现匹配的驱动后变化配置为硬件设备使用，而此时驱动会被复制到 Windows 的 System32 下的 Drivers 目录中，被设备实时加载，而设备所需的其他子配置文件或程序文件可能分布在系统的其他目录中。
如果我们要安装驱动则需要使用设备管理器手工为硬件设备更新或安装驱动，也可以使用设备生产商提供的驱动安装程序来执行安装，但是对于一些 OEM 设备，尤其是笔记本来说，需要反复执行设备驱动安装操作十几次，也是相当令人崩溃的，即使像前面所讲使用第三方应用程序实现批量安装，但要实现自动化处理还是命令来的更实在。
Windows 10 提供了两个内置命令用于设备驱动的管理和维护，DISM.exe 和 Pnputil.exe 。DISM 在系统在线（联机）状态下只支持导出驱动，如果要添加和删除驱动必须在系统脱机状态下进行。
- DISM 添加驱动
dism /image:c:\mount\offline /add-driver /driver:c:\drivers /recurse /forceunsign
/recurse，遍历指定目录下的所有子目录，还是相当有用。
/forceunsign，添加未签名的驱动，在 X64 系统上添加未经签名的设备驱动可以使用这个参数。 - DISM 删除驱动
dism /image:c:\mount\offline /remove-driver /driver:oem1.inf
设备所安装的第三方驱动都会被重新按照 Oem0.inf，Oem1.inf，Oem#.inf 命名方式存储，而删除的时候亦是如此。要获取系统都安装了哪些驱动可使用 /get-drivers 参数。令我们感到悲催的是删除驱动不支持通配符，只能一条一条执行，或编写成批处理脚本。 - DISM 导出驱动
dism /online /export-driver /destination:c:\exportdrivers
也只有导出驱动是可以在系统脱机和联机状态下进行的，这倒是十分方便。一般IT部门拿到新型号笔记本后通常会使用这个命令导出驱动。（PS：这个习惯要养成，因为厂商提供的打包驱动不一定会完整，这是真的！！！）
注意，即使能够脱机状态添加驱动，但是所添加的驱动也只能用于未安装驱动的设备实现自动的驱动安装，即已经安装的驱动不会被自动更新和替换，除非你在设备管理器中手动执行更新，或通过 Windows Update 从微软获取最新的设备驱动。（PS：十分无奈！！！）
DISM 在脱机 Windows 映像中添加和删除驱动程序的完整过程可参考微软官方提供的资料，这里就不再过多的讲解。
参考资料：https://msdn.microsoft.com/zh-cn/library/windows/hardware/dn898469(v=vs.85).aspx
接下来再说说 Pnputil.exe - Microsoft PnP 工具，在 Windows 10 之前，这个工具简直就是鸡肋，可实现的设备驱动操作非常的有限，它更像是 DriverStore 层的维护工具。因为对硬件的实时驱动根本起不到管理作用。直到 Windows 10 v1703 版，Pnputil 才算真正意义的即插即用硬件设备驱动管理工具。其主要特性是允许在系统联机状态下执行添加、安装、卸载、删除以及导出驱动的操作。前面提到过设备被识别后，驱动是实时加载的，此时是无法使用命令行在联机状态下删除驱动的。而 v1703 较 v1607 最大的改进是支持了 卸载 和 安装 参数，即除了对 DriverStore 层执行操作外，也可以对 Drivers 层执行操作。
- Pnputil 卸载和删除驱动
pnputil /delete-driver oem#.inf /uninstall /force
/uninstall，卸载并删除驱动
/force，强制执行即使设备驱动正在使用中
/reboot，更具需要重启系统以完成操作
注意：直至 Windows 10 v1703 仍旧不支持批量卸载和删除驱动。 - Pnputil 添加和安装驱动
pnputil /add-driver c:\oem\*.inf /subdirs /install
/subdirs，遍历子目录
/install，安装或更新驱动 - Pnputil 导出驱动
pnputil /export-driver * c:\driverbackup
注意：导出驱动支持 * 通配符，也支持导出单个驱动 Oem1.inf，要枚举驱动可使用 /enum-drivers 参数。
DISM 和 Pnputil 相比较，DISM 更适用于系统映像准备阶段方便日后分发，例如拿到一批新型号设备，可以导出 OEM 驱动，并准备一个测试用途的企业标准化系统映像，使用 DISM 将驱动导入脱机映像中，当映像被安装到这些新型号设备后便可自动识别和安装驱动到系统中。而 Pnputil 更适用于联机系统的维护，例如 IT 专业人员从厂商获取到设备的最新驱动包，可以使用 Pnputil 直接批量安装和更新设备驱动。利用这些命令，我们还可以编写灵活的脚本满足更多的应用场景。
HOWTO: 为 MDT Media LiteTouch 启用 WIM Split
HOWTO: 为 MDT Media LiteTouch 启用 WIM Split
现在的系统映像容量是越来越庞大，像 Windows Server 2016 的 ISO 要想通过 UFD 以 UEFI 方式来安装，可真是要提前准备一番，2个 UFD 一个是 FAT32 格式的用来做 UEFI 引导，另一个 NTFS 格式的用来存储安装源，没办法WIM 超过了4GB，相信这个场景不少 ITPro 都曾遭遇过！尤其通过 MDT 的 Media LiteTouch 安装系统时，问题尤为突出！虽然前段时间 gOxiA 与大家分享了 Widnows 10 v1703 支持 UFD 创建多分区 的文章，在 MDT 实践中可以通过创建对应目录结构实现 Media LiteTouch 部署大容量自定义系统映像的需求，但之后的维护工作却非常繁琐。其实在 MDT 中已经提供了 WIM 的分卷功能，只是官方很少提及！截止到今日，官方与网上都没有一个明确的说明该如何为 MDT Media LiteTouch 启用 WIM Split。（PS：明显的坑，大坑！）
gOxiA 抽出时间做了一下功课，对 MDT WIM Split 做个总结。WIMSplit 确实受 MDT 支持，但是官方并没有提供图形化的设置界面，我们需要修改配置文件中对应的选项参数来启用它。这个选项为“ <SkipWimSplit>False</SkipWimSplit>”，位于“settings.xml”中。也就是说只要在 Settings.xml 中将 SkipWimSplit 配置为 False 那么在对 Media 执行刷新时就会自动将大于 4GB 的 WIM 映像进行分拆。而网上普遍存在修改 SkipWimSplit 后并未生效的主要原因是选错了 settings.xml，问题就是这么简单！还没理解？！搜搜 settings.xml 都位于哪几个目录下？去修改主 settings.xml 就会作用到 Media LiteTouch。
这个问题的起因完全是用户和开发者概念逻辑不统一所致！大家都认为应该修改 Media 下的 Settings，但实际上需要修改部署点的，在刷新 Media 时脚本会将系统映像分拆然后拷贝到 Media 下，完毕后会删除原始位置的 SWM文件。
