SCCM2012でのアプリケーション評価のトラブルシューティング
SCCM 2012）で一部のアプリケーションが正しく評価されないという興味深い問題が発生しています。所有しているソフトウェアの例はAdobe Reader 11です。ソフトウェアセンターからMSI展開を使用してインストールすると、すべてがうまく機能します。誰かがアドビのWebサイトにアクセスし、実行可能なインストーラーをダウンロードして実行すると、問題が発生します。ソフトウェアセンターでソフトウェアがアンインストールされたことが検出され、利用可能なタイトルとして表示されます。
「Windowsインストーラー」の検出方法を使用して、これを探していますGUID "{AC76BA86-7AD7-1033-7B44-AB0000000001}"。AppDiscovery.logを見ると、 「+++アプリケーションが見つかりません。」というメッセージです。
だからここに質問があります：検出方法がクエリしているものと、それが何を返すのかをどこで確認できますか？
ボーナス質問：「Windowsインストーラ」の検出を実行するとき、システムはそのGUIDをどこで探しますか？
前もって感謝します
OK、これは長い記事になりますが、ここには良いものがあります。
まず、インストールされているソフトウェアの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はUSキーボードのANSIコードページです）。
ただし、EXEインストーラーはMUIバージョンであり、GUID of {AC76BA86-7AD7-FFFF-7B44-AB0000000001}-1033の代わりにFFFFがあることに注意してください。つまり、多言語。
検出方法では、OR句を追加して、GUIDを有効なインストールとして認識できるようにする必要があります。
次の2つの注意点にも注意してください。
1）検出方法でバージョン番号を指定する必要があります。 Reader 11のすべてのバージョンは同じGUID（つまり、11.0.1は11.0.7と同じ）であるため、ユーザーが古いバージョンを使用している場合、検出メソッドは誤検知を返します。 。
2）Readerのセキュリティパッチに関心がある場合は、アドビがMUIバージョンのみのパッチをリリースすることを知っておく必要があります。製品全体をアンインストール/再インストールしないと、MSIを使用して11.0.1から11.0.7に「アップグレード」することはできません。試してみると、製品が既にインストールされていることがわかります（GUIDが同じであるため）。
SCCMを使用してAdobe Readerを管理する正しい方法は次のとおりです。アプリケーションには2つの展開タイプが必要です。
1）既存の11.0.0 MSIを構成し（検出方法にバージョン番号11.0.00が指定されていることを確認します。GUIDを使用しないでください）、保存して閉じます。
2）戻って、別の配置タイプを追加します。今回は、タイプとしてスクリプトインストーラーを選択します（SCCMはMSPファイルをネイティブで処理しません）。 MSPファイルをポイントし、コマンドラインとして（通常のmsiexec/iの代わりに）msiexec/updateを使用します。検出方法には、バージョンと同じGUIDを使用しますが、11.0.07（またはその他）を使用します。依存関係として最初の展開タイプを指定します。次に、リスト内でパッチの優先順位が高いことを確認します。保存して、もう一度閉じます。
これで、リーダーがインストールされていないクライアントがアプリケーションを要求すると、両方がインストールされます。その人に既にEXEバージョンがインストールされている場合は、パッチが適用されます。すでにパッチが適用されている場合は、すでにインストールされていると表示されます。
ですから、少し調べてみて、Adobe Flashプレーヤーが適していることに気づき、私は可能な仮説を立てました。 SCCM=は、次のWMIの場所を調べます。
Namespace: root\CCM\CIModels
Class: CCM_MSIProduct
私がWMIについてほとんど知らないことから、これはSCCMクライアントによって作成されます。これは、SCCMがどのように機能するかを考えるときにねじれた種類の意味をなします。
この場所は、 System Center 2012 Configuration Manager Toolkit で取得できる "展開監視ツール"から取得しました。展開領域と[強制]タブを確認すると、DiscoverySourceXMLを確認して、検出結果を確認できます。
今日これを見つけたので、まだ完全にテストすることはできません。この場所は、アプリケーション検出プロセスの単なる結果ストアである可能性があります。これまでのところ、SCCMアプリケーション評価プロセスで機能する製品コードを教えていただければ十分です。
私は本当にこれを見てSCCM開発者にこれを見て真っ直ぐに設定する必要があります。
余分なもの
WMIオブジェクトを一覧表示するPowerShellスクリプト：
Get-WmiObject -Namespace root\ccm\CIModels -Class CCM_MSIProduct | Sort-Object ProductName |Format-Table ProductName,ProductCode,ProductVersion
検出方法がクエリしているものと、何が返されているかはどこで確認できますか？
SCCM）でこれをネイティブに行う方法はないと思いますが、特にグローバル条件の場合、本当にあったらいいのにと思います。ウィザードで検出ログを作成する以外に不満はありません。期待どおりに機能せず、トラブルシューティング情報としてユーザーインターフェイスが不透明になっています。
私がやろうとしていることは、検出ロジックを壊す状態にあるテストコンピューター（またはできればVMでスナップショットを使用できるようにする）を見つけることです。開始 ProcMon 、アプリケーション展開評価サイクルを実行して、何が見つかったかを確認します。
「Windowsインストーラー」検出を実行する場合、システムはそのGUIDをどこで探しますか？
[〜＃〜] msdn [〜＃〜] の読み取りが正しい場合、MSIはHKLM\Software\Classes\Installer\ProductsにProductCodeを登録します。妥当な前提は、アプリケーション検出がその場所をチェックすることです。これも ProcMon で確認できます。
Adobe Readerの実行可能インストーラーが検出ロジックを破壊する問題については、私は「ラボ」（つまり、ワークステーション）で少しテストを行い、問題を再現することができました。
Adobe Reader実行可能ファイルが行うことはすべて、MSIインストーラーを解凍して実行することだけだと思います。
setup.iniの内容を見ると、実行可能ファイルが実行するのはMSIインストーラーの起動だけであることがわかります。
[Startup]
RequireOS=Windows 2000
RequireMSI=3.0
RequireIE=6.0.2600.0
[Product]
msi=AcroRead.msi
どちらの方法でも、インストーラーはProductCodeを適切に登録したため、検出ロジックを実行するだけの場合は、2つのインストール方法に識別可能な違いはありません。ただし、実行可能インストーラーとMSIインストーラーのレジストリキーを比較すると、いくつかの違いがわかります。
実行可能インストーラから：
[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デプロイされたバージョンはローカルCCMキャッシュからのものであることに注意してください。
これらを適切に検出ロジックまたは要件に追加して、この状態を正しく検出することができます。
それは理にかなっています、アプリケーションがそれの外にインストールされたときにsccmはそれを検出しません。追跡するためにWMIテーブルを使用します。そのため、WMIリポジトリを削除して破損を「修復」すると、そのワークステーション/ユーザーに必要なすべてのSMSパッケージが再インストールされます。 2007年には、wmiテーブルはSMS_InstalledSoftwareと呼ばれていましたが、'12の名前はわかりません。
現在、Windowsインストーラーのインストールは行っていませんが、[プログラムの追加と削除]にあるインストールのGUIDを保持するWin32_Productと呼ばれるWMIテーブルがあることはわかっています。間違っている可能性があります。欠点は、異なるバージョンの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}