Windows Server 2019 フェールオーバークラスターで「The remote server has been paused or is in the process of being started」ClusterSharingPaused が出て全コマンドレット失敗する原因と再構築手順

Windows Server 2019 のフェールオーバークラスターで、突然すべてのクラスター系コマンドレットが失敗し「The remote server has been paused or is in the process of being started.（ClusterSharingPaused）」が出続ける場合、単なる WMI 障害ではなくクォーラム喪失やクラスター構成の破綻が疑われます。本記事では症状の読み解き方と、実際に復旧できた“解体→再構築”手順を具体的にまとめます。

現象：すべてのクラスター関連コマンドレットが失敗する

問題の特徴は、PowerShell からの操作だけでなく、WMI（ROOT\MSCluster）経由の参照までまとめて失敗する点です。代表的には次のような状態になります。

Get-ClusterNode、Stop-Cluster、Remove-Cluster など、クラスター関連のコマンドレットが軒並み失敗する
エラーが FullyQualifiedErrorId : ClusterSharingPaused となり、本文に「The remote server has been paused or is in the process of being started.」が出る
Get-WmiObject -Namespace "ROOT\MSCluster" など WMI 経由でも同じエラーで落ちる
Start-Cluster や Start-ClusterNode -FQ（ForceQuorum）を試しても、一瞬 Joining になってすぐ落ちる

見えているエラー	裏で起きていること（典型）	起きる影響
The remote server has been paused or is in the process of being started.	クラスターサービス（clussvc）が「完全に開始できない／一時停止扱い」のまま管理 API を受け付けない	PowerShell／WMI のどちらからも管理操作できず、切り分けが極端に難しくなる
ClusterSharingPaused	クォーラム喪失や内部データベース不整合などにより、クラスターの共有状態が “Paused” として扱われている	コマンドレットが連鎖的に失敗し、`Remove-Cluster` すら実行できない場合がある

今回のような環境で「壊れ方」が深刻化しやすい理由

本件は Windows Server 2019 の新規フェールオーバークラスター（4 ノード）で、S2D（Storage Spaces Direct）＋CSV を使っている構成が想定されます。さらに管理ポイントが分散ネットワーク名（DNN）で、クォーラムはファイル共有 Witness（複数の共有を用意）という前提です。

この組み合わせでは、どれか 1 つの要素が崩れると“クラスターサービスが完全に立ち上がらない”状態に入りやすく、結果として管理コマンドが全滅します。

クォーラム喪失：ハートビート断続・ノード間通信不安定・Witness 到達不可が重なると、クラスターが「自分が正当な多数派か」を判断できず停止に寄る
DNN／AD／DNS の絡み：DNN のコンピューターオブジェクト（クラスター名）が DNS を更新できないと、名前解決が揺らぎ、管理やクライアント接続が崩れる
ネットワークの二重化：10GbE×2 のクラスター専用ネットワークと、別帯域のクライアント専用ネットワークがあり、役割・メトリック・VLAN・MTU が不整合だと、断続的なハートビート喪失が起きる
“Microsoft Failover Cluster Virtual Adapter” の不整合：ノード間で仮想アダプターの状態が揃っていない、リネームが失敗する等は、ネットワークスタック／ドライバ／チーミング設定の差異のサインになり得る

イベントログの読み方：クラスターが「不安定／破綻した」サイン

質問環境では、初期にイベント ID 1237 が多数発生し、DNN のコンピューターオブジェクトへ「IP アドレスの動的更新」権限を付与したことで解消したとのことです。その数時間後に 4 ノードすべてがクラスターから落ち、以降は 1092 / 1146 / 1573 / 5398 / 1070 などが多数発生しています。

イベント ID の詳細メッセージは環境差がありますが、次のように“方向性”を掴むと復旧方針を決めやすくなります。

イベントの傾向	意味合い（読み取り）	次に疑うポイント
ハートビート喪失／復旧が短時間で大量	ノード間通信が断続的に切れている（物理／論理のどちらでも）	VLAN/MTU/ルーティング/チーミング/LACP/スイッチ設定、RDMA、ドライバ差異、同一セグメントか
クォーラム喪失・仲裁関連のイベントが繰り返し	多数派判定に失敗し、クラスターが自律停止に寄っている	Witness への到達性（DNS/SMB/権限）、時刻同期、サイト間遅延、ノードの再起動順序
名前解決・登録（DNN / DNS）由来のエラー	管理ポイントの登録・更新ができず、管理や接続が不安定になりやすい	AD 側の事前ステージ、DNS の動的更新権限、古い A レコード/重複登録
clussvc の開始失敗やサービス強制停止に近い挙動	クラスターサービスが正常起動できず“Paused/Starting”状態から抜けられない	クラスター構成情報の不整合、内部 DB 破損、ストレージ／CSV／S2D の初期化失敗

