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

今回は Windows Server 2016 で記憶域スペースの機能を利用して記憶域階層を用いた
仮想ディスクを作成する際の注意点についてご紹介します。

なお、記憶域スペースの機能で記憶域プールから仮想ディスクを作成した後、仮想ディスクの
拡張が実行できないことがございます。これは想定された動作ですが、本件では触れていないため
詳細は以下の Blog をご参照ください。

記憶域スペースの NumberOfColumns と仮想ディスクの拡張について
https://blogs.technet.microsoft.com/askcorejp/2017/06/22/numberofcolumns-of-storagespace/

■ 記憶域階層について

Window Server 2012 R2 より記憶域スペースでは記憶域プールにSSDとHDDの両方が
存在している場合、2つの記憶域の階層から構成される仮想ディスクの作成が可能となりました。

・SSD階層は頻繁にアクセスされるデータ用
・HDD階層はアクセスする頻度が少ないデータ用

記憶域スペースはデータのアクセス頻度に基づき、データを1MB単位のサブファイル（ブロック）レベルで
２つの階層の間で移動させます。記憶域階層は頻繁にアクセスされるデータを SSD に、アクセスする頻度が
少ないデータは HDD に移動させることで、パフォーマンスがすぐれた仮想ディスクを作成することができます。

■ Windows Server 2016 における仮想ディスク（階層化）作成の注意点

記憶域プールから仮想ディスク（階層設定）を作成する際に、仮想ディスクに割り当てる容量を
設定しますが、Windows Server 2016 では “最大サイズ” を選択すると作成実行後、以下のエラーが発生します。

これは、Windows Server 2016 に追加された新機能「記憶域スペースダイレクト」の
multi-resiliency tiering によってミラー化されたパリティ構成（mirror-accelerated parity）が
可能になったことにより、階層構成がより複雑化したことで、構築の際に生成される
メタデータの容量等が、追加の領域を消費することで上記エラーが発生している状況です。

最大サイズで算出されている容量は、各階層を個別に表示しています。そのため、現在、記憶域階層を
構成する際に実際に必要なリソース（割り当てられる最大サイズ）を、適切に算出するための方法がございません。

Windows Server 2016 の記憶域プール機能を使用して仮想ディスク（階層設定）を作成する際は
最大サイズで算出された容量から、更に容量を減らす調整を実施いただき、設定値を確定してください。
※ 記憶域プールのディスク構成や設定によって、この追加の領域 (減らす必要のある量) として必要な容量は異なります。

弊社検証環境では以下のように空き領域から約 2 割引いたサイズを指定すると
仮想ディスク（階層化）の作成が成功しました。作成するときは、最大サイズから
容量を少し減らして設定してください。

＜参考情報＞
ミラー化されたパリティ構成については以下の「Planning volumes in Storage Spaces Direct」で
ご紹介しています。

Planning volumes in Storage Spaces Direct
https://docs.microsoft.com/en-us/windows-server/storage/storage-spaces/plan-volumes

以下、それぞれ記憶域スペースダイレクトについての公開情報です。

Storage Spaces Direct in Windows Server 2016
https://docs.microsoft.com/en-us/windows-server/storage/storage-spaces/storage-spaces-direct-overview

Deep Dive: Volumes in Storage Spaces Direct
https://blogs.technet.microsoft.com/filecab/2016/08/29/deep-dive-volumes-in-spaces-direct/

本ブログがお役にたてば幸いです。

皆さんこんにちは。
Windows プラット フォーム サポートの今入です。

今回は、Windows 10 で移動ユーザー プロファイル を使用している場合に、スタートメニューの一部アプリケーションが表示されなくなる事象についてご紹介します。

事象

初回ログオン時	二回目以降のログオン時

※ スタートメニューのピン留めは、省略して (全て外して) おります。

解決策

このような環境の場合は、以下のレジストリをご設定頂くことで、事象を回避することが出来ます。

レジストリ パス: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Explorer
名前: SpecialRoamingOverrideAllowed
種類: REG_DWORD
値: 1
※ OS の再起動が必要となります。

影響

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

今回は Windows Server 2016 を起動すると、毎回以下の “シャットダウン イベントの追跡ツール” が起動する現象についてご紹介いたします。

[現象]
Windows Server 2016 で “Network List Service” サービスが無効化されていると、起動時に毎回以下のように “シャットダウン イベントの追跡ツール” が起動します

Windows OS の既定の動作として、シャットダウン (または再起動) の処理で、”Eventlog サービス″ が正常に終了できなかった場合、次回の OS 起動時に以下のイベントログ (ID 6008) の記録とともに上記の “シャットダウン イベントの追跡ツール” のダイアログが表示される動作があります。

このため、冒頭に記載した現象は、何らかの要因で毎回 “Eventlog サービス” が正常に終了することができない状況であるため、毎起動時に “シャットダウン イベントの追跡ツール” のダイアログが表示されることを示しています。

[原因]
OS に既定で存在する以下の “Network List Service” サービスのスタートアップの種類が “無効” に設定されている場合に必ず発生します。
これは、Windows Server 2016 で内部的に追加されたコンポーネントの影響によって、“Network List Service” サービスが無効である場合には、シャットダウン時に行われる各サービスの終了処理が正常に完了できないことに起因します。

[回避策]
本現象に対する回避策は “Network List Service” サービスのスタートアップの種類を “手動” または “自動” に設定ください。
※ OS の既定値は “手動” です

“Network List Service” サービスのスタートアップの種類を “手動” または “自動” に変更する場合の手順は、以下の通りです。

1. “Windows” + “R” キーを押下し、[ファイル名を指定して実行] を起動し、”services.msc” と入力し、[OK] ボタンを押します。
2. サービス画面にて、名前が “Network List Service” を探し、右クリックから [プロパティ] を選択します。
3. Network List Service のプロパティ画面にて、”スタートアップの種類” を “手動” または “自動” を選択し、[OK] ボタンを押します。

こんにちは、日本マイクロソフト Windows サポートの高谷です。

日々のサーバー管理で、更新プログラムは 1 つの重要なテーマと言えると思います。

この更新プログラム(いわゆるパッチ)を適用しようとした際、エラーになって適用できなかった、という経験はないでしょうか？

いろいろな原因が考えられますが、一つの大きな理由は、「すでに適用済みだから」ということが挙げられます。

同じ修正内容が含まれた別の更新プログラムが適用済みのために、今回適用しようとした更新プログラムは適用できなかったのかもしれません。ある更新プログラムに含まれる修正内容が、後発の別の更新プログラムに包含されていることは珍しくないのです。

更新プログラムの適用に失敗した際に、それが「既に適用済みだから」適用できなかった、もしくは、同じ修正内容が含まれている更新プログラムが適用済みだから、ということであれば、特に追加のアクションは必要ないので、適用済みかどうかがわかればとても便利です。

そこで今回は、更新プログラムの適用に失敗した際に、それが既に適用済みなのかどうかを確認する方法をお伝えしたいと思います。

■     更新プログラムの公開情報ページの見方

更新プログラムの公開情報のページは、タイトルに続いて、現象、原因、解決策という4つの大項目が並んでいますが、この ”解決策” の大項目の中に ”修正プログラムの情報” という小項目があります。

図 1) 更新プログラムの公開情報のページを開いた画面

図 2) ”修正プログラムの情報” の小項目内に “ファイル情報” のタブがあります。

この項目では、修正プログラムを適用するにあたっての前提条件や、適用時に再起動が必要か、などの情報が記載されておりますが、この小項目の一番下に、”ファイル情報” のタブが用意されております。

この “ファイル情報” のタブをクリックして開きますと、修正対象となっているファイルが具体的にその名称まで確認することができます。

図 3) 今回の更新プログラムでは、修正対象は “Storport.sys” であることが確認できます。

この更新プログラムを適用すると、 “Storport.sys” というファイルのバージョンが、6.3.9600.17122 になるというですので、ご自分の環境で “Storport.sys” のバージョンを確認すれば、この更新プログラムもしくは同じ修正内容が含まれる更新プログラムが適用済みであると判断できます。

なお、更新プログラムのロールアップ等、修正対象ファイルが多い場合は、.csv ファイルでおまとめして提供されている場合もございます。

図 4) 更新プログラムのロールアップの場合のトップページ

図 5) “ファイル情報” から CSV 形式で対象ファイルの情報一覧をダウンロードします。

■     “Storport.sys” のバージョンの確認方法 (例として)

今回の例では、”Storport.sys” が修正対象のファイルでしたので、例としてこのファイルのバージョンを確認してみます。

// 確認の手順

1. エクスプローラーで C ドライブを開き、検索バーで “Storport.sys” 検索します
2. 見つかった “Storport.sys” を右クリックし、プロパティを開きます。
3. [詳細] タブから “ファイル バージョン” の欄を確認します。

バージョンを確認すると、6.3.9600.17383 となっており、6.3.9600.17122よりもバージョンが上のため、修正されていることが判断できました。

今回は、更新プログラムが適用されているかどうかを確認する方法について、ご紹介させていただきましたが、いかがでしたでしょうか。

本ブログが少しでも皆様のお役に立てますと幸いです。

いつも弊社製品をご利用いただきまして誠にありがとうございます。
Windows プラットフォーム サポートの石田です。

パフォーマンスモニターにて LogicalDisk 及び PhysicalDisk のカウンターが表示されなくなる事象が発生した場合の対応についてご案内させていただきます。

