Windows Virtual Desktop #5 Windows クライアントを詳しくテストする話

この記事のWVDは”Windows Virtual Desktop Spring 2020 Release”が対象です。

Windows Virtual Desktop はHTML5 対応のWeb ブラウザまたは様々なOS 向けのクライアントアプリケーションに対応しています。　具体的には以下のOSです。　今回はWindows Desktop 向けのクライアントを試します。

Windows Desktop (32bit/64bit and ARM64)
MacOS
iOS
Android

上記にLinux はありませんがLinux 上で動作するFirefox およびChrome に対応しています。　Linux については Chrome からの接続とします。

1. クライアントアプリケーションのインストール

1.1. Installer のダウンロード

クライアントアプリケーションのインストーラはマイクロソフトのサイトから入手可能です。

Windows 向けとして 32bit と64bit 版、そして ARM64 版があります。　現状、ほとんどのクライアントはx86 の64bit になると思います。

ARM 版Windows といえばWindows RT を思い出します。　黒歴史な気もしますが VDI 観点ではVDA ライセンスを多少安価に付与出来るためクライアント端末としての価値はありました。　いかんせん通常利用のx86 のWindows を置き換えするにはアプリケーション対応の点で利用は広まらなかったと思います。　ユニバーサルアプリの発展が前提だったストーリーだったと思います。　

1.2. インストール

ダウンロードしたインストーラを実行します。

物理PCの環境ですがWindows 10 Enterprise をインストールしている物理PC です。実行モードは x86 64bit です。

”次へ”をクリックします。

途中で選択するようなものはなくあっという間にインストールは終了します。 “完了”をクリックします。

2. Windows Virtual Desktop への接続

リモートデスクトップクライアントを起動します。

“申し込む” をクリックします。

Azure AD のアカウントでサインインします。

“職場または学校アカウント” を選択します。

パスワードを入力します。

読み込みが完了するのを待ちます。　数十秒でしょうか。

仮想デスクトップへアクセスします。

サインインできました。

3. クライアントアプリケーションの設定

リモートデスクトップクライアントアプリケーションで実施できる設定を確認します。

3.1. ディスプレの設定

接続先のアイコンを右クリックすると”設定”を開くことが可能です。

個別の設定を実施する場合は”既定の設定の使用”のスライドボタンをOnからOffへ変更します。

ディスプレイに関する設定を変更することが可能です。

設定を変更する前は全画面モードでした。

例えば以下のように設定を変更するとウィンドウサイズが変わるのか試してみます。

全画面のままです。　以下のスクリーンショットだとわかりづらいですが全画面のままです。

以下の設定に変えることでウィンドウサイズに自動的に拡大 / 縮小できることがわかりました。　これは便利ですね。　”現在の画面に合わせて最大化”を有効にすることがポイントです。

サインインした直後は全画面モードです。　青い画面がAzure 上のWindows 10 です。

全画面モードを解除すると任意のウィンドウサイズに自動的に仮想のWindows 10 側の解像度も変更してくれます。　これが出来ないとスクロールバーで表示領域を変えながら操作することになるのでとてもありがたい機能です。

下のスクリーンショット、グレーのデスクトップは物理PC、青い画面がAzure 上のWindows 10 です。

以下のように物理PCのウィンドウサイズに柔軟に対応します。

3.2. Workspace に関する設定

Workspace の右の”…”をクリックすると3つのメニューが表示されます。

詳細

テナント名（workspace 名）やサインインしたAzure AD アカウントなどが確認できます。　また、”最新の情報に更新”ボタンからフィードに含まれる情報の最新化も実施可能です。

登録を解除

フィードの登録を解除します。

実行すると確認画面がポップアップします。”続ける”をクリックすると解除されます。

解除が完了すると未登録の状態の画面になります。

3.3. フィードバックの送信

Smile アイコンをクリックします。

フィードバックを送信できます。

3.4. 設定

歯車アイコンからは利用状況データをMicrosoft に送信するかどうかの設定、アプリモードとして見た目を変える設定、の2つを変更可能です。

逆にこの2つしか設定は無いということです。

3.5. その他のオプション

”・・・”をクリックするとその他オプションとして3つのメニューが表示されます。

バージョン情報

リモートデスクトップクライアントアプリケーションのバージョンを確認することが出来ます。

また”リセット”ボタンから初期化も可能です。

ヘルプ

ドキュメントがWeb ブラウザで開きます。

4. msrdcw.exe

msrdcw.exe は単独で実行することリモートデスクトップクライアントが起動します。

CUIから”msrdcw.exe /reset” を実行することでリモートデスクトップクライアントの構成情報をリセットし、インストール直後の状態に強制的に変更します。

公式ドキュメントでも使い方が簡単に紹介されています。

このコマンドは2つのファイルで構成されています。”msrdcw.exe” と ”msrdcw.exe.config” です。

ファイルは各ユーザのプロファイルのAppData の中です。 “%LOCALAPPDATA%\Apps\Remote Desktop” です。

“msrdcw.exe.config” の中身は何かに役立ちそうな情報は見つからず。

その他、”%LOCALAPPDATA%\Apps\Remote Desktop” フォルダには115個のファイルと34のフォルダがあります。　フォルダはアイコン用が1つ、それ以外の33個は言語関連です。　ファイルは色々ありますがタイムスタンプや中身を見る限りリモートデスクトップクライアントの構成情報の保存先となっているものはなさそうです。　

リモートデスクトップクライアントの構成情報の保存先がどこなのか調べてみます。一度Azure AD のサインインをすると次回はサインインは省略されるためどこかにその情報を保持し（保持期間はAzure AD 側で指定しますが既定がかなり長い）、起動時に読み込んでいるはずです。　process monitor で調べます。

何百、何千行と出力はありますがざっくりと確認するとファイルに設定を保存していて起動時に読み込むのではなくレジストリのようです。

この話だけで記事が1本分になりそうなので別にします。

5. まとめ

これまでリモートデスクトップクライアントを詳細に確認したことはありませんでした。　調べてみるといろいろ発見がありました。　ディスプレイの解像度変更にも対応していることはエンドユーザーの利便性につながる良い機能改善です。

また、フィード情報の自動更新が4時間毎とわかったことも運用設計を考える際に有用な情報です。　こちらもmsrdcw.exe のようなコマンドベースのツールが提供されれば管理者側で任意のタイミングで最新化を強制することができるようになるでしょう。

別記事で予定しているリモートデスクトップクライアント（msrdcw.exe）の構成情報、とくにAzure AD の資格情報、をどこにどのように保存しているかは一番気になるところです。この認証情報のリセットをいつでも任意のタイミングで実施したいためです。　Windows Virtual Desktop の課題に接続端末の制限があります。　Azure AD の条件付きアクセスよるデバイス認証を行うことは可能なのですが一度認証すると所定期間は認証無しで接続ブローカに接続できるためです。　ここをコントロールしたいという話になります。

とりあえず次は別のOS のクライアントの動作を確認します。