Windows Server リモートデスクトップサービスのライセンスサーバー

マイクロソフト デスクトップ仮想化ソリューション (リモートデスクトップとVDI) ～Windows Server 2019/2016対応～

このコースでは、リモートデスクトップサービスとVDIのエッセンスを1日で学習します。

リモートデスクトップサービスは、Windows CALなどと違ってライセンスサーバーによる厳密なライセンス管理が必要です。

ライセンスサーバーは複数登録できるのですが、ライセンス情報を共有する仕組みがないため、高可用性構成にすることができません。必要以上のライセンスを購入し、複数のライセンスサーバーに割り当てることで冗長化できますが、費用面から現実的ではありません。

ライセンス情報のバックアップと復元は可能なので、定期的なバックアップをおすすめします。

「RD ライセンス サーバーの移行をする方法」で検索すると見つかると思います(本ブログでは公式情報と直接の知り合い以外の記事は原則として紹介しません)

なお、一度割り当てられたライセンスは一定期間有効なので、ライセンスサーバーが停止しても既存のクライアントにすぐに影響が出るわけではありません。影響が出るのは新規接続したクライアントのみです。

リモートデスクトップライセンスの詳細は以下のサイトも参照してください。

クライアント アクセス ライセンス (CAL) を使用して RDS 展開をライセンスする

独力で仮想化システムを作った学生

ちょっと前に書いたブログに若干の加筆と修正をしたものです。登場する人の現在の所属などは確認していないのでご注意ください。

---

2010年10月、情報処理学会のセミナーに参加してきました。

そこで、司会をしていた近山隆先生にご挨拶。

セミナーでは4つセッションがあったのですが、中でもLily VMという、筑波大の学生が作ったシステムが素晴らしい。あまり知られていないのが残念ですが、海外のカンファレンス(確かBSD関係の何か)で発表し、Best Student Awardをもらったそうなので、世界の記録には残ったそうです。

近山先生のこと

近山先生といっても分からない人が多いと思いますが、当時世界最高速のLisp処理系UTI Lispの作者です。UTI LispはUniversity of Tokyo Interactive Lispの略だったと思います。

UTI Lispは、近山先生の博士論文で、高度な最適化で有名です。もちろん完全アセンブリ言語(日立/富士通Mシリーズ用)。

当時、修士課程の学生だった私は、学内で独自に実装された貧弱なLisp 1.5レベルの処理系に嫌気が差していました。ガベージコレクタが実装されていなかったので、正確にはLisp 1.5以下です。

学会誌を見るとUTI Lispというのがあるらしい。しかも、その上では、尊敬する中島秀之先生の自信作Prolog/KRが動作するというのです。

幸い、学校のコンピュータは東大と同じ日立Mシリーズ、早速電話して(当時、インターネットはないも同然です)、オープンリールテープを送ってもらい、処理系をビルドしました。

修士論文が書けたのも、近山・中島、両先生のおかけです。

ちなみに、研究室の電話は市外ダイヤル直通通話が禁止されており、100番通話(オペレーター通話)を使いました。オペレーター通話は以下のように使います。

1. 100番に電話
2. オペレータに対して、通話したい電話番号を伝える
3. オペレーターが電話してくれる
4. 本来の目的である通話
5. 電話を切る
6. オペレーターから電話がかかってきて、料金が通知される
7. その料金を経理に申告する

中島先生は、私が修士2年生の時、広島の学会で見つけて著書にサインをもらいました。

近山先生は、会う機会がなかったのですが、約30年ぶりに念願が叶い、大変嬉しく思っています。

Lily VMのこと

インテル/AMDのCPUアーキテクチャx86には仮想環境で使えない非特権命令が17あります。VMWareは、これらの命令を実行時に動的に変換します。動的変換はVMWareの重要な特許です。

一方、Amazon Web ServicesのEC2やSoftLayerなどのクラウドサービスで使われているXen(のPara Virtualization Mode)は仮想OSのソースコードを手作業で修正し仮想化します。手作業なので出来上がった仮想OSはI/Oも含めて実マシンとほぼ同じ速度で動作しますが、何しろ手作業なので時間がかかる。ちなみに、VMWareはI/O性能で実マシンに劣ります。

Lily VMは、コンパイラに手を入れて、コンパイル時に静的な命令変換を行います。詳しく聞けなかったのですが、おそらくコンパイラが参照する命令セットテーブルに手を入れるのでしょう。

これはなかなか素晴らしいアイデアだと思います。しかも作成したのが、筑波大学の3年生(当時)。日本にも、こういう素晴らしい学生がいるのですよ。

その後、SoftEtherの登大遊さんたちと一緒に研究と事業をしているそうです。

VDI仮想マシンの再作成

VDI(Virtual Desktop Infrastructure)は、クライアントPCを仮想マシンとして構成し、外部からリモートデスクトップ接続するサービスです。

Windows Server 2012では、VDI環境が大幅に強化され、Windows Server 2008 R2に比べて圧倒的に簡単になりました。

▲「マイクロソフトデスクトップ仮想化ソリューション」テキストより

VDIには、個人ごとに1台の仮想マシンを固定する「個人用仮想デスクトップ」と、一定台数の仮想マシンを使い回す(たとえば、10台あれば先着10人が使えて、誰かがログオフすれば他の人が使える)「プールされた仮想デスクトップ」があります。

「プールされた仮想デスクトップ」は、誰が使っても同じ環境になるように、全仮想マシンを同時に更新する仕組みが用意されています(実際には更新ではなくて、入れ換え)。

入れ替えのタイミングは、以下の2種類が選択できます。

• ユーザーが仮想デスクトップからログオフするとき
• スケジュールに基づく

ユーザーが仮想デスクトップからログオフするとき

開始時刻と終了時刻を指定し、この範囲で入れ替えを行います。開始時刻を現在時刻よりも前に設定すれば、即座に更新が始まります。

終了時刻の扱いについて、具体的な動作を記述したドキュメントが見当たらないので、実際に試してみました。システムに負荷をかけないように、指定された時刻の範囲で徐々に更新されていくようですが、即座に更新されることもありました。