[事象]
以下の Windows Server にてパフォーマンスモニターのLogicalDisk 及び PhysicalDisk のカウンターが表示されなくなる事象が発生することがございます。

– Windows Server 2008 Service Pack 2
– Windows Server 2008 R2 Service Pack 1
– Windows Server 2012
– Windows Server 2012 R2
– Windows Server 2016

[発生条件]
弊社にて把握できている発生条件は以下となります。

– Windows Server 2008 R2 にて更新プログラム 4041681 以降のバージョンが適用されている環境でパフォーマンスカウンターの情報を取得している。
– Remote Registry サービスは svchost.exe を複数のサービスと共有して起動している。
※ Remote Registry サービスは既定で svchost.exe を複数のサービスと共有可能な設定となっております。

[原因]
パフォーマンスカウンターの情報は Remote Registry サービスを介してパフォーマンスモニターへ返されております。パフォーマンスカウンターの情報を提供する Remote Registry サービスの内部処理のハンドリングに不具合があり LogicalDisk 及び PhysicalDisk のカウンターの情報を返す処理が呼び出されなくなるため本事象が発生いたします。

本不具合につきましては、現時点では、”対象OS”のいずれにおきましても修正モジュールは作成されておりません。

[対応策]
Remote Registry サービスを svchost.exe に単独で動作させることによって解消することができます。

// Remote Registry サービスの分離
コマンドプロンプトを管理者モードで起動し以下のコマンドを実行します。

> sc config remoteregistry type= own
※ type と = の間にはスペースは入りません。

Remote Registry サービスが起動している場合は、以下のコマンドで終了させます。

> sc stop remoteregistry

Remote Registry サービスは必要に応じて起動するため停止状態で問題ございません。

本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。

いつも弊社製品をご利用いただき誠にありがとうございます。 Windows プラットフォーム サポートの石井です。

本稿では、エラー イベント ID:30 についてご紹介します。

以下のエラー イベント ID:30 が更新プログラム適用後の再起動時に一度だけ記録されることがあります。

——

        ログの名前:         System

        ソース:           Microsoft-Windows-Eventlog

        日付:            YYYY/MM/DD HH:MM:SS

        イベント ID:       30

        タスクのカテゴリ:      サービスの開始

        レベル:           エラー

        キーワード:         サービス利用可能時間

        ユーザー:          LOCAL SERVICE

        コンピューター:    SERVERNAME

        説明:

        発行元 {0bf2fb94-7b60-4b4d-9766-e82f658df540} をチャネル

        Microsoft-Windows-Kernel-ShimEngine/Operational に有効にするときに、

        イベント ログ サービスでエラー (5) が発生しました。チャネル操作には影響

        ありませんが、発行元がチャネルにイベントを発行する際に影響があります。

        このエラーの一般的な理由の 1 つは、プロバイダーが ETW プロバイダー

        セキュリティを使用しており、イベント ログ サービス ID へのアクセス許可が

        与えられていないことです。

——

現在の実装上、当イベント ID:30 につきまして記録されることが確認されておりますが、一度だけ記録された当イベントは、安全に無視することができます。

Microsoft-Windows-Kernel-ShimEngine の Operational チャネルは既定で有効化されているログであり、本エラー イベントが出力された場合にも、Operational チャネルの状態は有効になります。

そのため、一般的には本エラー イベントが出力されたことによって、イベント ログ サービスや、システムの動作に影響を与えることはなく、無視いただいても問題ないイベントであると判断できます。

こんにちは、Windows プラットフォーム サポート 宮崎です。

今回は、Windows 10 の環境で Sysprep を用いたマスターイメージを作成する際の一般的な注意点やサポート部門より推奨する展開方法を紹介します。
これから初めてマスターイメージを作成する方もすでにマスターイメージの展開を行っておられる方も、ぜひ一読いただき貴社の展開内容と照らし合わせることでお役に立ててください。

目次

本ブログの目次とサマリーです。

1. Sysprep の考え方・・・マスターイメージの作成という工程には計画・工数を要します。
2. マスター イメージの前提条件・・・主に Sysprep を実行したボリュームライセンス メディアを利用します。
3. マスターイメージとして設定可能な範囲・・・設定可能な箇所は検証いただく必要があります。
4. 品質更新プログラムの適用・・・最新の品質更新プログラムの適用をお勧めします。
5. アップグレード環境・・・ご利用予定のバージョンの OS を新規にクリーン インストールした環境をお勧めします。
6. 複数ユーザープロファイルが存在する環境・・・単一のユーザー プロファイルで作業を完結することをお勧めします。
7. ドメイン参加状態での Sysprep・・・ドメイン参加のタイミング・注意点を解説します。
8. 最後に
9. 各項の参考技術情報

1. Sysprep の考え方

Sysprep はシステムを大量展開する際に、マスターイメージの作成を支援するためのツールであり、イメージ作成時において、実行するものとなります。そのため、Sysprep コマンドはあくまでマスターイメージの作成という工程の中で行うことが想定され、運用環境やイメージ作成以外を目的とした利用はサポートされません。

また、Sysprep は様々な利用用途の実現を必ずしも保証するものではなく、本記事で紹介しています通り様々な注意点があります。そのためイメージ作成・展開にあたって計画的な検証工程や検証にあたっての工数をお見積りいただくこと、加えて、イメージ作成において不要な作業は実施しないことが推奨されます。

2. マスター イメージの前提条件

配布可能なイメージは以下を前提条件としています。

条件 A. Sysprep を実施していること

Sysprep は端末の固有の情報を初期化してそのイメージを別の端末で再利用するためのツールです。端末固有の情報は、SID のほか、CMID や SusClientID 等、様々な ID が含まれていますので、Sysprep を実施せずに端末を複製した場合、端末固有の情報が複製されてしまい幅広い範囲で問題が生じる可能性があります。

条件 B. ボリュームライセンス契約より入手したイメージを用いて構築すること

お客様がお使いいただけるイメージは下記の 3 種です。

• ボリュームライセンス サービスセンター (VLSC) より入手可能なイメージ
• MSDN サブスクリプションより入手可能なテストイメージ
• OEM ベンダーのイメージ作成のために別途提供しているイメージ

実際のイメージの展開にあたって、Windows の再イメージング権はボリューム ライセンスのメディアにのみ付与しています。OEM ベンダー以外のお客様はボリューム ライセンスをご契約の上、イメージ入手してください。ボリュームライセンスのイメージをつかって、実際のマシンに展開する際に個々のマシンに対するドライバーは、提供元より個別に入手しイメージにインストールしてください。

なお、OEM のマシンには、上記の再イメージング権が付与されておらず、OEM ベンダー以外のお客様は権利上、OEM のマシンを利用した Sysprep 実施、マスタイメージの作成は許可されていません。また、イメージ自体にも OEM ベンダー様によるカスタマイズが行われていることで想定されないエラーなども発生する可能性があります。

3. マスターイメージとして設定可能な範囲

Sysprep のツール自体は現行 OS でサポートされていますが、設定可能な範囲は実際に Sysprep を実行して得られた結果の範囲までです。OS やアプリケーションの設定によってはマスターイメージに含めることができない場合があります。また、OS の設定箇所は非常に多数にわたり、それらすべての設定できる箇所と設定できない箇所を網羅するリストはありませんので、あらかじめ検証環境にて設定可能か検証してください。

4. 品質更新プログラムの適用

マスターイメージの作成の計画時点の最新の累積的な品質更新プログラムを適用することをお勧めしています。これにより既知の問題をあらかじめ回避することが可能なためです。

また、品質更新プログラムは Windows 10 リリース 情報より KB 番号が確認でき、Microsoft Update カタログからスタンドアロンインストーラーを入手することが可能です。逐一、Windows Update から品質構成プログラムをダウンロード・インストールする工数を削減できるため利用をお勧めしています。

5. アップグレード環境

Windows 10 で Version 1703 から Version 1709 へアップグレードされた環境での Sysprep にてすでに下記のような問題が報告されています。

Title: MiracastView パッケージ Windows 10 バージョン 1709 にコンピューターをアップグレードした後 sysprep エラーが発生します。
URL: https://support.microsoft.com/ja-jp/help/4057974/miracastview-cause-sysprep-error-windows-10-version-1709

上記の現象の場合は、回避策を案内している次第ではありますが、回避策の実施のために別途作業が伴うことやアップグレード特有の問題を未然に防ぐためにもサポート部門からはアップグレード環境ではなく利用予定のバージョンを新規に作成することをお勧めしています。

お客様の業務の要件によっては、いったん作成手順を実施したイメージに対して、最後にアップグレードのみをかけて Sysprep を行うことでバージョンごとのイメージ作成の工数を削減するという観点もありますが、アップグレード自体が多くの機能の変更を及ぼし、その変更によって一部の設定が変更・初期化される動作もありますのでアップグレード環境を組み合わせたマスターイメージの作成計画のメリットは十分ではありません。

Sysprep の考え方としては、マスターイメージの作成に対して不要な作業を実施しないことが推奨されます。アップグレード環境をマスターイメージとして取り扱うことは通常、メリットがないばかりでなく、利用予定のバージョンでクリーン インストールした環境での Sysprep の実施よりも他の動作影響を引き起こす可能性が高くなっています。

ボリュームライセンスを契約しているお客様であれば、各バージョンのイメージは個別に入手可能です。利用予定のバージョンのイメージを入手し、そのイメージを利用して作成計画を検討いただくことをお勧めします。

6. 複数ユーザープロファイルが存在する環境

