我在企业环境中使用 BigFix，并注意到最近一轮的 Microsoft 2016 补丁在一小部分资产上失败了。我能够通过创建自定义复制修复程序并使用修改后的相关性来解决这个问题，但是我必须使用的相关性并不总是一致的，即使大多数文件都位于C:\Windows\Sytem32.
例如：MS16-031 - 我的扫描平台寻找的标准是基于的版本号Ntdll.dll。我创建了一个具有相关性的自定义修复程序：
((version of x64 file "C:\Windows\System32\Ntdll.dll") as string) < VersionNumberGoesHere
这个方法很有效，因为我之前已经创建了一个 BigFix 分析来寻找Ntdll.dll使用相关性的方法：
if (exists x64 file "C:\Windows\System32\Ntdll.dll") then ((version of x64 file "C:\Windows\System32\Ntdll.dll") as string) else "Does Not Exist"
我能够确认与 Custom Fixlet 的相关性大概分析非常准确。出于某种原因，它不是两者的镜像，但它非常接近，并且 Custom Fixlet 列出了扫描结果中标记的所有机器，所以我对此很满意。
问题出现在这里：对于一些文件中C:\Windows\System32，我必须使用完全不同的语法才能根据扫描结果获取我正在寻找的正确版本号信息。 也就是说，我能使用上面列出的方法，但它提供的版本信息与扫描仪所寻找的版本信息相差甚远。 如果我使用上面列出的方法，假设扫描仪正在寻找“版本号 6.1.7600.16385”之类的东西，我看到的结果将改为“1.1.11302.0”。它仍然是某种明显的版本编号，但与我的扫描平台所引用的类型完全不同。
例如：MS16-027 - 为了找到mfds.dll分析的文件版本信息，我必须使用：
value "FileVersion" of version block 1 of file "mfds.dll" of system folder
对于自定义 Fixlet，我必须使用：
value "FileVersion" of version block 1 of file "mfds.dll" of system folder != VersionNumberGoesHere (OSServicePatch_gdr.LongStringOfNumbers)
我阅读了一些有关 BigFix 的 Action Script 语法的资料，似乎32 位系统和 64 位系统的路径会导致不同的结果，但是，我认为这只适用于位于 和 内的文件x64 file (command)？事实并非如此吗？如果是这样，那么 64 位版本的 System32 位于哪里，为什么两者的结果会如此不同？file (command)C:\Program FilesC:\Program Files (x86)
答案1
需要澄清的是，这是一个关于 BigFix 相关性的问题，而不是 BigFix ActionScript 的问题。
我想说的是，尽管 BigFix 的相关性有一点学习曲线，并且有时难以弄清楚复杂性的来源，但您遇到的问题更多地与文件如何具有多种不同类型的版本信息的复杂性以及微软的 WindowsOnWindows 重定向的工作方式有关。
文件版本信息会因读取位置不同而不同，原因很简单，因为文件版本可以放在多个位置，它们可能完全匹配，也可能不同。这取决于文件的创建者以及他们希望如何传达版本信息的含义。
相关性versions of files "mfds.dll"读取一个位置，而相关性values "FileVersion" of version blocks of files "mfds.dll"读取不同的位置。
看这里：
Q: (values "FileVersion" of version blocks of it, (it as string) of versions of it) of files "mfds.dll" of (system folders)
A: 10.0.14342.1000 (rs1_release.160506-1708), 10.0.14342.1000
T: 3.677 ms
I: plural ( string, string )
我认为您所看到的差异并不是由于file和之间的差异造成的x64 file，但出于多种原因，理解这一点很重要。
为了回答这个问题，假设我们正在谈论一台 64 位 Windows 计算机，并且您应该假设这适用于 Windows Vista 或更高版本，但也可能适用于 Windows XP 64 位。
由于 BigFix 客户端是一个 32 位进程，因此对特殊 x64 位位置进行的所有文件读取实际上都由 Windows 重定向到 32 位位置。
filesBigFix 相关性中和之间的区别是什么x64 files？对于大多数文件，使用files和x64 files实际上都会读取同一个文件。这是因为使用 会x64 files告诉 BigFix 在禁用 WindowsOnWindows(WoW) 重定向的情况下读取文件，但此重定向仅适用于对特定路径的读取。一个例子是Program Files和另一个是System32，而像 之类的东西C:\Windows\Temp完全不受 WoW 重定向的影响，因此无论如何读取的任何文件的C:\Windows\Temp工作方式都相同。
- 32位位置：
C:\Program Files (x86) - 64位位置：
C:\Program Files - 32位位置：
C:\Windows\SysWOW64 - 64位位置：
C:\Windows\System32 - 64位位置：
C:\Windows\sysnative- 无需禁用重定向即可运行的特殊虚假路径
我们要感谢微软，因为 64 位系统位置的名称中有 32，而 32 位系统位置的名称中有 64。这绝对是造成混淆的一个极为常见的原因。
mfds.dll使用此相关性可看到系统上实际上有 2 个副本。
(name of it, size of it) of files "mfds.dll" of (system folders; system x64 folders)
这种相关性读取两个位置是因为(system folders; system x64 folders)告诉 BigFix 同时读取C:\Windows\SysWOW64文件夹以及C:\Windows\System32文件夹。
疯狂？困惑？等等，事情会更奇怪。
在 fixlet 调试器中运行以下相关性：pathnames of files "mfds.dll" of (system folders; system x64 folders)
Q: pathnames of files "mfds.dll" of (system folders; system x64 folders)
A: C:\WINDOWS\system32\mfds.dll
A: C:\WINDOWS\system32\mfds.dll
T: 1.312 ms
I: plural string
请注意，两个文件的路径名相同，但它们并不是同一个文件！
这就是 WindowsOnWindows 重定向的工作原理。它欺骗 32 位进程，并告诉它从该C:\Windows\System32位置读取文件，尽管C:\Windows\SysWOW64在使用相关性的情况下它从那里读取system folders，因此 BigFix适当地将路径名报告为C:\WINDOWS\system32\mfds.dll。然后在相关性的情况下system x64 folders，BigFix（32 位进程）告诉 Windows 它想要C:\Windows\System32在禁用重定向的情况下读取位置，在这种情况下，它实际上读取位于的文件C:\WINDOWS\system32\mfds.dll和适当地报告这样的路径名。
我想重申，这与 BigFix 无关，而与微软通过 Windows 32 位重定向实现 Windows 64 位有关。
对于将来的 BigFix 问题，我强烈推荐非常活跃的论坛：https://forum.bigfix.com/