Exchange Server 2010 から Microsoft 365（Exchange Online）へ移行した後、オンプレ Exchange に管理接続できず「WinRM の content-type エラー」で詰まるケースがあります。本記事では、原因の見極め方と、正しいURL/ポートに接続し直す具体手順をまとめます。
Exchange 2010→Microsoft 365 移行後に発生しがちな「WinRM content-type エラー」とは
移行後、オンプレ Exchange へ PowerShell で接続しようとすると、次のようなエラーが出て管理ができなくなることがあります。
WinRM Client could not process the request.
It cannot determine the content type of the HTTP response from the destination computer.
The content type is 'text/html; charset=utf-8'.ポイントは、WinRM（WSMan）が期待している“管理用の応答”ではなく、HTML（ログイン画面やエラーページなど）を受け取っていることです。つまり、認証方式や Exchange 側の機能有効化に目が行きがちですが、根っこは「接続先がズレている」パターンが非常に多いです。
なぜ移行後に起きやすいのか
Exchange 2010 から Microsoft 365 に移行すると、次のような“入口”の変更が発生しがちです。
- 外部公開名（例：mail.contoso.com、autodiscover.contoso.com）が Microsoft 365 側に向く
- リバースプロキシ／WAF／ロードバランサの設定が変更され、意図せず別の応答が返る
- 管理者が「これまで使っていたURL」をそのまま使い続け、実は Exchange Online へ到達している
- オンプレ側の管理用ポート（5985/5986）が閉じられ、80/443 など“別サービスの入口”に当たってしまう
結果として、WinRM は“WSMan のSOAP応答”を待っているのに、実際には Web サーバーの HTML（サインイン画面、404、プロキシのブロックページ等）を受け取り、content-type で弾かれます。
まず整理：WinRM/WSMan と Exchange Remote PowerShell は「似て非なる入口」
「WinRM で繋ぐ」「Remote PowerShell で繋ぐ」は混同されやすいのですが、用途と入口が違います。ここを整理すると、原因の切り分けが一気に早くなります。
| 項目 | WinRM/WSMan（一般的なPowerShellリモート） | Exchange Remote PowerShell（Exchange管理用） |
|---|---|---|
| 目的 | Windows サーバーの汎用リモート管理 | Exchange 管理コマンド（Get-Mailbox など）を実行 |
| 主な接続先 | 5985(HTTP) / 5986(HTTPS) の WSMan | http(s)://サーバー/PowerShell/（Exchange仮想ディレクトリ） |
| 代表的なコマンド | Test-WSMan / Enter-PSSession / New-PSSession（汎用） | New-PSSession -ConfigurationName Microsoft.Exchange → Import-PSSession |
| よくある誤り | ポート未指定で80に当たる、プロキシのHTMLを掴む | URLが Microsoft 365 側を向く、/PowerShell/ 以外に当たる |
結論として、Exchange の管理が目的なら Exchange Remote PowerShell の流儀（New-PSSession → Import-PSSession） へ寄せた方が事故りにくいです。一方で、WinRM そのものが壊れている／ポートが閉じているのかを確認するには、WSMan 側のテストが近道です。
原因の本質：WinRM が「WSMan ではない応答（HTMLなど）」を掴んでいる
content-type エラーは、ざっくり言うと次の状態です。
- あなた：WSMan で話したい（WinRM の応答が欲しい）
- 相手：Webページ（HTML）を返してくる、または別の中継装置が HTML を返す
- 結果：WinRM が「期待した content-type じゃない」と終了
特に移行後に多いのは、“サーバー名は合っているように見えるが、ポート・パス・名前解決のどれかがズレて別サービスに到達している”パターンです。
| 返ってきがちな content-type / 兆候 | 実際に起きていること | 典型的な原因 |
|---|---|---|
| text/html | ログイン画面・エラーページ・プロキシのブロックページ | ポート80/443へ到達、/wsman ではなくトップへ到達、プロキシ介在 |
| 302/301 リダイレクト | 別URLへ転送され、その先がHTML | http→https 強制、公開URL変更、リバプロ設定 |
| 401/403 | 認証・許可で拒否 | 認証方式不一致、アクセス制御、SSL必須、NWセグメント制限 |
| タイムアウト | 到達できていない | Firewall、ルーティング、名前解決、NAT、ポート閉塞 |
最短で直すための切り分け手順
この問題は、闇雲に Kerberos やモジュールを触るより、「どこに当たって、何が返ってきているか」を先に確定させると一気に進みます。以下の順で確認してください。
クライアント側：まず “今どこへ繋いでいるか” を可視化する
PowerShell を実行する端末（管理端末）で、次を試します。ポイントは ポートとパスを明示することです。
WSMan（WinRM）として正しい入口を叩く（HTTP 5985）
# 推奨：ComputerName + Port で明示
Test-WSMan -ComputerName EXCH2010-CAS01 -Port 5985
# ConnectionURI を使う場合は /wsman を明示（重要）
Test-WSMan -ConnectionURI [http://EXCH2010-CAS01:5985/wsman](http://EXCH2010-CAS01:5985/wsman)HTTPS（5986）を使っている場合
Test-WSMan -ComputerName EXCH2010-CAS01 -UseSSL -Port 5986ここで失敗する場合、次に “何が返ってきているか” を見ます。WinRM は中身を見せずに落ちることがあるため、HTTP として覗くのが有効です。
# 返却ヘッダやステータスを確認（HTMLを掴んでいないか）
Invoke-WebRequest -Uri http://EXCH2010-CAS01:5985/wsman -UseBasicParsing |
Select-Object StatusCode, StatusDescription, Headers
# もし外部公開名を使っているなら、そのURLも確認（移行後に別物へ到達していないか）
Invoke-WebRequest -Uri https://mail.contoso.com/ -UseBasicParsing |
Select-Object StatusCode, Headers結果が text/html だったり、サインイン画面っぽい内容が返ってきたり、302 で別の場所へ飛ばされているなら、WinRM の入口ではなく“Web”の入口に当たっています。この時点で、認証方式云々より先に「URL/ポート/名前解決」の是正が必要です。
サーバー側：WSMan のリスナー（待受ポート）を確認する
オンプレ Exchange サーバー（または接続対象サーバー）側で、WSMan のリスナー設定を確認します。一般的には 5985（HTTP）か 5986（HTTPS）で待ち受けます。
# リスナー一覧（HTTP/HTTPS、Port、アドレスを確認）
Get-WSManInstance -ResourceURI winrm/config/listener -Enumerate
# サービス状態確認
Get-Service WinRM
# 最低限の構成（既に有効なら変更は少ないが、状態確認として有効）
winrm quickconfig確認ポイントは次のとおりです。
- Listener が存在するか（HTTP/HTTPS が1つ以上）
- Port が 5985/5986 になっているか（環境によってカスタムもある）
- HTTPS の場合、CertificateThumbprint が設定されているか
- WinRM サービスが起動しているか
また、実際にポートが LISTEN しているかを OS レベルで見ると早いです。
# PowerShell例
Get-NetTCPConnection -LocalPort 5985,5986 -State Listen
# コマンドプロンプト例
netstat -ano | findstr ":5985"
netstat -ano | findstr ":5986"クライアント側は「正しいポート」を明示して接続する
content-type エラーの典型は、ポート未指定で 80/443 に行ってしまい、IISや別サービスのHTMLを掴むケースです。必ずポートを明示し、可能なら /wsman まで明示します。
| 目的 | 推奨例 | 狙い |
|---|---|---|
| WinRM疎通確認（HTTP） | Test-WSMan -ComputerName EXCH2010-CAS01 -Port 5985 | 5985に確実に到達させる |
| WinRM疎通確認（HTTPS） | Test-WSMan -ComputerName EXCH2010-CAS01 -UseSSL -Port 5986 | 暗号化＆TrustedHosts回避にも有効 |
| ConnectionURIで指定する場合 | Test-WSMan -ConnectionURI http://EXCH2010-CAS01:5985/wsman | パス誤りを防ぐ |
Exchange 管理が目的なら「Remote PowerShell の流儀」で接続する
WinRM の確認は重要ですが、Exchange の管理（受信者・設定・コネクタ等）をやりたいなら、最終的には Exchange Remote PowerShell（Microsoft.Exchange エンドポイント）として接続する方が自然です。
Exchange 管理の基本形は次です。
# 例：ドメイン参加済み端末から、CAS（推奨）へ接続
$cred = Get-Credential
$session = New-PSSession ` -ConfigurationName Microsoft.Exchange`
-ConnectionUri [http://EXCH2010-CAS01/PowerShell/](http://EXCH2010-CAS01/PowerShell/) ` -Authentication Kerberos`
-Credential $cred
Import-PSSession $session -DisableNameCheckingここでの重要ポイントは次のとおりです。
- 接続先は /PowerShell/（/owa や /ecp に行かない）
- Exchange 2010 では、役割的に CAS サーバーが入口になりやすい（Mailbox サーバーへ直撃していると遠回りになることがある）
- “これまで使っていた外部公開名”が Microsoft 365 側を向いているなら、内部FQDNや管理用の別名を使う
HTTPS を使って安全に繋ぐ（証明書が整っている場合）
Workgroup 端末や別ドメインからの接続など、Kerberos が成立しにくい環境では HTTPS の方が安定することがあります。
$cred = Get-Credential
$sessionOption = New-PSSessionOption -SkipCACheck -SkipCNCheck -SkipRevocationCheck
# ※上記Skip系は“暫定回避”です。できれば正しい証明書で運用してください。
$session = New-PSSession `
-ConfigurationName Microsoft.Exchange `
-ConnectionUri https://EXCH2010-CAS01/PowerShell/ `
-Authentication Basic `
-Credential $cred `
-SessionOption $sessionOption
Import-PSSession $session -DisableNameChecking注意：Basic 認証は SSL/TLS 前提です（HTTP での Basic は避けてください）。また、Skip 系オプションは切り分け用途に留め、最終的には信頼済み証明書で運用するのが安全です。
ここを落とすとハマる：移行後に多い “入口ズレ” の具体例
外部公開名が Microsoft 365（Exchange Online）を向いている
移行後、mail.contoso.com が Exchange Online / Microsoft 365 側へ向くのは自然な変更です。ところが管理者が過去の手順のまま mail.contoso.com を叩くと、WinRM から見れば“別サービスのHTML”が返ってきます。
対策はシンプルで、管理用は内部名で固定します。
- 例：exmgmt.contoso.local や exch2010-cas01.contoso.local など、管理専用の名前を使う
- 管理端末の hosts で一時的に固定して切り分け（恒久はDNS推奨）
- ロードバランサ配下なら、まずは実サーバーへ直で確認
ポート未指定で 80/443 に当たってしまう
WSMan の標準は 5985/5986 ですが、コマンドや引数の与え方によっては 80/443 の Web サイトに当たり、HTML を掴むことがあります。特に「URI を手打ち」するケースで起きます。
対策は次の2つです。
- Test-WSMan は -ComputerName と -Port で指定（URI手打ちを減らす）
- URI を使うなら http(s)://ホスト:ポート/wsman を徹底
プロキシ（WinHTTP Proxy）が介在し、プロキシのHTMLを掴んでいる
企業ネットワークでは、HTTP/HTTPS がプロキシ経由になっており、WinRM の通信が意図せずプロキシへ流れて HTML（ブロックページ）を掴むことがあります。これは content-type エラーの典型です。
管理端末で次を確認してください。
netsh winhttp show proxyもしプロキシが設定されていて、WinRM 通信に不要なら、切り分けとして一時的に解除します。
netsh winhttp reset proxy組織ポリシーの兼ね合いがあるため、恒久対応はネットワーク担当と調整しつつ、管理系の通信（WinRM/Exchange管理）をプロキシ経由にしない設計に寄せると安定します。
Workgroup 端末・別ドメインから接続している（Kerberosが成立しない）
ドメイン参加していない端末や、信頼関係のないドメインからの接続では、認証が複雑になり “結果として HTML を掴む” 方向に転びやすいです（中継装置の認証ページに飛ばされる等）。
現実的な回避策は次の順で検討します。
- 可能なら管理端末を同一ドメイン参加（最も事故が少ない）
- 難しければ、HTTPS を前提にし、認証方式を環境に合わせる
- TrustedHosts の設定は最終手段（運用範囲を最小化）
TrustedHosts を使う場合の例（切り分け用途）：
# クライアント側で実行（管理端末）
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "EXCH2010-CAS01" -Force
Restart-Service WinRM注意：TrustedHosts を広く設定すると、なりすましリスクが上がります。ワイルドカード（*）は避け、必要なホスト名のみ最小で設定し、管理ネットワーク内に限定する運用が安全です。
ロードバランサ／リバースプロキシ配下で、/wsman や /PowerShell が想定と違う応答になる
移行後の見直しで WAF やロードバランサを強化した結果、管理用のパスが弾かれて HTML を返してしまうケースがあります。
- /wsman へのアクセスが 403（ブロックページ）になっている
- /PowerShell/ が別の認証ページへ 302 リダイレクトされる
- SSL オフロードでヘッダが変わり、IIS 側が想定外の応答になる
切り分けの鉄則は、まず“ロードバランサを経由しない”直アクセスで成功するか確認することです。直アクセスで成功し、経由で失敗するなら、ネットワーク機器側の制御（パス、ヘッダ、認証、TLS設定）に問題が寄っています。
サーバー側（Exchange 2010）で確認しておくと効くポイント
WSMan のポートが生きていても、Exchange の Remote PowerShell 入口（/PowerShell/）が壊れていると管理はできません。Exchange 2010 側で次も確認します。
PowerShell 仮想ディレクトリの URL と SSL 要件
# Exchange Management Shell で実行
Get-PowerShellVirtualDirectory |
Select-Object Identity,InternalUrl,ExternalUrl,RequireSSL,BasicAuthentication,WindowsAuthentication |
Format-Table -Auto確認ポイント：
- InternalUrl/ExternalUrl が意図したURLか（移行後の変更で残骸がないか）
- RequireSSL が有効なら、http で叩くとリダイレクトや拒否が起きうる
- WindowsAuthentication / BasicAuthentication の組み合わせが、接続方法と整合しているか
IIS で “/PowerShell” を叩いたときに何が返るか
/PowerShell/ にブラウザでアクセスすると、認証ダイアログが出たり、401 になったりすることがあります。ここで 404 や別サイトのページが出るなら、仮想ディレクトリやサイトバインドのズレを疑います。
また、IIS ログ（該当サイト）を見ると、
- どのパスにアクセスされているか
- ステータスコードが何か（200/401/403/404/302）
が分かるため、content-type エラーの裏側が読みやすくなります。
実務で効く「復旧の近道」パターン
個別環境差はありますが、現場で “直る確率が高い順” に並べると次の流れになります。
| 優先 | やること | 狙い |
|---|---|---|
| 高 | 接続先を内部FQDN＋ポート明示に変更（5985/5986、/wsman、/PowerShell） | HTMLを掴む原因（入口ズレ）を潰す |
| 高 | Test-WSMan / Invoke-WebRequest で“何が返ってきているか”を確認 | 誤った前提で対処しない |
| 中 | WinHTTP Proxy の確認・切り分け（netsh winhttp） | プロキシHTMLを掴む事故を潰す |
| 中 | Exchange 管理は New-PSSession -ConfigurationName Microsoft.Exchange を徹底 | 用途に合った入口へ寄せる |
| 低 | TrustedHosts や認証方式変更（環境依存で慎重に） | ドメイン外など特殊条件の回避 |
再発防止：移行後もオンプレ Exchange を残すなら「管理用の入口」を設計する
Microsoft 365 へ移行しても、オンプレ AD 同期（Azure AD Connect など）の都合で “受信者属性の管理” が必要になり、オンプレ Exchange をしばらく残す運用は珍しくありません。ただし、移行後は外部公開名が変わるため、管理者が迷子になりやすいです。
再発防止のために、次の設計が効きます。
- 管理専用のDNS名を用意する（例：exmgmt.contoso.local）
- 管理ネットワークからのみ到達可能にする（FWで制限）
- 接続手順を1枚にまとめ、“使ってよいURL/ポート”を固定する
- ロードバランサやリバプロの経路と、直アクセス経路を整理して記録する
- Exchange 2010 は古い製品のため、可能ならサポートされる構成への更新を計画する（セキュリティ・運用面で重要）
最終チェックリスト
最後に、現場でそのまま使えるチェックリストを置いておきます。上から順に潰すと、ほとんどのケースで原因に辿り着けます。
| チェック項目 | 確認方法（例） | OKの目安 |
|---|---|---|
| 名前解決がオンプレを向いている | nslookup EXCH2010-CAS01nslookup mail.contoso.com | 管理用はオンプレIPに解決 |
| WinRM の入口に到達している | Test-WSMan -ComputerName EXCH2010-CAS01 -Port 5985 | エラーなく応答が返る |
| 誤ってHTMLを掴んでいない | Invoke-WebRequest http://EXCH2010-CAS01:5985/wsman | text/html ではない／プロキシページが出ない |
| サーバー側でリスナーが存在する | Get-WSManInstance -ResourceURI winrm/config/listener -Enumerate | 5985/5986 で待受 |
| Exchange Remote PowerShell で接続できる | New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://EXCH2010-CAS01/PowerShell/ | Import-PSSession できる |
| プロキシが邪魔していない | netsh winhttp show proxy | 不要なら Direct |
コメント