複数のユーザー プロファイルが存在するシナリオにおいて Sysprep の使用は想定されておらず、既存のユーザー プロファイルが破損する等の影響を弊社に寄せられています。マスターイメージの作成において、複数のユーザーでログオンし作業するメリットは通常ありませんので、初回のログオン時に作成した一つのユーザーで作業を完結することで、ユーザー プロファイルに起因するトラブルを未然に防ぐことが可能です。

7. ドメイン参加状態での sysprep

ドメイン参加状態での sysprep の実施は弊社サポート部門としてはお勧めしていません。ドメインに参加することで、意図しないグループ ポリシーが適用される可能性が非常に高く、これらのポリシー設定によって Sysprep の実施が失敗するリスクも高くなります。またドメインに一度参加した後に離脱して WORKGROUP の環境に戻しても、すべてのポリシー設定が既定のものに戻るわけではありません。

特定のアプリケーションや設定のために、ドメイン参加が必須の場合でも、運用環境との OU を分けるなどなるべく必要のないポリシーが適用されないよう作業することで Sysprep 失敗のリスクが軽減されます。

なお、展開後のドメイン参加が必要となる状況では、Sysprep を実行した際にドメイン参加させるための以下のブログ記事に沿うように業務要件を検討いただくことをお勧めします。

Title: Sysprep 実行時にドメイン参加を自動化する方法
URL: https://blogs.technet.microsoft.com/askcorejp/2010/06/30/sysprep-2/

8. 最後に

マスターイメージの作成に用いる Sysprep は、展開時に設定を自動化・共通化するために非常に有用なツールですが、上記のように複数の注意点があります。お客様の業務要件をどの程度満たせるかについては十分な検証の工数が必要です。

トラブルを未然に防ぎ工数を削減するためにも、既知の制限・制約については考慮の上、ご検討を進めていただけましたら幸いです。

本記事におきましては予告なく内容を変更させていただくことがあります。
今後、情報のアップデートがあれば、本ブログにて引き続き情報を提供いたします。

9. 各項の参考技術情報

1. Sysprep の考え方

Sysprep の概要やサポート範囲について下記技術情報にて紹介しています。

Title: Sysprep (システム準備) の概要
URL: https://msdn.microsoft.com/ja-jp/library/windows/hardware/dn938335(v=vs.85).aspx

Title: Unsupported Sysprep scenarios
URL: https://support.microsoft.com/en-us/help/828287/unsupported-sysprep-scenarios

2. マスター イメージの前提

前提条件に関して以下の技術情報より記載しています。

Title: Sysprep Command-Line Options
URL: https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/sysprep-command-line-options

///// 抜粋ここから /////
Important
You must use the Sysprep /generalize command to generalize a complete
Windows installation before you can use the installation for deployment
to a new computer, whether you use imaging, hard disk duplication,
or another method. Moving or copying a Windows image to a different
computer without running the Sysprep /generalize command is not supported.
///// 抜粋ここまで /////

Title: OS プレインストール PC (OEM PC) の再イメージング (コピーによる社内展開) について
URL: https://support.microsoft.com/ja-jp/help/945472

3. マスターイメージとして設定可能な範囲

下記技術情報ではサーバーの役割の Sysprep サポート有無について記載しています。サーバー製品に関しましては、大量展開が想定されていないサーバーの役割や機能などもありますので、これらの役割や機能が有効にされている状態での Sysprep の実施はサポートされません。

Title: Sysprep Support for Server Roles
URL: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-8.1-and-8/hh824835(v=win.10)

4. 品質更新プログラムの適用

累積的な更新プログラムの事前適用を推奨することを以下の技術情報にて紹介しています。

Title: マスター イメージ作成時の更新の適用について
URL: https://blogs.technet.microsoft.com/askcorejp/2016/12/08/update-before-sysprep/

5. アップグレード環境について

弊社から OS のアップグレードに伴う、お客様開発のアプリのための非互換情報のリストを提供していない理由を下記のブログにて解説していますが、これはアップグレードに伴う OS の変更箇所を網羅した情報を提供していないことと技術的背景については同様となります。参考にしていただけますと幸いです。

Title: Part 5-b. Windows 10 導入時に考え方・やり方を変えるべきポイント ? アプリ編②
URL: https://blogs.msdn.microsoft.com/nakama/2016/08/18/win10waas-part5b/

また、アップグレードに伴い一部の設定が変更・初期化されることがありますが、この動作についても、この技術的な背景と同様にリスト提供が原理的にしかねるものとなります。

Title: Windows 10 の仕様とシステム要件
URL: https://www.microsoft.com/ja-jp/windows/windows-10-specifications#upgrade

///// 抜粋ここから /////
アップグレードと同時に多数のアプリケーション、ファイル、設定が移行されますが、一部のアプリケーションや設定が移行されない場合があります。
///// 抜粋ここまで /////

6. 複数ユーザープロファイルが存在する環境

個別記事を以下に紹介しています。

Title: 複数のユーザー プロファイルが存在する状態で Sysprep を実施した際に予期しない問題が発生する
URL: https://blogs.technet.microsoft.com/askcorejp/2016/06/27/複数のユーザー プロファイルが存在する状態で Sysprep を実施した際に予期しない問題が発生する/

こんにちは、日本マイクロソフト Windows サポートの高谷です。

不慮の事態に備え、定期的にバックアップを取ることが一般的となっているほか、変更作業の前に念のためにバックアップを取っておくなど、日々の運用の中でバックアップは地味ながら大きな役割を担っています。

マイクロソフトでは、Windows Server の標準のバックアップソフトとして、Windows Server バックアップの機能をご用意しております。今回は、この Windows Server バックアップで取得したバックアップ データをリストアする際の、ディスクの選択についてご説明したいと思います。

■     Windows Server バックアップとリストア

Windows Server バックアップは、その名称の通り、Windows Server に標準で搭載されているバックアップ ツールです。Windows Server 2008 以降で、サーバー マネージャーから機能を追加いただくことでご利用いただけます。

バックアップの取得対象としては、サーバー全体はもちろんのこと、対象のボリュームだけの取得や、システム状態のみ、あるいはベアメタル回復に対応しています。バックアップデータの保管先は、ローカル ディスク、外付けハードディスクやネットワーク経由の共有フォルダに対応しています。

リストア時は、リストア先のディスクはユーザー側で選択は出来ず、システム側でリストア可能なディスクを探し出し、リストア先を決定します。では、バックアップ先の候補として全く同じサイズのディスクが複数存在した場合はどのようなロジックで、どのディスクがリストア先として選出されるのでしょうか。

今回ご説明するケースは、以下の状況で取得したバックアップをリストアすることを想定しています。

// 状況

・OS : Windows Server 2012 R2
・ファームウェア : UEFI
・バックアップ対象：サーバー全体
……….ディスク構成 > Disk 0, 600 GB(C ドライブ 220 GB, D ドライブ 380 GB), GPT パーティションスタイル
………………………………>.Disk 1, 600 GB(E ドライブ 220 GB), GPT パーティションスタイル
・バックアップ データ保管先：外付けハードディスク
・ディスクは 2 本とも破損した想定で、リストア時は同じ容量・同じメーカーのディスクを新品で2 枚用意
・リストア時は Windows Server 2012 R2 のインストール用 DVD から起動し、リストア実行

■     リストア時の挙動について

.
では早速、リストア先として、全く同じディスクが複数存在する場合、どのディスクがリストア先として選出されるのかをご説明します。

前提として、リストアの順番としては、最も重要である C ドライブ (システムドライブ) からリストアを行います。ファームウェアが UEFI システムの場合は、OS を起動するディスクは必ずしも Disk 0 である必要はありませんので、接続されているディスクの中でリストアに最適なディスクを探し出し、そこへリストアします。

DVD から起動した OS は、接続しているディスクの中から C ドライブのリストア先として最も適したディスクを以下の基準で検索し、最適なディスクがあるか確認します。

・ディスクの署名が一致するか
・パーティション スタイル (MBR or GPT) が一致しているか
・リストア可能なサイズのディスクか

上記が全て一致するものがあれば、そのディスクをバックアップ取得時と同じディスクと判断し、そのディスクへリストアを行います。

最適なディスクの検索は、Disk 0 から順に、基準にマッチしているか確認していきます。ところが今回のケースでは、新品の全く同じサイズのディスクを 2 枚用意したため、どちらも基準にマッチしません。

この場合、基準にマッチしているか確認を行った最後のディスク (ディスク番号の最も大きいディスク) に C ドライブをリストアします。その後、空きディスクへ他のドライブをリストアしますので、バックアップ時とリストア後のディスク番号が逆になる現象が発生します。

// リストア後の状況

・OS : Windows Server 2012 R2
・ファームウェア : UEFI
……….ディスク構成 > Disk 0, 600 GB(E ドライブ 220 GB), GPT パーティションスタイル
………………………………>.Disk 1, 600 GB(C ドライブ 220 GB, D ドライブ 380 GB), GPT パーティションスタイル

これはシステムのデザインであり、不具合ではありません。リストア後のシステムへの影響もありませんので、ご安心ください。

■     ディスク番号が逆になる現象の回避策について

.
上記のディスク番号が逆になる現象を回避するためには、バックアップ取得時にディスクの署名を確認しておき、リストア直前にディスクの署名を書き換えることが有効な手段です。ディスク署名の確認方法と、変更方法についてもここでご紹介いたします。

// ディスクの署名の確認方法

