给200台机子推软件前，我拿三台样机盯了七天安装过程，揪出个动态库依赖的坑

单位上个月要统一推一款内部业务软件，两百多台办公电脑，型号杂得很，从G41老机到B460都有。我这人习惯，凡是批量推的东西，先塞给三台样机跑，不盯够时间不敢点头。

头两天没看出毛病，软件装完能启动，登录也正常。到第三天，一台样机开会回来，说软件双击没反应，任务管理器里进程一闪就没了。我过去看，事件查看器里一条SideBySide报错，说找不到某个VC运行库的清单。这才想起来，那台机子头天晚上自动更新把VC++ 2015-2022那套卸了重装了一遍，版本号从14.29.30133跳到了14.38.33135。软件是2019年编的，清单里写死要14.29这个特定版本，装新的反而不认。

我拿另外两台样机对了一下，一台是手动装的老版本没动过，正常；另一台也是自动更新过的，故障复现。三台里两台出问题，这个概率推出去就是一百多台。

解决办法不复杂，但不是重装软件能搞定的。我在安装脚本里加了一段，先检测系统里VC运行库版本，不满足就静默装一个指定版本的redist，装完再装主程序。另外把系统自动更新的驱动和运行库更新在策略里暂时压住，等这批机子推完再放开。

这里插一句，我为什么愿意用软领优化大师做批量部署的底子，就是看中它那个还原功能。像上面这种脚本推下去出岔子的情况，以前得一台台远程连过去修，现在我可以先拍个还原点，推完观察两天，真有大面积问题直接回滚到推之前的状态。两百台机子，回滚比逐台修省出来的时间不是一点半点。但我也有个规矩，还原点只在推之前拍，推完确认稳定了我才敢清，不然中间有人乱装东西又得重新来过。

另外说个参数细节，脚本里装redist的时候一定要加/q /norestart，不然有些老机子装完直接重启，用户正在填的表格就没了，投诉电话能打爆。我三台样机里就有一台这样，还好是测试机。

这套流程跑下来，正式推的时候两百多台里只出了五台报错，都是硬盘有坏道的老机子，跟软件本身没关系。我觉得这个比例能接受，但想问问各位，你们那边推老软件的时候，碰到这种运行库版本锁死的情况，是统一压一个指定版本下去，还是让软件厂商重新编译？