Windows 10 April 2018 Update（バージョン 1803）の RDP 関連の残念なバグ

RDP 接続だと UWP アプリ（ストア アプリ、Edge も）で英字入力のときに英語配列になっちゃう問題。例えば、http: と入力しようとすると http; とか、yama@ と入力しようとすると yama[ とかなっちゃう問題。RDP クライアントの mstsc と UWP 版リモートデスクトップ アプリの両方に影響。


うちだけかなぁと思ってたら、Windows 10 April 2018 Update（バージョン 1803 ）のバグだったようです。この問題に気付かないままパスワード入力画面とか出てくると、大いに悩むこと間違いなし（パスワードに記号が入ってると受け付けてくれないから）。正式リリースされるまで誰にも気づかれなかったのかしらん。

Windows 10 RS4 へのリモート デスクトップ接続時に、UWP アプリへの入力時のみキーボード配列が異なる事象について
[URL] https://blogs.technet.microsoft.com/askcorejp/2018/06/08/rs4-rdp-keyboardlayout/
（6/21 追記：原因が↑に追記されました。回避方法は変わらず。）
（6/27 追記：6/21 に原因が↑に追記されました。6/27 にレジストリを書き換える 回避策 2 が追加されてます。）
（12/5 追記: 追記遅れましたが、9/26 の KB4458469 (OS Build 17134.319) で修正されました。9/20 に最初に出て、何かあって 9/26 に再リリース）

Windows 10 RS4 って一般ユーザーに伝わらないような...

回避策として「全角（日本語）で入力して半角に変換」と書いてますが、私の回避策は...


英語配列なキーボードでも気にしない。日本語環境あるあるトラブルなので、がんばってキー入力する。: と @ だけでも覚えておけばなんとかなる。

バージョン 1803 への RDP 接続＋UWP アプリ＋IME オフで発生する問題ですが、結構、影響範囲は大きいかもしれません。設定アプリや Cortana の検索窓とかにも影響。こいつらも一種の UWP だから。

Hyper-Vの拡張セッション モードでバージョン1803仮想マシンに接続してUWPアプリを使うときにも影響。拡張セッション モードは RDP 接続を利用しているから。

パスワードの設定や入力のときにこの問題が影響していると、厄介なことになりますね。例えば、P@ssw0rd と設定したつもりが、実際には P[ssw0rd になってたり（そしてローカルでサインインの場面でパスワード違うって言われることに）。

もしかして、Windows Defender Application Guard (WDAG) で 1803 になってもキーボードだけどうにもならんのは、この問題が関係しているからだったりして。WDAG って仕組み的に間に RDP が一役噛んでる（隔離環境で実行中の OS 上の Edge に RemoteApp っぽく RDP 接続している感じ？）。

Windows 10 April 2018 Update（バージョン1803）における企業向け機能の改善点と強化点（@IT）
[URL] http://www.atmarkit.co.jp/ait/articles/1805/10/news015.html
Windows 10 バージョン 1803（17133.73/17134.1）の WDAG （2018/04/16）

ほら、WDAG のプロセス（hvsimgr.exe）の子プロセス（hdsirdpclient.exe） で mstscax.dll 使ってる。

IME オンで入力して変換するっていう askcorejp の言う回避策は WDAG の 101 問題でも同じように使える。

・・・ 別件 ・・・ 

この問題とは別に、うちではバージョン 1803 へのアップグレード後に RDP 関連でもう1つ気になる挙動の違いがあってさね。

LAN と Wi-Fi の 2 接続あって、LAN だけのとき（のような気がする） ワークグループ構成（ローカルの DNS なし）の PC で ↑ みたいな画面が出るようになっちゃった。あきらめずに何度か繰り返すと接続できる。IP 指定だと問題なく接続できる。LAN と Wi-Fi 両方接続（同一サブネット）するとすんなり接続できる（ような気がする）。んだけど、なんだか気持ち悪い。バージョン 1709 まではこんなの見たことないのさ。 PING <コンピューター名>も初回は名前解決失敗して、何度か試すと IPv6 を解決できる感じ。なにかのタイムアウト値が間違っててすぐにあきらめちゃってるような感じ。

6/11 追記) mDNS（Bonjour）が関係しているかもしれない。<コンピューター名>.local で接続すれば、すんなり接続できる（ような気がする）。これも関係なかったようです。

6/11 さらに追記) → この件に関してはこちらに回避策あり

Windows 10 バージョン 1709 と Windows 10 バージョン 1803 をクリーンインストールして最新に更新（17134.81 と 16299.461）、リモートデスクトップの有効化、ネットワークはプライベートにした 2 台の仮想マシンを用意。

・手元の Windows 10 バージョン 1803 から仮想マシンのバージョン 1803 は、”検出できません。”
・手元の Windows 10 バージョン 1803 から仮想マシンのバージョン 1709 は、問題なく接続できる。
・仮想マシンの Windows 10 バージョン 1709 から仮想マシンのバージョン 1803 は、問題なく接続できる。

さらに...

・手元の Windows 10 バージョン 1803 から仮想マシンのバージョン 1803 は、何度やっても ”検出できません。”
・手元の Windows 10 バージョン 1803 から仮想マシンのバージョン 1803 は、Windows Defender ファイアウォールを無効にしても ”検出できません。” ping <コンピューター名> も NG。
・手元の Windows 10 バージョン 1803 で resolve-dnsname <仮想マシンのバージョン 1803 のコンピューター名> が IPv6 しか返さない（関係あるかは別として）。

・仮想マシン側を更新なし 17134.1 でやってみても状況は変わらず。

・仮想マシン側で「SMB 1.0/CIFS ファイル共有のサポート」（クライアントとサーバー、クリーンインストールだと既定で無効）を有効化しても状況は変わらず（関係あるかは別として）。
・nbtstat -A IPv4、nbtstat -a <コンピューター名>は正常。

Windows 10 バージョン 1803 と バージョン 1803 間のワークグループ構成（ローカルの DNS なし）の名前解決環境が、なんだかおかしい。→ 一時的な回避策はこちら