我遇到了一个有趣的问题，即某些应用程序在 SCCM 2012 中无法正确评估。我拥有的示例软件是 Adobe Reader 11。当我通过软件中心使用 MSI 部署进行安装时，一切正常。当有人访问 adobe 网站并下载可执行安装程序并运行它时，就会出现问题。现在软件中心检测到该软件已卸载，并将列为可用标题。
我正在使用“Windows 安装程序”检测方法并寻找此 GUID“{AC76BA86-7AD7-1033-7B44-AB0000000001}”。当我查看 AppDiscovery.log 时，我得到的只是“未发现 +++ 应用程序”。信息。
那么问题来了：我在哪里可以看到检测方法正在查询什么以及返回什么？
额外问题：执行“Windows Installer”检测时，系统在哪里寻找该 GUID？
提前致谢
好的，这将是一个很长的帖子，但这里有好东西。
首先，已安装软件的 GUID 位于以下位置...
对于 32 位 Windows 和 64 位 Windows 上的 64 位软件：
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
对于 64 位 Windows 上的 32 位软件：
HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall
您遇到的问题是 GUID 字符串不正确。您从 Adobe 下载的 MSI 是美国英语版本，因此 GUID 字符串第三部分中的 1033（1033 是美国键盘的 ANSI 代码页）。
然而，EXE 安装程序是 MUI 版本，它的 GUID 为 {AC76BA86-7AD7-FFFF-7B44-AB0000000001} - 注意 FFFF 代替了 1033，这意味着它是多语言的。
在您的检测方法中，您需要添加一个 OR 子句，以便它将任一 GUID 识别为有效安装。
您还应该注意的两个问题：
1）您应该在检测方法中指定版本号。Reader 11 的所有版本都具有相同的 GUID（即 11.0.1 与 11.0.7 相同），因此如果用户使用的是旧版本，它将导致您的检测方法返回误报。
2) 如果您关心 Reader 的安全补丁，那么您应该知道 Adobe 仅针对 MUI 版本发布他们的补丁。如果不卸载/重新安装整个产品，您就无法使用其 MSI 从 11.0.1 到 11.0.7 进行“升级”。如果您尝试，它只会告诉您产品已经安装（因为 GUID 相同）。
以下是使用 SCCM 管理 Adobe Reader 的正确方法：您的应用程序中需要两种部署类型。
1) 按照已有的方式配置 11.0.0 MSI（确保检测方法指定了 11.0.00 的版本号——不要只使用 GUID）并保存并关闭它。
2）返回并添加另一种部署类型。这一次，选择 Script Installer 作为类型（SCCM 本身不处理 MSP 文件）。将它指向您的 MSP 文件并使用 msiexec /update（而不是通常的 msiexec /i）作为命令行。对于检测方法，使用相同的 GUID，但 11.0.07（或其他）作为版本。将第一个部署类型指定为其依赖项。然后确保补丁在列表中具有更高的优先级。现在保存并再次关闭它。
现在，当没有安装阅读器的客户端请求应用程序时，两者都将被安装。如果该人已经安装了EXE版本，它将被修补。如果它已经打过补丁，那么它只会显示为已安装。
因此，经过一番研究并意识到是 Adobe Flash 播放器让我感到不适，我形成了一个可能的假设。据我所知，SCCM 查看以下 WMI 位置：
根据我对 WMI 的了解，这是由 SCCM 客户端创建的，当您考虑 SCCM 的工作原理时，它会产生一种扭曲的感觉。
我从System Center 2012 Configuration Manager Toolkit中的“部署监视工具”获得了这个位置。如果您查看部署区域和 Enforcement 选项卡，您可以查看 DiscoverySourceXML 以查看检测返回的内容。
我今天才发现这一点，所以我还不能完全测试它。此位置可能只是应用程序发现过程的结果存储。到目前为止，让我知道哪些产品代码适用于 SCCM 应用程序评估流程就足够了。
我真的需要一个 SCCM 开发人员来看到这一点并让我明白这一点。
额外的东西
列出 WMI 对象的 Powershell 脚本：
我不认为有办法在 SCCM 中本地执行此操作，尽管我真的希望有，特别是对于全局条件。没有什么比在向导中构建检测日志更令人沮丧的了，它无法按预期工作，并且用户界面的不透明性作为故障排除信息。
我要做的是找到一台测试计算机（或者最好是一个 VM，以便您可以使用快照），它处于破坏您的检测逻辑的状态，启动ProcMon，运行应用程序部署评估周期并查看您的发现。
如果我对MSDN的阅读是正确的，MSI 将 ProductCode 注册到
HKLM\Software\Classes\Installer\Products. 一个合理的假设是应用程序检测会检查该位置，您可以再次使用ProcMon确认这一点。至于您的 Adobe Reader 可执行安装程序破坏了您的检测逻辑的问题，我在我的“实验室”（即我的工作站）进行了一些测试，并且能够重现您的问题。
我认为所有 Adobe Reader 可执行文件都是解压缩并运行 MSI 安装程序。
如果您查看其中的内容，
setup.ini您会发现所有可执行文件都是启动 MSI 安装程序：无论哪种方式，安装程序确实正确注册了 ProductCode，因此如果这就是您运行检测逻辑的全部内容，则两种安装方法之间没有明显区别。但是，如果您比较可执行安装程序和 MSI 安装程序的注册表项，您会发现一些差异：
从可执行安装程序：
从 MSI 安装程序：
PackageCode不同。安装源也应该不同。
从用户下载的可执行安装程序：
从 SCCM 部署的 MSI 安装程序：
请注意，SCCM 部署的版本来自本地 CCM 缓存。
您可以根据需要将这些添加到您的检测逻辑或要求中以更正检测此情况。
这是有道理的，当应用程序安装在它之外时，sccm 不会检测到。它使用 wmi 表来跟踪，这就是为什么如果有人删除 wmi 存储库以“治愈”损坏，它将重新安装该工作站/用户所需的所有 sms 包。在 2007 年，wmi 表被称为 SMS_InstalledSoftware，虽然我找不到 '12 的名称。
现在，我不进行 Windows 安装程序安装，但我知道有一个名为 wmi 的表
Win32_Product，其中包含您在“添加/删除程序”中找到的安装指南，我猜它看起来在那里，尽管我可能是错的。一个缺点是，如果他们安装了不同版本的 msi（因此安装了不同的 guid），那么这可能不会出现在您的检测中。我有时做的是对 .exe 进行软件清单检查，看看是否有人已经安装了这个，如果有的话是什么版本。我无法绕过人们自行在 sccm 之外安装应用程序，但这是政策，并不是 sccm 的真正用途。
我知道它很旧，但无法抗拒添加我的文章，尤其是关于 Win32_Product 的文章，因为它可能会产生负面影响！
我不能对上面的@Dotknuckle 回复发表评论，所以必须做一个全新的回复。Win32_Product 是一个坏主意，并且需要更长的时间，因为它会重新注册每个读取此内容的 MSI。http://www.itninja.com/link/why-win32-product-is-bad-news
至于 SMS_InstalledSoftware，它也存在于 SCCM 2012 中，并且位于命名空间 root\cimv2\sms 下，它比 Win32_Product 更安全，也更快。
可能同样适用于 CCM_MSIProduct 类，为什么它更快。我正在使用 SMS_InstalledSoftware 因为它返回更多信息。
我一直在 powershell 中使用我自己的自定义检测脚本，基本上做这样的事情。
有时我没有检测到应用程序；甚至日志都说它安装没有问题。但随后它说在返回错误代码 0 的下方未检测到；成功。
转到添加/删除程序或执行 Windows-R 并键入 appwiz.cpl 查看是否已安装该应用程序。如果它显示然后记下它在添加/删除程序中显示的确切名称。去掉它。如果它快速卸载，那么会有更大的问题。接下来您要做的是打开注册表编辑器，然后按 F3 进行搜索。键入应用程序在添加/删除中列出的名称。一旦您开始在注册表中找到它，您将被删除带有依赖项的键或值。如果密钥位于注册表中的某个位置，例如卸载、安装、产品、功能，则可以删除密钥。不用说要非常小心删除的内容，您可能会损坏您的计算机。完成后，只需进行另一次搜索以确保您删除了所有内容。现在尝试通过系统中心再次安装，如果它安装了，那么 YAY！如果没有