ただし、ログオン中の仮想デスクトップマシンは、ユーザーがログオフするまで更新は行われません。指定された終了時刻を過ぎていても、ログオフすれば更新が始まります。

スケジュールに基づく

ログオン中のユーザーがいても、強制ログオフして更新を行います。

こちらは、今すぐ実行するか、更新予定時刻を指定するか、どちらかを選びます。

なお、テンプレートとなる仮想マシンにはスナップショットがあっても構いません。仮想マシンに展開するときにスナップショットが統合されます。

更新時は、大量のファイルコピーが発生しますが、Windows Server 2012のオフロードデータ転送(ODX)に対応したストレージデバイスを使う場合は、LANではなくSAN内でデータ転送を行えるため、大幅に速度が向上する場合があります。

リモートデスクトップ接続ファイルの電子署名

リモートデスクトップサービスに接続するための情報を保存したテキストファイル(RDP)は、改ざん防止のため電子署名を追加できます。

RDPファイルは、リモートデスクトップ接続クライアントで[オプション表示]を行うことで保存できます。

RDPファイルに接続先ホスト名まで保存しておけば、ダブルクリックするだけでホストに接続できます。

しかし、システム管理者が「ここに接続してね」と配布したRDPファイルを使ってみたら、接続先で個人情報を聞かれた、実はRDPファイルは改ざんされており、本来の接続先とは違うホストにつながるようになっていたらどうでしょう。かなり危険な状態になります。

RDPファイルに電子署名を付けることで、こうした危険性に気付きやすくなります。

▼署名なしのRDPファイルを実行した場合

いかにも怪しそうです。

▼署名付きのRDPファイルの場合

だいぶいい感じです。

署名付きRDPファイルの中身を直接書き換えてみます。

▼RDPファイルの接続先をメモ帳で変更

エラーになりました。ただし、セキュリティ上問題ない変更については警告は出ないみたいです。

RDPファイルの署名手順は意外に知られていないので紹介します。

基本的な作業は以下の3ステップです。

1. 証明書のインストール
2. 証明書の拇印(Thumbprint)の取得
3. RDPファイルに署名

1. 証明書のインストール

まず、RDPファイルに署名作業を行うコンピュータに電子証明書をインストールします。信頼できるコンピュータであれば何でも構いません。

2. 証明書の拇印(Thumbprint)の取得

次に、[証明書]の管理ツールを構成します。

1. MMCコマンドを実行
2. [ファイル]メニューから[スナップインの追加と削除]を選択 (またはCtrl-M)
3. [証明書]スナップインを選択した[追加]をクリック
4. [コンピューターアカウント]を選択して[次へ]をクリック
5. [ローカルコンピューター]を選択して[完了]をクリック
6. [OK]をクリック

次に、自分のコンピュータの証明書に含まれる「拇印(Thumbprint)」を取得します。

1. [コンソールルート]-[証明書(ローカルコンピューター)]-[個人]-[証明書]を展開
2. 自分のコンピューターをダブルクリック
3. [詳細]タブを選択
4. 一番下にある[拇印]を選択
5. 拇印を選択し、Ctrl-Cでクリップボードにコピー(右クリックメニューは出ない)

コピーした拇印からスペースを取り除き、すべて大文字にします。大文字しか受け付けないことはヘルプなどに記載されていないので注意してください。

PowerShellを使うことで、この作業を自動化できます。

【実行例】
$tp = "fc ff 52 c9 05 f9 ac b0 f0 86 6f f1 ad 4f ee ca ee 6b 0a 9b"
$tp = $tp.ToUpper().Replace(" ","")

赤字は実際の拇印に置き換えてください。

3. RDPファイルに署名

最後に、以下のコマンドを実行して、RDPファイルに署名を追加します(管理者権限が必要です)。

rdpsign /sha1 スペースを除いて大文字に変換した拇印 RDPファイル /v
(/vは詳細表示オプション)

【実行例】
rdpsign /sha1 FCFF<<中略>>0A9B  default.rdp /v

物理マシンの認証を仮想マシンのドメインコントローラーで行うには

マイクロソフト製品の多くは、Active Directoryドメインサービスを必要とします。しかし、ドメインコントローラーはIDとセキュリティ管理の要なので、構築や複製が何かと面倒です。

特にVDI環境を構築するときは、物理マシンをドメインのメンバーにする必要があり、通常は物理マシンを2台必要とします。

何とか1台でできないものでしょうか。

ksakakiさんのブログ「More Than One Way」の記事「世界のブログから - 「ドメイン コントローラーどうしよう」に、ドメインコントローラーを仮想マシンとして構成し、その仮想マシンホストをメンバーとする手順が掲載されています。

詳細はksakakiさんのブログを読んでいただくとして、要点だけを整理してみましょう。

1. ドメインコントローラー仮想マシン(DC)は自動起動
   既定値は[サービスが停止したときに実行されていた場合は自動起動する]
2. ドメインコントローラー仮想マシン(DC)は最初に起動
   既定値は0
3. ドメインコントローラー仮想マシン(DC)は自動シャットダウン
   既定値は[保存]
4. 万一に備えて物理マシンのローカル管理者アカウントを正しく構成
   ドメインコントローラーが動かないと、ドメインのユーザーでログオンできません。セキュリティ対策としてローカル管理者Administratorの名前を変えたり、無効化する場合もありますが、Hyper-Vホストには必ずローカル管理者としてログオンできるようにしておいてください。

上記1から3は、以下のPowerShellコマンドレットで構成できます(`は継続行の印)。

Set-VM -VMName 仮想マシン名  `
    -AutomaticStartAction Start   `
    -AutomaticStartDelay 0          `
    -AutomaticStopAction ShutDown

しかし、これだけでは起動時のタイミングによってはエラーが出ます。追加の設定が「世界のブログから - Hyper-Vとドメイン コントローラーに関してもう一つ」として公開されています。

1. 確実に認証させるため、資格情報のキャッシュを停止
   物理マシンで以下のようにレジストリを変更します(PowerShellの場合)。
   Set-ItemProperty `
       'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon' '
        -Name cachedlogonscount –Value 0
   (`は継続行の印)
