Hebikuzure's Tech Memo

2020年9月11日

OneDrive のグループポリシー

Filed under: Microsoft Office — タグ: , — hebikuzure @ 7:02 午後

Windows 10 には OneDrive アプリが含まれていて、個人用 OneDrive、OneDrive for Business、SharePoint Online のドキュメント ライブラリをクライアント(Windows PC)に同期することができます。

企業で Microsoft 365 を契約して従来のファイルサーバーや NAS などの代わりに OneDrive for Business や SharePoint Online をクラウド ストレージとして利用する際、以下のような課題が出てくるでしょう。

  • PC のストレージが少ないのでファイル オンデマンドを全員有効にしたい(逆にファイル オンデマンドを無効にしたい場合もあるかも)
  • 会社の OneDrive for Business との同期はさせたいが、個人用 OneDrive を勝手に同期させたくない
  • ネットワーク帯域が有限なので、OneDrive の同期トラフィックを制御したい

こういうニーズには通常グループポリシーを使うのですが、Windows 10 でグループポリシー エディターを開くと、管理用テンプレートに OneDrive の項目がありますが。設定項目が以下のように少ししかありません。

スクリーンショット 2020-09-11 183822

OneDrive だから Office だろうと思って Office 向け管理用テンプレートをダウンロード/適用しても、OneDrive の項目はありません。OneDrive はグループポリシーでは詳細に制御できないのでしょうか。

OneDrive の管理用テンプレート

実は OneDrive 用の管理用テンプレートは OneDrive のインストール フォルダーに用意されています。

OneDrive はマシングローバルまたはユーザー単位でインストールされているので、以下のいずれかがインストール フォルダーです。

%localappdata%\Microsoft\OneDrive\

C:\Program Files (x86)\Microsoft OneDrive\

このフォルダーの中にビルド番号ごとのフォルダーがあり、さらにその中に adm フォルダーがあります。この中に管理用テンプレートが保存されています。

スクリーンショット 2020-09-11 184535

この管理用テンプレートを適切な場所(ローカルであれば C:\Windows\PolicyDefinitions、ドメイン環境でポリシー テンプレートのセントラルストアを使っている場合はそのセントラル ストア)にコピーします。ただし上図で見えている OneDrive.adml はインターナショナル版(英語版)なので、ja フォルダーの中にある adml ファイルを (ローカルであれば C:\Windows\PolicyDefinitions\ja-jp フォルダーに)コピーします。

これで OneDrive 用の管理用テンプレートが準備できました。グループポリシー エディターを再度開くと、OneDrive の項目ができています。

スクリーンショット 2020-09-11 185216

OneDrive の管理用テンプレートで制御できる項目は

  • OneDrive が読み取り専用で同期されたフォルダーで Windows アクセス許可の継承を無効にできるようにする
  • 特定の組織にのみ OneDrive アカウントの同期を許可する
  • Office ファイルの同期の競合を処理する方法をユーザーが選択できるようにする
  • ユーザーのディスク領域が不足している場合にファイルのダウンロードをブロックする
  • 特定の組織の OneDrive アカウントの同期をブロックする
  • Office デスクトップ アプリで共同編集して共有
  • チーム サイト ライブラリを自動的に同期するように構成する
  • 従量制課金ネットワークのときにも同期を続ける
  • デバイスのバッテリー節約機能モードがオンのときに同期を続ける
  • 同期済みチーム サイトのファイルをオンライン専用ファイルに変換する
  • OneDrive セットアップの最後に表示されるチュートリアルを無効にする
  • OneDrive の帯域幅管理の自動アップロードを有効にする
  • 同期アプリのダウンロード速度を固定速度に制限する
  • 同期アプリのアップロード速度をスループットのパーセンテージまでに制限する
  • 同期アプリのアップロード速度を固定速度に制限する
  • ユーザーがサインインするまで同期アプリがネットワーク トラフィックを生成できないようにする
  • ユーザーが OneDrive フォルダーの場所を変更できないようにする
  • ユーザーがリモートからファイルを取得できないようにする
  • ユーザーが Windows の既知のフォルダーから OneDrive に移動できないようにする
  • ユーザーが Windows の既知のフォルダーから PC にリダイレクトできないようにする
  • ユーザーが他の組織から共有されたライブラリとフォルダーを同期できないようにする
  • ユーザーが個人用の OneDrive アカウントを同期できないようにする
  • Windows の既知のフォルダーを OneDrive に移動するメッセージをユーザーに表示する
  • ユーザーがローカル コンピューター上の複数の OneDrive ファイルを削除するときにプロンプトを表示する
  • OneDrive 同期アプリの更新プログラムを Deferred リングで受け取る
  • 大規模な削除操作ではユーザーの確認が必要
  • OneDrive フォルダーの既定の場所を設定する
  • ユーザーの OneDrive が自動的にダウンロードできる最大サイズを設定する
  • 同期アプリの更新リングを設定する
  • サイレント モードで Windows の既知のフォルダーを OneDrive に移動する
  • Windows 資格情報を使用して OneDrive 同期アプリにユーザーをサイレント モードでサインインする
  • OneDrive ファイル オンデマンドを使用する
  • ディスク領域が不足しているユーザーに警告する

