针对 CVE-2026-0386 的 WDS 指导

        微软 MSRC 今天公布的安全漏洞中，CVE-2026-0386 描述了 WDS Hands-Free Deployment 的安全问题，WDS 通过未认证的 RPC 来传输 Unattend.xml，其不当的访问控制将允许未经授权的攻击者通过相邻网络执行代码。虽然攻击复杂性比较高，但对于在使用该项功能进行 Windows 部署的组织需要进行合规和安全评估，并尽快实施治理方案。

        微软目前已经给出的解决方案，并根据以下时间线推进，目前第一阶段（2026年1月14日中国当地时间），Hands-Free 部署仍被支持，但 IT 管理员可以禁用以增强安全性。在第二阶段（2026年4月）微软将通过更新的方式默认禁用 Hands-Free 部署功能，但如有需求，IT 管理员仍可以重新启用。

        具体的步骤指导如下：

• 第一阶段
• 当前 IT 管理员在评估该安全问题后，可通过手动配置注册表的方式禁用 Hands-Free 部署。
• HKLM\SYSTEM\CurrentControlSet\Services\WdsServer\Providers\WdsImgSrv\Unattend
• DWORD: AllowHandsFreeFunctionality
• Value: 00000000
• 第二阶段
• 如果 IT 管理员使用其他防护方案并继续使用 Hands-Free 部署，那么在2026年4月更新系统后需要手动配置注册表重新启用 Hands-Free 部署。
• HKLM\SYSTEM\CurrentControlSet\Services\WdsServer\Providers\WdsImgSrv\Unattend
• DWORD: AllowHandsFreeFunctionality
• Value: 00000001

        对于运维维护，IT 管理员可在 WDS 日志（Microsoft-Windows-Deployment-Services-Diagnostics/Debug）中看到相关的记录：

• 安全模式
• 将会看到警告日志，并记录“Warning: Unattend file request was made over an insecure connection. Windows Deployment Services has blocked the request to keep the system secure. For more information, see: https://go.microsoft.com/fwlink/?linkid=2344403”
• 不安全模式
• 将会看到错误日志，并记录“Error: This system is using insecure settings for Windows Deployment Services. This may expose sensitive configuration files to interception. Apply Microsoft’s- recommended security settings to protect your deployment. Learn more at: https://go.microsoft.com/fwlink/?linkid=2344403”

        WDS Hads-Free Deployment 即通过为 Boot Client 或 OSImage 指定应答文件来实现自动化部署。通过 AllowHandsFreeFunctionality 键值可以控制是否允许此项功能，从而禁用无验证 RPC 流程。

具体请参考 KB5074952

Microsoft Deployment Toolkit（MDT）正式下架
         这不仅是一个工具的落幕，更是一个 IT 工程时代的谢幕。从最初的 BDD 到 MDT，它用脚本、流程和标准化方法支撑起起了 Windows 在全球商业范围内的大规模自动化部署，奠定了企业桌面系统可规模化、标准化交付的基本范式。它是那个时代的工程化象征，也是无数 ITPro 的共同记忆。
         随着传统部署时代的落幕，行业全面转向基于现代模式的云管理、零接触部署与 DaaS。MDT 作为传统部署的典范，完成了一次历史性的交棒，设备交付也全面进入云优先时代。

2003-2026 R.I.P
致敬 ITPro，致敬那个时代，全面拥抱下一个时代……

推荐

动态部署：

Provisioning packages for Windows | Microsoft Learn

Windows subscription activation | Microsoft Learn

现代部署：

Overview of Windows Autopilot | Microsoft Learn

Overview of Windows Autopilot device preparation | Microsoft Learn

现代管理：

Microsoft Intune overview | Micrsoft Learn

DaaS：

What is Virtual Desktop | Microsoft Learn

What is Windows 365 | Microsoft Learn

377926/35

Windows ADK 10.1.28000.1 (2025年11月) 现已发布

        Windows ADK 10.1.28000.1 极其对应的 Windows PE 加载项现已在 Windows ADK 网站发布并提供下载，支持 Windows 11 26H1，提供对 Arm 64 的支持。在 Windows ADK 的选择上微软建议使用与 Windows 版本相匹配的 ADK 版本，如果当前组织环境混合使用不同的 Windows 版本，则推荐使用与环境中最新操作系统匹配的 ADK 版本。在使用多个 Windows 版本时需要注意的事项如下：

• Windows PE
• 可以使用 Windows PE 来部署早期版本的操作系统。
• 如果要自定义 Windows PE，需确保使用与要自定义的 WinPE 版本相匹配的 WinPE 可选组件。
• Windows 11 在 32bit 架构中不再可用，因此不支持为 Windows 11 使用 32bit 的 WinPE 版本。上一个支持 WinPE 32bit 的版本用于 Windows 10，但不能用于部署 Windows 11。
• 部署工具
• 较新版本的部署工具可用于版本低于正在使用的 ADK 版本的 Windows。
• 其他工具
• USMT、WSIM 和评估工具包，请使用与操作系统相匹配的 ADK 版本。
• 对于其他工具，则需要查看文档确认这些工具与所使用的操作系统的兼容性。
• Microsoft Endpoint Configuration Manager
• 需参考 Configuration Manager 中对 Windows ADK 的支持。

        对于 Windows ADK 的新版本功能和特性，微软也给出了详细的说明。

• Windows 评估工具包
• 常规稳定性、功能、性能和合规性改进。
• 实时翻译、即点即用、语音搜索和召回功能的 AI 评估改进。
• 更新了针对“立即加入”按钮更改的 Teams 评估。
• 更新了 Edge 浏览器评估，以便进行提示更改和错误修复。
• 更新了内存占用情况评估，以解决“找不到符号”的错误。
• 使用更新的 Post on/off 试探法改进了快速启动持续时间计算的准确性。
• 添加了 Windows Studio Effects 相机的性能评估。
• 更新了 YouTube 视频流评估，以适应与视频质量选择相关的 UI 更改。
• 更新了 Edge Web 浏览评估，以适应 Outlook 登录过程中的更改并改进密码提示处理。
• BCD 启动

只要计算机支持此 CA，使用“Windows UEFI CA 2023”签名的启动二进制文件将自动得到支持，无需任何额外参数。 默认情况下将设置 /bootex 选项，除非该工具在脱机模式下使用。

• 媒体体验分析器（MXA）

添加了 Power xdm，启用 HW 计划程序，修复了 Default.xml 中的拼写错误，以及其他错误修复。

• 批量激活管理工具（VAMT）

已更新以支持 Windows Server 2019/2025 产品密钥
已更新以支持 Microsoft Office 2024 产品
已更新以支持新的零售 Windows 产品密钥

• Windows 性能分析器（WPA）
• 新功能
• 插件管理改进和增强的错误处理。
• 用于追踪分析的命令行配置文件处理和符号选项增强。
• 新的表和列，包括与 AI 相关的表、CPU 空闲延迟和扩展的 Locks 表指标。
• 用于自定义的开发人员模式和高级插件选项。
• 支持跨多个表的共享筛选器和改进的预设管理。
• 性能改进
• 延迟的图形初始化，可加快跟踪加载速度并提高响应能力。
• 远程桌面的硬件加速支持。
• 用户界面更新
• 刷新的控件和对话框可提供更好的无障碍功能和深色模式支持。
• 改进了错误消息和状态指示器。
• 漏洞修复
• 稳定性增强功能解决了崩溃、挂起和 UI 不一致问题。
• 修复了插件安装、预设管理和跟踪处理的问题。
• 其他更新
• 迁移到 dotNET 8 以提高性能。
• 改进了多显示器和 DPI 支持。

下载地址：

• Windows ADK 10.1.28000.1 (2025年11月)
• Windows ADK 10.1.28000.1 的 Windows PE 加载项 (2025年11月)

Microsoft Configuration Manager 将转换为年度发布节奏

        近期微软官方发布了一则通告，宣布 Microsoft Configuration Manager 改为年度发布节奏，从 2609 版本开始一改过去的半年发布计划，采用年度发布的方式。这个发布周期的调整将会更好地支持 CM 用户的长期规划和运营稳定性。使我们能够清晰知道何时会发布新版本，有规划的做好升级准备工作；每个新版本都将可靠性置于新功能之上，让我们能够专注于稳定性和安全性；并按照自己的节奏向云原生管理 - Microsoft Intune 转变。

        Microsoft Intune 是设备管理的未来，微软会持续将所有新的创新体现在 Intune 中。而 CM 将继续为本地设备提供服务，并关注在安全性、稳定性和长期支持方面。CM 年度版本将会和 Windows 客户端安全性和稳定性节奏保持一致，确保用户享有可靠和安全的 CM 体验。

        虽然 CM 将改为年度发布，但其支持生命周期保持不变，每个版本自发布之日起将会获得 18 个月的支持。具体可参考：Microsoft Configuration Manager Lifecycle | Microsoft Learn

原文引用：

https://techcommunity.microsoft.com/blog/configurationmanagerblog/announcing-the-annual-release-cadence-for-microsoft-configuration-manager/4464794

项目发布：PPKG

        用于 Windows 自动化部署的 PPKG 文件和工程模板，帮助 IT 人员快速实现部署并学习 PPKG 制作。

        本项目提供 Windows 配置包（PPKG） 及其 工程文件，帮助 IT 人员和技术爱好者：

• 快速实现 Windows 自动化部署
• 减少手动配置时间与重复工作
• 学习如何使用 Windows Configuration Designer 创建和定制 PPKG

        适用场景

• 企业批量部署 Windows
• 教学与培训
• 测试和实验环境的快速配置
• 个人定制系统初始化

项目地址：https://github.com/goxia/PPKG

首发：Automated OOBE

https://github.com/goxia/PPKG/tree/main/Automated%20OOBE

HOWTO: 在全新部署 ConfigMgr TechPreview2411 时解决 SQL RMO 无法安装的问题

        今天快速分享一个 ConfigMgr 部署时遇到的小问题，ConfigMgr TechPreview2411 发布有一段时间，在该版本总提供了一些新的功能特性，我们可以先简要了解一下。

• 主要增加了对 Windows 11 24H2 和 Windows Server 2025 的支持。
• Windows 11 24H2 和 Windows Server 2025 已添加到产品生命周期仪表板和支持的平台。
• 添加了 Windows 11 24H2 和 Windows Server 2025 客户端支持。
• Windows Server 2025 上的 CM 中的启用映像现在支持最新的 Windows ADK。
• Windows 升级就绪仪表板现在支持 Windows 11 24H2 来升级客户端。

        需要注意：Windows Server 和 Windows 11 24H2 不支持防火墙规则。这会导致 ConfigMgr Applet 出现不合规状态。

• CMG（Cloud Management Gateway）增强的安全性，现在 CMG 安装程序使用托管标识的第三方服务器应用与 CMG 的 Azure 存储账户交互，而不是存储账户密钥。对于从早期版本升级到 4311tp 的场景，CMG 增强安全性按钮显示为已启用。CMG Entra 应用程序密钥续订功能包含四个选项。此更新还阻止超过 800 天续订其密钥。
• SQL 2012 和 2014 支持已弃用，从此版本开始，ConfigMgr 不再支持 SQL Server 2012 和 2014 版本。需要升级到最新的 SQL 版本或至少 SQL Server 2016。如果不升级，CM 升级将被阻止，并在预发布检查期间提示错误。
• Arm64 设备中的软件计数支持，ConfigMgr 现在支持 Arm64 设备的软件计数。软件计数用于监视文件名以 .exe 结尾的 Windows 电脑桌面应用。

        最近 gOxiA 在进行 Windows 11 24H2 部署相关的测试，所以搭建了一套基础环境用于全新部署 ConfigMgr TechPreview2411。安装准备过程比较顺利，但等到开始安装后没多久便会提示安装失败，具体报错如下图所示。

        从报错看是在执行 SQL RMO 安装时发生了错误，打开 ConfigMgrSetup.log 可以确认 CM Downloads 中的 msoledbsql.msi 安装失败。回顾之前的准备工作也都是按照提示一步步执行的应该不会有什么问题啊？！随即手动安装 msoledbsql.msi 测试，发现提示 VC++ 2022 Redistributable 版本过低，要求 14.34 或更高版本。

        回顾之前的准备过程，在启动 ConfigMgr 安装程序时会提示需要先安装 Microsoft ODBC driver for SQL Server Setup，但要安装这个程序则需要先安装 VC++ 2017，而向导提供的安装包版本为 14.16.27052.0，低于 msoledbsql.msi 所要求的最低 14.34 版本。

        按照最后提示的 VC++ 下载地址（https://go.microsoft.com/fwlink/?linkid=2219560）进行安装，仍旧提示失败！！！难道是需要 x86 版本？！随即测试验证通过，问题得以解决。总结一下个人感觉 ConfigMgr 非常庞大且复杂，其中涉及方方面面的很多细节不容忽视，稍有不慎就会引发各种各样的问题，所以熟读官方文档，反复测试积累经验，还是非常有必要的。