2. 起動時の待ち時間を回避するため、サービス起動順序を構成
   ドメインコントローラー(つまり仮想マシン)で以下のコマンドを実行
   sc config netlogon depend= LanmanWorkstation/LanmanServer/DNS
   (現在の依存関係は sc qc コマンドで表示できます)

以上の構成をしたら、あとは物理マシンの優先DNSに仮想マシンのDNSサーバーアドレスを指定し、通常どおりドメインに参加してください。

だいたいこれで大丈夫なのですが、VDIを構成する場合は以下のようなトラブルがありました。

• 仮想化ホストの構成時に警告が出る
  仮想化ホストの構成時に、ローカルグループの設定に失敗することがあります。管理ツールで見ると、ローカルグループは正しく構成されているようです。実際、そのままでも動作しましたが仮想化、念のためホストをVDIから削除して、再構成した方が無難です。
• 複数のNICがあると、クライアントOSの展開に失敗する
  仮想化ホスト(物理マシン)に、NICが2枚構成されていると(たとえば外部ネットワークと内部ネットワーク)、クライアントOSの展開に失敗しました。同じ構成で成功したこともあるので、詳細は分かりません。

前者はVDIの再構成で、後者は内部ネットワークをやめ、VLANで物理ネットワークを分離することで解決しました。ただ、そもそもなぜ複数NICで問題が発生したかは分かりませんので、もう少し調べてみます。

VLAN、使ってますか?

日経ITproに「VLAN、使ってますか？」という記事が出ました。Facebookに書いたものが「なんと自然な宣伝」と評判が良かったので、加筆してこちらに転載します。

記事では「VLAN(Virtual LAN)が意外に使われていない」とありました。これは、我々の認識とちょっと違います。数十人以上の社員がいる会社で、VLANがない状況というのはちょっと考えられません。

ちょうどいいタイミングで、グローバルナレッジの公式コラムにも「つながるネットワークコラム CCNA R&S一問一答 #19」としてVLANの話が出ています。

もしかしたら、サーバー担当とネットワーク担当が分かれている場合、サーバー担当はネットワーク構成を知らないことがあるので、自社のVLANが導入されていることを意識していなかったのではないでしょうか。

管理者が1人ならそういうことはないと思いますが、2人いる場合でサーバー担当とネットワーク担当に分かれている場合はサーバー担当はVLANを知らないかもしれません。

VLANは「Virtual LAN」というくらいで、そこに存在することを普段は意識する必要がありません。Virtualは「あたかもそこに存在するかのようにみなせること」で、VLANも「あたかもそこにLAN(1つのネットワーク)」が存在するかのようにみなすことができ、利用者はルーターやL3スイッチで中継されているのか、それともVLANなのかを認識することはありません。

「徳川家康は、virtual kingだった」のような用例もあるようです。徳川家康の称号は、天皇から与えられた征夷大将軍であり、名目上は行政長官です。しかし、実際には天皇や貴族が守るべき規則を作り、実質的な予算管理もしていましたから、「国王」と呼んでも差し支えないでしょう。実際、日本に開国を迫ったペリーは徳川家と交渉をしています。

社内にVLANを使うのは既に常識になっていいます。しかし、サーバーエンジニアには意外に知られていないのが実情です。

ところが、最近、それでは済まないことが起きています。

仮想マシンを使うと、仮想化ホストの仮想スイッチにVLANを構成しなければいけないからです。VMwareでもHyper-Vでも、仮想マシンは仮想マシンホスト内に構成されたL2スイッチ(仮想スイッチ)に接続され、そこから物理ネットワークに配線されます。もちろん仮想スイッチにもVLAN機能はあります。

このとき、仮想マシンホストのVLAN構成は、ネットワーク管理者の仕事なのかサーバー管理者の仕事なのか、というのは難しい問題です。

クラウド時代を見据えると、サーバーとネットワークの管理は統合に向かっており、両方の技術者が両方の技術を学習すべきです。

エンジニアのスキルシフトのご用命は、グローバルナレッジネットワークにどうぞ。

仮想マシンとしてのドメインコントローラーとディスクキャッシュ

Windows Serverをドメインコントローラーにした場合、Active Directoryデータベースの整合性を維持するため、書き込みキャッシュを無効にします。

仮想マシンをドメインコントローラーとして構成した場合、物理マシンのキャッシュが無効になるため、性能が低下するらしいが本当ですか。

という質問をいただきました。

最終的な答えはNOですが、いくつか微妙な問題があったのでまとめておきます。なお、以下の文書はすべてWindows Server 2008ベースのものですが、Windows Server 2012 R2でも状況は同じだと思われます。

サポート技術情報888794「仮想ホスト環境で Active Directory ドメイン コントローラーをホストする場合の考慮事項」には以下のことが記載されています。

仮想ホスト環境のソフトウェアで、Force Unit Access (FUA) をサポートする SCSI エミュレーション モードが正しくサポートされている場合、この環境で Active Directory が実行するバッファーなし書き込みはホスト オペレーティング システムに渡されます。

FUA がサポートされていない場合は、Active Directory データベース、ログ、およびチェックポイント ファイルをホストするゲスト オペレーティング システム上のすべてのボリュームにおいて、書き込みキャッシュを無効にする必要があります。

後半は自動的に設定されるため、特に意識する必要はありません。

FUAは、キャッシュ制御をするためのSCSIコマンドです。このコマンドが、仮想マシンから物理マシンに正しく送られる場合、キャッシュを無視してアクセスを行えるようです。

つまり、キャッシュを無効にしなくても、仮想マシンDCからのI/O要求に関してはキャッシュを使わずにディスクをアクセスします。

もちろんSCSIコマンドを発行するのは、仮想マシンの仮想ディスクに対してですから、仮想マシンには仮想SCSIディスクが必要です。また、最終的にSCSIコマンドを受け取るのは物理ディスクですから、物理ディスクもSCSIディスクでなければいけません。

物理ディスクがSCSIでない(IDE/ATA)の場合は、VHD(VHDX)ファイルが破損しないように、キャッシュを手動で無効にする必要があります。