1. コマンド プロンプトを管理者権限で起動します。
2. diskpart と入力し、diskpart ユーティリティを起動します。
3. 以下のコマンドを入力します。接続されているディスクが列挙されます。

……….>list disk

出力結果の例)

ディスク        状態                サイズ      空き   ダイナ  GPT
###                                         ……………..          ミック
————–     ————–     ———–     ———   ——–    ——–
ディスク 0    オンライン     557 GB       0 B                       *
ディスク 1    オンライン     557 GB       0 B                       *

4. 対象のディスクを選択します。例として Disk 0 を選択します。

……….>select disk 0

出力結果の例)

ディスク 0 が選択されました。

5. detail disk コマンドでディスクの詳細情報を参照します。

……….>detail disk

出力結果の例)

LSI MR9362-8i SCSI Disk Device
ディスク ID: {92B2DC6F-1C13-4506-AA35-253702E4AC24}
種類       : RAID
状態       : オンライン
パス       : 1
ターゲット : 0
LUN ID     : 0
場所のパス : PCIROOT(0)#PCI(0100)#PCI(0000)#RAID(P01T00L00)
現在の読み取り専用状態: いいえ
読み取り専用  : いいえ
ブート ディスク  : はい
ページ ファイル ディスク  : はい
休止状態ファイル ディスク  : いいえ
クラッシュ ダンプ ディスク  : はい
クラスター化ディスク  : いいえ

“Disk ID” と表示されているのが、ディスクの署名です。

// ディスクの署名の変更方法

事前準備として、以下の手順にてディスクを初期化し、パーティション スタイルを GPT へ変更しておきます。

1. リストア時に DVD から起動させた OS において、リストアを行う前にコマンド プロンプトを [Sift] + [F10] キーで起動します。
2. diskpart と入力し、diskpart ユーティリティーを起動します。

……….>diskpart

3. 以下のコマンドを入力します。

……….接続されているディスクが列挙されます。

……….>list disk

4. 対象のディスクを選択します。例として Disk 0 を選択します。

……….>select disk 0

5. clean コマンドでディスクを初期化します。

……….>clean

6. パーティション スタイルを GPT に変換します。

……….>convert GPT

パーティション スタイルを GPT に設定したら、ディスクの署名を書き換えます。

7. 以下のコマンドでディスクの署名を書き換えます。

構文)
……….DISKPART> uniqueid disk id <新しい Disk ID>

例)
……….DISKPART> uniqueid disk id 92B2DC6F-1C13-4506-AA35-253702E4AC24

8. 最後にディスク署名が入力した値と一致しているか、detail disk コマンドで確認します。

……….>detail disk

ディスク署名の変更方法は以上です。
以上の手順でディスク署名をバックアップ時のものと同じに設定しておくことで、リストア先のディスクを誘導することが可能です。

本ブログが少しでも皆様のお役に立てますと幸いです。

皆さん、こんにちは。Window プラットフォーム サポートの高橋です。
Windows 製品を特定産業向けの組み込み用途としてご利用いただく場合に、 お客様の要件に合わせたカスタマイズに加えて、組み込み用途に特化した 独自開発のシェルへ既定のシェルより置き換える場合がございます。

本ブログではシェルを置き換えた場合に従来の Windows 7 SP1 と Windows 10  Enterprise 2016 LTSB で動作が異なる点について確認している事象をご案内します。

//Windows 10 Enterprise 2016 LTSB について

Windows 10 を組み込み用途にご利用いただく場合には、サポート ライフサイクルが 長期間提供可能で、機能更新を行わない長期サービス チャネル (LTSC) を推奨しています。 LTSC に対応した製品の最新版が Windows 10 Enterprise 2016 LTSB になります。

//シェルについて

ユーザーが Windows にログオン後にユーザー インターフェイスを提供する機能を Windows ではシェルとよんでいます。機能例としてはユーザーに対してデスクトップ上に 表示されるタスクバーの操作や、ファイル操作の機能を提供します。なお Windows の既定の設定では explorer.exe がシェルの機能を提供します。シェルの機能を提供するプロセス名を以下のレジストリ値に設定することで他のカスタム シェルに置き換えが可能です。

キー名：HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
値名　：Shell

既定では上記レジストリ値 Shell に “explorer.exe” が設定されています。

//シェル置き換え時の Windows 7 SP1 と Windows 10 Enterprise 2016 LTSB での
動作の違いについて

1) explorer.exe のファイル ブラウザーの動作の違いについて

Windows 7 SP1 では上記にご案内したレジストリ値書き換え後、ログオン時に カスタム シェルを起動後、カスタム シェルより explorer.exe を起動した場合、 explorer.exe はファイル ブラウザーと動作します。下記の画像はコマンド プロンプト (cmd.exe) をカスタム シェルとして見立てて、レジストリ値 Shell に cmd.exe を設定して ログオンしている状態です。コマンド プロンプトから explorer.exe を起動後、エクスプローラーの ウィンドウが開く動作となります。

一方で、Windows 10 Enterprise 2016 LTSB でシェルを置き換えた場合、カスタム シェルから explore.exe を起動すると、Windows 7 SP1 のスクリーン ショットの状態から、タスク バーやデスクトップが表示される動作となります。

なお、explorer.exe に C:\ などのオプションを指定して起動した場合には、 Windows 7 SP1 と同様の動作になり、ファイル ブラウザーとしてのウィンドウのみが 表示されます。

2) 壁紙の描画について

Windows 7 では壁紙の描画がカーネル側で行われていましたが、Windows 8 以降では explorer.exe の処理の中で行われようになりました。そのためシェルの置き換えをおこなって explorer.exe が起動していない場合、Windows 10 Enterprise 2016 LTSB では 壁紙の描画を行わない動作となります。なお C:\Windows\system32\WallpaerHost.exe を起動した 場合には壁紙が描画されます。。

上記にご案内しましたシェル置き換え時の Windows 7 SP1 と Windows 10 Enterprise 2016 LTSB での 動作の違いについては公式文書にも記載するように関連部門と確認をすすめております。 現在組み込み用途向けの OS を Windows 7 SP1 から Windows 10 LTSB (LTSC) への移行検討を進めているお客様もいらっしゃると思いますが、上記にご案内した情報が参考になれば幸いです。

補足事項 : Windows 10 Enterprise 2016 LTSB でのシェルの置き換えについては Windows 10 でサポートしている Shell Launcher の機能を利用して cmd.exe を埋め込みのシェルとして指定後、eshell.exe をレジストリ値 Shell に 指定して確認した結果です。Shell Launcher の概要については下記の技術文書をご参照ください。

“Shell Launcher”
https://docs.microsoft.com/en-us/windows-hardware/customize/enterprise/shell-launcher

こんにちは、日本マイクロソフト Windows サポートの高谷です。

突然ですが、新規ディスクを差し込んでディスクの初期化を行う際、パーティションのスタイルを選択する必要があります。皆様は普段どちらを選ばれていますでしょうか。今回は、それぞれのスタイルの特徴と、変更する方法と最近よくいただくお問い合わせと対処策についてご紹介したいと思います。

■     MBR (マスター ブート レコード) と GPT (GUID パーティション テーブル)

.
新しいディスクを追加した際は、まずはそのディスクを初期化する必要があります。初期化の画面で、ディスクのパーティション スタイルについて MBR か GPT のどちらかを選択しなければいけません。

MBR スタイルは、古くからある 標準 BIOS パーティション テーブルを使用します。この BIOS では、利用できるディスクのサイズが 2 TB までという制限があったため、これに変わる新しいシステムとして UEFI (Unified Extensible Firmware Interface)  が考案されました。UEFIのシステムにおいて利用するパーティションが GPT  スタイルです。GPT スタイルは、 2 TB 以上のサイズを扱うことができる一方で、Windows XP などの古いシステムでは利用することができません。システム要件に応じて選択をする必要があります。

■     現在使用しているディスクのパーティション スタイルを確認する方法

.
現在使用しているディスクが、MBR と GPT のどちらのスタイルで初期化されていたか確認する方法は 2 つあります。

方法 1. [ディスクの管理] 画面から確認する

.
(1)  [ディスクの管理] を起動します。
(2)  パーティション スタイルを確認したいディスクへカーソルを合わせて右クリックします。
…….⇒MBR ディスクの場合は、[GPT ディスクへ変換] が表示されます。
…….⇒GPT ディスクの場合は、[MBR ディスクへ変換] が表示されます。

※     対象のディスクをボリュームとして利用している場合は、表示は見えますがグレーアウトしています。

方法 2. Diskpart コマンドで確認する

.
(1)  コマンド プロンプトを管理者権限で起動します。
(2)  Diskpart コマンドで Diskpart ユーティリティーを起動します。

…….>diskpart

(3)  List disk コマンドでディスク情報を表示します。

…….>list disk

…….⇒GPT の欄にアスタリスクが表示されているディスクは、GPT ディスクです。
…….⇒GPT の欄にアスタリスクが表示されていないディスクは、MBR ディスクです。

■     MBR ⇔ GPT のパーティション スタイル変更方法

.
パーティション スタイルは、ディスクの初期化の際に選択する設定です。従って、残念ながらディスクを一旦初期化しないとスタイルを変更することができません。以下に変更方法をご紹介します。

(1)  ディスク初期化の前に、データを別の場所へ避難させます。
(2)  [ディスクの管理] を起動します。
(3)  対象のディスク上の存在するボリュームで右クリックし、[ボリュームの削除] をクリックします。