なぜ WMI リセットやファイアウォール調整では直らないのか

この症状でよくある落とし穴は「PowerShell が落ちる＝WMI が壊れた」と考えてしまうことです。実際には逆で、WMI は“クラスターサービスが管理 API を返せない状態”を正しく報告しているだけ、というケースが多いです。

そのため、次の対処は“効くこともあるが、クラスター自体が破綻していると効かない”代表例です。

WMI/DCOM 関連のファイアウォールルールを有効化
winmgmt /resetRepository による WMI リポジトリリセット

クラスターサービスが起動できない／クォーラム確立に失敗している状態では、WMI を直してもクラスター管理は戻りません。根が深い場合は、クラスターを一度“解体”して健全な構成を作り直すほうが速く確実です。

最初の切り分け：クラスターコマンドが使えないときに確認する項目

コマンドレットが全滅している状況でも、OS 標準のサービス確認やイベントログ参照は実行できます。復旧・再構築の判断材料として、まず次を確認します（必要ならスクリーンショットやログとして保存します）。

確認対象	使うコマンド例	見え方の例	読み取り
clussvc の状態	`Get-Service clussvc` `sc query clussvc`	Running / Stopped / StartPending	StartPending が長い、または起動直後に落ちるなら、クォーラムや構成不整合で起動フェーズで詰まっている可能性が高い
Failover Clustering のイベント	`Get-WinEvent -LogName Microsoft-Windows-FailoverClustering/Operational -MaxEvents 200`	ハートビート喪失、仲裁失敗、名前登録失敗などが連続	ネットワーク断続やクォーラム揺れが主因か、AD/DNS の登録問題が主因かの当たりを付けられる
ノード間通信（クラスター用 NIC）	`Test-Connection <相手ノードのクラスター用IP>` `ping -S <自ノードのクラスター用IP> <相手IP>`	断続的にタイムアウトする	“たまに落ちる”が最も危険。スイッチ設定、VLAN、MTU、LACP、ドライバ差異などを疑う
Witness 共有への到達性	`Test-Path \\server\witness$` `New-Item \\server\witness$\health.txt -ItemType File`	参照はできるが作成ができない／認証が失敗する	共有権限または NTFS 権限、あるいは資格情報の問題。ここが揺れるとクォーラムが不安定になる
DNS の名前解決	`Resolve-DnsName myCluster`	古い IP が返る／複数レコードが混在する	DNN の登録不整合や、古い A レコードの残骸が疑われる
時刻同期	`w32tm /query /status`	大きなズレや同期エラー	Kerberos 認証や SMB 接続で失敗が出やすく、Witness 到達やクラスター参加に影響する

ここで「ノード間通信が断続的に不安定」「Witness 共有への書き込みが不安定」「DNS が揺れている」のいずれかが見えた場合、ForceQuorum の成功率は下がりがちです。短時間で復旧させる必要があるなら、次章の“解体→再構築”が現実的な選択になります。

作業前の準備：やってはいけないこと／残すべき情報

以降に紹介する「解体→再構築」は強力ですが、元に戻せない操作が含まれます。最低限、次を先に揃えます。

CSV 上のデータバックアップ（スナップショットだけに頼らず、復元手順も確認）
旧クラスターの設計メモ（ネットワークの用途、VLAN、MTU、優先順、Witness パス、共有名、アクセス権）
AD/DNS 側で触るオブジェクト名（クラスター DNN、CAU 用アカウント、DNS レコード）
ストレージの種類の確認（S2D か、共有ストレージ／iSCSI か）

確認項目	目安	メモする例
クラスター名（DNN）	AD コンピューターオブジェクト名と DNS 名が一致している	myCluster
Witness	実際に使用する共有は 1 つ（予備を用意するのは可）	\\myQuorumShareMachine\witness$
クラスター通信ネットワーク	用途（Cluster Only / Client Only）が明確で、ノード間で同一	10GbE×2：クラスタ用、2GbE Team：クライアント用
S2D/CSV のボリューム名と共有名	再作成後に同名に戻せるよう控える	CSV 名、SMB 共有名、ACL

根本対処：クラスターを「解体」して再構築する手順

受け入れられた解決策は、クラスター構成をきれいに削除し、AD オブジェクトも含めて再作成する方法です。ポイントは「壊れたクラスターに対して Remove-Cluster を頑張る」のではなく、各ノードをクラスター参加状態から切り離してフラットに戻すことです。

