Windows10にアップグレードしてみた
前回まででWindows10へのアップグレードの目処が立った（と思っていた）ので、7月の3連休を使って我が家のデスクトップPC2台をWindows7からWindows10にアップグレードすることにした。
ダウンロードサイズが3GBちょっとあるため、事前にダウンロードしておいたWindows10のインストールメディア（ISOファイル）を使ってアップグレードした。ちなみにISOファイルの作成ツールは、下記URLから取得することができる。再インストールやクリーンインストール（一度アップグレードしたマシンは、認証済みとしてクリーンインストールができるようになる）をしたくなった時に必要になるので、今回のアップグレードは直接インストールファイルをダウンロードしながら行う場合でも、ISOファイルは作っておいた方がいい。ただし、7/30以降はメディア作成ツールやISOファイルの「素」となるインストールファイルがダウンロードできない可能性があるので、7/29までに実施しておく方が無難だ。
https://www.microsoft.com/ja-jp/software-download/windows10
↑「ツールを今すぐダウンロード」を押す。「今すぐアップグレード」を押してしまうとアップグレードが始まってしまうので注意。
とりあえず1台目。ファイルサーバ兼メールサーバとVMWareの仮想マシン（Webアプリ用のWindows Serverが入っている）の母艦として運用しているPCからアップグレードを始める。
ISOイメージをマウント（Windows7は標準でISOのマウント機能がないので「Daemon Tools Lite」等を使う）すると、設定にもよるが動作を聞いてくるので「Setup.exeを実行」を選択する。もし自動実行の機能をオフにしている場合は、マウントしたドライブを開いて「Setup.exe」を実行すればいい。
あとは更新プログラムのダウンロードを同時に行うかと、「今のOS環境から何を引き継ぐか」を聞いてくるぐらいで、それらを指定するとインストールが始まる。
インストールのプロセスは、ファイルのコピー→機能とドライバのインストール→環境の移行という流れで、途中で2、3回ほど再起動を行いつつ進んでいく。マシンのスペックやネット環境などによって所要時間は変わってくるが、このPCではだいたい2時間ぐらいかかった。
アップグレードが終わってサインインすると、エラー情報をMSに送信するかとかの初期設定を若干あるが、それが終わるととりあえずアップグレード自体は完了となる。
アップグレードそのものはあっけないほど簡単なのだが、そこで終わらせてくれないのがWindowsというかMicrosoft。ここから諸々の問題を潰す作業が始まることになる。以下は私が遭遇したトラブルと対処について触れていく。
【トラブルその1 ： VMWare Playerの仮想マシンが起動しない】
1台目のPCはファイルサーバ兼Webアプリケーション用のVMWare仮想マシンの母艦ということもあって、普通のデスクトップPCを24時間365日稼働させている（「人でなし！」と言うなかれ）。で、自動更新などの再起動に備えてOSへの自動ログオン後にVMWareの仮想マシンがスタートアップで自動起動するように設定してある。まずはこれが話の前提。で、PCを再起動すると、OSの自動サインインは問題なく引き継がれていたのだが・・・次のVMWare仮想マシンの起動でいきなりエラーが出た。
メッセージをよく読むと、「『VMWare Authorization Service』というサービスが動作していない」ということが分かるので、早速サービスの状態を確認してみる。
・・・なるほど、たしかに該当のサービスは「実行中」になっていない。イベントログを確認すると、サービスの起動に失敗した旨のログが記録されていた。ググってみると、どうもこのトラブルは他でも出ているらしいことが分かった。
とりあえず、手動でサービスを起動して仮想マシンを起動すると、仮想マシンは問題なく起動した。ただ、これでは前述の前提の運用には使えない。ということで、このサービスがOS起動時にちゃんと起動するようにしなければならない。で、サービスの起動設定や「回復」の設定をいじってみたが状況は変わらず。一応、サービスの「スタートアップの種類」を「自動（遅延開始）」にすると、サービスそのものは最終的に自動起動するが、仮想マシンの起動には間に合っていないらしくエラーは回避できなかった。
そこで、タスクスケジューラにシステム起動時にサービスを起動するようなタスクを作成してみた。
この状態でPCを再起動すると、今度はサインイン後に自動的に仮想マシンが正常に起動した。
まずは問題が一つ解決した・・・と思っていたのだが、VMWare絡みのトラブルはまだまだ続くのであった。
【トラブルその2 ： VMWare Playerの仮想マシンがネットワークに接続できない】
文字通りなのだが、仮想マシンがネットワークに接続できなくなった。
原因は、VMWare Playerでは仮想マシンが「ブリッジ接続」でネットワークに接続する際には「VMWare Bridge Protocol」というネットワークアダプタにバインドされたサービス（「Protocol」なのに「サービス」とはこれいかに？と言う話は置いといて）を介して行う（「NAT接続」の場合はどうか分からないが）のだが、Windows10にアップグレードするとこれが引き継がれないためだ。まったく、何してくれてるんだろうね、Windows10は（怒）。
なので、ローカルエリアネットワーク接続のプロパティを開き、「インストール」→「サービス」で製造元を「VMWare, Inc.」を選択すると「VMWare Bridge Protocol」があるので、これをインストールする。
なお、「VMWare Bridge Protocol」をインストールし直す前に仮想マシンを起動すると、仮想マシンのネットワーク接続がオフになるので、仮想マシンを起動する前にこの手順を行った方が手間が少ない。もし、先に仮想マシンを起動してしまった場合は、手動で仮想マシンのネットワークを接続し直せば解決する。
【トラブルその3 ： VMWare PlayerにインポートしたXPモードが使えない】
XPモードはWindows7固有の機能なので、Windows10にアップグレードすれば使えなくなる。これは当たり前。なので、事前準備としてVMWare PlayerにXPモードをインポートしておいたのだが、いざ起動してみると・・・・
「なんじゃこりゃああああああああああああああ！！！！（by 松田優作）」
なんと言うことだ。折角インポートしたXPモードが起動しないではないか。
理屈的には、XPモードは「Windows7で（移行期のために）限定的にWindowsXPを使えるようにした」ものなので、他のOSでの動作を許可しない、ということなのだろうが、何もそこまでしなくてもいいのに・・・。世の中には「自己責任」という言葉もあるではないか、と言いたいが、出来ないものはどうしようもない。
これに関しては、残念ながら回避方法はない。次善の策としては、「WindowsXPのメディアとライセンスを持っている」という条件は付くが、VMWare Playerに「本物の」Windows XPをインストールして環境を構築し直すしかない（私はそれで対処した）。これでも「ユニティ」も使えるので。
参考までに、WindowsXPの「Windows Update」は今でも機能していて、少なくともOSがSP3以上になっていればパッチをダウンロードすることができる。注意点としては、XPのIEはバージョンが6なのでデフォルトではTLSが有効になっていないため、そのままWindows Updateを実行してもエラーになる（SSLとTLSの話は本題ではないのでここでは割愛する）。なので「インターネット オプション」の「詳細設定」で「TLS1.0」を有効にして「SSL1.0」「SSL2.0」「SSL3.0」を無効にしてやるとアップデートできるようになる。
【トラブルその4 ： Wake on LAN(WOL)が使えなくなった】
これはRealtec社のNICを使っているユーザ限定のトラブルかも知れないが、Windows10にアップグレードしてからWOLが使えなくなった。最初は「たまにはこういうこともあるだろう」と軽く考えていたが、何度WOLを試してもPCが起動してこない。
で、ググって見ると一発で原因が判明した。Windows10が標準でインストールするRealtecのNIC用ドライバーにどうやら不具合があるらしいとのこと。Windows8.1用、もしくはWindows10用のドライバをメーカーのサイトからダウンロードして入れ替えてやることで解決したという情報があったので早速Windows10用のドライバをインストールしてみると、先程までの状態が嘘みたいにWOLが復活した。ぶっちゃけ、今日が休日だったのと、自宅に居る時でもPCの電源投入はWOLで行っていたのですぐに異常が判明したが、もし気づかないまま外出先で自宅PCにアクセスする必要が生じていたらアウトだったと思うと、この時点でトラブルを潰せたのは運が良かったと思う。
【トラブルではないが、ちょっとがっかりしたこと】
これはWindows8かららしいが、「サインイン」「サインアウト」「シャットダウン」の際のサウンドが鳴らないようになってしまった。色々調べてみて、レジストリを変更するとコントロールパネルのイベント音設定項目に「ログオン時」等を表示させる（＆サウンドを設定して「テスト」で音を鳴らす）事はできる（ネット情報では、これでちゃんと音が出るようになったとの話もある）のだが、実際には音が鳴らない。何でわざわざこれらを使えなくしたのかは分からないが、サインアウトはともかく、サインインとシャットダウンの音が鳴らないのは個人的には少し不便を感じる。これが「システム的に出来なくなった」のか「設定で機能を無効にしているのか」分からないが、時間のある時に調べてみようと思う。
他にも、細々としたトラブルはあったものの、何とかPC2台のアップグレードが無事に（？）終了した。ほぼ丸一日かかったので、やはり連休に実施したのは正解だったと思っている。
最後に、Windows10を少し使ってみての感想を。
起動や動作はWindows7と遜色ないと言っても過言ではないほどサクサクと動いている。インタフェースもWindows7に比較的近いので、それほど操作方法で迷うことは少ない。「Quick Launch」も使えるので、これまでと使い勝手はさほど変わらない。あと、これは個体差もあるので保証の限りではないが、Office2003とかVB6で作ったプログラムのような古いアプリケーションやプログラムも比較的動作している。
今のところの感触としては、新しいOSだけに挙動の怪しい部分が多少あるものの、思っていたよりは「良いOS」なんじゃないかと思う。そういう意味では、マイクロソフトは強引な「強制アップグレード」とか、余計な事はやらない方が良かったのに。Windows10はあれでかなり反感を買った（≒評価を落とした）と思うし、しなくてもいい「損」をしたんじゃないかな。
おしまい。
ダウンロードサイズが3GBちょっとあるため、事前にダウンロードしておいたWindows10のインストールメディア（ISOファイル）を使ってアップグレードした。ちなみにISOファイルの作成ツールは、下記URLから取得することができる。再インストールやクリーンインストール（一度アップグレードしたマシンは、認証済みとしてクリーンインストールができるようになる）をしたくなった時に必要になるので、今回のアップグレードは直接インストールファイルをダウンロードしながら行う場合でも、ISOファイルは作っておいた方がいい。ただし、7/30以降はメディア作成ツールやISOファイルの「素」となるインストールファイルがダウンロードできない可能性があるので、7/29までに実施しておく方が無難だ。
https://www.microsoft.com/ja-jp/software-download/windows10
↑「ツールを今すぐダウンロード」を押す。「今すぐアップグレード」を押してしまうとアップグレードが始まってしまうので注意。
とりあえず1台目。ファイルサーバ兼メールサーバとVMWareの仮想マシン（Webアプリ用のWindows Serverが入っている）の母艦として運用しているPCからアップグレードを始める。
ISOイメージをマウント（Windows7は標準でISOのマウント機能がないので「Daemon Tools Lite」等を使う）すると、設定にもよるが動作を聞いてくるので「Setup.exeを実行」を選択する。もし自動実行の機能をオフにしている場合は、マウントしたドライブを開いて「Setup.exe」を実行すればいい。
あとは更新プログラムのダウンロードを同時に行うかと、「今のOS環境から何を引き継ぐか」を聞いてくるぐらいで、それらを指定するとインストールが始まる。
インストールのプロセスは、ファイルのコピー→機能とドライバのインストール→環境の移行という流れで、途中で2、3回ほど再起動を行いつつ進んでいく。マシンのスペックやネット環境などによって所要時間は変わってくるが、このPCではだいたい2時間ぐらいかかった。
アップグレードが終わってサインインすると、エラー情報をMSに送信するかとかの初期設定を若干あるが、それが終わるととりあえずアップグレード自体は完了となる。
アップグレードそのものはあっけないほど簡単なのだが、そこで終わらせてくれないのがWindowsというかMicrosoft。ここから諸々の問題を潰す作業が始まることになる。以下は私が遭遇したトラブルと対処について触れていく。
【トラブルその1 ： VMWare Playerの仮想マシンが起動しない】
1台目のPCはファイルサーバ兼Webアプリケーション用のVMWare仮想マシンの母艦ということもあって、普通のデスクトップPCを24時間365日稼働させている（「人でなし！」と言うなかれ）。で、自動更新などの再起動に備えてOSへの自動ログオン後にVMWareの仮想マシンがスタートアップで自動起動するように設定してある。まずはこれが話の前提。で、PCを再起動すると、OSの自動サインインは問題なく引き継がれていたのだが・・・次のVMWare仮想マシンの起動でいきなりエラーが出た。
メッセージをよく読むと、「『VMWare Authorization Service』というサービスが動作していない」ということが分かるので、早速サービスの状態を確認してみる。
・・・なるほど、たしかに該当のサービスは「実行中」になっていない。イベントログを確認すると、サービスの起動に失敗した旨のログが記録されていた。ググってみると、どうもこのトラブルは他でも出ているらしいことが分かった。
とりあえず、手動でサービスを起動して仮想マシンを起動すると、仮想マシンは問題なく起動した。ただ、これでは前述の前提の運用には使えない。ということで、このサービスがOS起動時にちゃんと起動するようにしなければならない。で、サービスの起動設定や「回復」の設定をいじってみたが状況は変わらず。一応、サービスの「スタートアップの種類」を「自動（遅延開始）」にすると、サービスそのものは最終的に自動起動するが、仮想マシンの起動には間に合っていないらしくエラーは回避できなかった。
そこで、タスクスケジューラにシステム起動時にサービスを起動するようなタスクを作成してみた。
この状態でPCを再起動すると、今度はサインイン後に自動的に仮想マシンが正常に起動した。
まずは問題が一つ解決した・・・と思っていたのだが、VMWare絡みのトラブルはまだまだ続くのであった。
【トラブルその2 ： VMWare Playerの仮想マシンがネットワークに接続できない】
文字通りなのだが、仮想マシンがネットワークに接続できなくなった。
原因は、VMWare Playerでは仮想マシンが「ブリッジ接続」でネットワークに接続する際には「VMWare Bridge Protocol」というネットワークアダプタにバインドされたサービス（「Protocol」なのに「サービス」とはこれいかに？と言う話は置いといて）を介して行う（「NAT接続」の場合はどうか分からないが）のだが、Windows10にアップグレードするとこれが引き継がれないためだ。まったく、何してくれてるんだろうね、Windows10は（怒）。
なので、ローカルエリアネットワーク接続のプロパティを開き、「インストール」→「サービス」で製造元を「VMWare, Inc.」を選択すると「VMWare Bridge Protocol」があるので、これをインストールする。
なお、「VMWare Bridge Protocol」をインストールし直す前に仮想マシンを起動すると、仮想マシンのネットワーク接続がオフになるので、仮想マシンを起動する前にこの手順を行った方が手間が少ない。もし、先に仮想マシンを起動してしまった場合は、手動で仮想マシンのネットワークを接続し直せば解決する。
【トラブルその3 ： VMWare PlayerにインポートしたXPモードが使えない】
XPモードはWindows7固有の機能なので、Windows10にアップグレードすれば使えなくなる。これは当たり前。なので、事前準備としてVMWare PlayerにXPモードをインポートしておいたのだが、いざ起動してみると・・・・
「なんじゃこりゃああああああああああああああ！！！！（by 松田優作）」
なんと言うことだ。折角インポートしたXPモードが起動しないではないか。
理屈的には、XPモードは「Windows7で（移行期のために）限定的にWindowsXPを使えるようにした」ものなので、他のOSでの動作を許可しない、ということなのだろうが、何もそこまでしなくてもいいのに・・・。世の中には「自己責任」という言葉もあるではないか、と言いたいが、出来ないものはどうしようもない。
これに関しては、残念ながら回避方法はない。次善の策としては、「WindowsXPのメディアとライセンスを持っている」という条件は付くが、VMWare Playerに「本物の」Windows XPをインストールして環境を構築し直すしかない（私はそれで対処した）。これでも「ユニティ」も使えるので。
参考までに、WindowsXPの「Windows Update」は今でも機能していて、少なくともOSがSP3以上になっていればパッチをダウンロードすることができる。注意点としては、XPのIEはバージョンが6なのでデフォルトではTLSが有効になっていないため、そのままWindows Updateを実行してもエラーになる（SSLとTLSの話は本題ではないのでここでは割愛する）。なので「インターネット オプション」の「詳細設定」で「TLS1.0」を有効にして「SSL1.0」「SSL2.0」「SSL3.0」を無効にしてやるとアップデートできるようになる。
【トラブルその4 ： Wake on LAN(WOL)が使えなくなった】
これはRealtec社のNICを使っているユーザ限定のトラブルかも知れないが、Windows10にアップグレードしてからWOLが使えなくなった。最初は「たまにはこういうこともあるだろう」と軽く考えていたが、何度WOLを試してもPCが起動してこない。
で、ググって見ると一発で原因が判明した。Windows10が標準でインストールするRealtecのNIC用ドライバーにどうやら不具合があるらしいとのこと。Windows8.1用、もしくはWindows10用のドライバをメーカーのサイトからダウンロードして入れ替えてやることで解決したという情報があったので早速Windows10用のドライバをインストールしてみると、先程までの状態が嘘みたいにWOLが復活した。ぶっちゃけ、今日が休日だったのと、自宅に居る時でもPCの電源投入はWOLで行っていたのですぐに異常が判明したが、もし気づかないまま外出先で自宅PCにアクセスする必要が生じていたらアウトだったと思うと、この時点でトラブルを潰せたのは運が良かったと思う。
【トラブルではないが、ちょっとがっかりしたこと】
これはWindows8かららしいが、「サインイン」「サインアウト」「シャットダウン」の際のサウンドが鳴らないようになってしまった。色々調べてみて、レジストリを変更するとコントロールパネルのイベント音設定項目に「ログオン時」等を表示させる（＆サウンドを設定して「テスト」で音を鳴らす）事はできる（ネット情報では、これでちゃんと音が出るようになったとの話もある）のだが、実際には音が鳴らない。何でわざわざこれらを使えなくしたのかは分からないが、サインアウトはともかく、サインインとシャットダウンの音が鳴らないのは個人的には少し不便を感じる。これが「システム的に出来なくなった」のか「設定で機能を無効にしているのか」分からないが、時間のある時に調べてみようと思う。
他にも、細々としたトラブルはあったものの、何とかPC2台のアップグレードが無事に（？）終了した。ほぼ丸一日かかったので、やはり連休に実施したのは正解だったと思っている。
最後に、Windows10を少し使ってみての感想を。
起動や動作はWindows7と遜色ないと言っても過言ではないほどサクサクと動いている。インタフェースもWindows7に比較的近いので、それほど操作方法で迷うことは少ない。「Quick Launch」も使えるので、これまでと使い勝手はさほど変わらない。あと、これは個体差もあるので保証の限りではないが、Office2003とかVB6で作ったプログラムのような古いアプリケーションやプログラムも比較的動作している。
今のところの感触としては、新しいOSだけに挙動の怪しい部分が多少あるものの、思っていたよりは「良いOS」なんじゃないかと思う。そういう意味では、マイクロソフトは強引な「強制アップグレード」とか、余計な事はやらない方が良かったのに。Windows10はあれでかなり反感を買った（≒評価を落とした）と思うし、しなくてもいい「損」をしたんじゃないかな。
おしまい。
Windows10へのアップグレードの準備をしてみた（その3・リモートコントロールソフトを試してみる）
Windows10に移行する際に障壁となるもののうち、XPモードの移行については前回で解決した。
もう一つの大きな問題は、いわゆる「リモートコントロールソフト」と呼ばれる、PCを遠隔操作できるソフトで、現在使っている「pcAnywhere」がWindows10に対応しておらず、かつ、新規開発を中止してしまったため、事実上Windows10では使えないことだ。
リモートコントロールならばWindows標準の「リモートデスクトップ」を使えばいいのでは？と思われるかもしれないがさにあらず。「リモートデスクトップ」というのは乱暴な言い方をすれば「リモートコントロールソフト『もどき』」なのだ。どういうことかというと、リモートデスクトップで表示されている画面というのは、操作対象となっているPCのデスクトップ画面をそのまま表示している訳ではなく、別のセッションを作ることで擬似的にリモートPCのデスクトップと同じ環境を作り出している（ちなみに、リモートデスクトップで接続している間、リモートPCのデスクトップは「ロック」状態となる）。そのため、一部のソフトがリモートデスクトップ上では動作しない（たとえば、DVD等の書き込みソフトなど）。
また、リモートデスクトップでは「ログオン前」の画面を操作することはできない。それに対して、「pcAnywhere」等のリモートコントロールソフトは、操作対象となっているPC（以下、「リモートクライアント」）のデスクトップ画面をそのまま転送し、また、キーボードやマウス入力をリモートクライアントに直接送る。要は、リモートコントロールソフト上でマウスを動かすと、リモートPCのデスクトップ上でも同じようにマウスが動く、と言う訳だ。つまり、本当の意味でのリモートコントロールを実現している。
前置きが長くなったが（毎回同じ事を言っているような・・・）、ここで問題になるのは、リモートデスクトップでは一部のソフトが動作しないため、そのソフトを利用する場合にリモートからの操作ができないということなのだ。そのため、本物のリモートコントロールソフトである「pcAnywhere」と使い分けをしていた、というのがこれまでの運用。Windows10で同等のことをするためには、Windows10に対応したリモートコントロールソフトを導入する必要がある。これには大きく分けて2つの方法がある。
まず一つは、Windows10に対応した有償のソフトを導入すること。今だと「Laplink」あたりがそれに該当するが、有償というだけあって当然お金がかかる。しかも、リモートPCの台数＋コントロールするPCの台数分のライセンスが必要となり、Amazonあたりで調べてみても結構なお値段がする（まあ、2ライセンスで1万円半ばぐらいなのだが）。なので、できればこの方法は執りたくない。
そうなると、もう一つの方法を選択することになる。ここまで書けば察しは付くと思うが、無償のリモートコントロールソフトを探して導入する方法だ。
要件としては
・ログオン前の状態から操作可能であること
・「本物の」デスクトップを操作できること
の2点（ぶっちゃけ、言ってることは同じ事なのだが）を満たすソフトが必要となる。
と言うことで、ネットを探してみると「brynhildr（ブリュンヒルデ）」というフリーのリモートコントロールソフトが良さそうだということで、これを試してみることにした。
まず、「brynhildr」をダウンロードする必要がある。以下のサイトからダウンロードする。
http://blog.x-row.net/?p=2455&comment=1
ダウンロードしたZIPファイルを展開すると、3つのファイルが取得できる。これを適当なフォルダに格納する。
なお、Brynhildrはクライアント（操作する側）、サーバ（操作される側）共に同じソフトを使うので、操作するPCと操作されるPCの両方にこれらのファイルを置く必要がある。
準備が出来たところで、まずサーバ側から。なお、前提条件として、リモートPC側は「実際のコンソールで」ログオンした状態（リモートデスクトップでのログオンではなく）としておくこと。
ダウンロードしたファイルの中から「brynhildr.exe」を起動する。
起動すると、下図のウィンドウが表示される。
設定する箇所は2点。
・Mode ... 「Server」に変更する。これで「サーバモード（操作される側）」として動作する。
・Password ... 待ち受けのパスワードを入力する。
「Port」は待ち受けのポート番号だが、デフォルトの「55500」で問題なければ変更する必要はない。「Control」は「On（デフォルト値）」にしておかないと、リモートPCの操作ができないので注意。
設定したら、「OK」ボタンを押すと、Brynhildrがサーバモードで動作する。なお、初回実行時には、Windowsファイアウォールが通信を許可するか聞いてくる（Windowsファイアウォールを使っている場合）ので、許可するようにする。その際、「パブリック ネットワーク」には許可しない方が無難だ（というより、普通は必要ない）。
Brynhildrがサーバモードで起動数と、タスクトレイに下図のようなアイコン（赤で囲った黒三角のアイコン）が表示される。とりあえずこれで、Brynhildrはサーバモードで動作した。
次はクライアント側。
サーバ側と同じく、ダウンロードしたファイルの中から「brynhildr.exe」を起動する。
Brynhildrのウィンドウが表示されるので、下図のように設定する。
最低限設定する項目は3点。
・Mode ... 「Client」を選択する
・IP ... リモートPCのIPアドレスを入力する
・Password ... リモートPC側で設定したものと同じパスワードを入力する
「OK」ボタンを押すと、通信に問題がなければクライアントウィンドウが表示される。なお、リモートPC側と同じように、初回起動時にはWindowsファイアウォールを許可する必要がある。
これでリモートPCの画面が表示されればめでたしめでたし・・・と言いたいところなのだが、実はまだ問題がある。
ここで一度Brynhildrのクライアントウィンドウを閉じ、リモートPCにリモートデスクトップで接続後切断（もしくは、リモートPCのコンソールから「ロック」を選択してもよい）して、再度Brynhildrのクライアント接続を試みると・・・クライアントウィンドウは表示されるがウィンドウ内の画面は真っ黒になるはずだ。
これは何故かというと、先程リモートPC側で起動したBrynhildrは、単なる「デスクトップアプリケーション」と同じ位置づけにあるためで、リモートデスクトップ等を使ってデスクトップを「ロック」してしまうと正しく動作することができないためだ。更に言えば、同様の理由で前述のBrynhildrの動作では、ログオン前の状態を操作することはできない。それではBrynhildrとリモートデスクトップは両立出来ないのか？と思われるかもしれないが、さにあらず。解決方法はある。
結論から先に言えば、リモートPC側のBrynhildrをWindowsの「サービス」として動作するように変更すればよい。その手順を見てゆく。
まず、リモートPC側で起動しているBrynhildrサーバを終了させる。タスクトレイ上のBrynhildrのアイコンを右クリックして、メニューから「Quit」を選択すればBrynhildrが終了する。これはリモートデスクトップから行っても、実際のコンソールから行ってもよい（もっと簡単な方法は、一度リモートPCを再起動することだが）。
次に、リモートPC側の「Brynhildr.exe」を「管理者として実行」で起動する（ここが肝）。なお、Brynhildrのフォルダにファイルが増えているが、一度Brynhildrを起動すると生成されるファイル類なので気にしなくても良い。
Brynhildrを起動したら、前述の設定（モード、パスワード）に加えて、「Service」の設定を行う。
ちなみに先程Brynhildrを普通に起動した時は、「Service」のプルダウンは「------」しか表示されなかったはずだが、今度は「Entry」という選択肢が追加されるので、これを選択する。設定が終わったら「OK」ボタンを押す。
今度はタスクトレイにBrynhildrのアイコンは表示されないが、慌てることなかれ。Windowsの「サービス」を確認すると、下図のように「Brynhildr」が登録されているはずだ。
これで、Brynhildrがサービスとして動作することになるため、ログオン前の状態からリモートPCの操作が可能になる。なお、最初にBrynhildr.exeを普通に起動してみたが、これは「Brynhildr.exeを普通に起動するとこういう挙動を示す」ということを見せるためのものなので、最初からサービスとして登録する手順を実行しても、もちろん問題はない。
Brynhildrがサービスとして起動しているので、下図のようにログオン前の状態から画面の表示及び操作が可能になる。
なお、「Ctrl+Alt+Del」キーのような特殊なキーをBrynhildrに送信するための方法としては、下図のようにBrynhildrのクライアントウィンドウのタイトルバー左端のアイコンを右クリックするとメニューが表示されるので、その中から「SendKeys」→「Ctrl + Alt + Del」を選択してやればよい。あと、ウィンドウサイズが小さい場合は、同じくこのメニュー上の「WindowScale」で表示倍率を変更することで大きさを変えることができる。
これでBrynhildrが普通に使えるようになった。
さて、気になるパフォーマンスだが、pcAnywhere等と厳密に比較してみた訳ではないのであくまでも体感レベルの話になるが、有線接続であれば実用には十分なパフォーマンスは出ていると思う。たまに「もっさり」とした動きをする気がするが、個人的にはそれほど気にならなかった。
今回、設定に関してはほとんどデフォルト値を使用したが、Brynhildrには設定項目が数多くあるので、設定次第では更なるチューニングも可能かと思われる。この辺りはBrynhildrのサイト等を参考にしてもらいたい。
ともあれ、Windows7→Windows10へ移行するための比較的大きな障壁はこれで一応クリアできた。
多分、それでも細々としたツールなどの古いソフトのいくつかはWindows10上でちゃんと動作しないかもしれないが、その時はその時ということで、7月の3連休あたりにWindows10へのアップグレードを実施しようと思っている。
おしまい。
【余談】
2016/7/1時点で発売中の「日経PC21」の記事を読むと、一度Windows10にアップグレード（＋アクティベーション）すれば、そのPCをWindows7/8.1に戻してもWindows10のアクティベーション情報は残るそうなので（つまり、無償アップグレード期間の7/29以降であっても、そのPCに関しては無償でWindows10をインストールできる）、「とりあえずWindows10にアップグレードして、ちゃんと動かなかったら元のWindowsに戻す」という手を使ってもよさそうだ。
もう一つの大きな問題は、いわゆる「リモートコントロールソフト」と呼ばれる、PCを遠隔操作できるソフトで、現在使っている「pcAnywhere」がWindows10に対応しておらず、かつ、新規開発を中止してしまったため、事実上Windows10では使えないことだ。
リモートコントロールならばWindows標準の「リモートデスクトップ」を使えばいいのでは？と思われるかもしれないがさにあらず。「リモートデスクトップ」というのは乱暴な言い方をすれば「リモートコントロールソフト『もどき』」なのだ。どういうことかというと、リモートデスクトップで表示されている画面というのは、操作対象となっているPCのデスクトップ画面をそのまま表示している訳ではなく、別のセッションを作ることで擬似的にリモートPCのデスクトップと同じ環境を作り出している（ちなみに、リモートデスクトップで接続している間、リモートPCのデスクトップは「ロック」状態となる）。そのため、一部のソフトがリモートデスクトップ上では動作しない（たとえば、DVD等の書き込みソフトなど）。
また、リモートデスクトップでは「ログオン前」の画面を操作することはできない。それに対して、「pcAnywhere」等のリモートコントロールソフトは、操作対象となっているPC（以下、「リモートクライアント」）のデスクトップ画面をそのまま転送し、また、キーボードやマウス入力をリモートクライアントに直接送る。要は、リモートコントロールソフト上でマウスを動かすと、リモートPCのデスクトップ上でも同じようにマウスが動く、と言う訳だ。つまり、本当の意味でのリモートコントロールを実現している。
前置きが長くなったが（毎回同じ事を言っているような・・・）、ここで問題になるのは、リモートデスクトップでは一部のソフトが動作しないため、そのソフトを利用する場合にリモートからの操作ができないということなのだ。そのため、本物のリモートコントロールソフトである「pcAnywhere」と使い分けをしていた、というのがこれまでの運用。Windows10で同等のことをするためには、Windows10に対応したリモートコントロールソフトを導入する必要がある。これには大きく分けて2つの方法がある。
まず一つは、Windows10に対応した有償のソフトを導入すること。今だと「Laplink」あたりがそれに該当するが、有償というだけあって当然お金がかかる。しかも、リモートPCの台数＋コントロールするPCの台数分のライセンスが必要となり、Amazonあたりで調べてみても結構なお値段がする（まあ、2ライセンスで1万円半ばぐらいなのだが）。なので、できればこの方法は執りたくない。
そうなると、もう一つの方法を選択することになる。ここまで書けば察しは付くと思うが、無償のリモートコントロールソフトを探して導入する方法だ。
要件としては
・ログオン前の状態から操作可能であること
・「本物の」デスクトップを操作できること
の2点（ぶっちゃけ、言ってることは同じ事なのだが）を満たすソフトが必要となる。
と言うことで、ネットを探してみると「brynhildr（ブリュンヒルデ）」というフリーのリモートコントロールソフトが良さそうだということで、これを試してみることにした。
まず、「brynhildr」をダウンロードする必要がある。以下のサイトからダウンロードする。
http://blog.x-row.net/?p=2455&comment=1
ダウンロードしたZIPファイルを展開すると、3つのファイルが取得できる。これを適当なフォルダに格納する。
なお、Brynhildrはクライアント（操作する側）、サーバ（操作される側）共に同じソフトを使うので、操作するPCと操作されるPCの両方にこれらのファイルを置く必要がある。
準備が出来たところで、まずサーバ側から。なお、前提条件として、リモートPC側は「実際のコンソールで」ログオンした状態（リモートデスクトップでのログオンではなく）としておくこと。
ダウンロードしたファイルの中から「brynhildr.exe」を起動する。
起動すると、下図のウィンドウが表示される。
設定する箇所は2点。
・Mode ... 「Server」に変更する。これで「サーバモード（操作される側）」として動作する。
・Password ... 待ち受けのパスワードを入力する。
「Port」は待ち受けのポート番号だが、デフォルトの「55500」で問題なければ変更する必要はない。「Control」は「On（デフォルト値）」にしておかないと、リモートPCの操作ができないので注意。
設定したら、「OK」ボタンを押すと、Brynhildrがサーバモードで動作する。なお、初回実行時には、Windowsファイアウォールが通信を許可するか聞いてくる（Windowsファイアウォールを使っている場合）ので、許可するようにする。その際、「パブリック ネットワーク」には許可しない方が無難だ（というより、普通は必要ない）。
Brynhildrがサーバモードで起動数と、タスクトレイに下図のようなアイコン（赤で囲った黒三角のアイコン）が表示される。とりあえずこれで、Brynhildrはサーバモードで動作した。
次はクライアント側。
サーバ側と同じく、ダウンロードしたファイルの中から「brynhildr.exe」を起動する。
Brynhildrのウィンドウが表示されるので、下図のように設定する。
最低限設定する項目は3点。
・Mode ... 「Client」を選択する
・IP ... リモートPCのIPアドレスを入力する
・Password ... リモートPC側で設定したものと同じパスワードを入力する
「OK」ボタンを押すと、通信に問題がなければクライアントウィンドウが表示される。なお、リモートPC側と同じように、初回起動時にはWindowsファイアウォールを許可する必要がある。
これでリモートPCの画面が表示されればめでたしめでたし・・・と言いたいところなのだが、実はまだ問題がある。
ここで一度Brynhildrのクライアントウィンドウを閉じ、リモートPCにリモートデスクトップで接続後切断（もしくは、リモートPCのコンソールから「ロック」を選択してもよい）して、再度Brynhildrのクライアント接続を試みると・・・クライアントウィンドウは表示されるがウィンドウ内の画面は真っ黒になるはずだ。
これは何故かというと、先程リモートPC側で起動したBrynhildrは、単なる「デスクトップアプリケーション」と同じ位置づけにあるためで、リモートデスクトップ等を使ってデスクトップを「ロック」してしまうと正しく動作することができないためだ。更に言えば、同様の理由で前述のBrynhildrの動作では、ログオン前の状態を操作することはできない。それではBrynhildrとリモートデスクトップは両立出来ないのか？と思われるかもしれないが、さにあらず。解決方法はある。
結論から先に言えば、リモートPC側のBrynhildrをWindowsの「サービス」として動作するように変更すればよい。その手順を見てゆく。
まず、リモートPC側で起動しているBrynhildrサーバを終了させる。タスクトレイ上のBrynhildrのアイコンを右クリックして、メニューから「Quit」を選択すればBrynhildrが終了する。これはリモートデスクトップから行っても、実際のコンソールから行ってもよい（もっと簡単な方法は、一度リモートPCを再起動することだが）。
次に、リモートPC側の「Brynhildr.exe」を「管理者として実行」で起動する（ここが肝）。なお、Brynhildrのフォルダにファイルが増えているが、一度Brynhildrを起動すると生成されるファイル類なので気にしなくても良い。
Brynhildrを起動したら、前述の設定（モード、パスワード）に加えて、「Service」の設定を行う。
ちなみに先程Brynhildrを普通に起動した時は、「Service」のプルダウンは「------」しか表示されなかったはずだが、今度は「Entry」という選択肢が追加されるので、これを選択する。設定が終わったら「OK」ボタンを押す。
今度はタスクトレイにBrynhildrのアイコンは表示されないが、慌てることなかれ。Windowsの「サービス」を確認すると、下図のように「Brynhildr」が登録されているはずだ。
これで、Brynhildrがサービスとして動作することになるため、ログオン前の状態からリモートPCの操作が可能になる。なお、最初にBrynhildr.exeを普通に起動してみたが、これは「Brynhildr.exeを普通に起動するとこういう挙動を示す」ということを見せるためのものなので、最初からサービスとして登録する手順を実行しても、もちろん問題はない。
Brynhildrがサービスとして起動しているので、下図のようにログオン前の状態から画面の表示及び操作が可能になる。
なお、「Ctrl+Alt+Del」キーのような特殊なキーをBrynhildrに送信するための方法としては、下図のようにBrynhildrのクライアントウィンドウのタイトルバー左端のアイコンを右クリックするとメニューが表示されるので、その中から「SendKeys」→「Ctrl + Alt + Del」を選択してやればよい。あと、ウィンドウサイズが小さい場合は、同じくこのメニュー上の「WindowScale」で表示倍率を変更することで大きさを変えることができる。
これでBrynhildrが普通に使えるようになった。
さて、気になるパフォーマンスだが、pcAnywhere等と厳密に比較してみた訳ではないのであくまでも体感レベルの話になるが、有線接続であれば実用には十分なパフォーマンスは出ていると思う。たまに「もっさり」とした動きをする気がするが、個人的にはそれほど気にならなかった。
今回、設定に関してはほとんどデフォルト値を使用したが、Brynhildrには設定項目が数多くあるので、設定次第では更なるチューニングも可能かと思われる。この辺りはBrynhildrのサイト等を参考にしてもらいたい。
ともあれ、Windows7→Windows10へ移行するための比較的大きな障壁はこれで一応クリアできた。
多分、それでも細々としたツールなどの古いソフトのいくつかはWindows10上でちゃんと動作しないかもしれないが、その時はその時ということで、7月の3連休あたりにWindows10へのアップグレードを実施しようと思っている。
おしまい。
【余談】
2016/7/1時点で発売中の「日経PC21」の記事を読むと、一度Windows10にアップグレード（＋アクティベーション）すれば、そのPCをWindows7/8.1に戻してもWindows10のアクティベーション情報は残るそうなので（つまり、無償アップグレード期間の7/29以降であっても、そのPCに関しては無償でWindows10をインストールできる）、「とりあえずWindows10にアップグレードして、ちゃんと動かなかったら元のWindowsに戻す」という手を使ってもよさそうだ。
Windows10へのアップグレードの準備をしてみた（その2・XPモードをVMWareに移行 後編）
前回は、XPモードをVMWare Playerに移行する所まで話が進んだので、今回はもう一歩進めて「VMWare Player上のアプリケーションをローカルアプリケーション『風』に使う」方法について。ここで「風」と書いたのは、この先を読んでいただければ分かると思うが、「本家」のXPモードに比べると若干の手順が必要になるため、完全にイコールとはならないということを意味している。
前置きはそのぐらいにして、本題へ。
これは説明の必要はないと思うが、VMWare上のXPモード（インポートしたもの：以下、「XPモード」）上でメモ帳を動作させている状態。別段、これと言って特別なものではない。無論、この状態でもXPモード上のアプリケーションを普通に使うことはできる。まあ、XPモードの画面解像度を上げたり、「フルスクリーンモード」で動かせばそれはそれで別段不便はないのだが、VMWare Playerを起動するという操作を行わなければならない分、一手間余計にかかる（大した手間でないと言ってしまえばそれまでだが）ので、もう少しだけ楽をしようというのが今回の話になる。
具体的には、上のメモ帳を
こんな感じで（といってもデスクトップが写っていないんで分かりづらいが）使おう、というものだ。
VMWare Playerには、それを実現するために「ユニティ」という機能がある。「ユニティ」を使うと、VMWare Player上の仮想マシンでで動作するアプリケーションを、あたかもローカルアプリケーションのように使うことが出来る（「ユニティ」の正確な機能についての説明は割愛する。実際には「十分に理解していない」だけなのだが。また、「ユニティ」がどのOSなら対応しているのかは不明。詳しく知りたい方はググってください）。本家XPモードのような機能なのだが、本家との大きな違いとしては、本家では「XPモードの初期設定後にインストールしたアプリケーション」しかローカル（もどき）で使うことが出来なかったのに対して、こちらは上図のようにメモ帳とかペイントなど、「スタート」メニューから呼び出せるアプリケーションは（多分）全て使える点がある。
では、「ユニティ」を使うための手順を見ていく。なお、「ユニティ」を使うためには「VMWare Tools」がインストールされている必要がある。
まずは、通常通りにVMWare Playerを起動して（あ、待って、そこで読むのを止めないで！）、XPモードの仮想マシンを起動する。これは最低一回はやらなければならない手順になる。
XPモードの仮想マシンが起動したら、VMWare Playerの「Player」メニューから「ユニティ」を選択する。ちなみに、ここで既にアプリケーションが立ち上がっていると、この操作のあと、そのアプリケーションがローカルアプリのような見栄えになる。
「ユニティ」を実行すると、VMWare Playerのアプリケーションウィンドウ（仮想マシンを表示しているウィンドウ）が消えて、画面左下に下図のようなウィンドウ（実際にはメニューなのだが）が表示される。
なお、上図のウィンドウが消えてしまった場合（数秒経つと表示が消える）は、「Ctrl」＋「Shift」＋「U」キーを押すことで再度表示させることができる。ここからが今回の話の肝になる部分だが、このメニューからアプリケーションを起動することになる。
上のウィンドウ（以下「ユニティのメニュー」）は、ウィンドウズで言うところの「スタートボタン」と同じ働きをする。
つまり、これをくりっくすると下図のような感じになる。
見ての通り、まんま「スタートメニュー」と同じ動きをする。ちなみに上図に写っているメモ帳とMS-IMEは、XPモードのものだ。で、ここで目的のメニュー（今回は「メモ帳」）を選択すると、そのアプリケーションが、あたかもローカルで起動したように起動するという訳だ。ちなみに、「ユニティ」を使って起動したアプリケーションのタイトルバーには、それを示すマーク（四角形が重なったようなマーク）が表示されるので、それによって本物のローカルアプリケーションとの区別が付けられる。
では、「ユニティ（で起動した仮想マシン上のアプリケーション）」を完全に終わらせるにはどうすればよいか。起動しているアプリケーションを「×」ボタンで閉じるだけでは、仮想マシン自体は終了しない。ここは本家XPモードとの違いなので注意が必要（本家の場合は、アプリケーションを閉じると、自動的にOSが休止状態になる）。終了のさせ方は、大雑把に言うと
・「ユニティ」を終了して仮想マシンのウィンドウに戻る
・仮想マシンをシャットダウンする
という流れになる。
ということで、まずは「ユニティ」を終了させる必要がある。これには2つの方法がある。
まず一つ目。
「ユニティのメニュー」から「ユニティを終了する」を選択すると、通常の仮想マシンウィンドウに戻る。
次に、もう一つのやり方。
ホストOSのタスクバーを注意深く見れば分かるのだが、下図のように「ユニティ」動作中もVMWare Playerの仮想マシンウィンドウはタスクバー上に表示されている（この辺りは本家と異なる。本家の場合はOSは完全に「裏方」に回っている）。
ここで仮想マシンウィンドウ（下図の左側のアイコン）をクリックすると、次のようなウィンドウが表示される。
何というか彩りに欠けた画面だが、「ユニティ」実行中は仮想マシンウィンドウの表示はこのようになるので、画面上の「ユニティを終了する」ボタンをクリックすれば、通常のOS画面に戻る。
ちなみに仮想マシンウィンドウを「×」ボタンで閉じようとすると、VMWare Playerでおなじみの上図のようなダイアログが表示されるが、「ユニティ」実行中にこれをやった場合にどうなるかは試していないので、できれば止めておいた方がいいのではないかと。
それはさておき、「ユニティ」を終了させるとOSの画面が表示されるので、あとは通常通りのシャットダウンを行えばいい。これは本家とちがって必ずやらなければならない手順になる（ここは本家に一歩譲る部分）。
以上が「ユニティ」の使い方の基本になるが、話はまだ続く。
ぶっちゃけ、これまで書いた手順だと、アプリケーションを起動するまでに結構手間がかかる。もっと楽にアプリケーションを起動する方法はないのか？と思ったそこのアナタ、あるんですよ、これが！
実は、「ユニティ」のメニューの項目は（少なくともアプリケーションに限っては）、ローカルのデスクトップにアイコンを作成することができる。次にその手順を見ていく。
まず、「ユニティ」が使えるようにする所までは同じ手順なので省略する。ユニティのメニューを開いたら、目的のアプリケーションのあるところまでメニューをたどってゆき、そのメニュー上で右クリックする。すると、「デスクトップにショートカットを作成」というコンテキストメニューが表示されるので、これを選択すると・・・
デスクトップ上にショートカットが出来る（今回は「メモ帳」のアイコンを作ってみた）。
次回からは、このアイコンをダブルクリックすると、仮想OSが起動→「ユニティ」を実行→「アプリケーションの起動」の一連の流れが自動的に行われるようになる。なお、前回触れた「自動ログオン」を設定していないと、途中でログオン認証を求められるので注意が必要。
上図のアイコンをダブルクリックしてからの流れ的には下図のような感じになる。
終了の仕方は前述の方法と同じになる。
と言うことで、「ユニティ」の機能を使うと、VMWare Player上でも本家XPモードに近い仮想アプリケーションの運用が可能になる。もちろん、前回触れた「フォルダの共有」を使うことで、ホストOSとのデータの受け渡しも可能だ。
これでとりあえず、XPモード亡き後の対応が出来ることが分かった。
次はリモートコントロールソフトの検証か・・・
つづく。
前置きはそのぐらいにして、本題へ。
これは説明の必要はないと思うが、VMWare上のXPモード（インポートしたもの：以下、「XPモード」）上でメモ帳を動作させている状態。別段、これと言って特別なものではない。無論、この状態でもXPモード上のアプリケーションを普通に使うことはできる。まあ、XPモードの画面解像度を上げたり、「フルスクリーンモード」で動かせばそれはそれで別段不便はないのだが、VMWare Playerを起動するという操作を行わなければならない分、一手間余計にかかる（大した手間でないと言ってしまえばそれまでだが）ので、もう少しだけ楽をしようというのが今回の話になる。
具体的には、上のメモ帳を
こんな感じで（といってもデスクトップが写っていないんで分かりづらいが）使おう、というものだ。
VMWare Playerには、それを実現するために「ユニティ」という機能がある。「ユニティ」を使うと、VMWare Player上の仮想マシンでで動作するアプリケーションを、あたかもローカルアプリケーションのように使うことが出来る（「ユニティ」の正確な機能についての説明は割愛する。実際には「十分に理解していない」だけなのだが。また、「ユニティ」がどのOSなら対応しているのかは不明。詳しく知りたい方はググってください）。本家XPモードのような機能なのだが、本家との大きな違いとしては、本家では「XPモードの初期設定後にインストールしたアプリケーション」しかローカル（もどき）で使うことが出来なかったのに対して、こちらは上図のようにメモ帳とかペイントなど、「スタート」メニューから呼び出せるアプリケーションは（多分）全て使える点がある。
では、「ユニティ」を使うための手順を見ていく。なお、「ユニティ」を使うためには「VMWare Tools」がインストールされている必要がある。
まずは、通常通りにVMWare Playerを起動して（あ、待って、そこで読むのを止めないで！）、XPモードの仮想マシンを起動する。これは最低一回はやらなければならない手順になる。
XPモードの仮想マシンが起動したら、VMWare Playerの「Player」メニューから「ユニティ」を選択する。ちなみに、ここで既にアプリケーションが立ち上がっていると、この操作のあと、そのアプリケーションがローカルアプリのような見栄えになる。
「ユニティ」を実行すると、VMWare Playerのアプリケーションウィンドウ（仮想マシンを表示しているウィンドウ）が消えて、画面左下に下図のようなウィンドウ（実際にはメニューなのだが）が表示される。
なお、上図のウィンドウが消えてしまった場合（数秒経つと表示が消える）は、「Ctrl」＋「Shift」＋「U」キーを押すことで再度表示させることができる。ここからが今回の話の肝になる部分だが、このメニューからアプリケーションを起動することになる。
上のウィンドウ（以下「ユニティのメニュー」）は、ウィンドウズで言うところの「スタートボタン」と同じ働きをする。
つまり、これをくりっくすると下図のような感じになる。
見ての通り、まんま「スタートメニュー」と同じ動きをする。ちなみに上図に写っているメモ帳とMS-IMEは、XPモードのものだ。で、ここで目的のメニュー（今回は「メモ帳」）を選択すると、そのアプリケーションが、あたかもローカルで起動したように起動するという訳だ。ちなみに、「ユニティ」を使って起動したアプリケーションのタイトルバーには、それを示すマーク（四角形が重なったようなマーク）が表示されるので、それによって本物のローカルアプリケーションとの区別が付けられる。
では、「ユニティ（で起動した仮想マシン上のアプリケーション）」を完全に終わらせるにはどうすればよいか。起動しているアプリケーションを「×」ボタンで閉じるだけでは、仮想マシン自体は終了しない。ここは本家XPモードとの違いなので注意が必要（本家の場合は、アプリケーションを閉じると、自動的にOSが休止状態になる）。終了のさせ方は、大雑把に言うと
・「ユニティ」を終了して仮想マシンのウィンドウに戻る
・仮想マシンをシャットダウンする
という流れになる。
ということで、まずは「ユニティ」を終了させる必要がある。これには2つの方法がある。
まず一つ目。
「ユニティのメニュー」から「ユニティを終了する」を選択すると、通常の仮想マシンウィンドウに戻る。
次に、もう一つのやり方。
ホストOSのタスクバーを注意深く見れば分かるのだが、下図のように「ユニティ」動作中もVMWare Playerの仮想マシンウィンドウはタスクバー上に表示されている（この辺りは本家と異なる。本家の場合はOSは完全に「裏方」に回っている）。
ここで仮想マシンウィンドウ（下図の左側のアイコン）をクリックすると、次のようなウィンドウが表示される。
何というか彩りに欠けた画面だが、「ユニティ」実行中は仮想マシンウィンドウの表示はこのようになるので、画面上の「ユニティを終了する」ボタンをクリックすれば、通常のOS画面に戻る。
ちなみに仮想マシンウィンドウを「×」ボタンで閉じようとすると、VMWare Playerでおなじみの上図のようなダイアログが表示されるが、「ユニティ」実行中にこれをやった場合にどうなるかは試していないので、できれば止めておいた方がいいのではないかと。
それはさておき、「ユニティ」を終了させるとOSの画面が表示されるので、あとは通常通りのシャットダウンを行えばいい。これは本家とちがって必ずやらなければならない手順になる（ここは本家に一歩譲る部分）。
以上が「ユニティ」の使い方の基本になるが、話はまだ続く。
ぶっちゃけ、これまで書いた手順だと、アプリケーションを起動するまでに結構手間がかかる。もっと楽にアプリケーションを起動する方法はないのか？と思ったそこのアナタ、あるんですよ、これが！
実は、「ユニティ」のメニューの項目は（少なくともアプリケーションに限っては）、ローカルのデスクトップにアイコンを作成することができる。次にその手順を見ていく。
まず、「ユニティ」が使えるようにする所までは同じ手順なので省略する。ユニティのメニューを開いたら、目的のアプリケーションのあるところまでメニューをたどってゆき、そのメニュー上で右クリックする。すると、「デスクトップにショートカットを作成」というコンテキストメニューが表示されるので、これを選択すると・・・
デスクトップ上にショートカットが出来る（今回は「メモ帳」のアイコンを作ってみた）。
次回からは、このアイコンをダブルクリックすると、仮想OSが起動→「ユニティ」を実行→「アプリケーションの起動」の一連の流れが自動的に行われるようになる。なお、前回触れた「自動ログオン」を設定していないと、途中でログオン認証を求められるので注意が必要。
上図のアイコンをダブルクリックしてからの流れ的には下図のような感じになる。
終了の仕方は前述の方法と同じになる。
と言うことで、「ユニティ」の機能を使うと、VMWare Player上でも本家XPモードに近い仮想アプリケーションの運用が可能になる。もちろん、前回触れた「フォルダの共有」を使うことで、ホストOSとのデータの受け渡しも可能だ。
これでとりあえず、XPモード亡き後の対応が出来ることが分かった。
次はリモートコントロールソフトの検証か・・・
つづく。
Windows10へのアップグレードの準備をしてみた（その1・XPモードをVMWareに移行 前編）
【2016.7.17 追記】
Windows10へのアップグレードを実際に行ってから分かったことだが、XPモードはたとえVMWare Playerに「お引っ越し」してもWindows10では動作しない事が判明した。ちなみにWindows10上のVMWare Playerで移行したXPモードを起動するとこうなる。
ということで、以下の記事は「Windows10への移行準備としてのXPモードの移行」としては役に立たないが、「Windows7上でXPモードをWindows VirtualPC（MS純正の仮想環境）からVMWare Playerに移行する手順」として読み替えてもらえればと思い、そのまま残すことにした。ちなみに、VMWare Playerに製品版のWindows XPをインストール（メディアとライセンスは必要になるが）すれば、次のトピックの「ユニティ」は使用できる。あくまでも、「XPモードはWindows7専用の仕組みなのでWindows7以外のシステムでは使えないようになっている」ということだ。
追記ここまで。
【ここからが最初に書いた記事】
現在使っているWindows7からWindows10への障壁の一つとなっている「XPモード」について、「VMWare Player」に移行できることが分かったので試してみた。
今使っているWindows7のPCには、既にVMWare Playerがインストールされているので、そのあたりの話は割愛して、VMWare Playerがインストールされた状態から話は始まる。
VMWare Playerの「Player」→「ファイル」メニューをたどっていくと、「WindowsXPモードのインポート」というメニューがある。「なーんだ、楽勝じゃん」と思って早速メニューをクリックしてみた。
だがしかし、現実は甘くはなかった・・・・
VMWare Player様は「vCenter Converter Standalone」をご所望でいらっしゃった。ちなみにvCenter Converterというのは、VMWareを始めとする各種仮想マシンの変換や、物理PCから仮想マシンを作り出すことのできる便利なツールで、VMWareのサイトから無料でダウンロードできる（ちなみに、VMWare Playerも無料）。が、我がPCには既にvCenter Converterはインストールされている・・・なのに何故？と思ったら、理由が書いてあった。要はインストールのオプションが違うということらしい（デフォルトでは「スタンドアロン」でインストールされ、普通はそっちを選ぶのだが、もしかするとVMWare Playerとの連携のために「クライアント・サーバ」でインストールする必要があるのかもしれない。その辺の詳しいことはあくまでも推測）。
ということで、vCenter Converterを一度アンインストールして再度インストールする。
インストーラを実行すると、途中で「Setup Type」を聞いてくる。ここで「Client-Server installation (advanced)」を選択してやればいい。ということでvCenter Converterの入れ直しも終わり、再度XPモードのインポートにチャレンジする。
今度はエラーにならずに「仮想マシンのインストール」に進んだ。ここでは新規仮想マシンの名前と、新しく作成する仮想マシンを格納するフォルダを指定する。このあたりはお好みで。
XPモードインポート中・・・
インポートが完了すると、仮想マシンの一覧にインポートしたXPモードがリストされる（上図では「Windows XP Mode」）。ここで若干仮想マシンの設定を変更する（別にしなくても問題はないが、変更しておいた方がいい部分もあるので）。リストからインポートしたXPモードの仮想マシンを選択して、ウインドウ右下の「仮想マシン設定の編集」をクリックすると、仮想マシン設定の編集が行える。
ご存じのこととは思うが、WindowsXPは既にサポートが切れているため、セキュリティ的には非常に脆弱だ。それはXPモードでも変わらない。なのでXPモードを使う際はネットワークに接続しないことをお勧めする。という訳で、上図の「ネットワークアダプタ」の設定を次のように変更する。
・「接続済み」「パワーオン時に接続」 ... チェックを外す
・ネットワーク接続 ... 「ホストオンリー」を選択
これで、このXPモードの仮想マシンは、外部への接続が出来なくなる。あとはメモリに余裕があれば数値を上げておくと（2GBもあれば十分かと）動作が軽くなる。
ここで疑問に思う方もいると思う。「ネットに接続できない場合、どうやって外部とのデータのやり取りをすればいいのか？」と。そのための方法は複数あるが、一つはホストPC（VMWare Playerが動作しているPC）の特定のドライブ／フォルダを、仮想マシンの「共有」フォルダとして扱う方法がある。
「オプション」タブを開くと上図の画面に切り替わるので、ここで「共有フォルダ」をクリックしてウインドウ右側で必要な設定を行えばよい。私の場合はホストPCでリッピングしたMP3データをXPモード上にあるエンコードソフトでエンコードすることが目的なので、ホストPC上のMP3データを一時的に保管するフォルダのみを共有としている。このフォルダでは、基本的にMP3データのやり取りしかしないので、このフォルダだけを共有しておけば、理屈的には外部から仮想マシンへのウイルス感染や不正アクセスを防ぐことができるはずだ。ここでのポイントとしては、共有対象とするフォルダは「出来るだけ範囲を狭める」こと。「Cドライブまるごと」などの設定よりはセキュリティリスクを抑えることができる。
【2016.7.23追記】
「共有フォルダ」で共有されたフォルダは、ゲストOSから見ると「HGFS」というファイルシステムでマウントされるのだが、たとえばゲストOS上でISOファイルを作成して共有フォルダに保存しようとすると、保存先では「I00」「I01」のようにISOファイルが分割されて保存される。HGFSの仕様がよく分からないのではっきりしたことは言えないが、おそらくFATのように2GBとか4GBを超えるファイルが扱えないのではないかと思われる。用途によってはそういった制約もあるので要注意。
追記ここまで。
もう一つやっておいた方がいいと思うのは、「自動ログオン」の設定。「本家」のXPモードでは普通にインストールすれば自動ログオンを行っているが、VMWareにインポートしたXPモードではデフォルトでは自動ログオンをしないようになっている。そのため、後述（次回かな？）する「アプリケーションの公開」的なことをやりたい場合には、自動ログオンを有効にしておかないと毎回OSへのログオンを求められる。自動ログオンの設定も上図の画面上で行う。
他のパラメータは必要に応じて設定すればいいと思う。
さて、これでXPモードがVMWareに移行された。早速起動してみる。
・・・だが人生はそんなに甘くなかった。仮想マシンを起動すると、おもむろにWindowsXPの初期設定が始まるではないか！とりあえず先へ進んでみると、思った通り「素」のWindowsXPが起動してきた。何てこった・・・せっせと構築した元のXPモードの環境が引き継がれていない。つまりVMWare PlayerのXPモードのインポートは、「XPモードの『ガワ』だけをインポートしますよ」というものだということだ。
だが、折角苦労して構築したXPモードの環境をむざむざ手放すのも惜しい。何か手はないものか・・・
そこで思いついたのが、「本家XPモードの仮想ディスクをVMWare形式に変換して、今のVMWare側のXPモードの仮想ハードディスクと置き換えればいいのではないか」ということで、早速試してみた。
ネットを漁ると、フリーの仮想ディスク変換ツールは色々あるので、適当なツールを選んで本家XPモードの仮想ディスクをVMWare形式の仮想ディスクに変換する（当然、ファイル名はVMWare側の仮想ディスクのファイル名と同じにする必要がある。あと、ファイルを置き換える際は一度VMWareのXPモード仮想マシンをシャットダウンする必要がある）。そしてファイルを置き換えて仮想マシンを再び立ち上げてみると・・・やった、計画通り！VMWareのXPモードに元のXPモードの環境がそのまま移行された。
これでXPモードの移行はほぼ終わったのだが、ここで忘れてはならないことがある。
XPモードで使っていた時に仮想マシンにインストールされていた「VirtualPC 統合コンポーネント」をアンインストールして、代わりに「VMWare Tools」をインストールする作業が必要になる（これらはいずれも「仮想マシンを快適に使えるようにするツール」的なもの）。ここまで済ませると、インポートしたXPモードがまともに動かせるようになる。
さて、次にXPモードのように仮想アプリケーションを「あたかもローカルアプリケーションのように使える」ようにする。それは次回。
続く。
Windows10へのアップグレードを実際に行ってから分かったことだが、XPモードはたとえVMWare Playerに「お引っ越し」してもWindows10では動作しない事が判明した。ちなみにWindows10上のVMWare Playerで移行したXPモードを起動するとこうなる。
ということで、以下の記事は「Windows10への移行準備としてのXPモードの移行」としては役に立たないが、「Windows7上でXPモードをWindows VirtualPC（MS純正の仮想環境）からVMWare Playerに移行する手順」として読み替えてもらえればと思い、そのまま残すことにした。ちなみに、VMWare Playerに製品版のWindows XPをインストール（メディアとライセンスは必要になるが）すれば、次のトピックの「ユニティ」は使用できる。あくまでも、「XPモードはWindows7専用の仕組みなのでWindows7以外のシステムでは使えないようになっている」ということだ。
追記ここまで。
【ここからが最初に書いた記事】
現在使っているWindows7からWindows10への障壁の一つとなっている「XPモード」について、「VMWare Player」に移行できることが分かったので試してみた。
今使っているWindows7のPCには、既にVMWare Playerがインストールされているので、そのあたりの話は割愛して、VMWare Playerがインストールされた状態から話は始まる。
VMWare Playerの「Player」→「ファイル」メニューをたどっていくと、「WindowsXPモードのインポート」というメニューがある。「なーんだ、楽勝じゃん」と思って早速メニューをクリックしてみた。
だがしかし、現実は甘くはなかった・・・・
VMWare Player様は「vCenter Converter Standalone」をご所望でいらっしゃった。ちなみにvCenter Converterというのは、VMWareを始めとする各種仮想マシンの変換や、物理PCから仮想マシンを作り出すことのできる便利なツールで、VMWareのサイトから無料でダウンロードできる（ちなみに、VMWare Playerも無料）。が、我がPCには既にvCenter Converterはインストールされている・・・なのに何故？と思ったら、理由が書いてあった。要はインストールのオプションが違うということらしい（デフォルトでは「スタンドアロン」でインストールされ、普通はそっちを選ぶのだが、もしかするとVMWare Playerとの連携のために「クライアント・サーバ」でインストールする必要があるのかもしれない。その辺の詳しいことはあくまでも推測）。
ということで、vCenter Converterを一度アンインストールして再度インストールする。
インストーラを実行すると、途中で「Setup Type」を聞いてくる。ここで「Client-Server installation (advanced)」を選択してやればいい。ということでvCenter Converterの入れ直しも終わり、再度XPモードのインポートにチャレンジする。
今度はエラーにならずに「仮想マシンのインストール」に進んだ。ここでは新規仮想マシンの名前と、新しく作成する仮想マシンを格納するフォルダを指定する。このあたりはお好みで。
XPモードインポート中・・・
インポートが完了すると、仮想マシンの一覧にインポートしたXPモードがリストされる（上図では「Windows XP Mode」）。ここで若干仮想マシンの設定を変更する（別にしなくても問題はないが、変更しておいた方がいい部分もあるので）。リストからインポートしたXPモードの仮想マシンを選択して、ウインドウ右下の「仮想マシン設定の編集」をクリックすると、仮想マシン設定の編集が行える。
ご存じのこととは思うが、WindowsXPは既にサポートが切れているため、セキュリティ的には非常に脆弱だ。それはXPモードでも変わらない。なのでXPモードを使う際はネットワークに接続しないことをお勧めする。という訳で、上図の「ネットワークアダプタ」の設定を次のように変更する。
・「接続済み」「パワーオン時に接続」 ... チェックを外す
・ネットワーク接続 ... 「ホストオンリー」を選択
これで、このXPモードの仮想マシンは、外部への接続が出来なくなる。あとはメモリに余裕があれば数値を上げておくと（2GBもあれば十分かと）動作が軽くなる。
ここで疑問に思う方もいると思う。「ネットに接続できない場合、どうやって外部とのデータのやり取りをすればいいのか？」と。そのための方法は複数あるが、一つはホストPC（VMWare Playerが動作しているPC）の特定のドライブ／フォルダを、仮想マシンの「共有」フォルダとして扱う方法がある。
「オプション」タブを開くと上図の画面に切り替わるので、ここで「共有フォルダ」をクリックしてウインドウ右側で必要な設定を行えばよい。私の場合はホストPCでリッピングしたMP3データをXPモード上にあるエンコードソフトでエンコードすることが目的なので、ホストPC上のMP3データを一時的に保管するフォルダのみを共有としている。このフォルダでは、基本的にMP3データのやり取りしかしないので、このフォルダだけを共有しておけば、理屈的には外部から仮想マシンへのウイルス感染や不正アクセスを防ぐことができるはずだ。ここでのポイントとしては、共有対象とするフォルダは「出来るだけ範囲を狭める」こと。「Cドライブまるごと」などの設定よりはセキュリティリスクを抑えることができる。
【2016.7.23追記】
「共有フォルダ」で共有されたフォルダは、ゲストOSから見ると「HGFS」というファイルシステムでマウントされるのだが、たとえばゲストOS上でISOファイルを作成して共有フォルダに保存しようとすると、保存先では「I00」「I01」のようにISOファイルが分割されて保存される。HGFSの仕様がよく分からないのではっきりしたことは言えないが、おそらくFATのように2GBとか4GBを超えるファイルが扱えないのではないかと思われる。用途によってはそういった制約もあるので要注意。
追記ここまで。
もう一つやっておいた方がいいと思うのは、「自動ログオン」の設定。「本家」のXPモードでは普通にインストールすれば自動ログオンを行っているが、VMWareにインポートしたXPモードではデフォルトでは自動ログオンをしないようになっている。そのため、後述（次回かな？）する「アプリケーションの公開」的なことをやりたい場合には、自動ログオンを有効にしておかないと毎回OSへのログオンを求められる。自動ログオンの設定も上図の画面上で行う。
他のパラメータは必要に応じて設定すればいいと思う。
さて、これでXPモードがVMWareに移行された。早速起動してみる。
・・・だが人生はそんなに甘くなかった。仮想マシンを起動すると、おもむろにWindowsXPの初期設定が始まるではないか！とりあえず先へ進んでみると、思った通り「素」のWindowsXPが起動してきた。何てこった・・・せっせと構築した元のXPモードの環境が引き継がれていない。つまりVMWare PlayerのXPモードのインポートは、「XPモードの『ガワ』だけをインポートしますよ」というものだということだ。
だが、折角苦労して構築したXPモードの環境をむざむざ手放すのも惜しい。何か手はないものか・・・
そこで思いついたのが、「本家XPモードの仮想ディスクをVMWare形式に変換して、今のVMWare側のXPモードの仮想ハードディスクと置き換えればいいのではないか」ということで、早速試してみた。
ネットを漁ると、フリーの仮想ディスク変換ツールは色々あるので、適当なツールを選んで本家XPモードの仮想ディスクをVMWare形式の仮想ディスクに変換する（当然、ファイル名はVMWare側の仮想ディスクのファイル名と同じにする必要がある。あと、ファイルを置き換える際は一度VMWareのXPモード仮想マシンをシャットダウンする必要がある）。そしてファイルを置き換えて仮想マシンを再び立ち上げてみると・・・やった、計画通り！VMWareのXPモードに元のXPモードの環境がそのまま移行された。
これでXPモードの移行はほぼ終わったのだが、ここで忘れてはならないことがある。
XPモードで使っていた時に仮想マシンにインストールされていた「VirtualPC 統合コンポーネント」をアンインストールして、代わりに「VMWare Tools」をインストールする作業が必要になる（これらはいずれも「仮想マシンを快適に使えるようにするツール」的なもの）。ここまで済ませると、インポートしたXPモードがまともに動かせるようになる。
さて、次にXPモードのように仮想アプリケーションを「あたかもローカルアプリケーションのように使える」ようにする。それは次回。
続く。
Windows10へのアップグレードを割と真面目に検討してみた
数ヶ月前から、鬱陶しいことこの上なく頻繁に画面上に現れるようになった、Windows10へのアップグレードを催促する下図の画面。「キャンセル」の選択肢がない（「×」ボタンを押せばキャンセルできるが）のは、PCに余り詳しくない人間が見たら「どっちにしてもアップグレードを選ばなければならないのか・・・」と思わせる可能性が高いと思われ、まるで「○○詐欺」の様相を呈しているようだ。
しばらく前からは、日付を勝手に指定して「半強制的に」インストールを迫るまでに。今度は「×」ボタンでウインドウを閉じると「OK」と見なされるという驚愕の仕様（てか、MSが定めたガイドラインを自らガン無視しているのはどうかと）。「言うことを聞かないなら無理矢理」って、どんだけ鬼畜なんだと。コレはさすがにあかんだろ・・・・
その余りのやりたい放題ぶりに、世間からの非難囂々、ついには国会の場でも（まあ、こっちは選挙に向けた「点数稼ぎ」だろうけど）問題視されているWindows10への無償アップグレードだが、マイクロソフト（MS）のやり方はともかくとして、最新のOSが「無償」で手に入るのは、あながち悪い話でもない。現時点で比較的人気の高いWindows7も、遅くとも2020年にはサポートが終了する（第6世代Coreプロセッサ搭載機向けは2017年夏まで）ことを考えれば、いずれはOSのアップグレードは必要となる。5年後に1万数千円を支払ってOSを買うか、今「タダで」アップグレードするか、そこは各位の事情等も絡んでくるので一概には言えないが、もし「どうしても今の環境を変えられない（仕事などの都合で）」理由がなければ、無償アップグレードも選択肢として考えるのが賢明だと思う。個人的には今回のMSのやり方を快く思っていないので、決して「ウェルカム」ではないのだが・・・・
ということで、我が家のPCについて、Windows10へのアップグレードについて検討してみた。
我が家で使っているPC（仮想マシンを除く）は、デスクトップPCが2台とノートPCが1台で、ノートPCは元々Windows10がインストールされていたものをダウングレード権を使ってWindows7を入れている物なので、Windows10へは「アップグレード」ではなく「インストールし直し」となるので今回の話からは除外して、デスクトップPC2台を対象として検討することにした。
その結果、解決しなければならない問題は、主に2つあることが分かった。
まず一つは、リモートコントロールの問題。
現状は「リモートデスクトップ」をメインに使っているが、リモートデスクトップでは行えない処理が若干存在する（例えばDVD、Blu-rayへの書き込みなど）。そういった場合はシマンテック社の「pcAnywhere」を使っている（リモートデスクトップが実際のデスクトップをそのままクライアントに転送している訳ではないのに対して、こちらはデスクトップの画面を直接転送している）が、以前Windows10のPCを使う機会があってpcAnywhereをインストールしてみたら動作しなかった。では最新版のpcAnywhereを導入すればいいのでは？と思われるかもしれないが、残念ながらpcAnywhereは既に開発を終了していて、今手元にあるバージョンが最新かつ最終バージョンとなる。なのでWindows10でpcAnywhereは使えない。本来ならば、直接コンソールを操作すれば済む話なのだが、諸々の事情でデスクトップPCのコンソール前にはバリケードの如く「物」が積み上がっていて、物理的にコンソールにアクセスするのが大変な状況になっている（「断捨離しろよ」というツッコミはなしで）。
もう一つの問題は、「XPモード」が使えなくなる点。
XPモードを必要としている理由は2つあって、1つは今使っているUSB接続のFMラジオチューナーがXPまでしか対応していない点がある。無論、Windows7等に対応したチューナーも世の中には存在するが、値段が高い（そこまでしてどうしても必要とは言い切れない）。なので、今使っているチューナーが使える内はそれで済ませたいと。ぶっちゃけ、こっちはそれほど大した問題ではない。
問題なのはもう一つの理由で、かれこれ15年近く使っているMP3エンコードソフトがXPまでしか対応していない（パッチを当ててようやくXPで使える代物）こと。こちらの用途としては、別のソフトでCDからリッピングした音源を、用途に応じて複数のビットレートに変換するというもので、使い勝手がいいので重宝している。MP3のエンコードソフトはフリーソフトから市販ソフトまで探せばそれなりに見つかるのだが、使い勝手等で満足できるものがなかなか見つからないので、XPモードが使えなくなると非常に困る。
他にも、Office2003が使えなくなる（SQL Serverのデータを書き換えるのにAccess2003の「データページ」を利用していたりする）などの問題はあるが、それらは何とかなりそうな問題なのでそれほど気にしていない。結局、上記2つの問題をクリアしないことにはWindows10へのアップグレードは難しい。とは言え、いずれはWindows10へアップグレードしなければならない日はやってくるので、この機会に問題をクリアしておいた方がいいと思い、代替手段を探すことにした。
まずリモートアクセスの問題は、フリーソフトの「Brynhildr（ブリュンヒルデ）」というソフトが比較的pcAnywhereに近い動きをするらしいことが分かった。これがダメなら最悪は有償の「LAPLINK」あたりを購入するしかないが、できれば余計な出費は避けたい。
次にXPモードの問題は、「VMWare Player」でXPモードを「インポート」出来ることが判明。さらに「ユニティ」という機能を使えば、今のXPモードのようにメニューから直接アプリを起動出来るらしいとのこと。「VMWare Player」ではローカルディスクとのデータ共有も可能なので、MP3ファイルを格納するフォルダだけをホストOSと共有し、XPモードのネットワークを無効化しておけば、理屈的にはウイルス感染の可能性も極めて低くなるはず。
とりあえず目処は立ちそうだということが分かったので、これから順次検証を行っていこうと思う。
つづく。
しばらく前からは、日付を勝手に指定して「半強制的に」インストールを迫るまでに。今度は「×」ボタンでウインドウを閉じると「OK」と見なされるという驚愕の仕様（てか、MSが定めたガイドラインを自らガン無視しているのはどうかと）。「言うことを聞かないなら無理矢理」って、どんだけ鬼畜なんだと。コレはさすがにあかんだろ・・・・
その余りのやりたい放題ぶりに、世間からの非難囂々、ついには国会の場でも（まあ、こっちは選挙に向けた「点数稼ぎ」だろうけど）問題視されているWindows10への無償アップグレードだが、マイクロソフト（MS）のやり方はともかくとして、最新のOSが「無償」で手に入るのは、あながち悪い話でもない。現時点で比較的人気の高いWindows7も、遅くとも2020年にはサポートが終了する（第6世代Coreプロセッサ搭載機向けは2017年夏まで）ことを考えれば、いずれはOSのアップグレードは必要となる。5年後に1万数千円を支払ってOSを買うか、今「タダで」アップグレードするか、そこは各位の事情等も絡んでくるので一概には言えないが、もし「どうしても今の環境を変えられない（仕事などの都合で）」理由がなければ、無償アップグレードも選択肢として考えるのが賢明だと思う。個人的には今回のMSのやり方を快く思っていないので、決して「ウェルカム」ではないのだが・・・・
ということで、我が家のPCについて、Windows10へのアップグレードについて検討してみた。
我が家で使っているPC（仮想マシンを除く）は、デスクトップPCが2台とノートPCが1台で、ノートPCは元々Windows10がインストールされていたものをダウングレード権を使ってWindows7を入れている物なので、Windows10へは「アップグレード」ではなく「インストールし直し」となるので今回の話からは除外して、デスクトップPC2台を対象として検討することにした。
その結果、解決しなければならない問題は、主に2つあることが分かった。
まず一つは、リモートコントロールの問題。
現状は「リモートデスクトップ」をメインに使っているが、リモートデスクトップでは行えない処理が若干存在する（例えばDVD、Blu-rayへの書き込みなど）。そういった場合はシマンテック社の「pcAnywhere」を使っている（リモートデスクトップが実際のデスクトップをそのままクライアントに転送している訳ではないのに対して、こちらはデスクトップの画面を直接転送している）が、以前Windows10のPCを使う機会があってpcAnywhereをインストールしてみたら動作しなかった。では最新版のpcAnywhereを導入すればいいのでは？と思われるかもしれないが、残念ながらpcAnywhereは既に開発を終了していて、今手元にあるバージョンが最新かつ最終バージョンとなる。なのでWindows10でpcAnywhereは使えない。本来ならば、直接コンソールを操作すれば済む話なのだが、諸々の事情でデスクトップPCのコンソール前にはバリケードの如く「物」が積み上がっていて、物理的にコンソールにアクセスするのが大変な状況になっている（「断捨離しろよ」というツッコミはなしで）。
もう一つの問題は、「XPモード」が使えなくなる点。
XPモードを必要としている理由は2つあって、1つは今使っているUSB接続のFMラジオチューナーがXPまでしか対応していない点がある。無論、Windows7等に対応したチューナーも世の中には存在するが、値段が高い（そこまでしてどうしても必要とは言い切れない）。なので、今使っているチューナーが使える内はそれで済ませたいと。ぶっちゃけ、こっちはそれほど大した問題ではない。
問題なのはもう一つの理由で、かれこれ15年近く使っているMP3エンコードソフトがXPまでしか対応していない（パッチを当ててようやくXPで使える代物）こと。こちらの用途としては、別のソフトでCDからリッピングした音源を、用途に応じて複数のビットレートに変換するというもので、使い勝手がいいので重宝している。MP3のエンコードソフトはフリーソフトから市販ソフトまで探せばそれなりに見つかるのだが、使い勝手等で満足できるものがなかなか見つからないので、XPモードが使えなくなると非常に困る。
他にも、Office2003が使えなくなる（SQL Serverのデータを書き換えるのにAccess2003の「データページ」を利用していたりする）などの問題はあるが、それらは何とかなりそうな問題なのでそれほど気にしていない。結局、上記2つの問題をクリアしないことにはWindows10へのアップグレードは難しい。とは言え、いずれはWindows10へアップグレードしなければならない日はやってくるので、この機会に問題をクリアしておいた方がいいと思い、代替手段を探すことにした。
まずリモートアクセスの問題は、フリーソフトの「Brynhildr（ブリュンヒルデ）」というソフトが比較的pcAnywhereに近い動きをするらしいことが分かった。これがダメなら最悪は有償の「LAPLINK」あたりを購入するしかないが、できれば余計な出費は避けたい。
次にXPモードの問題は、「VMWare Player」でXPモードを「インポート」出来ることが判明。さらに「ユニティ」という機能を使えば、今のXPモードのようにメニューから直接アプリを起動出来るらしいとのこと。「VMWare Player」ではローカルディスクとのデータ共有も可能なので、MP3ファイルを格納するフォルダだけをホストOSと共有し、XPモードのネットワークを無効化しておけば、理屈的にはウイルス感染の可能性も極めて低くなるはず。
とりあえず目処は立ちそうだということが分かったので、これから順次検証を行っていこうと思う。
つづく。
Fortigateを設定してみた（その4・VPNでWOL!）
【今回のお話は】
「俺たちの戦いはこれからだ！」的な話。別名「第一部完（多分第二部はないよ）」みたいな話。
さて、Fortigateを使った我が家のインターネット環境の整備もあとわずか。残っているのはVPN経由でWOL(Wake On LAN)を実行することのみとなった。
WOLは「マジック・パケット」と呼ばれる特殊なイーサネット・フレームをネットワークに送信することによって、待機状態のパソコンをリモートで起動する仕組み（待機状態の家電製品のスイッチをリモコンでオンにするようなもの）だが、ここで注目すべきはWOLの信号は「イーサネット・フレーム」つまり「レイヤ2(L2)」の通信ということだ（余談だが、レイヤ2レベルのデータは「フレーム」と呼ぶのに、何故かWOLでは「パケット」と呼んでいる。通常、「パケット」はレイヤ3のデータの呼び名なのだが）。ここではOSI7階層とかマジック・パケットの詳しい説明は割愛するが、FortigateのVPN(IPSec VPN、SSL-VPN)はいずれも「レイヤ3(L3)」以上の階層で通信する仕組みになっているので、レイヤ2の通信をそのまま通すことはできない。この辺りの説明は長くなるので省略するが、ここで言いたいことは「マジック・パケットはそのままではVPNを通れない」ということだ。
ちなみに、以前使っていたバッファローのブロードバンドルータがどのようにWOLを実現していたかと言うと、仕組みは実に単純で、ルータのLAN側ポート側にルータからマジック・パケットを送信するだけ、というものである。これなら単にLAN上の装置が同一ネットワークのPCに対してイーサネット・フレームを送信するだけなので、何の問題もなくWOLが実現できるという訳だ。
話を戻すと、本来L2で実現しているWOLを、L3で動作しているVPN（ここでは「≒ルータ」と読み替えても差し支えない）」を通して如何に利用可能にするか、これが今回の話の主題になる。
ということで、早速「Wake On LAN VPN」とか「Wake On LAN レイヤ3」等のキーワードでググってみるが、なかなかこれといった情報が見当たらない。それでも情報をかき集めていくと、
・VPNやルータをまたいだWOLは可能である
・そのためには、IPアドレスによる宛先指定が可能なWOLのソフトが必要
ということが分かった。
とりあえず、「IPアドレスによる宛先指定が可能なWOL」ソフトを探してみる。
まずはAndroid端末（スマホ、タブレット）から。
「Playストア」で「Wake On Lan」で検索してみてシンプルで使えそうなソフトとして、「Wake On Lan」というそのままズバリな名前のアプリがあったのでインストールと設定を行ってみた。
アプリ起動後、WOLで起動させたいPCの情報を登録する。登録画面は下図のような感じ。
ここで最低限必要な設定としては、
（・ニックネーム←これはアプリ上でデバイスを識別するための名前なので何でもいい）
・デバイス（宛先PC）のIPアドレス
・デバイスのMACアドレス
・デバイスが存在するネットワークのブロードキャストアドレス
だが、MACアドレスとブロードキャストアドレスはVPN経由の場合は設定しなくても行けそうな気がする。これらは例えばWi-Fi接続などでL2レベルでLANに接続されている場合にのみ使われるのではないかと思うが、一応設定しておく。
設定が終わると、下図のようにデバイス一覧に設定したデバイスが追加されるので、これをタップすることでマジック・パケットの送出が行われる。
ということで、早速試してみる。
先にAndroid端末をVPNに接続しておいてから対象PCをシャットダウンして、電源が落ちた段階で「Wake On Lan」アプリの該当ホストをタップしてみると・・・対象PCから「ピッ」という音が聞こえて起動が始まった。よし、上手くいった！
と、ここで話が終わればめでたしめでたしなのだが、実は話はまだ終わっていなかった。
翌日、外出先からVPN経由でWOLを実行して帰宅すると、PCは沈黙したままだった。つまり、WOLが上手くいっていない。そこでもう一度PCの目の前でWOLを試してみると、やはりPCはウンともスンとも言わない。ここで接続をWi-Fiに切り替えてWOLを実行すると、普通にPCが起動した。ということは、アプリの問題でもPCのWOL機能の問題でもない。何故だ？「坊や（以下、自主規制）」はさておき、理由を考える。
・IPを直接指定したとしても、そもそもWOLはL2レベルの通信、つまりPCのLANアダプタのMACアドレスを
宛先としてマジック・パケットを送信する。
・そして、そもそも起動していないPCにはまだIPアドレスが割り振られていないので、IPアドレス宛ての
通信が出来るはずがない。
・さらに、PCのシャットダウン直後はWOLが上手くいっていたのに、時間を置くとWOLができなくなる
これらをつなぎ合わせていくと、導き出される結論は－Fortigateの「ARPテーブル（ARPキャッシュ）」しかない。
ARPテーブルというのは、MACアドレスとIPアドレスを紐付ける対応表のことで、通常のルータでは一定時間その対応関係を保持している。これがARPキャッシュ。つまり、PCシャットダウン直後にWOLが上手くいっていたのは、FortigateのARPキャッシュに「目的のPCのIPアドレス→そのPCのMACアドレス」の対応情報がまだ残っていて、IPアドレス宛のパケットを受信したFortigateはARPキャッシュからそのパケットを「投げる」先のMACアドレスが分かっていたためで、時間の経過でARPキャッシュから対応情報が消えれば、Fortigateは受け取ったIPアドレスに対応するMACアドレスが分からず、どこにパケットを投げたらいいか分からなくなる。そう考えれば全ての辻褄が合う。
そうと分かれば話は簡単。ARPキャッシュが「動的に」情報を書き換えるのなら、ARPテーブルに「静的に」情報を登録すればいい。
ということで、FortigateのCLIからコマンドを入力する（下記の「←」以降は注釈なので入力しない）。
config system arp-table
edit 1 ←「1」はエントリー番号なので適宜読み替えが必要
set interface "internal1" ←対象PCが存在するインタフェース
set ip 192.168.1.1 ←対象PCのIPアドレス
set mac 00:11:22:33:44:55 ←対象PCのMACアドレス
end
確認のため、「get system arp-table」と入力してみる。
== [ 1 ]
id: 1 interface: internal1 ip: 192.168.1.1 mac: 00:11:22:33:44:55
=
と表示されていれば、ARPテーブルに情報が正しく登録されている。
推測が正しいことを確認するために、シャットダウンから半日以上経過した後にVPN経由でWOLを実行してみると、今度は問題なくPCが起動してきた。
若干のトラブルはあったものの、これで外出先からのWOLが以前に比べて簡単になった。何しろ以前はVPNに接続してからブロードバンドルータにログインしてブラウザ立ち上げてWOLのページを呼び出して対象PCのアイコンをクリックする、という手順を踏まなければならなかったのが、今ではVPNへの接続を含めてタップ数回で済むようになったのだから。
なお、モバイルPCの方も、IPアドレスで宛先を指定できるタイプのWOLソフトを使えば、VPN経由でWOLが出来るのは言うまでもない。
ここまで紆余曲折あったものの、ようやく当初の目的をすべて果たすことが出来た。
今回はVPNの刷新が主目的なのでFortigateの機能を十全に使いこなしているとは言いがたいが、それでもPPTPの頃に比べると格段に使い勝手は良くなったと思うし、値段に見合った価値はあったと思っている。
おしまい。
「俺たちの戦いはこれからだ！」的な話。別名「第一部完（多分第二部はないよ）」みたいな話。
さて、Fortigateを使った我が家のインターネット環境の整備もあとわずか。残っているのはVPN経由でWOL(Wake On LAN)を実行することのみとなった。
WOLは「マジック・パケット」と呼ばれる特殊なイーサネット・フレームをネットワークに送信することによって、待機状態のパソコンをリモートで起動する仕組み（待機状態の家電製品のスイッチをリモコンでオンにするようなもの）だが、ここで注目すべきはWOLの信号は「イーサネット・フレーム」つまり「レイヤ2(L2)」の通信ということだ（余談だが、レイヤ2レベルのデータは「フレーム」と呼ぶのに、何故かWOLでは「パケット」と呼んでいる。通常、「パケット」はレイヤ3のデータの呼び名なのだが）。ここではOSI7階層とかマジック・パケットの詳しい説明は割愛するが、FortigateのVPN(IPSec VPN、SSL-VPN)はいずれも「レイヤ3(L3)」以上の階層で通信する仕組みになっているので、レイヤ2の通信をそのまま通すことはできない。この辺りの説明は長くなるので省略するが、ここで言いたいことは「マジック・パケットはそのままではVPNを通れない」ということだ。
ちなみに、以前使っていたバッファローのブロードバンドルータがどのようにWOLを実現していたかと言うと、仕組みは実に単純で、ルータのLAN側ポート側にルータからマジック・パケットを送信するだけ、というものである。これなら単にLAN上の装置が同一ネットワークのPCに対してイーサネット・フレームを送信するだけなので、何の問題もなくWOLが実現できるという訳だ。
話を戻すと、本来L2で実現しているWOLを、L3で動作しているVPN（ここでは「≒ルータ」と読み替えても差し支えない）」を通して如何に利用可能にするか、これが今回の話の主題になる。
ということで、早速「Wake On LAN VPN」とか「Wake On LAN レイヤ3」等のキーワードでググってみるが、なかなかこれといった情報が見当たらない。それでも情報をかき集めていくと、
・VPNやルータをまたいだWOLは可能である
・そのためには、IPアドレスによる宛先指定が可能なWOLのソフトが必要
ということが分かった。
とりあえず、「IPアドレスによる宛先指定が可能なWOL」ソフトを探してみる。
まずはAndroid端末（スマホ、タブレット）から。
「Playストア」で「Wake On Lan」で検索してみてシンプルで使えそうなソフトとして、「Wake On Lan」というそのままズバリな名前のアプリがあったのでインストールと設定を行ってみた。
アプリ起動後、WOLで起動させたいPCの情報を登録する。登録画面は下図のような感じ。
ここで最低限必要な設定としては、
（・ニックネーム←これはアプリ上でデバイスを識別するための名前なので何でもいい）
・デバイス（宛先PC）のIPアドレス
・デバイスのMACアドレス
・デバイスが存在するネットワークのブロードキャストアドレス
だが、MACアドレスとブロードキャストアドレスはVPN経由の場合は設定しなくても行けそうな気がする。これらは例えばWi-Fi接続などでL2レベルでLANに接続されている場合にのみ使われるのではないかと思うが、一応設定しておく。
設定が終わると、下図のようにデバイス一覧に設定したデバイスが追加されるので、これをタップすることでマジック・パケットの送出が行われる。
ということで、早速試してみる。
先にAndroid端末をVPNに接続しておいてから対象PCをシャットダウンして、電源が落ちた段階で「Wake On Lan」アプリの該当ホストをタップしてみると・・・対象PCから「ピッ」という音が聞こえて起動が始まった。よし、上手くいった！
と、ここで話が終わればめでたしめでたしなのだが、実は話はまだ終わっていなかった。
翌日、外出先からVPN経由でWOLを実行して帰宅すると、PCは沈黙したままだった。つまり、WOLが上手くいっていない。そこでもう一度PCの目の前でWOLを試してみると、やはりPCはウンともスンとも言わない。ここで接続をWi-Fiに切り替えてWOLを実行すると、普通にPCが起動した。ということは、アプリの問題でもPCのWOL機能の問題でもない。何故だ？「坊や（以下、自主規制）」はさておき、理由を考える。
・IPを直接指定したとしても、そもそもWOLはL2レベルの通信、つまりPCのLANアダプタのMACアドレスを
宛先としてマジック・パケットを送信する。
・そして、そもそも起動していないPCにはまだIPアドレスが割り振られていないので、IPアドレス宛ての
通信が出来るはずがない。
・さらに、PCのシャットダウン直後はWOLが上手くいっていたのに、時間を置くとWOLができなくなる
これらをつなぎ合わせていくと、導き出される結論は－Fortigateの「ARPテーブル（ARPキャッシュ）」しかない。
ARPテーブルというのは、MACアドレスとIPアドレスを紐付ける対応表のことで、通常のルータでは一定時間その対応関係を保持している。これがARPキャッシュ。つまり、PCシャットダウン直後にWOLが上手くいっていたのは、FortigateのARPキャッシュに「目的のPCのIPアドレス→そのPCのMACアドレス」の対応情報がまだ残っていて、IPアドレス宛のパケットを受信したFortigateはARPキャッシュからそのパケットを「投げる」先のMACアドレスが分かっていたためで、時間の経過でARPキャッシュから対応情報が消えれば、Fortigateは受け取ったIPアドレスに対応するMACアドレスが分からず、どこにパケットを投げたらいいか分からなくなる。そう考えれば全ての辻褄が合う。
そうと分かれば話は簡単。ARPキャッシュが「動的に」情報を書き換えるのなら、ARPテーブルに「静的に」情報を登録すればいい。
ということで、FortigateのCLIからコマンドを入力する（下記の「←」以降は注釈なので入力しない）。
config system arp-table
edit 1 ←「1」はエントリー番号なので適宜読み替えが必要
set interface "internal1" ←対象PCが存在するインタフェース
set ip 192.168.1.1 ←対象PCのIPアドレス
set mac 00:11:22:33:44:55 ←対象PCのMACアドレス
end
確認のため、「get system arp-table」と入力してみる。
== [ 1 ]
id: 1 interface: internal1 ip: 192.168.1.1 mac: 00:11:22:33:44:55
=
と表示されていれば、ARPテーブルに情報が正しく登録されている。
推測が正しいことを確認するために、シャットダウンから半日以上経過した後にVPN経由でWOLを実行してみると、今度は問題なくPCが起動してきた。
若干のトラブルはあったものの、これで外出先からのWOLが以前に比べて簡単になった。何しろ以前はVPNに接続してからブロードバンドルータにログインしてブラウザ立ち上げてWOLのページを呼び出して対象PCのアイコンをクリックする、という手順を踏まなければならなかったのが、今ではVPNへの接続を含めてタップ数回で済むようになったのだから。
なお、モバイルPCの方も、IPアドレスで宛先を指定できるタイプのWOLソフトを使えば、VPN経由でWOLが出来るのは言うまでもない。
ここまで紆余曲折あったものの、ようやく当初の目的をすべて果たすことが出来た。
今回はVPNの刷新が主目的なのでFortigateの機能を十全に使いこなしているとは言いがたいが、それでもPPTPの頃に比べると格段に使い勝手は良くなったと思うし、値段に見合った価値はあったと思っている。
おしまい。
Fortigateを設定してみた（その3・VPNの設定）
今回はVPN設定のお話。元々Fortigateを購入したのは、より安全性の高いVPNを構築したかったからなので、ここからが本当にやりたかったことになる。ぶっちゃけ、VPNがなければ普通のブロードバンドルータで十分なので。
Fortigateでは「IPSec VPN」と「SSL-VPN」という2種類のVPNをサポートしている。それぞれの違いとか詳しい仕組みについては、一から説明していくと膨大な量になるので、ここでは割愛する。巷にはその手の書籍が沢山あるので、興味があればそちらを参照されたい。
また、VPNの方式として、VPN装置（今回で言えばFortigate）同士を接続する「拠点間VPN（←呼び方は他にもある。用途としては、オフィス同士を接続する場合などに用いられる）」と、モバイル機器からVPN装置に接続する「クライアントVPN（←これも呼び方は他にもある）」の2種類があるが、今回はモバイルからの接続をしたいので「クライアントVPN」になる。
ということで、早速設定していく。実際の使用では、IPSecかSSLのどちらか一つが使えれば問題ないのだが、折角なので両方使えるようにしておいた。
では実際の手順を。
【IPSec、SSL共通の設定】
・ユーザの作成
VPNの認証にはいくつか方法があるが、今回は一番オーソドックスな「ユーザID／パスワード」による認証方式とすることにした。ということで、まずユーザを作成する。なお、ここで作成したユーザは、IPSec、SSLで共用することが可能である。
「ユーザ」－「ユーザ」－「ローカル」の順にメニューを辿っていくと、上図のような画面に切り替わるので、ここで「新規作成」を押す。
ユーザの追加画面が表示されるので、「ユーザ名」と「パスワード」を入力して「OK」ボタンを押す。これでユーザが追加される。
次に、ユーザグループを作成する。ユーザグループというのは、文字通りユーザを所属させるグループのことだが、FortigateのVPNではグループ単位でアクセス制御を行うので、グループの作成が必須となる。
「ユーザ」－「ユーザグループ」－「ユーザグループ」の順にメニューを辿っていくと、上図のような画面が表示されるので、「新規作成」を押す。
ここではグループの作成と、メンバの追加を行う。まず基本的な設定として
・名前
・タイプ
・SSL-VPNアクセスを許可
の設定を行う。上図のような感じに設定する。今回はこのグループをSSL-VPNでも使うので「SSL-VPNアクセスを許可」にチェックを入れておく。
続いて、このグループにユーザを追加する。上図左側の「利用できるユーザ」から、このグループに参加させたいユーザを選択して、「→」ボタンを押すと、上図右側のようにユーザがグループのメンバとなる。あとは「OK」ボタンを押せばグループの作成が完了する。
まずここまでが準備段階。ここからはIPSec VPN、SSL-VPNそれぞれの設定を行っていく。
【IPSec VPNの設定】
・FortiClient VPNの作成
「VPN」－「IPsec」－「自動鍵(IKE)」の順にメニューを辿っていくと、上図のような画面が表示されるので、「FortiClient VPNを作成」を押す。
上図の画面にて設定を行っていく。
・「ローカル出力インタフェース」は「WAN1（インターネットに接続されたインタフェース）」を選択する。
・「認証方法」は「事前共通鍵」を設定し、その下の「事前共通鍵」に任意の文字列（8文字以上）を設定する。なお、「事前共通鍵」はVPNクライアント側でも同一の文字列を設定する必要があるので忘れないように。
・「ユーザグループ」はこのVPN接続で使用するユーザグループを選択する。
・「アドレス範囲 スタートIP」と「アドレス範囲 エンドIP」は、VPNクライアントに割り当てるIPアドレスを設定する。VPNクライアントがFortigateに接続すると、クライアント側のFortigateクライアントはこの範囲のアドレスから割り当てられたIPアドレスでVPNの通信を行う。なお、このIPアドレスの範囲は、一度設定するとGUIの画面からの変更ができない（と思われる）。変更する場合はCUIでコマンドベースでの変更が必要となるため、安易な決め方をすると後で苦労することになる。
・「Enable IPv4 Split Tunnel」は、「VPNを通じて行う通信」と「VPNを通さない通信」を分けるための設定で、これをオフにすると、すべての通信はVPN経由でしか通信できなくなる。つまり、上図の例では、「192.168.xxx.0/24」向けの通信はVPNを通してアクセスするが、それ以外の通信はすべてインターネット（VPNを通さない）向けの通信となる。簡単に言えば、VPNを使いながらそれ以外のインターネットアクセスも同時に行いたい場合にこれをオンにする。
設定が終わったら「OK」ボタンを押して設定を保存する。
Fortigate Client VPNが作成されると、上図のようになる。ちなみに「クライアントVPN」は、Fortigateでは「インタフェースモード」で実現する。
フェーズ1の設定はこんな感じ。
ネットワーク構成にもよるが、「NATトラバーサル」は基本的には有効にしておいた方がいい。これが有効になっていないと、NAT環境下でのVPN接続ができなくなる。
フェーズ2の設定。
暗号化、認証共に、もっと強力な方式を使用することが可能なのだが、ここでは暗号化は「AES128」、認証は「SHA-1」を設定しておく。理由は、Android版のFortiClientがここまでしかサポートしていないため。
これで認証と暗号化に関する設定が終わったので、次にファイアウォールポリシーの設定を行う。
忘れているかもしれないが、Fortigateはファイアウォールでもあるので、ファイアウォールポリシーの設定を行わなければVPNの接続ができてもその先のネットワークへのアクセスができない。
・ファイアウォールポリシーの設定
上図では既に設定済みの状態となっているが、IPSec VPN経由で「Internal1」への通信を許可するためには、上図のシーケンス番号1の設定を行う。まっさらな状態から行うには、まず「新規作成」を押す。
・「送信元インタフェース／ゾーン」は「FortiClient（IKEの設定で作成した時に付けた名前）」を選択する。「送信元アドレス」は「all」で構わない。
・「宛先インタフェース／ゾーン」は「Internal1」を選択する。「宛先アドレス」は、必要に応じて設定する。Internal1内の全てに対してアクセスを許可する場合は「all」で構わない。「サービス」も同様。
設定が終わったら、「OK」を押してポリシーの設定を保存する。
ここまででIPSec VPNが使えるようになる（はず）。
次にSSL-VPNの設定。
【SSL-VPNの設定】
・アドレスオブジェクトの作成
SSL-VPNクライアントに割り当てるIPアドレスを設定する。
「ファイアウォールオブジェクト」－「アドレス」－「アドレス」の順にメニューを辿ってゆき、上図の画面で「新規作成」を押す。
上図のように設定する。なお、IP範囲は「192.168.1.[1-15]」のような指定も可能。この場合、「192.168.1.1」～「192.168.1.15」を意味する。他にも「192.168.1.0/24」のような指定も可能。
・SSL-VPNの設定
「VPN」－「SSL」－「設定」の順にメニューを辿っていくと、上図の画面が表示される。
ここでは、「IPプール」の設定を行う。IPプールとは、クライアントに割り当てるIPアドレスのことで、前の手順で作成したアドレスを指定する。
そのほかの設定は基本的にデフォルトで問題ないが、「ログインポート」はセキュリティを高めたい場合は別のポート番号に変更した方がよい。なお、その場合はクライアント側の接続ポート番号を変更することも忘れずに。
「適用」ボタンを押して設定を保存。
・ファイアウォールポリシーの作成
SSL-VPNでは最低2つのファイアウォールポリシーを作成する必要がある。上図でいうところの「シーケンス番号3」と「シーケンス番号7」がそれにあたる。なお、上図では既にポリシーが作成済みだが、実際には新規でポリシーを作成する。また、図のシーケンス番号はファイアウォールポリシーの設定状態によって変わってくる。
まずシーケンス番号7の方の設定から。
「送信元インタフェース」は「WAN1」、「宛先インタフェース」は「Internal1」を指定する。
また、「アクション」は「SSL-VPN」を設定する。
更に、「SSL-VPNユーザを設定」をチェックし、「追加」ボタンを押してSSL-VPNへのアクセスを許可するユーザグループ（今回は「VPN_Users」）を追加する。
設定が終わったら「OK」ボタンを押して設定を保存する。
次にシーケンス番号3の設定。
「送信先インタフェース」は「sslvpn トンネルインタフェース」を指定する。
「送信元アドレス」は前の手順で作成したアドレスオブジェクトを設定する。
「宛先インタフェース」は「Internal1」を選択する。「宛先アドレス」はアクセス範囲に応じて設定するが、Internal1全体へのアクセスを許可する場合は「all」で問題ない。「サービス」も同様。
設定が終わったら「OK」ボタンを押して設定を保存する。
これでSSL-VPNの設定が完了した（はず）。
Fortigate側の設定は以上になる。
次にVPNクライアントの設定を行う。
【WindowsPC】
・FortiClientの入手及びインストール
まず、http://forticlient.com/ からFortiClientをダウンロードする。
上図の「Get FortiClient 5.4（現時点の最新バージョン） for Windows」を選択し、「Download」をクリックしてダウンロードする。ダウンロードされたファイルはオンラインインストーラなので、インストーラ本体はまだダウンロードされていない。なので、インターネットに接続された状態で下図のアイコンをダブルクリックする。
あとは指示にしたがってインストールを進めていく。
・IPSec接続の設定
インストールしたFortiClientを起動すると、上図のような画面が表示されるので、一番上の歯車のボタン（赤丸で囲んだ部分）をクリックして、メニューから「新規接続の追加」を選択する。
上図の一番上にある「SSL-VPN」「IPｓec VPN」から、「IPsec VPN」を選択すると、IPsec VPN用の設定画面が表示されるので、上図のように設定していく（設定値は環境に合わせて読み替えてください）。
下図へ続く。
「モード」はアグレッシブ」を選択する。
更に続く。
フェーズ1の設定は基本的にこのままでいい。強いて挙げれば「NATトラバーサル」を有効にするぐらい。
更に続く。
フェーズ2も基本的にそのままで問題ない。
ここまで設定したら「適用」を押して設定を保存する。
これでIPSec VPNの設定が完了。
・SSL-Sec接続の設定
設定の新規追加の方法はIPSec VPNと同じなので省略。
SSL-VPNの方は、IPSec VPNに比べると設定項目が少ない。
なお、Fortigate側の設定で「ログインポート」の設定を変更した場合は、「ポートのカスタム」にチェックを入れて、右側の数値をForitigateの「ログインポート」のポート番号と合わせる必要がある。
設定が終了したら「適用」を押して設定を保存する。
これでSSL-VPNの方も設定が完了。
実際に接続テストを行ってみる。なお、接続テスト時には「外部からのインターネットアクセス」が必要となるので、モバイルルータやスマホのテザリングなどを使って、該当PCを外部から接続できる状態にする必要がある（内部からのインターネット接続では、VPN接続が失敗する）ので注意が必要。
・接続確認
ユーザ名とパスワードを入力して「接続」ボタンを押す。手順はIPSec VPNもSSL-VPNも同じ。
接続が成功すると、下図のような表示に切り替わる。
あとは実際に内部のリソース（ファイル共有など）にアクセスできることを確認すれば終了。
Mac OSの方は環境がないので試していないが、多分Windowsと大差ないと思われる。
【Android端末】
・FortiClientの入手及びインストール
Androidの場合は、「Playストア」からインストールする。
インストールが完了すると、下図のアイコンが表示されるのでこれをタップする。
下図のような画面（下図は既にVPNの設定済みの状態）が表示されるので、一番下の「新規VPN」をタップする。
「VPN名（識別用の名前）」と「VPNタイプ」を選択して、「作成」をタップする。
ここまではIPSec VPN、SSL-VPN共に共通。
・IPSec VPNの設定
以下、ざっと設定画面を。基本的な考え方はWindows PCと同じ。
サーバアドレスの設定。
共有キーの設定。
ネットワーク、認証関係の設定。
ここでは「IKEモード」を「アグレッシブモード」にする。
IPSec フェーズ1の設定。
基本的に変更する必要はない。
IPsec XAuth（認証）設定。
Windows用クライアントとの違いは、パスワードを保存できる点。この辺りはセキュリティと利便性を秤にかけて判断するとよい。
IPSec フェーズ2の設定。
こちらも基本的に変更する項目はない。
ここまでで設定は完了。
なお、Android用のFortiClientの場合は設定を保存するための「OK」や「適用」がないが、設定は保存されている。
・IPSec VPNの設定
同じく、ざっと設定画面を。基本的な考え方はWindows PCと同じ。
設定項目はIPSec VPNに比べると少ない。
なお、Fortigate側の設定で「ログインポート」の設定を変更した場合は、「ポート」の数値をForitigateの「ログインポート」のポート番号と合わせる必要がある。
接続先サーバ（Fortigate）のアドレス設定。
ユーザ名の設定。
なお、図は省略しているが、パスワードはIPSec VPNと同様に保存が可能。
設定完了状態。
以上でAndroid端末用のFortiClientの設定が完了。
iOS版は（以下同文）。
設定が終わったので、実際に接続してみる。
「接続」をタップする。なお、インターネットへの接続ができない場合は「接続」がグレーアウトしてタップできないようになっている。
ユーザ名とパスワードを入力（設定時に登録されている場合はそれが表示される）して、「ログイン」をタップ。
接続中。ちょっと時間がかかる・・・
接続が成功すると、上図の状態になる。
接続を切断する場合は「切断」をタップする。
あとは適当な内部リソースへのアクセスができることを確認する。
以上で接続確認終了。
これでようやくFortigateでVPNが使えるようになった。
使ってみた感想としては、PPTPの頃はかなりの頻度で接続断が発生していたが、Fortigateに変えてからはIPSec、SSL共にPPTPに比べて通信が安定している。これまで使ってきて、足回り（インターネット）の不調以外でVPN接続が切れた記憶がない。これだけでもFortigateに変えた価値があったと思う。
さて、残るはVPN経由でのWOL。またそれは次回の話ということで。
つづく。
【おまけ：Android端末のモバイルデータ通信での注意点】
Android 6.0からはアプリ単位で「バックグラウンド通信の許可／拒否」を設定できるようになった。
ここで「アプリのバックグラウンドデータを制限」を有効にすると、FortiClientでVPNに接続してから何か別のアプリケーションを実行するためにFortiClientを終了すると、VPN接続が切断されてしまう。ちなみに上図の設定は「モバイルデータ通信」のみ有効なので、Wi-Fi接続には影響しない。
通信量を節約するためにアプリのバックグラウンド通信を制限していると、結構やりがちなので参考までに。
Android 5.x以前やiOSについては、実機がないので分からないが、Android5.xの場合は「バックグラウンド通信を制限」という項目で全てのアプリのバックグラウンド通信を制限していたが、制限を有効にした場合は前述と同じ動作になるのではないかと思われる（5.xの頃はそもそもWi-Fiオンリーでモバイルデータ通信自体使っていなかったのと、機種変してパケット通信プランを変えられてからはバックグラウンド通信を許可していたので、実際どうなるのかは不明）。
Fortigateでは「IPSec VPN」と「SSL-VPN」という2種類のVPNをサポートしている。それぞれの違いとか詳しい仕組みについては、一から説明していくと膨大な量になるので、ここでは割愛する。巷にはその手の書籍が沢山あるので、興味があればそちらを参照されたい。
また、VPNの方式として、VPN装置（今回で言えばFortigate）同士を接続する「拠点間VPN（←呼び方は他にもある。用途としては、オフィス同士を接続する場合などに用いられる）」と、モバイル機器からVPN装置に接続する「クライアントVPN（←これも呼び方は他にもある）」の2種類があるが、今回はモバイルからの接続をしたいので「クライアントVPN」になる。
ということで、早速設定していく。実際の使用では、IPSecかSSLのどちらか一つが使えれば問題ないのだが、折角なので両方使えるようにしておいた。
では実際の手順を。
【IPSec、SSL共通の設定】
・ユーザの作成
VPNの認証にはいくつか方法があるが、今回は一番オーソドックスな「ユーザID／パスワード」による認証方式とすることにした。ということで、まずユーザを作成する。なお、ここで作成したユーザは、IPSec、SSLで共用することが可能である。
「ユーザ」－「ユーザ」－「ローカル」の順にメニューを辿っていくと、上図のような画面に切り替わるので、ここで「新規作成」を押す。
ユーザの追加画面が表示されるので、「ユーザ名」と「パスワード」を入力して「OK」ボタンを押す。これでユーザが追加される。
次に、ユーザグループを作成する。ユーザグループというのは、文字通りユーザを所属させるグループのことだが、FortigateのVPNではグループ単位でアクセス制御を行うので、グループの作成が必須となる。
「ユーザ」－「ユーザグループ」－「ユーザグループ」の順にメニューを辿っていくと、上図のような画面が表示されるので、「新規作成」を押す。
ここではグループの作成と、メンバの追加を行う。まず基本的な設定として
・名前
・タイプ
・SSL-VPNアクセスを許可
の設定を行う。上図のような感じに設定する。今回はこのグループをSSL-VPNでも使うので「SSL-VPNアクセスを許可」にチェックを入れておく。
続いて、このグループにユーザを追加する。上図左側の「利用できるユーザ」から、このグループに参加させたいユーザを選択して、「→」ボタンを押すと、上図右側のようにユーザがグループのメンバとなる。あとは「OK」ボタンを押せばグループの作成が完了する。
まずここまでが準備段階。ここからはIPSec VPN、SSL-VPNそれぞれの設定を行っていく。
【IPSec VPNの設定】
・FortiClient VPNの作成
「VPN」－「IPsec」－「自動鍵(IKE)」の順にメニューを辿っていくと、上図のような画面が表示されるので、「FortiClient VPNを作成」を押す。
上図の画面にて設定を行っていく。
・「ローカル出力インタフェース」は「WAN1（インターネットに接続されたインタフェース）」を選択する。
・「認証方法」は「事前共通鍵」を設定し、その下の「事前共通鍵」に任意の文字列（8文字以上）を設定する。なお、「事前共通鍵」はVPNクライアント側でも同一の文字列を設定する必要があるので忘れないように。
・「ユーザグループ」はこのVPN接続で使用するユーザグループを選択する。
・「アドレス範囲 スタートIP」と「アドレス範囲 エンドIP」は、VPNクライアントに割り当てるIPアドレスを設定する。VPNクライアントがFortigateに接続すると、クライアント側のFortigateクライアントはこの範囲のアドレスから割り当てられたIPアドレスでVPNの通信を行う。なお、このIPアドレスの範囲は、一度設定するとGUIの画面からの変更ができない（と思われる）。変更する場合はCUIでコマンドベースでの変更が必要となるため、安易な決め方をすると後で苦労することになる。
・「Enable IPv4 Split Tunnel」は、「VPNを通じて行う通信」と「VPNを通さない通信」を分けるための設定で、これをオフにすると、すべての通信はVPN経由でしか通信できなくなる。つまり、上図の例では、「192.168.xxx.0/24」向けの通信はVPNを通してアクセスするが、それ以外の通信はすべてインターネット（VPNを通さない）向けの通信となる。簡単に言えば、VPNを使いながらそれ以外のインターネットアクセスも同時に行いたい場合にこれをオンにする。
設定が終わったら「OK」ボタンを押して設定を保存する。
Fortigate Client VPNが作成されると、上図のようになる。ちなみに「クライアントVPN」は、Fortigateでは「インタフェースモード」で実現する。
フェーズ1の設定はこんな感じ。
ネットワーク構成にもよるが、「NATトラバーサル」は基本的には有効にしておいた方がいい。これが有効になっていないと、NAT環境下でのVPN接続ができなくなる。
フェーズ2の設定。
暗号化、認証共に、もっと強力な方式を使用することが可能なのだが、ここでは暗号化は「AES128」、認証は「SHA-1」を設定しておく。理由は、Android版のFortiClientがここまでしかサポートしていないため。
これで認証と暗号化に関する設定が終わったので、次にファイアウォールポリシーの設定を行う。
忘れているかもしれないが、Fortigateはファイアウォールでもあるので、ファイアウォールポリシーの設定を行わなければVPNの接続ができてもその先のネットワークへのアクセスができない。
・ファイアウォールポリシーの設定
上図では既に設定済みの状態となっているが、IPSec VPN経由で「Internal1」への通信を許可するためには、上図のシーケンス番号1の設定を行う。まっさらな状態から行うには、まず「新規作成」を押す。
・「送信元インタフェース／ゾーン」は「FortiClient（IKEの設定で作成した時に付けた名前）」を選択する。「送信元アドレス」は「all」で構わない。
・「宛先インタフェース／ゾーン」は「Internal1」を選択する。「宛先アドレス」は、必要に応じて設定する。Internal1内の全てに対してアクセスを許可する場合は「all」で構わない。「サービス」も同様。
設定が終わったら、「OK」を押してポリシーの設定を保存する。
ここまででIPSec VPNが使えるようになる（はず）。
次にSSL-VPNの設定。
【SSL-VPNの設定】
・アドレスオブジェクトの作成
SSL-VPNクライアントに割り当てるIPアドレスを設定する。
「ファイアウォールオブジェクト」－「アドレス」－「アドレス」の順にメニューを辿ってゆき、上図の画面で「新規作成」を押す。
上図のように設定する。なお、IP範囲は「192.168.1.[1-15]」のような指定も可能。この場合、「192.168.1.1」～「192.168.1.15」を意味する。他にも「192.168.1.0/24」のような指定も可能。
・SSL-VPNの設定
「VPN」－「SSL」－「設定」の順にメニューを辿っていくと、上図の画面が表示される。
ここでは、「IPプール」の設定を行う。IPプールとは、クライアントに割り当てるIPアドレスのことで、前の手順で作成したアドレスを指定する。
そのほかの設定は基本的にデフォルトで問題ないが、「ログインポート」はセキュリティを高めたい場合は別のポート番号に変更した方がよい。なお、その場合はクライアント側の接続ポート番号を変更することも忘れずに。
「適用」ボタンを押して設定を保存。
・ファイアウォールポリシーの作成
SSL-VPNでは最低2つのファイアウォールポリシーを作成する必要がある。上図でいうところの「シーケンス番号3」と「シーケンス番号7」がそれにあたる。なお、上図では既にポリシーが作成済みだが、実際には新規でポリシーを作成する。また、図のシーケンス番号はファイアウォールポリシーの設定状態によって変わってくる。
まずシーケンス番号7の方の設定から。
「送信元インタフェース」は「WAN1」、「宛先インタフェース」は「Internal1」を指定する。
また、「アクション」は「SSL-VPN」を設定する。
更に、「SSL-VPNユーザを設定」をチェックし、「追加」ボタンを押してSSL-VPNへのアクセスを許可するユーザグループ（今回は「VPN_Users」）を追加する。
設定が終わったら「OK」ボタンを押して設定を保存する。
次にシーケンス番号3の設定。
「送信先インタフェース」は「sslvpn トンネルインタフェース」を指定する。
「送信元アドレス」は前の手順で作成したアドレスオブジェクトを設定する。
「宛先インタフェース」は「Internal1」を選択する。「宛先アドレス」はアクセス範囲に応じて設定するが、Internal1全体へのアクセスを許可する場合は「all」で問題ない。「サービス」も同様。
設定が終わったら「OK」ボタンを押して設定を保存する。
これでSSL-VPNの設定が完了した（はず）。
Fortigate側の設定は以上になる。
次にVPNクライアントの設定を行う。
【WindowsPC】
・FortiClientの入手及びインストール
まず、http://forticlient.com/ からFortiClientをダウンロードする。
上図の「Get FortiClient 5.4（現時点の最新バージョン） for Windows」を選択し、「Download」をクリックしてダウンロードする。ダウンロードされたファイルはオンラインインストーラなので、インストーラ本体はまだダウンロードされていない。なので、インターネットに接続された状態で下図のアイコンをダブルクリックする。
あとは指示にしたがってインストールを進めていく。
・IPSec接続の設定
インストールしたFortiClientを起動すると、上図のような画面が表示されるので、一番上の歯車のボタン（赤丸で囲んだ部分）をクリックして、メニューから「新規接続の追加」を選択する。
上図の一番上にある「SSL-VPN」「IPｓec VPN」から、「IPsec VPN」を選択すると、IPsec VPN用の設定画面が表示されるので、上図のように設定していく（設定値は環境に合わせて読み替えてください）。
下図へ続く。
「モード」はアグレッシブ」を選択する。
更に続く。
フェーズ1の設定は基本的にこのままでいい。強いて挙げれば「NATトラバーサル」を有効にするぐらい。
更に続く。
フェーズ2も基本的にそのままで問題ない。
ここまで設定したら「適用」を押して設定を保存する。
これでIPSec VPNの設定が完了。
・SSL-Sec接続の設定
設定の新規追加の方法はIPSec VPNと同じなので省略。
SSL-VPNの方は、IPSec VPNに比べると設定項目が少ない。
なお、Fortigate側の設定で「ログインポート」の設定を変更した場合は、「ポートのカスタム」にチェックを入れて、右側の数値をForitigateの「ログインポート」のポート番号と合わせる必要がある。
設定が終了したら「適用」を押して設定を保存する。
これでSSL-VPNの方も設定が完了。
実際に接続テストを行ってみる。なお、接続テスト時には「外部からのインターネットアクセス」が必要となるので、モバイルルータやスマホのテザリングなどを使って、該当PCを外部から接続できる状態にする必要がある（内部からのインターネット接続では、VPN接続が失敗する）ので注意が必要。
・接続確認
ユーザ名とパスワードを入力して「接続」ボタンを押す。手順はIPSec VPNもSSL-VPNも同じ。
接続が成功すると、下図のような表示に切り替わる。
あとは実際に内部のリソース（ファイル共有など）にアクセスできることを確認すれば終了。
Mac OSの方は環境がないので試していないが、多分Windowsと大差ないと思われる。
【Android端末】
・FortiClientの入手及びインストール
Androidの場合は、「Playストア」からインストールする。
インストールが完了すると、下図のアイコンが表示されるのでこれをタップする。
下図のような画面（下図は既にVPNの設定済みの状態）が表示されるので、一番下の「新規VPN」をタップする。
「VPN名（識別用の名前）」と「VPNタイプ」を選択して、「作成」をタップする。
ここまではIPSec VPN、SSL-VPN共に共通。
・IPSec VPNの設定
以下、ざっと設定画面を。基本的な考え方はWindows PCと同じ。
サーバアドレスの設定。
共有キーの設定。
ネットワーク、認証関係の設定。
ここでは「IKEモード」を「アグレッシブモード」にする。
IPSec フェーズ1の設定。
基本的に変更する必要はない。
IPsec XAuth（認証）設定。
Windows用クライアントとの違いは、パスワードを保存できる点。この辺りはセキュリティと利便性を秤にかけて判断するとよい。
IPSec フェーズ2の設定。
こちらも基本的に変更する項目はない。
ここまでで設定は完了。
なお、Android用のFortiClientの場合は設定を保存するための「OK」や「適用」がないが、設定は保存されている。
・IPSec VPNの設定
同じく、ざっと設定画面を。基本的な考え方はWindows PCと同じ。
設定項目はIPSec VPNに比べると少ない。
なお、Fortigate側の設定で「ログインポート」の設定を変更した場合は、「ポート」の数値をForitigateの「ログインポート」のポート番号と合わせる必要がある。
接続先サーバ（Fortigate）のアドレス設定。
ユーザ名の設定。
なお、図は省略しているが、パスワードはIPSec VPNと同様に保存が可能。
設定完了状態。
以上でAndroid端末用のFortiClientの設定が完了。
iOS版は（以下同文）。
設定が終わったので、実際に接続してみる。
「接続」をタップする。なお、インターネットへの接続ができない場合は「接続」がグレーアウトしてタップできないようになっている。
ユーザ名とパスワードを入力（設定時に登録されている場合はそれが表示される）して、「ログイン」をタップ。
接続中。ちょっと時間がかかる・・・
接続が成功すると、上図の状態になる。
接続を切断する場合は「切断」をタップする。
あとは適当な内部リソースへのアクセスができることを確認する。
以上で接続確認終了。
これでようやくFortigateでVPNが使えるようになった。
使ってみた感想としては、PPTPの頃はかなりの頻度で接続断が発生していたが、Fortigateに変えてからはIPSec、SSL共にPPTPに比べて通信が安定している。これまで使ってきて、足回り（インターネット）の不調以外でVPN接続が切れた記憶がない。これだけでもFortigateに変えた価値があったと思う。
さて、残るはVPN経由でのWOL。またそれは次回の話ということで。
つづく。
【おまけ：Android端末のモバイルデータ通信での注意点】
Android 6.0からはアプリ単位で「バックグラウンド通信の許可／拒否」を設定できるようになった。
ここで「アプリのバックグラウンドデータを制限」を有効にすると、FortiClientでVPNに接続してから何か別のアプリケーションを実行するためにFortiClientを終了すると、VPN接続が切断されてしまう。ちなみに上図の設定は「モバイルデータ通信」のみ有効なので、Wi-Fi接続には影響しない。
通信量を節約するためにアプリのバックグラウンド通信を制限していると、結構やりがちなので参考までに。
Android 5.x以前やiOSについては、実機がないので分からないが、Android5.xの場合は「バックグラウンド通信を制限」という項目で全てのアプリのバックグラウンド通信を制限していたが、制限を有効にした場合は前述と同じ動作になるのではないかと思われる（5.xの頃はそもそもWi-Fiオンリーでモバイルデータ通信自体使っていなかったのと、機種変してパケット通信プランを変えられてからはバックグラウンド通信を許可していたので、実際どうなるのかは不明）。
