とあるリモートワークIT環境要件
ユーザとしての私の要件
なお、私物PCはWindows10 Professionalです。
| ① | ② | ③ | ④ | ⑤ | |
| (a) | 対策ア：Hyper-V上のゲストOSのWindows10からVPN＋VDI、Web会議はホストOS | ||||
| (b) | |||||
| (c) | 対策イ：Hyper-Vの拡張セッションでのCisco AnyConnect利用 対策ウ：特定のモニタ指定のリモートデスクトップ接続設定 | ||||
| (d) | 対策エ：日本語キーボード設定のまま英語キーボード、Emacsキーバインド | ||||
PCからVPN接続すると全トラフィックがVPN接続先に向かうため、Web会議(Cisco Webex等)のトラフィックもVPN接続先ネットワークからInternetに戻ってWeb会議システムに向かってしまうため、リモートIT環境要件②VPN接続先からのWeb会議(Cisco Webex等)は非推奨に抵触してしまう。実際、ここの環境では時間帯によって音声品質が激悪になるので、会議にならない。仕方がないので、Web会議の音声接続は、VPNを介さずに会社貸与のスマホ・タブレット等が推奨となっている。
これだと、ユーザとしての私の要件(a)を満たさない。
(もっとも、VPN GWをISP(インターネット)内に設けるだとか、会社貸与ノートPCにドメイン管理でルーティングの仕向先をWeb会議だけはVPNを介さないように設定するだとか、できるような気もするのだが、ここではそうはしていないようだ)
そこで、このとあるリモートワークIT環境を使っている先人の知恵を拝借して、私物PCにHyper-V上のゲストOSとしてWindows10をインストールし、ゲストOS側からVPN＋VDIし、ホストOS側からWeb会議に接続することにした。
また、ゲストOSはリモートワーク専用にすることで、ユーザとしての私の要件(b)も満たすので助かる。ゲストOSなら会社ご指定のものにマミれても、万一なにか動かない場合の切り分けとか考えなくてすむ。
ホストOSのWindows10上でのHyper-Vの有効化の設定方法、Windows10のISOイメージのダウンロード方法、Hyper-V上のゲストOS作成・Windows10のインストール方法は、ググればすぐ出てくるし、最新の情報はググった方がよいと思うので特定のリンク先の記載はここでは割愛する。
なお、以下2点に留意のこと。
Hyper-Vでは拡張セッションの有効・無効が設定できる。デフォルトは拡張セッション：有効。
Hyper-Vの拡張セッションは、Windowsのリモートデスクトップの仕組みを利用して、ホストOSからゲストOSに接続するらしく、この際、ホストOS～ゲストOS間でネットワーク接続が必要になるようだ。
VPN接続した際に、ゲストOSは全てのルーティングがVPN接続先に向いてしまうため、ホストOS～ゲストOS間が接続できなくなる場合があるようだ。
とあるリモートワークIT環境では、Cisco AnyConnectは、そもそも拡張セッション下だとエラー画面が出て、全くVPN接続できない。
とある先人によれば、Hyper-Vの拡張セッション：有効と、Cisco AnyConnectのVPN接続を両立させるには、Microsoft store配布版(UWPアプリ版)のAnyConnectをゲストOSにインストールし、ゲストOSのネットワークインタフェースの設定をすこし変えればよいそうなので、それで対策することとした。
詳細：Hyper-Vの仮想マシン（拡張セッション）からCisco AnyConnectを利用するには
3台あるマルチモニタを下図のように使いたいのだが、当初、リモートデスクトップ(Hyper-Vの拡張セッションを使う上で必要)は、3モニタまたがっての全画面か、どれか1モニタのみか、のどちらかしか選べないように思われた。
ググってみたところ、【RDP】特定のディスプレイを指定してマルチディスプレイでリモートデスクトップするのようにできるそうだ。
引用・要約すると、以下の通り。
デスクトップで右クリック→ディスプレイ設定→識別 で表示されるモニタの番号とは違うようで、コマンドプロンプトから
mstsc.exe /l
と入力して起動される下図のようなウィンドウを表示して確認する。
()内の最初の2つの数字がメインディスプレイの左上隅を原点とする座標になっているようである。
したがって、下図のようになり、今回ゲストOSを表示したいモニタのモニタIDは、0と2である。
なお、メインディスプレイを他のモニタに変更しても、このモニタIDは変わらないようである。
use multimon:i:1 (複数モニタで使う場合は1にする)
selectedmonitors:s:0,2 (追記する。ゲストOS上のメインディスプレイのモニタIDを最初に書く。
ここではモニタID：0がメインディスプレイ、1がサブディスプレイ)
ここでの課題・対策は以下のように分かれる。
| Fakeymacs | DvorakJ | Xkeymacs | MS-IMEのキー設定 | |
| エー1 | ○ (要 設定追加) | ○ | ||
| エー2 | ○ | ○ | ||
| エー3 | ○ | ○ |
そこで、対策方法は以下の2つがある。対策エ-b)は2つの常駐ソフトがキー入力に関わるが、対策エ-a)はその点シンプルである。一方、対策エ-a)は、設定がすこしだけ多い。
Fakeymacs は、Windows の操作を Emacs のキーバインドで行えるようにするための
Keyhacの設定である。
ホストOS上でも使用しているが、VDI内でも別途動作させる必要がある。
Keyhacは、ダウンロードしたzipファイルをどこかのフォルダに展開してkeyhac.exeを起動するのみなので、Administrator権限は不要である。
一方、日本語キーボードドライバで英語配列を使う【KEYHAC 編】によると、KeyhacにPythonでほんの少しコードを書く(設定レベルとも言う)ことで、Windowsの設定は日本語キーボード設定のまま、英語キーボードを使う方法の記載がある。
この2つを組合せて利用するため、Fakeymacsに、日本語キーボードドライバで英語配列を使う【KEYHAC 編】のPythonのコードを加えて利用することにした。
# Windows OS自身の設定を日本語キーボード設定のままで、英語キーボードを使用
#if 0:
if 1:
fc.kmg = keymap.defineWindowKeymap()
# S-2 => @
fc.kmg[ "S-2" ] = "(192)"
# S-6 => ^
fc.kmg[ "S-6" ] = "(222)"
# S-7 => &
fc.kmg[ "S-7" ] = "S-6"
# S-8 => *
fc.kmg[ "S-8" ] = "S-(186)"
# S-9 => (
fc.kmg[ "S-9" ] = "S-8"
# S-0 => )
fc.kmg[ "S-0" ] = "S-9"
# S-- => _
fc.kmg[ "S-Minus" ] = "S-(226)"
# ^ => =
fc.kmg[ "(222)" ] = "S-Minus"
# S-^ => +
fc.kmg[ "S-(222)" ] = "S-Plus"
# [ => \
# S-[ => |
keymap.replaceKey( "(221)", "(220)" )
# 半角/全角 => `
fc.kmg[ "(243)" ] = "S-(192)"
fc.kmg[ "(244)" ] = "S-(192)"
# S-半角/全角 => ~
fc.kmg[ "S-(243)" ] = "S-(222)"
fc.kmg[ "S-(244)" ] = "S-(222)"
# @ => [
# S-@ => {
keymap.replaceKey( "(192)", "(219)" )
# [ => ]
# S-[ => }
keymap.replaceKey( "(219)", "(221)" )
# S-; => :
fc.kmg[ "S-Plus" ] = "(186)"
# : => '
fc.kmg[ "(186)" ] = "S-7"
# S-: => "
fc.kmg[ "S-(186)" ] = "S-2"
# --------------------------------------------------------------------------------------------------
なお、当初、この追加設定なしに、Fakeymacsと後述のDvorakJの組合せを試してみたが、キー入力がバッファリングされてしまって使い物にならなかった。DvorakJないしFakeymacsの設定次第かもしれない。
DvorakJという常駐ソフトなら、Administrator権限なしで、unzipしたフォルダをどこかのフォルダに置いて、手動起動し、多少の設定をすることで、ホストOSの英語キーボードの入力がVDI上でも同じ入力になった。
ソフトウェア名から、キー配列のDvorak配列を思い浮かべてしまうが、Dvorak配列だけが利用できるわけではないようだ。
XKeymacsは、Emacsのようなキー割り当てを、Windows上のアプリケーションで実現してくれる常駐ソフトである。Administrator権限なしで、unzipしたフォルダをどこかのフォルダに置いて、手動起動可能である。
XKeymacsにもキーボードレイアウトを変更する機能はあるのだが、キーアサインをまるごと変えることしかできないので、例えば、Shiftキー＋2の「"」を「@」に変更して、日本語キーボード設定のまま、英語キーボードを使うようなことはできないように思われる。
そこで、DvorakJとXKeymacsを組み合わせて対策する。いわゆる常駐ソフトを2つで、キー入力を扱うのは、いささか、動作安定性などの観点では気になる。私が使用している範囲では、時々挙動不審になり、それぞれの常駐ソフトを終了→改めて起動する必要のあることもあった。ただ、致命的というほどではない印象である。
なお、かな漢字入力中(IME起動中)の変換対象の文節区切りの変更(C-i, C-oなど)は、ホストOS上ではMS-IMEの代わりにGoogle日本語入力を使用し、Google日本語入力にWnn風キー設定ファイルをインポートして使用しているが、VDIのWindows10にはAdministrator権限がないため、そもそもGoogle日本語入力をインストールできない。
しかたがないので、古式ゆかしく、MS-IMEのキー設定をしこしこWnn風に変更した。
まず、最近のWindows10のMS-IMEだとキー設定が可能な範囲が狭すぎるので、以前のMS-IMEに戻す。
参考：Windowsを更新したら、IMEでいつものキー設定ができなくなった
次に、MS-IMEのキー設定をしこしこWnn風に変更する。
変更する設定は下記などが参考になる。
参考：MS-IME 98のWnn/Canna風キー設定