こんにちは、Windows サポートの新川です。

 ゲスト OS のメモリ使用状況について、以下のご質問をいただく事があります。

• タスクマネージャーでパフォーマンスを見ていたら、物理メモリが大量に使われているけれども、プロセス タブでそんなに物理メモリを使っているプロセスが見当たらない
• パフォーマンス モニタを見ていると、突然 Memory\Available Mbytes が大きく減ったけど、その時間帯の Memory カウンタや Process カウンタを見ても、ほとんど物理メモリを使っているものが見つからない。

 これらは、そのゲスト OS のメモリ管理を “動的” に設定されているのであれば、バルーニング と呼ばれる仕組みによって発生しているものが大半を占めます。今回は、バルーニングの見え方について少しお話しします。

 ■ Dynamic Memoryの実装

まずはバルーニングの前に Dynamic Memory についての説明です。Windows Server 2008 R2 SP1 より、Hot Add Memory が可能なゲスト OS に対して、Hyper-V ホストからシステム稼働中に動的に物理メモリを割り当てる事が可能になりました。この機能により、ゲスト OS に割り当てられるメモリが動的に最適化出来るようになっています。ただし、Dynamic Memory のゲスト OS の要件には、Hot Add Memory というのはありますが、Hot Remove Memoryというのはありません。つまり、ゲスト OS は “動的に物理メモリを追加” さえサポートしていれば、”動的に物理メモリを削除” する事をサポートされていなくても、Hyper-V ホストはゲスト OS から使っていない物理メモリを回収しているという事になります。(Hyper-V Dynamic Memoryメモリの要求要件についての詳細は 、Hyper-V Dynamic Memory Configuration Guide をご参照ください。)

■ Hyper-V ホストはどのようにしてゲスト OS から物理メモリを回収するか。

それでは、Hyper-V ホストはどのようにゲスト OS から物理メモリを回収しているのでしょうか。実は、Dynamic Memory については既に詳細について記載されたホワイトペーパーが公開されており、Dynamic Memory Technical Overview whitepaper (英語) と Dynamic Memory の実装と構成 (日本語) – ベータ版 からダウンロード可能です。他にも Tech・Ed Japan 2010 の Effective Hyper-V R2 SP1 ～ 詳説 Dynamic Memory ～ には、Hyper-V 以外の製品との比較も含めて非常に細かく書かれています。簡単に説明すると、SP1 で新しくなった Hyper-V ホストの VSP (Virtual Service Provider) とゲスト OS の VSC (Virtual Service Client) で、ゲスト OS の物理メモリのニーズの判断や割り当てを行っています。

ゲスト OS から物理メモリの回収は、ゲスト OS 上で物理メモリを減らすのではなく、特定のメモリ ページにゲスト OS からアクセス出来ない状態にする事で実現します。この領域は、再びゲスト OS の物理メモリ使用量があがって必要になった場合は小さくなり、そのゲスト OS で利用可能な物理メモリ量が増えます。反対に、ゲスト OS で必要な物理メモリ量が減れば、このページは大きくなります。風船のように膨らんだり萎んだりする事から、この仕組がバルーニングと呼ばれています。

■ バルーニングの様子は、メモリ監視をしているとどのように見えるか。

それでは、動的メモリを意識せず、ゲスト OS 上のみでメモリ使用状況を監視していた場合、どのように見えるか確認してみましょう。この環境では、Windows の限界に挑むシリーズのMark’s ブログ でも利用されている testlimit ツール (こちらからダウンロード可能です)にて、大量にメモリを予約するテストを行った後、プロセスが停止してしばらく時間が経過しています。Hyper-V コンソールで確認すると、現在は 768MB が割り当てられています。

それでは、ゲスト OS 内の状況を確認してみましょう。まずは、ゲスト OS のタスクマネージャーを見てみます。以下のように搭載物理メモリが 6,981 MBで、うち 6.57GB (6,727 MB) が利用中となっています。

上記から、カーネル メモリの使用量が非常に少ないことは見えますが、プロセス タブを開いても、使用量の多いプロセスは見つかりません。