各ノードからフェールオーバークラスター機能を削除して入れ直す

管理用サーバーから PowerShell リモートで一括作業する前提の例です。ドメイン環境なら Kerberos を使うのが基本ですが、状況によっては TrustedHosts が必要になることがあります。運用ポリシーに合わせて実施してください。

# 各ノード側（事前設定例）
Set-Item WSMan:\localhost\Client\TrustedHosts -Concatenate -Value "管理サーバー名"
Enable-PSRemoting -Force

管理サーバーから 4 ノードへ、クラスター機能を削除→再インストールします。

# 管理サーバー側
Invoke-Command -ComputerName one,two,three,four {
    Remove-WindowsFeature Failover-Clustering -Restart
}

Invoke-Command -ComputerName one,two,three,four {
    Install-WindowsFeature Failover-Clustering -IncludeManagementTools -Restart
}

再起動後、ノードに残ったクラスター参加情報をクリアします。

Invoke-Command -ComputerName one,two,three,four {
    Clear-ClusterNode
}

この段階で狙っているのは次の状態です。

各ノードが「過去に所属していたクラスターの残骸」から切り離される
clussvc の起動失敗を引きずる前提が消え、再作成に移れる

AD / DNS 上のクラスター関連オブジェクトを整理する

DNN 構成のクラスターでは、AD 上のクラスター名（DNN）のコンピューターオブジェクトや、CAU 用のコンピューターオブジェクトが絡みます。壊れた状態のまま残すと、DNS レコードの更新失敗や重複で再作成が不安定になります。

Active Directory ユーザーとコンピューター（dsa.msc）で、クラスター DNN のコンピューターアカウントを一度削除する
同名で再作成し、無効化した状態にしておく（事前ステージ）
CAU 用（例：myCluster-CAU）のコンピューターアカウントも必要に応じて削除／再作成する
DNS 側に古い A レコードや重複登録が残っていないか確認し、必要ならクリーンアップする

さらに、AD/DNS 管理者に依頼して、再作成した DNN オブジェクトに DNS 更新に必要な権限を付与します（環境によって呼び方は異なりますが、質問環境では「IP アドレスの動的更新」の権限付与で改善しています）。

クォーラム用ファイル共有サーバーでは、共有と NTFS の両方でクラスター名（myCluster）に書き込み権限を付与します。

対象	実施内容	つまずきやすい点
AD（クラスター DNN）	削除→再作成（無効化）→DNS 更新に必要な権限を付与	古いオブジェクトが残ると再作成時に衝突しやすい
AD（CAU 用）	myCluster-CAU などを削除／再作成	CAU ロール追加時に VCO 作成で失敗することがある
DNS	古い A レコード／重複登録を整理	レコードが残ると名前解決が揺らぎ、参加や管理が不安定になる
Witness 共有	共有・NTFS ともにクラスター名へ書き込み権限	共有権限だけ／NTFS だけ付けて片手落ちになりやすい

クラスターを新規作成する（DNN）

ノードがフラットになり、AD/DNS/Witness が整理できたら、クラスターを作り直します。DNN で構成する例です。

