この記事のWVDは”Windows Virtual Desktop Spring 2020 Release”が対象です。
Windows Virtual Desktop Spring 2020 では RDP の設定を Azure Portal から変更できるようになりました。 以下の画面です。 この設定の挙動を確かめていきます。 中編ではドライブのリダイレクションの設定を試します。
リダイレクションの設定ですが、以下の項目を設定可能です。 この中編では Disk drives のリダイレクションをテストします。 後編では Audio input / output をテストする予定です。
- Disk drives
- COM ports
- Clipboard
- Printers
- Smart cards
- Audio input
- Audio output
Disk drives
現在の設定は規定値の”None” です。
ドライブはC:とD:のみです。 ローカルデバイスのドライブはリダイレクションされていないことを確認できます。
設定を”None” から”All” に変更します。
仮想のWindows 10 からサインアウトし、再度サインインします。
しかし、ローカルデバイスのドライブはマウントされません。 前編のディスプレイ設定が反映しない現象と同じかもしれません。 Azure Portal でのRDP settings の変更が反映されないということです。
.rdp ファイルの内容を確認することにします。 %localappdata%\rdclientwpf に移動します。
Workspace のフォルダに移動します。
.rdp ファイルの中身を確認します。 ただ、その前にタイムスタンプが約10時間前で更新されていません。 また、.rdp ファイルの中の リダイレクションに関連する設定は以下の通り。
| redirectdrives:i:1 redirectclipboard:i:1 redirectprinters:i:1 redirectcomports:i:0 redirectsmartcards:i:1 |
Windows Virtual Desktop に関する RDP 設定の公式マニュアルを確認しますが この”redirectdrives”パラメータに関する記載は見つからず。 まあマニュアルの該当ページはPowershell 向けの情報なので .rdp ファイルでの記述方法とは異なっていても特におかしくはありません。
一度、フィードを更新してみます。
しかし、タイムスタンプは変わらず。 ドライブのリダイレクションが有効になった新しい .rdp ファイルで更新されると想定していたのですが想定通りには動きません。
今度はリモートデスクトップクライアントで購読をいったん解除し、再度購読しなおします。 今度はタイムスタンプが変わりました。 まあ、解除したタイミングでファイルは削除され、再度購読したタイミングでWVD のコントロールプレーンからダウンロードしてくるためです。
.rdp ファイルの中身を確認します。 中身は同じでした。
| redirectdrives:i:1 redirectclipboard:i:1 redirectprinters:i:1 redirectcomports:i:0 redirectsmartcards:i:1 |
.rdp ファイルに変化はありませんが、Windows Virtual Desktop のWindows 10 に接続してみます。 ドライブのリダイレクションに成功しました。
もう一度確認します。 購読の解除ではなく、フィードの更新で設定が反映するか確認します。
設定を”None”に変えます。
リモートデスクトップクライアントで”最新の情報に更新”を実行します。
更新後、Windows Virtual Desktop 上のWindows 10 に接続します。 ドライブのリダイレクションが無効化されたことが確認出来ました。 フィードの更新だけで反映されることが確認出来ました。
次は “Dynamic drives”をテストします。
ヘルプからDynamic drives はローカルデバイスで追加されたドライブも動的にマウントできる機能のようです。
Windows Virtual Desktop 上のWindows 10 にサインインします。 ”All”の時とことなり、ローカルデバイスのC:、D:、F:ドライブはマウントされません。
ローカルデバイスにリムーバルメディアを接続します。 動的に仮想のWindows 10 にN:ドライブがリダイレクションされました。 利用シーンとしては、ローカルデバイスにUSBメディアなどを接続し、そのUSBメディアをWVD 上のWindows 10 でも利用したい場合になるでしょうか。 別途、読み取り専用やUSBメディアの限定の設定など別途必要にはなりそうですが（Windows Virtual Desktop にはその設定は無いのでグループポリシーや3rd Party のツールを使うことになるか）。
ドライブのリダイレクションの残る設定は”Custom” です。 リダイレクションするローカルドライブを明示的に指定します。 ローカルデバイスも管理下におかれた環境で利用することになりそうです。
リダイレクションしたドライブからのファイルコピーをテストします。 ローカルデバイスのドライブのデータをWindows Virtual Desktop 上のWindows 10 にコピーします。
スループットは 大体 80Mbps で頭打ちになっています。
自宅のインターネット環境をGoogle の速度テストの結果は以下の通り。 アップロードが遅く、上記の約80Mbps は自宅のインターネット環境の遅さがボトルネックのようです。
また、CPU リソースを結構使っています。データの圧縮・非圧縮や暗号化・複合化の処理かもしれません。 または Drive のリダイレクションの中でIO 処理をエミュレーターしているからなのか。
通信方向を逆にします。 WVD 上のWindows 10 からローカルデバイスのドライブへコピーします。 こちらは100Mbps で頭打ちです。自宅のインターネット環境は500Mbps 位なのでこちらは Azure 側で制限がかかっていそうです（VNet かStorage account のどちらかか）。 また、CPUのリソース使用率が75%まで到達しているのでリダイレクションに関するCPU 処理がボトルネックになっている可能性が高そうです。切り分けにはバーストタイプのBs シリーズではなく高速CPU を使ったテストが必要です。
まとめです。 ドライブのリダイレクションは問題なく機能しました。 また、Azure Portal 上での設定変更を反映するにはリモートデスクトップクライアント側でフィードの更新が必要なこともわかりました。これは実運用を考えるとすこし知恵が必要そうです。 利用者に強制的に更新を促すのは難しいので自動で更新する仕組みの準備が必要そうです。
次の後編ではAudioの リダイレクションを確認します。 既定の設定は以下の通りなのですが、 Audio input は”Off”です。 つまり、WVD 上でTeams 会議を行おうとした場合、ローカルデバイスの音声入力をリダイレクトしないということになりそうです（既定では）。 後編ではTeam 会議をテストします。