なお、仮想ディスクは、ドメインコントローラーの既定の動作によりSCSIであろうとなかろうと書き込みキャッシュを無効にします。

Microsoft TechNetのドキュメント「仮想化ドメイン コントローラーの展開に関する考慮事項」には以下の記述があります。

Active Directory のデータが壊れる可能性を減らすため、SCSI コントローラーを使用するか、ATA ドライブまたは IDE ドライブで書き込みキャッシュを無効にしてください。

仮想ドメイン コントローラーをホストする Hyper-V サーバーでは、IDE ドライブや ATA ドライブではなく SCSI 物理ドライブを使用してください。SCSI ドライブを使用できない場合は、仮想ドメイン コントローラーをホストする ATA ドライブまたは IDE ドライブで書き込みキャッシュを必ず無効にしてください。詳細については、「Event ID 1539 – Database Integrity (イベント ID 1539 - データベースの整合性に関するページ)」を参照してください。

ドメイン コントローラーとして実行するすべての仮想マシンで、仮想 SCSI コントローラーを使用してください。仮想 SCSI コントローラーを使用できない場合は、ドメイン コントローラーとして実行する仮想マシンの仮想 IDE ドライブで書き込みキャッシュを必ず無効にしてください。インストールされているディスク コントローラーの種類は Virtual Machine Manager の設定ダイアログ ボックスで確認できます。詳細については、「仮想マシンを構成する」を参照してください。

まとめると、以下の通りです。

• 物理ディスクがATAの場合
  • 物理ディスク…手動でキャッシュ無効化
  • 仮想ディスク…自動的にキャッシュ無効化

• 物理ディスクがSCSIの場合で仮想ディスクがATAの場合
  • 物理ディスク…手動でキャッシュ無効化
  • 仮想ディスク…自動的にキャッシュ無効化

• 物理ディスクも仮想ディスクもSCSIの場合
  • 物理ディスク…FUAによる自動制御
  • 仮想ディスク…自動的にキャッシュ無効化

より詳細な内容は、以下のドキュメントをダウンロードしてください(英語です)。

Hyper-V でのドメイン コントローラーの実行に関するページ (ダウンロード可能な Word 文書)

Hyper-V 仮想化環境での時刻同期

時刻同期は今ではサーバーの非常に重要な要件となりました。時刻が同期されていないと、各種のログの照合が難しくなるだけでなく、認証プロトコルが失敗することさえあります。

Hyper-Vを含め、多くの仮想化環境では、仮想マシンの時刻が遅れる傾向にあります。

昔「任天堂ゲームウォッチ」という携帯ゲームがありました。単機能なので、学校でゲーム機本体の交換を行った経験のある人もいるでしょう。ゲームウォッチは、名前の通り本来は時計なのですが、内蔵されたCPUでソフトウェア的に時刻情報を管理していたようです。頻繁にゲームを行うと、CPU割り込みが増え、表示時刻が遅れるという問題がありました。仮想環境でもこれと似たような問題が発生します。

ちなみにゲームウォッチの発売は1980年なので、このたとえ話は40歳代以上にしか分からないと思います。何しろファミリーコンピューター(ファミコン)以前の話です。

●Hyper-V統合サービスでの時刻同期

閑話休題、そこでHyper-Vでは「統合サービス」を仮想マシン上で動作させることで、時刻の遅れを防ぎます。

マイクロソフトのWebサイト「ヒント: Hyper-V 仮想化環境におけるゲスト OS の時刻同期について」によると、時刻同期は以下のように行われます(Windows Server 2008/2008 R2での記載ですが、2012でも同じだと思われます)。

• ゲストOSの時刻が、ホストOSより遅れている場合(5秒以上)
  強制的に時刻同期を行う
• ゲストOSの時刻とホストOSの時刻のずれが5 秒未満の場合
  時刻同期を行うかどうかは NTP (w32timeサービス) に委任
  統合サービスの時刻同期 はVM IC Time Synchronization Provider という名前の NTP Time Providerとして提供
• ゲストOSの時刻が、ホストOSの時刻より進んでいる場合(5秒以上)
  時刻同期しないので、必要に応じてNTPなど、他の時刻同期機構を利用

また、統合サービスの "時刻の同期" は、他の時刻ソース(他の NTP サーバー)の参照環境と共存可能なように実装されているそうです。

その他に、ゲストOSの起動時に同期します。ゲストOSの時刻はシャットダウンまたは保存時に停止するため、次に起動したときは必ず遅れています。つまり、メカニズムとしては「5秒以上遅れている場合」と同じです。

 

●NTPの構成

NTPのパラメータ調整はW32TMコマンドを使います。仮想マシンンに依存しない時刻同期については、私と同じDirectory ServicesのMicrosoft MVPである小鮒道成さんが書いた記事が参考になります。

「Windowsネットワーク時刻同期の基礎とノウハウ」

万一時刻がずれてしまったらどうするかということも問題になります。時刻変更の影響が予測できる場合で、許容できる程度のリスクであれば、一気に同期させるのもひとつの方法です。

時計を進めることは、遅らせることに比べてリスクが少ないと考えられます。通常、仮想マシンンは時刻が遅れるので、多くの場合は問題が出ません。

しかし、時刻変更の影響が予測できない場合や、リスクが大きい場合はどうすればいいでしょう。NTPのパラメータで調整できるならそうしてください。そうでなければ、人間が少しずつ時刻差を縮めていくしかありません。

 

●【追記】ドメインコントローラーの構成

仮想マシンドメインコントローラーでは特別な注意があります。

Microsoft TechNetのドキュメント「仮想化ドメイン コントローラーの展開に関する考慮事項」から引用します(太字は私の注釈)。

ドメイン コントローラーとして構成された仮想マシンでは、統合サービスを通じてホストとの時間の同期を無効にしてください。代わりに、既定の Windows タイム サービス (W32time) ドメイン階層時間の同期を使用してください。

