Windows DFSR-複製されたディレクトリのアクセス許可を変更し、1週間以上にわたって350,000のバックログを保持
質問：この350,000ファイルのバックログをより速く完了する方法はありますか？ほとんどすべてのファイルで唯一の変更は、影響を受ける各ファイルのACLの変更でした。一部のファイルは内容が変更されていますが、この状況では一般的ではありません。 これは修正される可能性があります。このテキストを編集して、一定の期間と検証後に成功/失敗を確認します。この質問文の終わりに向かって、それを修正した可能性がある最近行われた変更について詳しく説明しました。 約450,000ファイルのDFSRレプリケーショングループがあり、1.5 TBのスペースを使用しています。この状況では、約500マイル離れた2つのWindows Server 2008 R2サーバーがあります。他のサーバーがありますが、このレプリケーショングループには関与していません。サーバーアルファはメインサーバーであり、ほとんどのスタッフが使用しています。サーバーベータは、リモートオフィスのサーバーであり、ビジー状態ではありません。 ここで、このレプリケーション・グループのバックログのグラフは（PNGは、Googleドライブ上にホストされている）スローシンクロの進行状況を示します。 そのレプリケーショングループのルートディレクトリにある権限エントリを削除する必要がありました。もちろん、ほとんどのサブフォルダーに継承されています。この変更はサーバーALPHAで行いました。その直後、DFSRには350,000のファイルバックログがありました。1週間以上経ち、現在は267,000に達しています。（最初に）変更されたのは、単一の権限の変更のみでした。 これは何が起こったかです（これは解決策ではなく、この問題の原因となったものの別の説明です）：http : //blogs.technet.com/b/askds/archive/2012/04/14/saturday-mail-sack -because-it-turns-out-friday-night-was-alright-for-fighting.aspx＃dfsr サーバーBETAで発生した変更は、その方向にバックログがないため、サーバーALPHAに非常に迅速に複製されます。ベータ版で変更されたファイルは、問題なくアルファ版に変換されます。 それは、一端で50Mbps接続のファイバーを介して他端で100Mbpsのファイバーに24/7をフルスピードで複製します。ステージング領域は各サーバーで100GBです。イベントログには何も興味深いものはありません。この特定のレプリケーションにも、このALPHA / BETAサーバーペアにもない関連のないレプリケーショングループに表示される、関連のない最高水準点イベントがあります。特に、最高水準点や接続エラーのイベントログエントリはありません。 レプリケーショングループに関するALPHAのビュー： 帯域幅の節約：99.83％の削減（18.1 GBではなく30.85 MBの複製） 30.85MB / 18.1GBは、ALPHAとBETAでDFSRサービスを最後に再起動してから発生したと思います。もしそうなら、これは非常に長い時間がかかっていても（実際にかかるはずの時間よりも長い）、実際にはファイルの内容がネットワーク経由で転送されていないことを示しています。 複製フォルダ：1.46TB（実サイズ）、439,387（ファイル）、52,886（フォルダ） 競合および削除されたフォルダー：100.00GB（構成済みサイズ）、34.01GB（実際のサイズ）、19,620（ファイル）、2,393（フォルダー） ステージングフォルダー：200.00GB（構成済みサイズ）、92.54GB（実際のサイズ） ログ（5月14日午後7時）に1つの最高水準点エラーが発生したため、ステージングクォータを100GBから200GBに増やしました。マイクロソフトが承認したルートは20％増加することを知っていますが、私はこれで遊んでいません。ステージングディスクアレイには、十分な空き容量があります。 すべてのサーバーでウイルス対策を無効にしても効果はありませんでしたが、少しは役立つと思いました。今のところ、ウイルス対策を再度有効にしていますが、方程式から変数を削除するために、レプリケーショングループのパスをスキャンから除外するように設定しています。 これを速くする方法はありますか？私はサーバーBETAでもこの変更を加えるだけですが、ALPHAで変更されたが、BETAにレプリケートされていないファイルがあり、BETAで継承されたアクセス許可の変更を行うと、OLDファイルがBETAからALPHAにプッシュされます（DFSRがどのファイルが衝突で勝ったかを比較するとき、ファイルのタイムスタンプを無視します）。そして、それが起こるのはむしろ悪いでしょう。 バックログはゆっくりと減少しています。とてもゆっくりと。しかし、それは進んでいます。しかし、このレートでは、完了するまでに数週間かかります。データセットのコピーを3TBドライブに押し込んでリモートオフィスに発送することを考えています。もっと良い方法はありますか？ 5月16日午前4時US PT：問題を修正した可能性のあるもの（とにかく正直に修正されていると仮定）： DCに複数の変更を加えましたが、それはずっと前に行われるべきでした。問題は、このネットワークが他の誰かから継承された可能性があるということです。他の誰かから継承された可能性があります。問題が修正された変更を約束することはできません。ここではそれらは特定の順序ではありません： すべてのDCが "ドメインコントローラー" OUに含まれていませんでした。DCが他の場所にあるWindowsドメインを見たことがありません。それらを元の場所に戻しました。以前は、各オフィスがある都市の名前で分離されたOUにありました。（それらを移動したので、対処する必要がある配管工事があるようですが、現時点ではすべて問題ないようです...） AVGアンチウイルスは、すべてのDCおよびDFSR参加サーバーで実行されています。レプリケートフォルダーとステージングフォルダーをアクティブ/オンアクセススキャンから除外しました。これで問題が修正されたとは思わないので、後でこの問題をテストして、その変更を元に戻すとDFSRの複製速度が低下するかどうかを確認します。それは別の日の挑戦です。 dcdiag.exeは、RODCに関するDNSの問題を訴えました。ドメインにRODCがまったくない場合でも、この問題を修正しました。私はこれが何かを修正したとは思いません。 _ldap._tcp.domain.GUID._msdcs.DOMAIN.NET SRVレコードの1つがDCSの1つ（DFSRサーバーの1つではない）で欠落していたので、それを修正しました。これも役に立たなかったと思います。 サーバーを再起動したときの1つとして、DFSRデータベースの不適切なシャットダウン（イベント2212）が発生し、データベースの再構築に数時間かかりました。終了すると、イベント2214が報告され、終了したことがわかります。その後、レプリケーションはまだ非常に低速で実行されていましたが、スタックされていたものは何でも取り外せるようになった可能性があります。 DCの1つは、インターフェイス構成でセカンダリDNSサーバーとして127.0.0.1を持っていませんでした。追加しました。これはDFSRサーバーの1つではなかったので、おそらくそれとは何の関係もありませんでした。 私はTechNetブログをフォローしました： DFSRサーバーでのDFSR推奨レジストリ設定でのレプリケーションパフォーマンスのチューニング。AsyncIoMaxBufferSizeBytesが4194304に設定されていることを除いて、「テスト済みの高パフォーマンス値」の値をすべて使用しました。これは、高値よりも1ノッチ低い値です。これは問題を解決できたかもしれません...または多分そうではありません。あまりにも多くの変数を変更するときにそれを区別することは困難です。 dcdiag.exeはベータ版のRPCサービスとの通信に関する問題について不満を述べましたが、それはすでに上記の変更を行った後です。これが最も起こりそうな問題であるように見えましたが、私がそれを修正するためにしたことは何もありませんでした。VPNは適切に実行されており、ファイアウォールはそれをブロックしていませんでした。上記の項目のいずれかがRPCの問題の原因であり、それを修正した可能性があります。または、単純な偶然の一致であった可能性があります。私はない今、そのエラーを取得し、複製は現在順調に稼働しています。 この話の教訓は、一度に1つずつ変更するか、何が原因でそれが修正されたのか本当に分からないことです。しかし、私は必死で、それを修正するための時間を使い果たしていたので、問題に対して大量の弾丸を発射しました。修正を特定した場合は、ここで報告します。ただし、絞り込みに頼らないでください。 編集5/21/2012： 昨日、リモートサーバーにスペアサーバー（GAMMA）を使って約7時間運転することで、これを解決しました。GAMMAがプライマリローカルサーバーとして機能し、通常のサーバー（ベータ）がレプリケーションに追いつきます。私がそれを配置してから、サーバーはレプリケーション速度の約2倍になります。これはVPN関連の問題である可能性があることを教えてくれますが、ALPHAからGAMMAにすべての新しい更新がレプリケートされているように思われるため、これは非常に迅速で順調です。 編集5/22/2012： …