次に、ゲスト OS 上のパフォーマンス モニタです。Available Bytes が大きく増減していますが、物理メモリの内訳になりそうな、Pool NonPaged Bytes や Cache Bytes (= System Cache Resident Bytes + System Driver Resident Bytes + System Code Resident Bytes + Pool Paged Resident Bytes のカウンターの合計) や、Process\Working Set で全プロセスの合計を見ても、同じ単位での動きがありません。Committed Bytes が大きく上がっている事は見えますが、これだけでは何に使っているのかがわかりません。

更に、ゲスト OS 内で RAMMap ツールを用いるともう少し内訳が見え、Driver Locked が 6,229,244 KB (≒ 6083 MB ≒ 5.94 GB) を占めている事がわかります。しかし、これ以上の詳細は掴むことが出来ません。

(なお、RAMMap を動かした際にこのゲスト OS への物理メモリの割り当てが少し増えてしまったため、バルーニングのサイズは小さくなっています)

■ 動的メモリ割り当て状況を確認する方法

上述の通り、ゲスト OS 内だけでメモリ使用状況を確認しても、実際にゲスト OS 内でメモリ使用量があがって枯渇しかけているのか、バルーニングの動作で使用量が上がっているように見えるのか、判断が付きませんでした。これについてはHyper-V ホストで以下のカウンタなどが追加されているため、このカウンタから確認が可能です。 

• Hyper-V Dynamic Memory VM 

Hyper-V Dynamic Memory VM  カウンタの中で、Hyper-V Dynamic Memory VM\Physical Memory というインスタンスが実際にゲスト OS に割り当てられているメモリサイズです。今回の例では、一時的に 6,982 MB (≒ 6.8GB) が割り当てられ、その後すぐに割り当てが 826 MB まで減っている事が確認出来ます。今後、物理メモリの利用状況を監視されている環境で動的メモリをご利���になる場合は、Hyper-V ホストのパフォーマンス ログも同時に取得ください。

■ おまけ。ゲスト OS のメモリ ダンプなどからバルーニングを認識出来るか？

ゲスト OS のメモリ ダンプしかない状況で、バルーニングによって利用されている事が特定出来るか確認してみます。

物理メモリの利用状況の確認には  !memusage コマンドが用いられますが、以下のように AWE で 6,273,624 KB (≒ 6127 MB ≒ 5.98 GB ) 使用中となっています。

kd> !memusage
loading PFN database
loading (100% complete)
Compiling memory usage data (99% Complete).
             Zeroed:  48307 (193228 kb)
               Free:      5 (    20 kb)
            Standby:  19724 ( 78896 kb)
           Modified:    821 (  3284 kb)
    ModifiedNoWrite:      0 (     0 kb)
       Active/Valid: 1713940 (6855760 kb)
         Transition:      2 (     8 kb)
                Bad:    383 (  1532 kb)
            Unknown:      0 (     0 kb)
              TOTAL: 1782799 (7131196 kb)
  Building kernel map
  Finished building kernel map
Scanning PFN database - (100% complete)

  Usage Summary (in Kb):
Control       Valid Standby Dirty Shared Locked PageTables  name
ffffffffffffd 6273624      0     0     0     0     0    AWE
fffffa80308a69c0  1056    160     0   956     0     0  mapped_file( ntdll.dll )
fffffa8031297690  4988   6080     0     0     0     0  mapped_file( System.ServiceModel.ni.dll )
fffffa8030884ce0   100    696     4     0     0     0  mapped_file( $BitMap )
fffffa80308a5e30    48    636     0     0     0     0  mapped_file( ntdll.dll )
fffffa80327979d0    76     96     0     0     0     0  mapped_file( werconcpl.dll )
fffffa8030881930    64   1896     0     0     0     0  mapped_file( $LogFile )
fffffa80312d98b0   108    636     0     0     0     0  mapped_file( ntfrs.exe )
fffffa803088ba50     4      0     0     0     0     0    No Name for File
:
--------     0      0     0 -----     0 -----  driver ( RDPDD.dll )
--------   436     16     0 -----     0 -----  driver ( spsys.sys )
--------    56      0     0 -----     0 -----  driver ( crashdmp.sys )
--------    48      0     0 -----     0 -----  driver ( dump_ataport.sys )
--------    36      0     0 -----     0 -----  driver ( dump_atapi.sys )
--------  67840      4     0 -----  1048   160         ( Paged Pool )
--------  5820    156  1512 -----     0   140         ( Kernel Stacks )
--------  42540      0     0 -----     0   160         ( NonPaged Pool )
--------   188      0     0 -----     0    24         ( System Working Set Structures )
Summary   6855760  78904  3284 40764 75444 13432  Total