これだけあります(「コンピューターの構成」と「ユーザーの構成」それぞれに OneDrive がありますが、設定項目は異なります)。

先ほどあげたファイル オンデマンドの構成や個人用 OneDrive 同期の禁止、帯域制御などの設定も可能になっているのが確認できるでしょう。

参考情報:グループ ポリシーを使用し、OneDrive 同期設定を制御する | Microsoft Docs

2020年8月12日

Windows 10 – ダークモードが一部に反映されない

Filed under: Windows Tips — タグ: , , , — hebikuzure @ 6:26 午後

Windows 10 バージョン 1903 以降には「ダークモード」が搭載されており、Windows の標準ユーザーインターフェイスをダークモード(黒を基調とした配色)で表示することができます。

またダークモードに対応したアプリでは、Windows システムの設定に従ってダークモードに切り替わるものもあります。個人的には「白時に黒」より「黒字に白」の方がディスプレイの輝度を下げても視認性が良いので、モバイル環境では(ディスプレイの輝度を下げてバッテリーを長持ちさせるため)ダークモードにしています。

ダークモードが反映されない

ところがダークモードに設定したはずなのに、画面の一部が白っぽい表示のままになってしまうことがあります。例えば以下のように、Windows エクスプローラーの一部が正しくダークモードになりません。


※ 「ダークモードでエクスプローラーの一部が白く表示される」から引用

この現象は、ダークモードに切り替える前に適用していたテーマが Windows の配色の一部を上書きしていて、ダークモードに変更してもその設定が残っているからのようです。

そのため、この現象は以下の手順で解決できます。

  1. いったんダークモードを解除する
  2. [個人設定] – [テーマ] を開く
  3. [テーマの変更] で [Windows] を選択して反映させる
  4. ダークモードを有効にする

2020年8月2日

システム イメージ バックアップの設定を初期化する


Windows 10 の「バックアップと復元」

Windows のバックアップ機能は Windows XP と Windows Server 2003 R2 までは NTBackup、それ以降の Windows ではシステム イメージ バックアップを含む「バックアップと復元」(Windows Server では「Windows Server Backup」)が標準機能として提供されていました。しかし Windows 10 ではバージョン 1709 以降、システム イメージ バックアップの継続的開発(メンテナンス)は終了し、フル ディスク バックアップはサードパーティーの製品を利用することが推奨されています(Windows 10 features we’re no longer developing に記載)。

とは言え、Windows 10 の「バックアップと復元」が直ちに利用できなくなるわけではありませんし、問題なく利用できる環境も多数あります。また Windows Server では引き続き Windows Server Backup がサポートされていますので、まだまだ現役の機能といえるでしょう。

「バックアップと復元」を利用していてちょっと困るのは、一度設定したバックアップの構成(バックアップ対象やバックアップ先、スケジュールなど)を初期化するユーザーインターフェースがなく、現在の設定の「変更」しかできない点です。通常はそう困ることもないのですが、何らかの理由でバックアップがエラーになったり失敗した際に設定情報の破損や不整合が発生すると、それを上手く修正できなくなる場合があります。

例;バックアップエラーコード0x800070015

「バックアップと復元」の設定を初期化する

何らかのトラブルで「バックアップと復元」の画面が開かなくなったり、設定を変更できなくなったり、正しいと思われる設定をしてもバックアップが行えない場合、レジストリに保存されているバックアップ設定を削除し、設定を初期化することができます。

