欢迎光临,这里是 gOxiA=苏繁=SuFan 独立的个人博客。
本站域名:http://goxia.maytide.net or http://sufan.maytide.net
移动设备请访问:http://goxia.maytide.net/m
转载文章,请务必保留出处与作者信息,未经许可严禁用于商业用途!

troubleshooting

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。安装准备过程比较顺利,但等到开始安装后没多久便会提示安装失败,具体报错如下图所示。

ConfigMgr2411tp_Setup_SQRMO

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

msoledbsql

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

ConfigMgr2411TP_Setup_req1

ConfigMgr2411TP_Setup_req2

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

再谈 CompactOS

[ 2025/01/07 17:55 | by gOxiA ]

Windows_logo_horiz_blue_rgb

再谈 CompactOS

        距离上一次谈及 CompactOS 已经过去十年了,那还是在2015年的12月与大家分享了“HOWTO: 利用 CompactOS 减少 Windows 10 磁盘占用量”。感叹时间过得可真快,很多东西都已经变了……Windows 10 都已经发布10年之久了,说到这里提醒各位距离 Windows 10 生命周期结束还剩10个月左右(Windows 10 2025年10月14日终止服务),要抓紧向新的操作系统版本迁移!!!话题回到 CompactOS,再聊起它是因为最近在测试 Windows 11 IoT Enterprise LTSC 2024(以下简称W11IoTEntLTSC2024),先看下面两幅图。

compactos-disable

compactos-enable

        第一张图,是未启用 CompactOS 时空间占用情况,达到了 10.5GB,后者是启用了 CompactOS 的结果,仅占用了不到7GB的空间。对于结合了云端服务的现代计算设备而言,存储空间显得并不那么重要,先不说那些动辄 8~18TB 甚至更大海量存储的机械式硬盘,单固态硬盘 256GB ~ 1TB 也是常见,再高的还有 2TB ~ 4TB。既然不缺存储空间为什么还要谈 CompactOS 呢?对于 IoT 场景,通常设备存储不会太大,32GB ~ 64GB更为常见,按照 gOxiA 这个极端测试,仅配置了一个 16GB 的存储,此时操作系统的占用空间就显得尤为重要,越少的占用意味着可以留出更多空间给业务应用使用。所以,我们仍会用到 CompactOS,利用这个功能我们可以仅压缩运行操作系统所使用的文件,这些文件在运行读取操作时并不会在硬盘上进行解压缩,仅当需要进行写操作时才会从内存释放到硬盘。对于现代计算设备 CompactOS 所带来的影响是微乎其微的,甚至我们根本不会察觉到有什么变化,尤其是使用固态硬盘时!此外,根据微软官方的解释,由于压缩意味着减少读取,这将消除存储设备的负载,并提高 I/O 性能;但也意味着增加解压缩,此时 CPU 的负载将增加从而降低性能。这个特性也使 CompactOS 在具有快速 CPU 和 慢速存储 I/O 的系统上表现出可能更好的性能,当然这并不是绝对的!!! 下面是对启动过程做的评估,两台设备都是执行的全新安装,左列的设备在安装时使用应答文件启用的 CompactOS,为了确保数据的准确性,各做了三次启动数据的收集。左列设备的数据展示了在启用 CompactOS 后确实会对设备性能造成一些小的影响,启动速度慢了2秒左右,感官上确实没什么感觉!

WPR-Results-Analyze

        之后对收集的 ETL 数据继续了对比,确实如官方文档所述,挺有意思!

wpr-usage-analyze

        综上,如果我们要启用 CompactOS,建议使用更快的 CPU 和更大容量更快的内存,为了确保整体的运行性能,建议首选固态硬盘!对于启用 CompactOS,到目前 Windows 11 的 24H2 版本,Windows Setup 提供的 CompactOS 参数仍只支持升级模式,全新安装模式仍不受支持!要想在全新安装时启用 CompactOS 建议通过应答文件实现,参考如下:

unattend-compactos

        结束本次分享前,快速聊一下 CompactOS 所使用的压缩算法 - XPRESS4K,压缩率低但速度最快,与它一起提供的算法还有 XPRESS8K,XPRESS16K 以及 LZX。当我们要单独压缩某个程序时就可以根据实际需求执行,例如:compact /c /exe:lzx c:\program files\lobapp\lobapp.exe,对于 OEM 也可以对预装的那些只读程序文件进行压缩。