使用 WDS 部署 Windows 11 24H2 Arm 的可行性研究

        今天继续分享与 Windows 自动部署相关的话题，前面介绍了“基于 Autounattend 应答文件的 Windows 11 24H2 Arm 自动化安装”，这次 gOxiA 要与大家分享一下最近在 WDS 上部署 Windows 11 24H2 Arm 的收获。如果你关注过之前的一篇日志“WDS 变更部署支持”，会了解到 WDS 很关键的信息，即便如此 gOxiA 还是希望通过实践做一下可行性研究。

        环境为一个工作组的Windows Server 2025（以下简称：WS2025），安装了 DHCP 和 WDS Role，并进行了配置目前属于可工作状态；客户端是一台 Arm 架构的设备，支持 PXE Boot 启动。首次尝试时，我先导入了 Windows 10 22H2 Arm 安装源中的 Boot.wim，在成功执行 PXE Boot 引导进入 Windows Setup 的 PE 环境后，报了一个错误，如下图所示，看起来是 DHCP 导致的一个问题。

        在导入网卡、USB等驱动后仍旧是报这个错误，看来应该是底层做了某些限制，指示给了一个完全无关的报错。之后又尝试导入 Windows 11 24H2 Arm 的 Boot.wim，启动后如下图所示，看起来是缺少相关驱动。

        但实际测试后发现即使导入了驱动也仍是这个提示，而且需要调用 CMD 执行网络初始化才能启动网络，但始终是提示需要驱动的界面，同上也只能放弃！

        最后的希望只能放在 Windows PE 上了，使用 Windows ADK 生成 Arm64 的 PE，并集成了网卡驱动，将其添加到 WS2025 WDS 的启动映像中，客户端引导成功，并且网络能够自动初始化。尝试做了 Ping 可连通 WS2025 服务器，并且还能够正常使用 Net use 命令。但当 gOxiA 尝试向该 PE 集成相关的 Setup 和 WDSTools 相关组件后，则该映像将启动失败。结论同上，应该是底层做了限制，就是要杜绝掉使用 WDS 执行 Windows Setup。

        OK，gOxiA 再换个思路，不在当前 PE 集成相关组件，使其成为一个可正常引导并访问访问网络的 PE 环境，之后从网络加载 Windows 11 24H2 Arm 的安装源，手动执行 Windows Setup，惊喜！！！竟然以 Legacy Setup 模式成功启动了 Windows Setup，但是呢……安装向导会提示当前设备不符合 Windows 11 最低需求。

        怎么可能！？该设备绝对是满足的，要了解真相只能排查日志 - Setupact.log，如下图所示，TPM没有被检测到。手动做了 TPM 的Bypass 检查跳过，这次可以了……

        既然因为检测不到 TPM 而终止，那就想办法为 PE 集成 TPM 驱动呗！想着简单，实现起来可是难上加难！首先查看 TPM 驱动发现它是一个系统级自带的驱动，与之相关的只有 TPM 固件驱动，检查 TPM 固件对应的 OEM.inf，再确认实际的 inf 名称，将其加载到 PE，谁想仍旧无法正常检测到 TPM，成为了难解之题，只能放到后续再研究。

        总结，通过本次测试研究，可使用基本版的 Windows 11 PE，通过手动加载 Windows 11 24H2 Arm 安装源的方式启动 Windows Setup，对于 TPM 问题可以通过 BypassCheck 的方法处理。那么 gOxiA 完全可以手动编制一个定制 PE 自动执行这些操作以完成 Windows 11 24H Arm 的自动部署。只是这样一来，WDS 仅仅是充当了一个 PXE Boot 的角色，而部署则完全依赖 WS2025 的 SMB。

        后面，会抽时间完成这个 PE 的定制，如有收获会继续与大家分享！

已删除的 Windows 功能 - 20241001

        随着 Windows 11 24H2 的发布，我们也迎来了全新的 AI 端侧时代，微软正在加速 Windows 的演进，逐步去弃用和删除那些过时的或极低使用率的 Windows 功能。今天这篇日志主要面向 Windows 部署管理员，以帮助他们更好地掌握 Windows 的功能变化。以下是 2024年10月1日的最新数据（PS: 可能未全部包含，可参考文末官方文档链接）。其中提及的特性和功能都已经从 Windows 客户端的产品映像中移除，这意味着依赖于这些功能的应用程序或代码在发布版或更高版本中不再起作用。

• 写字板，2024年10月1日，从Windows 11 24H2 和 Windows Server 2025 开始，从所有版本移除。
• Alljoyn，2024年10月1日，Microsoft AllJoyn 的实现已被移除。
• 更新符合性，2023年3月31日，Windows 客户端的基于云服务的更新符合性已移除，替换为 Windows Update for Business reports。
• 应用商店上传程序工具，2022年11月，已移除对存储上传工具的支持，此工具仅包含在 Windows SDK 中。该工具的终结点已从服务中删除，文件将在下一版 SDK 中移除。
• IE11，2022年6月15日，已从 Windows 客户端移除，但用户仍可以使用 Microsoft Edge 浏览器中的 IE 模式访问旧网站。
• 基于 XDDM 的远程显示驱动程序，21H1，此版本在中已删除 Windows 2000 显示驱动程序模型（基于 XDDM）的远程显示驱动程序的支持。
• Microsoft Edge 旧版，21H1，Microsoft Edge 旧版在2021年3月9日之后不再受支持，并从系统中移除。
• MBAE 服务元数据，20H2，MBAE 应用体验将替换为 MO UWP 应用。
• 连接应用，2004，默认情况下将不再安装使用 Miracast 进行无线投屏的 Connect App，但将作为可选功能提供，并更名为“无线显示”功能。
• Rinna 和日语地址建议，2004，日语输入法编辑器的 Rinna 和日语地址建议服务于2020年8月13日结束。
• Windows To Go，2004，在Windows 1903中宣布弃用，并被移除。
• 移动计划和消息传递用用，2004，这两个应用现在仅以 OEM 的渠道分发，仅包含在那些已启用手机网络设备的 Windows 映像中。
• PNRP API，1909，在 Windows 1809 中已经关闭了对等名称解析协议（PNRP）云服务，2024年2月，将在 Windows 11 24H2 中移除对应的 API，建议使用 DNS-SD 和 mDNS 来实现服务发现方案。
• 任务栏设置漫游，1909，已移除任务栏设置漫游，在1903时已宣布弃用。
• 桌面消息应用不提供消息同步，1903，已移除桌面上的消息传递应用的同步功能，其本可用于同步从 Windows 移动版接收的短信，并在桌面上保留这些短信副本。
• 分布式扫描管理（DSM），1809，已移除此扫描程序管理功能，没有支持此功能的设备。
• Unattend.xml 中的 FontSmoothing 设置，1809，该设置已被移除，不再需要此设置，应答文件会自动忽略此设置。Windows 10 已默认使用 ClearType。
• 全息影像应用，1809，已将该应用替换为“混合现实查看器”。
• Limpet.exe，1809，微软将发布用于访问 Azure 连接的 TPM 的 Limpet.exe 工具，开放源代码。
• 手机助手，1809，已从系统移除，可使用设置应用中的手机页面将手机于电脑同步。
• WES7-SP1和WES8，1809，微软不再向 Windows Embedded Standard 7-SP1和8发布新的更新，将改为 Microsoft 更新目录下载。
• Groove Music Pass，1803，微软于2017年通过MSStore结束了 Groove 流媒体音乐服务和音乐曲目销售。Groove App 正在更新以反映此更改。
• 人员建议将不再包括非 MSA 的未保存联系人，1803，仅手动保存你向其发送邮件或从中接收邮件的人员的联系人详细信息。
• 控制面板中的语言控件，1803，已移除，使用设置应用更改语言设置。
• HomeGroup，1803，已移除，建议使用 Windows 内置的网络共享功能来共享打印机、文件和文件夹。
• 连接到建议的开放热点，1803，已移除，需要手动连接 Wi-Fi 热点。
• 3D Builder 应用，1709，已移除，建议使用画图3D。
• Apndatabase.xml，1709，已移除。
• 增强的缓解体验工具包（EMET），1709，已移除，使用 Exploit Protection 作为替代项。
• Outlook Express，1709，已移除。
• Reader App（阅读器应用），1709，已移除，并集成到 Microsoft Edge。
• 阅读列表，1709，已移除，并集成到 Microsoft Edge。
• 主题中的屏幕保护功能，1709，已移除。GPO、控制面板和Sysprep中的屏幕保护程序功能仍能正常运行。建议首选锁屏界面功能和策略。
• Syskey，1709，已移除，并建议用户改用 Bitlocker。
• TCP 卸载引擎，1709，已移除，该功能已转换为堆叠 TCP 引擎。
• 磁帖数据层，1709，已替换为 Title Store。
• ReFS，1709，仅在 Windows 10 企业版和专业工作站版可用，其他 SKU 将移除。
• Microsoft Edge 旧版中的 Flash，1703，改为使用单击即运行（C2R）选项。
• 交互服务检测服务，1703，已移除。
• Microsoft 画图，1703，此应用程序不适用于不在完整本地化列表中的语言。
• TLS 中的 NPN 支持，1703，已由 Application-Layer 协议协商取代。
• Windows 信息保护策略，1703，不再支持 AllowUserDecryption 策略。
• 适用于 Windows Mobile 的 WSUS，1703，过度到统一更新平台（UUP）。

        对于 已弃用的 Windows 功能 和 已弃用功能的资源，IT 管理员建议参考以下官方文档。

• 已弃用的 Windows 功能
• 在2024年10月1日的文档更新中，可以了解到宣告弃用的功能：旧版 DRM 服务，画图3D，Adobe Type1字体，DirectAccess，NTLM，驱动程序验证程序GUI，NPLogonNotify和NPPasswordChangeNotify API，密钥长度短于2048位的 RSA 密钥的 TLS 服务器身份验证证书，Test-Base，Windows Mixed Reality，适用于 Microsoft Edge 的 Defender 应用程序防护，旧版控制台，Windows 语音识别，Office 的 Defender 应用程序防护，步骤记录器，技巧提示，Computer Browser，WebDav 服务，Remote MailSlots，Microsoft Entra 账号的时间线，VBScript，写字板，AllJoyn，TLS 1.0/1.1，Cortana，MSDT Windows支持诊断工具，适用于32位 Arm 版 UWP 应用程序，基于云服务的更新合规性，Windows 信息保护，BitLocker To Go 读取器，个性化漫游，WMIC，TimeLine 时间线，Microsoft Edge 旧版，Windows Hello companion device framework，动态磁盘，Bitlocker管理和监控 - MBAM，反馈中心的语言社区选项，包状态漫游，XDDM，任务栏漫游，Wi-Fi WEP 和 TKIP，Print 3D，配套设备动态锁 API，OneSync 服务，GPO 中的软件限制策略，脱机符号程序包 - Symbols MSI，Windows 帮助查看器 - WinHlp32.exe，MBAE 服务元数据，文件资源管理器中的联系人功能，手机助手，IPv4/6转换技术（6to4、ISATAP，Teredo 和 Direct Tunnels），Layered Service Providers，分布式扫描管理 - DSM，IIS6 管理兼容性，IIS 摘要式身份验证，适用于 IIS 的 RSA/AES 加密，主题中的屏幕保护程序功能，同步设置，系统映像备份，TLS RC4 密码，TPM 所有者密码管理，TPM.msc 和 TPM 远程管理，使用 Microsoft 配置管理器的 Windows Hello for Business 部署，PowerShell 2.0，Apndatabase.xml，磁贴数据层，TLS DHE_DSS 密码，TCP Chimney 卸载，IPSec 任务卸载，Wusa.exe /uninstall /kb:xxxxxxxx /quiet。
• 已弃用功能的资源

