Microsoft IntuneでWin32アプリを配布した際、インストーラーが「再起動が必要」と返しただけなのに、インストール失敗として記録されることがあります。
この場合は、インストーラーが返す終了コードを確認し、Intuneの［Program］設定でSoft rebootまたはHard rebootに対応付けるのが基本です。再起動要求を単純なSuccessとして処理すると、Intuneが「再起動が必要」という情報を保持できません。
また、終了コードの設定と検出規則は別の仕組みです。終了コードはインストール直後の処理を決め、検出規則はアプリが実際に端末へ導入されたかを確認します。両方を正しく設定しないと、インストール自体は成功しているのに失敗や未検出として扱われることがあります。
Intune Win32アプリで再起動要求が失敗になる理由
Win32アプリのインストーラーは、処理結果を数値の終了コード、またはリターンコードとして返します。
たとえば、インストーラーによっては次の状態をそれぞれ異なるコードで返します。
- 正常にインストールできた
- インストールには成功したが再起動が必要
- 別のインストール処理が動作中なので後で再試行してほしい
- 致命的なエラーでインストールできなかった
Intuneは数値だけを見て、その意味を自動的にすべて判断できるわけではありません。［Program］設定に登録された対応付けを使い、そのコードをSuccess、Failed、Soft rebootなどの動作へ変換します。
そのため、再起動要求を示すコードがFailedとして登録されていたり、ラッパースクリプトが別のコードを返していたりすると、実際には導入できていても失敗として記録されます。
リターンコードに設定できる5種類の動作
IntuneのWin32アプリでは、インストーラーから返されたコードを次の5種類に対応付けられます。Microsoftの公式ドキュメントでは、各種類の動作が次のように定義されています。([Microsoft Learn][1])
| Code type | 意味 | 主な用途 |
|---|---|---|
| Success | インストール成功 | 再起動も再試行も不要な正常終了 |
| Failed | インストール失敗 | 自動再試行では解決しないエラー |
| Retry | 一時的な失敗として再試行 | 別のインストール処理が動作中など |
| Soft reboot | 再起動は必要だが、次のWin32アプリを導入できる | 現在のアプリの完了に再起動が必要 |
| Hard reboot | 再起動するまで次のWin32アプリを導入できない | 後続処理を進める前に再起動が必須 |
重要なのは、インストールに成功して再起動だけが必要なコードを、Failedにしないことです。
一方で、再起動が必要なコードを安易にSuccessへ変更することも避けます。Successにすると、Intuneから見れば通常の正常終了となり、再起動が必要という意味が失われます。
Intuneで終了コードを設定する手順
インストーラーが実際に返すコードを確認する
最初に確認するのは、一般的なコード一覧ではなく、配布対象のインストーラーが実際に返すコードです。
確認先には次のようなものがあります。
- 製品ベンダーの導入手順書
- インストーラーの公式リファレンス
- インストールログ
- コマンドを手動実行した際の終了コード
- インストールに使用するPowerShellスクリプト
- バッチファイルやラッパーアプリの仕様
MSI、EXE、ベンダー独自のセットアッププログラムでは、同じ数値が常に同じ意味になるとは限りません。特に独自EXEやラッパースクリプトを使用している場合は、MSIの終了コード表だけで判断しないことが重要です。
［Program］でリターンコードを確認する
Win32アプリの作成画面または編集画面で［Program］を開きます。
［Specify return codes to indicate post-installation behavior］の一覧で、インストーラーが返す数値とCode typeの対応を確認します。
Intuneではアプリ作成時にリターンコードの行があらかじめ追加されますが、必要に応じて既存行の変更や新しいコードの追加ができます。([Microsoft Learn][1])
設定例は次のようになります。
| インストーラーの結果 | Intuneで設定する候補 |
|---|---|
| 正常終了、再起動不要 | Success |
| 正常終了、再起動が必要 | Soft rebootまたはHard reboot |
| 一時的な競合で後から実行可能 | Retry |
| 設定不備や致命的エラー | Failed |
数値だけを見て決めるのではなく、そのコードが示す状態と、後続アプリを進めてよいかを基準に選びます。
Device restart behaviorも確認する
リターンコードだけでなく、同じ［Program］にある［Device restart behavior］も確認します。
リターンコードは「再起動が必要か」を表しますが、端末を実際にいつ再起動するか、利用者へどのように通知するかは、Device restart behaviorとの組み合わせで変わります。([Microsoft Learn][1])
保存後は少数端末で試験する
設定変更後は、全端末へ一斉配布せず、検証用グループで次の点を確認します。
- インストール結果がSuccess、Soft rebootなど想定した状態になるか
- 再起動通知が表示されるか
- 再起動前に次のWin32アプリが導入されるか
- 再起動後に検出規則が成立するか
- 同じアプリが再配布されないか
- 利用者の作業中に意図しない再起動が発生しないか
Soft rebootとHard rebootの違い
Soft rebootとHard rebootは、どちらも再起動要求を表します。ただし、次のWin32アプリを導入できるかどうかが異なります。
Soft reboot
Soft rebootでは、現在のアプリを完全に導入するために再起動が必要ですが、再起動前でも次のWin32アプリの導入を進められます。([Microsoft Learn][1])
次のような場合に適しています。
- インストール自体は完了している
- 再起動後にファイルやサービスの置き換えが完了する
- 後続アプリの導入を止める必要はない
- 利用者の都合に合わせて再起動させたい
ただし、後続アプリが現在のアプリの再起動後の状態を前提としている場合は、Soft rebootでは不十分なことがあります。
Hard reboot
Hard rebootでは、端末を再起動するまで、次のWin32アプリを導入できません。([Microsoft Learn][1])
次のような場合に検討します。
- ベンダーが後続処理の前に再起動を求めている
- 再起動前の状態で別のアプリを導入すると競合する
- 依存関係のある次のアプリが、再起動後の環境を必要とする
- ドライバーやシステム構成の反映後でなければ後続処理を実行できない
Hard rebootは導入順序を安全に制御できますが、再起動ポリシーによっては利用者の作業へ大きな影響を与えます。必要性を確認せずに設定するのは避けます。
Device restart behaviorによる動作の違い
［Device restart behavior］には複数の選択肢があり、同じHard rebootやSoft rebootでも端末側の動作が変わります。公式ドキュメントで示されている主な違いは次のとおりです。([Microsoft Learn][1])
| 設定 | 主な動作 |
|---|---|
| Determine behavior based on return codes | Hard rebootでは直ちに再起動し、Soft rebootでは再起動が必要であることを通知する |
| No specific action | MSIベースのアプリ導入中に端末の再起動を抑制する |
| App install may force a device restart | Hard rebootでは120分後に再起動する旨を通知し、Soft rebootでは再起動が必要であることだけを通知する |
| Intune will force a mandatory device restart | 正常にインストールした後、常に端末を再起動する |
再起動要求を正しくSoft rebootやHard rebootに登録しても、Device restart behaviorが運用方針と合っていなければ、想定外のタイミングで再起動する可能性があります。
特に［Determine behavior based on return codes］とHard rebootの組み合わせは、直ちに再起動する動作として説明されています。業務端末へ適用する場合は、未保存の文書や作業中のアプリに影響が出ないよう、利用者への事前通知や配布時間帯の調整が必要です。
Retryは5分間隔で3回試行される
Retryに対応付けたコードが返されると、Intuneのエージェントは5分間隔でアプリのインストールを3回試行します。([Microsoft Learn][1])
Retryは、時間を置けば解消する可能性がある状態に使用します。
たとえば、Windows Installerで別のインストール処理が進行中の場合、しばらく待つことで導入できる可能性があります。ただし、設定ファイルの不足、コマンドラインの誤り、権限不足など、待っても解決しないエラーをRetryへ設定しても成功しません。
| 状態 | Retryの適否 |
|---|---|
| 別のインストールが一時的に動作中 | 適している |
| 一時ファイルが使用中 | 製品仕様を確認して検討 |
| ネットワークやサービスの一時的な不調 | インストーラーの再実行が安全なら検討 |
| インストールコマンドが間違っている | 適していない |
| 必要ファイルがパッケージに含まれていない | 適していない |
| 対応していないOSへ配布している | 適していない |
Retryを設定するときは、同じ処理を複数回実行しても問題がないかも確認します。再実行のたびに設定が重複したり、中途半端なファイルが残ったりするインストーラーでは、単純な再試行が逆効果になることがあります。
Windows Installerでよく見られる終了コードの例
Windows Installerの公式ドキュメントでは、代表的なコードとして次の値が定義されています。これはMsiExec.exeやInstMsi.exeが返すコードであり、すべてのEXEインストーラーに共通するものではありません。([Microsoft Learn][2])
| コード | Windows Installer上の意味 | Intuneでの設定候補 |
|---|---|---|
| 0 | 正常終了 | Success |
| 3010 | インストール成功。ただし完了には再起動が必要 | Soft rebootを基本に製品仕様を確認 |
| 1641 | インストーラーが再起動を開始した。処理自体は成功 | Hard reboot候補として動作を検証 |
| 1618 | 別のインストールが進行中 | Retry候補 |
たとえば、MSIが3010を返しているのに、Intune側で3010がFailedとして登録されていれば、再起動要求が失敗として扱われます。
この場合は、製品仕様上3010が正常な再起動要求であることを確認したうえで、Soft rebootなどへ変更します。
ただし、次のようなケースでは3010とは異なるコードが返される可能性があります。
- ベンダー独自のEXEを使用している
- EXEの内部からMSIを呼び出している
- PowerShellでインストーラーをラップしている
- バッチファイルから複数のインストーラーを実行している
- 独自のエラーハンドリングでコードを変換している
既定の数値コードを全製品へ一律に当てはめるのではなく、実際の導入コマンド単位で確認する必要があります。
PowerShellスクリプトが終了コードを書き換えていないか確認する
IntuneのWin32アプリでPowerShellスクリプトをインストーラーとして使用する場合、Intuneが受け取るのは、スクリプト内で実行したMSIやEXEのコードではなく、最終的にPowerShellスクリプトが返した終了コードです。
Microsoftの公式ドキュメントでも、PowerShellスクリプトをインストーラーとして使用した場合、Intune上のインストール結果はスクリプトのリターンコードに基づいて表示されると説明されています。([Microsoft Learn][1])
たとえば、次のスクリプトはインストーラーの終了コードをIntuneへ引き継ぐ説明用の例です。
$process = Start-Process `
-FilePath ".\setup.exe" `
-ArgumentList "/quiet /norestart" `
-Wait `
-PassThru
exit $process.ExitCode一方、インストーラーの結果に関係なく最後にexit 0を実行すると、Intuneには常にSuccess相当のコードが返ります。
Start-Process `
-FilePath ".\setup.exe" `
-ArgumentList "/quiet /norestart" `
-Wait
exit 0逆に、インストールには成功しているのにスクリプト内の後処理で例外が発生し、別の非ゼロコードを返す場合もあります。
再起動要求が失敗になるときは、Intuneの設定だけでなく、次の経路を順に確認します。
MSI・EXEの終了コード
↓
PowerShell・バッチファイルの処理
↓
スクリプトが最終的に返す終了コード
↓
Intuneのリターンコード設定リターンコードと検出規則は役割が異なる
リターンコードを正しく設定しても、検出規則が誤っていれば、アプリが未導入として扱われることがあります。
| 設定 | 判定する内容 | 判定するタイミング |
|---|---|---|
| リターンコード | インストーラーがどのように終了したか | インストールコマンド終了時 |
| 検出規則 | アプリが端末に存在しているか | インストール後や再評価時 |
| 要件規則 | その端末がインストール対象として適切か | インストール前 |
Intuneの検出規則では、MSI製品コード、ファイル、レジストリ、カスタム検出スクリプトなどを使ってアプリの存在を確認します。必須として割り当てたアプリが未検出の場合、Intuneはおおむね24時間以内に再度アプリを提供する場合があります。([Microsoft Learn][1])
そのため、次のような症状では検出規則も確認します。
- インストール直後は成功したが、後から未導入になる
- 同じアプリが繰り返しインストールされる
- 再起動後に失敗へ変わったように見える
- ファイルは存在するのにIntuneでは未検出になる
- 32ビットと64ビットのパスやレジストリを取り違えている
再起動後に作成されるファイルやレジストリを検出対象にしている場合、再起動前には検出規則が成立しない可能性があります。リターンコードだけでなく、検出対象がいつ作成されるかも確認してください。
症状から設定箇所を切り分ける
| 症状 | 優先して確認する箇所 |
|---|---|
| 再起動要求コードを返した直後に失敗になる | リターンコードのCode type |
| MSIは3010だがIntuneでは別の数値になる | PowerShellやラッパーの終了処理 |
| 5分おきにインストールが繰り返される | Retryに登録されたコード |
| 再起動するまで次のアプリが進まない | Hard rebootの設定 |
| 再起動通知が表示されない | Device restart behavior |
| 導入後も未インストールと判定される | 検出規則 |
| 同じアプリが後日再配布される | 検出規則と割り当て |
| 作業中に突然再起動する | Hard rebootと再起動動作の組み合わせ |
設定変更前に確認したいチェックリスト
- インストーラーの公式資料で終了コードの意味を確認したか
- 実際の導入コマンドが返すコードを確認したか
- PowerShellやバッチがコードを書き換えていないか
- 再起動要求をFailedまたは単純なSuccessにしていないか
- Soft rebootとHard rebootの違いを理解しているか
- Device restart behaviorが業務運用に合っているか
- Retryにしても解決しない恒久的エラーではないか
- 再起動前後で検出規則が成立するか
- 少数端末の検証グループで試験したか
- 強制再起動の可能性を利用者へ案内したか
再起動要求は失敗ではなく、正しい動作へ対応付ける
Intune Win32アプリで再起動要求が失敗になる場合は、まずインストーラーが返す終了コードと、［Program］のリターンコード設定を照合します。
インストールに成功して再起動だけが必要なら、製品仕様と後続アプリへの影響を確認し、Soft rebootまたはHard rebootへ対応付けます。短時間で解消する一時的な状態ならRetryを検討し、待っても解決しないエラーはFailedとして扱います。
あわせて、Device restart behavior、PowerShellスクリプトの終了コード、検出規則を確認してください。特に業務端末では、Hard rebootや強制再起動を設定する前に、利用者への通知と検証用端末での動作確認が欠かせません。
[1]: https://learn.microsoft.com/en-us/intune/intune-service/apps/apps-win32-add “Add and Assign Win32 Apps to Microsoft Intune – Microsoft Intune | Microsoft Learn”
[2]: https://learn.microsoft.com/en-us/windows/win32/msi/error-codes “MsiExec.exe and InstMsi.exe error messages (for developers) – Win32 apps | Microsoft Learn”
コメント