HOWTO: 使用 Intune 发布管理员控制的 SSO 设置
HOWTO: 使用 Intune 发布管理员控制的 SSO 设置
在 2023 年 11月发布的更新（KB5032288）中，微软加入了确保欧洲经济区（EEA）遵守《数字市场法案》（DMA）的解决方案，旨在确保位于该区域的用户在使用 MSA 或 EntraID 登录 Windows 后启用第一个应用程序或服务时将提示用户是否愿意使用登录 Windows 的账号来登录这些应用或服务，从而限制了 Windows 单点登录（SSO），这一举措从 2024年1月开始推广至2024年3月全面推广。
EEA 区域包括了：奥地利、比利时、保加利亚、克罗地亚、塞浦路斯共和国、捷克共和国、丹麦、爱沙尼亚、芬兰、法国、德国、希腊、匈牙利、爱尔兰、意大利、拉脱维亚、立陶宛、卢森堡、马耳他、荷兰、波兰、葡萄牙、罗马尼亚、斯洛伐克、斯洛文尼亚、西班牙、瑞典、冰岛、列支敦士登和挪威。 EEA 区内共有 30 个国家。注意，由于英国退出欧盟，自 2021 年起不再是 EEA 成员国。
虽然该措施不影响中国用户，但对于正在出海的中国企业来说会有一些影响。好消息是！自 2026年7月发布的 KB5101650 更新允许管理员来配置受托管的终端是否自动接受 SSO 权限。但是会有一些前置条件：
- 范围：仅适用于拥有 EntraID 账户的 Windows 托管企业设备
- 不支持个人账户 - MSA
- 不支持非托管设备
- 支持的操作系统：Windows 11 24H2 和 25H2 含 KB5101650
要实现自动接受受管理设备的 SSO 权限，只需要修改注册表：
- HKLM\SOFTWARE\Policies\Microsoft\Windows\AAD
- AutoAcceptSsoPermission
- DWORD
- 1
该配置可以通过 GPO 等支持注册表策略部署的管理工具进行设置，对于在使用 Intune 的组织可以通过下发面向设备的 PowerShell 脚本，脚本内容参考如下：
$Path = "HKLM:\SOFTWARE\Policies\MicrosoftWindows\AAD"
if (-not (Test-Path $Path)) { New-Item -Path $Path -Force | Out-Null }
New-ItemProperty `
-Path $Path `
-Name "AutoAcceptSsoPermission" `
-PropertyType DWord `
-Value 1 `
-Force | Out-Null
对于网上流传的通过 OMA-URI 方式配置注册表的方法，经测试当前并不可行，所以放弃 ./Device/Vendor/MSFT/Registry 这个方式吧！
HOWTO: 通过 Intune 管理 WSL 和 WSLC
HOWTO: 通过 Intune 管理 WSL 和 WSLC
前端时间 gOxiA 与大家分享了 WSLC （WSL 容器）相关的内容 - 微软 WSL 容器发布预览版，从 WSL 2.9.3 Pre-Release 开始可以使用 WSLC 命令处理容器事务，如果你还没有开始体验，可通过 wsl --update --pre-release 获取预览版。相信你也会发自内心的感谢微软伟大的产品开发团队！
对于组织用户可能迫切需要统一管理 WSL/WSLC，并进行颗粒化的配置。WSL 的项目网站提供了 WSL ADMX，IT 管理员可以使用这个管理模板进行预管理和配置。如果当前组织正在使用 Intune，也不是问题！因为 Intune 已经支持导入 ADMX。
登录 Intune 管理中心，转到“设备 - Windows - 配置”，选择“导入 ADMX”。
在“导入 ADMX”页面点击“导入”，上传“ADMX 文件”和“默认语言的 ADML 文件”即可。
如果导入失败，如下图所示，则根据提示先导入 WSL ADMX 依赖的 Windows ADMX，然后重新尝试上传导入 WSL ADMX。
WSL ADMX 导入成功后，我们即可通过创建 CSP 来预先管理和配置 WSL/WSLC。以下 CSP 配置全部属于 WSL 命名空间，最终在 Intune 中会以：./Vendor/MSFT/Policy/Config/WSL/<PolicyName> 的形式出现。
EnableWSL（启用或禁用 WSL）
CSP 路径： ./Vendor/MSFT/Policy/Config/WSL/EnableWSL
值： 0 = 禁用 WSL 1 = 启用 WSL
DefaultVersion（默认 WSL 版本）
控制默认使用 WSL 1 或 WSL 2。
CSP 路径： ./Vendor/MSFT/Policy/Config/WSL/DefaultVersion
值： 1 = WSL 1 2 = WSL 2
EnableInterop（启用 Windows ↔ Linux 互操作）
控制是否允许 WSL 调用 Windows 程序、Windows 调用 Linux 程序。
CSP 路径： ./Vendor/MSFT/Policy/Config/WSL/EnableInterop
值： 0 = 禁用互操作 1 = 启用互操作
EnableDriveMounting（启用自动挂载 Windows 盘符）
控制 WSL 是否自动挂载 C:、D: 等。
CSP 路径： ./Vendor/MSFT/Policy/Config/WSL/EnableDriveMounting
值： 0 = 禁用自动挂载 1 = 启用自动挂载
EnableNetwork（启用 WSL 网络集成）
控制 WSL 是否使用 Windows 网络堆栈。
CSP 路径： ./Vendor/MSFT/Policy/Config/WSL/EnableNetwork
值： 0 = 禁用网络 1 = 启用网络
EnableFirewall（启用 WSL 防火墙例外）
控制是否允许 WSL 网络流量通过 Windows 防火墙。
CSP 路径： ./Vendor/MSFT/Policy/Config/WSL/EnableFirewall
值： 0 = 禁用例外 1 = 启用例外
EnableContainer（启用 WSL Container）
控制是否允许 WSL Container 功能。
CSP 路径： ./Vendor/MSFT/Policy/Config/WSL/EnableContainer
值： 0 = 禁用 1 = 启用
ContainerNetworkingMode（WSL 容器网络模式）
控制容器网络行为。
CSP 路径： ./Vendor/MSFT/Policy/Config/WSL/ContainerNetworkingMode
值： 0 = NAT 1 = Bridge 2 = None
ContainerCpuLimit（容器 CPU 限制）
限制容器 CPU 使用。
CSP 路径： ./Vendor/MSFT/Policy/Config/WSL/ContainerCpuLimit
值：数字（百分比或核心数）
ContainerMemoryLimit（容器内存限制）
限制容器内存使用。
CSP 路径： ./Vendor/MSFT/Policy/Config/WSL/ContainerMemoryLimit
值：数字（MB）
AllowedDistros（允许的发行版列表）
限制用户可安装的 Linux 发行版。
CSP 路径： ./Vendor/MSFT/Policy/Config/WSL/AllowedDistros
值：发行版名称列表（例如：Ubuntu;Debian;Alpine）
EnableLogging（启用 WSL 日志）
控制是否记录 WSL 日志。
CSP 路径： ./Vendor/MSFT/Policy/Config/WSL/EnableLogging
值： 0 = 禁用 1 = 启用
DebugMode（WSL 调试模式）
启用额外调试输出。
CSP 路径： ./Vendor/MSFT/Policy/Config/WSL/DebugMode
值： 0 = 禁用 1 = 启用
EnterpriseMode（企业模式）
启用企业级限制。
CSP 路径： ./Vendor/MSFT/Policy/Config/WSL/EnterpriseMode
值： 0 = 禁用 1 = 启用
GraphIntegration（Graph API 集成）
控制是否允许 WSL 与企业 Graph API 集成。
CSP 路径： ./Vendor/MSFT/Policy/Config/WSL/GraphIntegration
值： 0 = 禁用 1 = 启用
如果你觉得 CSP 配置麻烦，也可以通过创建基于模板类型的“导入的管理模板”配置文件来进行可视化配置。
Cloud rebuild 预览版发布
Cloud rebuild 预览版发布
微软在最近发布的 Windows 11 Insider 版本中提供了 Cloud rebuild 功能，从字面的意思可以理解为 Windows 操作系统的云重建，它与以往我们使用的 Windows 重置有一些区别，功能上虽然容易造成混淆，但在概念上存在本质的区别，这对于长期从事桌面标准化工作的 ITPro 以及 Windows 资深发烧友来说却是极为重要的一项改进以及需要务必关注的新功能！！！
Cloud rebuild 为 IT 管理员和普通用户提供了更为便利的操作系统重装方案，在过去我们要为设备重装系统其实并不简单，尤其对于普通用户，除了需要具备一些专业知识外，还需要提前准备很多物理和软件资源。但现在借助 Cloud rebuild 我们可以轻松地将设备还原为一个崭新的 Windows 环境。它无需依赖 U盘启动，也不必从 Windows 桌面状态发起，更不需要事先准备自定义系统映像和设备驱动程序，只要能够进入 WinRE 即可从微软官网站点获取 Windows 映像和设备驱动，然后对系统磁盘重新格式化，以及系统和驱动的安装，最终使设备系统环境恢复到崭新如初的状态。对于未托管的设备会从 OOBE 阶段开始对系统初始化配置，而那些已经通过 Intune 管理的设备则会重新连接到 Intune，并根据组织分发的策略执行后续的标准化配置。
简单理解这个概念，就是进入 WinRE 启动 Cloud rebuild，它就会帮你把设备系统环境擦除并重装为一个全新的状态！！！
下面我们来实际体验一下 Cloud rebuild，在 Windows 11 设备上要想进入 WinRE 其实有很多种方式，这里就不一一罗列，gOxiA 只介绍最为常用的两个场景。如果操作系统已经无法正常工作，那我们可以在启动设备进入 Windows 的过程中强行关机两次，那么第三次启动时就会进入 WinRE 环境；否则，打开 Windows 设置 应用，进入“系统 - 恢复”找到“高级启动”选项并点击“立即重新启动”。
进入 WinRE 后选择“疑难解答”即可看到“云重建”。
启动云重建后，会开始进行准备，主要就是检查网络访问情况以及当前的系统环境。如果准备就绪则会提示 Cloud rebuild 的主要内容，如要安装的操作系统版本以及 SKU 和语言。
重点来了，如果当前设备没有有线网络怎么办，只能连接到无线网络！？没问题，Cloud rebuild 重中之重的功能就是提供了无线网络连接的能力，当准备工作过程没有识别有线网络后，便会提示我们通过 WiFi 方式进行连接，只要当前无线网络支持 WPA-Personal 并能够访问互联网即可。
由于 Cloud rebuild 会重新格式化系统磁盘，所以接下来会进行确认，如果继续则会执行云重建，我们只需要等待即可。从提示可见 Cloud rebuild 将会：
- 删除所有个人文件、账户、应用和程序
- 删除对设置所做的任何更改
- 删除主驱动器上的所有内容并准备全新安装 Windows
- 安装 Windows 和所需驱动程序
整个过程还是很快的，全程可以看到下载和安装的进度，一个基础的场景 20多分钟就可完成，超出预期！相信未来实用性将会非常强。
要检查当前电脑的的 WinRE 和系统重置的配置和启用情况，可使用命令行：reagentc /getrecoverysettings，如果是组织用户还可以对一些关键配置进行预配，例如 WiFi 网络，可以添加 <wifi ssid="ContosoWiFi" password="ContosoWiFiPassword" /> 预先配置要连接的无线网络。
有关 Cloud rebuild 的更多详细信息可以参考： Cloud rebuild (Preview) | Microsoft Learn，更多推荐的官方文档如下：