VBScript 弃用计划

        早在去年的10月份微软就宣布将逐步弃用 VBScript，至今年5月份公布了 VBScript 弃用计划时间表和后续步骤。最近 gOxiA 在测试 Windows 11 24H2 及对应的 LTSC 版本，所以又做了研读并写此日志备忘及分享各位。VBScript 历史悠久，首次推出于 1996 年，其全称是 Visural Basic Scripting Edition，它是一种轻量级的脚本语言，在过去几十年中 IT 人员总会利用 VBScript 执行自动任务，或编写控制程序。它还经常被嵌入到 HTML 页面中使用，可以提升动态交互体验。作为 Windows ITPro 你一定知道 MDT（Microsoft Deployment Toolkit）这款伟大的 Windows 部署工具，它富有严谨的逻辑性，在 gOxiA 眼中就是一款 IT 系统部署的艺术品，它完全免费，全部基于 VBScript 所编写。所以将会非常关注 VBScript 未来弃用计划。

        VBScript 已经不再是系统默认组件，它将作为按需功能（FOD）提供，以下是微软给出的计划和后续步骤。

        在第一阶段，VBScript 将以 FOD 方式预装在所有的 Windows 11 24H2 中，并默认启用。这意味着 IT 也可以根据当前企业环境的需要对其进行卸载。

        第二阶段，在2027年左右，默认情况下将不再启用 VBScript FOD。这意味着 IT 如果仍依赖 VBScript，可以通过“可选功能”或命令行方式 “ DISM /Online /Add-Capability /CapabilityName:VBSCRIPT~~~~ ” 单独启用 VBScript FOD。

        第三阶段，VBScript 将停用，并从未来的系统版本中移除。这意味着 VBScript 相关的所有文件都将被移除。此时也宣告所有依赖于 VBScript 的项目将停止运行。

        在 VBScript 即将弃用这段时间，微软建议考虑使用两种现代解决方案来替代 VBScript，它们是 PowerShell 和 JavaScript。微软还专门提供将 VBScript 转换为 PowerShell 的指导文档 “The VBScript to Windows PowerShell Conversion Guide”。

        是时候对 MDT 说再见了！去拥抱 Windows 动态部署和现代部署方法了。

HOWTO: 使用 WinGet 从 Microsoft Store Apps 下载 Windows App 进行脱机分发

        WinGet 即 Windows Package Manager（Windows程序包管理器），一款微软原生的以命令行方式运行的应用程序包管理，它还提供了 open source client，可用于应用程序的云安装。WinGet 发布于 2020 年的 Microsoft Build 大会上，当时 gOxiA 还写了一篇介绍的日志“体验新的 Windows 程序包管理器”。过去 WinGet 由于处于预览阶段，其 WinGet-cli 当时未内置于系统中，所以还曾写过一篇日志来讲解如何通过 Intune 分发 WinGet-cli “HOWTO: 通过 Intune 分发 WinGet 测试版”。在经过了几年的演进后，WinGet-cli 已经内置于系统，且不断在更新完善！就在前不久发布的 v1.8 版本开始还提供了对下载 Microsoft Store apps 的支持。这是一个令人兴奋的消息，它将提高企业 IT 在动态和现代部署方面的灵活性。此外，专注于 Intune 和 MSStore Apps 部署的朋友也许已经注意到 Microsoft Store for Business 已经退役下线，WinGet v1.8 就像及时雨一般，解决了当前下载 MSStore Apps 的问题。

        今天 gOxiA 将与大家分享的是如何使用 WinGet 下载微软应用商店中的应用安装包。以 “Windows App”为例，首先我们可以使用 WinGet Search 进行应用的搜索。从下图我们获得了一个搜索结果列表，位于第一行的便是要下载的“Windows App”，包含了它的 ID 信息，可能包含的版本信息，以及源于 MSStore。

        然后，我们可以使用 WinGet Show 显示应用的详细信息，其中我们可以检索该应用是否支持脱机分发，如下图所示 “Windows App” 的 “支持脱机分发” 状态为 “true”。

        接下来，我们可以使用 WinGet Download 进行下载。注意，虽然 WinGet 支持从 MSStore 下载应用安装包，但需要进行身份验证。

        只有完成身份验证后才能进行应用安装包的下载。在下载的过程除了会下载应用安装包，还会下载其依赖包以及应用许可证。注意，应用许可证会再进行一次身份验证。

        成功下载所有文件后，我们可以在“下载”目录看到它，WinGet 会以应用 ID 新生成一个目录，其中包含了所有相关的文件。

        最后，企业 IT 便可以通过 PPKG 或 Intune 的 Windows 业务线应用进行部署。

PPKG -

Intune -

推荐官方文档：

Use the WinGet Tool to install and manage applications | Microsoft Learn

为企业部署 Arm Client 做准备

        随着 AI 端侧运行的兴起，以及更多的基于 ARM 平台的品牌设备发布，预计在未来会有相当体量的 ARM Client 进入企业环境。对于需要进行 Windows 桌面标准化交付的组织，ITPro 需要了解基于 ARM 的 Windows 部署差异，提早准备部署测试环境，当商用 ARM 设备上市后可以及时有效的进行实践。

        在过去基于 ARM 的 Windows 设备将仅支持 Intune 这样的现代部署，以及 PPKG 这样的动态部署方法，对于使用映像执行传统部署的方案并不支持。但现在 Windows 11 最新版本（24H2）将开始全面支持基于映像方式的部署以及定制方案。

        在最新发布的 Windows ADK 10.1.26100.1 中，Windows PE 的 Arm 版本支持 PowerShell、.Net 和 Arm 上的 x64 仿真（Arm64EC）。对于 Windows PE Boot WIM，可以使用 CopyPE 指定 Arm64 生成启动文件，便可在 Arm 设备上引导启动。

        从 Arm64 的 WIM 文件看并没有什么“特别”之处。

        硬盘分区方面，UEFI 建议分区布局仍旧适用于 Arm。其中 System (Boot) 分区建议 260MB，MSR 16MB，Recovery 2GB。

        对于需要使用无人参与应答文件的 ITPro，当要为 Arm 的 OS WIM 生成编录文件时（.clg）则要使用 32位版本的 Windows SIM。基于 Arm 的 Windows 包含与 AMD64 Windows 相同的恢复环境，但 Arm 恢复环境下使用的工具必须与 Arm 兼容，此外 Arm WinRE 环境下是不支持 PowerShell 和 .NET 的。

        如果打算使用 PXE 服务器，如 WDS 进行 WIM 的部署，需要导入 Arm64 的 Boot WIM，这一过程还会自动导入 Arm64 的启动文件。

        系统定制方面 Arm64 与 传统 AMD64 过程一般相同，我们仍旧可以通过 Windows Setup 或 DISM 执行映像的手工安装。也同样可以 Mount WIM 文件并执行修改，Sysprep 以及 Audit Mode 也同样适用于 Arm64。

        语言包以及按需功能也都保持一致，但注意对应 Arm 版本。驱动程序方面，由于 Arm 的驱动要少于 x86 平台，所以需要确保拥有完整的 Arm 设备驱动程序，并且应当注入到 PE 和 脱机映像中 。

        此外，需要注意的是 Arm 平台不支持 FFU 方式，仅支持 WIM。

        虽然目前微软尚未公开提供 Arm 版的 Windows 安装源，但如果你已经拿到了基于 Arm 的 Windows 设备，其实是可以通过 PE 离线方式捕获 OSImage 或导出设备驱动的。这样一来，就可提前进行传统部署的测试环境！

        最后，虽然我们已经可以利用传统的部署方法来为 Arm 平台准备 Windows，但 gOxiA 还是极力推荐使用 Intune 的 Windows Autopilot 这种更现代的部署方案。一些 OEM 设备预装的 Windows 环境已经非常出色，整体干净整洁没有多余的程序或驱动附加应用，开机即可通过 Windows Autopilot 执行标准化部署，整个过程让人感到舒适轻松！最近看到 next generation of Windows Autopilot 的消息，有机会要试试到时与大家分享。

微软发布 Windows 部署"四部曲"

        今天这篇日志不是一篇纯技术分享，只是四个微软官方文档的推荐，非常适合那些计划部署 Windows 11、Windows 365 以及 Azure Virtual Desktop 的 ITPro，这仅是三部曲，那第四部其实是使用 Configuration Manager 执行 In-place upgrade（就地升级）。整个文档采用了带入式体验，提供了精心设计的学习内容，同时还与阅读者互动，甚至可生成用于部署的脚本，使大家能够更深入投入到文档学习和部署实践中。

        下来让我们一睹芳容！

Windows 11 setup guide，其中还蕴藏了很多相关产品/服务的 setup guide，内容十分丰富，绝对是宝藏级手册！

Windows 365 Enterprise deployment checklist，根据不同的部署选项，对不同检查进行分类并根据优先级进行说明。

Azure Virtual Desktop setup guide

In-place upgrade with Configuration Manager，跟随向导学习相关的知识内容，并提供部署相关信息，便可在最后生成部署脚本导入到我们的CM中进行实践。

即可行动起来！！！

HOWTO: 为基于 Windows 10 的 ADK 提供 UFS 支持

        UFS - Universal Flash Storage（通用闪存存储），是我们常见的闪存存储设备的一个类型，虽然名字与 eMMC 和 SSD 相比有些陌生，但提到手机或平板电脑，相信大家就容易理解了，是的目前都广泛采用了 UFS 作为存储设备。UFS 在性能方面比 eMMC 要强很多，但低于最新的 SSD，但肯定强于早前的 SSD，相信在用手机做文件复制时一定有所感受，其性能还是非常强劲的。

        UFS 目前也正广泛使用在 Windows 平板设备上，如果我们打开设备管理器查看磁盘驱动器可能并不会直观查阅到，但在存储控制器中可以清晰看到设备是否使用了 UFS 控制器（系统自带驱动）。如下图所示，该设备采用了 SAMSUNG 的 UFS 存储器。

        查阅了三星官网了解到 KLUDG4UHGC-B0E1 是一款 UFS 3.1 制式的存储器，尺寸只有 11×13×0.8mm，1.2/2.5v，看来是相当轻巧和省电；性能也是不错的！

        回到正题，如果买来的 Windows 设备预装的是 Windows 11，并且没有计划使用 Windows 10，那么可以划走这篇日志，否则跟随 gOxiA 往下走会有一些收获。

        在企业环境下，IT 通常会使用 Windows ADK 作为桌面标准化的定制工具，有经验的 IT 会知道 Windows 10 的 ADK 是基于 Windows 10 2004版的，即 19041。如果我们使用该版本的 ADK 生成 PE 用于批量部署，会发现默认将无法识别 UFS 存储器，也就是说当我们用 PE 引导设备后将无法识别到硬盘！！！

        那么我们该如何为基于 Windows 10 的 ADK 提供 UFS 支持呢？！前面讲过 UFS 控制器的驱动默认集成在 Windows 11 中，如果是缺少驱动支持，我们可以做旁加载，但实际测试发现在 Windows 10 ADK 的 PE 中是包含该驱动的，但为什么就不支持呢？！尝试将设备的驱动集成到 PE 也无济于事，看来应该与 Windows 10 操作系统本身有关。

        查阅了网络文献了解到“自 Windows 10 2004（20H1 - 19041）开始就引入了对 UFS 驱动器的支持，在此版本之前的 Windows 10 版本中，对 UFS 驱动器的支持可能有限或不完全。”既然如此就印证了前面测试的结果，包含了驱动但可能不完全支持，那么既然当前设备支持 Windows 10 22H2 操作系统（OEM PE 的版本为 19041.2728），说明 Windows 10 理论上是可以支持 UFS 的，也许问题就出在了累计更新上。

        由于 Windows 10 20H1 生命周期已经停止，所以可从 Windows Update Catalog 下载到的离线累计更新包（LCU）是有限的。查阅 19041.2728 发现其所对应的是 KB5023696，但该 KB 已经不再包含 19041 的相关说明和支持情况，仅支持 19042、19044和19045。但有提到如果脱机映像没有包含 KB5011543 (March 22, 2022)或更高版本的 LCU，则需要安装 KB5014032 (May 10, 2022 SSU)，经仔细复查发现其支持 2004 版 Windows 10，并提供了更新包。

        万事俱备只欠东风 - 实践出成果！从 Windows Update Catalog 下载 KB5023696 和 KB5011543，然后使用 ADK 生成一个 PE 实例，Mount 这个 Boot.wim 文件到指定目录，然后使用 “Dism /add-package” 为 PE 集成更新；建议锁定更新“Dism /cleanup-image /image:c:\winpe_amd64\mount /startcomponentcleanup /resetbase /scratchdir:c:\temp”；最后 Unmount 确认写入修改。

        使用已经集成更新的 PE 引导 UFS 设备，经测试已经可以识别 UFS 存储器，其 PE 系统版本为 19041.2728；Diskpart 的版本是 19041.964。

