RemoteAppで接続できなくなった(半分解決)

AWS上のWindowsインスタンスでRemoteAppの導入をやっていたら、ふとした拍子にリモートデスクトップで入れなくなってしまい、インスタンスを破棄して作り直すべきか迷っている件の続きです。

（前の記事　[RemoteAppで接続できなくなった(Schannel 36874)](http://qiita.com/hotta/items/b3e9374b90d5d86f5f49)）

Domain Controller(DC)にログインして[サーバーマネージャー]＞[すべてのサーバー]から障害となっているサーバーを選択。右クリックして[コンピューターの管理]を選ぶと、普通に動きました。

イベントビューアーの管理イベントで上がっているのは一個だけ。

![グループポリシーの処理に失敗.PNG](https://qiita-image-store.s3.amazonaws.com/0/47305/88f14be2-7bc0-0484-f8e8-9b31b1e1cc09.png)

これ、他のサーバーでもしょっちゅう出ます。インスタンスのネットワークインターフェイスが有効になる前にサービスが上がってしまうとか言うタイミングの問題なのかも。念のため手で動かしてみると、特に問題なく通ります。

```ps1
rds-test.union-test.local]: PS C:\> gpupdate
ポリシーを最新の情報に更新しています...

コンピューター ポリシーの更新が正常に完了しました。
ユーザー ポリシーの更新が正常に完了しました。
```

[グループポリシー Group Policy が適用されない時の確認事項](http://www.itserviceknowledgebase.com/article/214575333.html)

チューニングについてはいろいろあるみたいですが、とりあえず見なかったことにして先に進みます。

3389 ポートへのコネクション後のネゴシエーションでコケているので、どれがそいつを待っているのかを見てみます（見やすいようにインデントを調整）。

```ps1
[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](https://github.com/bmatzelle/gow)というのを入れているので

```ps1
netstat -abn | head -10
```

とかやるところですけど、パイプラインを通すと日本語が化けちゃったので却下ｗ）

3389 は TermService というのが待ち受けているようです。

```ps1
[rds-test.union-test.local]: PS C:\> Get-Service -Name TermService

Status   Name               DisplayName
------   ----               -----------
Running  TermService        Remote Desktop Services
```

ちなみに、リモートデスクトップサービスの役割を導入していないサーバーだとどう出るのか確認。DC上で実行すると、

```ps1
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]をざっくりと削除してみました。

![役割の削除の失敗.PNG](https://qiita-image-store.s3.amazonaws.com/0/47305/828f7220-6102-362b-2b13-ad608b4e244f.png)

うーん、やっぱりコンポーネントのどこかで不整合が発生しているのかな？イベントビューアーで見ると、

![ハンドルが無効です.PNG](https://qiita-image-store.s3.amazonaws.com/0/47305/8bfd4de5-699d-dc3a-80e2-3ef90d29a2fb.png)

その後、もう一度[役割と機能の削除]を選ぶと、見事にすべての役割が復活しています。ここは、トランザクション処理がきちんとしているのをほめるべきか。

リモートデスクトップサービスで導入していたコンポーネントは以下のようになっていました。

- 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 から。
![WebAccess削除失敗.PNG](https://qiita-image-store.s3.amazonaws.com/0/47305/7f62cee1-b493-4266-302f-9b7ea32bb645.png)

おおぅ。

ちょっと作戦を変えます。Web Access ってくらいだから、IIS に依存しているはずです。IIS を削除してみるというのはどうか？

![削除の進行状況の表示.PNG](https://qiita-image-store.s3.amazonaws.com/0/47305/5184df96-5cb3-cb34-cab9-864c0cd19829.png)

いい感じです。依存関係により Remote Desktop Web Access も芋づるで削除対象になっています。再起動後、もう一度[役割と機能の削除]で確認すると、Web Access は消えていました。この時点で念のためリモートデスクトップ接続を確認すると、、、なんと接続が復活！ IIS だから 3389 ポートなんぞ関係ないと思っていましたが、奥が深い。。。

ちなみにこの状態で、入れるようになったサーバーのサーバーマネージャーで確認すると、以下のようになっていました。

![サーバープールに存在しません.PNG](https://qiita-image-store.s3.amazonaws.com/0/47305/c55a5abc-4f8c-ae57-b178-6bd442fdb802.png)

リモートデスクトップサービスについては、以下の書籍を見ながら実験しています。

- [標準テキスト Windows Server 2012 R2 構築・運用・管理パーフェクトガイド](https://www.amazon.co.jp/%E6%A8%99%E6%BA%96%E3%83%86%E3%82%AD%E3%82%B9%E3%83%88-Windows-Server-2012-%E6%A7%8B%E7%AF%89%E3%83%BB%E9%81%8B%E7%94%A8%E3%83%BB%E7%AE%A1%E7%90%86%E3%83%91%E3%83%BC%E3%83%95%E3%82%A7%E3%82%AF%E3%83%88%E3%82%AC%E3%82%A4%E3%83%89/dp/4797377046/)
- [Windows Server 2012 R2テクノロジ入門 (TechNet ITプロシリーズ)](https://www.amazon.co.jp/Windows-Server-R2%E3%83%86%E3%82%AF%E3%83%8E%E3%83%AD%E3%82%B8%E5%85%A5%E9%96%80-TechNet-IT%E3%83%97%E3%83%AD%E3%82%B7%E3%83%AA%E3%83%BC%E3%82%BA/dp/4822298256/)
- [ひと目でわかる リモートデスクトップサービス WindowsServer2012版 (TechNet ITプロシリーズ) ](https://www.amazon.co.jp/ひと目でわかる-リモートデスクトップサービス-WindowsServer2012版-TechNet-ITプロシリーズ/dp/4822294994/)

　しかしながら、コンポーネントの組み合わせが多岐にわたり、書籍以外の構成にするといろんな事象が出ます。ネット上にも情報が少なくて困ります。

　ということで、3389 ポートのネゴシエーションに失敗する件については今後の課題ですが、とりあえず「インスタンスに接続できない」という件については、接続できるようになったので、半分解決というところです。Windows のトラブルシュートに関するご参考になれば幸いです。