回答:
いくつかの利点：
エンタープライズ環境でソフトウェアを展開するとき、MSIを介してソフトウェアを展開することはほとんど楽しいと思います。対照的に、私はほとんどの場合、ソフトウェアが別のコンテナにある場合にソフトウェアを展開することを恐れています。
MSIインストールの操作に関する追加情報についてmsiexecは、[実行]ダイアログに入力してください。
2018年7月の更新：以下の情報の非常に圧縮された要約がstackoverflowで利用可能です：MSIの主な利点 （"executive summary"-の種類）。
私は大企業でリリースマネージャー、ビルドエンジニア、セットアップ開発者として、またアプリケーションパッケージャーおよび展開エンジニアとして開発に携わってきました。
これは、MSI の最良（および最悪）の概念的および実際の機能のレビューです。MSIファイルで見つかった最も一般的な設計問題は、以下の個別の回答として提示されます。完全なふりをしていない-本当に厄介な「頭脳ダンプ」-「本には見つからないもの」を意図している（おそらく正当な理由のため）。
また、このMSDNの記事「Windowsインストーラー：システム管理者向けの利点と実装」を読むことをお勧めします。
一言で言えば、MSIは標準化に関するものであり、レガシーインストーラテクノロジーの「展開臭」に対処することに関するものです。展開の問題が繰り返し発生する、不良なインストールアーキテクチャ設計のコレクション。
全体的なMSIが提供する包括的な、標準化されたフレームワークインストーラ用決定的もアンインストール含むとするための組み込み機能およびオプションサイレント走行と標準化されたGUIすることができるリモートトリガを。
これらの機能だけでは大規模な改善を構成する信頼性とともに、企業展開のために、おそらく最も重要な機能-無計画アンインストールとサイレントランニングをあしらった、以前のインストールテクノロジの上にリモートパッケージ管理を経由して Active Directoryのかなど、専用のリモート管理ツールのMicrosoft SCCM、（旧SMS）を IBM Tivoli、 CA Unicenterなど。
誰かがこの回答の以前のバージョンを複製しました。たぶん、もっと早く読む？
MSI は、設計によりレガシー展開の臭いを積極的に阻止します。これらのトピックについては、後のセクションで説明しますが、簡単なリストとして、レガシーインストーラーおよび古い展開テクノロジーで最も認識される問題は次のとおりです。
このリストは、他の多くの重要かつ認識されている展開上の欠陥とともに続きます。これらの問題が最も頻繁に発生したのは明らかに企業展開の世界であり、標準準拠のMSIファイルを作成するためにレガシーインストーラーをディスクおよびレジストリスキャンテクノロジーでキャプチャする「アプリケーションの再パッケージ化」というビジネスをもたらしました。信頼できる展開のため。
アプリケーションの再パッケージ化は専門的な仕事であり、知識のある人が適切に行うと一般に優れた品質のMSIファイルになりますが、特定のアプリケーションが動作するためにインタラクティブに実行する必要がある複雑な登録ロジックのため、すべてのアプリケーションを再パッケージ化することはできません。
で平易な言葉 MSIの本当に重要な利点は、（順不同）は次のとおりです。
では、現実の世界、私が発見したあまり成功の側面を含めるようにパッチの適用（非常に複雑な）、MSI-GUI（プレーン機能は、非常に複雑、柔軟性に欠ける）、弾力性（可能性があり、繰り返し自己修復の問題をデバッグするのは難しい）、および全体的な複雑さ初心者向けの技術を扱うこと（時々、高度な基本操作-アップグレード、GUI、相互作用する多くの詳細などが予期しない結果を引き起こすなど）。MSIのオーバーヘッドの増加により、インストールプロセスの速度も大幅に低下しています。MSIのインストール速度を改善するためのヒントを参照してください。
テキストの残りの部分では、MSIのこれらの側面のいくつかをより詳細に扱っています。
MSIファイルは、基本的にはCOM構造のストレージファイルとして保存されたSQL Serverデータベースです。基本的には、ファイル内のファイルシステムまたはデータストリームのコレクションです。これはで使用されるファイルタイプであるMicrosoft Officeドキュメント、およびそれがもたらす標準フォーマットすることができ見直しと検査 - 大きな問題大企業のために。
コンパイルされたカスタムアクションを除き、MSIファイルはホワイトボックスです。セットアップがシステム全体のネットワーク設定などのクレイジーなものを変更した場合、適切なツールを使用して実際に確認できます。注目すべき例外は、コンパイルされたカスタムアクションです。これはブラックボックスです。Windowsロゴ要件では、カスタムアクションに注釈を付けて何をしているのかを説明する必要がありますが、セットアップ開発者はこれを無視することがよくあります。Wixの出現によりこれが改善されることを願っています。
そのようなコンパイルされたカスタムアクションが実際に技術的な意味で何を行うかを判断するには、セットアップキャプチャが必要です。これは私の経験ではほとんど行われていません。ソフトウェアが企業展開の承認を必要とする場合は、ベンダーに連絡して情報を入手するのがより一般的です。セットアップだけでなく、アプリケーション自体が使用を妨げる場合があります。
MSIは、ベンダーのインストーラー更新プログラムとの相互運用性を維持しながら、組織のニーズと標準に合うように変換を介してカスタマイズできます。インストーラー自体を変更するのではなく、トランスフォーム（.mstファイル）（必要に応じてデータベースフラグメントまたは変更トランザクション）と呼ばれる別の組織固有のファイルにカスタマイズを作成します。カスタムアクションを無効にしたり、一般的な変更を行ったり、インストーラーのすべてを上書きまたは無効にしたり、ファイルなどの新しいものを追加することもできます。変換ファイルは、MSIファイルを異なる言語にローカライズするために使用されることもあります。いくつかの変換を単一のMSIに適用できます。これは、パスが切り捨てられたサンプルです。
msiexec.exe /I "My.msi" /QN /L*V "C:\My.log" TRANSFORMS="C:\1031.mst;C:\My.mst"
クイックパラメーターの説明：
/QN = run completely silently
/L*V "C:\My.log"= verbose logging
TRANSFORMS="C:\1031.mst;C:\My.mst" = Apply transforms 1031.mst and My.mst.
Windowsインストーラーは、製品がレジストリにインストールしたすべてのアイテムの包括的なデータベースを保持します（HKEY_CLASSES_ROOT \ Installer-ここで直接変更しないでください！それは専門家にも当てはまります）。
製品がインストールされているか、インストールされている機能、インストールされているファイルのバージョンを確実に判断できます。さらに、ベース製品に適用されているパッチがある場合は、そのリストを取得できます。このデータベースには、Microsoft SCCM、IBM Tivoli、CA Unicenterなどのさまざまなスクリプト、構成、および管理ツールを使用して、Win32、COMまたは.NETをサポートするAPIを介してアクセスできます。
MSIには、制限されたユーザーがインストールに管理者権限を必要とする製品のインストールをトリガーできるようにする「昇格された権利」の原則も含まれます。これは、管理者がすべてのワークステーションに実際にインストールすることなく、ユーザーがインストーラーを利用できるようにする「広告機能」の一部です。この昇格された権利の概念が正しく機能するには、インストーラー自体がいくつかのコアアカウントで正しく作成されている必要があります。ユーザーは製品のインストールを自分でトリガーするか、SCCM、Tivoli、Unicenter（通常は大企業）などの専用デプロイメントシステムによってインストールを制御できます。一時的な管理者権限を台無しにして作業を行う必要はありません 多くの場合、レガシーインストーラーの場合です。
また、包括的なインストールデータベースにより、インストールされたパッチの完全な概要が得られるため、自動化ツールおよび管理ツールを介してセキュリティの脆弱性を検出できます。
MSIファイルを検証ルールでチェックして、多数の内部整合性ルール（ICEと呼ばれる）に準拠していることを確認できます。）。企業は、独自のICEチェックを作成して、特別な企業ルールと要件を実施できます。これはQAに大いに役立ちます。検証が可能な理由は、リレーショナルデータベースと関連するデータベーススキーマの自己参照の性質によるものです。データベースは、外部キー、データ型、フィールド幅、スキーマバージョンなどに関して、内部的に一貫性があり、独自のスキーマに準拠する必要があります。検証もこれを超え、パッケージ内の真の論理的な欠陥とエラーを検出できます。 、フォーマットとタイプの欠陥だけではありません。たとえば、エラーのある宛先に展開されているファイルまたはファイルタイプを検出できます。
Windowsインストーラーの管理者インストール機能は、MSIからソースファイルを抽出する標準的な方法を提供します（このトピックに関する追加情報があります）。これらのソースファイルを共有に配置し、すべてのワークステーションでインストールできるようになります。これにより、CDなどのインストールメディアを要求せずに、修復、アンインストール、および変更操作が完了します。これは、特別な状況で古いバージョンのソースファイルへのアクセスが必要な場合があるパッチ適用および更新操作にとって特に重要です。
この復元機能には一般的な問題もあります。ほとんどの管理者は、停止しないように見える周期的な自己修復サイクルのマシンを経験しています。この問題の原因の長いリストについては、リンクをたどってください。繰り返しますが、こちらは読みやすいかもしれない短いバージョンです。
MSIファイルをインストールすると、通常、復元ポイントが作成されます。さらに、インストール中に置換または上書きされたすべてのファイルとレジストリアイテムは、インストールが完了せず、カスタムアクションで行われた変更がない限り、保存および復元されます。
カスタムアクションは、Windowsロゴ準拠のための独自のロールバックサポートを実装する必要があります。多くの場合、これは無視されますが、メインのカスタムアクションによって行われた変更を取り消すための2番目のカスタムアクションの作成を伴います。
ロールバックにより、インストールが失敗した場合でもワークステーションが安定した状態のままになります。実際のロールバックスクリプトがに保存されている隠しフォルダ、システムドライブに直接-一般的にC：\ Config.MSI、それが拡張.RBSと.RBFを持つファイルが含まれ- ロールバックスクリプトファイルを。設計が不十分なMSIファイルは、ここでWindowsの組み込み機能に違反する可能性があると予想される場合があります。詳細については、このスレッドの他の投稿を参照してください。
ロールバックを無効にしてインストールを高速化する方法があります。一般的にはお勧めしませんが、MSIFASTINSTALLプロパティとDISABLEROLLBACKの詳細を次に示します。これは複雑な機能ですが、ここに簡単なロールバックの概要があります。
非常に複雑ですが、Windowsインストーラーでのパッチ適用はシステム上で完全に管理および登録されているため、インストールされているものを確認することでシステムのセキュリティ状態を判断できます。更新はいくつかの基本的なバリアントに標準化されており、これにより、複雑さを処理できれば、より確実に更新を実行できます。展開システムは、失敗した更新とその理由を報告できます。
主観的な見方では、パッチ適用は2つの基本的な用途でうまく機能します。1）提供された製品の小さな修正プログラム、2）インストールされた製品のパッチ適用
パッチは、すでに機能しているアップデートの単なる配信メカニズムです。そのため、元のセットアップ自体よりも複雑でエラーが発生しやすいのは単なるコンテナーです。パッチの最大のルールは、元のMSIよりも小さくする必要があること、またはパッチを配信する明確な理由がないことです。複数の製品バージョンを対象とする場合、パッチはすぐに巨大になります。
Windowsインストーラーは、以前のインカネーションよりもはるかに優れた標準化されたログ機能を提供しますが、ほとんど冗長です。ログアナライザーを使用してログファイルを解読し、カスタムログレベルを使用して、不必要な情報を含む大きすぎるログファイルを生成しないようにすることができます。デバッグの目的には、詳細なログが非常に役立ちます。MSIログファイルを読み取るための適切な手動方法については、Rob Menschingのブログを参照してください（基本的に、ログファイルで" value 3 " を検索します）。詳細ログを実行するコマンドラインの例を次に示します。
msiexec.exe /I "C:\Installer.msi" /QN /L*V "C:\msilog.log"
Windows Installer TeamのRobert Macdonaldによるこの記事は、MSIロギングの実用的な外観として強く推奨されています：Windows Installer Logsを解釈する方法。
Windows Installerのすべてが良いというわけではありません。その複雑さは時には困惑させることがありますが、大企業の場合、上記のメリットのリストを考慮すると、MSIファイルは他の展開形式よりもはるかに優れています。
新しい「パラダイム」を理解するには、MSIが固定されたイベントシーケンスではなく、ターゲットシステムで何が起こるかを宣言的に説明することを意図していることを理解することが重要です。あなたはそれを巨大なSQL文と考えることができると思います。たとえば、INIファイルに追加または変更するアイテムを宣言します。インストールの実行中に変更が追跡され、インストールが失敗した場合に変更を元に戻すことができるように、ロールバックが利用可能です。これは実際に「automagic」のように機能し、正しく行われた場合に信頼性があります。
それは巨大な頭痛のために、経験豊富なMSIの開発者は、人々がより良い内蔵のMSI機能が実装された機能のための複雑な、信頼性のないカスタムアクションに依存している参照してください。すべてのMSIエラーとロールバック問題のかなりの部分は、誤ったカスタムアクションが原因であり、他のほとんどのエラーは、MSIデザインの誤った使用が原因です（一般的なMSIエラーのリストについては、個別の回答を参照してください）。
組み込みのMSI機能に加えて、MSIファイルをコンパイルするXML方式であるWixなどの新しいフレームワークを介して、より多くのカスタム機能が利用できるようになりました。そのため、ほとんどの操作で複雑なカスタムアクションロジックの必要性はますます少なくなっています。
MSIは、iniファイル設定、フォント、環境変数、レジストリキー、COM情報、ショートカット、ファイル拡張子、起動条件、GACインストール、ODBCなどのマージ処理を完全にサポートしています。
WIXは、SQLサーバー拡張機能、IISのインストールと構成、パフォーマンスカウンター、DirectXチェックおよびその他のゲーム関連タスク、.NETネイティブイメージ生成、COM +、ドライバー、ファイアウォールルール、PowerShell拡張機能、アプリケーション終了などの非常に高度な機能をさらにサポートします。ユーザー、グループ、共有などの管理。対処するのに多少関与しますが、独自のカスタムアクションよりもはるかに信頼性が高くなります。
見通しを立てるために：これらの組み込みおよび既製のソリューションは、利用可能な最高の展開エキスパートによって作成され、数千、数万、または数百万のユーザーによってテストされます（MSIの組み込みのものについて）自体）。あなたはあなたがあなた自身のカスタムアクションをより良くすることができると本当に思いますか？ カスタムアクションの使用はまれなイベントであり、インストールする製品に固有の何かを達成するために絶対に必要なはずです。また、適切なロールバックサポートも記述する必要がありますが、これは非常に複雑です。
カスタムアクションの記述はほとんどの場合間違いですが、実際に柔軟性が必要な場合もあります。いつものように、あなたの戦いをうまく選ぶことが重要です。最初は楽しいタスクかもしれませんが、多くの予期しない問題に直面し、多くの時間を浪費することになります。これは非常に深刻です。私は企業で使用するC ++カスタムアクションのスイートを自分で作成しました（エラーが発生しやすいVBScriptカスタムアクションを排除するため）-それは公園内を歩くことではなく、コーディングは世界で最も難しいことではないかもしれませんが、デバッグとテストと実際のMSIファイルへの接続は、非常に複雑なものです。利用可能な既製のオプションを調査する時間は、開発作業の数週間を節約し、展開の信頼性を大幅に高める可能性があります。
非常に重要な点は、1回だけ実行され、非常に複雑な偽装、シーケンス、コンディショニング、およびランタイムを備えたセットアップではなく、予測可能なランタイムコンテキストと適切なエラー処理が利用可能な場合、アプリケーションの起動時に多くのアプリケーション構成が行われることです複雑さ。
セットアップでアプリケーションを構成するのではなく、最初の起動時に構成のためにアプリケーションを準備する必要があります。具体的には、 HKLMへの書き込み、サービスの登録、マシンごとのパスへのインストール、およびアプリケーションが通常のユーザー権限で独自に書き込むことができないものなど、昇格された権限を必要とするすべての設定をセットアップで書き込む必要があります。
セットアップ開発者の場合、セットアップカスタムアクションを記述する代わりに、アプリケーションの起動シーケンスのコーディングに関与するように提案する必要があります。他に何もない場合、あなたが他の誰かに「お金を渡す」ことを試みているように見えることを避けるために。この起動シーケンスでは、より信頼性が高く、テスト可能なコードを記述できます。これにより、QA担当者からテストの支援を受けやすくなります（多くの場合、展開テストやアプリケーションテストを理解していません）。
セットアップの複雑さの中心は、エラーが累積的である（迅速な再コンパイルだけでなく配信プロセスを管理している）、エラーのデバッグが非常に難しい（エラーが発生したシステムにアクセスできない）、ターゲットシステム州は考えられるあらゆる方法で異なります。この複雑さと、衝撃的な数の方法でターゲットシステムが警告する方法の詳細については、この回答を参照してください。WindowsインストーラーとWiXの作成、展開の複雑さ（下の方を参照）。
MSIファイルをコンパイルする新しいXMLベースの方法の説明については、このWiXクイックイントロダクションをお読みください。テキストベースのソースファイルは、以前よりもはるかに優れたソース管理を提供します。これは無料のオープンソースツールキットであり、強く推奨されています。
NB：MSIファイルに関する一般的な設計問題の概要については、スレッドの別の場所を参照してください-非常に不完全ですが、読む価値があるはずです。100％関連しているわけではないので、この返信に追加したくありませんでしたが、実際の使用では重要なトピックです。
（恥知らずな「昇進」を許してください-それは簡単なアクセスと検索のためです）
システム管理者がネットワーク上の展開を制御するのに役立つトピックへのリンクをいくつか紹介します。
特別なハウツートピック：
概念トピック/ベストプラクティス：
この答えは非常に進行中の作業であり、大まかな概要です。追加、質問、更新を歓迎します。このリストは決して完全ではありません。面倒なパッケージに関する情報をコメントに追加します。
また、多くのMSIファイルにエラー（場合によっては重大なエラー）が含まれていることを警告する必要がありますが、訓練されたアプリケーションパッケージャーはこれを検出し、ほとんどの場合問題を排除できます。基本的に別の質問に回答するため、これを別の回答として追加していますが、同じスレッドに関連があると感じています。
MSIに関連する技術的な詳細は非常に複雑です。基本レベルでは、ファイルとレジストリ設定をコンポーネント（アトミックインストール）と機能（ユーザーが選択できるインストールするアプリケーションパーツ（辞書機能など））に分解します。コンポーネントを分割するためのベストプラクティスルールが多数あり、MSIファイルのエラーは多数あります。これらのエラーは通常、「メジャーアップグレード」の使用を標準化することで処理されます。
実際のインストールは、いくつかのインストールシーケンスで実行されます。これらはすべてデータベーステーブルで定義されており、MSIの理解と処理は非常に複雑です。インストールシーケンス全体に広がるのは、標準アクションとカスタムアクションです。標準アクションはMicrosoftが設計したものであり、実行する必要があります（シーケンスは変更される場合があります）。ベンダーは、MSI自体でカバーされていないカスタムロジックを実行するカスタムアクションを利用できます。これらは、スクリプト形式でもコンパイル形式でもかまいません。カスタムアクションは、即時（一度に実行、システムを変更する必要はないが頻繁に実行）または遅延（実行スクリプトに書き込まれ、トランザクションとして実行され、ロールバックをサポート）することができます。
MSIの一般的なエラーは次のとおりです（特定の順序ではなく、実際の混乱として表示されます）。
より多くの微妙なエラーと、私が忘れていたいくつかのより大きく典型的な問題があります。
MSDNのWindows Installer Best Practiceの記事をご覧ください。
MSIを使用すると、パッチ（MSPファイル）とアップグレードも簡単になります。MSIでは、独自の製品コードとアップグレードコードの概念を使用しているため、プロセス全体が簡単になります。
一部の展開システム（CA Unicenter Software Deliveryはその一例です）もMSIを特別な方法で理解できるため、MSIを展開システムによりよく統合できます。たとえば、MSIを展開システムのソフトウェアライブラリにフィードすると、製品内のさまざまな機能が自動的に検出され、より詳細なカスタムアクション（ローカルインストール、検証、修復など）およびログ記録が自動的に許可されます。
自己修復/修復は、MSIにとっても大きな利点です。
また、XMLソースコードからWindowsインストールパッケージをビルドするツールセットであるオープンソースWindows Installer XMLを確認してください。ツールセットは、開発者がビルドプロセスに統合してMSIおよびMSMセットアップパッケージをビルドできるコマンドライン環境をサポートします。これは、MSがその主要なソフトウェアパッケージのいくつかを準備するために使用します。