しかし、念のため AWE について確認しても、明示的に AWE を使っているプロセスはありません。

 kd> !for_each_process "dt _eprocess @#Process AweInfo"
nt!_EPROCESS
   +0x388 AweInfo : (null)
nt!_EPROCESS
   +0x388 AweInfo : (null)
nt!_EPROCESS
   +0x388 AweInfo : (null)
nt!_EPROCESS
   +0x388 AweInfo : (null)
nt!_EPROCESS
   +0x388 AweInfo : (null)
nt!_EPROCESS
   +0x388 AweInfo : (null)
nt!_EPROCESS
   +0x388 AweInfo : (null)
nt!_EPROCESS
   +0x388 AweInfo : (null)
nt!_EPROCESS
   +0x388 AweInfo : (null)
nt!_EPROCESS
   +0x388 AweInfo : (null)
:
nt!_EPROCESS
   +0x388 AweInfo : (null)
nt!_EPROCESS
   +0x388 AweInfo : (null)
nt!_EPROCESS
   +0x388 AweInfo : (null)
nt!_EPROCESS
   +0x388 AweInfo : (null)
nt!_EPROCESS
   +0x388 AweInfo : (null)
nt!_EPROCESS
   +0x388 AweInfo : (null)
nt!_EPROCESS
   +0x388 AweInfo : (null)
nt!_EPROCESS
   +0x388 AweInfo : (null)

実は、!memusage コマンドで AWE フレームと認識されている領域には MDL で確保された領域が含まれるため、MmAllocatePagesForMdl などで確保された場合にもこのような結果になります。(RAMMap ではその点を正しく認識して表示しているので、AWE ではなく “Driver Locked” と表示されます)

残念ながら MDL 領域は、Pool のようにどのドライバから要求されたものかを確認する方法がないので、メモリダンプでも特定は困難です。下記のように MDL を使う可能性があるドライバを探しても複数あり、ここから黄色マークの dmsvc.sys によって確保された事を裏付ける事が出来ません。

kd> x nt!MmAllocatePagesForMdl*
fffff800`015ef9a0 nt!MmAllocatePagesForMdl = <no type information>
fffff800`015ef900 nt!MmAllocatePagesForMdlEx = <no type information>

// ドライバ内に nt!MmAllocatePagesForMdl のアドレス (fffff800`015ef9a0) が含まれており、MmAllocatePagesForMdl を使っている可能性があるもの (抜粋)