ホスト時間の同期では、ゲスト オペレーティング システムは各自のシステム クロックをホスト オペレーティング システムのシステム クロックに同期させることができます。ドメイン コントローラーはそれぞれ独自の時間同期メカニズムを持っているので、ドメイン コントローラーとして構成された仮想マシンではホスト時間の同期を無効にする必要があります。ドメイン コントローラーが各自のソースから時間を同期させると同時にホストからも時間を同期させた場合、ドメイン コントローラーの時間が頻繁に変化する可能性があります。ドメイン コントローラーのタスクの多くはシステム時間に関連付けられているので、システム時間が突然変化した場合、それが原因で残留オブジェクトがディレクトリに残り、レプリケーションが停止する可能性があります。

Hyper-V マネージャーの [統合サービス] セクションにある仮想マシンの設定で [コンピューターの時計の同期] チェック ボックスをオフにすることで、ホスト時間の同期を無効にすることができます。

Hyper-VとVMware

今日は(もう昨日ですか)、Hyper-VとVMwareの話をしてきました。VMwareの部分は、社内のエキスパートと相談して作りました。

どちらもサーバー仮想化製品ですが、そこでのビジネスはもう終わっていて、大ざっぱに言えば「どちらでも問題ない」というレベルになっています。

その証拠に、各社、ハイパーバイザー単体では値段がついていません。

じゃあ、何がビジネスの中心かというと、まずはストレージとネットワーク、そしてIT運用全体を管理するITMS(ITサービスマネージメント)でしょう。

マイクロソフト製品で言うと、ストレージはWindowsの「記憶域プール」およびサードパーティ製品のSAN。そしてSMB 3.0ベースのNASです。

ちょっとしつこかったかも知れませんが、SMB 3.0は本当にいいプロトコルに大変身しています。仮想マシンの置き場所として十分機能します。

ネットワークはHyper-Vの拡張機能としてのNVGREと、それを制御するSystem Center Virtual Machine Managerですね。

そして、運用管理はSystem Center製品の連携です。

System Centerは複雑な製品ですが、これからのITサービス管理に必須の製品になるはずです。

Windows Server 2012 Hyper-V ネットワーク仮想化

先日、一部のお客様向けにSystem CenterとHyper-V、そしてWindows Azureのセミナーを実施しました。

Windows Server 2012のHyper-Vは、System Center 2012 SP1から利用することを前提に構成されている機能があります。

NVGREを使ったネットワーク仮想化もそのひとつです。

NVGREの設定はPowerShellからのみ設定可能です。
それくらいならいいんですが、せっかく設定した内容をシャットダウンすると消えてしまうとか、構成手順が恐ろしく面倒とか、そもそも意味が分からないとか、さまざまなご意見を聞きます。

私も、時間内でうまく説明できず、申し訳ありませんでした、
何か良い資料はないかと探しているのですが、なかなか見つかりません。

「いい資料があれば紹介する」というお約束で、期限は切っていないのですが、あまりお待たせするのも申し訳ないので英語の資料を紹介しておきます。

• Implementing Enterprise-Scale Disaster Recovery with Hyper-V Replica, Windows Network Virtualization and Microsoft System Center 2012 SP1
• Deep Dive on Hyper-V Network Virtualization in Windows Server 2012 R2

後者は、タイトル通りWindows Server 2012 R2のお話です。

その他、マイクロソフトではさまざまな勉強会を開催しています。

エバンジェリストの高添修さんのブログ「高添はここにいます」などで告知されますので、注意して見ていてください。

たとえば「6月19日(水)は何の日? NVGRE (ネットワーク仮想化) をみっちり学ぶセミナーの日^^」のようなイベントは、これからも開催されると思います。

遅くなった上に、十分な情報ではなく、しかも終了後のイベント告知ということになってしましまい、本当に申し訳ありません。

何か追加の情報があれば、この場でお伝えしていきたいと思います。

SCVMMからHyper-Vに接続するツールを単独で起動する

前に書いた記事の再掲です。既にSystem Center Virtual Machine Manager 2012 SP1が登場していますが、そちらでの動作確認はしていません。

---

SCVMM (System Center Virtual Machine Manager) 2008では、Hyper-V上で動作する仮想サーバー(子パーティション)に接続するために VirtualMachineViewer.exe というツールを使います。

このツールは単独で起動することもできるのですが、パラメータ指定が分かりにくい上、表示されるヘルプの必須パラメータとオプションパラメータの指定が間違っているという問題があります。

実際には、以下のパラメータで接続できます。

VirtualMachineViewer -host ホスト名 -port 2179 -vmid VMID -vmname タイトル

• -hostは、Hyper-Vの親パーティション
• -portは、ポート番号で、通常は2179
• -vmidは、仮想サーバーのIDでHyper-Vの構成情報を格納したXMLファイルのファイル名
• -vmnameは、タイトルバーの文字列ですので何でも構いません。

Hyper-Vの接続クライアントはターミナルサービスの認証プロトコルを使います。そのため、コマンドを直接入力すると、認証ダイアログボックスが開きます。SCVMMコンソールから接続する場合は、認証を内部で行っているようですが、VirtualMachineViewerを直接起動した場合は手動で認証情報を入力する必要があります。

自動化するには、ターミナルサービスのシングルサインオンの構成をしてください。

Hyper-Vのリモート管理(少し古い記事です)

Windows Server 2008のHyper-V管理ツールは、原則としてドメイン環境でないと利用できませんが、これをワークグループで使用する方法です。

昔書いた記事で、少し古くなってしまいました。Windows Server 2012では検証していませんのでご了承ください。

---

Hyper-Vをインストールすると、一部のファイアウォールルールが自動的に構成され、別のコンピューターからリモート管理ができるようになります。

しかし、これではワークグループ環境でリモート管理を行うには十分ではありません。

以下のような構成が必要です。

Part 1 サーバー側での設定

1. ユーザーアカウントの作成
   管理するコンピュータと、管理されるHyper-Vで同じユーザー名とパスワードのアカウントを作成
2. ファイアウォールルールの構成
   "Windows Management Instrumentation (WMI)" グループに所属するルールをすべて有効(許可)にします。
   受信ルールが3つ、送信ルールが1つの合計4つです。
   コマンドは以下の通りです。もちろんGUIでも構いません。
   netsh advfirewall firewall set rule group="Windows Management Instrumentation (WMI)" new enable=yes
