郭老师，你在85楼描述的是 ESU 许可证；在89楼描述的是系统根证书。这二者之间没有从属关系，甚至没有任何关系。

郭老师，你在85楼描述的是 ESU 许可证；在89楼描述的是系统根证书。这二者之间没有从属关系，甚至没有任何关系。

wu733 发表于 2025-7-6 22:15
抱歉，你说的这个数字证书我还不是很懂
不可否认，某些国软就是这么干的，时间一到就自动销毁
但是Win9 ...

certmgr.msc

qq2348227 发表于 2025-7-6 21:39
你就说，微软 会不会在 【Dec 2025 年，或者 Jan 2026 年】for Server 2008 R2 SP1 (win7x64)，埋逻辑炸弹 ...

抱歉，你说的这个数字证书我还不是很懂
不可否认，某些国软就是这么干的，时间一到就自动销毁
但是Win98最近都还有人在用，Win7会突然就用不了了？

你就说，微软 会不会在 【Dec 2025 年，或者 Jan 2026 年】for Server 2008 R2 SP1 (win7x64)，埋逻辑炸弹？
或者说，脱管之后/撒手不管之后，"2008R2SP1/win7x64"还能续命多久？（指数字证书延续）

仔细阅读完，感觉意义不大呢？

wu733 发表于 2025-7-6 19:45
你是指哪方面的数字证书？

就是 esu 4-6 默认的 所有数字证书
终止支持信息

[size=1.4em]对 Windows Server 2008 R2 的支持将于 2026 年 1 月结束

[size=1.4em]Windows Server 2008 R2 高级保证将于 2026 年 1 月 13 日结束。

[size=1.4em]Windows Server 2008 R2 扩展安全更新 (ESU) 已于 2023 年 1 月 10 日结束。 此外，Azure 上的扩展安全更新支持于 2024 年 1 月 9 日结束。 有关详细信息，请参阅 Windows Server 扩展安全更新概述。

[size=1.4em]建议升级到更高版本的 Windows Server。 有关详细信息，请参阅 Windows Server 升级概述。

两个压缩包已经更新

qq2348227 发表于 2025-7-6 19:26
大佬，能不能研究：

提取 July 2025 for Server 2008 R2 SP1 (win7x64)的所有数字证书，然后嫁接到 Jan  ...

好的，到时我一定补上

qq2348227 发表于 2025-7-6 19:26
大佬，能不能研究：

提取 July 2025 for Server 2008 R2 SP1 (win7x64)的所有数字证书，然后嫁接到 Jan  ...

你是指哪方面的数字证书？

大佬，能不能研究：

提取 July 2025 for Server 2008 R2 SP1 (win7x64)的所有数字证书，然后嫁接到 Jan 2020 for win7x64 方案啊？

gwaijyut 发表于 2025-7-5 15:05
这是把最新的文件删了，留下旧的文件夹？
旧文件夹里面其实装的也是新版文件（不全是，有时候是），而且 ...

" 当A补丁取代了B补丁，B补丁在winsxs下做的增量就可以删除了。"
这个可以有

wu733 发表于 2025-7-6 00:07
6.1.760x（包括6.1.7600、6.1.7601）、7.1.7601、7.2.7601版本的增量文件夹下，还需要分别提取6.1.7601、 ...

如果是这样的话，那么对这部分的注册表操作就简单一些：不必修改原路径(包含版本号)的文件夹名称，直接修改对应dll等文件的版本号即可。

另外，对于KB3125574的安装顺序，先后都可以。当然，最后装的肯定(必须)是月度汇总。
当使用相同的补丁列表，提前或靠后安装KB…574，区别只在于安装后产生的冗余文件的多少。
如果参考Simplix的做法，把它安排在所有补丁的倒数第三个比较合适：
（倒数4--最新的SSU；倒数3--KB3125574；倒数2--dotnet3.5相关；倒数1--月度汇总）

这个过程需要整体分析，局部分析不可靠。改天找时间提供实测对比

gwaijyut 发表于 2025-7-5 22:56
“如果是未安装KB3125574的情况下呢？经我验证，system32下使用的或者系统正在使用的版本，并不是版本最 ...

6.1.760x（包括6.1.7600、6.1.7601）、7.1.7601、7.2.7601版本的增量文件夹下，还需要分别提取6.1.7601、7.1.7601、7.2.7601最新稳定版的文件，分别进行替换。

其中，经验证，6.1.7600和6.1.7601版的增量可以全部使用6.1.7601版的最新稳定版进行替换，因为我发现非KB3125574系统中微软官方就是这么干的

wu733 发表于 2025-7-5 19:35
“ 这是把最新的文件删了，留下旧的文件夹？ ”
是的，也就是旧瓶装新酒。考虑到许多增量版本，我将它们 ...

“如果是未安装KB3125574的情况下呢？经我验证，system32下使用的或者系统正在使用的版本，并不是版本最新的那个（未安装KB3125574的情况）。”