kd> !for_each_module ".echo ${@#ModuleName} ;s -q ${@#ModuleName} L?${@#Size} fffff800`015ef9a0"
hal
fffff800`0142b098  fffff800`015ef9a0 fffff800`01473f04
nt
fffff800`0199e928  fffff800`015ef9a0 fffff800`0199c8a8
CI
fffff880`011ed0c0  fffff800`015ef9a0 fffff800`0155d420
NDIS
fffff880`011ed0c0  fffff800`015ef9a0 fffff800`0155d420
msrpc
fffff880`011ed0c0  fffff800`015ef9a0 fffff800`0155d420
ACPI
fffff880`011ed0c0  fffff800`015ef9a0 fffff800`0155d420
pci
fffff880`011ed0c0  fffff800`015ef9a0 fffff800`0155d420
Wdf01000
fffff880`011ed0c0  fffff800`015ef9a0 fffff800`0155d420
WDFLDR
fffff880`011ed0c0  fffff800`015ef9a0 fffff800`0155d420
vmbus
fffff880`011ed0c0  fffff800`015ef9a0 fffff800`0155d420
winhv
fffff880`011ed0c0  fffff800`015ef9a0 fffff800`0155d420
Ntfs
fffff880`01992470  fffff800`015ef9a0 fffff800`018e2780
tcpip
fffff880`01992470  fffff800`015ef9a0 fffff800`018e2780
fwpkclnt
fffff880`01992470  fffff800`015ef9a0 fffff800`018e2780
volsnap
fffff880`01992470  fffff800`015ef9a0 fffff800`018e2780
CLASSPNP
fffff880`01992470  fffff800`015ef9a0 fffff800`018e2780
cdrom
fffff880`01992470  fffff800`015ef9a0 fffff800`018e2780
dfs
fffff880`01992470  fffff800`015ef9a0 fffff800`018e2780
Null
fffff880`01992470  fffff800`015ef9a0 fffff800`018e2780
vga
fffff880`01992470  fffff800`015ef9a0 fffff800`018e2780
VIDEOPRT
fffff880`01992470  fffff800`015ef9a0 fffff800`018e2780
rdbss
fffff880`02858470  fffff800`015ef9a0 fffff800`015c4d40
netbt
fffff880`02858470  fffff800`015ef9a0 fffff800`015c4d40
pacer
fffff880`02858470  fffff800`015ef9a0 fffff800`015c4d40
serial
fffff880`02858470  fffff800`015ef9a0 fffff800`015c4d40
blbdrive
fffff880`02858470  fffff800`015ef9a0 fffff800`015c4d40
raspptp
fffff880`02858470  fffff800`015ef9a0 fffff800`015c4d40
rassstp
fffff880`02858470  fffff800`015ef9a0 fffff800`015c4d40
rdpbus
fffff880`02858470  fffff800`015ef9a0 fffff800`015c4d40
ks
fffff880`02858470  fffff800`015ef9a0 fffff800`015c4d40

// 同じく nt!MmAllocatePagesForMdlEx (fffff800`015ef900) を呼び出す可能性があるドライバ抜粋