Windows ADK 2023年度9月更新 发布

        今天在访问 MSDN 订阅时竟然意外的看到 Windows ADK 发布了更新版本，并且同时更新了 ADK 主程序和 ADK PE 组件。真是让人惊喜和意外！！！

        当前版本为 ADK for Windows 11, Version 22H2 (updated September 2023)，包含了众多的更新和改进，主要为：

• Supply Chain Trust Tools
• 添加了”供应链信任工具“。（可选组件，通常 ITPro 用不上，不做过多介绍，开发人员会用上吧，主要生成与 SPDX - 软件包数据交换规范 兼容的 SBOM - 软件物料清单。）
• Assessment toolkit
• 更新了浏览电池使用时间工作负荷。
• 添加了人脸身份验证指标并提高了Modern Standby性能评估的可靠性。
• 为电池使用时间作业添加了新的自动诊断（包含了C状态驻留，闲置状态的纯净度）
• 修复了影响对评估结果进行的ETW跟踪处理的各种故障。
• 修复了影响媒体播放器自动计算媒体播放性能评估可靠性的各种Bug。
• 修复了电池使用时间测试期间随机发生的影响闲置纯净度的Bug。
• 修复了由于ETW检测更改而导致 Microsoft Edge 性能评估缺失性能指标的问题。
• Windows PE
• 添加了对 ARM64 WinPE 上的 x64 模拟作为可选组件的支持。（也就是说现在可以通过为PE集成 Architecture/WinPE-x64-Support，以在 ARM64 PE 上启用 x64 仿真支持，PS：难道这意味着未来我们将能够使用传统部署方法来执行 ARM 设备的系统交付？！）
• Windows PE Known Issues
• VBScript 当前在 WinPE 中无法工作。它预计在即将推出的服务更新中得到修复。（还在依赖 VBScript 脚本来执行部署的方案会受到影响，需要注意哦！）
• Windows Performance Analyzer (WPA)
• WPA已基于 .NET6 构建，包含原生的 ARM64 支持。
• 新 UI
• 解决了与 .NET 7 相关的 ETL 跟踪处理问题（ETW 0x80070032）。
• Windows System Image Manager
• x86 版本的 SIM 可以为所有受支持体系结构类型的 Windows 映像创建目录。
• Assessment toolkit known issues
• 在 ARM64 设备上，WPA可执行文件不会自动添加到 PATH 环境变量中。
• 在辅助监视器上以全屏模式最大化 WPA 时，左上角的右键菜单出现在不正确的监视器上。

        备注：

        应用程序虚拟化（App-V）将于2026年4月结束。届时，App-V 排序器将不再包含在 ADK 中。（PS：挺可惜，App-V 的前身是 Softgrid，当时2008年吧，还有幸参加了国内首批 TTT 培训。）

        以下是一些新版的解图，供大家参考，可见版本号已从 22621 变更为 25398。

        Windows PE Add-on 仅支持 AMD64 和 ARM64 (虽然能从参数中看到提供 x86，但实际无效！)，且不同版本的 PE Add-on 安装无法共存哦，会提示需要先卸载当前版本。（PS：但 gOxiA 觉得不代表不能魔改。）

HOWTO: 使用 PPKG 为 Windows 11 配置桌面和锁屏背景

        定制桌面和锁屏背景对于组织来说可以提升企业形象，并且也可以在登录或进入桌面时，利用背景图片中的信息来提示最终用户。

        在传统的部署方式中，IT人员通常会预先定制 Image 来实现类似的需求，或者通过 GPO。如何在动态部署方式中使用 PPKG 来定制 Windows 桌面和锁屏背景呢？其中又会遇到哪些“坑”呢？！今天 gOxiA 就来分享相关的知识。

        当我们决定使用 PPKG 来定制时，可能会觉得非常简单容易，在左侧选择“DesktopBackgroundAndColors”进行相关项的配置，但其实并非如此。如果查阅“DesktopBackgroundAndColors”官方说明，请不要忽略“Do not use. Instead, use the Personalization settings.”。

        是的，建议我们使用“Personalization”配置选项。如果当前要引用的图片文件来自网络，例如是一个 URL，那么配置后会发现没问题，可正确应用背景。但如果是要添加一个文件就没有那么容易了，仅仅配置“DeployDesktopImage”或“DeployLockScreenImage”从本地添加一个图片文件进去，在实际应用后并不会生效。

        仔细查阅文档，理解文档，原来还要同时配置“DeployImageUrl”和“LockScreenImageUrl”选项，既然是URL那么这两个选项该怎么写呢？填写文件所在的完整路径？！可是如何不深入研究怎么知道加载的图片文件最终会保存到哪个目录下？！等到研究了所有文档做了大量验证后，填写了目录路径，又发现根本无效。原来，URL这里只需要直接填写图片文件名即可！！！（惊讶，惊悚，这篇官方文档于2022年12月10日更新，但依旧没有说清楚！！！）

        大坑还在后面，查阅使用范围，可看到该选项适用于 Windows Client，可是如果最终在专业版上部署后会发现依旧无效。原因是什么呢？？？！！！

        原因是这个 Personalization 隶属于 CSP，而这个配置仅适用于如下 SKU。

        但是，但是呢！虽然这个 Personalization CSP 仅支持 企业版、教育版和 SE 版，但如果设置了 SharePC CSP 中的 SetEduPolicies 后，它也将支持 Windows 专业版。一波多折，不论怎样如果你看到了 gOxiA 的这篇日志，起码可以少走很多弯路！！！

HOWTO: 如何跳过 Windows 首次登录动画

        企业 IT 在不断优化大规模自动化部署的 Windows 配置，试图加快部署的速度，尤其是希望缩短系统初始化阶段的等待时间，曾经不少 IT 都遭遇到部署的深度定制的 Image 在完成 OOBE 后卡在了首次登录阶段，OOBE 全自动完成迅速进入到了 Windows 登录界面，但是当输入账号密码后却经历了漫长的首次登录动画。

        要跳过首次登录动画方法有很多，可以使用 GPO 或直接修改注册表，当然也可以通过 Intune CSP 实现。首先让我们回顾一下这些方案！

1. 通过组策略，定位至“计算机配置 - 管理模板 - 系统 - 登录”，找到“显示首次登录动画”，将其禁用。

2. 通过注册表方式，配置“EnableFirstLogonAnimation”键值为 0，它位于“HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System”，借助注册表的方式我们可以轻易的应用在不同的部署方式中。

3. Intune CSP

Scope：Device

Editions：除了Home以外

OS：1903及以上版本

Device：./Device/Vendor/MSFT/Policy/Config/WindowsLogon/EnableFirstLogonAnimation

Format：Int

Value：0

参考文档：https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp-windowslogon#enablefirstlogonanimation

        虽然我们有很多种方案来跳过首次登录动画，但在实际应用中会发现动画虽然不显示了，可登录到的桌面时间并未缩短。当我们输入账号密码点击登录后，会显示“正在准备 Windows”，一样需要等待一段时间。

        此时，我们可以借助“DelayedDesktopSwitchTimeout”键值，缩短登录脚本完成前与用户交互的超时时间。默认需要等待 Session 0 的 30秒超时时间。为此需要定制注册表键值，它位于“HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System”，类型是 DWORD，值为 0。很可惜 gOxiA 并未在 GPO 或 CSP 中找到这个配置选项，目前仅能通过注册表方式实现。

        当“DelayedDesktopSwitchTimeout”键值生效后，我们会发现首次登录桌面的时间将大大缩减，基本上是瞬间进入桌面，这将极大改善最终用户登录桌面时的体验。

HOWTO: 为 MSIX 创建自签名证书

        MSIX 是一种 Windows 应用安装包的格式，它可以将我们的 Win32 或 UWP 甚至是绿色版软件打包成 MSIX 格式用于企业批量和自动化部署。另外从官方文档了解到 1.2019.1220.0 还支持将包含的服务转换为应用程序。这对于一些要部署国产小软件的企业来说是个好消息，未来 gOxiA 也将尝试去打包那些应用程序。

        而今天我们要分享的是如何为 MSIX 创建自签名证书，因为 MSIX 生成后要发布给最终用户需要对 MSIX 进行签名，如果当前环境没有 CA 或无法生成所需的证书就需要创建自签名证书，否则无法应用 MSIX。

        在创建自签名证书前，我们需要确定 MSIX 的 发布者信息，通常这些信息位于 AppxManifest.xml 文件中，其 Publisher 信息必须与证书中的主体相同。之后参考下面的命令行创建证书：

New-SelfSignedCertificate -Type Custom -Subject "CN=Contoso Software, O=Contoso Corporation, C=US" -KeyUsage DigitalSignature -FriendlyName "Your friendly name goes here" -CertStoreLocation "Cert:\CurrentUser\My" -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.3", "2.5.29.19={text}")

        其中：

• -keyusage 表示证书的用途，对于自签名证书，应为 DigitalSignature
• -TextExtension 表示一些扩展设置，2.5.29.37={text}1.3.6.1.5.5.7.3.3，表示证书用于代码签名；2.5.29.19={text} 表示该证书非CA

        接下来使用 PowerShell 查看证书信息：

Set-Location Cert:\CurrentUser\My
Get-ChildItem | Format-Table Subject, FriendlyName, Thumbprint

        在确认了证书信息后，现在可以将证书导出为 pfx 格式，为此执行：

$password = ConvertTo-SecureString -String <Your Password> -Force -AsPlainText
Export-PfxCertificate -cert "Cert:\CurrentUser\My\<Certificate Thumbprint>" -FilePath <FilePath>.pfx -Password $password

        现在我们拿到了 pfx 就可以用于 MSIX 签名，后续 gOxiA 也会积极分享 MSIX 相关的实践。

参考文档：

https://learn.microsoft.com/zh-cn/windows/msix/package/create-certificate-package-signing

HOWTO: 大规模部署 Windows Teams 客户端

        早前 Teams 是作为独立的安装包来发布的，这对正在部署 Teams 的组织是一项巨大的挑战，因为很多 IT 还在下载 EXE 的安装包，并将其用于大规模部署中。其实 Teams 当前已经被包含在 Microsoft 365 Apps 中，下图可以了解包含 Teams 的版本发布情况。

        企业 IT 人员可以通过 ODT 生成安装配置文件直接部署，默认包含 Teams 组件。但如果你希望在 M365 Apps 安装中排除 Teams 也是可行的，通过在 XML 中添加  <ExcludeApp ID="Teams" /> 即可。

        如果因为某些原因，当前组织还在单独部署 Teams 应用程序，也完全不是问题，因为微软提供了用于大规模部署的 MSI 安装包。