(4)  削除の確認ダイアログで、[はい] を選択します。
…….※ ボリュームを削除すると、ボリューム内のデータはすべて削除されます。事前にデータを待避してから実行ください。
(5)  ボリュームの削除が完了したら、ディスク上で右クリックし、[GPT ディスクに変換] をクリックします。

もともと GPT ディスクの場合は、[MBR ディスクへ変換] をクリックします。下の図では例として、MBR ディスクを GPT ディスクへ変換する場合を示しています。

(6)  GPT へ変換した後は、再度ボリュームを作成し、待避していたデータを戻します。これで変換は完了です。

■     ディスク拡張に関してよくいただくお問い合わせ

.
仮想化やクラウドのサービスが普及してから、弊社では以下の質問を受けることが多くなってきました。

Q. よくいただくご質問

.
==========================================================================
もともと MBR スタイルでディスクを初期化して利用していたが、データが増えてきた。
パブリック クラウド上のサーバーを利用しているため、クラウドの管理コンソールから仮想ディスクの拡張を行った。

その後、ゲスト OS 側で、ボリュームを拡張しようとしたが 2 TB バイトまでしか拡張ができない。
==========================================================================
.

クラウド上の仮想サーバーの場合、必要に応じてリソースを追加できるという特徴があります。ディスクのサイズも後から拡張できるため、システムの構築時には少し小さめにディスクを構築し、後から必要なだけ拡張するというお客様はとても多いです。

構築時にディスクを MBR スタイルで初期化してしまっていると、後から 2 TB 以上のサイズにボリュームを拡張できない問題に直面します。

こういった状況の場合、弊社からご案内できる解決方法は 2 つあります。

方法 1. パーティション スタイルを GPT に変更し、2 TB 以上のボリュームを作成する。

方法 2. ディスクをダイナミック ディスクに変換し、複数ディスクにまたがるボリュームを構成する。

方法 1. は “MBR ⇔ GPT のパーティション スタイル変更方法” の項目にて説明しましたので、ここからは方法 2. のダイナミック ディスクに変換する方法についてご紹介いたします。

■     ダイナミック ディスクへ変換することによるボリューム サイズ拡張 (2 TB 以上) 方法

.
(1)  事前の準備として新規のディスクを追加して、初期化まで済ませておきます。パーティション スタイルは MBR と GPT どちらでも問題ありません。
(2)  [ディスクの管理] を起動します。
(3)  サイズを拡張したいボリュームが存在するディスクを右クリックし、[ダイナミック ディスクに変換] をクリックします。

(4)  確認のダイアログで [変換] をクリックし、変換します。
…….※ 変換が完了すると、ディスクの管理画面上で、対象のボリュームの帯の色が黄色になります。
(5)  対象のボリューム上で右クリックし、[ボリュームの拡張] を選択します。

(6)  ボリュームの拡張ウィザードが起動します。
(7)  利用可能なディスクから、事前に追加しておいたディスクを選択し、[追加] してから、[次へ] をクリックします。

(8)  [完了] をクリックし、拡張を行います。拡張の確認では、[はい] を選択します。
…….※ 新規追加したディスクも自動的にダイナミック ディスクへ変換されます。
(9)  2 本のディスクにまたがってボリュームが構成されます。ディスクの管理画面では、帯の色が紫に変わります。これで完成です。

いかがでしたでしょうか。

本ブログが少しでも皆様のお役に立てますと幸いです。

こんにちは、Setup / Deployment サポート チームです。
今回は、更新プログラムの適用時に 0x80070020  (ERROR_SHARING_VIOLATION) のエラーで失敗する事象と、その対処方法について、ご紹介いたします。同様の事象を経験されている場合、こちらの情報を参考にしていただければ幸いです。 

Windows Server 2012 R2 および Windows 8.1 では、ネイティブ イメージ タスクと呼ばれる Windows タスクが実装されています。
具体的なタスク名は、以下です。

  \Microsoft\Windows\.Net Framework\.NET Framework NGEN v4.0.30319

  \Microsoft\Windows\.Net Framework\.NET Framework NGEN v4.0.30319 64

このタスクは .NET におけるネイティブ イメージを事前に作成するためのタスクです。
このタスクの動作と、更新プログラムを適用処理がバッティングした場合、0x80070020 (ERROR_SHARING_VIOLATION) のエラーが発生し、更新プログラムの適用が失敗してしまう場合があります。

 この事象はタイミングの問題であるため、時間を少し置いてから、更新プログラムの適用いただくか、以下のように手動でネイティブ イメージを作成し、その後に、更新プログラムを適用してください。 

～ 手順 ～

   1) コマンド プロンプトを [管理者として実行] で起動します。
   2) 下記のコマンドを実行し、ネイティブ イメージを手動で作成します。

      ngen.exe update /force
 
   3) 終了後、更新プログラムの適用を行います。

なお、更新プログラムの適用が 0x80070020 (ERROR_SHARING_VIOLATION) エラーで失敗した場合、同じ更新プログラム (あるいは関連性のある更新プログラム)を再起動後にもう1度適用すると、0x800f0831 (CBS_E_STORE_CORRUPTION) エラーに変わり、失敗してしまうこともあります。これは、該当の更新プログラムが途中まで進み、終了している可能性が考えられますので、事前に、該当の更新プログラムをアンインストールしてから、再度、適用をお試しください。 

また 0x80070020 (ERROR_SHARING_VIOLATION) のエラーは、前述のタスクとのバッティング以外にも、様々なアプリケーションとバッティングして発生する可能性があります。
上記の手順で対応しても、同様の事象が繰り返し発生するようであれば、後述する “クリーン ブート” 状態でのインストールをお試しください。

 <参考技術情報>
ネイティブ イメージ タスク
https://msdn.microsoft.com/ja-jp/library/hh691779.aspx

 Windows でクリーン ブートを実行する方法
https://support.microsoft.com/ja-jp/help/929135/how-to-perform-a-clean-boot-in-windows

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

ファイルサーバーではファイル サーバー リソース マネージャー (FSRM) の
クォータという、フォルダの利用サイズを制限する機能を使用して、環境を
監視されている方は多くいらっしゃると思います。

今回はクォータ値を設定している際に、制限をしているフォルダ内のファイルを
削除してフォルダの容量は充分にある状態なのに、クォータ値の使用容量が
減少しておらずクォータの上限値を超えてしまう不具合について紹介いたします。

この不具合は Windows Server 2008 /2008 R2 で発生します。
なぜ、フォルダの容量とクォータ値の使用容量に差異が発生するのか
また、対処策やよくご質問いただくお問合せをご紹介いたします。

  発生要因

FSRM のクォータ機能では、ファイル システムが管理しているメタ データ情報とは別に
クォータ機能のためのデータベースを保持していますので、クォータ対象の領域へ
ファイルが追加された際や、ファイルが削除された際にこのデータベースを更新します。

本事象は、クォータ設定を行ったフォルダ内のデータ (ファイルやフォルダ) を削除した
タイミングにより、クォータの Quota.sys ドライバが使用率の計算を正しく検知できず、
結果としてクォータのデータ ベースへ該当の削除処理が反映されないために発生します。

  対処策

本事象の恒久的な対処策は修正プログラムを適用し、操作されたファイルを
正しくハンドリングできる Quota.sys を動作させる方法です。

Windows Server 2008 の場合は KB2983628 を適用ください。
———————————————————-
■ 文章番号: 2983628
ファイル サーバー リソース マネージャーのクォータのフィルターはWindows Server 2008 SP2 で正しくデクリメントされません。
URL : http://support.microsoft.com/kb/2983628/en-us
———————————————————-

Windows Server 2008 R2 の場合は KB2679054 を適用ください。
———————————————————-
■ 文章番号: 2679054
Title : Free disk space is not reallocated to a disk quota when you delete files in Windows Server 2008 R2 (英文)
URL : https://support.microsoft.com/ja-jp/help/2679054/free-disk-space-is-not-reallocated-to-a-disk-quota-when-you-delete-files-in-windows-server-2008-r2
———————————————————-
※ 本修正プログラムの適用後に再起動が必要となります。

また、再起動後は、念のため “DirQuota” コマンドにてクォータの再スキャンの
実施をお願いいたします。手順につきましては以下にてご案内いたします。

================================
■ DirQuota コマンドについて
================================
クォータが設定されている領域の再スキャンを実施し、クォータのデータ
ベースの更新を行うコマンドになります。

DirQuota コマンド実行手順
————–
1.コマンド プロンプトを管理者権限で開きます。
2.以下のコマンドを実行します。

– 特定のパスを更新する場合
dirquota quota scan /path:<パス名>

例) dirquota quota scan /path:D:\share\user1

<参考情報>
Dirquota quota scan
https://technet.microsoft.com/ja-jp/library/cc742101(v=ws.10).aspx
————–

※ ディレクトリの使用量やファイル数によっては、 DirQuota コマンドでのスキャンに
お時間を要する場合がございます。その場合、 DirQuota コマンドでのスキャンを実施後も
しばらくの間一部のディレクトリで使用量が正しく反映されない状況となります。
具体的な目安時間をお伝えすることは困難でございますが、DirQuota コマンドでの
スキャン実施後に、以下コマンドを実行することにより、スキャンが完了しているか
確認することが可能です。

> Dirquota quota list

※ 実行結果の “クォータの状態” が “再構築” となっていれば未完了、 “有効“と
なっていれば完了していることを示します。