3. DCOMセキュリティの構成
   ・dcomcnfgコマンドを実行
   ・[コンソールルート]-[コンポーネントサービス]-[コンピュータ]の下にある[マイコンピュータ]のプロパティを表示
   ・[COMセキュリティ]タブの[起動とアクティブ化のアクセス許可]で[制限の編集]をクリック
   ★この画面は紛らわしい選択肢が多いので注意してください。
   ・管理者として設定したいユーザーまたはグループを追加して、[リモートからの起動]と[リモートからのアクティブ化]を有効化([ローカルからの起動]は最初から選択されています)
4. WMIセキュリティの構成
   ・サーバーマネージャで[構成]-[WMIコントロール]を右クリックしてプロパティを表示
   ・[セキュリティ]タブを選択
   ・[Root]-[CIMv2]を選択
   ・[セキュリティ]をクリック
   ・ユーザーを追加し[アカウントの有効化]が選択されていることを確認
   ・[詳細設定]をクリック
   ・追加したユーザーを選択し[編集]をクリック
   ・[適用先]を[この名前空間のみ]から[この名前空間と副名前空間]に変更
   ・[リモートの有効化]を選択
   ・[これらのアクセス許可を、このコンテナの中にあるオブジェクトコンテナにのみ適用する]を選択
   ・[OK]をクリック
   ・同様の手順をRoot\virtualizationに対しても実行
5. Hyper-Vの権利の構成
   ・コマンドプロンプトからAZMan.mscを起動
   ・[承認マネージャ]を右クリックし、[承認ストアを開く]を選択
   ・承認ストアとして[XMLファイル]を選択し、[C:\ProgramData\Microsoft\Windows\Hyper-V\InitialStore.xml]を指定して[OK]をクリック
   ・[承認マネージャ]-[InitialStore.xml]-[Hyper-V services]-[役割の割り当て]-[Administrator]を右クリック
   ・[ユーザーとグループの割り当て]から[WindowsとActive Directoryを使用]を選択
   ・管理権限を与えたいユーザーを指定して[OK]をクリック
   ・再起動

Part 2 クライアント側(管理ツールを実行するコンピュータ)での設定

1. WMI用のファイアウォールルールの構成
   Part 1 の2と同様、クライアントでも "Windows Management Instrumentation (WMI)" グループに所属するルールをすべて有効化(許可)。
   Windows Vistaの場合は受信の規則が6つ、送信の規則が2つで、合計8つのルールが構成されます。
   コマンドは以下の通りです。もちろんGUIでも構いません。
   netsh advfirewall firewall set rule group="Windows Management Instrumentation (WMI)" new enable=yes
2. MMC用のファイアウォールルールの構成
   以下のコマンドを実行し、MMCに対してファイアウォールの例外規則を設定します。
   コマンドは以下の通りです。もちろんGUIでも構いません。
   Netsh firewall add allowedprogram program=%windir%\system32\mmc.exe name="Microsoft Management Console"
3. DCOMセキュリティの構成
   ワークグループや信頼関係のないドメインの場合に必要です。同一ドメインの場合や信頼関係のあるドメインの場合には必要ありません。
   ・dcomcnfgコマンドを実行
   ・[コンソールルート]-[コンポーネントサービス]-[コンピュータ]の下にある[マイコンピュータ]のプロパティを表示
   ・[COMセキュリティ]タブの[アクセス許可]で[制限の編集]をクリック
   ・ANONYMOUS LOGONに[リモートアクセス]を許可([ローカルアクセス]は最初から選択されている)
   ・必要なだけ[OK]をクリックしてダイアログボックスを終了

以上で、Hyper-Vをリモートから管理するための準備が完了しました。

【参考資料】

今見たら、情報が更新されているようです。正確に知りたい方は、英語ですが、ぜひこちらをどうぞ。

• http://blogs.technet.com/hirookun/archive/2008/08/21/3109197.aspx
• http://blogs.technet.com/jhoward/archive/2008/03/28/part-1-hyper-v-remote-management-you-do-not-have-the-requested-permission-to-complete-this-task-contact-the-administrator-of-the-authorization-policy-for-the-computer-computername.aspx
• http://blogs.technet.com/jhoward/archive/2008/03/28/part-2-hyper-v-remote-management-you-do-not-have-the-requested-permission-to-complete-this-task-contact-the-administrator-of-the-authorization-policy-for-the-computer-computername.aspx
  

Windows Server 2012 Hyper-VとNICチーミング

どうしても分からなかったので、ogawadさんに助けを求めました。

Windows Server 2012は、OSレベルでNICチーミングがサポートされます。チーミングされたNICは、1つのNICに見えるので、それをHyper-Vの外部仮想スイッチ(仮想ネットワーク)として割り当てることができます。

また、Hyper-V仮想マシンに割り当てた仮想NIC同士でもチーミングが可能です。つまり、複数の物理NICそれぞれに仮想スイッチを割り当てて、仮想マシン内でチーミングを行なうこともできます。

この時、仮想マシンでチーミングすると、仮想スイッチを通っているためVMで物理NICのリンクダウンが検出できないのではないか、というご質問をいただき、即答できないでいました。

結論を言うと、後者の場合でもリンクダウンを検出できます。

SR-IOVの有無とか、いろいろ考えてる前に試してみればすぐ分かることでした。お恥ずかしい限りです。

Hyper-V仮想マシンの設定に「NICチーミングを許可」する設定があります。これがオンになっていると、物理NICの状態を伝えてくれるようです。

逆に、SR-IOV を利用する場合、自身にスイッチ相当の機構が埋め込まれるので、利用するNICによっては、ホストOSにすらリンクダウンが通知されないものがあるそうです。

SR-IOVの方がハードウェア情報を伝えやすいと思っていたのですが、そうでもないようです。

SR-IOVについてはogawadさんのブログの「Windows Server 2012 Hyper-V の SR-IOV 構築手順 (3)」に詳しいので、そちらを参照してください。コメント欄には私の質問も載っていて、ちょっと格好悪いのですが、分からなかったものは仕方ありません。

