VBScript 弃用计划
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 进行脱机分发
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 做准备
为企业部署 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 的消息，有机会要试试到时与大家分享。