New-Cluster `
  -Name myCluster `
  -Node one,two,three,four `
  -NoStorage `
  -IgnoreNetwork "192.168.0.0/24","192.168.1.0/24" `
  -ManagementPointNetworkType Distributed

-IgnoreNetwork は「管理 NIC として使わないネットワーク」を除外するための例です。ここを誤ると、意図しないネットワークでクラスター管理が動き、後々のトラブルになります。作成前に各ノードの IP 帯を棚卸しし、“クラスター通信に使う帯域”と“使わない帯域”を明確にしておきます。

CAU ロールの追加とクォーラム設定

必要に応じて CAU（Cluster Aware Updating）ロールを追加します。

Add-CauClusterRole `
  -DaysOfWeek Saturday `
  -WeeksOfMonth 1 `
  -RequireAllNodesOnline `
  -MaxFailedNodes 1 `
  -EnableFirewallRules `
  -CauPluginName Microsoft.WindowsUpdatePlugin `
  -VirtualComputerObjectName myCluster-CAU `
  -GroupName myCluster-CAU

続いてクォーラムをファイル共有 Witness に設定します。共有を複数用意していても、クラスターが同時に使う Witness は基本的に 1 つです（切り替え用の予備として管理するのは有効です）。

Set-ClusterQuorum `
  -FileShareWitness \\myQuorumShareMachine\witness$ `
  -Credential (Get-Credential)

クラスターネットワークの役割を揃える

ネットワークの役割が曖昧なままだと、ハートビート断続→クォーラム揺れ→クラスター不安定の温床になります。再構築後は早い段階で役割を確定させます。

Get-ClusterNetwork | Format-Table Name, Address, Role

Role は値で制御されます（一般的な意味合いは次のとおり）。

Role 値	意味	用途の例
0	None（クラスターでは使わない）	クライアント専用ネットワーク、バックアップ専用など
1	Cluster Only（クラスター内部通信のみ）	10GbE のハートビート／CSV／S2D 通信用
3	Cluster and Client（両方）	クライアントアクセスもこのネットワークで受ける設計の場合

例として、10GbE×2 をクラスター専用、クライアント用 NIC チームはクラスター通信に使わない（None）とするなら次のように設定します。

(Get-ClusterNetwork "Cluster Network 1").Role = 1
(Get-ClusterNetwork "Cluster Network 2").Role = 1
(Get-ClusterNetwork "Cluster Network 3").Role = 0

ストレージ／CSV の再登録（S2D と共有ストレージで考え方が違う）

ここは環境差が出やすい部分です。S2D（Storage Spaces Direct）では「ディスクをクラスターに追加して CSV 化する」よりも、S2D の有効化やボリューム再作成の手順が主体になります。一方、共有ストレージ（SAN/iSCSI 等）では、未割り当てディスクの追加→CSV 変換が基本です。

質問環境の例としては、クラスターが認識している未割り当てディスクを追加し、CSV に変換する流れが紹介されています。

Get-ClusterAvailableDisk | Add-ClusterDisk

Get-ClusterResource |
  Where-Object { $_.OwnerGroup -eq "Available Storage" -and $_.Name -ne "Cluster Virtual Disk (ClusterPerformanceHistory)" } |
  Add-ClusterSharedVolume

また、旧環境の名残として次のような“掃除対象”が出ることがあります。

Performance History 用のディスク（Cluster Virtual Disk (ClusterPerformanceHistory)）の扱いが中途半端に残る
SID/GUID 名のまま残っている Cluster Group や Virtual Disk があり、管理上わかりにくい
クラスター名リソースの表示名が期待と異なる

CSV の論理名を元の名前に戻す例です。

Get-ClusterSharedVolume | Format-Table Name, SharedVolumeInfo

# 必要に応じて論理名を変更
(Get-ClusterSharedVolume "Cluster Disk 1").Name = "Cluster Virtual Disk (元のボリューム名)"

その後、各 CSV に対して元どおりの SMB 共有名・アクセス権で共有を作り直します。共有名がアプリケーション側で固定参照されている場合は、ここを揃えることが復旧の肝になります。

代替案：/fixquorum で復旧できる場合もある

クラスターの規模や状況によっては、再構築まではせずにクォーラムを修復して復旧できることがあります。小規模（例：2 ノードの検証環境）で、ハートビート喪失やクォーラム破損が主因のときに選択肢になります。

片方のノード（例：node2）をシャットダウンする
残ったノード（node1）でクラスターサービスを /fixquorum 付きで起動する

net stop clussvc
net start clussvc /fixquorum

その後、シャットダウンしていたノードを起動し直す

ただし、4 ノード＋Witness＋S2D のように要素が多い構成では、/fixquorum を使ってもクラスターがすぐ落ちることがあります。ForceQuorum で一瞬 Joining になるが維持できない場合は、クォーラムだけでなくネットワークや構成情報の不整合が残っている可能性が高く、再構築のほうが現実的です。

再発防止：次に同じ“全コマンドレット死亡”を起こさないために

一度こうした状態に入ると、切り分けより“復旧・再構築”が主戦場になります。再発防止として、次を設計・運用に組み込むと効果があります。

クォーラムと Witness の健全性を定期点検する

Witness 共有は、DNS 解決・SMB 到達・権限（共有＋NTFS）の 3 点をセットで確認する
共有サーバー側の監査ログやイベントログも確認し、認証失敗が出ていないかを見る
複数の Witness を用意する場合は「切替手順」を文書化し、同時併用しない

クラスター通信ネットワークを“揃える”

ノード間で NIC ドライバ／ファームウェア／チーミング方式（LACP など）を統一する
MTU（ジャンボフレーム）、VLAN、QoS、RDMA の有無をノード間で一致させる
クライアント用ネットワークをクラスター通信に混ぜない（Role=0 を徹底する等）

AD/DNS（DNN）を“事前ステージ”前提で運用する

DNN のコンピューターオブジェクトは、作成者・権限・DNS 更新権限を明確にし、変更履歴を残す
DNS に古いレコードが残る運用（手動登録や、誤った動的更新）を避ける

“壊れたときの逃げ道”を用意する

クラスター構成のバックアップ（手順書）を整備し、再構築で戻せる粒度にする
CSV 名、共有名、ACL、アプリの参照先を台帳化しておく
検証環境で /fixquorum や ForceQuorum の動作確認をしておく

よくある質問

Q. Remove-Cluster すら実行できません。どうやって“解体”しますか？
A. 管理コマンドが全滅している状態では、壊れたクラスターに対して Remove-Cluster を通そうとしても詰みやすいです。各ノードで Failover-Clustering 機能を削除→再インストールし、Clear-ClusterNode で参加情報を消してから、新規に New-Cluster で作り直すほうが確実です。

Q. WMI を直したのに PowerShell が直りません。
A. WMI が原因ではなく、クラスターサービスが “Paused/Starting” のまま管理 API を返せない可能性が高いです。イベントログで clussvc の起動失敗やクォーラム関連イベントが出ているなら、クォーラム／ネットワーク／AD/DNS を含めて全体を疑う必要があります。

Q. DNN なのに「IP アドレスの動的更新」権限が関係するのはなぜ？
A. DNN は従来の「クラスター名＋固定 IP」の作りとは違いますが、DNS 上ではクラスター名が解決できる必要があります。AD/DNS の権限不足で DNS 登録や更新が失敗すると、管理や接続が不安定になり、クォーラムや参加処理の不具合を誘発することがあります。

「The remote server has been paused or is in the process of being started. / ClusterSharingPaused」で全コマンドレットが失敗する状況は、クラスターが“立ち上がっていない”サインです。小手先の WMI 修復で直らないときは、ノードをフラットに戻し、AD/DNS/Witness を整理してクラスターを再作成する手順が最短ルートになります。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Windows Server 2019 フェールオーバークラスターで「The remote server has been paused or is in the process of being started」ClusterSharingPaused が出て全コマンドレット失敗する原因と再構築手順

現象：すべてのクラスター関連コマンドレットが失敗する

今回のような環境で「壊れ方」が深刻化しやすい理由

イベントログの読み方：クラスターが「不安定／破綻した」サイン

なぜ WMI リセットやファイアウォール調整では直らないのか

最初の切り分け：クラスターコマンドが使えないときに確認する項目

作業前の準備：やってはいけないこと／残すべき情報

根本対処：クラスターを「解体」して再構築する手順

各ノードからフェールオーバークラスター機能を削除して入れ直す

AD / DNS 上のクラスター関連オブジェクトを整理する

クラスターを新規作成する（DNN）

CAU ロールの追加とクォーラム設定

クラスターネットワークの役割を揃える

ストレージ／CSV の再登録（S2D と共有ストレージで考え方が違う）

代替案：/fixquorum で復旧できる場合もある

再発防止：次に同じ“全コマンドレット死亡”を起こさないために

クォーラムと Witness の健全性を定期点検する

クラスター通信ネットワークを“揃える”

AD/DNS（DNN）を“事前ステージ”前提で運用する

“壊れたときの逃げ道”を用意する

よくある質問

この記事を書いた人

コメント

コメントするコメントをキャンセル

Windows Server 2019 フェールオーバークラスターで「The remote server has been paused or is in the process of being started」ClusterSharingPaused が出て全コマンドレット失敗する原因と再構築手順

現象：すべてのクラスター関連コマンドレットが失敗する

今回のような環境で「壊れ方」が深刻化しやすい理由

イベントログの読み方：クラスターが「不安定／破綻した」サイン

なぜ WMI リセットやファイアウォール調整では直らないのか

最初の切り分け：クラスターコマンドが使えないときに確認する項目

作業前の準備：やってはいけないこと／残すべき情報

根本対処：クラスターを「解体」して再構築する手順

各ノードからフェールオーバークラスター機能を削除して入れ直す

AD / DNS 上のクラスター関連オブジェクトを整理する

クラスターを新規作成する（DNN）

CAU ロールの追加とクォーラム設定

クラスターネットワークの役割を揃える

ストレージ／CSV の再登録（S2D と共有ストレージで考え方が違う）

代替案：/fixquorum で復旧できる場合もある

再発防止：次に同じ“全コマンドレット死亡”を起こさないために

クォーラムと Witness の健全性を定期点検する

クラスター通信ネットワークを“揃える”

AD/DNS（DNN）を“事前ステージ”前提で運用する

“壊れたときの逃げ道”を用意する

よくある質問

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル