微软 WSL 容器发布预览版
微软 WSL 容器发布预览版
微软在 Build 2025 大会上宣布开源 WSL 后，紧接着在今年 Build 大会上又公布 WSL 将提供容器功能。就在今天发布的 WSL 2.9.3 Pre-Release 正式提供了 WSL Containers（WSLC）预览版。通过 WSLC 为 WSL 带来了原生 Linux 容器支持，现在我们仅需要使用 WSLC 命令即可轻松运行起来一个 容器，并可对容器进行管理。WSLC 基于 WSL 构建，能够将容器连接到多个网络，并提供了丰富的网络支持；而且支持 GPU 的容器，方便了广大的开发者，API 相关资料可参考 WSL container API developer reference | WSL Dev。
WSLC 不仅提供了 CLI 使我们能够轻松地在 Windows 上创建、运行和管理容器；而且还提供了 API 允许设计开发更多的应用场景，满足了企业和开发者的需求。WSLC 的安装非常简单，如果之前已经安装过 WSL，现在只需要执行 wsl --update --pre-release 即可升级到刚发布的预览版 WSL 2.9.3 Pre-Release。无需重启电脑，即可开始使用 WSLC 命令处理容器事务。
虽然通过命令行可以执行升级，但升级过程目前主要还是依赖 MSI 安装包，所以会有个提权安装的提示，允许即可。
当然你也可以直接通过 WSL 发布到 Github 上的官方仓库获取安装包及发布说明。WSL | Github
WSLC 安装结束后，可以执行 “wslc run -it --rm -d -p 8080:80 --name web nginx” 快速启动一个 Nginx Web 服务器。想要更炫的测试效果，则可以执行下面的命令行启动一个在 Web 中运行的 Linux，这比之前 gOxiA 跑 macOS 感觉要容易太多了，而且运行的效果还真的不错。
参考 WSLC --help 帮助，我们可以快速学会如何管理容器。
WSL 以及 WSLC 满足企业环境的需求，除了可以借助 MDE 进行环境保护，IT 管理员还可以借助提供的 ADMX 对其进行策略管理。如果组织当前在使用 Intune，我们可以将 WSL 官方提供的 ADMX 相关文件导入到 Intune 即可执行配置策略。WSL 的 ADMX 可从以下地址下载。
https://github.com/microsoft/WSL/blob/70cf77fa39b1f5bd0b74a5772d24512d668c2878/intune/WSL.admx
关于 WSL Container（WSL 容器 - WSLC）的更多细节可参考：WSL container | Microsoft Learn
由于不是 Dokcer 的重度用户，现在可以卸载 Docker Desktop 改用 WSLC，即方便又好用！
Windows 11 26H2 准备就绪
Windows 11 26H2 准备就绪
近几年 Windows 的版本迭代更新相比较过去要轻松顺利很多，失败率和工作复杂度明显下降，效率大幅提升，IT 人员的工作压力显然轻松了不少！对于今年的重要版本更新 - Windows 11 26H2，延续了之前的更新机制，将作为 eKB 方式发布，启用包的大小仅几百 KB，使版本更新相当轻松，而且对最终用户的干扰也最小。这些得益于改进的平台和服务方式，对于 Windows 11 26H2，采用了与每年下半年发布的最新版本相同的共享服务模式，无需完整的操作系统替代升级方案，只需要小型启用包即可获得新的功能更新。像已经部署了 24H2、25H2 的组织因为使用同一个服务支持，即同一个源代码库；同样的安全和质量更新；同样的兼容性验证。他们都将实现快速的版本迭代，不同版本的却别仅仅在于启用了哪些功能。
需要注意的是运行 26H1 的设备无法更新到 26H2，因为 26H1 基于同步的 Windows 核心，但微软会提供其他升级方案使其更新到未来的 Windows 版本。（推荐阅读：ITPro 应该了解的 Windows 11 26H1 信息）
Windows 11 26H2 预计于今年10月正式发布，但 Windows Insider 成员已经可以获取到发布预览版本，待正式发布后用户能够通过 Windows Update、Microsoft Intune、WSUS 多个渠道获取 26H2 更新。对于最佳实践，组织 IT 应该可以进行小范围的推送测试，并在正式发布之后逐步扩展到所有设备。
Windows 11 26H2 的支持声明周期遵循以往的规则，家庭版、专业版等继续保持 24 个月的支持周期；而企业版、教育版等支持 36 个月。
Windows Insider 用户在更新到 26300.8697 正式进入到 26H2 分支。
HOWTO: 解决无法正常显示自定义文件夹图标或本地化文件夹名称问题
HOWTO: 解决无法正常显示自定义文件夹图标或名称问题
为了更清晰的管理我们的文件夹，使其更容易被识别，通常会通过自定义文件夹（Desktop.ini）图标的方式对其个性化显示，或者为其设定本地化的目录名称，比如当前目录命名为“AIPrompt”，在中文环境下会自动显示为“AI提示词”。
但近期可能会遇到无法正常显示这些自定义文件夹图标或名称的问题，如果当前系统安装了2026年6月10日发布的 Windows 安全更新，则可能会遇到此类的现象。
- 不再显示由 desktop.ini 定义的图标
- 不再显示由 desktop.ini 定义的本地化文件夹显示名称，只会显示其原始名称
经确认这是一个预期的行为，新的 Windows 更新强化了对 desktop.ini 引入处理的机制，当 Windows 无法确定 desktop.ini 文件源是否受信任时，Windows 则会忽略该文件，并将其视为不存在。这个机制其实早就存在，只是本次更新包含了 Desktop.ini 文件，当我们从以下位置获取到文件时将会视为不受信任的源。
- 从带有 Web 标记（MOTW - Mark of the Web）的 Internet 位置下载
- 从某些远程位置，如：WebDAV 或 基于 HTTP 的位置复制时
- 文件未分类为 Intranet 或区域策略信任的网络路径
本次安全更新仅会影响自定义文件夹的图标和本地化名称，不会影响对文件夹或其文件的访问权限。对于本次更新建议组织用户将内部的路径添加到受信任的站点。
如果组织在使用 GPO 管理客户端配置，可从“计算机配置 - 管理模板 - Windows 组件 - 文件资源管理器”中找到并启用“允许使用文件快捷方式图表中的远程路径”设置。
如果是 Intune 可以从新建策略的设置目录中搜索“Allow the use of remote paths in file shortcut icons” 进行配置。其对应的 CSP 是：
./Device/Vendor/MSFT/Policy/Config/ADMX_WindowsExplorer/EnableShellShortcutIconRemotePath
对于临时的非规模化标准化的处理的方式可以检查 desktop.ini 是否属于不受信任的源，并删除其标记即可。要检查文件相关信息可以使用 Get-Item 并加载 -stream 参数。
如果文件信息中包含 Zone.Identifier 则表示文件包含标签信息。可以使用 Get-Content 加 -stream zone.identifier 参数获取该信息的详细值。
具体可参考下方图片中的示例。
对于 Zone.Identifier 的值分别表示：
- 0：本地计算机
- 1：内网
- 2：受信任站点
- 3：互联网
- 4：受限站点