Teams 商业：Teams 32bit，Teams 64bit，Teams ARM64

        虽然 Teams 提供了 MSI 安装包，但它还是比较特别的，并非传统的面向设备上下文安装，而是每当新用户登录产生新的用户配置文件时都会启动安装程序，并在用户的文件夹中安装 Teams 应用的副本。

        此外当首次启动 Teams 时还需要用户同意其配置防火墙，当然微软也为此提供了一个脚本方案 - https://learn.microsoft.com/en-us/microsoftteams/client-firewall-script?source=recommendations 。

        对于那些希望 Teams 在安装后不要自启动的场景，可以在 Teams MSI 部署时使用特定的参数 OPTIONS="noAutoStart=True" ALLUSERS=1 。或者通过组策略进行设置，“用户配置 - 策略 - 管理模板 - Microsoft Teams”。如果没有这个 Teams 管理模板，则需要提前下载准备，Office 管理模板下载地址：https://www.microsoft.com/en-us/download/details.aspx?id=49030

        但对于已经部署过的 Teams 并设置过自启动的用户实例，必须先将组策略设置为所需的值后，在基于每个用户运行 Teams 自动启动重置脚本。

        最后，如果要卸载并清理 Teams 安装，则可以参考微软提供的脚本：https://learn.microsoft.com/en-us/microsoftteams/scripts/powershell-script-deployment-cleanup?source=recommendations

参考资料：

https://learn.microsoft.com/en-us/MicrosoftTeams/msi-deployment

HOWTO: 使用 PPKG 跳过 Windows OOBE

        Windows OOBE 即我们常说的 Windows 初始欢迎界面，其标准术语是“Out of Box experience”，即 Windows 开箱体验。OOBE 包含了一系列的屏幕指引，如需要客户接收许可协议，指定所在区域，连接到 Internet，登录 MSA 或 M365 账号等等，以下仅仅列出了部分的屏幕步骤。

        如果你是以为企业 IT 桌面标准化的编制人员，那么下面的列表应该会很有帮助。用户在 Windows 10 OOBE 期间可能会看到的屏幕的非详尽列表，按顺序排列：

1. 语言选择
2. Cortana 欢迎
3. 区域选择
4. 键盘选择
5. 连接到网络
6. 自动下载关键 ZDP 和驱动程序更新。 有关详细信息，请参阅 OOBE 期间的 Windows 更新。
7. 最终用户许可协议 (EULA)
8. 登录或创建本地帐户或 Microsoft 帐户 (MSA)。 如果用户选择本地帐户选项，则 OOBE 流的下一步将显示“改为使用 Microsoft 登录?”屏幕。 此屏幕会建议用户使用其 MSA 登录，以获得最佳 Windows 体验。
9. 为本地帐户创建安全问题。 Windows 10 版本 1803 中的新功能。 仅当用户在上一屏幕中选择创建本地帐户而不是登录到其 MSA 时才显示。 请参阅 OOBE 屏幕详细信息，了解有关 OOBE 中这一新屏幕的详细信息。
10. Windows Hello 设置
11. 链接您的电话和电脑。 仅当用户在前面的屏幕上登录 Microsoft 帐户并连接网络后，才会显示此屏幕。
12. 将文件保存至 OneDrive。 这是云服务页。
13. 设置 Office。 仅当用户连接到网络并提供其 Microsoft 帐户信息后，才会显示此屏幕。 本页中的内容将因用户的帐户类型而异。 例如，如果他们的 Microsoft 帐户有资格免费试用 Office，该页面将鼓励用户设置免费试用。 这是云服务页。
14. 付款信息。 Windows 10 版本 1803 中的新功能。 仅当用户从“设置 Office”屏幕上选择加入 Office 免费试用版时才会显示。 这是云服务页。
15. 使 Cortana 成为我的个人助理
16. 隐私设置。 用户将在此屏幕上看到最多 7 个隐私设置。 并非所有用户都会看到相同的设置。
17. OEM 注册页
18. 获取最新版 Windows。 在 Windows 10 版本 1803 之前，此屏幕名为“电脑正在等待更新”，并在 OOBE 结束时显示。

        对于 Windows 11 OOBE 过程会有很大的变化，其中最为显著的就是会强制用户使用 MSA 或 M365 账号登录（近来有一些用户反馈，可能多发于 OEM 系统）。

        如果企业之前已经在实施标准化的部署技术和流程，那么这个问题可轻松应对，因为通常 IT 会编制 Unattend.xml 来实现本地账号的创建，或加域的动作，同时还会实现 OOBE 自动化，所以并没有什么干扰或影响。

        但那些还在使用非标准化技术来实施的环境，将面临巨大挑战！但如果您所在的组织已经全面使用 M365 账号登录 Windows，那可以就此暂停去干别的事情了，无需再此浪费时间！！！否则你将需要借助 PPKG 来作为一种解决方案。

        PPKG 是一种动态部署方案，相比较 Unattend 那些传统的方法，更灵活更高效，我们只需要将制作好的 PPKG 文件复制到到 U盘，就可以在 OOBE 阶段应用，在 OOBE 屏幕上连续按五次 Win 键，即可激活选项。

        gOxiA 已经事先做好了一个 PPKG，将会自动化 OOBE 直接跳转到登录界面，默认会在系统中创建一个本地账号，想测试体验的朋友可以直接下载下面的文件。但如果你想了解编制的方法可以继续往下阅读。

OOBEforLocalUser.zip

本地账号：Admin

密码：goxia

        打开 ICD，选择“Advanced provisioning”创建 PPKG，在左侧“Runtime settings”配置“Accounts - Users - UserName，Password，UserGroup”，以及“OOBE - Desktop - HideOobe”。最后导出为 PPKG 即可参考前面步骤使用。

HOWTO: 解决 MDT 部署后 Summary Wizard 空白故障

        使用 MDT 创建和部署一套标准安装流程的系统映像，涉及相关的应用软件都是基于 MSI 或支持静默安装的 EXE 文件。每个软件的静默安装参数都是单独经过验证测试的，导入 MDT 进行部署安装。但在实际的部署序列验证中发现整个部署完成后会弹出一个空白的 Wizard.hta 窗体，导致部署无法结束。即使忽略最后的 Summary 也无法跳过 Wizard.hta 这个问题。在早前 gOxiA 曾发布过相同的日志“MDT FinalSummery 发生 Wizard 空白页面问题”，并分享了一些经验，但要彻底解决这个问题还是需要详细测试和验证的。

        参考早前的日志我们已经了解到通常是在应用安装序列中包含了禁用外部驱动器策略的安全软件时才会发生，且仅在 MDT Media 场景下出现。如果当前部署案例中必须要执行这些安全软件安装序列，就必须解决 Wizard 空白的问题。做了大量的测试和验证发现，Wizard 窗体会使用到如下文件：

• "Wizard.hta",
• "Wizard.css",
• "Wizard.ico",
• "ZTIUtility.vbs",
• "WizUtility.vbs",
• "ZTIConfigFile.vbs",
• "ZTIDiskUtility.vbs",
• "ZTIDataAccess.vbs",
• "header-image.png",
• "Computer.png",
• "Summary_Definition_ENU.xml",
• "Summary_Scripts.vbs",
• "plusicon.gif",
• "minusico.gif"

        只要确保这些文件存在，即可解决 Wizard 空白问题。为此我们可以写一个脚本加载到有影响的应用软件安装序列前，将相关的文件拷贝到特定目录下，即可解决问题。例如：

md %localappdata%\temp\deploymentscripts

copy . %localappdata%\temp\deploymentscripts

HOWTO: 使用组策略限制设备安装

        从事 Windows 桌面标准化工作的 IT 朋友应该了解，Windows 在设备支持方面的显著特性就是 PnP - 即插即用，系统驱动程序存储区会保存一些常见的设备驱动，当设备连接到系统后，会自动匹配并安装对应的驱动；如果驱动程序存储区没有对应的驱动，则会通过 Internet 向 Windows Update 发送请求获取设备驱动。所以，当我们向系统安装设备驱动程序时，在底层的动作会有两步，驱动会先自动拷贝至存储区，然后在匹配到当前系统实例上（安装驱动）。

        OSImage 的编制人员通常会使用 DISM 命令将非系统自带的设备所需驱动注入到 Image，当系统执行 Specialized 阶段时会进行驱动匹配和安装；或者在普通用户连接设备时实现驱动安装。对于最终用户，这是非常友好的，因为用户可以在没有帮助的情况下开始使用设备。但是，这也会对 IT 部门带来挑战，他们可能无法支持各种设备，此外公司也可能会通过阻止用户使用 USB 端口来阻止用户连接 USB 设备。

        在 Windows 平台上提供了多个组策略设置，可用于控制设备和设备驱动程序的安装。这使 IT 可以限制特定设备的安装，但允许安装所有其他设备。要学习和使用这些组策略可以打开组策略编辑器并定位到“计算机配置-管理模板-系统-驱动程序安装”：

        其中包含两个配置选项：

• 允许非管理员为这些设备设置类安装驱动程序：允许用户安装指定的设备驱动程序。您可以通过检查伴随设备驱动程序的.inf文件来确定适当的驱动程序设置类。
• 关闭Windows Update设备驱动程序搜索提示：确定管理员在设备安装期间是否收到提示以搜索Windows Update驱动程序。

        要控制设备安装限制的组策略设置，可定位到“计算机配置-管理模板-系统-设备安装-设备安装限制”。

        其中包含：

• 允许管理员覆盖设备安装限制策略：允许管理员组的成员安装或更新设备的驱动程序，而不管策略设置如何。
• 允许使用与这些设备设置类匹配的驱动程序来安装设备：允许安装与指定的设置类全局唯一标识符（GUID）相匹配的设备。
• 使用与这些设备设置类匹配的驱动程序防止安装设备：防止安装与指定的设置类GUID匹配的设备。
• 当策略设置阻止安装时显示自定义消息：允许管理员定义当策略设置阻止设备安装时显示的自定义消息。
• 当策略设置阻止设备安装时显示自定义消息标题：允许管理员定义自定义消息标题，当策略设置阻止设备安装时显示。
• 允许安装匹配任何这些设备标识符的设备：允许安装与您指定的设备标识符匹配的设备。
• 防止安装符合任何这些设备标识符的设备：阻止安装与您指定的设备标识匹配的设备。
• 时间（以秒为单位）在策略更改生效时强制重新启动：允许您定义设备安装后计算机等待重新启动的时间。
• 防止安装可移动设备：允许您阻止用户安装可移动设备。
• 防止其他策略设置未描述的设备安装：允许您确保用户无法安装任何驱动程序，即使没有限制安装的策略。

HOWTO: 解决 FFU 执行 Split 后未生成分卷文件问题

        当我们为 Windows 系统实例生成 FFU Image 后，可能因为容量大小的问题需要对 FFU 执行 Split，例如：要部署的设备使用 UEFI，则 UFlash 必须使用 FAT32 格式，但该格式的分区无法存储超过 4GB 大小的文件，此时的方案要么是将 FFU 单独存储在 NTFS 分区上，或者将映像进行分卷存储。

        FFU 与 WIM 格式虽然有本质上的区别，但也都支持分卷存储，但是 FFU 在执行分卷时则会遇到一个问题（如果我们忽略了 FFU 的基础信息，则这会变成一个 Keng - 坑）！！！继续往下看……

        通常我们会采用默认命令行和参数执行 Capture FFU，但当我们需要使用 /Split-FFU 来拆分 FFU 时会发现执行过程非常块，并且结果反馈已经完成，并没有任何报错，但当去找寻这些拆分后的文件时却发现它们并不存在。

        原来 FFU 的 Split 必须使用未经压缩过的 FFU，而命令行参数会默认使用压缩选项，具体说明如下：

        如此一来，作为映像部署人员，如果需要在未来拆分这些 FFU 文件，则在捕获时必须加上 /Compress:none 参数，但 FFU 的文件容量也将剧增。文末让我们再一次对 FFU 的特性增加深印象：

• 用途：在工厂车间实现最快速的 Windows 捕获和部署。
• 映像样式：基于扇区
• 压缩：模式使用 Xpress-Huffman
• 它捕获什么内容：捕获完整的驱动器信息集，包括分区。
• 应用映像时会发生什么情况：清理整个驱动器。
• 是否可以部署到不同大小的硬盘驱动器：是的，但新驱动器大小必须等于或大于原驱动器大小。
• 是否可以修改映像：是的，通过使用 DISM 可以装载，修改和卸载映像。
• 可靠性：包含目录和哈希表，用于在刷写到设备上之前验证签名。在捕获过程中生成哈希表，并在应用时进行验证。