実際に試してみましょう。まずバックアップの設定を何もしていない状態です。
clip_image001

この時、以下のレジストリ キーの中身は何もありません(値の無い既定があるだけ)
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsBackup\

clip_image001[5]

バックアップの設定を構成して、バックアップを行います。
clip_image001[7]

clip_image001[9] clip_image001[11]

そうすると、先ほどのレジストリ キー配下に設定情報が書き込まれます。
clip_image001[13]

ここで以下のキーを削除します。
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsBackup\
(キーごと削除したので次のキー WindowsUpdate が開いている状態)
clip_image001[15]

[バックアップと復元] を開くと、設定が初期化されています。
clip_image001[21]

2019年12月18日

新旧 Edge の Side by Side 実行

Filed under: Microsoft Edge, Windows Info — タグ: , — hebikuzure @ 7:22 午後

2020年1月15日に新しい Edge が公開されます。新しい Edge は企業向けのブラウザーという位置付けでさまざまな機能が盛り込まれています。とはいえ既に現在の Edge を既定のブラウザーとして活用している組織やユーザーも少なくないでしょうから、新しい edge にいきなり切り替えできないという場合もあるでしょう。そうした場合、新しい Edge に自動更新されたり Windows Update でインストールされたりすることは Blocker Toolkit を使ってブロックできます

しかし今の Edge を使いつつ、新しい Edge の動作確認や検証をしたいという場合もあります。そうした場合に一番簡単なのは、Blocker Toolkit で新しい Edge の自動適用はブロックしておき、Beta 版 Edge をインストールする方法です。Beta リリースは6週間後に安定板としてリリースされる候補版ですので、基本的に新しい Edge の動作確認・検証で利用するのに問題はないでしょう。

とはいえ現在の Edge を使いつつ、安定板の Edge (Chromium 版) も利用したいというニーズがあります。そうした場合の Side by Side 実行の方法が公開されています。

Side by Side 実行を構成する

新旧の Edge を同時利用するには、そのためのグループポリシーを構成します。

  1. まずエンタープライズ向け Edge のページからポリシー ファイルをダウンロードします。cab ファイルがダウンロードされるので、Windows エクスプローラーで開くと中に ZIP ファイルがあります。この ZIP ファイルを展開します。いろいろなファイルができますが、windows フォルダーの中に admx フォルダーがあるので、開きます。msedge.admx と msedgeupdate.admx がテンプレート ファイルなので、これを C:\Windows\PolicyDefinitions にコピーします(要管理者権限)。また言語ファイル(Windows の表示言語が日本語なら ja-jp フォルダー)も同じ場所にコピーします。
  2. そうるすとグループポリシー エディターの
    /コンピューターの構成 /管理用テンプレート
    /Microsoft edge/Microsoft Edge – 既定の設定/Microsoft Edge の更新、という3つの項目が追加されます。
  3. 以下のポリシーを構成します
    /コンピューターの構成 /管理用テンプレート/Microsoft Edge の更新/アプリケーション/Microsoft Edge でのブラウザーの同時実行エクスペリエンスを許可する
    このポリシーを有効にすると、新しい Edge がインストールされても従来の Edge が隠されることなく、今までと同様に利用できます。
    コメント 2019-12-18 191445

このポリシーは新しい Edgeがインストールされる前に構成する必要があります。ポリシーの構成前に新しい Edge のインストールが行われると、その時点で従来の Edge は置き換えられてアクセスできなくなります(スタート メニューのタイル、関連付けやピン留めしていたサイトなども全て新しい Edge で開くように変更されます)。後からポリシーの構成を行った場合、再度新しい Edge のインストーラーが実行されるまでポリシーの効果は現れません。またポリシーの効果が現れても、スタート画面や新しい Edge で開くよう変更された関連付け/ピン留めサイトは元に戻りません。

新しい Edge 用の Blocker Toolkit が公開

Filed under: Microsoft Edge, Windows Info — タグ: , — hebikuzure @ 6:41 午後

2020年1月15日に新しい Chromium ベースの Microsoft Edge がリリースされます。

Blocker Toolkit の使い方

現行の Edge を利用している企業やユーザーで、今しばらくは新しい Edge ではなく現行の Edge を利用していたいという希望もあるでしょう。そうした場合に利用できる Blocker Toolkit がリリースされました。