Dirquota quota list で以下のように情報が取得できます。
——————————–
クォータのパス:         C:\o
説明:なし
ソース テンプレート:    100 MB 制限 (一致するテンプレート)
クォータの状態:         有効　　＜——–
制限:                   100.00 MB (ハード)
使用領域:               1.00 KB (0%)
利用可能:               100.00 MB
ピーク時の使用率:       1.00 KB (2017/11/28 18:25)
しきい値:
警告 ( 85%):         電子メール
警告 ( 95%):         電子メール, イベント ログ
制限 (100%):         電子メール, イベント ログ
——————————–

よくお問合せいただくご質問　Q&A

Q1.修正プログラムの適用をすぐには実施できないので、他の対処策はないのか？

A1. 残念ながら、恒久的な対処策は修正プログラムの適用のみです。
しかし、一時的に事象を改善させる方法はございます。
以下のコマンドでクォータのデータベースを手動で
更新することでクォータ値を再算出し、使用率が正しく更新されます。

＞ dirquota quota scan

※ 本コマンドでデータベースの使用率が一時的に正しい値になっても、
Quota.sys がデータ削除を正常に検知しないという不具合は発生します。

————————————————-

Q2. クライアント OS によっては、本事象が発生していないユーザーもいるが
OS のバージョンによって発生有無が異なるのか？

A2. 本不具合は Quota.sys が正常に削除を検知しないことで発生するため
ファイルの削除を実施するユーザーやクライアント OS のバージョンは
関係ありません。

————————————————-

Q3. 本事象（Quota.sys が削除を正常に検知しない動作）は、ファイルの削除時に必ず発生するのか？

A3. ファイルの削除時に、必ずしも本事象が発生するわけではございません。
サイズが大きいファイルの削除時や多くのファイルを一括で削除した際などに
本事象が発生することが多い傾向であることは確認できております。

————————————————-

Q4. 修正プログラム（KB2983628、KB2679054）を適用した際の影響について

A4. KB2983628 及び KB2679054 は Quota.sys のみの修正を行っております。
そのため、その他のドライバー情報は含まれておりませんので他の機能や
システムに影響はございません。

————————————————-

本ブログが少しでも皆様のお役に立てますと幸いです。

皆さん、こんにちは。Windows プラットフォーム サポートの大羽です。

Windows 8.1 以降の OS をご利用の方で、コントロール パネルの「デバイスとプリンターの表示」を開く際に、時間がかかることがあります。

通常はすぐに開きますが、時間がかかるときは 1 分 ～ 5 分程度、酷いときは 30 分ほど表示に時間がかかることがあります。

この問題は、問題の発生する端末に登録されているデバイス オブジェクトの数に依存します。
「デバイスとプリンターの表示」の処理では、各デバイスや子オブジェクトの列挙を行いますが、デバイス数が多い環境では、これらの情報の列挙数が累積的に増え、内部で繰り返し処理が行われるため、登録デバイス数が多い場合表示に時間がかかります。

この問題は Windows 10 RS2 (1703) 以降のバージョンでは改善が行われており、現在までに同様の問題についての報告はございません。
Windows 10 RS1 (1607) では、以下の更新プログラムを適用いただくことで、Windows 10 RS2 (1703) 同様に改善されます。

2018 年 1 月 18 日 — KB4057142 (OS ビルド 14393.2034)
https://support.microsoft.com/ja-jp/help/4057142/windows-10-update-kb4057142

残念ながら、Windows 10 RS1 (1607) より前の OS バージョンにつきましては、これらの改善が行われていないため、「デバイスとプリンターの表示」に時間がかかることがございます。

特に Windows Server 2012 R2 環境において、リモート デスクトップ サーバーとプリンター サーバーを兼任しているような場合に、クライアントのプリンター デバイス オブジェクトがサーバー上に集約されるため、登録デバイス数が増え、「デバイスとプリンターの表示」に時間がかかることがございます。

上記のような環境をご利用の皆様には、ご不便をおかけして申し訳ございませんが、「デバイスとプリンターの表示」が完了するまで、お待ちくださいますようお願いいたします。

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

Windows Server には、ファイル サーバー リソース マネージャー (以下 FSRM) という機能があります。ファイル サーバーを管理する上で便利であるため、ご利用いただいているお客様も多いのではないでしょうか。

今回は、その中の機能の一つであるクォータの動作についてご紹介したいと思います。

■     FSRM のクォータ機能とは

.
クォータは、フォルダに保存できるファイルの合計サイズに制限を設けることができ、ファイル サーバーのリソース管理に役立てることができます。クォータのテンプレートが初めから用意されていますので、これを使って簡単に利用制限を設けることができます。(もちろん自分で好きなサイズに設定することもできます)

また、クォータには、ユーザーにそれ以上のデータの保存を許さないハード クォータと、警告のみで保存は許可するソフト クォータがあるなど、柔軟な制御が可能になっています。現状、どれくらい使用しているかも “使用率” 欄にて一目で確認ができます。(下図)

この例の場合では、E ドライブの直下にある “テスト用フォルダ” に対して 100 MB のハード クォータを設定しています。使用率は 42 % なので、約 42 MB 分のファイルが保存されていることがわかりますので、ユーザーは残り約 58 MB 分の空き領域を利用することができます。

■     NTFS 圧縮について

.
少し話は変わりますが、NTFS 圧縮という機能をご存知でしょうか。
Windows 標準のファイル システムとして NTFS があります。NTFS を利用している場合、ドライブ/フォルダのプロパティで [詳細設定] をクリックすると、[内容を圧縮してディスク領域を節約する] という項目があります。このチェックボックスにチェックを入れると、NTFS のファイル システムの機能で圧縮を行い、ディスク上のサイズを小さくすることができます。NTFS の機能であるため、NTFS 圧縮と呼ばれています。

.zip 等のように拡張子が変わることはなく、設定したドライブ/フォルダ内で有効となり、内部のファイルが圧縮されます。この機能もディスク領域を効率よく利用できるため、ご利用いただいているお客様も多いのではないでしょうか。

このチェック ボックスにチェックを入れ、[OK] をクリックすると、圧縮の確認画面が現れ、さらにここで[OK]　を選択すると圧縮が即時に適用されます。適用されたドライブ/フォルダは、フォルダ名が青色で表示されるようになります。

プロパティを確認すると、ディスク上のサイズが確かに小さくなっていることがわかります。今回の例では、42 MB のファイルが 8.22 MB まで圧縮されています。

■     NTFS 圧縮した場合の FSRM クォータ画面について

.
さてここで、FSRM のクォータ画面はどうなっているか、確認してみましょう。

使用率が一気に下がり、 8 % と表示されています。FSRM のクォータは、ディスク上のサイズに対して制限を行っているため、このような表示となります。クォータで使える容量に制限を加えながらも、ユーザーが許可された領域を効率よく利用することができる例となります。

補足)
このテスト用フォルダの中身を DIR コマンドで確認すると、ファイルサイズと空き領域の和が、クォータの制限値を超えてしまい、矛盾した表示に見えます。これは、ファイルのサイズとしては圧縮前のサイズが表示されますが、空き領域としてはディスク上の空き領域が表示されるためにこのような表示になっています。

不具合ではありませんのでご安心ください。

今回はFSRM のクォータ機能と NTFS 圧縮の併用についてご説明いたしました。
どちらもとても便利な機能ですので、ぜひご利用いただければと思います。

本ブログが少しでも皆様のお役に立てますと幸いです。

こんにちは、Windows プラットフォーム サポートの大川です。
今回は Windows10 におけるレガシー フィルター ドライバーのブロック動作のお話になります。

まずは、フィルター ドライバーについてお話したいと思います。ファイル システムへ I/O が届くまでには、
いくつかのドライバーを介して、読み取りや書き込みが行われます。フィルター ドライバーはこのドライバーの
階層に追加され、I/O の動作を変更するためのドライバーになります。

例えば、弊社製品のファイル サーバー リソース マネージャー (FSRM) にクォータという、フォルダの利用
サイズを制限する機能があります。これは、Quota.sys というフィルター ドライバーが階層に追加されること
により実現されています。対象のフォルダ内にあるファイルに対してI/O が発行された際に書き込まれるサイズ
などを参照し、制限サイズを超える場合には、この I/O をファイル システムに届く前にブロックします。
これにより、設定したサイズ以上のデータが書き込まれないようにしています。

このように I/O の動作を変更する フィルター ドライバーですが、実は 2 種類のドライバーがあります。
ミニ フィルター ドライバーとレガシー フィルター ドライバーになります。

ミニフィルター ドライバーはフィルター マネージャーというコンポーネントと連携して動作しますが、
レガシー フィルター ドライバーはこのコンポーネントを介さずに直接、ファイル システムなどの操作を行います。

現在ご利用いただいている環境のフィルター ドライバーは fltmc コマンドで確認が可能です。

// 動作しているフィルタードライバーの表示方法
=============================================================================
1) コマンド プロンプトを管理者権限で起動します。

2) 以下のコマンドを実行します。

fltmc filters

表示例)
Filter Name                          Num Instances     Altitude   Frame
—————————— ——————     ————   —–
AVLegacy                                              389998.99   <Legacy>

EncryptionLegacy                               149998.99   <Legacy>

AVMiniFilter                               3       32800         0

※レガシー フィルター ドライバーが動作している場合は、上記のように一番右に が
表示されます。それ以外は、ミニ フィルター ドライバーとして動作しています。
=============================================================================

