AWS上のWindowsインスタンスでRemoteAppの導入をやっていたら、ふとした拍子にリモートデスクトップで入れなくなってしまい、インスタンスを破棄して作り直すべきか迷っている件の続きです。
（前の記事 RemoteAppで接続できなくなった(Schannel 36874)）
Domain Controller(DC)にログインして[サーバーマネージャー]＞[すべてのサーバー]から障害となっているサーバーを選択。右クリックして[コンピューターの管理]を選ぶと、普通に動きました。
イベントビューアーの管理イベントで上がっているのは一個だけ。
これ、他のサーバーでもしょっちゅう出ます。インスタンスのネットワークインターフェイスが有効になる前にサービスが上がってしまうとか言うタイミングの問題なのかも。念のため手で動かしてみると、特に問題なく通ります。
rds-test.union-test.local]: PS C:\> gpupdate
ポリシーを最新の情報に更新しています...
コンピューター ポリシーの更新が正常に完了しました。
ユーザー ポリシーの更新が正常に完了しました。
グループポリシー Group Policy が適用されない時の確認事項
チューニングについてはいろいろあるみたいですが、とりあえず見なかったことにして先に進みます。
3389 ポートへのコネクション後のネゴシエーションでコケているので、どれがそいつを待っているのかを見てみます（見やすいようにインデントを調整）。
[rds-test.union-test.local]: PS C:\> netstat -abn
アクティブな接続
プロトコル ローカル アドレス 外部アドレス 状態
TCP 0.0.0.0:22 0.0.0.0:0 LISTENING [sshd.exe]
TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 所有者情報を取得できません
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING RpcSs[svchost.exe]
TCP 0.0.0.0:443 0.0.0.0:0 LISTENING 所有者情報を取得できません
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 所有者情報を取得できません
TCP 0.0.0.0:3389 0.0.0.0:0 LISTENING TermService[svchost.exe]
（以下略）
（実際は Gow - The lightweight alternative to Cygwinというのを入れているので
netstat -abn | head -10
とかやるところですけど、パイプラインを通すと日本語が化けちゃったので却下ｗ）
3389 は TermService というのが待ち受けているようです。
[rds-test.union-test.local]: PS C:\> Get-Service -Name TermService
Status Name DisplayName
------ ---- -----------
Running TermService Remote Desktop Services
ちなみに、リモートデスクトップサービスの役割を導入していないサーバーだとどう出るのか確認。DC上で実行すると、
PS C:\> netstat -abn
（中略）
TCP 0.0.0.0:3389 0.0.0.0:0 LISTENING TermService[svchost.exe]
PS C:\> Get-Service -Name TermService
Status Name DisplayName
------ ---- -----------
Running TermService Remote Desktop Services
全く同じですね。もともとデフォルトで Remote Desktop Service という（AWSでは事実上）必須のサービスが動いていて、これに対してリモートデスクトップサービスの役割を導入すると、周辺コンポーネントが大幅に拡張されるということなんでしょうか。
ここでふと、サーバーマネージャーでリモート管理できるのなら、リモートデスクトップサービスの役割自体を削除してしまえば元の状態に戻るのではないかと思いつきました。
[サーバーマネージャー]＞[管理]＞[役割と機能の削除]。これを使って[Remote Desktop Services]をざっくりと削除してみました。
うーん、やっぱりコンポーネントのどこかで不整合が発生しているのかな？イベントビューアーで見ると、
その後、もう一度[役割と機能の削除]を選ぶと、見事にすべての役割が復活しています。ここは、トランザクション処理がきちんとしているのをほめるべきか。
リモートデスクトップサービスで導入していたコンポーネントは以下のようになっていました。
- Remote Desktop Services
- Remote Desktop Connection Broker（導入済み）
- Remote Desktop Gateway（未）
- Remote Desktop Session Host（導入済み）
- Remote Desktop Virtualization Host（未）
- Remote Desktop Web Access（導入済み）
しょうがないので、１つずつ消していくことにします。まずは Remote Desktop Web Access から。
おおぅ。
ちょっと作戦を変えます。Web Access ってくらいだから、IIS に依存しているはずです。IIS を削除してみるというのはどうか？
いい感じです。依存関係により Remote Desktop Web Access も芋づるで削除対象になっています。再起動後、もう一度[役割と機能の削除]で確認すると、Web Access は消えていました。この時点で念のためリモートデスクトップ接続を確認すると、、、なんと接続が復活！ IIS だから 3389 ポートなんぞ関係ないと思っていましたが、奥が深い。。。
ちなみにこの状態で、入れるようになったサーバーのサーバーマネージャーで確認すると、以下のようになっていました。
リモートデスクトップサービスについては、以下の書籍を見ながら実験しています。
- 標準テキスト Windows Server 2012 R2 構築・運用・管理パーフェクトガイド
- Windows Server 2012 R2テクノロジ入門 (TechNet ITプロシリーズ)
- ひと目でわかる リモートデスクトップサービス WindowsServer2012版 (TechNet ITプロシリーズ)
しかしながら、コンポーネントの組み合わせが多岐にわたり、書籍以外の構成にするといろんな事象が出ます。ネット上にも情報が少なくて困ります。
ということで、3389 ポートのネゴシエーションに失敗する件については今後の課題ですが、とりあえず「インスタンスに接続できない」という件については、接続できるようになったので、半分解決というところです。Windows のトラブルシュートに関するご参考になれば幸いです。