kd> !for_each_module ".echo ${@#ModuleName} ;s -q ${@#ModuleName} L?${@#Size} fffff800`015ef900"
nt
fffff800`0199e940  fffff800`015ef900 fffff800`0199c1d0
dmvsc
fffff880`00c17188  fffff800`015ef900 fffff800`014d09c0
CLFS
fffff880`00e41070  fffff800`015ef900 fffff800`014b3550
CI
fffff880`00e41070  fffff800`015ef900 fffff800`014b3550
fffff880`011f13e8  fffff800`015ef900 00000000`00000000
HIDCLASS
fffff880`00e41070  fffff800`015ef900 fffff800`014b3550
volmgrx
fffff880`00e41070  fffff800`015ef900 fffff800`014b3550
amdxata
fffff880`00e41070  fffff800`015ef900 fffff800`014b3550
NETIO
fffff880`00e41070  fffff800`015ef900 fffff800`014b3550
NDIS
fffff880`011f13e8  fffff800`015ef900 00000000`00000000
msrpc
fffff880`011f13e8  fffff800`015ef900 00000000`00000000
ACPI
fffff880`011f13e8  fffff800`015ef900 00000000`00000000
pci
fffff880`011f13e8  fffff800`015ef900 00000000`00000000
Wdf01000
fffff880`011f13e8  fffff800`015ef900 00000000`00000000
WDFLDR
fffff880`011f13e8  fffff800`015ef900 00000000`00000000
vmbus
fffff880`011f13e8  fffff800`015ef900 00000000`00000000
winhv
fffff880`011f13e8  fffff800`015ef900 00000000`00000000

// バルーニングを行なうドライバは、上記では黄色マークがついている以下の dmvsc.sys となります。しかし、メモリ ダンプから今回の MDL 領域が dmvsc.sys によって確保された事を裏付ける情報がありません。

Module[3006] [C:\WINDOWS\SYSTEM32\DRIVERS\DMVSC.SYS]
  Company Name:      Microsoft Corporation
  File Description:  Dynamic Memory
  Product Version:   6.1.7601.17514
  File Version:      6.1.7601.17514 (win7sp1_rtm.101119-1850)
  File Size (bytes): 71168
  File Date:         ? 11 21 12:24:00 2010
    Module TimeDateStamp = 0x4ce79b97 - Sat Nov 20 18:57:43 2010
    Module Checksum      = 0x000120f5
    Module SizeOfImage   = 0x00018000
  Module Pointer to PDB = [dmvsc.pdb]
    Module PDB Guid = {1A806C15-8753-40A0-82DB-9868074FDFDC}
    Module PDB Age = 0x1

こんにちは。Windows テクノロジー サポートの新木です。

リモート デスクトップ セッション ホストの負荷分散構成において、リモート デスクトップ接続時に発生する証明書エラーの警告メッセージを表示させない方法についてご紹介したいと思います。

今回は、通常の RDP 接続をする場合と、RemoteApp を使用してリモート デスクトップ セッション ホスト上のアプリケーションを起動する場合について説明します。

今回ご紹介する内容は Windows Server 2008 R2 の内容となっていますが、Windows Server 2008 においても同様の手順にて証明書エラーの警告メッセージを回避することができますので、参考にしていただければ幸いです。

今回手順をご紹介する上で、検証に使用した環境の構成を以下に記載します。

サーバーはすべて Windows Server 2008 R2 のサーバーを使用しています。

・ドメイン コントローラー 1 台

・リモート デスクトップ セッション ホスト サーバー 2 台

・リモート デスクトップ接続ブローカー サーバー 1 台

・クライアント (Windows 7 SP1)

※リモート デスクトップ接続ブローカーの 「FARM1」 というファームに上記2台のリモート デスクトップ セッション ホスト サーバーを参加させました。

※ドメイン コントローラーには、Active Directory 証明書サービスがインストールされています。

まずは、既定の状態で、クライアントから FARM1 に対してリモート デスクトップ接続を実行した時と、クライアントに配布した RDP ファイルにより RemoteApp を起動した時の挙動について確認してみましょう。

■リモート デスクトップ接続

[リモート デスクトップ接続] を起動して、コンピューター名の欄に 「FARM1」 と入力して ［接続］ボタンを押すと、ユーザー アカウント情報を入力するポップアップが表示されます。

ユーザー アカウント情報を入力して [OK] ボタンを押すと以下警告メッセージが表示されます。

「はい」 を押すとリモート デスクトップ接続することはできます。また、この「コンピューターへの接続について今後確認しない」というチェックボックスをオンにすると、次回接続時からは表示されなくなります。

■RemoteApp接続

同様に、クライアントに配布した RDP ファイルから RemoteApp を起動すると、以下警告メッセージが表示されます。

［接続］ ボタンを押すと、ユーザー アカウント情報を入力するポップアップが表示されます。

この 「コンピューターへの接続について今後確認しない」 というチェック ボックスをオンにすると、次回接続時からは表示されなくなります。

ユーザー アカウント情報を入力して [OK]  ボタンを押すとさらに以下警告メッセージが表示されます。

「はい」 を押すとアプリケーションが起動されます。また、この 「コンピューターへの接続について今後確認しない」 というチェック ボックスをオンにすると、次回接続時からは表示されなくなります。

上記は、リモート デスクトップ セッション ホスト上に、クライアントが信頼する証明機関から発行された証明書がない場合に、発生する警告メッセージです。

この状況で、リモート デスクトップ セッション ホスト サーバー名の証明書を使用すると、以下警告メッセージが表示されるようになります。

これは、ファーム名を使用してリモート デスクトップ接続しているのに対し、リモート デスクトップ セッション ホストから発行される証明書の名前がリモート デスクトップ セッション ホスト名であるために、発生するエラーです。

これらの警告メッセージを、「コンピューターへの接続について今後確認しない」` というチェック ボックスをオンにするなどの設定をせず、始めから表示させないようにするためには、ファーム名が記載された証明書を作成し、各リモート デスクトップ セッション ホストに証明書をインストールする必要があります。

ただし、”ファーム名.xxxx.xxx” のように FQDN にて接続する場合は、FQDN で証明書を作成する必要がありますのでご注意ください。

以下に手順を案内します。

Active Directory 証明書サービスがインストールされているサーバーにおいて、以下手順を実行してください。

1.  サーバー マネージャーの左ペインより [Active Directory 証明書サービス] - [証明書テンプレート] を選択します。中央ペインに表示される [Web サーバー] を右クリックし、[テンプレートの複製] を選択します。

2. Windows Server バージョン (最小限サポートされている CA) を選択し 「OK」 を押します。

3. 作成した新しいテンプレートで以下の変更を行います。

  
・要求処理タブで 「秘密キーのエクスポートを許可する」 のチェック ボックスをオンにします。

　　 ※後ほど秘密鍵をエクスポートするためです。

  
・セキュリティ タブで、Authenticated Users の登録許可を与えます。

　　 ※後ほど Web ブラウザよりテンプレートを選択するためです。

4. サーバー マネージャーの左ペインより [Active Directory 証明書サービス] - [CA名] - [証明書テンプレート] を右クリックします。  
[新規作成] - [発行する証明書テンプレート] を選択します。

5. ステップ 1. で複製したテンプレートを選択して、[OK] を押します。 中央ペインの [証明書テンプレート] に複製したテンプレート名が表示されたことを確認します。

次に、下記手順を各リモート デスクトップ セッション ホストにて実行してください。

1. 証明書の要求登録を行いたいホスト上 (リモート デスクトップ セッション ホスト上)で web ブラウザより、https://<CA ホスト名>/CertSrv にアクセスします。

※HTTPS 接続を有効にするために適宜 IIS  の設定をしてください。

2. Web ページの [タスクの選択：] から [証明書を要求する] を選択します。

3. [証明書の要求の詳細設定] を選択します。

4. [この CA への要求を作成し送信する。] を選択します。

5. [証明書 テンプレート:] において、複製したテンプレート名が表示されるのを確認して選択します。本例では FARM1 を選択します。

6. 名前欄にホスト名を記載します。今回はファーム名を入力してページ下部の [送信] ボタンを押します。

7. [この証明書のインストール] を押します。ここで、証明書がユーザー アカウントの個人ストアにインストールされます。

ユーザー アカウントの個人ストアにインストールされた証明書を、エクスポートし、コンピューターの個人ストアにインストールする必要があります。

8. [スタート]-[ファイル名を指定して実行] を選択し、"mmc" を入力して [OK] を押します。[ファイル ]- [スナップインの追加と削除] より [証明書] を選択し、証明書のスナップイン 「ユーザー アカウント」 を起動します。

9. 個人ストアに要求した証明書が存在することを確認して、右クリックから[全てのタスク] - [エクスポート] を選択します。

ウィザードに従って証明書( .pfx ファイル) をエクスポートします。

※ここで、必ず 「はい、秘密キーをエクスポートします」 を選択してください。               

「正しくエクスポートされました。」 というメッセージが表示されます。

10. 証明書スナップインのコンピュータ アカウント版を起動して、上でエクスポートした証明書を、コンピュータ アカウントの個人ストアにインポートします。

インポートする証明書ファイルの指定にて、上でエクスポートした証明書を選択します。この時、ファイルの種類を Personal Information Exchange (*.pfx; *.p12) にするのを忘れずに。                 

以上でファーム名で作成した証明書を作成し、各リモート デスクトップ セッション ホストに証明書をインストールすることができました。

ここからは、ファーム名で作成した証明書と各機能との紐づけ作業となります。以下作業についても、各リモート デスクトップ セッションホストにて実行してください。

1. [リモート デスクトップ セッション ホスト サーバーの構成]を起動します。

2. [RDP-Tcp] のプロパティを開きます。

 3. [証明書：] 欄にある「選択」ボタンを押します。

4. コンピューターの個人ストアにインストールされている証明書の一覧が表示されるので、ファーム名で作成した証明書を選択し 「OK」 を押します。

5. [証明書：] 欄が 「自動生成」 と言う表示から 「FARM1」 に変わります。

以上の設定で、[リモート デスクトップ接続]を起動して、コンピューター名の欄に 「FARM1」 と入力して リモートデスクトップ接続を実行する際に、警告メッセージが表示されなくなります。

ただし、RemoteApp を起動する場合はさらに以下設定が必要となります。

1. [RemoteApp マネージャー] を起動します。

2. [RD セッション ホスト サーバー] 欄の横の 「変更」 を選択します。

3. [接続の設定] 欄において、[サーバー名] に「FARM1」 と入力します。

4. [デジタル署名] タブを選択し、[デジタル証明書を使用して署名する] にチェックを入れ「変更」ボタンを押します。

5. 証明書選択のポップアップが表示されるので、ファーム名の証明書を選択し「OK」を押します。

6. [デジタル証明書の詳細] 欄に FARM1 証明書の情報が表示されます。「適用」「OK」 ボタンを押します。

以上の設定を完了してから、RemoteApp マネージャーより RDP ファイルを作成しクライアントに配布してください。RDP ファイルより RemoteApp を起動すると以下メッセージが表示されるだけとなり、証明書エラーの警告メッセージが表示されなくなります。

こんにちは。

プラットフォームサポートの丸山です。

今日は、SP1 を適用した Windows 7 端末や Windows Server 2008 R2 端末に、リモートデスクトップ、または RemoteApp などを使用してログオンし、Easy Print でリダイレクトされたプリンターを使用するときの動作変更のお話です。

■ Windows 7 SP1 または Windows Server 2008 R2 SP1 の Easy Print プリンタードライバーの動作変更について

リモート デスクトップ接続または RemoteAppを利用して、別のコンピューターにログオンした場合、Easy Print プリンター ドライバーを使用して、クライアント端末のプリンターをサーバーで使えるようにプリンターのリダイレクトを行うことができます。

このとき、接続先のコンピューターが SP1 が適用された Windows 7 または Windows Server 2008 R2 環境である場合において、Easy Print を使用してリダイレクトされたプリンターでは、拡大、縮小印刷機能に使用される、スケーリング機能がサポートされなくなりました。

特に、Easy Print を使用した場合には、印刷設定画面はクライアント端末のプリンター設定画面が呼ばれるため、ユーザーはプリンタードライバーがサポートするすべての機能が問題なく動作することを期待しますが、仮にユーザーが印刷設定画面でスケーリングに関わる設定項目を変更した場合には、この値は単純に無視される動作となります。

■ Easy Print でスケーリングがサポートされなくなった変更の経緯について

まず、Easy Print の処理の流れ��ついて確認しましょう。

以下の図は、Easy Print を使用したときの、印刷処理の簡単な流れですが、注目すべきポイントは、サーバーで実施された印刷処理が、クライアント端末にXPS形式で転送されるところです。

図 : Easy Print の処理の流れ

このとき、サーバー側で動作しているアプリケーションにて実行された印刷処理は、内部的に Microsoft XPS Document Converter (MXDC) の機能を使用して、一時ファイルとして使用する XPS 形式の印刷データを作成します。

Office などのアプリケーションでは、プリンター ドライバーがスケーリング機能をサポートしていない場合には、アプリケーション独自のスケーリング機能を使用して、印字結果がスケールされますが、プリンター ドライバーがスケーリング機能をサポートしている場合には、アプリケーション独自の機能ではなく、プリンター ドライバーのスケーリング機能を利用します。

しかしながら、Easy Print プリンター ドライバーが使用している MXDC は、拡大縮小印刷のためのスケーリング機能をサポートしていないため、アプリケーションが設定した拡大縮小印刷が意図した印刷結果とならない現象が報告されました。

確認されている影響としては、たとえば縮小印刷を実施した場合に用紙サイズよりも大きな印刷物を正しく取り扱えず、印字結果が欠けてしまう現象や、拡大印刷を実施した場合にプリンターの余白領域が考慮されず、印字位置がずれてしまう現象などが挙げられます。

このような問題について対応策を検討した結果、Easy Print プリンター ドライバーを使用する場合には、スケーリング機能が期待通りの出力結果とならないと判断し、スケーリング機能をサポートしないよう変更すべき、との結論に至りました。

以上のような状況から、SP1 が適用された Windows 7 または Windows Server 2008 R2 環境では、Easy Print を使用してリダイレクトされたプリンターでは、スケーリング機能をアドバタイズしないよう、変更されております。

この変更は、たとえばサーバー側で動作しているアプリケーションがリダイレクトされたプリンターに対して DeviceCapabilities 関数の問い合わせを実施した場合に、プリンターがスケーリング機能をサポートしていないことを示す応答が返されます。

また、アプリケーションが印刷時の DEVMODE の dmScale にスケーリング値を設定しても、最終的な印刷結果にはスケーリングの値が反映されません。

■ 本問題の回避策について

この動作変更による問題を回避するためには、以下のようなアイデアがあげられます。

1. アプリケーションが対応している場合、独自スケーリング機能を使用する

弊社 Office シリーズなどの一部のアプリケーションでは、プリンタードライバーがスケーリング機能をサポートしていないときに、アプリケーション独自のスケーリング機能が動作して、拡大、縮小印刷が可能となる場合があります。

お使いのアプリケーションが独自のスケーリング機能をサポートしている場合には、その機能を使用することで、問題の回避ができます。

2. サーバーに直接接続されたプリンターを利用する

サーバーとなる端末が近くにある場合や、利用者数が少ない状況では、あらかじめすべてのプリンター接続をサーバーに登録しておくことで、リダイレクトされたプリンターを使用した問題の発生を避けることができます。

3. 従来形式でリダイレクトされたプリンターを使用する

今回の動作変更の結果、Easy Print を使用した場合には、スケーリング機能が無効化されますが、クライアント環境にて動作しているプリンタードライバーがスケーリングをサポートしている場合には、従来形式のプリンターリダイレクトを使用することで、スケーリング機能が有効となります。

ただし、従来形式のリダイレクトを使用するには、クライアントで使用しているプリンタードライバを、サーバーとなるコンピューターにもあらかじめインストールしておく必要があります。

※ クライアント端末が 32bit で サーバー端末が 64bit である場合など、クライアント端末とサーバー端末の CPU アーキテクチャが違う場合には、それぞれのアーキテクチャ向けのプリンタードライバーをインストールしておく必要があります。

プリンタードライバーをインストールしていただき、サーバーとなるコンピューターにて以下のグループポリシーを [無効] に設定すると、Easy Print よりも、従来形式のプリンターリダイレクトが優先されるようになります。

[コンピューターの構成] ※または [ユーザーの構成]
  [管理用テンプレート]
   [Windows コンポーネント]
    [リモート デスクトップ サービス]
     [リモート デスクトップ セッション ホスト]
      [プリンターのリダイレクト]
       [リモート デスクトップ Easy Print プリンター ドライバーを最初に使う]

設定後の画面はこんな感じです。

図 : ポリシー設定変更後の画面

本ポリシー設定後、コンピューターを再起動すると、設定が反映されます。

■ 参考情報

ターミナル サービスの印刷機能
http://technet.microsoft.com/ja-jp/library/cc772270.aspx

TS RemoteApp
http://technet.microsoft.com/ja-jp/library/cc731340.aspx

■ 今後の展開について

今回の動作変更は、SP1 が適用された Windows 7 または Windows Server 2008 R2 のほか、Windows 7 RTM、Windows Server 2008 R2 RTM、Windows Vista SP2、Windows Server 2008 SP2 の最新のLDRブランチに反映されております。このため、これらのバージョンの Windows でも、今後リリースされる修正プログラムの適用や、サービスパックの適用などにより Easy Print の動作変更が反映される可能性があります。

なお、本動作変更につきましては、新しい情報があり次第、本ブログを更新していく予定です。