弊社としては、ミニフィルターに属するドライバーを使用することを推奨しています。これは、直接、
ファイル システムを操作するよりも、フィルター マネージャーを介して動作した方が、Windows 内で
より親和性や危険な動作などを検知し、抑止することが可能となるためです。

Windows10 では 2016 年 8 月頃に提供を開始した Aniversary Update から、このレガシーフィルター
に属するドライバーを動作させないための機能が追加されました。この機能は既定では無効となっており、
有効にすると、レガシー フィルター ドライバーのロードをブロックするように動作します。
この動作は、レジストリの値を変更することにより変えることが可能です。

この動作について、弊社から公開させていただいている記事がありますので、参照いただければと思います。

Blocking legacy file system filter drivers
https://docs.microsoft.com/en-us/windows-hardware/drivers/ifs/blocking-file-system-filter-drivers

現在提供させていただいている Windows10 のどのバージョンにおいても、既定の動作としては、ブロックする
機能は無効となっております。

しかし、2018 年春に提供を予定している Windows10 のバージョン以降においては、この既定の動作が変わる予定です。
つまり、レジストリの値を変更していなくても、既定でレガシー フィルター ドライバーのロードがブロックされます。
※ 2018 年春に提供を予定している Windows10 のインサイダー プレビューの動作もブロックする動作となっています。

もし、継続してレガシー フィルター ドライバーを利用されたい場合には、以下の手順でレジストリを変更いただければと思います。

// レガシー フィルター ドライバーの有効化手順
=============================================================================
1. コマンド プロンプトを管理者権限で起動します。

2. 以下のコマンドを実行し、有効化の項目を設定します。

reg add ” HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\I/O System” /v IoBlockLegacyFsFilters /t REG_DWORD /d 0

3. 以下のコマンドを実行し、項目が追加されていることを確認します。

reg query ” HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\I/O System” /v IoBlockLegacyFsFilters

表示例)
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\I/O System
IoBlockLegacyFsFilters REG_DWORD 0x0

4. OS を再起動します。

5. 再起動が完了したら、ログオンし、fltmc コマンドにてレガシー フィルター ドライバーがロードされていることを確認します。
=============================================================================

本ブログが少しでも皆様のお役に立てますと幸いです。

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

セッション ベースまたは VDI のリモート デスクトップ サービスでは、コレクションという概念でセッション ホスト サーバーまたは仮想デスクトップを管理いたします。
コレクション作成時には、一意となる任意の “コレクション名”を付けますが、”コレクション名” は日本語と英数字のいずれでも使用可能です。
ただし、日本語コレクション名、英数字コレクション名のいずれにおいても作成上の注意点がありますので、本ブログにて広報いたします。

■ 共通の注意事項

コレクション名を決める際、入力文字数に制限はございませんが、英数字の場合は先頭16文字のみでユニークなコレクション名であるかどうかが判断されます。
また、コレクション名を決めた際、内部で使用される “コレクション ID” が自動的に決まりますが、コレクション ID は 32 文字までの制限があります。

なお、後述いたしますが、日本語名コレクションの場合は一律で特別なコレクション ID が決められますので、まったく異なるコレクション名であってもユニークであるとは判断されません。

■ 日本語コレクション名についての注意事項

英数字コレクションの場合、コレクション名がそのまま “コレクション ID” となります。

例 :
コレクション名 : Test01
コレクション ID : Test01

ただし、日本語コレクション名の場合、日本語コレクション名がそのままコレクション ID にはなりません。
“farm” といった文字列に、サフィックスとして数字が加えられたものがコレクション ID となります。
例えば、”総務部” “経理部” “人事部” “渉外部” といったコレクションを作成した場合、それぞれのコレクション ID は以下になります。

1. コレクション名 : 総務部
   コレクション ID : farm
2. コレクション名 : 経理部
   コレクション ID : farm1
3. コレクション名 : 人事部
   コレクション ID : farm12
4. コレクション名 : 渉外部
   コレクション ID : farm123

上記の通り、”farm” に加えてサフィックスとして数字が一つずつ増えていく実装となっています。
この時、付加される数字は前回作成されたコレクション ID の末尾に、インクリメントされた数字が追加される形となりますため、コレクション ID の文字数が増えていきます。

ただし、ここで注意が必要なポイントとして、コレクション ID が 32 文字が限界となることとなります。

日本語コレクション名を増やしていくと、20 コレクション目のコレクション ID は以下となります。

farm12345678910111213141516171819

この時、コレクション ID は 33 文字となり、制限値を超えた文字数となるため、コレクション作成に失敗いたします。
つまり、日本語コレクション名については 19 コレクションまでが限界となります。

■ 英数字コレクション名についての注意事項

英数字の場合は、コレクション名がそのまま コレクション ID となりますが、16 文字目までをユニークな文字列とする必要があります。
コレクション ID として使用可能な文字数は 32 文字となりますが、16 文字目まで同じコレクション名の場合、17 文字目以降は日本語コレクション名と同様に自動的にサフィックスが付与されます。

例として以下のような名前のコレクションを 2 つ作ると仮定します。

Collection_Japanese_SOUMUBU
Collection_Japanese_KEIRIBU

この時、2 つのコレクションは 32 文字以内はユニークな名前となっておりますが、コレクション ID が作成される場合には、以下の 16 文字目までが同一コレクション名かどうかの判定に使われます。

Collection_Japan

そのため、上記 2 つのコレクションは、それぞれ以下のコレクション ID が割り当てられます。

Collection_Japan
Collection_Japan1

続けて、”Collection_Japanese” から始まるコレクションが作成された場合は、同様に以下のコレクション ID が割り当てられます。

Collection_Japan12
Collection_Japan123

日本語名コレクションの時と同様にコレクション ID の文字数が増えていきます。
そのため、同じ “Collection_Japanese” から始まるコレクション名が増えた場合、14 コレクション目で以下のように 33 文字を超えるため、コレクション作成に失敗します。

Collection_Japan12345678910111213

英数字コレクション名をご利用いただく際も、先頭 16 文字目までをユニークな名前としていただく必要があります。

■ 回避策について

コレクション ID については、任意で決めることや変更することができません。
しかしながら、コレクション名は作成後に変更することが可能となっております。

その点を利用し、まずは確実に重複しない英数字にてコレクション名を決定し、他と重複しないコレクション ID で作成します。
その後、コレクションのプロパティからコレクション名を変更することで、日本語コレクション名を 20 コレクション以上作成することや、英数字コレクション名の 16 文字目以上まで重複したコレクションを 14 コレクション以上作成することができます。

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

Windows Server には、ファイル サーバー リソース マネージャー (以下 FSRM) という機能があります。
ファイル サーバーを管理する上で便利であるため、ご利用いただいているお客様も多いのではないでしょうか。
今回は、その中の機能の一つであるファイル スクリーンの動作について、基本的な動作とよくあるご質問をご紹介したいと思います。

■ FSRM のファイルスクリーン機能とは

.
ファイル スクリーン機能は、特定のフォルダに対して、ユーザーが特定の種類のファイルしか保存できないよう制御する機能です。
ファイル グループが既定で用意されており、このグループを使って対象の種類のファイルの保存を制御できます。

.
例えば、.exe 等の実行形式のファイルをユーザーに保存させたくない場合は、ブロックするファイル グループとして “実行形式ファイル” を指定し、ファイル スクリーンを作成するだけで制御が可能です。
また、ファイルスクリーンの例外の作成によって、本来保存を許可されていないファイルを例外的に許可することも可能です。

※ ファイル スクリーンの作成方法については、以下の公開ページで紹介されております。

“ファイル スクリーンを作成する”
https://docs.microsoft.com/ja-jp/windows-server/storage/fsrm/create-file-screen

.
制御の大部分は最初から用意されているファイル グループで事足りると思いますが、自分でファイル グループを作成することでより柔軟な制御が可能です。以下に例をご紹介いたします。

例) .txt の拡張子のファイルだけ、保存を許可したい場合
.
テキストファイルのみ保存を許可し、それ以外のファイルは全て許可しない設定となります。
まずはファイル グループを作成します。

..1. [ファイル グループ] で右クリック -> [ファイル グループの作成] をクリックします。
..2. ファイル グループ名は任意で命名します。
..3. 含めるファイルに “*(アスタリスク)” を入力し、[追加] をクリックします。
..4. 除外するファイルに “*.txt” を入力し、[追加] をクリックします。以下の図のように設定できているか確認ください。

次にファイル スクリーンを作成し、ブロックするグループとして上で作成したグループを指定します。

..5. [ファイル スクリーン] で右クリック -> [ファイル スクリーンの作成] をクリックします。
..6. ファイル スクリーンのパスとして、設定を行うフォルダを指定します。
..7. [カスタム ファイル スクリーンのプロパティの定義] のラジオボタンにチェックを入れ、[カスタム プロパティ] をクリックします。
..8. ブロックするファイル グループの選択で、先ほど作成したファイル グループにチェックを入れ、[OK] をクリックします。

.
上記の設定では、拒否するファイルの名称として “*(アスタリスク)” を指定したため、すべてのファイルの保存を禁止しました。一方で “*.txt” (拡張子が .txt であればどんなファイルでも) を禁止の除外とする設定としましたので、.txt の拡張子のファイルだけ保存を許可することができました。
アスタリスクはワイルドカードであるため、アスタリスクを効果的に使うことがポイントと言えると思います。

■ よくあるご質問

.
弊社でファイル スクリーンに関してよくいただくご質問を公開させていただきます。

