これはいくつかの説明がありますが、ここにあります。アップグレード時に複数のインスタンスのMSIパッケージが失敗する
動的インスタンス（つまり、ユーザーがMSIファイルにハードコードされていないパッケージをインストールするときに定義されたインスタンス）をインストールする複数インスタンスのMSIを作成する必要があります。今、私はすでにブートストラップを作成し、MSI APIを使用して変換（MST）を動的に作成し、元のMSIに適用するという苦労を経験しました。多くの手直しの後、インストールとアンインストールがうまく動作します（必要に応じて詳細を投稿します）。
基本的に、MSTにProductCode、ProductName、PackageCode（概要情報）の変換が含まれています。すべてのコンポーネントのGUIDが変更されます。そうでなければ、アンインストールは愚かな方法で失敗します。また、ブートストラッパーは、コマンド行パラメーターMSINEWINSTANCE = 1（詳細はhere）でインストールを開始します。
しかし、アップグレードされたインスタンスを（メジャーアップグレードを介して）アップグレードしたいのですが、アップグレードコードがユニークである（または私が考えた）主な理由です。しかし、私はMSIのバージョンをインクリメントし、それを起動しようとすると（再度、ブートストラップを介して、MSIINSTANCEGUIDプロパティを介して目的のインスタンスのProductCodeを渡します）、失敗します。ログは言う：
=== Verbose logging started: 12/13/2011 17:43:56 Build type: SHIP UNICODE 5.00.7601.00 Calling process: C:\Windows\SysWOW64\msiexec.exe ===
MSI (c) (5C:D0) [17:43:56:120]: Font created. Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg
MSI (c) (5C:D0) [17:43:56:120]: Font created. Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg
MSI (c) (5C:34) [17:43:56:120]: Resetting cached policy values
MSI (c) (5C:34) [17:43:56:120]: Machine policy value 'Debug' is 2
MSI (c) (5C:34) [17:43:56:120]: ******* RunEngine:
******* Product: D:\TestArea\AMLDC.msi
******* Action:
******* CommandLine: **********
MSI (c) (5C:34) [17:43:56:120]: Machine policy value 'DisableUserInstalls' is 0
MSI (c) (5C:34) [17:43:56:135]: MainEngineThread is returning 1625
=== Verbose logging stopped: 12/13/2011 17:43:56 ===
とUIメッセージは、「システム管理者がこのインストールを防止するためのポリシーを設定している」と言ってポップアップ表示されます。明らかにそれは真実ではありません（ポリシーはログに表示され、より明示的なメッセージが提供されます）。
1625エラーコードが "ERROR_INSTALL_PACKAGE_REJECTED"に対応しているようです。
私は次に何を試すことができますか？私はMSIエンジンがこのケースで何をしようとしているのか、UpgradeCodeを調べ、元の変換（MSIINSTANCEGUIDパラメータを使って与えた製品コードでキャッシュして到達可能でなければならない）を適用することを考えています。しかし、エンジンがその段階に到達しないことは明らかです（ログファイルに記録する必要があります）。
一言、これははるかに痛いです。
編集：いくつかの時間後に...
クイックノートコンポーネントのGUIDを変更するに：それは（私はインスタンスを追跡するために使用するいくつかのレジストリエントリを持っている）非ファイルコンポーネントのだけは本当に必要なのです。私がGUIDを変更しないと、アンインストール時に正しく掃除されません。詳細はhereです。ファイルの場合は、キーパスが異なる場合は正常に動作し、レジストリコンポーネントを変更するだけでコードが検証されます。
私は、各インスタンスのUpgradeCodeを変更しない限り（FindRelatedProductsはUpgradeCodeのみを参照するため、私は思う）、大きなアップグレードはおそらく私にとってはうまくいかないことを学びました。そこに：軽度のアップグレード。
MSIINSTANCGUUID = {existing-instance-product-code}と一緒に/ fvamusを使用して新しいバージョンのインストーラを起動すると、パッケージに新しいファイルを追加しようとするまで動作していたようです将来起こります）...もちろん、それは動作しません（もちろん、新しいファイルのコンポーネントは再インストール時にインストールされません）。
私はおそらく、変換を使ってUpgradeCodeを変更し、それが何を意味するのかを見たり、FindRelatedProductsの出力プロパティをいくつかのカスタムアクションで混乱させたりします。しかし、最初の問題（1625エラー）は、大規模なアップグレードであったため、原因を知らずに何かできることがあるかどうかは不明です。私が上に貼り付けたのは、のMSI詳細ログのです。何かに戻る前にエラー1625が返されました.MSIのアップグレードテーブルのすべての行を削除しようとしました行動に変化はなかった。
私はこの愚かな問題にもっと時間を費やすことができないので、他に何も動かなければ、サイレントアンインストールとそれに続く同じ設定での通常のインストールが強制されます。私は思っていたが、助けられないのであれば...
編集：MSIのパスを完全には開始せず、自分のインストーラを絶対gzipされたストリームと簡単なxcopyを使用してスクラッチを作成します。ビジュアルスタジオなどからファイルを圧縮したmsbuildタスクでも。
FindRelatedProducts/RemoveExistingProductsに問題がありますか、または以前のバージョンをメジャーアップグレードの一部として削除する新しいバージョンのインストールで問題がありますか？マシンにv1.0のインスタンスが3つあり、v2.0（メジャーアップグレード）をインストールしようとしたときに、何をしたいですか？すべてのコンポーネントコードを変更することは私には珍しいことですが、私は主に現在の症状の原因のようには聞こえないことに同意します。 –
新しいバージョンをインストールするとき、私はブートストラッパーを通して既存のインスタンスの選択を許可しています。 MSIINSTANCEGUIDを渡しているので、そのインスタンスだけがアップグレードされると思います。しかし、私はFindRelatedProductsがUpgradeCodeだけを見ていることを学んだのですが、これまではすべてのインスタンスで同じようにしていました。私はマイナーなアップグレードを試してきました（私にはうまくいく/ fvamusで再インストールしています）。実際にあなたは何を知っている、私はすべての新しい情報で質問を編集します。 –