• Windows Server 2012 R2 環境で Quota 6 イベントが記録される

    こんにちは。

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

    本日は、Windows Server 2012 R2 環境で出力される Quota 6 イベントについてお伝えいたします。

    クォータの設定を行っているドライブを Window Server バックアップで取得した場合、バックアップ期間中に Quota 6 のイベントがシステム ログに記録されます。
    Quota 6 のイベントはクォータ ドライバーをボリュームに対して接続できず、正常にクォータの設定が行えなかったことを示します。バックアップ期間中に表示される Quota 6 に記載のボリュームは、VSS (Volume Shadow Copy) を取得する際に利用されるボリュームです。本ボリュームは書き込みが保護されているため、クォータ ドライバーの接続は Windows Server バックアップによるバックアップ処理への介入を行う処理ではございません。そのため、Quota 6 のイベントがバックアップ期間中にのみ記録され、それ以外のタイミングでは記録されていない場合は、本イベントは無視可能なイベントであり、バックアップ データにも影響を与えないイベントです。

    なお、クォータがボリュームに対して正常に設定されているかを確認するにあたりましては fltmc コマンドをご利用ください。

     >fltmc instances -f quota

     実行例:
     C:\>fltmc instances -f quota

     Instances for quota filter:

     Volume Name                              Altitude        Instance Name       Frame  VlStatus
     -------------------------------------  ------------  ----------------------  -----  --------
     C:                                        125000     quota                     0
     D:                                        125000     quota                     0

    正常にクォータ ドライバーが接続されている場合、対象のボリュームが上記の通り表示されます。クォータの設定が外れている場合は、以下のコマンドを利用し、クォータの再設定をご実施ください。

     >fltmc attach quota <ボリューム名>

     実行例:
     C:\>fltmc attach quota e:
     
     ATTACH successful... Instance Name: quota

  • スタートアップ修復の無効化について

    こんにちは。Windows プラットフォーム サポートの世古です。

    日々のサポート業務の中で、お問い合わせを頂く内容についてご紹介します。

    今回は Window 7 で標準の機能となっている「スタートアップ修復」の無効化方法についてご紹介します。管理上「スタートアップ修復」によるシステムの復元をユーザーに行わせたくない場合には以下の手順をご参照下さい。まず「スタートアップ修復」の機能について知りたい方は “補足(スタートアップ修復について)” で説明しておりますので、そちらを先にご確認ください。

    「スタートアップ修復」は既存の設定でシステムの復元機能が有効になっており、実行すると直近の復元ポイントに復元されます。最近インストールしたドライバやソフトウェアなどが起動障害の原因である場合、システムの復元が自動実行されることで障害が取り除かれます。

    しかしグループ ポリシーなどで復元ポイントの作成を無効にしている環境では、新たに復元ポイントが作成されることはなく古い復元ポイントのみが残ってしまっている場合があり、スタートアップ修復が行われた結果として、システムを構築した時点の環境に復元されてしまう場合があります。このような環境においては、以下に記載したスタートアップ修復の無効化および復元ポイントの削除が有効な場合がございます。

     

    ・スタートアップ修復の無効化方法

    以下にスタートアップ修復を無効化する手順を紹介いたします。

    1. コマンド プロンプトを管理者権限で起動します。

    2. 下記の 2 つのコマンドを実行します。

     

    bcdedit /set {current} recoveryenabled No

    bcdedit /deletevalue {current} recoverysequence

     

    また以下のコマンドにて再度有効にする事が出来ます。

     

    REAgentc /Enable

     

    (補足)

    対象となるWindows ブート ローダーの identifier に {current} 以外の値が設定されている場合は、各端末毎にGUID を確認していただく必要がございます。

    Windows ブート ローダーの値の確認は bcdedit コマンドで確認できます。

     

    ・復元ポイントの削除方法について

    以前の復元ポイントに戻る事を回避する為に、スタートアップ修復の無効化に加え、システムの復元ポイントを削除する場合には以下の手順をご参照ください。

    システムの保護は、シャドウ コピーの機能を利用して情報を管理しており以下のコマンドの実行により、復元ポイントの削除が可能です。

     

    Vssadmin Delete shadows /All

     

    削除されたかどうかは、下記のコマンドを実施し、「クエリを満たす項目が何もありませんでした」となれば、削除は成功しています。

     

    Vssadmin List Shadows

     

    ・補足(スタートアップ修復について)

    Windows 7 では既定で自動フェールオーバーという機能が有効であり、システムの起動に何らかの要因で失敗した場合、Windows RE (回復環境)にフェール オーバーさせ、[スタートアップ修復] の機能を提供します。

    システムの起動後、以下の様な画面が表示されます。


    しばらくすると、選択されている項目で自動的に起動されます。ここでスタートアップ修復の起動(推奨)が選択されていた場合には以下の画面が表示されます。

     

    そして次に [システムの復元] を実施するかの選択画面に推移します。

    単に [スタートアップ修復] を実施するのであれば問題はありませんが、ここで誘導される [システムの復元] を行う場合にはいつの復元ポイントに戻るかについて考慮する必要があります。

     

    Windows 7 では Windows Update などによる更新プログラムのインストールやドライバのアップデートの際、自動で復元ポイントが作成され、あるいは前回復元ポイントが作成されてから 7 日以上経過している場合は自動で復元ポイントが作成されます。

     

    以下参考情報となりますので併せてご参照ください。

    <参考情報>

    Windows RE の機能: http://technet.microsoft.com/ja-jp/library/dd744291(v=ws.10).aspx

    Windows 回復環境テクニカル リファレンス: http://technet.microsoft.com/ja-jp/library/dd744255(v=ws.10).aspx

     

  • パフォーマンス モニターの時刻表示ずれについて

    こんにちは。Windows サポートチームの太田です。
     
    今回はパフォーマンス モニターの表示に関する問題を確認いたしましたので、ご紹介いたします。

    [概要]
    パフォーマンス モニターを用いて、グラフにてリアルタイムのパフォーマンス データを表示させている際に、
    実際のシステム時刻からずれた時刻が表示される場合があります。

    [詳細]
    この現象は、長期間連続稼働させていることによって表示上の問題が発生する場合があります。
    パフォーマンスデータやグラフの描画自体はリアルタイムに正しく表示されますが、表示される時刻が実際のシステム時刻よりも過去の時刻が表示されます。

    具体例を示します。

    図の例では、システム時刻は 23:52 ですが、パフォーマンスモニターに表示されるリアルタイムの時刻は、17:52 となり 6時間遅れています。

    [影響]
    この事象は、パフォーマンスモニターの時刻表示に限定した問題で、時刻以外は正確な情報が表示されます。
    また、データ コレクターを用いて採取するパフォーマンスログはこの影響を受けません。

    [回避策]
    定期的にパフォーマンスモニターを終了/起動していただくようお願いいたします。

    [対象OS]
    Windows Server 2008 /Vista 以降の Windows にて発生することを確認しております。

    ご不便をおかけいたしますが、上記回避策にてご対応くださいますようお願いいたします。




  • RDS (TS) CAL について

    こんにちは。

    Windows プラットフォーム サポートの吉田です。

    今回は、リモート デスクトップ サービス (旧ターミナル サービス) で利用される CAL (Client Access License) の概要および動作についてご説明いたします。

    Windows Server に多数のセッションを同時に接続させるためには、リモート デスクトップ サービス環境を構築する必要がありますが、ご利用いただくためには、各クライアントに対して、リモート デスクトップ サービス クライアント アクセス ライセンス (RDS CAL) を発行します。

     ※ Windows Server 2008 までは、ターミナル サービス クライアント アクセス ライセンス (TS CAL) が正式名称となりますが、本稿では全て CAL と記載します。

     

    CAL の動作原理や有効期限について、よくいただくご質問を以下にまとめました。

    ぜひご参考ください。

     

    1. CAL の概要

    --------------------------

    CAL は大きく以下の 2 種類に分類されます。

    • デバイス CAL
    • ユーザー CAL

    この 2 種類は、お客様のリモート デスクトップ サービス環境に応じて、使い分けていただく必要があります。

    簡単に説明すると、デバイス CAL は接続元デバイス (クライアント) 毎に対して発行され、ユーザー CAL は接続ユーザー毎に発行されます。

    例えば、一つのデバイスを複数人でご利用いただく環境の場合はデバイス CAL、一人のユーザーが複数のデバイスをご利用いただく環境の場合は、ユーザー CAL をご利用する事で、購入 (インストール) いただく CAL の数量を効率よく管理できます。

     

    重要なポイントとして、一台のセッション ホスト サーバー (ターミナル サーバー) に対しては、デバイス CAL を使って接続させるか、ユーザー CAL を使って接続させるかに応じて、いずれかのライセンス モードを選択する必要があります。

    セッション ホスト サーバーが両方の CAL に応じる事はできません。

    なお、一台のライセンス サーバーに、デバイス CAL、ユーザー CAL の両方をインストールする事は可能です。

     

    デバイス CAL、ユーザー CAL はそれぞれ発行動作が異なります。

    次項でそれぞれの動作概要をご説明します。

     

    2. デバイス CAL について

    ---------------------------

    デバイス CAL は、クライアント コンピューター (デバイス) に対してセッション ホスト サーバーへアクセスする権限を与えます。

    デバイス CAL が一度発行されると、その情報がクライアント コンピューター上に保持されます。

    デバイス CAL の情報は、クライアントの以下のレジストリに格納されます。

     HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSLicensing\Store\LICENSE00x

     

    図 1 : デバイス CAL 情報 レジストリ

     

    デバイス CAL は、初回接続時に発行される一時 CAL と、二回目の接続時に発行される恒久 CAL の二種類が存在します。

     

    [一時 CAL]

    クライアント コンピューターからセッション ホスト サーバーに初めて接続した時に発行されるライセンスです。

    一時 CAL の有効期限は、一律で 90 日間となり、恒久 CAL の余剰数がない状態の場合は、二度目以降の接続時も一時 CAL のまま接続します。

    一時 CAL の発行数に制限はありません。

     

    図 2 : 一時 CAL 発行例

     

    [恒久 CAL]

    一時 CAL を持っているクライアント コンピューターが二回目に接続した時に発行されるライセンスです。

    恒久 CAL の有効期限は、52 日間から 89 日間のランダムな期間が設定されます。

    この有効期限を任意の期間にすることはできません。

    ライセンス サーバーにインストールした数量を上限として発行されます。

     

    図 3 : 恒久 CAL 発行例

     ----

    上記の通り、デバイス CAL には一時 CAL、恒久 CAL ともに有効期限をもっています。

    その有効期限を過ぎた場合には、もちろん接続ができなくなります。

    そのため、セッション ホスト サーバーに接続するクライアント コンピューター数を適切に管理する必要があります。

     

    [恒久 CAL の更新について]

    恒久 CAL の有効期限は、52 日間から 89 日間のランダムな期間が設定されますが、その有効期限日の 1 週間前から CAL の更新期間となります。

    更新期間中にセッション ホスト サーバーに接続する事で、新たに 52 日間から 89 日間のランダムな期間が設定されます。

     

    [ライセンスの失効について]

    Windows Server 2008 以降の CAL については、ライセンス マネージャー上から、失効処理を行う事ができます。

    接続する事がなくなったクライアントや、誤って接続して発行させてしまったクライアントに対して、発行された CAL を失効させ、別のクライアントのために発行の余剰を作ることができます。

    ※ Windows Server 2003 以前の CAL については失効処理を行う事ができません

     

    図 4 : 失効

     

    失効できる数はインストールしている CAL 総数の 20 % までとなります。

    また、失効された CAL につきましても、発行先のクライアントが保持する CAL の情報は変わりませんので、有効期限内は接続する事が可能です。

    失効処理は、あくまでライセンス サーバー上の管理上の情報となります。

     

    極端な例となりますが、100 CAL が存在し、全ての CAL が発行済みであるとします。

    その状態で上限となる 20 % の CAL を失効させ、さらに新規で 20 台のクライントが接続し、恒久 CAL が発行された場合、一時的には 120 台のクライアントが恒久 CAL を持つ状態となります。

     

    [クライアント の識別について]

    セッション ホスト サーバーは、接続元のクライアントをコンピューター名ではなく、各クライアントが一意で持つ Hardware ID で識別します。

    仮に同様のホスト名を持つクライアントからの接続が受け付けた場合においても、別のクライアントとして管理されます。

    Hardware ID は、クライアント コンピューターの以下のレジストリにあります。

     

     HKLM\Software\Microsoft\MSLicensing\HardwareID\ClientHWID

     

    図 5 : Hardware ID

     

    ただし、ライセンス マネージャー上では、コンピューター名のみで表示されますので、同じコンピューター名を持つクライアントが存在する環境や、コンピューター名の変更が発生する場合には注意が必要です。

    また、ライセンス マネージャー上は、初回 CAL 発行時のコンピューター名で表示されますので、CAL を持つクライアントのコンピューター名を変更した場合においても、旧コンピューター名のまま表示されます。

     

     3. ユーザー CAL について

    ---------------------------

    ユーザー CAL には、デバイス CAL のような、一時 CAL や恒久 CAL といった概念はありません。

    また、デバイス CAL のように、接続元クライアントのレジストリに情報が記録される動作でもありません。

     

    CAL の発行情報は、ドメイン コントローラー上の各ユーザー コンテナに情報として格納されます。

    その情報については、Windows Server 2012 以降の環境あれば、ライセンス マネージャー上に表示されますが、Windows Server 2008 R2 以前のバージョンにおいては、ライセンス マネージャー上には表示されず、レポート機能を使用する必要があります。

    以下は Windows Server 2012 ライセンス サーバーの例となります。

    ライセンス サーバーが、ドメイン環境かつ Windows Server 2012 以降の場合は、ライセンス マネージャー上でユーザー CAL の発行状況を確認する事ができます。

     

    図 6 : ユーザー CAL 発行例

     

    なお、ユーザー CAL の有効期限は一律で 60 日間となっておりますが、その有効期限は、あくまでその時点で発行されているユーザー CAL の情報管理のため使われるものとなり、有効期限を超過した場合も、超過直後の接続時に新たな有効期限が付与されますので、長期間アクセスが無い場合においても、接続不可となる事は発生いたしません。

     

    ユーザー CAL (ユーザー数ライセンス モード) では、1 人のユーザーに対して、無制限の数のクライアントからセッション ホスト サーバーにアクセスする権限が与えられます。

    ユーザー CAL (ユーザー数ライセンス モード) はライセンスによって強制されることはありません。

    そのため、ライセンス サーバーにインストールされている CALの数に関係なく、クライアント接続を行うことができます。

    ただしこれによって、各ユーザーに有効な CAL を持たせなければならないという、マイクロソフト ソフトウェア ライセンス条項の要件から管理者が免除されるわけではありません。

    接続ユーザー数ライセンス モードを使用している場合に、各ユーザーに有効な CAL を持たせることができなければ、ライセンス条項違反となります。

      

    4. デバイス CAL 運用において、クライアントが接続できなくなった際の暫定対策について

    ------------------------------------------------------------------------------------------

    ライセンス マネージャー上で、対象クライアントに対して、正常にライセンスが 発行されているにも関わらず、クライアントがセッション ホスト サーバーに接続ができなくなった場合や、恒久 CAL の余剰数がない状態で、有効期限が超過したクライアントをどうしても接続させる必要がある場合の暫定対策として、クライアントで保持しているライセンス情報、および HardwareID を削除して、ライセンス サーバーに対して、新規接続のクライアント と判断させて接続する方法があります。

     

    <暫定対策 : クライアントのレジストリ削除>

    [ハードウェア ID] および、ライセンス情報のレジストリを削除することで、セッション ホスト サーバー側で、新規接続のクライアントだと判断され、ライセンス サーバーから一時 CAL が発行されます。

     

    そのため、一時 CAL にて、90 日間は リモートデスクトップ 接続が可能となります。

    恒久 CAL に使用可能な数が残っている場合には、 2 度目の接続から 一時 CAL から恒久 CAL に変わります。

     

    削除する必要のあるレジストリは以下となります。

     1. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSLicensing\HardwareID\ClientHWID

     2. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSLicensing\Store\LICENSE00x

       (LICENSE00x は x に数字が入ります。いくつか存在する場合がありますので、その際は全て削除します)

     

    なお、上記手順の実行につきましては、クライアント PC の administrator 権限のあるユーザーにて実行する必要があります。

    また、初回接続時に、新たに HardwareID レジストリが作成されますので、初回接続時につきましても、administrator 権限のあるユーザーにて実施する必要があります。


    補足情報 : 多段 RDP 接続について

    ------------------------------------------------------------------------------------------

    Windows Server 2008 R2 までは、多段 RDP 接続はサポートされておりません。

    例 : Windows 7 ---- RDP ----> Windows Server 2008 R2 (1) ---- RDP ----> Windows Server 2008 R2 (2)

    英語文献とはなりますが、以下に公開情報がございます。

    - Running a Remote Desktop session within another Remote Desktop session is not supported
      http://support.microsoft.com/kb/2582684

    しかしながら、条件つきとはなりますが、Windows Server 2012 からは、正式にサポートされております。

    - Running a Remote Desktop Connection session within another Remote Desktop Connection session is supported with Remote Desktop Protocol 8.0 for specific scenarios
      http://support.microsoft.com/kb/2754550

    例 : Windows 8 ---- RDP ----> Windows Server 2012 (1) ---- RDP ----> Windows Server 2012 (2)

    上記のように、クライアントは Windows 8 以降であり、サーバーはいずれも Windows Server 2012 以降である必要がございます。

    なお、CAL については、[Windows Server 2012 (1)] に接続するために、[Windows 8] に必要となり、[Windows Server 2012 (2)] に接続するために、中継となる [Windows Server 2012 (1)] に発行される必要がございますので、数量の管理にはご留意願います。

     ---------------------------------------------------

     -参考文献

     リモート デスクトップ サービス クライアント アクセス ライセンス (RDS CAL)

      http://technet.microsoft.com/ja-jp/library/cc753650.aspx

     リモート デスクトップ ライセンスの概要

      http://technet.microsoft.com/ja-jp/library/cc725933.aspx

     リモート デスクトップ サービス クライアント アクセス ライセンス (RDS CAL) を管理する

      http://technet.microsoft.com/ja-jp/library/dd759163.aspx

     Removing Terminal Server licenses from an RDP client

      http://support.microsoft.com/kb/187614/ja

  • Windows 7 での RemoteFX USB リダイレクトについて

    こんにちは。

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

    今回は、Windows 7 での RemoteFX  USB リダイレクトを使用するうえで注意事項を紹介させて頂きます。

    リモート デスクトップ接続した際、リモート セッション上でローカル コンピューター (クライアント) のデバイスやリソースを使用したい場合に、リダイレクトという機能を使用することが可能です。
    しかしながら、従来のリダイレクトできるデバイスは限られており、Web カメラ、スキャナ等は MTP (メディア転送プロトコル) または PTP (画像転送プロトコル) がサポートがされていない場合リダイレクトを行うことができませんでした。

    そこで、どのデバイスでもリダイレクトが出来るように、RemoteFX USB リダイレクトがWindows 7 SP1 及び Windows Server 2008 R2 SP1  に KB 2592687 を適用することによりサポートされるようになりました。

    RemoteFX USB リダイレクトでは、厳密にはリダイレクトを行いたいUSB デバイス だけでなく、USB ポートのエミュレートも行います。
    そのため、ローカルのデバイスとして、USB 2.0 Driver が使用されていた場合においても、RemoteFX USB リダイレクトでは、まず、自身に最適なデバイスである USB 3.0 の使用を試みます。
    Windows 7 では USB 3.0 が ネイティブにサポートされていないため、USB 3.0 ポートを認識することができず、リダイレクトを行うことができません。


    上記の動作は Windows 7 を RDP クライアントとしてご利用いただく上での機能上の制限となります。Windows 7 でUSB デバイスのリダイレクトを行う場合には USB 2.0 ポートとしてリダイレクトをご利用いただく必要がございます。
    なお、Windows 8 以降の OS では、USB 3.0 スタック はネイティブに実装されているため、RemoteFX USB リダイレクトとして USB 3.0 を使用することが可能です。


    - 参考文献
    USB ドライバー スタック アーキテクチャ
    http://msdn.microsoft.com/ja-jp/library/windows/hardware/hh406256(v=vs.85).aspx

    ローカルのデバイスとリソースをリモート セッションで使用できるようにする
    http://technet.microsoft.com/ja-jp/library/cc770631.aspx

    Windows 7 と Windows サーバー 2008 R2 のリモート デスクトップ プロトコル (RDP) 8.0 更新
    http://support.microsoft.com/kb/2592687
    ※ RemoteFX USB リダイレクトを利用する為には上記の修正プログラムを適用し、Remote Desktop Connection 8.0 以上を使用する必要があります。