HOWTO: 解决 WDS PXE-E16 问题

        一台基于 Windows Server 2022 的 WDS 服务器已加入到 AD，并使用 AD 集成模式进行了初始化的配置，跟随向导同时导入了 WinSvr 2022 的 Boot.wim 和 Install.wim，但是在使用 Hyper-V Gen2 VM 执行首次网络引导时是正常的，但是在通过实体机进行 PXE 网络引导时，发生了 PXE-E16 故障；之后再用 VM 测试同样报错。

        从报错信息可见 PXE-E16: No valid offer received. 在 Configuration Manager 中 PXE 启动问题的高级故障排除 | Microsoft Learn 文档中提供了一些排查的思路。尝试创建一个 Gen1 VM 引导发现是可以正常工作的，说明 WDS 服务和发现均没有问题，看来是有其他原因。

        网上曾有文章介绍使用 WDS 的独立模式进行配置，但在本案中并不适合，回过头来分析客户端的特征，并结合 WDS 事件日志做了分析，才恍然大悟。

1. 客户端使用 UEFI 模式启动
2. 查阅 WDS 事件日志，可看到设备已从 PXE 启动，但并未执行后续启动步骤。在日志中可以看到一个重要的提示“客户端体系结构: 4”
   
3. 如果使用 Gen1 VM 执行 PXE 启动，日志中记录其客户端体系结构为1，之后会创建 Non-Shared 缓冲区来读取文件“\boot\x86\wdsnbp.com”，之后当 gOxiA 按下 F12 确认从网络引导后，WDS 又为其过程创建了“\bootx64\pxeboot.n12”，随后 TFTP 获取到 x64 的 Boot.wim 成功引导加载 PE 环境。在 Configuration Manager 中的 PXE 启动 | Microsoft Learn 这篇文档中我们可以获取到很多有用的信息。

        由于 WDS 初始提供 wdsnbp.com 来引导客户端启动，而其特性仅支持 x86 和 x64 BIOS，所以最终导致 Gen2 VM 和实体设备发生引导故障，因为两者均为 UEFI。

        为了确保 UEFI 这类的 Modern PC 能够通过 WDS 提供的 PXE 进行网络引导，我们需要强制 WDS 为客户端提供 UEFI 支持，即使用 Bootmgfw.efi 或 Wdsmgfw.efi，为此我们需要配置 DHCP，添加 067 选项，强制默认使用 UEFI 引导。

        最后再次执行启动验证，Gen2 VM 和 实体机均能够正常通过 PXE 引导。在 WDS 事件日志中，可跟踪到设备初始便会使用 067 指定的 efi 文件加载引导，之后会成功加载 x64uefi 下的 bcd 并顺利完成后续的 Boot.wim 加载任务。

        需要注意，当通过 DHCP 强制支持 UEFI 后，在使用 Gen1 VM 执行 PXE 网络引导，则会发生 PXE-E79 故障。

        如果在企业环境中同时存在 BIOS 和 UEFI 固件类型的设备，IT 管理员可以考虑配置 DHCP 服务器，定义供应商类别（DHCP Vendor Classes），添加 UEFI x86/x64 以及 BIOS x86&x64 的支持。

微软发布边缘计算设备映像生成器的公共预览版

        微软今天在其技术社区发布了一款面向边缘计算设备的映像生成器，以下简称：EDIB，目前是公共预览版。利用该工具设备生成商或OEM，甚至是 IT 人员都可以构建安全和自定义的 Windows IoT Enterprise LTSC 2021 设备映像。

        如果您之前也做过系统定制方面的工作一定深有体会，很多繁琐的配置步骤和测试验证过程会让人感到沮丧。EDIB 提供了引导式的用户体验来定义系统映像，可以轻松的配置 Windows 系统的可选功能、策略、语言和区域设置以及质量更新；针对制造商或OEM还可方便的集成驱动程序、应用程序和OEM支持信息；在设备锁定配置方面，可以与配置用户账户、Shell自定义、全新体验、无品牌启动、键盘筛选器、统一写入筛选器和自定义登录配置。

        下面是 Edge Device Image Builder 的初始界面，我们可以从新建一个项目开始。

        虽然界面和操作流程都很简单，但也有一些先决条件：

• 如果要在虚拟机上运行 Edge Device Image Builder，那主机 PC 必须满足 Hyper-V 嵌套虚拟化的先决条件，有关配置嵌套虚拟化可以参考：https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/user-guide/nested-virtualization#configure-nested-virtualization
• 仅支持 Windows 10 IoT Enterprise LTSC，版本21H2
• Windows ADK 2004
• Windows ADK 2004 PE Add-on
• 按需自定义语言和功能包
• Packer

        看到这里如果您已经心动，打算用它来生成一个单应用的 Kiosk 设备映像，那恐怕要失望了，因为目前还无法通过此工具生成，且没有解决方案。

        更多细节和使用指导建议浏览下面的官方文档，如果已经迫不及待想要一试也可以从下面的链接下载。

下载地址：https://aka.ms/EDIBPublicPreviewRelease

官方文档：https://aka.ms/EDIBDocumentation

HOWTO: 解决 WDS 自动化部署 Windows 时 PE 应答文件无法自动应用系统映像

        在企业 IT 服务台，通常会部署一台 WDS 服务器用于桌面端的系统交付任务。WDS 的优势和特点相信了解的朋友都有了解，内置在 Windows Server 中的一个服务，提供了友好的 UI 管理界面，配置简单除了支持 AD 也可以在工作组环境下运行，除了可用来通过网络安装 Windows 操作系统，还支持 PXE 引导，最为重要的是它还支持全自动化部署的应用场景，并提供了简单的设备驱动管理功能。

        今天，要分享的是在自动化部署场景下，应答文件无法自动应用系统映像的问题。我们知道要实现 WDS 的自动化部署，首先要解决 PE 引导进入 WDS 环境后的登录验证问题，之后才会执行 Windows Setup 过程，在这个 Setup 向导中会允许 IT 人员选择要安装的系统映像，以及目标设备的磁盘准备工作。为此我们需要创建一个应答文件，在“1 windowsPE”阶段添加“amd64_Microsoft-Windows-Setup_neutral”以配置相关的应答设置。

        其中，使用“WindowsDeploymentServices”来指定验证登录到 WDS 的账户信息（Login），并通过“ImageSeclection”指定要安装哪个系统映像（InstallImage），以及要安装到哪个磁盘的分区（InstallTo）。

        考虑到设备要重建系统分区和格式化，所以我们还应该添加“DiskConfiguration”对硬盘进行自动化配置，本例为 UEFI 设备创建了三个必要分区：EFI、MSR、Primary

        到这里我们可以在 WDS 中加载这个应答文件，并做一下测试。WDS 为 PE Boot 加载 Unattend 的过程很简单，打开 WDS 控制台，进入其属性，找到客户端选项卡，勾选“启用无人参与安装”，为“x64 UEFI 体系结构”指定我们刚才创建的应答文件即可。

        在实际测试中注意到部署过程并未自动化去安装预先配置的系统映像，我们复查一下应答文件，重点检查“ImageSelection”下的“InstallImage”，如下图所示：

        我们可以很轻松的确认 ImageGroup和 ImageName，并没有什么不妥，那么 Filename 是应该填写完整的 UNC 路径还是仅填写 WIM 文件名呢？！其实这里只需要填写 WIM 文件名即可，但需要注意的是导入的 Install.wim 通常包含多个 SKU，在添加到 WDS 后会为每个 SKU 生成一个 WIM 文件，我们需要在映像属性中确认这个文件名。

        可是确认了 Filename 后为什么还是不能自动应用系统映像？！且没有任何报错呢？！我们再来回顾一下 WDS 部署系统时的过程，引导进入 WDS Client Setup 环境后首先会要求我们配置语言，OK！这就是重点，还记得我们前面编制的应答文件并没有包含语言设置部分，但测试时也确实略过的语言选项，但由于缺失这部分就会导致应答文件无法完全匹配。现在，我们重新编辑应答文件，在 PE 阶段添加“amd64_Microsoft-Windows-International-Core-WinPE_neutral”，如果当前导入到 WDS 里的 PE Boot image 是中文版的，则将相关的语言配置为 zh-cn 即可，其中 InputLocale 的中文对应的是 0804:00000804。

        现在，重新执行 WDS 部署，可以看到问题得到解决。

MDT FinalSummery 发生 Wizard 空白页面问题

        动态部署和现代部署大行其道，传统部署貌似正逐渐没落，好久没有分享 MDT 相关的内容，今天就最近遇到的一个问题做一下经验分享。在执行 MDT Media 部署时 FinalSummery 发生异常，Wizard.hta 页面出现空白内容，导致无法看到部署结果摘要。具体现象如下图所示：

        从图中可以看到 Wizard.hta 是一个空白页面，如果进行测试会发现它并不会影响后续的任务序列，例如我们添加一个 FinishAction 是不会受到这个问题影响的，当初 gOxiA 打算通过 SkipFinalSummary 略过这个页面，但发现事与愿违。进一步排查，注意到在实际路径中并未发现这个文件，说明 Wizard.hta 未能成功生成或拷贝到指定的目录中。

        检查了 CustomSettings、任务序列，以及应答文件，还做了可疑的测试也都未能完全验证，对于相关日志也是看了又看进行了多例对比，也没发现什么线索，期间当然也用上了 YYDS 的 Bing Search，无济于事……

        在测试中，由于要快速测试获得结果页面，精简了 Install Applications，测试中竟然没有再出现 Wizard 空白页面的问题。反复验证确认 Apps 中因为包含安全软件，而默认加载了禁用外部驱动器的策略，导致在安全软件安装完毕后，外部驱动器被直接禁掉，导致无法正常读取 MDT Media 数据，至此真相大白……

        虽然谜底揭开，但目前也没有更好的 Workaround 以规避这个问题，或者可以考虑使用 LiteTouch OEM Task Sequence 模板。

        最后针对此类问题做一下总结分享：

• 排查应用，避免影响访问数据源的应用
• 确保 Domain Join 正常
• 确保 网卡驱动 正常加载

HOWTO: 解决 USMT 迁移应用时发生 EdgeMigrationPlugin 失败问题

        基于 Chromium 内核的 Microsoft Edge 浏览器已内置于较新的 Windows 系统中，微软对于早期版本的 Windows 在后续的 KB 补丁中也都集成了新版 Edge，这无疑方便了 IT人员和最终用户。但在 Windows 10 21H2 上进行 USMT 迁移时却遇到了与 Edge 有关的问题，具体如下图所示，在应用 USMT 迁移时发生错误，导致部署失败。查阅 Setuperr.log 发生了载入 Session 失败的问题，原因是未找到文件，再往下看应该与 Edge 有关，“Microsoft-Edge-Migration-PluginEdgeMigrationPlugin.dll”访问被拒绝，回忆执行 Capture 阶段并未发生错误！疑似在 Apply SPP 时此文件被占用导致发生错误。

        由于相关的文档内容太少，目前获取到的解决方案是在捕获时将“Microsoft-Edge-Migration-Plugin”排除在外。为此需要修改 Config_AppsAndSettings.xml 文件，添加“Microsoft-Edge-Migration-Plugin”例外，如下所示。

        利用此方法我们可以排除那些会导致应用 USMT 失败的组件，至于本案中涉及的组件失败的具体原因恐怕只有微软方面能解了。

M365 Apps for enterprise 预安装要点

        当企业 IT 需要将 Microsoft 365 Apps（以下简称 Office365）作为标准化映像的一部分，就需要进行预安装。很多 IT 都会产生疑问，对于 Click-to-Run 模式的 Office 该如何进行预安装呢？今天 gOxiA 将快速与大家分享其中的一个要点。

        首先我们先回顾一下 Office365 的安装方式，OEM 设备通常会预装 Office365，其运行模式为 Click-to-Run，对于 OEM 如果要在设备预装系统中集成 Office365 则需要使用 OPK，该工具包需要微软授权。另一种方式，是用户访问 Office365 网站下载 Setup.exe 在线安装，其运行模式同样为 Click-to-Run。对于企业，会由 IT 人员通过 ODT（Office Deployment Tool）下载 Office365 安装源，然后生成安装配置文件，格式为 XML，然后使用 ODT 为设备端安装，其运行模式同样为 Click-to-Run。

        回到正题！