ところがここでもうひとつの疑問が生まれます。物理NICのリンクがダウンしていても、仮想スイッチは生きているので、仮想マシン同士は通信できるはずです。しかし、チーミングドライバが物理NICのリンクダウンを伝えると、通信ができなくなってしまいます。

今度調べようと思っていたら、これまたogawadさんが調べてくれました。

ゲストチーミングしていない場合は、アップリンクとなる物理NICがダウンしても同一の仮想スイッチにつながっていれば引き続き通信できます(従来通りの動作です)。

ゲストチーミングしている場合は、アップリンクとなる物理NICがダウン(全滅)すると)、同一の仮想スイッチにつながっていても通信できないということです。これは、ゲストOSからリンクダウン状態として認識されるためのようです。

ogawadさん、いろいろどうもありがとうございました。

Windows Server 2012 Hyper-Vのレプリケーション

一部お客様向けに Windows Server 2012 の研修が始まり、私が担当しています。

さて、先週Hyper-Vレプリケーションで誤解を招く(というより、ほとんど間違っている)表現があったので、この場を借りて補足しておきます。

Windows Server 2012では、Hyper-V仮想マシンを他の物理マシンに連続的に複製できます。複製間隔はおよそ5分、さらに1時間に1回スナップショットを指定した世代分だけ残せます。

また、オプションとしてVSSによる「整合性のある」スナップショットを指定した時間毎に残せます(最短1時間)。

この複製は、前回との差分を複製しますが、実際に差分ディスクを作成するわけではありません。あくまでもイメージです。実際にはデータベースの「ログ」の方が近いようです(これもイメージですが)。

スナップショットを取ると、内部的に差分ディスクを作ります。しかし、5分に1回の複製は、スナップショットを作るわけではなく、差分ディスクも作成されません。

Windows Server 2012の新機能の詳細は、マイクロソフトTechNet Webサイト内の「Windows Server 2012」に掲載されています(日本語です)。

ターミナルサービスのシングルサインオン

あまり知られていないようなので、再掲載します。

Windows Server 2008では、Active Directoryドメインにログオンしたユーザーは、ターミナルサービスに対してシングルサインオン、つまりユーザー名とパスワードを省略し、現在のユーザーアカウントでてログオンできます。

これにはサーバーとクライアントの両方の設定が必要です。
ただし、サーバーの構成は既定値でシングルサインオンが可能ですので、実際に必要なのはクライアントの設定だけです。

グループポリシーで以下の値を設定してください。

[コンピュータの構成]-[ポリシー]-[管理テンプレート]-[システム]-[資格情報の委任]を開く

• [既定の資格情報の委任を許可する]を[有効]に設定
• サーバ一覧に「termsrv/ターミナルサーバのホスト名」を追加

ホスト名は、実際にアクセスするときの名前に一致している必要があります。

クライアントでドメインサフィックスまで含めて指定する場合は、ホスト名もFQDNでなければいけません。

グループポリシーで登録した名前と、クライアントで接続時に指定したホスト名が違う場合はシングルサインオンが機能しません。

詳しくは@ITの記事「Windows Server 2008の基礎知識」第10回ターミナル・サービスによるクライアントの仮想化（後編）へどうぞ。

この機能は、RemoteAppを使う時に特に重要です。アプリケーションを使うたびにアカウント情報を入力するのは面倒ですからね。

なお、Windows Server 2012でも基本は同じですが、VDI環境やRemoteAppなどでは自動的に委任が行われるようで、特別な設定は必要ありません。

Hyper-V用のスクリプト

以前に書いた記事の再掲載です。

Hyper-Vを操作するスクリプトは、PowerShell用の拡張が公開されていますので、そちらを使う方が簡単かもしれません。

詳しくは、私が書いたマイナビの記事「【管理効率化への挑戦】PowerShellで仮想環境も管理!! Hyper-V、SCとの連携」をご覧ください。

また、Windows Serve 2012では標準でPowerShellコマンドレットが利用できるようになります。

Hatena タグ: Hyper-V

---

Hyper-Vを制御するためのスクリプトは、Virtual Serverと互換性がありません。
Hyper-VがWMIベースなのに対して、Virtual ServerはCOMベースという違いもあります。
Hyper-VのWMIプロバイダは以下のブログが分かりやすいようです。

• Hyper-V Programming Model (ブログ)
• Hyper-V WMI Provider (公式情報)
• Virtualization Team Blog (仮想化開発チームのブログ)
• 「Hyper-V RC1」緊急レビュー (翻訳)

ただし、「Hyper-V RC1」緊急レビューに掲載されているスクリプトを日本語版Windowsで利用する場合は

if VM.Caption = "Virtual Machine" then

を

if VM.Caption = "仮想マシン" then

に書き換える必要があります。

caption属性という、言語ごとに違う表記を使うのはおかしいと思いますが、他のサンプルでもそうなっているようです。

以下は、修正済みのスクリプトです。
現在実行中の全仮想サーバーのスナップショットを取ります。

Option Explicit 
Dim strComputer 
Dim WMIService 
Dim VMManagementService 
Dim VMSystemSettingData 
Dim VMs 
Dim VM 
Dim ret 

strComputer = "." 
Set WMIService = GetObject("winmgmts:\\" & strComputer & "\root\virtualization") 
Set VMs = WMIService.ExecQuery("SELECT * FROM Msvm_ComputerSystem") 
Set VMManagementService = WMIService.ExecQuery("SELECT * FROM Msvm_VirtualSystemManagementService").ItemIndex(0) 

For Each VM In VMs
   if VM.Caption = "仮想マシン" then
      if VM.EnabledState = 2 then 
         WScript.StdOut.Write VM.ElementName & "is running. Creating Snapthot..." 
         set VMSystemSettingData = (VM.Associators_("Msvm_SettingsDefineState","Msvm_VirtualSystemSettingData")).ItemIndex(0)
         ret = VMManagementService.CreateVirtualSystemSnapShot(VM.Path_.Path,VMSystemSettingData)
         if ret = 0 or ret = 4096 then 
            WScript.StdOut.Write "Success."  
         else 
            WScript.StdOut.Write "Failed." 
         end if 
      end if
      WScript.StdOut.Write vbCrLf 
   end if 
