BMC(ベースボード管理コントローラー)を介したサーバのリモート制御手段として注目を集めるRedfish。しかしWindows Server 2022/2019環境では、グレースフルな再起動が意図どおりに動作しないケースが報告されています。本記事では、その原因や確認方法を解説し、再起動を確実に成功させるためのポイントを丁寧にご紹介します。
Redfishでのグレースフル再起動とは
RedfishはDMTF(Distributed Management Task Force)によって策定されたサーバ管理用の標準規格であり、HTTP(S)を介したREST APIベースのインターフェイスを提供します。従来のIPMIよりも安全で拡張性が高く、サーバの電源操作やシステムモニタリング、さらにはBIOS/UEFI設定など、幅広いリモート管理が可能です。
グレースフル再起動の意味
グレースフル再起動(Graceful Reboot)は、OS側で実行中のアプリケーションやサービスに対して、適切にシャットダウンのプロセスを指示し、データの破損などを防ぎながら再起動を行う手法です。Redfish側で“GracefulRestart”や“PushPowerButton”などのコマンドを実行すると、通常はWindowsが内部でshutdownやRestart-Computer相当の処理を呼び出して、ユーザーセッションとアプリケーションを安全に終了させた上で再起動を行います。
Windows Serverとの連携
Redfishが発行するリモート再起動要求は、BMCファームウェアを通じてWindows Serverへと受け渡されます。BMCは通常、マザーボード上で独立した小型のプロセッサとして機能し、ネットワーク越しに受け取った指示をOSやハードウェアへ送達します。
Windows Serverが受信した再起動要求を正しく解釈し、スリープ状態や休止状態(ハイバーネーション)でなければ、ユーザーセッションの終了処理に入り、イベントログにも再起動操作が行われた記録が残るはずです。しかし、環境によってはこの一連のフローがうまく機能しないケースがあります。
再起動が反映されない主な原因と対処法
実際に、Redfish経由で「グレースフル再起動」指示を行っても、OSがまったく応答しない、あるいは一部のマシンでしか再起動がかからないといった事象が報告されています。ここでは、その主な原因と対処法を詳しく見ていきましょう。
1. スリープや休止状態における不具合
Windows Server 2022/2019でも、スリープや休止状態を利用するシナリオは一般的には少ないものの、特定の設定や環境下ではサーバが自動的にスリープへ移行することがあります。
- 原因：OSがスリープ中または休止状態中に、BMC経由での再起動要求を完全に受け取れず、OS側に処理が渡らない
- 対処法：
- サーバの電源設定を確認し、スリープや休止状態に入らないようにする
- 先にサーバを“Wake on LAN”機能などで起動状態に戻してからRedfish経由で再起動を試す
- BMCのWebインターフェイスから“Power On System”を実行し、OSが起動したのを確認した後にグレースフル再起動コマンドを送る
これにより、OSが動作している状態で確実に再起動コマンドを受け付けられるようになります。
2. アクティブユーザーセッションの影響
Windows Server環境では、ユーザーがログインし、アプリケーションを起動している最中にshutdown /rなどの再起動コマンドが来ると、通常は「再起動してもよいか」などのダイアログが裏側で表示される場合があります。
- 原因：ユーザーセッションやアプリケーションが“応答待ち”のダイアログを出しており、再起動要求が保留状態になる
- 対処法：
- Active Directoryやローカルアカウントでログイン中のユーザーが不要であれば、事前にログオフさせるよう運用を整える
gpedit.mscやグループポリシーを活用し、「強制的にアプリケーションをシャットダウンする」設定を見直す- ターミナルサービス(RDP)などから強制的にユーザーをログオフさせ、再起動要求を行う
上記の設定を行うと、無人運用時にアプリケーションが勝手に再起動要求をブロックするリスクを最小化できます。
3. ファームウェアやOSアップデートの不足
Redfishの実装はBMCベンダーごとにやや異なる場合があり、特に古いファームウェアだとWindows側への再起動要求の連携に不具合が生じることがあります。また、OS側においても最新の累積アップデートを適用していないと、シャットダウンや再起動に関する不具合が修正されていない可能性があります。
- 対処法：
- サーバベンダーのWebサイトから最新のBMC(ベースボード管理コントローラー)ファームウェアを入手し、アップデートする
- Windows Updateを適用し、Windows Serverのビルドやドライバーを最新の状態に保つ
- BIOS/UEFIのバージョンも最新化し、再起動シーケンスで問題が生じにくい環境を整える
4. ソフトウェア障害やサービス異常
ウイルス対策ソフトやセキュリティポリシーが厳しく設定されているサーバでは、外部からのリモート要求をブロックしている可能性があります。また、運用上重要なサービスが終了できず、OSが「再起動をキャンセルする」ような例外的ケースも考えられます。
- 対処法：
- イベント ビューアーの「アプリケーション」ログや「システム」ログを詳細に確認し、再起動要求のタイミングでエラーが出ていないかをチェックする
- ウイルス対策ソフトのログを確認し、Redfish経由のリクエストがブロック対象となっていないかを調べる
- 特定のサービスが再起動前に正常に停止されるか、Windowsの「サービス」管理画面やPowerShellコマンドで確認する
OSが再起動したかどうかを確認する方法
イベントIDでのログ確認
Windows Serverが再起動要求を受け取り、実際に再起動を開始したかを確認するには、以下の手順が一般的です。
- イベント ビューアーを開く
- 「Windowsログ」 → 「システム」を選択
- イベントID 1074 を探す
「1074」はUser32ソースで「再起動が行われた」「シャットダウンが行われた」という内容が記録されることが多く、誰が、どのように再起動を指示したのかを含む追加情報が確認できます。ただし、「再起動要求を拒否した」かどうかを示す明確なイベントIDは標準で存在しません。
そのため、再起動が行われなかった理由はイベントログに直接書かれない可能性が高いという点に注意が必要です。
アプリケーションログやRedfish側ログの併用
Redfish経由のリクエストを送る際に使用している管理ツールやスクリプトがあれば、そちらのログを併せて確認しましょう。ツール独自に「再起動要求が正常に完了した」または「エラーが発生した」というログを出力している場合があります。
また、BMCのWebUIやRedfishエンドポイント自体にも「レスポンスコード」や「エラーコード」が残ることがあります。再起動要求送信後にレスポンスとして正常ステータス(例えばHTTP 200系)が返ってきているかを確認することも重要です。
PowerShellを用いたイベントログの絞り込み
PowerShell上でも再起動をテストしたり、イベントログを絞り込んで検索できます。例えば、以下のようなコマンドを実行することで、イベントID 1074だけを抽出して確認できます。
Get-WinEvent -LogName System | Where-Object {
$_.Id -eq 1074
} | Select-Object TimeCreated, Id, LevelDisplayName, Message -First 20LogName System：システムログを指定Where-Object { $_.Id -eq 1074 }：イベントID 1074だけを抽出-First 20：最新20件を表示
この結果を見て、再起動がいつ、どのユーザーコンテキストで実行されたかを簡単に把握できます。
Redfish経由で確実に再起動させるためのポイント
1. Windows PowerShellやコマンドラインでの動作確認
Redfishによる再起動がうまくいかない場合、まずはOS側の通常コマンドが問題なく動作するか確認しましょう。
- shutdownコマンド
shutdown /r /t 0/rは再起動指定、/t 0はタイマーを0秒とする意味です。これで即時に再起動がかかるかどうかを確認します。
- PowerShellのRestart-Computer
Restart-Computer -Force-Forceオプションを付けることで、実行中のアプリケーションを強制終了しつつ再起動を実施します。ユーザーセッションにダイアログを介在させないため、Redfish経由の挙動を擬似的に確認することができます。
2. BMCの設定とファームウェア更新
Redfishのリクエストを受け取るBMCでは、ファームウェアのバージョンや設定によってWindowsからの応答が異なる場合があります。特に以下を確認しましょう。
- BMCのRedfish機能が有効になっているか
- ファイアウォールやネットワークポートの設定が正しいか
- 最新のBMCファームウェアが適用されているか
下記のような簡単な表を参考に、設定をチェックしてみてください。
| 項目 | 確認内容 | 設定例 |
|---|---|---|
| Redfish機能の有効化 | BMC WebUIや製品マニュアルでRedfishが有効化されているか確認 | 「Enable Redfish API」などのチェックボックスに✅を入れる |
| ネットワークポートの疎通 | Redfish用のTCPポート(通常は443または8443)が開放されているか | ファイアウォール例外ルールにTCP 443を追加 |
| BMCファームウェアバージョン | 最新の安定リリースが適用されているか | メーカーサイトからダウンロードし、ファームウェアアップデート実行 |
| BIOS/UEFIのRedfish連携設定 | BIOS/UEFIレベルでRedfish関連の機能が正しく設定されているか | 「Allow BMC to control system reboot via Redfish」などの項目が有効 |
3. イベントログを監視するスクリプトの導入
再起動要求が実際にOSに届いているかを監視するために、イベントログの監視スクリプトを導入する方法もあります。例えば、以下のPowerShellサンプルスクリプトでイベントログ(イベントID 1074)をリアルタイムに監視し、記録されたら管理者にメール通知を行う設定などが可能です。
# イベントログ監視サンプル
# イベントログのサブスクリプションフィルタ
$Query = @"
<QueryList>
<Query Id="0" Path="System">
<Select Path="System">*[System[(EventID=1074)]]</Select>
</Query>
</QueryList>
"@
Register-WinEvent -Query $Query -Action {
# イベント情報を取得
$event = $Event.SourceEventArgs.NewEvent
$time = $event.TimeCreated
$msg = $event.Message
# ログ記録やメール通知処理など
Write-Host "Reboot detected at $time. Details: $msg"
}こうした仕組みを導入すると、Redfish経由で再起動要求を行った際に実際のOS再起動をリアルタイムで検知できます。もしイベントが検知されなければ、OS側に再起動要求が到達していない、または受け付けられなかったと判断しやすくなります。
4. グループポリシーとシャットダウンポリシーの見直し
Windows Serverには、シャットダウンや再起動時のポリシーを制御する設定があります。例えば、グループポリシー「コンピューターの構成」→「管理用テンプレート」→「システム」などをチェックし、次のような項目を確認します。
- “シャットダウン イベントの追跡ツールを表示する”
- “ユーザーに対し、強制的にアプリケーションを閉じる”
- “複数の対話型ユーザーがいる場合にシャットダウン/再起動を許可する”
サーバ環境でユーザー対話を最小限にし、無人運用の再起動を安全に進めたい場合は、ユーザー入力を待たず強制的にアプリケーションを終了する設定が推奨される場合があります。
Redfish経由の再起動にまつわるトラブルシューティングの手順
トラブルシューティングの流れ例
ここでは、Redfishを使って再起動したつもりが実行されない場合に、どのように原因を絞り込んでいくかの一例を示します。
- サーバの実機状態を確認
- 物理的にサーバが起動中か、スリープ状態に入っていないか確認する
- BMC WebUIからサーバの電源ステータスを確認する
- Redfishレスポンスの確認
- Redfish APIコマンドを送信し、ステータスコード(200、202、400、403など)をチェックする
- BMC製品のログにエラーや拒否の記録がないか確認
- OSイベントログの確認
- イベントID 1074が記録されているか
- アプリケーションログでエラーが発生していないか
- ソフトウェアやユーザーセッションの切り分け
- シャットダウン・再起動がブロックされるプログラムが常駐していないか
- ターミナルサービス(RDP)セッションが残っていないか
- BMCおよびOSのアップデート
- BMCファームウェア、BIOS、OSパッチを最新化
- 再テスト
- 上記の対処を行ってから再度Redfish経由で再起動コマンドを実行
- Windowsが正常にシャットダウン・再起動できることを確認
まとめ
Redfish経由のグレースフル再起動は非常に便利な機能ですが、Windows Server 2022/2019環境によっては、ユーザーセッションやポリシー設定、ファームウェアのバージョンなどの要因が重なり、再起動要求が正しく反映されないケースがあります。再起動が行われていればイベントID 1074がログに残りますが、拒否された場合の専用ログは存在しないため、Redfish側のログやアプリケーションログと併せて原因を絞り込む必要があります。
また、スリープ状態や休止状態では再起動要求が届かないことがある点や、ユーザーセッション中に強制終了ダイアログが出て処理が止まることも考慮が必要です。定期的なBMCファームウェアやWindows Updateの適用により、再起動不具合のリスクを下げることができます。
運用の現場では、Redfish経由の無人再起動が必要となるケースも増えていますが、その際は必ずイベントログやBMCログを活用し、OSが適切に要求を受け取っているかをチェックしましょう。これらの対策を実践することで、Windows Serverの安定稼働を確保しながら、効率的なリモート管理を実現できます。
コメント