サイレントインストールを使うと、ユーザーの作業を妨げたり、各従業員に手動で承認・インストールしてもらったりすることなく、デバイス全体にアプリケーションや更新プログラムを展開できます。ただし、EXEインストーラーからサイレントインストールを実行しようとすると、ITチームが問題に直面することがあります。
MSIインストーラーはmsiexecを通じて一連のサイレントスイッチを共有しているため、サイレントインストールコマンドの設定が容易になりますが、EXEインストーラーにはそのような一貫性がありません。スイッチはインストーラーの作成に使用されたツールによって異なるため、/SコマンドがあるEXEでは機能しても、別のEXEではまったく機能しない可能性があります。このガイドのスイッチは、Windows 10とWindows 11でも同じように機能します。
それを踏まえて、サイレントインストール用のEXEコマンド、一般的なスイッチ、インストーラーフレームワークの見分け方、そしてサイレントインストールの扱い方と直面しうる障害について見ていきましょう。
EXEファイルをサイレントインストールする一般的なスイッチ
必要なサイレントインストールスイッチは、そのEXEを構築したフレームワークによって異なります。いくつかのバリエーションはありますが、インストーラーフレームワークとサイレントインストールコマンドを早い段階で特定することは可能です。
一般的なサイレントインストールスイッチには次のものがあります。
インストーラーフレームワーク | サイレントインストールコマンド | ※ |
InstallShield(Basic MSI) |
|
|
InstallShield(InstallScript) |
| 記録された応答ファイル( |
Inno Setup |
|
|
NSIS (Nullsoft) |
| 大文字と小文字を区別: |
WiX Burn bundle |
| オプションを確認するには、 |
Advanced Installer EXE |
|
|
サイレントインストールのスイッチが見つかったら、複数のデバイスに設定する前に、必ずテストしてください。誤ったスイッチを使うと、誰にも見えないプロンプトでインストールが止まってしまうことがあるため、1台のマシンでテストする価値は十分にあります。
ステップ1:インストーラーをビルドしたツールを特定する
まず最初に、そのインストーラーが使用しているフレームワークを特定します。EXEインストーラーは通常、InstallShield、NSIS、Advanced Installer などのパッケージングツールで構築されたラッパーです。各ツールにはそれぞれ独自のスイッチがあるため、使用ツールを特定すると選択肢を1つか2つに絞り込めます。
このツールは次のようないくつかの方法で特定できます。
インストーラーを
/?または/helpを付けて実行します: 多くのインストーラーはオプションを一覧表示したりツール名を示したりするため、ヘルプウィンドウはツールを特定する最も簡単な方法であることがよくあります。Microsoft の WinGet ドキュメントでは、サイレントインストール用のスイッチを見つけるために、-?を付けてインストーラーを実行することが推奨されています。セットアップウィザードを確認します: セットアップウィザードには、パッケージ化ツールの名前が表示されていることがよくあります。通常どおり起動してから、タイトルバー、ブランディング、または About のテキストを確認すると、そこに記載されているかどうかを確認できます。この後に確認したい手順がいくつかあるため、インストールする前に必ずキャンセルしてください。
アプリのWinGetマニフェストを確認します。アプリがWindows Package Managerコミュニティリポジトリにある場合は、そのマニフェストレコードを確認できます。これには、Inno、Nullsoft、WiX、Burn、MSIなどのインストーラーの種類が含まれていることがよくあります。
これらの方法がどれも機能しない場合は、ベンダーの設定ドキュメントを確認して詳しい情報を調べることができます。
ステップ2: EXEのサイレントインストール用スイッチを見つける
次に、サイレントインストールのスイッチが何かを確認する必要があります。これに対処する方法はいくつかあり、たとえば次のようなものがあります。
ベンダーの設定ドキュメントを確認する
ベンダーは、特にエンタープライズ設定に対応している場合、サイレントインストールオプションを用意していることがよくあります。ドキュメントを確認すれば、サイレントインストールのスイッチを直接見つけられることがあるため、まず最初に確認すべきです。ドキュメントには多くの場合、そのスイッチが何であるかが記載されており、ライセンスキーや機能選択など、ベンダーが追加したカスタムオプションも含まれていることがあります。
インストーラーのヘルプ出力を確認する
ドキュメントがわかりにくい場合は、インストーラーのヘルプ出力を確認できます。これを行うには、コマンドプロンプトで EXE を /? または /help を付けて実行し、使用方法のウィンドウが表示された場合は、サポートされているオプションが一覧表示されるはずです。ヘルプ出力がない場合は、インストールをキャンセルして別の方法を試す必要があります。
アプリの WinGet マニフェストを調べる
アプリがWinGetのコミュニティリポジトリにある場合、サイレントインストールをサポートしていることが必須です。GitHubでwinget-pkgsリポジトリを検索すると、そのアプリに記録されているインストーラーの種類とサイレントスイッチを確認できます。
最後の手段としてUniversal Silent Switch Finderを試す
他の方法がすべてうまくいかない場合、Universal Silent Switch Finder は、EXE を解析してそのインストーラーの種類に応じたスイッチを提案する無料のレガシーユーティリティです。ただし、これには制限があります。元のサイトはすでに利用できず、既知のフレームワークを使用していないカスタムインストーラーのスイッチは見つけられません。そのため、これを使用する必要がある場合は、信頼できるソースからダウンロードし、提案されたコマンドを必ずテストしてください。
インストーラーフレームワーク別のサイレントインストールスイッチ
では次に、よく見かけるサイレントインストールのスイッチをいくつか見ていきましょう。使用しているインストーラーフレームワークの種類がわかると、必要なインストールスイッチを特定しやすくなるため、この一覧を使えばスイッチをより簡単に見つけられます:
InstallShield のサイレントインストール
InstallShieldのサイレントインストール方法は、setup.exe を構築したプロジェクトタイプによって異なる場合があります。これには次のものが含まれます:
基本的なMSIプロジェクト: これらは応答ファイルを使用せずに
setup.exe /s /v"/qn"を実行します。/vとその値の間にスペースは入れられないため、/v"/qn"は動作しますが、/v "/qn"は動作しません。/vの引用符内にMSIプロパティを渡すこともできます。たとえば、setup.exe /s /v"/qn INSTALLDIR=D:\Destination"のように指定できます。InstallScript and InstallScript MSI projects: これらには応答ファイルが必要です。まず
setup.exe /rを1回実行して回答をsetup.issファイルに記録し、その後setup.exe /sを実行してそれをサイレントで再生します。これらについては、/f1を使って応答ファイルのパスを設定し、/f2を使ってログのパスを設定します。どちらも絶対パスで指定してください。
Inno Setup
Inno では、/SILENT コマンドを使用するとウィザードを非表示にしつつ進行状況ウィンドウは表示でき、/VERYSILENT を使用するとすべてを非表示にできます。/SUPPRESSMSGBOXES でメッセージボックスを抑制したり、 /NORESTART で自動再起動を防いだりすることもできます。
たとえば、Inno を使用したサイレントインストールは次のようになります: setup.exe /VERYSILENT /SUPPRESSMSGBOXES /NORESTART /LOG="C:\Logs\app.log"。
一部のメッセージボックスは抑制できない点と、/DIR= を機能させるには完全修飾パスが必要な点に注意してください。
NSIS (Nullsoft)
Nullsoft では、サイレントインストールを実行するために /S コマンドを使用できます。NSIS のオプションは大文字と小文字が区別されるため、S は大文字である必要がある点に注意してください。引用符なしで(パスにスペースが含まれていても)、最後のオプションとして /D= を使用してインストールフォルダを設定できます。
たとえば、setup.exe /S /D=C:\Program Files\App を実行できます。
インストーラーの作成者はこれらの既定値を上書きできるため、ベンダーのドキュメントに異なるコマンドが記載されている場合は、そちらを使用してください。
WiX Burn バンドル
Burn バンドルは、複数のパッケージ(通常は MSI)を連結して実行する EXE です。オプションはカスタマイズされている場合があるため、必ず /? を付けてバンドルを実行し、オプションを確認してください。
WiX Burn バンドルは、たとえば次のようになります: setup.exe /quiet /norestart /log C:\Logs\app.log.
Advanced Installer EXE
Advanced Installer EXE では、/exenoui を使用してラッパーのインターフェースを非表示にし、その後に msiexec オプションを続けることで、内部の MSI にコマンドを適用できます。これはたとえば次のようになります: setup.exe /exenoui /qn /norestart.
コマンドラインとPowerShellからEXEをサイレントインストールする方法
コマンドラインとPowerShellは、EXEをインストールする最も一般的な方法の2つです。サイレントインストールを実行する場合は、いくつかの簡単な手順に従って行えます。
コマンドプロンプトから
コマンドラインからEXEをサイレントインストールするには、インストール対象がすべてのユーザーに適用される場合、管理者としてコマンドプロンプトを実行します。そこから、インストーラーのフォルダーに移動し、そのEXEを対応するスイッチ付きで実行します。パスにスペースが含まれる場合は、必ず引用符で囲んでください。
一部のsetup.exeファイルは2つ目のプロセスに処理を引き継ぎ、インストールが完了する前にプロンプトに戻ることがある点に注意してください。このような場合は、インストールが完了するまでプロンプトを待機させるために、start /waitを使用してください。InstallShield Basic MSIセットアップでは、/wも使用できます。
PowerShell から
PowerShellを使用している場合は、Start-Process を -ArgumentList、-Wait、-PassThru と一緒に使用し、返されたプロセスオブジェクトから終了コードを読み取ることができます。Microsoft では、必要な引用符文字を含め、すべての引数を 1 つの ArgumentList 文字列として渡すことを推奨しています。
たとえば、PowerShell コマンドは次のようになります。
$p = Start-Process -FilePath "C:\Installers\setup.exe" -ArgumentList "/VERYSILENT /SUPPRESSMSGBOXES /NORESTART" -Wait -PassThru
$p.ExitCode
設定する前に再起動と終了コードに対処する
多くの更新またはインストールでは、正常に完了するために再起動が必要です。ただし、サイレントインストールではこの点が複雑になることがあります。サイレントインストールによって勤務時間中にユーザーのコンピュータが再起動されると、業務の中断につながるおそれがあります。同時に、デバイスでまだ再起動が必要な状態にもかかわらずインストールが成功として報告されると、問題の原因となり、保留中の更新が完了済みとしてマークされてしまうこともあります。
ここで終了コードについて説明します。終了コードとは、インストーラーが完了時に返す数値のことで、スクリプトや設定ツールがそれを読み取り、インストールが成功したか、失敗したか、または再起動が必要かを判断します。これらのコードはMSIベースのインストールでは標準化されており、(0 は成功、3010 は再起動が必要な成功を示しますが、EXEフレームワークでは異なる場合があります。
再起動と終了コードを扱う際に押さえておきたい重要なポイントがいくつかあります。
Inno Setup は警告なしで再起動することがあります: 再起動が必要な場合に
/NORESTARTを使用しないと、/SILENTコマンドでは "Reboot now?" というプロンプトが表示されます。一方、/VERYSILENTでは確認なしでマシンが再起動されます。中断なくインストールするには、/VERYSILENTと/NORESTARTを組み合わせて使用するのがよいでしょう。ただし、インストールに再起動が必要な場合は、ユーザーによる再起動は引き続き必要です。再起動が必要な場合でも、Inno Setup は 0 を返します: 再起動が必要な状態でも、インストールが完了したと報告されることがあります。コマンドに
/RESTARTEXITCODE=3010を追加すると、設定ツールが再起動待ちかどうかを判別できるようになります。InstallShield Basic MSI と Advanced Installer のセットアップでは、
msiexecのオプションを次の方法で渡します: コマンドのmsiexec部分に/norestart を追加すると再起動を抑制できるため、ユーザーの作業中にデバイスが予期せず再起動するのを防げます。1台のマシンで終了コードをテストしてください。更新を設定する前に、必ずコマンドをテストしてください。設定ツールを設定する前に、PowerShellからコマンドを実行し、終了コードを確認して、成功時と再起動保留時に何が返されるかを確認してください。
Intune では、終了コードはリターンコードの種類に対応付けられており、各コードの動作はアプリのデバイス再起動設定によって異なります。「リターンコードに基づいて動作を判断する」では、ハード再起動コードはデバイスを即座に再起動し、ソフト再起動コードは再起動が必要であることをユーザーに通知します。そのため、インストーラーが返すコードが Intune の想定と一致していることを確認する必要があります。
一般的なEXEサイレントインストールの問題をトラブルシューティングする
サイレントインストールを試みる際に、いくつかの問題や難しさに直面することがあります。一般的な EXE サイレントインストールの問題には、次のようなものがあります。
インストーラーがサイレントスイッチを無視する
インストーラーがサイレントスイッチを無視する場合、そのスイッチが別のフレームワーク用であるか、大文字と小文字が正しくない可能性があります。ベンダーのドキュメントを必ず再確認し、フレームワークを確認したうえで、すべてが正しく記載されていることを確認してください。たとえば、NSISが受け付けるのは大文字の/Sのみなので、大文字にし忘れると結果が変わります。
インストールが途中で止まり、完了しない
インストールが完了しない場合、誰にも見えない入力待ちになっていることがあります。たとえば、Intune のインストールがタイムアウト時間(既定では 60 分)を過ぎても待機している場合、失敗としてマークされます。一般的な原因としては、/SUPPRESSMSGBOXES では非表示にできない Inno Setup のメッセージボックスや、/s を付けてもサイレントにならない InstallShield の前提条件インストールがあります。
パスにスペースが含まれているとインストールに失敗する
これも、コマンド内のタイプミスが大きな違いを生むケースの1つです。フレームワークごとに引用符のルールが異なることが多く、誤った種類の引用符やスペースを使うとインストールが失敗することがあります。たとえば、NSIS の /D= は最後に置く必要があり、パスにスペースが含まれていても引用符は使えません。一方で、InstallShield では /v の値の中でエスケープした引用符が必要です。
何が問題だったのかを示すログがありません
何か問題が起きても、理由がはっきりわからない場合はどうすればよいでしょうか?テスト前にログを有効にしていなかった場合、原因を特定できない可能性があります。テストする前に必ずログを有効にし、そのログを既存のフォルダーに接続してください。これは、Inno Setup では /LOG="path" コマンド、InstallShield の setup.exe では /debuglog"path" を使用し、WiX Burn バンドルでは /log を使用します。
この EXE にはサイレントインストールオプションがありません
EXEによっては、そもそもサイレントインストールのオプションが用意されていないものもあります。この場合は、ベンダーが標準的なサイレントスイッチに対応したMSI版インストーラーを提供しているか確認してください。提供されていない場合は、EXEを再パッケージ化する必要があり、これにはある程度の専門的な作業が必要です。
Microsoft IntuneでサイレントEXEインストールを設定する
Microsoft Intuneを使用している場合、サイレントEXEインストールを設定する際に正しく設定すべきWin32アプリの項目がいくつかあります。Intuneでは、インストーラーと関連ファイルを.intunewinにまとめて、EXEをWin32アプリとして設定しますファイル。その後、インストールコマンド、アンインストールコマンド、検出ルールとともにそのファイルをアップロードします。Intuneは対話型インストールをサポートしていないため、インストールコマンドは完全にサイレントである必要があります。
これらのコマンドには次のものが含まれます。
インストールコマンド: テスト済みのとおり、EXE名の後にそのサイレントスイッチを続けます。なお、Intune ではコマンドラインの代わりに PowerShell スクリプトを指定することもできます。
アンインストールコマンド: アプリケーションをいつ、どのようにアンインストールするか。ここでは環境変数は展開されないため、アンインストールでそれらが必要な場合はラッパースクリプトを使用するとよいでしょう。
コマンドフィールド内の PowerShell: コマンドが
powershell.exeを呼び出す場合、Intune は 32 ビット版の PowerShell を起動するため、Windows によって 32 ビットのシステムフォルダーへリダイレクトされます。代わりに 64 ビット版の PowerShell を実行するには、%SystemRoot%\Sysnative\WindowsPowerShell\v1.0\powershell.exeを使用します。インストールの動作: インストールの動作を設定する際は、管理者権限が必要なインストールには System を選択してください。ユーザー コンテキストでのインストールに、ユーザーが持っていない管理者権限が必要な場合、失敗します。
タイムアウト: Intuneはデフォルトで60分待機してからインストールを失敗としてマークしますが、これは最長1日まで調整できます。
戻りコード: Intuneでは、アプリの作成時に既定のコードが追加されます。Inno Setupで設定する
/RESTARTEXITCODEの値など、インストーラーが返すカスタムコードを追加できます。再試行コードを設定すると、Intuneは5分間隔で3回試行します。検出ルール: Intuneがアプリのインストールを確認できるようにするには、少なくとも1つのルールが必要です。EXEにはMSI製品コードがないため、ファイル、レジストリ、またはスクリプトのルールを使用してください。
アプリカタログ全体でEXEのサイレントインストールが難しくなる理由
ここまでくると、EXE のサイレントインストールは必要以上に複雑だと感じるかもしれません。各 EXE について、フレームワークの特定、スイッチの確認、再起動や終了コードの動作テスト、検出ルールの作成などが必要です。そして新しい更新が出るたびに、そのプロセスはまた最初から始まります。
これをアプリごとに毎回繰り返すと、調査とテストはかなり大きな作業負荷になりかねません。
AI搭載のパッケージングツールを使えば、大規模な環境全体でも、その作業の多くを担えます。
Splashtop Agentic Packr は、インストーラーから Intune までのプロセスを自動化する、AI搭載のアプリケーションパッケージングツールです。AIエージェントがインストーラーを読み取り、パッケージを構築し、ユーザーに届く前にテストを行うため、管理者はまず結果を確認できます。
Splashtop Agentic Packr を使うと、次のことができます。
インストーラーを解析してパッケージを構築: Splashtop Agentic Packr はインストーラーを自動的に解析し、インストールロジックを含む PSADT パッケージを構築するため、管理者は新しいアプリごとにインストールスクリプトを作成する必要がありません。パッケージは PSADT 上に構築されているため、管理者は必要に応じてそれらを開いて確認し、調整できます。
展開前にテスト: すべてのパッケージはクリーンな仮想マシンでテストされ、セキュリティスキャンも実施されるため、意図したとおりに動作することを確認できます。管理者は公開前にQAスコアカードとログを確認できるため、最終判断を下せます。
検出ルールの設定と Intune パッケージ化: Splashtop Agentic Packr は検出ルールを書き込み、Intune パッケージを作成し、Intune に公開します。
新しいバージョンを検出: 新しいアプリバージョンがリリースされると、Agentic Packrがそれらを検出し、更新済みパッケージを自動で構築するため、ITチームの時間をさらに節約できます。
さらに、Splashtop AEM(Autonomous Endpoint Management)とSplashtop Agentic Packrを組み合わせて使用することで、設定をさらに改善できます。Splashtop Agentic Packrはパッケージの構築とテストを行い、その後Splashtop AEMが組織全体のデバイスに自動で設定できます。
スイッチの確認にかける時間を減らし、展開作業により多くの時間を使いましょう
EXEフレームワークごとに、独自のスイッチや再起動時の動作などがあります。それぞれを見極めて正しく設定することが、サイレントインストールを難しくする要因になりますが、同時に、それぞれを安全に設定できるようにするためにも必要です。
Splashtop Agentic Packr は、インストーラーを手動スクリプト作成なしでテスト済みの Intune 対応パッケージに変換するため、IT チームは新しいアプリやアップデートごとの調査やテストにかける時間を減らせます。
Splashtop Agentic Packr がインストーラーをテスト済みですぐに設定できるパッケージに変える方法を見てみませんか?詳細を確認して、今すぐ動作をご覧ください。




