在SCCM2012中对应用评估进行故障排除

好吧，这将是一个很长的职位，但这里有好东西。

首先，已安装软件的GUID位于以下位置…

对于32位Windows和64位Windows上的64位软件：
HKLM \ SOFTWARE \微软\的Windows \ CurrentVersion \卸载

对于64位Windows上的32位软件：
HKLM \ SOFTWARE \ Wow6432Node \微软\的Windows \ CurrentVersion \卸载

您遇到的问题是GUIDstring不正确。 您从Adobe下载的MSI是美国英文版，因此GUIDstring的第三部分（1033是美国键盘的ANSI代码页）中的1033。

但是，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版本发布补丁。 你不能从11.0.1升级到11.0.7和他们的MSI，而无需卸载/重新安装整个产品。 如果你尝试，它会告诉你产品已经安装（因为GUID是一样的）。

以下是使用SCCMpipe理Adobe Reader的正确方法：您的应用程序需要两种部署types。

1）像你已经有的一样configuration11.0.0 MSI（确保检测方法的版本号是11.0.00，不要只使用GUID）并保存并closures它。

2）返回并添加另一个部署types。 这一次，select脚本安装程序作为types（SCCM本身不处理MSP文件）。 将其指向您的MSP文件，并使用msiexec / update（而不是通常的msiexec / i）作为您的命令行。 对于检测方法，使用相同的GUID，但11.0.07（或其他）作为版本。 指定第一个部署types作为其依赖项。 然后确保该补丁在列表中具有更高的优先级。 现在保存并再次closures它。

现在，当没有安装读卡器的客户端请求应用程序时，两者都将被安装。 如果这个人已经安装了EXE版本，它将被打补丁。 如果它已经被修补，那么它将显示为已经安装。

所以在经过一番研究并意识到Adobe Flash Player给我带来了一些困难之后，我形成了一个可能的假设。 据我所知，SCCM在以下WMI位置查找：

Namespace: root\CCM\CIModels Class: CCM_MSIProduct 

从我对WMI了解甚less的情况来看，这是由SCCM客户端创build的，当您思考SCCM的工作原理时，这会产生一种扭曲的感觉。

我从“部署监视工具”获取了该位置，您可以在System Center 2012 Configuration Manager工具包中find该位置。 如果您查看部署区域和“执行”选项卡，则可以查看DiscoverySourceXML以查看检测返回的内容。

我今天才发现，所以我还没有完全testing。 此位置可能只是应用程序发现过程的结果存储区。 到目前为止，让我知道哪些产品代码与SCCM应用程序评估过程一起工作已经足够了。

我真的需要一个SCCM开发者来看看这个，并且让我直观。

额外的东西

列出WMI对象的Powershell脚本：

 Get-WmiObject -Namespace root\ccm\CIModels -Class CCM_MSIProduct | Sort-Object ProductName |Format-Table ProductName,ProductCode,ProductVersion 

我在哪里可以看到检测方法查询的内容以及返回的内容？

我不认为SCCM有办法做到这一点，尽pipe真的希望有，尤其是对于全球情况。 没有比在向导中构build“检测日志”更令人沮丧的事了，如果不能像预期的那样工作，并且您的用户界面不透明作为您的疑难解答信息。

我要做的是find一个testing计算机（或者最好是一个虚拟机，这样你可以使用快照），处于打破检测逻辑的状态，启动ProcMon ，运行应用程序部署评估周期，看看你find了什么。

执行“Windows安装程序”检测时，系统在何处查找该GUID？

如果我对MSDN的阅读是正确的，MSI会在HKLM\Software\Classes\Installer\Products注册ProductCode。 一个合理的假设是，应用程序检测检查该位置，同样可以使用ProcMon进行确认。

至于你的问题Adobe Reader的可执行安装程序打破你的检测逻辑我做了一些在我的“实验室”（即我的工作站）testing，并能够重现您的问题。

我认为所有Adobe Reader可执行文件都是解包并运行MSI安装程序。

如果您查看setup.ini的内容，您可以看到所有可执行文件都启动了MSI安装程序：

 [Startup] RequireOS=Windows 2000 RequireMSI=3.0 RequireIE=6.0.2600.0 [Product] msi=AcroRead.msi 

无论哪种方式，安装程序确实注册了ProductCode，所以如果这是所有你运行你的检测逻辑上没有明显的区别两种安装方法。 但是，如果您对可执行安装程序和MSI安装程序的registry项进行比较，则可以看到一些差异：

从可执行安装程序：

 [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products\68AB67CA7DA73301B744BA0000000010] "ProductName"="Adobe Reader XI (11.0.06)" "PackageCode"="08610D4D4ABC0E74BB0257B5EDD58107" 

从MSI安装程序：

 [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products\68AB67CA7DA73301B744BA0000000010] "ProductName"="Adobe Reader XI (11.0.06)" "PackageCode"="26A6583616073E04583DBCA6F0289EEB" 

PackageCode是不同的。 安装源也应该不同。

从用户下载的可执行文件安装程序：

 C:\ProgramData\Adobe\Setup\{AC76BA86-7AD7-1033-7B44-AB0000000001}\ 

从SCCM部署MSI安装程序：

 C:\Windows\ccmcache\6f\ 

请注意，SCCM部署版本来自本地CCMcaching。

您可以根据需要将这些添加到检测逻辑或要求中，以纠正检测到的情况。

这是有道理的，sccm不会检测到应用程序安装在其外部的时间。 它使用wmi表来跟踪，这就是为什么如果有人删除wmi repo来“治愈”腐败，它将重新安装所需的工作站/用户的所有短信包。 在2007年，wmi表被称为SMS_InstalledSoftware，虽然我找不到'12所要求的。

现在，我不做Windows安装程序的安装，但是我知道有一个名为Win32_Product的wmi表，它包含了在Add / Remove Programs中find的安装指导，我猜是看起来在那里，尽pipe我可能是错的。 缺点是，如果他们安装不同版本的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中使用我自己的自定义检测脚本，基本上做这样的事情。

 $SPSS22 = Get-WmiObject -namespace Root\cimv2\sms -class SMS_InstalledSoftware -filter "ARPDisplayName LIKE '%SPSS Statistics%' AND ProductVersion='22.0.0.0'" If($SPSS22){return $true} 

有时我得到的应用程序没有检测到; 即使日志说，它没有问题安装。 但后来说，没有发现正确的地方下面说，返回的错误代码0; 成功。

转到添加/删除程序或执行Windows-R并键入appwiz.cpl查看是否安装了该应用程序。 如果显示，请记下添加/删除程序中显示的确切名称。 去掉它。 如果它迅速卸载，那么有更大的问题。 接下来你要做的是打开registry编辑器，然后按F3键进行search。 键入在添加/删除中列出的应用程序的名称。 一旦你开始在registry中find它，你将被删除键或取决于值。 如果删除键是某些地方，如卸载，安装，产品，function在registry中。 不用说，要非常小心你删除了什么，你可能会破坏你的电脑。 一旦完成，只需做另一个search，以确保你删除了一切。 现在尝试通过系统中心再次安装，如果它安装然后YAY！ 如果没有，那么还有一些底层的registry键或值需要删除。