这个并不绝对，情况比较多。似乎没有具体规律，大致有三种情况：
1、system32下使用当前最新版，winsxs中有多个版本；
2、system32下使用较旧版本，最新版在winsxs中；
3、system32下使用较旧版本，SysWOW64中使用当前最新版（这种情况就比较奇葩）

wu733 发表于 2025-7-5 21:05
winsxs下的许多增量文件夹，在你一个补丁一个补丁安装的情况下，这些增量文件夹下的文件版本是不同的。
...

“41个仅仅被KB3125574文件更新但又未被月度汇总更新”的KBs，
“1、非KB3125574方案不是最新版（我个人以为，应该是最稳定的那个版本，最新版则是测试版）”
“2、KB3125574方案的话，如果未被月度汇总更新，则全部替换成23403版，如果已经被月度汇总更新，比如KB4534310，则全部替换成24545）”

1、是的，非KB3125574方案中，41个KB所升级的文件，不是最新(最终)版，因为这些文件的“最新(最终)版”，由KB3125574提供。KB3125574对这41个KB的程序集，不仅仅是替代，还包含了升级；
2、是的。KB4534310程序集中，版本修订编号以24545为主，部分二进制文件不使用6.1.7601.xxxxx作为版本号

我明白了。“旧壶装新酒”，很好的思路。其中，对于“并行程序集”(如果有)，建议再细化一下。这是因为：
1、通常，“并行程序集”是单个 DLL 的多个版本，由“清单”文件描述，包含始终一起提供给应用程序的一组资源（一组 DLL、Windows 类、COM 服务器、类型库或接口）；
2、"清单"文件包含了描述"并行程序集"及其依赖项的元数据，是程序集"自我说明"的核心文档。每个并行程序集都具有唯一标识，标识的属性之一是其版本；
3、例如，test.dll 版本 1.0 和 test.dll 版本 v2.0 都位于并行程序集缓存中(winsxs\)，当 Program.exe 调用 test.dll 时，并行管理器将确定 Program.exe 是否具有清单中描述的版本依赖关系:
     如果没有相关的清单，系统将加载程序集的默认版本（system32\test.dll 版本 v1.0）;
     如果并行管理器发现 Program.exe 对清单中说明的版本 test.dll_v2.0 有依赖关系，则会加载该版本，使之与 Program.exe 一起运行。
综上，针对“并行程序集”部分，可以考虑补齐(或修改)清单文件。在本贴的情况中，这么做其实非常非常的麻烦！由于是“旧壶装新酒”，不做增量，与之对应的原始清单文件就需要修改，同时，包括且不限于以下路径的注册表信息：
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\ComponentDetect 【组件相关】


异常的难！

gwaijyut 发表于 2025-7-5 12:36
由于无权限上传图片，只能文字描述，唉！我尽量争取简单明了吧
涉及补丁：KB3147071、KB3125574

winsxs下的许多增量文件夹，在你一个补丁一个补丁安装的情况下，这些增量文件夹下的文件版本是不同的。

但是，如果你安装的是 “离线集成或封装” 的系统（非一个补丁一个补丁在线即时安装），此时你会发现系统的winsxs下的这些增量文件夹下的文件版本均被系统替换成了相同的一个版本（这也是我制作 “41个仅仅被KB3125574文件更新但又未被月度汇总更新压缩包 ”最关键的动机）：
1、非KB3125574方案不是最新版（我个人以为，应该是最稳定的那个版本，最新版则是测试版）
2、KB3125574方案的话，如果未被月度汇总更新，则全部替换成23403版，如果已经被月度汇总更新，比如KB4534310，则全部替换成24545）

这就好比给系统打驱动一样，最新版并不一定是最合适的版本。
在这里，非KB3125574方案使用的就是最稳定、最合适的版本，最新版反而存在潜在不确定的风险。而KB3125574方案使用的是23403+月度汇总更新的版本（23403版文件被微软官方认为是截止到2016年4月以来最稳定的版本，微软官方认为可以用23403版文件替换所有低版本的文件。而月度汇总如果又替换23403版文件，则微软官方认为月度汇总的版本是最稳定的）

gwaijyut 发表于 2025-7-5 12:36
由于无权限上传图片，只能文字描述，唉！我尽量争取简单明了吧
涉及补丁：KB3147071、KB3125574

我没有采用先进生产力工具去分析。我就是简单的，实体机安装了非KB3125574方案的系统，虚拟机则安装了“ 在非KB3125574补丁方案基础上 ”，“ KB3125574在前，月度汇总KB4534310在后 ”，这么一个传统手法的KB3125574的系统。如此，即可方便进行文件版本的比较和分析。
比如：我想知道未打KB3125574情况下，当前系统正在使用的文件版本，我就到实体机的System32及相关的文件夹下去查找，或者到winsxs下查找对应补丁文件夹中winsxs下的增量文件夹是否存在。我想知道打了KB3125574情况下，KB3125574更新了哪些文件版本，我就到虚拟机的相关文件夹下去查找，或者到winsxs下查找对应补丁文件夹中winsxs下的增量文件夹是否存在。

更新验证环境：
截止到2020年01月14日月度汇总KB4534310为止，以非KB3125574补丁方案做为基础，并采取 “ KB3125574在前，月度汇总KB4534310在后 ”传统打补丁的手法。
也即最终，我采用的整体打补丁的方法去研究的

gwaijyut 发表于 2025-7-5 14:28
在“合体版”中，建议楼主再检查一下吧

以Mtxoci.dll为例，KB3125574 将Mtxoci.dll更新为：6.1.7601.234 ...

“ 以Mtxoci.dll为例，KB3125574 将Mtxoci.dll更新为：6.1.7601.23403 ，合体版中，缺少这两个目录(及文件副本)，需要补齐”
我是考虑未安装KB3125574的情况，这个6.1.7601.23403目录是不存在的，故不需要补齐

wu733 发表于 2025-7-5 10:15
具体是Windows6.1-KB3133977-x64这个文件夹的winsxs下的里面，有七个23403的子文件夹，删除吧

这是把最新的文件删了，留下旧的文件夹？
旧文件夹里面其实装的也是新版文件（不全是，有时候是），而且，旧文件夹是否冗余，需要做进一步判断：
有两种情况不是冗余，部分初始文件夹，以及并行文件夹。
这里说的"并行文件夹"，由"并行程序集"产生。例如，同一个KB补丁，可能包含多个同名不同版的DLL文件:X.dll_ver01,X.dll_ver02,X.dll_ver03，ver01看上去就是旧版。由于跟其他几个版本同属一个KB，这几个版本之间就是"并行"关系，就不能把它当做冗余删除。
多个版本的并行程序，版本号最新的那个，一般是放在system32下使用的，其余的在winsxs下做增量更新。当A补丁取代了B补丁，B补丁在winsxs下做的增量就可以删除了。（适用于"官载取代"，以及楼主总结的"完全取代"，其他情况需继续进一步判断）

这个好

感谢分享!

在“合体版”中，建议楼主再检查一下吧

以Mtxoci.dll为例，KB3125574 将Mtxoci.dll更新为：6.1.7601.23403，对应winsxs目录：
C:\Windows\winsxs\amd64_microsoft-windows-com-dtc-oraclesupport_31bf3856ad364e35_6.1.7601.23403_none_4c296aef9821c0b6
C:\Windows\winsxs\x86_microsoft-windows-com-dtc-oraclesupport_31bf3856ad364e35_6.1.7601.23403_none_f00acf6bdfc44f80
1、合体版中，缺少这两个目录(及文件副本)，需要补齐。按：一般的，system32、SysWOW64 中的 DLL 文件，在winsxs中均存在对应版本的副本(以及目录)；
2、合体版中，Mtxoci.dll存在多个冗余副本，分别存储在多个以不同版本号区别命名的目录中(winsxs内)。均可删除。仅补齐以上两个目录即可。
     这些冗余目录分别是：19135、23338、23391

由于无权限上传图片，只能文字描述，唉！我尽量争取简单明了吧
涉及补丁：KB3147071、KB3125574

0.1、在D:\根目录，新建文件夹“版本跟踪”，切换到该目录；
0.2、新建空命令(文本)文件：“程序集清单.txt”、“获取清单文件版本号.cmd”；

1、获取 KB3147071 包含的"并行程序集"清单：h-t-t-p-://download.microsoft.com/download/b/a/3/ba3363d3-c3ba-4c4f-99a5-ca8275956a2e/3147071.csv
     提取 “x64 Windows 7 and Windows Server 2008 R2” 涉及的 194 个文件列表，将其复制到 D:\版本跟踪\程序集清单.txt

2、编辑 D:\版本跟踪\获取清单文件版本号.cmd，粘贴以下内容后保存：

1. @echo off
   
2. setlocal enabledelayedexpansion
   
3. for /f "delims=" %%f in (程序集清单.txt) do (
   
4.     echo 正在搜索 %%f ...
   
5.     wmic datafile where name="C:\\Windows\\System32\\%%f" get Name,Version 2>nul >> VersionInfo.txt || echo 未找到 %%f
   
6. )
   
7. endlocal
   
8. pause

复制代码

-----至此，完成准备工作-----

3、在虚拟机中，安装官版Windows 7 x64 SP1，并拍摄快照“Original”
3.1、运行 D:\版本跟踪\获取清单文件版本号.cmd ，得到 VersionInfo.txt ，将此文件重命名为“Original.txt”；
3.2、安装 KB3147071，重启后，运行 D:\版本跟踪\获取清单文件版本号.cmd ，得到 VersionInfo.txt ，将此文件重命名为“KB3147071_sys32.txt”；
3.3、恢复快照Original，安装KB3125574，重启后，运行 D:\版本跟踪\获取清单文件版本号.cmd ，得到 VersionInfo.txt ，将此文件重命名为“KB3125574_sys32.txt”；


4、使用BeyondCompare或类似工具，对比三个文件。

至此，完成文件版本号的对比。以上示例，仅跟踪了C:\\Windows\\System32目录的文件版本变化。其他目录同理，修改批处理中的目录地址即可。


这是一个大概的流程，其余细节的处理以及注册表部分就不写了，比较多和杂。大差不差吧