1. Office365 支持作为操作系统映像的一部分。

2. 需要通过 ODT 进行安装，不支持从 Office365 门户下载 Setup.exe 工具进行安装。

3. 需要事先通过 ODT 将安装源下载到本地进行安装。

4. 为防止安装期间尝试自动激活，需要修改 Office365 的安装配置文件，确保如下设置。

5. 可以静默安装

6. Office365 安装完毕后请勿打开任何 Office 程序（PS：一旦打开会安装临时密钥），可以使用如下命令检测密钥。

7. 请勿保存测试计算机的映像。

WDS 变更部署支持

        在 Windows 11 发布后，微软也公布了 Windows 部署服务（WDS）的最新支持说明 - https://docs.microsoft.com/zh-cn/windows/deployment/wds-boot-support ，大致意思是通过 WDS 的 PXE 加载 Windows 11 的 Boot.wim 来实施 Windows Setup 时，该方案将不再受支持。 如下图所示，进入 PE 环境后会有一个否决通知，且无法跳过，只能重启动。（PS：通过测试在此界面下仍能调出 CMD）

        在说明文档中提给出了详细的受影响的部署方案，说实话看了半天也没完全理解，尤其是在做过实验之后。

        gOxiA 的实验是这样的，以 VM 方式安装了一台 Windows Server 2022，然后分别导入了 Win 10、11 和 2022 的 Boot.wim，然后又分别导入了它们的 Install.wim，执行部署测试。

        如果选择 Windows 11 的 Boot.wim 启动，会出现文章前面提到的的“否决通知”；选择 Windows 10 的 Boot.wim 启动，则如以往一样正常安装映像。

        但选择 Windows Server 2022 的 Boot.wim 启动虽然也会显示“否决通知”，但仍可以通过点击“下一页”跳过，并正常安装映像。

        从目前的测试看，限制仅仅是 Boot.wim 中的 Setup 程序会检测是否基于 WDS PXE 启动，并给出对应的“否则通知”，还并没有基于 WDS 本身进行限制，还允许一段时间的过渡期。但从另一篇文档（Windows Server 2022 已删除或不再开发的功能）中可以了解到，WDS 的操作系统部署功能将逐渐弃用，并建议企业 IT 桌面交付部门尽快使用 Configuration Manager 或 MDT 进行桌面系统的交付。

使用 Provisioning Packages 帮助企业 IT 人员快速交付 Windows 10 设备

        在前段时间 gOxiA 分享了一篇文章 - “虚拟环境下在 Windows 10 OOBE 阶段测试部署 PPKG”，详细介绍了如何在虚拟机环境下 OOBE 阶段测试 PPKG 的方法。并且还分享了一些重点知识。今天我们将介绍使用 Provisioning Packages（预配包）帮助企业 IT 人员快速交付 Windows 设备。

        在过去的传统部署方案中，企业IT通常会根据组织的需求和规则策略重新定制标准化系统映像，在新设备到来后首先会进入 IT 桌面部门，通常会在 IT 服务台使用 WDS、MDT 或 SCCM OSD 等方案，重新为设备部署 Windows 操作系统。并且 IT 桌面部门还需要根据其他诸如业务或安全部门不断提出的新需求或变更重新生成映像。可以想象这是一件非常庞大且复杂的项目工作。

        自 Windows 10 发布以来，提出了 WaaS – Windows 即服务的概念，随之为这一“现代桌面”提供了一系列的“现代部署”方案可满足不同场景的需求。在这些方案中，IT 人员可以利用“动态部署方案”轻松便捷地为企业交付新的 Windows 10 设备。

        假设我们有一个场景，企业订购了一批新的 Surface 设备，其预装了 Windows 10 的专业版，随机搭载了 Office 应用程序，并且设备驱动也是内置的，由于随机系统非常干净，而且是最佳的运行状态，企业希望基于现有的系统进行定制和交付，由于 OEM 系统不支持映像的重新定制和生成，按照过去传统的做法企业IT桌面人员需要使用批量授权重新为 Surface 生成定制的企业标准化映像，这一过程所付出的工作量是相当繁重的，而且企业可能会重复使用专业版的授权。最后，企业IT桌面部门还需要不基于网络的部署。

        在以上这种场景下，如何选择一种快速高效的部署方法呢？！

        综合比较动态部署方案中的 Provisioning Packages（预配包）更容易满足这一部署场景的需求。利用预配包我们可以快速配置新的设备，而无需完成准备和安装新映像的过程；生成的预配包可以配置多个设备来节省时间；在准备和部署过程中不需要设备管理基础架构；预配包可以应用在没有网络连接的设备上。由于预配包是一个扩展名为 PPKG 的文件，我们可以多种形式进行预配包的分发，如：可移动磁盘，电子邮件，网络共享等。部署方式也随之灵活许多，除了可以双击预配包手动安装，也可以利用命令行编写脚本，尤为重要的是在 Windows 10 的 OOBE 阶段也可以应用预配包，这样一来我们就可以实现自动化的部署交付过程。

        到这里，您可能希望知道预配包都能为我们做些什么？是否可以像以往的部署方案那样利用 Unattend 实现无应答安装和配置，加载一系列的脚本程序进行高级的自动化配置……等等？！

        Provisioning Packages 为我们提供了丰富的预配设置选项，可以分配设备名称、输入产品密钥以升级 Windows，删除预安装的软件，连接到 WiFi，加入到 AD 或侦测到 AAD，当然也可以创建本地账号，还可以添加应用程序、证书……更多具体的细节可以参考微软官方文档。https://docs.microsoft.com/en-us/windows/configuration/wcd/wcd

        那么我们如何生成预配包（Provisioning Packages - PPKG）呢？如果您是一位经验丰富的桌面标准化 IT 人员，应该知道 Windows ADK，其中的“配置设计器”（Windows Configuration Designer - ICD）便是 PPKG 的生成工具。我们也可以在“Microsoft Store”中安装它“Windows Configuration Designer”。

        打开 ICD，默认会提供几个预配模板，如果是新手可以先从“预配桌面设备”开始，它提供了向导式的配置过程，可满足基本需求。通常 gOxiA 会使用“高级预配”来创建 PPKG 以满足不同的需求。

        在“高级预配”模式下，通过左边提供的配置项来进行预配设置，如果您所需的需求未能满足，则需要考虑配合其他方法，如：命令行、脚本……或基于 AD 的组策略进行后续的配置管理。当预配包设计完毕后，就可以利用导出功能生成 PPKG 文件，在生成过程中我们可以为预配包起一个便于识别的名称，版本号会根据每次生成递增，利用“所有者”和“等级”我们可以为当前预配包设置优先级别。

        创建好的PPKG就可以按照前文介绍的那样以不同形式分发给用户，或在 OOBE 阶段应用。 ]]> https://goxia.maytide.net/read.php/1944.htm gOxiA <sufan_cn@msn.com> Fri, 17 May 2019 03:24:39 +0000 https://goxia.maytide.net/read.php/1944.htm

HOWTO: 使用 USMT 捕获指定的用户注册表数据

        USMT (User State Migration Tool)，即用户状态迁移工具，其历史悠久且一直免费，可帮助企业 IT 人员在大型的 Windows 部署场景下简化用户数据的迁移过程。USMT 能够从现有系统环境下捕获用户账户、用户文件、操作系统设置和应用程序设置，然后将其迁移到新的 Windows 系统中。

        如果您是第一次听说 USMT，是不是很心动？！希望尽快了解并上手操作，但可惜的是可能会令看官失望了，因为今天的分享恐怕仅适用于已经入门的 USMT 用户。

        是这样，前段时间有位网友向 gOxiA 咨询了 USMT 相关的使用问题，说在手工创建自定义的捕获配置文件后，无法正常迁移数据，遇到 0x0803wa 警告，具体内容是：Registry location HKCU\Software\Microsoft\Internet Explorer\Main [Search Page] is considered invalid in the current context. 如下图所示：

        大致的意思就是注册表位置在当前的上下文是无效的，排除了注册表路径问题，那问题应当就出在自定义的捕获配置文件（.xml）上。下面 gOxiA 提供了正确的文件内容截图。

        在 component 字段，由于没有强制指定上下文，所以其默认为 UserandSystem，所以我们需要在 rules 中强制为 Uesr 上下文，这样才能捕获到我们当前指定的注册表数据。

        另外一个不能忽视的问题，由于当前捕获的数据是隶属 Internet Explorer，其默认属于系统设置，所以我们需要先使用 genconfig 参数生成可选的 config.xml 文件，然后将默认要迁移的系统设置都改为 “no”，这样在捕获的时候即可不迁移系统设置，且仅按照指定的捕获配置文件进行迁移。

scanstate /vsc /o /config:config.xml /i:ie_searchpage.xml /ue:*\* /ui:domain\sufan /v:13 /l:scanstate.log w:\usmtdata

        这样就仅迁移出来了指定用户的指定数据，捕获出来的数据包将会非常小。当需要迁移到用户的新环境下，则可以参考如下命令行。

loadstate /i:ie_searchpage.xml /ue:*\* /ui:domainsufan /l:loadstate.log w:\usmtdata

Microsoft Assessment and Planning Toolkit - 收集数据

        在上个月 gOxiA 与大家分享了两篇 Microsoft Assessment and Planning Toolkit（以下简称：MAP）的日志，如需回顾可点击下面的日志链接。

• Microsoft Assessment and Planning Toolkit - 概览
• Microsoft Assessment and Planning Toolkit - 安装

        整体来说 MAP 的安装和使用还是非常简便的，并没有太多的需求，也不需要复杂的配置过程，对于 IT 专业人员能够很快上手。今天 gOxiA 将介绍如何使用 MAP 收集数据。在 MAP 安装完毕后，可以从程序组中找到并打开它，在首次启动 MAP 时会自动弹出数据库创建选项，由于 MAP 默认安装了 LocalDB 支持，所以 Data source 为 LocalDB，只需在 Create an inventory database 下的 Name 文本框输入数据库名称即可。

数据库创建完毕后，会进入 MAP 程序界面，在 Overview 可以通过 Perform an inventory 启动数据收集向导。

        在 Inventory Scenarios 选项中，选择 Windows computers，此方案将使用 WMI 来收集硬件、设备和软件等信息，以帮助 IT 人员进行分析和评估，是常用的收集方案。

        在 Discovery Methods 选项中，可以通过 ADDS（Use ActiveDirectory Domain Services） 或 IP 地址范围（Scan an IP address range）来探索目标，当然还提供了其他的选项，本例中将使用 IP 地址范围进行目标的探索和收集。

在 Scan an IP Address Range 选项下，我们可以添加多个 IP 地址段。

      因为前面我们选择了 Windows Computers 的收集方案，所以在 All Computers Credentials 选项下需要创建可 WMI 远端计算机的用户账号，为了方便起见在这里可以输入域管理员的账号信息，对于权限细化的 IT 环境可能会需要添加多个访问账号。在后续的 Credentials Order 选项中可以调整账号的使用顺序，否则可快速略过。

        当我们完成上述的配置后，数据收集任务便开始自动执行，等待的时间并不长，很快收集工作便会结束。（PS：MAP 数据收集不依赖独立的客户端代理，但仍能在很短的时间内完成收集工作！）

        数据完成收集后，我们便可以在不同的评估场景下看到分析数据，例如在 Desktop 下可以看到 Windows 10 Readiness 和 Office 2016 Readiness 等常见的评估方案概览数据。

        点击每个方案便可进入其详细页，可以使用 Options 下的 Generate Windows 10 Readiness Report 生成更为详尽的表格文件。

        以 Office 2016 Readiness 为例，我们可以从详细信息中了解到当前有1台设备无法满足 Office 2016 的需求，为此我们可以生成报表查看详情。

        打开 Office 2016 Readiness 的报表（PS：生成的报表通常位于用户文档目录下的MAP目录，按照数据库名称命名子文件夹。）在 Office2016Assessment 工作表中可以筛选出 Not Office 2016 Ready 的计算机，在 Reasons for Recommendation 下记录了原因，在本示例中为满足 Office 2016 需求的设备是因为操作系统未受支持导致的，因为这计算机的当前系统是 Windows XP Pro w/SP3。

        MAP 虽然是免费的，但它的潜在价值非常大，如果能在合适的场景下应用，必定事半功倍！！！