利用方法は簡単で、記載されているダウンロード リンクからファイルをダウンロードして実行します。展開先を聞かれるので適当なフォルダー(デスクトップなど)を指定して進むと、4つのファイルが作成されます。このうちの EdgeChromium_Blocker.cmd を管理者として実行したコマンド プロンプトで /B オプションを付けて実行します。

> EdgeChromium_Blocker.cmd /B

これでWindows Update や自動更新で新しい Edge がインストールされるのをブロックできます。

ただしユーザーが自分でインストーラーをダウンロードして実行すれば、新しい Edge のインストールは可能です。インストールには管理者権限が必要ですので、ユーザーにローカル マシンの管理者権限を与えている場合は注意してください。

同じスクリプトを /U オプションを付けて実行すれば、今度はブロックを解除できます。

レジストリ 情報

このスクリプトでは以下のレジストリを構成します。

キー:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EdgeUpdate
名前:DoNotUpdateToEdgeWithChromium
データ:0 [ブロックしない] / 1 [ブロックする]

グループポリシー

Tooklit を展開してできた EdgeChromium_Blocker.admx と EdgeChromium_Blocker.adml を使えば、グループポリシーで新しい Edge のブロックを構成できます。

EdgeChromium_Blocker.admx を C:\Windows\PolicyDefinitions に、EdgeChromium_Blocker.adml を C:\Windows\PolicyDefinitions\ja-JP に(Windows の表示言語が日本語の場合、それ以外の言語の場合はそれに合わせたフォルダーに)コピーします。

そうするとグループポリシー エディターの

/コンピューターの構成 /管理用テンプレート /Windows コンポーネント /Windows Update

Microsoft Edge (Chromium-based) Blockers が表示され、”Do not allow delivery of Microsoft Edge (Chromium-Based) through Automatic Updates” という項目が現れます。このポリシーを有効にすることで、ポリシーの対象となるクライアントでの自動更新/Windows Update での新しい Edge のインストールがブロックできます。

なおこのポリシーはタトゥーイングされるので、有効にした場合にそれを取り消してインストールを許可するには、かならず無効のポリシーを適用させてください。

2019年11月13日

Microsoft Ignite The Tour Tokyo に登壇します

Filed under: Information — タグ: , — hebikuzure @ 4:24 午後

先日、アメリカ・フロリダ州オーランドで開催された Microsoft のテクニカル イベント “Microsoft Ignite” の内容を凝縮して(ダイジェストして、ともいう)世界各地で開催される “Ignite the Tour” の一環、”Microsoft Ignite The Tour Tokyo” が来る 12月5日~6日、東京(会場 ザ・プリンス パークタワー東京)で開催されます。

このイベントで、以下のセッションに登壇させていただくことになりました。

またこれとは別に、ラーニングパス コンテンツでも以下のセッションを受け持ちます。

  • Microsoft 365 管理センターの新機能 (ADM41)
    Day 2 : 3:15pm – 4:00PM
  • Office 365 グループの導入 (ADM51)
    Day 2 : 4:30PM – 5:15PM

Microsoft Ignite The Tour Tokyo” の参加申し込みは残念ながら現在キャンセル待ちとなっていますが、参加予定の方で新しい Chromium ベースの Edge に興味のある方は、ぜひご聴講ください。

またセッション後には Speaker Q&A も行いますので、こちらにもぜひお立ち寄りください。

Microsoft Ignite The Tour Tokyo” 参加登録ページ
https://register.msignite-the-tour.microsoft.com/tokyo

2019年11月5日

2019年11月4日

Android 9 (Pie) 以降で DoT (DNS Over TLS) を利用する

Filed under: Security — タグ: , , , — hebikuzure @ 2:52 午後

先日「HTML5 5th Anniversary」というイベントで「Web に関わる人に知っておいてほしい) Web ブラウザー 最新事情」(リンク先 SlideShare) というセッションを行いました。

このセッションで紹介した Android 9 (Pie) 以降で DoT (DNS over TLS) を利用する方法について解説します。

DoT とは

