Azure で Windows Server 2025 の VM を新規作成すると、初回ログイン直後にデスクトップは表示されるのにタスクバーが出ず、Server Manager の開始画面あたりで固まって操作不能になることがあります。Bastion でも直接 RDP でも同様に起きるため、ネットワークだけでなく OS とディスク周りの切り分けが重要です。
現象の特徴：Bastion / RDP 共通で「ログイン直後に固まる」
このトラブルは、Azure ポータルから Windows Server 2025 の新規 Azure VM を作成した直後に発生しやすく、ログイン自体は成功するのに、ログイン完了後のデスクトップ操作がほぼできなくなるのが特徴です。Bastion 経由でも、直接 RDP 接続でも同じ挙動になるため、まずは「踏み台の問題」や「RDP クライアントの問題」ではなく、VM 側の状態（OS / ストレージ / 初期化処理）を疑うのが近道です。
- デスクトップ背景は表示されるが、タスクバーが出ない／クリック操作が反応しない
- Server Manager の起動画面が見えたあたりでフリーズし、その後入力を受け付けない
Ctrl + Alt + End（リモート環境での Secure Attention Sequence 相当）が効かず、サインアウトやタスクマネージャーが出せない- 切断して再接続すると、Bastion は「接続が不安定」になりやすく、RDP は認証後に接続し続けるだけで入れない（黒画面・無限待機など）
- VM を作り直しても再現し、テナントが違っても起きることがある
| 症状 | 見える現象 | 示唆されること |
|---|---|---|
| ログイン直後に固まる | デスクトップは出るが UI が動かない | ネットワークよりも、ログオン後に動くプロセス（Shell / Explorer / Server Manager / ドライバー初期化）が怪しい |
| タスクバーが出ない | スタートや時計が表示されない | Explorer（シェル）が正常起動できていない、または起動中に I/O 待ちで固まっている可能性 |
| Bastion でも RDP でも同じ | 接続方法を変えても再現 | RDP 経路の問題ではなく、OS 側のハング／極端な遅延の可能性が高い |
| 再接続でさらに悪化 | RDP が認証後に入れない、Bastion が不安定表示 | OS が応答不能になり、セッション再作成が詰まっている可能性。接続方法の変更より VM 側の復旧が必要 |
結論から：追加データディスクや Host Caching が絡む既知不具合の可能性が高い
原因として有力なのは、VM に追加で接続しているディスク（データディスク）、または Azure 側のディスク設定であるHost Caching（ホスト キャッシュ）が絡んだ Windows Server 2025 側の不具合です。特に「新規作成直後」「初回ログイン直後」「Server Manager の起動タイミングで固まる」という条件が揃う場合、OS の初期化処理の中でストレージ待ちが発生し、その影響がシェル（Explorer）に波及して UI 全体が止まって見えるケースがあります。
ポイントは、ストレージの問題があるといっても、単純に「ディスクが壊れている」というより、特定の構成（ディスク + キャッシュ設定 + OS バージョン）でのみ起きるタイプの不具合である点です。そのため、最初から深追いしてイベントログ解析に入るより、最小の変更で切り分けできる手順から試すのが効率的です。
最短で原因を絞る：切り分けフロー
この問題は「触れない状態」になりやすいので、まずは Azure 側（ポータル操作だけ）で完結する切り分けを優先します。以下の順に進めると、短時間で原因を狭められます。
| 優先 | やること | 目的 | 期待する結果 | 次に進む判断 |
|---|---|---|---|---|
| 高 | 追加ディスクを切り離す | ディスク関連が原因か最短で判定 | 正常ログインできる | 改善したら Host Caching を調整して再接続を試す |
| 高 | Host Caching を None / Read-only へ変更 | 同じディスクでも設定差で回避できるか検証 | 再現しない構成が見つかる | 安定した設定で運用 → 性能要件があれば段階的に最適化 |
| 中 | 最小構成に戻して Windows Update を適用 | 既知問題の修正を取り込む | 更新後は安定する | 更新で直るなら恒久対策。直らなければ回避策（構成変更）を優先 |
| 中 | Windows Server 2025 release health を確認 | 既知の問題・回避策の有無を把握 | 該当の既知不具合が見つかる | 案内されている回避策・修正済み更新の適用へ |
| 低 | Windows Server 2022 に切り替える | 業務影響を止める現実的回避 | 安定運用できる | 稼働を優先。後日 Server 2025 の検証を再開する |
対処手順：追加データディスクをいったん切り離して起動・ログインを確認する
最優先で試すべき対処が、追加ディスク（データディスク）を VM から切り離す方法です。重要なのは、ここで行うのは「削除」ではなく切り離し（Detach）であり、ディスクそのものを残したまま VM 側から外す点です。
事前に確認しておきたい注意点
- ディスクを「削除」しない：VM 削除時にディスクも削除される設定（Delete with VM）が有効になっていないか確認する
- 運用データがある場合はスナップショットを取る：念のため、ディスクのスナップショット作成を検討する
- 可能なら VM を停止（割り当て解除）してから切り離す：整合性と作業の安全性のため
Azure ポータルでの切り離し手順（例）
- 対象 VM を開き、左メニューから ディスク を選択する
- データ ディスク セクションで、追加されているディスクを確認する
- VM を 停止（割り当て解除） できるなら実施する
- 該当のデータディスクを 切り離し（Detach） して保存する
- VM を起動し、Bastion / RDP のいずれかでログインして挙動を確認する
ここでタスクバーが正常に表示され、Server Manager も起動して操作できるようになれば、原因はほぼ「追加ディスク周り」に絞れます。逆に、追加ディスクを外しても同じ症状なら、OS 更新・機能（セキュリティ機能やドライバー）・VM サイズなど別軸の検証に進みます。
Azure CLI での切り離し（自動化したい場合）
ポータル操作が難しい環境や複数台で検証したい場合は、CLI でも同等の作業ができます。
# VM を停止（割り当て解除）
az vm deallocate -g <resource-group> -n <vm-name>
# データディスクを切り離す（LUN を指定）
az vm disk detach -g --vm-name --lun
# VM を起動
az vm start -g -n 切り離したディスクはリソースとして残るため、あとで同じ VM へ再接続したり、別 VM にアタッチして検証したりできます。
追加ディスクが必要な場合：Host Caching（ホスト キャッシュ）を見直す
追加ディスクを外すと改善するが、業務要件としてデータディスクが必須な場合は、次に Host Caching を見直します。Host Caching は Azure 側でディスク I/O を最適化するための機能ですが、ワークロードや OS / ドライバーとの組み合わせによっては相性問題が起きることがあります。
まずは検証として、キャッシュが有効になっている場合にRead-only（読み取り専用）へ変更、または None を試すのが定石です（最適値はワークロードに依存します）。
| Host Caching | 概要 | 向いているケース | 今回のトラブル観点での考え方 |
|---|---|---|---|
| None | ホスト キャッシュを使わない | 切り分けの第一候補。書き込みが多い一般的なデータディスク、アプリの作業領域など | まずは「固まらない」ことを優先するなら最初に試す価値が高い |
| Read-only | 読み取り中心のキャッシュ | 参照が多いデータ、配布コンテンツ、読み取り負荷が高いワークロード | キャッシュ有効で固まる場合、Read-only の方が安定するケースがある |
| Read/Write | 読み書きキャッシュ | 推奨構成が明確な用途（例：OS ディスクなど） | まずは切り分けとして避け、必要になってから検証するのが安全 |
Host Caching の変更手順（Azure ポータル）
- VM の ディスク を開き、対象のデータディスクを選ぶ
- Host Caching を Read-only または None に変更する
- 保存後、VM を再起動してログイン挙動を確認する
この段階では「性能を最大化」よりも、まず安定してログインできる構成を作ることが目的です。安定したら、負荷試験をしながら最適なキャッシュ設定に寄せていきます。
ログイン後に固まる理由：Shell がディスク列挙で詰まることがある
「ディスクが原因でタスクバーが出ない」というと意外に感じるかもしれません。しかし Windows のログオン後は、Explorer（シェル）や Server Manager を含む複数のプロセスが、ドライブ一覧・ボリューム情報・ストレージの状態を参照します。もしデータディスクの初期化や応答に問題があると、UI が直接エラーを出さずに待ち続ける形になり、結果として「画面が固まった」ように見えます。
特に Azure VM では、同じ “ディスク” に見えても、裏側のストレージ経路（ドライバー、キャッシュ、ホスト側最適化）が複数あります。Windows Server 2025 の更新状況によっては、特定構成だけが初回ログオンのタイミングで詰まることが起き得ます。
既知の問題の確認：Windows Server 2025 release health をチェックする
切り分けができたら、次にやるべきは「既知の問題として扱われていないか」を確認することです。Microsoft は Windows のバージョンごとに、既知の問題と解決状況をまとめたページ（release health）を公開しており、フリーズ・RDP・シェル周りの不具合が掲載されることがあります。
- 「Windows Server 2025 release health（既知の問題と解決状況）」で、該当しそうな症状がないか探す
- 回避策が提示されている場合は、まずその回避策を優先して適用する
- 「修正済み」とされている場合は、修正が含まれる更新プログラムが VM に入っているかを確認する
release health は更新頻度が高いので、検証環境でも本番環境でも、Server 2025 を使うなら定期的に確認する運用が安全です。
運用のコツ：最小構成→更新適用→追加ディスク接続の順にする
Server 2025 を採用する場合、最初からディスクや拡張機能を盛るよりも、次の順番が安全です。
- OS だけの最小構成（OS ディスクのみ）で VM を作成し、初回ログインの安定性を確認する
- Windows Update（累積更新）を適用し、再起動を挟んで状態を安定させる
- 必要に応じて Azure VM Agent など関連コンポーネントも最新化する
- 最後にデータディスクを接続し、Host Caching をワークロードに合わせて設定する
この流れにしておくと、もし不具合があっても「どの段階で壊れたか」が明確になり、切り戻しも簡単です。特に今回のような「初回ログイン直後にフリーズ」は、最小構成に戻せれば復旧が早いです。
ログインできるようになった後にやっておくと安心な確認
ディスクを外した／キャッシュ設定を変えた結果、ログインできるようになったら、再発防止のために次の確認をしておくと安心です。
- データディスクを再接続する前に、Windows Update を一通り適用して再起動を完了させる
- データディスクを再接続する場合は、Host Caching を None（または Read-only）から始め、段階的に最適化する
- 接続直後はディスク初期化やスキャンで I/O が増えるため、初回は余裕をもって作業する
ログイン後にディスク状態を軽く確認したい場合は、PowerShell で物理ディスクやボリュームの見え方をチェックできます。
# ディスクとパーティションの一覧
Get-Disk | Sort-Object Number | Format-Table Number,FriendlyName,PartitionStyle,OperationalStatus,Size -Auto
# ボリュームの一覧（ドライブ文字・ファイルシステム）
Get-Volume | Sort-Object DriveLetter | Format-Table DriveLetter,FileSystemLabel,FileSystem,HealthStatus,SizeRemaining,Size -Autoそれでも操作不能になる場合の現実的な救済策
フリーズが激しいと、VM 内での対処（タスクマネージャー起動、Explorer 再起動など）にたどり着けません。そこで、Azure 側から打てる手を用意しておくと復旧が楽になります。
- ディスク切り離しは VM に入れなくてもできる：まずは停止（割り当て解除）→ データディスク detach を試す
- 再デプロイ（Redeploy）：ホスト側の問題が疑わしい時の切り分けとして有効な場合がある
- RDP 設定のリセット：ログイン後フリーズとは別軸だが、接続不能が混ざったときに切り分けが楽になる
- ブート診断・シリアル コンソール：OS が不安定でもログを見られる可能性がある（事前に有効化しておくと安心）
ただし、今回の問題に限っては「接続系の復旧」よりも、まずディスク周りの構成を軽くすることが改善に直結しやすいです。
業務影響が大きい場合：Windows Server 2022 へ切り替える判断
「Server 2025 である必要が薄い」「原因究明に時間をかけられない」「まずはサービス稼働が最優先」という状況なら、Windows Server 2022 への切り替え（ダウングレード）が最も現実的な回避策です。実運用では、安定稼働させた後に Server 2025 へ再挑戦する方が、結果的にトータル工数が減ることも少なくありません。
| 選択肢 | メリット | デメリット | 向いているケース |
|---|---|---|---|
| Server 2025 を継続 | 新機能・将来性。長期的には移行回数が減る | 既知不具合の影響を受ける可能性。検証コストが増える | Server 2025 固有の要件がある／検証環境がある |
| Server 2022 に切り替え | 枯れていて安定。トラブルシューティング情報が豊富 | 将来 Server 2025 へ移行する作業が別途必要 | 稼働優先／短期で安定させたい／まずは標準構成で動かしたい |
再発防止：Windows Server 2025 Azure VM を作るときのチェックリスト
同じ現象に何度もハマらないために、VM 作成時のチェックポイントをまとめます。特に複数テナントや複数サブスクリプションで検証する場合、構成差分が埋もれやすいので、最初から「記録して比較できる形」にしておくと強いです。
| 項目 | 推奨 | 理由 |
|---|---|---|
| 初期構成 | OS ディスクのみで作成 → ログイン確認 | OS 単体での安定性をまず確保し、原因切り分けを簡単にする |
| データディスク | ログイン確認後に追加で接続 | 初回ログオン直後のフリーズに巻き込まれにくい |
| Host Caching | 迷ったら None から | 相性問題の切り分けがしやすい。必要なら Read-only を段階的に試す |
| 更新適用 | 作成直後に Windows Update → 再起動 | 既知不具合が修正されている可能性がある。検証の前提を揃えられる |
| テンプレート化 | ARM / Bicep / Terraform で構成を固定 | 「同じはずなのに違う」を防ぎ、再現性のある検証ができる |
Microsoft / Azure サポートへ相談する場合に用意すると早い情報
サポートに問い合わせる場合は、「何が起きたか」だけでなく「どの構成で起きたか」を揃えると、やり取りが短くなります。以下の項目をメモしておくのがおすすめです。
| 情報 | 例 | なぜ必要か |
|---|---|---|
| OS イメージ | Windows Server 2025 の SKU / バージョン | 特定ビルドや更新の組み合わせでのみ起きる不具合があるため |
| VM サイズ | D 系 / E 系 など | 基盤やドライバー経路が変わることがあるため |
| ディスク構成 | OS ディスク種別、データディスク数、LUN、サイズ | 追加ディスク・キャッシュ設定が原因候補になるため |
| Host Caching 設定 | None / Read-only / Read/Write | 再現条件の核になりやすい |
| 再現手順 | 「作成→ディスク追加→初回ログインで固まる」など | 切り分けが一気に進む |
本件のような「Windows Server 2025 の新規 Azure VM が初回ログイン直後に固まって操作不能」問題は、入口の切り分けさえ押さえれば短時間で回避策に到達できます。まずは追加データディスクの切り離しで安定性を確認し、必要なら Host Caching の調整と更新適用を組み合わせ、業務優先なら Server 2022 への切り替えも選択肢に入れて進めるのが現実的です。
コメント