Microsoft Assessment and Planning Toolkit - 安装

        上一篇文章《Microsoft Assessment and Planning Toolkit - 概览》我们对 MAP Toolkit 有了简要的认识，今天将要学习如何安装 MAP Toolkit。

        获取 MAP Toolkit，建议从微软官方网站获取最新版本。

https://www.microsoft.com/en-us/download/details.aspx?id=7826

        MAP Toolkit 支持以下操作系统：

• Windows 10
• Windows 8/8.1
• Windows 7 SP1
• Windows Server 2008 R2 SP1
• Windows Server 2012/R2
• Windows Server 2016

注：操作系统需安装 .NET Framework 4.5；如果使用 SQL 实例，应使用"SQL_Latin1_General_CP1_CI_AS"排序。

        MAP Toolkit 硬件需满足以下最低需求：

• 双核 1.5GHz 处理器
• 2.0 GB 内存
• 1 GB 硬盘空间
• 网卡
• 1024*768 分辨率

        准备就绪后我们便可以开始安装，本例选择使用 MAP Toolkit 自带的 LocalDB 数据库，这样可以更快地安装 MAP，且无需 SQL Server，当然使用 LocalDB 将仅支持 10GB 以内的数据量。

        整个安装过程非常简单，跟随向导一路“下一步”即可。

Microsoft Assessment and Planning Toolkit - 概览

        当我们的 IT 部门决定要为企业 PC 升级他们的操作系统时，就会面临很大的挑战，除了要确保现有 PC 的硬件能够满足新操作系统的需求外，还要识别出现有应用程序是否能够运行在新操作系统之上，以及为新操作系统提供新应用程序的必要性。所以，在部署新操作系统之前，应当仔细评估和规划应用程序和硬件与新操作系统的兼容性。微软为用户提供了一款免费的工具 - Microsoft Assessment and Planning Tookit（微软评估和规划工具包），以下简称 MAP。

        MAP 顾名思义即一种用于评估和生成报告的工具，以帮助企业 IT 人员评估当前的 IT 基础架构，规划未来的系统和应用升级工作。MAP 使用 Windows 管理规范（WMI），以及活动目录服务（ADDS）和其他技术来收集企业环境中的数据，而无需在目标计算机上安装任何代理客户端软件，所以我们可以安全、快速地评估各种平台迁移的 IT 环境：

• Windows 10, Windows 8.1, Windows 7
• Office 2013, 2016 和 Office 365
• Windows Server 2012, 2012R2 和 2016
• SQL Server 2014 和 2016
• Hyper-V
• Microsoft Private Cloud Fast Track
• Azure

        在为企业实施 Windows 10 升级时，可以使用 MAP 扫描和评估当前 PC 的就绪情况，并生成我们所需的 Word 或 Excel 格式的报告。

        微软为使用 MAP 制定了六个关键阶段，以帮助我们能够正确有效地使用 MAP。

第1阶段：选择您的目标

第2阶段：收集您的数据收集需求

第3阶段：准备您的环境

第4阶段：安装 MAP Toolkit

第5阶段：收集数据

第6阶段：审查报告

        有关上述6个阶段的详细信息建议参考微软官方文档：

https://social.technet.microsoft.com/wiki/contents/articles/17804.how-to-use-the-map-toolkit.aspx

        在第1阶段，我们可以收集和评估哪些清单数据？！微软在 WiKi 中也给出了详细的说明资料：

https://social.technet.microsoft.com/wiki/contents/articles/17806.choose-your-map-toolkit-goal.aspx

        如果您正打算收集企业中 IE 部署的情况，或者了解现有硬件是否可以运行 Windows 10 或者 Office 2016/365，都可以借助 MAP Toolkit 来收集清单并进行有效性评估，其自动生成的报告极大地简化了我们的数据收集和分析的工作，减少了投入的精力和成本。

        在后续的文章 gOxiA 将与大家分享 MAP 的安装和使用经验！

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 驱动的问题

        一台基于 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，并将驱动集成到映像中，操作过程中使用到的命令行参考如下：

1. Dism /mount-image /imagefile:d:\goldimages\customizeos.wim /index:1 /mountdir:c:\mount\windows
2. Dism /image:c:\mount\windows /add-driver /driver:d:\drivers\realtek /recurse
3. Dism /unmount-image /mountdir:c:\mount\windows /commit

        若要使用命令行对 WDS 已经添加的安装映像可使用 wdsutil /replace-image命令，参考命令行：

1. 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

        中国当地时间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 配合脚本批量删除驱动程序

        利用 DISM 或 Pnputil 我们已经能够实现脱机或在线模式批量安装硬件的驱动程序，那么如何能够实现批量卸载已经集成到映像中的驱动程序呢？！

        假设我们的映像编制人员为 Surface 设备创建了定制化的系统映像，并集成了 Surface 的设备驱动程序，现在我们希望编制好的映像可以作为通用映像部署在其他计算机上，这时我们就需要清理已经集成在映像内的驱动程序。

        要卸载映像内集成的第三方驱动程序，我们首先需要列表出来它们，所以为此我们执行如下命令行。

        利用上述的参考命令我们可以检索到当前映像中已经安装的硬件驱动程序，其中“已发布的名称：oemX.inf”是我们需要记录的数据。接下来使用下例命令行就可以从映像中卸载驱动。

        我们有了用于检索的关键词，就可以使用“find”来获得准确的驱动列表，可创建变量以生成动态驱动列表，便可以实现动态批量卸载驱动，参考脚本如下：

        以上脚本可以从 gOxiA 的 Github 获取。https://github.com/goxia/ITSM/blob/master/remove_driver.bat

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 类型的计算机。

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

解决因超大内存导致的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. 不同机型使用同一个映像和应答，附加专为企业定制的配置工具，在配置过程中识别机型，并执行相关配置和维护脚本。

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 自动添加配置无线网络

        由于 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（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驱动库推翻重来。

微软发布 Microsoft Deployment Toolkit 8450

        今天微软通过 Microsoft Download Center 发布了 Microsoft Deployment Toolkit 的最新版本 MDT 8450，本次更新支持最新版的 Windows Assessment and Deployment Kit（ADK）以及 Windows 10，即 1709（10.1.16299.15）,同时也支持 Configuration Manager v1710，整体改进了 Windows 10 的部署和升级。

        在 Microsoft Deployment Toolkit Team Blog 上也发布了 MDT 8450 的修订说明。质量改进方面解决了不少已知的 Bug，具体的界面和功能体验还有待测试。

• Quality updates (titles of bug fixes)
• Win10 Sideloaded App dependencies and license not installed
• CaptureOnly task sequence doesn't allow capturing an image
• Error received when starting an MDT task sequence: Invalid DeploymentType value "" specified. The deployment will not proceed
• ZTIMoveStateStore looks for the state store folder in the wrong location causing it to fail to move it
• xml contains a simple typo that caused undesirable behavior
• Install Roles & Features doesn't work for Windows Server 2016 IIS Management Console feature
• Browsing for OS images in the upgrade task sequence does not work when using folders
• MDT tool improperly provisions the TPM into a Reduced Functionality State (see KB 4018657 for more information)
• Updates to ZTIGather chassis type detection logic
• Upgrade OS step leaves behind SetupComplete.cmd, breaking future deployments
• Includes updated Configuration Manager task sequence binaries

        相对于近期呼声较高的现代化 IT 交付技术 - Windows AutoPilot，不少用户产生了疑虑，MDT 是否会被终结？！而这次 MDT 8450 的发布说明中给出了解答，MDT 团队明确了会对这个免费部署工具的持续交付。

        MDT 8450 支持在现有 MDT 上进行升级，一路覆盖安装，在过程中使会通过对比文件 Hash 进行替换，而一些被修改过的文件和必要文件会自动执行备份，之后打开 MDT 管理器会要求对部署节点进行升级，如果一切顺利，最后可以再对部署点执行 Update，重新生成 Litetouch Boot 去替换 WDS 已经导入的 Boot WIM。

        根据目前初步的测试，MDT 8450 仍旧支持 Windows 7 的部署，所以适合广大的企业IT环境。但是对于国内这种多分区，或固态+机械硬盘且多分区的复杂环境，默认支持或称为流程，还是存在一些问题的，存在差异理论这是问题的根源！

HOWTO: 获取已安装的 Windows Update 列表

        在进行桌面标准化的系统更新补丁阶段，需要对客户端从 Windows Update 或内部 WSUS 安装补丁的相关数据进行整理汇总，便于后续的测试和评估，以确保生成适用于当前企业IT环境的系统版本，打造出卓越的黄金映像。既然要进行整理汇总，就需要将更新的补丁列表导出至文件，但是在“查看更新历史记录”和“已安装更新”中都没有提供导出视图列表的功能。

        还好通过 Windows 命令行能够实现，在 PowerShell 下提供了 Get-Hotfix 能够列出当前系统已经安装的更新补丁，如果列表的数据并非我们所需要的那样，可以通过参数自己指定要收集的信息。

        例如，gOxiA 需要收集更新补丁的安装时间、当前计算机名、更新补丁KB号、更新补丁类型，以及更新补丁的说明网址，那么可以使用 PowerShell 命令行“Get-Hotfix |select-object installedon,csname,hotfixid,description,caption”，之后在利用管道通过 Export-csv 输出为 CSV 格式文档。

        此外，我们也可以使用 WMIC 提供的 qfe 命令参数进行处理，命令行非常简单"wmic qfe list /format:csv > c:\WAU_List.csv"，相比较起来 Get-Hotfix 更灵活，但是 WMIC 便捷性更强些。

        导出后的 CSV 可以利用 Excel 2016 内置的 PowerBI 功能通过查询方式从 CSV 中提取数据进行分析和列表的完善。

备忘专用，以后没有大的变更，将仅更新这篇日志。

Windows Server, version 1709

Windows Server 2016

Windows 10, version 1709

Windows 10

Windows Server 2012 R2 and Windows 8.1

Windows Server 2012 and Windows 8

Windows 7 and Windows Server 2008 R2

Windows Vista and Windows Server 2008

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: 为 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文件。

HOWTO: 解决 Windows DISM error ID3 0x80070003 故障

        DISM error ID3 的故障描述，自定义的 Windows 7 标准化系统映像测试正常，封装后在测试环境中部署时发现在 offline mode 下使用 DISM 对系统进行管理时操作失败，如下图所示 DISM 未能找到有效的 Windows 目录，但是当前系统路径确实是有效的，本以为是封装前的系统出现了异常，也反复进行了原始映像的测试，并对当前系统进行了检查并未发现有什么可疑的地方，无奈只能重点排查 DISM 日志！

        在对 dism.log 文件进行了分析后，发现了详细的报错信息，DISM 在对脱机映像执行操作时发生了错误，“DISM OS Provider: PID=1420 Failed to mount the remote registry...(hr:0x80070003)”！复查系统映像创建中的配置修改以及后续部署时无人应答文件的设置，可算找到了线索在应答文件中对用户配置文件进行了重定向，该设置会将 Users 目录移动到其他分区，这就导致“All Users” 和“Default”目录也被移动，而 Default 目录包含默认的注册表数据文件（NTUSER.DAT），当 DISM 对脱机映像管理时会去 Mount 这个注册表数据文件，所以最终导致操作失败。

        而要解决这个问题的办法还是相当简单的，就是在系统所在分区创建一个相同的目录结构（C:\Users\Default\）, 并将 Windows 安装源（Install.wim）中的 NTUSER.DAT 文件拷贝过去即可。在微软官方的知识库（KB2293874）中确认了这是一个已知的问题。

        随后 gOxiA 在 Windows 10 上也重现了这个故障问题，dism.log 中记录的错误提示稍有区别，但意思完全相同，所以解决方法一致。为什么时隔7年这个问题仍旧没有解决，恐怕也只有产品组的人员知道！不过也完全可以理解，在企业环境中要重定向用户配置文件目录通常会使用组策略进行设置，此法不会移动系统级的目录；而直接通过应答文件的做法恐怕也是极为罕见的场景需求。