Next

ユーザープロファイルの仮想化

古いブログに書いた記事の再掲載ですが、現在でも状況は同じです。
同じ技術でも、時代が変わると位置付けが変わることがあります。

当初、「移動プロファイル」は、「少数のPCを複数の利用者で共有する」という状況を想定していました。
WIndows NTの教育コースでは確かにそう言ってました。

その後、Windows 2000やWindows XP時代になって「1人1台」の環境が当たり前になり、移動プロファイルの重要性は低下しました。

しかし、リモートデスクトップサービス(ターミナルサービス)が登場してから、少し使い方を変えて、ふたたび脚光を浴びています。

使い方が変わったので、新しい名前を付けたということでしょう。

---

米国のTechEd 2008のセッションスライドを見ていて思ったこと。

マイクロソフトの仮想化技術といえば以下の4つということになっていました。

• サーバー仮想化: Virtual Server / Hyper-V
• デスクトップ仮想化: Virtual PC
• プレゼンテーション仮想化: Terminal services
• アプリケーション仮想化: App--V (旧称SoftGrid)

ところがスライドには "Profile Virtualization" の文字が...
よく見たら「移動プロファイル」と「オフラインファイル」でした。

移動プロファイルはWindows NTからあるし、オフラインファイルもWindows 2000からあります。
そのときは「仮想化」なんて誰も言っていません。
まあ、仮想化と言えば仮想化なんですが、単に流行に乗った感じもします。

じゃあ、これはどうでしょう。

• USBフラッシュメモリ仮想化: あらゆるUSBフラッシュメモリ機器をハードディスクとして見せます。
• マウス仮想化: PS/2マウスもUSBマウスも、メーカーを問わずマウス移動と左右ボタンのクリックが可能です。

考えてみたら、OSの仕事のほとんどは「仮想化」ですね。

Hatena タグ: 仮想化

RDセッションホストと、RDセッションブローカー

今日は「マイクロソフト クライアント仮想化ソリューション(#50590) ～リモートデスクトップとVDI～」を担当しました。

1つ、答え切れなかった質問があるので、この場を借りてお答えします(1日の講習会だと調べきれないことがあります)。

【質問】
リモートデスクトップサービスで、リモートデスクトップセッションホスト(RDセッションホスト)を負荷分散しており、リモートデスクトップ接続ブローカー(RD接続ブローカー)を構成しています。

ここで、RDセッションホストとしてAとBの2台があるとします。両ホストはサーバーファームFを構成しています。

ユーザーXがファームFに接続したところ、Aにログオンしました。その後、Xのセッションを残してAのネットワークが切断されました。現在、ネットワークは切断されたままです。

ユーザーXが、ファームFに再接続したらどうなるででしょう。RD接続ブローカーは正常なのでAに再接続されるはずですが、Aは停止しています。

【実験】
権威のある文献を探しきれなかったので、実際にやってみました。

仮想マシンでA、B、2台のRDセッションホストを構成し、RD接続ブローカーに登録します。
次に、DNSラウンドロビンの機能を使ってファームFを構成しました。

ユーザーXでファームFに接続し、Aにログオンしたことを確認して、仮想マシンAの状態を保存しました。

その後、ユーザーXでファームFに再接続すると、Aに接続しようとします。しかしAは応答しないので、リモートデスクトップクライアントがエラーを起こし、接続に失敗します。

もちろんファームFではなくBのIPアドレスやホスト名を使って明示的に接続することは可能です。

その後、Aを復旧してからファームFに接続すると、無事Aに接続されました。

【結論】
RD接続ブローカーのセッション情報は、RDセッションホストの死活を監視せず、機械的に以前のセッションを復元しようとする。

セッションを保持する時間を制限する、管理者に依頼してセッションを強制的に切断する、といった工夫が必要なようです。

RD接続ブローカーを含め、リモートデスクトップサービスの詳細は、マイクロソフト高田祐二さんのブログ「Windows Server 2008 R2 RDS の構築・設計指針」が参考になりました。合わせてご覧ください。

Hyper-V & Virtual Server & SYSPREP

Windows Server 2008で、Hyper-V役割を追加してからSYSPREPをかけると、Hyper-Vが無効になります。役割は追加されたままですが、ハイパーバイザが起動しない模様。

R2では直っているので問題はありません。

これは、KB954356で解説されていますが、機械翻訳は久々にひどい感じです。
まず、一部の文章が英語のままです。しかも、コマンドの順序が入れ替わっている上、一部のスペースが抜けてます。

日本語: Bcdedit hypervisorlaunchtype auto/set {current}
英語: Bcdedit /set {current} hypervisorlaunchtype auto

ところが、この文書に従ってハイパーバイザを有効にしても、ネットワークが正しく動作しません。

Hyper-V用の仮想ネットワークアダプタが動作していないようです。
いったん、仮想ネットワークを初期化してから再作成すると「その物理ネットワークアダプタは既に使われています」という意味のエラーが出ます。

復旧には、KB954356の方法に加え、すでに作られてしまった仮想ネットワークアダプタのレジストリキーを削除する必要があるようです。

仮想ネットワークアダプタの問題はR2でも解決されていませんが、「気にしない」という解決方法もあるので、まあいいでしょう。

Hyper-Vとイリノイ大学

2007年、イリノイ大学アーバナ・シャンペーン校でACM(米国コンピュータ学会)のイベントがありました。

この中で、Eric Trautさんが仮想化とWindows 7(のMinWin)について語っています。
公開当時「Windows 7のアーキテクチャの紹介」と話題になったのですが、本来は仮想化です。英語ですが、なかなか分かりやすかったので、Hyper-Vに興味を持っている方におすすめします。

ところで、イリノイ大学アーバナ・シャンペーン校といえば、初期のコンピュータILLIACとか、最近だと(もう「最近」とは言えませんか?)、NCSA Mosaicで有名です。

でも、一番有名なのは HAL 9000 が誕生した場所として、ではないでしょうか。