DoT (DNS over TLS) とは何か、簡単に説明しておきましょう。従来の DNS の通信は通信自体の暗号化、サーバー検証、エンティティ検証といったセキュアな通信が一切行われておらず、DNS スプーフィングや中間者攻撃に対して脆弱です。また DNS クエリの内容がネットワーク経路上で簡単に傍受できるプライバシー上の問題もありました。こうした問題を改善し DNS をセキュアなものにする技術がいくつか提唱され実用化されています。DoT はその中で、DNS クライアント(スタブ リゾルバ)と DNS キャッシュ サーバー(フルサービス リゾルバ)の間の通信を TLS で保護するものです。

image

image

DNS の安全性

携帯電話キャリアの DNS であればクライアントと DNS サーバーの間の通信はキャリアの WLAN 網内で完結するので、基本的に DNS トラフィック自体を暗号化などで保護しなくとも安全と考えられます。また固定回線で ISP 経由でインターネット接続する場合も、日本国内であれば宅内装置と ISP の間は電話会社の回線を PPPoE で通過するので、同様に ISP の DNS サーバーまでのトラフィックを暗号化などで保護しなくとも安全と考えられます。

ただし DNS 問い合わせの内容はキャリア側で収集可能なので、プライバシーの問題は考慮しなければならないでしょう。一時期話題になった「海賊版コンテンツのブロッキング」もキャリアや ISP の DNS でブロックを行う手法が検討されていました。

DNS の安全性が問題になるのは、こうしたクライアントと DNS サーバーの間の経路が信頼できない場合です。具体的には公衆無線 LAN などのパブリックなネットワークを経由してインターネット接続する場合です。こうしたネットワークでは DNS の盗聴や中間者攻撃による DNS スプーフィングが可能な場合がありますし、そもそもそのネットワークが提供している DNS サーバー自体が安全に構成されていて信頼/信用できるのかどうか分からない場合もあるでしょう。DoT(やクライアント・DNS サーバー間を暗号化する別の方法である DoH – DNS over HTTPS)はこうしたネットワークを利用する場合に効果を発揮します。

DoT を利用する

Android 9 (Pie) 以降の Android OS ではシステム DNS に DoT が実装されています。そのため [設定] でネットワークに DoT を構成すれば、基本的にすべてのネットワーク通信の DNS 問い合わせをセキュアにできます。本年後半以降、各携帯電話キャリアから発売された Android スマートフォンはほぼ Android 9 を搭載しているので、最近 Android スマートフォンを買った / 機種変更した人であれば、すぐに DoT を試してみることができます。

Android 9 以降でDoT を利用するには [設定] – [ネットワークとインターネット] を開き、[詳細設定] をタップして開きます。すると [プライベート DNS] という項目が見つかるでしょう。これが DoT の設定です。[プライベート DNS] をタップすると、以下のような画面が表示されます。

image

この各項目はそれぞれ次のような動作を示しています。

  • OFF:DoT を利用しない
  • 自動:DHCP などで現在構成されている DNS サーバーに DoT での接続を試し、DoT が使えなければ従来の DNS にフォールバックする
  • プライベート DNS プロバイダのホスト名:指定した DNS サーバーに DoT で接続、失敗してもフォールバックしない

既定は「自動」ですが、現時点では携帯電話キャリアの DNS サーバーで DoT に対応しているところはありませんし、Wi-Fi アクセスポイントで DHCP で提供される DNS サーバーでも DoT に対応しているところはまずないので、「自動」のままでは DoT が利用されることは無いでしょう。

[プライベート DNS プロバイダのホスト名] を選択し、DNS のホスト名を入力します。注意が必要なのは、DoT は TLS で通信を保護するので、TLS の証明書検証のためにホスト名が必要になるという点です、通常の DNS は IP アドレスで指定しますが、ここではホスト名を指定します。

※ DoT 対応 DNS サーバーのホスト名は既存の DNS 構成を利用して(保護されていない)DNS で問い合わせ可能です。仮にここで不正なレコードが返って来たとしても、その不正な IP アドレスに対して(正しいホスト名での)TLS 接続はできませんので、安全は保たれるという仕組みです。またそのために DoT 接続に失敗した場合、フォールバックしない動作になっています。

利用可能な DoT 対応のパブリック DNS の一覧は

などで公開されていますし、提供元の Web サイトなので設定方法が公開されています。

ここでは Cloudflare と Google、そして IIJ のパブリック DNS のホスト名を紹介しておきます。