最后推荐两篇微软的官方文档供大家参考:

Compact OS, single-instancing, and image optimization | Microsoft Learn

Using Compact OS with Windows IoT Enterprise | Microsoft Learn

troubleshooting

  

HOWTO: 修复 Windows 系统文件和组件存储

  

        Windows 运行一段时间可能因为意外关机、系统崩溃,或不兼容的软件或驱动更新,又或者是第三方优化工具的误操作,导致 Windows 系统文件和组件存储出现错误,那我们的系统环境就会出现一些莫名其妙的异常故障现象,或发生性能缓慢的问题,所以定期检查修复是非常有必要的运维措施,那么我们该如何检查修复 Windows 系统文件和组件存储呢?!

  

        gOxiA 今天要分享的话题相对轻松,也更容易理解和掌握!首先我们先了解一下什么是系统文件和组件存储。系统文件即 Windows 操作系统自身的一些关键文件,它们包含了动态链接库文件(DLL);可执行文件(EXE);驱动文件(SYS);还有一些配置文件,如:注册表和启动相关文件;其他的还会有字体和主题文件这样的 Windows 应用资源文件,以及安全策略和网络组件文件。

  

        组件存储即 WinSxS 文件夹中的内容,它是系统文件的基石(备份库),包含了 Windows 所有核心组件的多个版本,用于支持系统文件的兼容性和回滚功能。每个组件都有对应的清单文件,记录了它们之间依赖关系和文件属性。文件中还包含文件的哈希值和数字签名,用于验证文件的完整性。

  

        系统文件和组件存储的关系是当进行系统文件扫描和修复时,都会从组件存储中进行提取。所以当我们执行系统文件修复失败时,就要先去执行和完整组件存储的修复。两者都会生成日志,并存储在“C:\Windows\Logs\DISM\dism.log”文件中,当需要进行相关排错时我们可以利用上这个日志文件。

  

        接下来,我们来了解如何修复系统文件和组件存储。对于系统文件,我们可以使用 SFC 命令,它内置于我们的系统中,需要管理员权限才能正常实行,具体的命令为:

  

sfc /scannow

  

sfc-scannow

  

        SFC 通过调用 Windows Resource Protection(WRP)技术来识别是否有核心文件被删除、损坏或修改。这个技术其实可以追溯到 Windows 98 时代的系统文件保护(System File Protection, SFP),再此之前 Windows 系统极易受到篡改……那会也是众多杀毒软件和专杀工具盛行的时期,再此之后 Windows 2000 和 XP 引入了 Windows 文件保护(Windows File Protection, WFP),到 Windows Vista 开始诞生了 WRP 并一路完善增强至今,使 Windows 越来越安全越来越稳定。

  

        OK,回归正题!如果执行后提示无法修复,那么我们就要使用 DISM 命令修复组件存储,首先我们可以先执行一次组件存储扫描,为此执行如下命令:

  

dism /online /cleanup-image /scanhealth

  

dism-scanhealth

  

        扫描组件存储后一旦发现有异常,我们就要执行修复,为此我们可以使用 /restorehealth 参数,即:

  

dism /online /cleanup-image /restorehealth

  

dism-restorehealth

  

        在执行 restorehealth 进行修复时会自动连接网络从微软官方 Update 及相关文件的资源网站下载正确的文件,如果出现网络问题则会影响修复,并提示失败。此时我们就需要手动指定稳定可靠的源,这个源可以是一个 Windows 实例,或者直接 Mount 一个 WIM 到目录进行引用,如果觉得麻烦,也可以直接引用一个 WIM。但需要确保引用的源与当前 Windows 实例的版本一致。

  

       下面 gOxiA 将引用一个 WIM 文件进行组件的修复,命令行如下:

  

dism /online /cleanup-image /restorehealth /source:wim:\f:\sources\install.wm /limitaccess

  

dism-restorehealth-succeed

  

        如果版本一致,并且源无损坏等异常,则能够修复成功,这样一来我们就不必通过重新安装操作系统来解决问题。

  

        最后,友情提示切勿使用第三方优化工具去执行清理 WinSxS 目录实现所谓的存储优化,它只会带来隐患!!!

分页: 1/477 第一页 1 2 3 4 5 6 7 8 9 10 下页 最后页 [ 显示模式: 摘要 | 列表 ]