.
Q. ファイル スクリーン機能を有効にする前に置いていたファイルの拡張子が、ファイル スクリーンで禁止する予定の拡張子でした。機能を有効化するとこのファイルは削除されますか？

機能の有効化前に既に指定された拡張子のファイルが存在する場合には、ファイル スクリーンの対象外となりますので、削除されることはありません。ファイルの更新・削除などの操作が可能なまま残ります。

.
Q. コマンドでファイル スクリーンを作成する方法はありますか？

可能です。PowerShell にコマンドが用意されていますので、以下にご案内いたします。

“FileServerResourceManager”
https://docs.microsoft.com/en-us/powershell/module/fileserverresourcemanager/?view=win10-ps&viewFallbackFrom=winserverr2-ps

例) C ドライブ配下の Shared フォルダに対して、”イメージ ファイルのブロック” のテンプレートを利用してファイル スクリーンを作成したい場合は、以下のコマンドを実行します。

PS C:\> New-FsrmFileScreen -Path “C:\shared” -Template “Block Image Files”

.
Q. 拡張子は何でもいいので、10 文字のファイル名のファイルだけ保存を許可したいのですが可能ですか？

残念ながら、ファイル スクリーンの機能は、ファイル名の長さに関しては制御することができません。

.
Q.特定のサイズ以下のファイルのみ保存を許可したいのですが可能ですか？

残念ながら、ファイル スクリーンの機能は、ファイルのサイズに関しては制御することができません。

いかがでしたでしょうか。
本ブログが少しでも皆様のお役に立てますと幸いです。

皆さん、こんにちは。Windows サポート チームです。

今回は、5 月 9 日 (日本時間) に提供される予定の更新プログラムが、リモート デスクトップ並びに関連技術に影響する範囲について、紹介します。
もともとは、CredSSP と呼ばれる認証プロトコルの脆弱性に関する対策で CVE-2018-0086 にて公開済みの問題であり、各オペレーティングシステム向けに対策された更新プログラムは、3 月の時点で提供済みとなっております。
この対策に対して、5 月 9日に提供される更新プログラムでは対策済みのモジュールの既定の接続方法が変更されるため、環境によりリモートデスクトップ接続に問題が生じる場合があります。

尚、本説明にて「３月の更新プログラム」という記載がございますが、具体的なKB番号はOS毎に異なるため後述の KB リストをご参照ください。

目次.
1. 問題概要
2. 接続可否パターン
3. 解決先
4. 回避策
5. 参考情報

1. 問題概要

CredSSP の脆弱性情報 CVE-2018-0886 対策のためリリースされた 3月の更新プログラムを基として、新たに5月にリリースされる更新プログラムにて更にセキュリティレベルが上がります。
全てのコンピューターに更新プログラムが適用済みであれば問題はありませんが、3月以降の更新プログラムがリモートデスクトップ接続先に適用されていない状態で、接続元に5月の更新が適用されると既定ではリモートデスクトップ接続ができなくなります。また、RemoteAppの場合はエラーメッセージなくアプリケーションが終了します。

本記事を参考にして事前対処を行い、リモート デスクトップ、RemoteApp、仮想デスクトップ環境などへ接続できなくなることへの対策を行っていただきますようお願いいたします。

3月以降の更新プログラムを適用すると以下のポリシーで CredSSP の挙動が制御されるようになります。

ポリシーのパス:
[コンピューターの構成] – [管理用テンプレート] – [システム] – [資格情報の委任]
– [暗号化オラクルの修復] (英語 : Encryption Oracle Remediation)

3 月、4 月の更新プログラムではポリシーが未構成の場合、既定の接続方法が [脆弱 (Vulnerable)] ですが、5 月の更新プログラムでは、既定の接続方法が [緩和 (Mitigated)] に変更されます。この結果、各更新の適用または未適用のコンピューターが混在するとリモート デスクトップ接続が出来ない状況が発生します。
基本的には CVE-2018-0086 記載のある下記の相互運用性一覧に従いますが、以下にリモート デスクトップのご利用環境の具体例に沿って、対策および影響を説明しておりますので、ご参照ください。

具体的には下記ケースでリモートデスクトップ接続先ができなくります。

• リモートデスクトップ接続先 (RD 接続ブローカーを含む) が３月の更新プログラム未適用
• リモートデスクトップ接続元が５月の更新プログラム適用済み

2. 接続可否パターン

3. 解決策

リモートデスクトップ接続先に CVE-2018-0886 の 3 月以降の更新プログラムを適用いただくこととなります。
注意が必要な点といたしまして、リモート デスクトップ サービス (RDS) 環境でご利用いただいている場合、RD 接続ブローカー サーバーにも適用いただく必要がございます。
これは RDS 環境の場合、接続時の認証が RD 接続ブローカー サーバーでも行われるためです。
なお、RDS 環境ではその他に RD Web アクセス、RD ゲートウェイ、RD ライセンス、RD 仮想化ホストの役割が利用されますが、これらの役割自体は本件に関与しません。しかし運用等にてこれらのサーバーにリモートデスクトップ接続することがある場合には 3 月以降の更新プログラムを適用して下さい。

4. 回避策

リモートデスクトップ接続先に 3 月以降の更新プログラムを適用できない場合には以下の回避策がございますが、いずれもセキュリティ リスクが高まりますので、影響をご理解いただいたうえで実施願います。

4-1. リモートデスクトップ接続元(クライアント) での回避策 1

リモートデスクトップ接続元にて以下のポリシーを変更することでリモートデスクトップ接続先に 3 月以降の更新プログラムが未適用の場合でも接続可能となります。

[コンピューターの構成]
-> [管理用テンプレート]
-> [システム]
-> [資格情報の委任]

ポリシー名 : Encryption Oracle Remediation (暗号化オラクルの修復)
設定 : Vulnerable (脆弱)

4-2. リモートデスクトップ接続元(クライアント) での回避策 2

リモートデスクトップ接続元にて以下レジストリを手動もしくは REG ADD コマンドで追加いただくことでも回避策 1 と同様の効果が得られます。

レジストリ パス : HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters
値 : AllowEncryptionOracle
データの種類 : DWORD
値 : 2

REG ADD コマンドで追加いただく場合には以下のコマンド ラインとなります。
REG ADD HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters /v AllowEncryptionOracle /t REG_DWORD /d 2

※ レジストリ変更後に再起動は必要ございません。

4-3. リモート デスクトップ接続先(サーバー) での回避策

リモートデスクトップ接続先 で NLA (Network Level Authentication) を強制しないようにすることで接続可能となります。

NLA を強制しないようにするためには、以下の3つの方法のいずれかで設定できます。

方法１：

以下のポリシー変更にてNLAを強制しないようにすることができます。

[コンピューターの構成]
-> [管理用テンプレート]
-> [Windows コンポーネント]
-> [リモート デスクトップ サービス]
-> [リモート デスクトップ サービス セッション ホスト]
-> [セキュリティ]

ポリシー名 : リモート接続にネットワーク レベル認証を使用したユーザー認証を必要とする
設定 : 無効

方法 2:

[システムのプロパティ] －[リモート] タブにおいて、「ネットワークレベル認証でリモートデスクトップを実行しているコンピューターからのみ接続を許可する」
のチェックを外します。

方法 3：

リモート デスクトップ サービス (RDS) 環境にて、RD 接続ブローカーで接続先 (RD セッション ホスト) をコレクション管理している場合には、コレクションのプロパティで以下を変更することでも対処が可能です。

コレクションプロパティ において、
「ネットワークレベル認証でリモートデスクトップを実行しているコンピューターからのみ接続を許可する」
のチェックを外します。

尚、コレクションに参加していないRD 接続ブローカーでは上記方法 1. もしくは方法 2. で NLA を強制しないようにしていただく必要がございます。

4-4. NLA を強制しないことに関する注意事項

NLA を強制しないようにすることで CredSSP を利用しなくなるため、本脆弱性における影響は受けなくなります。
しかしながら、以下の通りセキュリティレベルを下げる状態となりますので、弊社としては NLA を強制しないようにする事は推奨しておりません。

NLA は RDP 接続時に接続先端末がユーザーとのセッションを確立する前にユーザー認証を要求し、セキュリティを強化するための認証方法です。
NLA を強制しないようにした場合、NLA を利用しない接続元コンピューターから接続が行われた際に、RDP 接続時のセッションが確立後に認証が行われるため、セキュリティレベルが低下します（Windows Server 2003 と同様のセキュリティ レベル）。
すなわち、資格情報を確認する前に、セッション ホスト サーバーへのセッションが確立されてしまうため、この点を突く悪意のある攻撃があった場合、セッションを乱立させることでポートが枯渇し、セッション ホスト サーバーが使用できない状態に陥るような、セキュリティが低い事による弱点をさらす事になりますのでご注意ください。

5. 参考情報

CVE-2018-0886 の CredSSP の更新プログラムについて (当社サポートブログ)
https://blogs.technet.microsoft.com/jpntsblog/2018/04/20/cve-2018-0886/

CVE-2018-0886 の CredSSP の更新プログラム(サポート技術情報)
https://support.microsoft.com/ja-jp/help/4093492/credssp-updates-for-cve-2018-0886-march-13-2018

CVE-2018-0886 | CredSSP のリモートでコードが実行される脆弱性
https://portal.msrc.microsoft.com/ja-jp/security-guidance/advisory/CVE-2018-088

KB List(3月以降の更新プログラムのKB番号)
下記KBのいずれかがリモート デスクトップ接続先に適用されていれば本件を回避することができます。