HOWTO: 使用 Windows ADK 生成 ADKTools
HOWTO: 使用 Windows ADK 生成 ADKTools
Windows ADK 即 Windows 评估和部署工具包（Windows Assessment and Deployment Kit），可用于自定义和部署 Windows 10 映像的部署工具，其中 WinPE、USMT、DISM 等工具是桌面运维人员最为常用的部署工具，其中的 DISM 更是有别与 Windows 系统内置的 DISM，前者功能更强大，因为可以用于创建和部署 Siloed Provisioning Packages（SPP）。
（注意：自 Windows 10 1809 开始 PE 与 ADK 分开发布）
前面已经提到，ADK 中包含了桌面运维人员最为常用的部署工具，如果要在不同的设备上使用，默认则需要安装 Windows ADK，这样执行效率就大打折扣。其实 Windows ADK 中的工具多数都支持免安装运行，我们只需要在一台设备上安装完毕后，将所需的工具复制出来即可，但是手动复制各个工具所涉及的文件非常不便。
其实，Windows ADK 中内置了一个脚本，可以方便我们生成所需的 ADKTools，其中包含了 DISM、USMT，以及 Windows Setup 的相关文件。要使用该脚本，需要从 Windows Kits 程序组中找到“Deployment and Imaging Tools Environment”（部署和映像工具环境）并运行它。
然后，键入“CopyDandI.cmd amd64 d:adktools”执行自动复制，脚本会将适用于 64位系统的相关文件统一复制到指定的目录中。
最后我们将这个目录放到一个共享位置，或 U盘中即可，当然也可以集成到 PE Boot.wim 中。有了这个 ADKTools 后，我们就可以创建和部署 SPP，以及执行用户数据迁移等工作。
HOWTO: 解决 WDS 无法导入 Realtek PCIe GBE Family Controller 驱动的问题
HOWTO: 解决 WDS 无法导入 Realtek PCIe GBE Family Controller 驱动的问题
一台基于 Windows Server 2012 的 WDS 服务器，为 Lenovo M910t 机型添加驱动，发现 Realtek PCIe GBE Family Controller 驱动无法导入，其文件名为 rt64win7.inf，属于 64位体系架构驱动。
在添加过程中仅提示某些程序包无法添加到服务器中，但并没有给出具体的失败原因。可参考的常见原因是驱动未签名，驱动程序包损坏或网络连接问题。
经测试，该驱动可直接集成到系统映像（WIM）中正常安装和使用，检查发现驱动签名也是正常的，极有可能是该驱动与 WDS 不兼容，也尝试下载了其他版本的驱动发现均发生此类问题。由于 PE10 引导后可正常驱动该网卡，所以临时的解决方案即在 WIM 中集成该驱动。在 Windows 10 中由于 DISM 可以直接管理 WIM，所以 IT 人员可以直接使用 DISM Mount WIM，并将驱动集成到映像中，操作过程中使用到的命令行参考如下：
- Dism /mount-image /imagefile:d:\goldimages\customizeos.wim /index:1 /mountdir:c:\mount\windows
- Dism /image:c:\mount\windows /add-driver /driver:d:\drivers\realtek /recurse
- Dism /unmount-image /mountdir:c:\mount\windows /commit
若要使用命令行对 WDS 已经添加的安装映像可使用 wdsutil /replace-image命令，参考命令行：
- wdsutil /replace-image /image:"Windows 10 Pro x64" /imagetype:install /replacementimage /imagefile:"d:\goldimages\customizeos.wim
近期从 Realtek 官方下载了最新发布的网卡驱动，发现在驱动程序包中有一个提示文本文件，如下图所示！
按照 Realtek 官方的建议，将 Realtek PCIe GBE Family Controller 驱动包中的 WinPE 驱动添加到 WDS，此问题即可解决，且网卡也能正常使用。
微软发布 MDT 8456
微软发布 MDT 8456
中国当地时间1月26日，正值周末，也临近新年，但 gOxiA 早已养成早起的习惯，上了推才发现圈内人士都在转发 MDT 的最新推文，原来是微软发布了 Microsoft Deployment Toolkit 的最新版本 MDT 8456。
在这一版开始支持 Windows 10 / Server 2019 的 1809版本，并且可与 Configuration Manager 1810 进行集成。功能方面并没有带来太多的惊喜，嵌套任务序列的支持是本次更新带来的新功能。此外，MDT 8456 仍继续支持部署 Windows 7 操作系统，所以 IT 人员不要犹豫，为了能够提供更完善的 Windows 10 部署，建议升级到 MDT 8456。有关本次更新版本的具体信息，可参考微软官方文档。
https://docs.microsoft.com/en-us/sccm/mdt/release-notes
升级到 MDT 8456 非常容易，从微软下载中心拿到 MDT 8456 后可直接在当前 MDT 环境执行升级安装，他会自动卸载当前旧的 MDT 版本，并使用新版替代。
在完成升级安装后，打开 MDT 的 Deployment Work Bench 会看到提示，要求对当前部署点进行更新。我们可以在左侧的部署共享列表中选中部署点然后执行“Upgrade Deployment Share”，这样就会自动更新部署点内的相关脚本和文件。
在部署点升级完毕后，我们仍旧需要执行“Update Deployment Share”来更新我们的 LTI PE，如果之前有创建过媒体部署，也需要进行更新。
MDT 8456 下载地址：https://aka.ms/mdtdownload
HOWTO: 使用 DISM 配合脚本批量删除驱动程序
HOWTO: 使用 DISM 配合脚本批量删除驱动程序
利用 DISM 或 Pnputil 我们已经能够实现脱机或在线模式批量安装硬件的驱动程序，那么如何能够实现批量卸载已经集成到映像中的驱动程序呢？！
假设我们的映像编制人员为 Surface 设备创建了定制化的系统映像，并集成了 Surface 的设备驱动程序，现在我们希望编制好的映像可以作为通用映像部署在其他计算机上，这时我们就需要清理已经集成在映像内的驱动程序。
要卸载映像内集成的第三方驱动程序，我们首先需要列表出来它们，所以为此我们执行如下命令行。
利用上述的参考命令我们可以检索到当前映像中已经安装的硬件驱动程序，其中“已发布的名称：oemX.inf”是我们需要记录的数据。接下来使用下例命令行就可以从映像中卸载驱动。
细心和已经在使用该命令管理的驱动的朋友会注意到，由于映像中第三方驱动可能会很多，有时多大近70个，那么我们就需要一次一次执行上面的卸载驱动命令，将 oemX.inf 从映像中删除，这将是一件令人崩溃的任务。有些朋友可能会利用 Excel 批量转换和生成指令，其实我们完全可以利用批处理命令“For ... Do ...”来实现。
实现逻辑就是利用 DISM 的 Get-Drivers 参数获取驱动列表，并查找其中的唯一特征，例如下图所示我们能看到所有被列出的第三方驱动程序都不是“内置驱动程序”，那么可以用它来作为检索关键词。
[code]dism /image:c:\ /get-drivers /format:table
我们有了用于检索的关键词，就可以使用“find”来获得准确的驱动列表，可创建变量以生成动态驱动列表，便可以实现动态批量卸载驱动，参考脚本如下：
以上脚本可以从 gOxiA 的 Github 获取。https://github.com/goxia/ITSM/blob/master/remove_driver.bat
[MDT]HOWTO: 解决 LiteTouch OEM 发生 0xC000014C 引导故障
HOWTO: 解决 LiteTouch OEM 发生 0xC000014C 引导故障
通过 LiteTouch OEM 默认任务序列制作好 Media，拿到客户端实施，LiteTouch OEM Media 引导正常，也执行了 LiteTouch OEM 任务序列，正常结束并关机。再次开机后，引导过程中发生 0xC000014C 故障，具体错误可参考下图。
该问题通常发生在 UEFI 引导类型的机器上，这是因为 LiteTouch OEM 默认的任务序列中使用的是基于 MBR 类型的分区方案，只有一个 NTFS 格式的分区卷，所以到客户端引导时就会发生故障。
解决办法很简单，在现有“Format and Partition Disk”任务上将其改名为“Format and Partition Disk (BIOS)”，然后根据需要重新划分磁盘分区，再在“Options”选项下添加变量：“IsUEFI not equals True”。
同理再新添加一个磁盘任务序列，命名为“Format and Partition Disk (UEFI)”，定制好分区后，也添加一个变量“IsUEFI equals True”。
最后重新生成 Media，即可解决 0xC000014C 故障问题，且同时支持 BIOS 和 UEFI 类型的计算机。
[MDT]HOWTO: 解决 LiteTouch OEM 发生 DISM Error 11 故障
HOWTO: 解决 LiteTouch OEM 发生 DISM Error 11 故障
MDT 的 Lite Touch OEM 任务序列用于在计算机硬盘上预加载操作系统映像。通常由计算机原始设备制造商（OEM）使用，但一些企业也有类似场景的需求。本文 gOxiA 将于大家分享的是解决实施 LiteTouch OEM 过程中，可能发生的 DISM Error 11 故障问题。
按照标准流程创建完毕 LiteTouch OEM，并生成 Media 后，拿到客户端上进行测试，在释放映像的过程中发生故障，导致 LiteTouch OEM 任务序列终止，如下图所示：
在 Details 中能看到故障发生在 WIM 释放阶段，尝试手动执行命令提示“Error 11”，指出“试图加载格式不正确的程序”。在网上搜索了 DISM Error 11 的相关信息，并没有多大的帮助。更换了其他版本的 DISM 执行同样发生此错误，只能再重新领会错误信息。
gOxiA 尝试调用网络共享中的 WIM 执行该命令行，发现并未有问题。说明 MDT 在生成 Media 时出现了异常，但是向导程序并未成功检测到复制发生了错误，最终导致该故障的发生。而 DISM Error 11 给出的错误提示又未能完全表达意思，误导了用户。
对于 MDT 任务序列的执行过程都是相关命令和资源的调用，如果通过错误提示无法分析故障原因，不妨参考日志手动执行命令行，也许真相就会显露出来。
补充：该问题最终查明，存储 LiteTouchOEM 的媒介是 连接在这台虚拟机上使用 SCSI 接口的虚拟磁盘，而这个虚拟磁盘又存储在固态硬盘上，所以导致近 9GB 的数据以每秒近 500MB 的速度瞬间写入，随后由于手工断开 SCSI 磁盘，导致缓存未成功写入。:-P
[Tips]解决因超大内存导致的Windows系统安装故障
解决因超大内存导致的Windows系统安装故障
一台 Dell 工作站，硬件配置有 128GB 内存和 512GB 固态硬盘，IT 人员为 512GB 固态硬盘平均划分了两个分区，在安装 Windows 操作系统时发生故障，具体表现为在 Specialize 阶段初始化系统时发生错误，如下图所示：
检查了相关日志文件，发现记录有 “CopyProfileDirectory from C:\Users\Administrator failed (0x80070070)” 错误事件，经分析 0x8007007 为磁盘容量已满导致的故障。
在当前案例场景下检查，512GB 仅划分了两个分区，且只格式化了用于安装系统的分区，而当前硬件设备配置了超大容量的内存（128GB），导致在 Specialize 阶段生成 Hiberfil.sys 文件后，没有可用空间再生成 Pagefile.sys，因为设备存储没有其他有效格式分区，系统无法利用其他分区存储 Pagefile.sys，最终导致 0x80070070 故障。
这个看似简单的问题实际上在解决过程中非常复杂，尤其是在企业 IT 环境中。如果单纯为了解决本次故障，可以将第二个分区格式化，这样在 Specialize 阶段初始化时，如果系统分区容量不够，则会自动在第二分区上创建 Pagefile.sys。但如果企业采用了定制的标准化系统映像，那么问题就会非常复杂。
起初 gOxiA 计划在 Specialize 阶段的 RunSynchronous 中添加一条命令“powercfg /h off”来实现关闭休眠文件（Hiberfil.sys），但测试发现此条命令并不会生效。翻阅了微软官方的文档提示应该在 RunAsyncronous 中执行该命令，于是又进行了尝试，结果发现并未生效，也检查了相关的日志文件，确实在 Specialize 阶段成功执行了命令，但也确实并未生效。而微软官方文档推荐在 AuditMode 阶段执行，也就是说 oobe 也是支持的，但是这些阶段执行“powercfg /h off”并不能解决本案例实质性问题。
为了解决这个问题只能从注册表下手，可以修改注册表，将系统 Power 下的 HibernateEnabled 键值设置为 0 ，即可禁用休眠功能。测试在 Specialize 阶段执行如下命令行。
测试结果是 Specialize 阶段修改了注册表也不会即刻生效，所以最终的结果是直接修改映像（WIM）的注册表键值。通常采取的做法是 Mount WIM，然后在注册表中加载映像中的注册表文件，位于“C:\Windows\System32\config”。
问题虽然是解决了，但是也引发了其他的问题，企业环境中的笔记本该怎么办呢？！这里给出几个方案供选择：
1. 按照不同机型，分配不同的映像。
2. 按照不同机型，应用不同的应答文件。
3. 不同机型使用同一个映像和应答，附加专为企业定制的配置工具，在配置过程中识别机型，并执行相关配置和维护脚本。
[Tips]HOWTO: 解决在 M2NVMe 固态硬盘上部署 Windows 7 的故障问题
HOWTO: 解决在 M2NVMe 固态硬盘上部署 Windows 7 的故障问题
故障描述：WDS 部署 Windows 7，安装结束后在 Start Logo 处自动重启，无法正常初始化操作系统，导致安装失败。
故障分析：WDS 部署 Windows 7 时 Boot.wim 使用的是 Windows 10 的 17134 版，在磁盘分区界面能够正常识别硬盘，说明驱动没有问题。而且 WDS 为此 Windows 7 映像绑定有对应设备机型的驱动库，所以在执行部署时会将相关驱动自动导入系统驱动存储区。基本可以排除设备驱动导致的故障。分析硬件设备，是一台图形工作站，磁盘配置为：1TB 固态 + 4TB 机械 * 2，其中 1TB 固态硬盘为 M.2 NVMe 接口的 Samsung MZVLW1T0。
解决方案：Windows 7 wSP1 RTM 不兼容 M.2 NVMe，为已知问题。需要向微软申请热修复补丁：KB2990941-v3、KB3087873-v2，下载到补丁后将其安装到脱机映像中即可。需要注意，如果你计划使用 Windows 7 的 Boot.wim，还需要将补丁安装到此 Boot 中，建议同时将磁盘驱动一并安装到 Boot，以在安装阶段识别硬盘驱动器，当然也可以在安装界面单独载入驱动。
HOWTO: 为 Windows 自动添加配置无线网络
HOWTO: 为 Windows 自动添加配置无线网络
由于 Windows 应答文件（Unattend.xml）中并未包含自动配置 WiFi 的选项，而在企业中确实存在为定制的标准化系统映像预先添加企业 WiFi 的需求，或者希望将一个脚本包发给用户，可以自动添加和配置无线网络。为此，微软在 Windows 10 上推出了新的配置工具 WICD，即：Windows 映像和配置设计器，可以轻松实现多种场景需求。
以自动添加和配置无线网络为例，新建一个“高级预配”，然后在左边配置列表中找到“运行时设置-ConnectivityProfiles-WLAN-WLANSetting”，根据需要添加并设置其下的参数。如果要配置的 WiFi 不允许自动连接，可将“AutoConnect”设置为“FALSE”；一些企业默认的办公用途公共 WiFi 通常会进行隐藏，所以为此需要为此类型的 WiFi 启用“HiddenNetwork”；“SecurityType”和“SecurityKey”这是 WiFi 网络的安全协议和密钥。
当配置工作完成后，便可以导出这个预配包，格式为 .PPKG，可以在 Windows 10 系统上执行运行。
因为配置包通常都非常小，IT人员可以通过邮件发送给用户自助执行，当然也可以使用 DISM 在向标准化映像添加，或在映像初始化中自动执行，具体的命令行参考如下：
企业 IT 人员对于早期的 Windows 系统版本，如 Windows 7，也有非常高的需求。那么该如何实现呢？！
使用 Netsh 可以在 Windows 7 上轻松实现以上的过程。首先找一台电脑连接到 WiFi，之后执行以下命令行，将无线配置导出为一个 xml 文件。
如果要在其他电脑上导入这个 WiFi 配置，则需要执行以下命令。
在应用无线配置文件时，需要注意，如果当前 WiFi 是一个隐藏网络，且不允许自动连接，那么需要检查无线配置文件，并对主要参数进行修改。对于隐藏网络，需要将“nonBroadcast”设置为“TRUE”；而连接模式“connectionMode”设置为“manual”。
[WDS] 通过 WDS 为 Windows 10 部署提供驱动安装支持
WDS（Windows Desployment Services）即 Windows 部署服务，其架构需求简单，配置灵活，使用起来轻松直观，所以深受企业 IT 服务台的青睐，常用于简单需求的 Windows 桌面系统安装场景。在一些管理级别不高的企业，为了简化管理和部署过程，WDS 中的系统安装映像通常使用的是集成了万能驱动的版本，但是对于复杂多样的企业 IT 环境，此法反而弄巧成拙，导致交付到用户手里的 Windows 设备经常会出现蓝屏、性能低下等异常的故障。
其实 WDS 本身也提供驱动部署的支持，只是基于数据库结构管理，所以刚上手的用户可能对其操作流程并不适应，时常会因操作出错，而需删除已有的配置重新来过。今天 gOxiA 将与大家分享 WDS 驱动管理方面的知识和经验，为了方便说明专门整理了一张图希望能够让更清晰明了的让大家了解。
WDS驱动管理是基于数据库结构管理的，对于驱动文件本身的管理其实非常简陋，并不是很智能。其完全依赖筛选器来进行管理和部署驱动，而筛选器可提供的选项又并非满足大家的需要，所以在使用WDS进行驱动管理时应该遵循如下的流程规范：
1、先创建驱动组，驱动组基于设备机型及系统架构来创建，例如我们要通过 WDS 为 ThinkPad X270 部署 Windows 10 Pro x64，那么我们可以先创建名为“Lenovo-X270-Win10x64”的驱动组。为了确保该组下所有的驱动都能被正确安装，所以建议选择“安装此组中的所有驱动程序包”。
2、导入驱动包，将厂商发布的 Drivers Pack解压缩，并添加到WDS中，因为是要批量导入驱动，所以选择“从文件夹中选择所有驱动程序”，这样向导将遍历目标路径下的所有子目录添加驱动。如果企业驱动库位于一个UNC路径，可先通过资源管理器访问并复制路径填写到位置栏。
可用的驱动程序包界面可看到搜索到可添加到WDS驱动库的驱动程序，大家会注意到体系结构包含x64、x86，甚至有些还会包含IA64，如果要导入的驱动数量较少，或者你不嫌麻烦，可以在如下图步骤中去除那些不适用于X64架构的驱动，因为大家应该记得，前面的驱动组添加过程中我们配置为“安装此组中的所有驱动程序包”，如果导入的驱动不适用于X64架构，如包含了X86或IA64驱动，将导致WDS部署客户端操作系统时，在“特殊化”阶段报错，导致安装失败。
导入驱动后，可能会提示部分驱动无法导入到WDS驱动库中，这是因为部分驱动未包含签名，可能会导致设备出现意外故障。通常我们可以忽略，如果在WDS部署客户端设备后发现有未知设置未能成功安装驱动，可单独联系厂家获取驱动。
添加到驱动组这一步非常重要，WDS的运维人员在这一步的操作一定要谨慎，不要出错，因为WDS的驱动管理完全依赖筛选器，如果这一步出现错误，可能会导致我们要推翻之前所有的驱动操作，重新来过一遍。
3、修改驱动组筛选器，前面的步骤我们已经完成了对应设备机型的驱动组及其对应驱动的添加，那么如何确保创建的驱动组能正确匹配到要部署系统的客户端设备上呢？！为此，我们需要为驱动组添加一些筛选器，确保其与设备和映像匹配。为了确保设备机型与驱动组匹配，需要为驱动组添加“制造商”和“型号”筛选器。
制造商即设备的品牌，如本例中 Thinkpad X270 的制造商为 LENOVO，而其型号却为 20K6A00DCD，那么我们该如何确认一个设备的制造商和型号信息呢？！有两个办法，从包装盒获取，不同时期发布的产品或批次，这些名称可能都不会相同；另一个办法是使用 WMIC 指令，如：“wmic csproduct get …”其中 … 为 vendor 时是提取设备制造商名称，而为 name 时是提取设备型号。
在制造商和型号通过筛选器匹配后，我们还需要确保驱动组与映像进行匹配，所以我们继续添加如下筛选器：“OS版本”和“映像ID”，其中 OS版本 可在安装映像属性中查看到，但是需要注意筛选器中的OS版本包含两个信息，一个是映像版本，还需要加上 Service Pack 级别，以本案中的 Windows 10 为例，那么其最终的 OS版本号应为 10.0.16299.0。
而映像ID 获取相对来说就较为繁琐了，在 WDS 管理器中是无法查看映像ID的，需要通过命令行进行操作，参考如下：
借助 WDS 的命令行获取映像ID，“wdsutil /get-image /image:”Windows 10 Pro” /imagetype:install /imagegroup:”Windows 10 x64”，gOxiA 建议获取到的映像ID单独存储在一个文本文件中，便于日后查看。此外，映像ID是添加映像文件（WIM）到WDS时产生的唯一值，如果你删除重新添加了映像那么其ID便会变更，但是如果你使用替换映像的操作方式，则不会影响到映像ID。
4、删除驱动，前面的三个步骤完成后驱动的导入即告结束，但请不要忘记因为我们导入的驱动包含X86和IA64，所以我们需要使用WDS的删除驱动功能来帮我们从驱动组剔除掉无用的驱动程序。过程很简单。打开删除驱动对话框，添加搜索筛选器，选择要从哪个驱动组删除驱动，并指定要删除的驱动架构版本，搜索到后便可批量删除。这里需要注意的是，虽然我们能够通过筛选器来删除特定组中的驱动，但是如果其他组有相同的驱动时，执行删除的操作也会从在其他组中生效。
对于WDS的驱动管理，基本就是导入和剔除驱动，不要想着可以利用筛选器去满足更多的需求，因为稍有不慎就会导致整个WDS驱动库推翻重来。