実際に Cloudflare のパブリック DNS (1dot1dot1dot1.cloudflare-dns.com) を設定して、Cloudflaer のテスト ページ(https://1.1.1.1/help)を表示すると、以下のように DoT が有効と表示されます。

image

Google のインストラクションに書かれているように、Android 9 ではこの [プライベート DNS] による DoT の設定は VPN では利用されません。この問題は Android 10 で修正されています。

2019年8月25日

2019年8月10日

ファイル サーバーの冗長化

Filed under: Windows Tips — タグ: , , , , — hebikuzure @ 4:52 午後

今回も仕事で調べた話の記録です。

ファイルサーバーの冗長化

LAN を利用する目的の一つにファイルやフォルダーの共有があります。多くの会社では専用のファイル サーバーを構築して社内で共有するファイルやフォルダーをホストしているでしょう。こうした共有されているデーターは会社の資産であり、重要なものとして保護する価値があります。この保護は一般的な情報セキュリティの CIA=「機密性」(Confidentiality)、「完全性」(Integrity)、「可用性」(Availability)を確保するということです。

Windows Server で構築されたファイル サーバーでは、機密性については ACL によるアクセスコントロールやファイルの暗号化(EFS)・ディスクの暗号化(BitLocker)、Windows 情報保護(WIP)などの多くの機能が提供されていますし、サードパーティー製のソリューションもよく利用されています。完全性と可用性の確保で一番ポピュラーなのはデータのバックアップでしょう。これも標準機能・サードパーティー製ソリューションともに幅広く利用されています。またストレージの冗長化も完全性や可用性の確保に RAID などが多く利用されている方法です。

とりわけ可用性の確保では、ストレージを冗長化することが(ディスクが HDD であれ SSD であれ寿命のそう長くないパーツである以上)非常に有効ですが、物理的にデータを保持するストレージではなく、そのストレージを接続し論理的に共有リソースとしてホストするファイル サーバーの冗長化はどのように行うことができるでしょうか。

ファイル サーバーを冗長化する場合、以下のような機能が必要になります。

  • クライアントからは冗長化されたどのサーバーに対しても同一の方法(パス)でアクセスできる
  • 冗長化されたすべてのサーバーは常に同一内容のデータを共有ファイルとしてホストする
  • 冗長化されたサーバーの一部が停止しても、データーの完全性と可用性は損なわれない

こうした条件を Windows Server のファイル サーバーで満たすことができる機能として、以下のような方法が考えられます。

  • Windows Server フェイルオーバー クラスタ(WSFC)を構成する
  • DFSR を利用する
  • 記憶域レプリカを利用する

それぞれの特徴を簡単にまとめて見ました。

Windows Server フェイルオーバー クラスタ

Windows Server フェイルオーバー クラスタは Windows Server の標準機能です。複数のサーバーをクラスタ化し、共有のストレージ(SAS / Fiber Channel / iSCSI)を利用してファイル共有を提供します。動作的には参加しているすべてのサーバーは常時 Active になります。
共有リソースを保持するストレージは共有されますので、ストレージ自体の冗長性確保は別に考える必要があります(基本的に冗長構成が必須)。

2 ノード クラスター
図:https://docs.microsoft.com/ja-jp/windows-server/failover-clustering/deploy-two-node-clustered-file-server より引用

Pros

  • 多数のサーバーをクラスタリングすることで堅牢な冗長性を確保できます
  • Active Directory に依存しない機能なのでワークグループ クラスターを作成できます(ただしファイルサーバーとしての利用は非推奨)

Cons

  • 共有ストレージの要件(SAS / Fiber Channel / iSCSI)のハードルがやや高くなります
  • クラスタに参加するサーバーは同一または類似している必要があります
  • 構成の難易度が相対的に高くなります

参考情報

DFSR

Windows Server の標準機能である DFS 名前空間で作成されたターゲット フォルダー間を自動的にレプリケートする機能です。DFS 名前空間とは複数のサーバー上に配置されている共有フォルダーを、論理的に構造化された 1 つ以上の名前空間にグループ化できる機能で、ユーザーに対して共有フォルダーを仮想化し、複数のサーバー上にあるファイルに 1 つのパスアクセスできるものです。
動作的には DFS を構成するすべてのサーバーは Active に動作します。共有リソースを保持するストレージはサーバーごとに個別に接続されるので、サーバー単位で冗長構成を取らなくとも全体としてはデーターの冗長化が行えています。サーバー間の同期はフォルダー単位でファイル ベースで行われます。

DFS 名前空間のテクノロジ要素
図:https://docs.microsoft.com/ja-jp/windows-server/storage/dfs-namespaces/dfs-overview より引用

Pros

  • 構成が容易です
  • 特別なハードウエアやネットワークを必要としません
  • サーバーやディスクのスペックはまちまちでも問題ありません
  • クライアントからは単一の記憶域として扱えます
  • 障害時の対処が単純(フェールオーバーの操作が必要なく、障害サーバーを復旧させるだけ)です
  • Windows Server Standard 以上のエディションで利用可能です

Cons

  • Active Directory が必須です
  • DFS 名前空間の動作原理上、クライアントがどの物理サーバーにアクセスするか明示的に制御できません(Active Directory サイトの構成によりある程度は制御可能
  • フォルダー間のレプリケートはクライアントからのアクセス(書き込み)とは非同期に行われるため、複製フォルダー間の常時整合性は保証されません(変更が検知されたファイルはいったんステージング領域にコピーされ、その後ネットワーク経由で他のサーバーに同期されます)。そのため同一のファイルが複数のサーバーで頻繁に更新される場合、競合によるデーターの損失や破損が生じる場合があります。

DFSRの参考情報

記憶域レプリカ

記憶域レプリカは障害復旧用にサーバーまたはクラスター間でボリュームのレプリケーションを行う Windows Server の機能です。レプリケーションは同期レプリケーションと非同期レプリケーションが選択できます。機時間の短いネットワーク内でデータをミラーリングし整合性の維持を図るには同期レプリケーションを、遠隔地間など待機時間の長いネットワークを通じてデータをミラーリングする場合は(整合性は保証されませんが)非同期レプリケーションを選択できます。サーバーは Active / Standby の構成(レプリケートされる側を待機系にする)も可能です。サーバー間の同期はボリューム単位でブロック ベースで行われます。
※記憶域レプリカはサーバー間でのレプリケーション以外に、クラスターのノード(群)間、クラスター間でのレプリケーションが可能です。(下図はサーバー間構成例)

施設 5 のサーバーを施設 9 のサーバーでレプリケートしていることを示す図
図:https://docs.microsoft.com/ja-jp/windows-server/storage/storage-replica/storage-replica-overview より引用

Pros

  • 構成が比較的容易です
  • 特別なハードウエアやネットワークを必要としません
  • サーバーやディスクのスペックはまちまちでも問題ありません
  • レプリケートを同期実行できるので、複製間の整合性が高く障害時のファイル システム レベルでのデータ損失もゼロになります

Cons

  • Active Directory が必須です
  • 障害時のフェールオーバーを手動で行うか、自動化する仕組みを作る必要があります(レプリケートするサーバー上のフォルダーをターゲットにする DFS 名前空間を構成して、DFSR ではなく記憶域レプリカで同期する構成にすることは可能です)
  • Windows Server 2016 以前では Standard エディションでは利用できません(Data Center エディションが必要。Windows Server 2019 では Standard エディションでも一部制限付きですが利用可能)

記憶域レプリカの参考情報

まとめ

ミッションクリティカルで堅牢生・高可用性を必要とする場合は WSFC を利用するのが望ましいでしょう。ただし構築に必要なハードウエア費用や技術的コストは相対的に高くなります。

DFSR の良い点は、遠隔地のサーバー間など帯域や遅延に制限のある環境でもクライアントからのアクセスのパフォーマンスに影響を与えることなく同期が行えることです。また同期するグループに何台でもサーバーを追加できる点や構成が用意である点もメリットでしょう。参照が中心のデーターをホストするファイル サーバーを(場所的にも)広範囲で冗長化するのに向いていると思います。

記憶域レプリカは1対1のレプリケーションとなる点が制約です。DFSR のように3台以上のサーバーを同期させることはできません。その代わり同期レプリケーションが可能なので、DFSR のようなデーターの破損や競合の発生は生じません。複数のクライアントから頻繁に更新されるデーターを多数持つファイルサーバーの冗長化に向いていると思います。

ファイルサーバーの冗長化を検討される機会があれば、以上の内容を参考にしてください。

Older Posts »

WordPress.com Blog.

%d人のブロガーが「いいね」をつけました。