Jeda lama saat mengakses namespace DFS

Kami baru saja memigrasikan jaringan Windows kami untuk menggunakan DFS untuk file yang dibagikan. DFS berfungsi dengan baik, kecuali untuk satu masalah yang menjengkelkan: pengguna mengalami penundaan yang signifikan ketika mereka mencoba mengakses namespace DFS yang belum mereka akses selama beberapa waktu. Saya telah mencoba memecahkan masalah tetapi belum berhasil sejauh ini, dan saya berharap seseorang di sini mungkin memiliki beberapa petunjuk untuk membantu menyelesaikan masalah.

Pertama, beberapa latar belakang di jaringan kami:

Jaringan menggunakan domain Active Directory tingkat fungsional Windows 2008 dengan dua DC Windows 2008 dan dua server DNS (satu pada masing-masing DC). Jaringan hanya DNS - tidak ada WINS. Semua komputer berada di situs yang sama dan terhubung oleh Gigabit Ethernet. Kami memiliki sekitar 20 ruang nama DFS berbasis Domain dalam mode Windows 2008, dan setiap ruang nama DFS memiliki dua server ruang nama DFS Windows 2008 (dua server yang sama untuk semua ruang nama). Semua server namespace berada dalam mode FQDN dan semua target folder ditentukan menggunakan FQDN mereka. Semua komputer terbaru dengan Paket Layanan dan tambalan.

Target folder aktual (yaitu SMB membagikan folder DFS kami arahkan ke) tersebar di beberapa server file dan aplikasi, semua menjalankan Windows 2008 bar dua server aplikasi yang menjalankan Windows 2003 R2, tanpa setup replikasi sama sekali (misalnya semua folder DFS saat ini hanya memiliki satu target folder).

Beberapa detail tentang masalah ini:

Penundaan akses namespace umumnya 1 - 10 detik panjang dan tampaknya terjadi ketika komputer tertentu belum mengakses namespace yang diminta sekitar lima menit atau lebih.

Misalnya, jika pengguna belum mengakses \\ domain.name \ namespace1 \ selama lebih dari lima menit dan berupaya mengakses \\ domain.name \ namespace1 \ melalui Windows Explorer, jendela Explorer akan membeku selama 1 - 10 detik sebelum akhirnya melanjutkan dan menampilkan folder yang ada di \\ domain.name \ namespace1. Jika mereka kemudian menutup jendela Explorer dan mencoba mengakses \\ domain.name \ namespace1 \ lagi dalam waktu lima menit, konten akan ditampilkan hampir secara instan - jika mereka menunggu lebih dari lima menit maka akan melalui jeda 1 - 10 detik lagi.

Setelah "di dalam" namespace semuanya bagus dan cepat, itu hanya koneksi awal ke namespace yang lambat.

Penundaan penjelajahan tampaknya memengaruhi semua varian Windows yang kami gunakan (Windows 2008 x64 SP2, Windows 2003 R2 x86 SP2, Windows XP Pro x86 SP3) - mungkin sedikit lebih buruk di Windows XP / 2003 daripada di Windows 2008, tapi saya Saya tidak yakin apakah perbedaannya bukan hanya psikologis.

Mengakses target folder yang mendasarinya secara langsung menunjukkan tidak ada penundaan sama sekali - yaitu jika saham SMB yang ditunjuk oleh DFS diakses secara langsung (melewati DFS) maka tidak ada jeda.

Selama pemecahan masalah saya perhatikan bahwa "Durasi cache" untuk semua root DFS kami diatur ke 300 detik - 5 menit. Mengingat bahwa ini adalah jumlah waktu yang sama yang diperlukan untuk memicu jeda, saya berasumsi bahwa caching ini entah bagaimana terkait, meskipun saya tidak yakin persis apa yang di-cache pada klien dan karenanya apa yang perlu dilihat lagi setelah 5 menit berlalu.

Dalam mencoba menyelesaikan masalah, saya sudah mencoba / memeriksa yang berikut (tidak berhasil):

• Jalankan dcdiag di kedua Pengontrol Domain - tidak ada masalah ditemukan
• Selesai memeriksa server DNS dasar tanpa menemukan masalah - Saya tidak tahu cara memeriksa server DNS secara detail, tapi saya akan menambahkan bahwa jaringan tidak menunjukkan perilaku aneh lainnya yang mungkin mengarah ke masalah DNS
• Anti Virus dinonaktifkan pada klien dan server
• Menghapus salah satu server namespace dari beberapa ruang nama - tidak ada perbedaan

Jadi di situlah saya merencanakan - dan saya kehabisan ide. Adakah yang bisa menyarankan apa yang menyebabkan penundaan dan / atau apa yang harus saya coba selanjutnya?

Yah, kami akhirnya tampaknya telah menyelesaikan masalah ini di lingkungan kami. Untuk keuntungan orang lain, inilah yang kami temukan dan bagaimana kami memperbaiki masalahnya:

Untuk mencoba dan mendapatkan wawasan lebih lanjut tentang apa yang terjadi sebelum / selama / setelah penundaan, kami menggunakan Wireshark pada mesin klien untuk menangkap / menganalisis lalu lintas jaringan sementara klien itu berusaha mengakses bagian DFS.

Capture ini menunjukkan sesuatu yang aneh: setiap kali penundaan terjadi, di antara permintaan DFS dikirim dari klien ke DC, dan rujukan ke server akar DFS kembali dari DC ke klien, DC mengirimkan beberapa nama siaran pencarian ke jaringan.

Pertama, DC akan menyiarkan pencarian NetBIOS untuk DOMAIN (di mana DOMAIN adalah nama domain pra-Windows 2000 Active Directory kami). Beberapa detik kemudian, itu akan menyiarkan pencarian LLMNR untuk DOMAIN. Ini akan diikuti oleh pencarian NetBios siaran lagi untuk DOMAIN. Setelah ketiga pencarian ini disiarkan (dan saya berasumsi kehabisan waktu) DC akhirnya akan menanggapi klien dengan rujukan (yang benar) ke server root DFS.

Pencarian nama siaran ini untuk DOMAIN hanya dikirim ketika penundaan lama membuka bagian DFS terjadi, dan kami dapat dengan jelas melihat dari penangkapan Wireshark bahwa DC tidak mengembalikan rujukan ke server root DFS sampai ketiga pencarian dikirim ( dan ~ 7 detik berlalu). Jadi, pencarian nama siaran ini jelas merupakan penyebab keterlambatan kami.

Sekarang kami tahu apa masalahnya, kami mulai mencoba mencari tahu mengapa pencarian nama siaran ini terjadi. Setelah sedikit lebih banyak Googling dan beberapa trial-and-error, kami menemukan jawaban kami: kami belum menetapkan kunci registri DfsDnsConfig pada pengontrol domain kami menjadi 1, seperti yang diperlukan saat menggunakan DFS di lingkungan khusus DNS.

Ketika kami awalnya menyiapkan DFS di lingkungan kami , kami membaca berbagai artikel tentang cara mengkonfigurasi DFS untuk lingkungan khusus-DNS (mis. Microsoft KB244380 dan lainnya) dan mengetahui kunci registri ini, tetapi telah salah mengartikan instruksi kapan / bagaimana cara mengkonfigurasi Gunakan.

KB244380 mengatakan:

Kunci registri DFSDnsConfig harus ditambahkan ke setiap server yang akan berpartisipasi dalam ruang nama DFS untuk semua komputer untuk memahami nama yang sepenuhnya memenuhi syarat.

Kami pikir ini berarti bahwa kunci registri harus ditetapkan pada server namespace DFS saja, tidak menyadari bahwa itu juga diperlukan pada pengontrol domain. Setelah kami menetapkan DfsDnsConfig ke 1 pada pengontrol domain kami (dan me-restart layanan "DFS Namespace"), masalahnya hilang.

Jelas kami senang dengan hasil ini, tetapi saya akan menambahkan bahwa saya masih belum 100% yakin bahwa ini adalah satu-satunya masalah kami - saya ingin tahu apakah menambahkan DfsDnsConfig = 1 ke DC kami hanya menyelesaikan masalah, daripada menyelesaikannya . Saya tidak tahu mengapa DC akan mencoba mencari DOMAIN (nama domain itu sendiri, bukan server di domain) selama proses rujukan DFS, bahkan di lingkungan non-DNS-saja, dan saya juga tahu saya belum menetapkan DfsDnsConfig = 1 pada pengontrol domain di lingkungan DNS-only (diakui jauh lebih kecil / sederhana) lainnya dan belum memiliki masalah yang sama. Namun, kami telah memecahkan masalah kami sehingga kami senang.

Saya harap ini bermanfaat bagi orang lain yang mengalami masalah serupa - dan terima kasih sekali lagi kepada mereka yang menawarkan saran.

Ini bisa disebabkan oleh pemesanan netmask server DNS. Kami menemukan ini baru-baru ini di Server 2003. Ini tergantung pada subnetting Anda saat ini.

Contoh.

Situs 1: IP subnet 10.0.0.0/24 Situs 2: IP subnet 10.0.1.0/24

Klien di situs 2 membuat kueri DNS untuk namespace berbasis domain Anda dan akan diberikan server DFS di situs 1 secara default karena server DNS tidak mengetahui batas-batas IP situs. Anda perlu memberi tahu server DNS Anda tentang apa subnet mask yang digunakan untuk mengidentifikasi alamat IP mana yang harus ditanggapi.

Lihat http://support.microsoft.com/kb/842197

Blog Tim Direktori Aktif memiliki artikel Tiga bagian SEMUA tentang Penundaan DFS.

http://blogs.technet.com/b/askds/archive/2009/09/29/o-dfs-shares-where-art-thou-part-1-3.aspx

Ini mencakup dasar-dasar pada Proses Referensi, dan kemudian menunjukkan bagaimana menggunakan berbagai alat termasuk dfsUtil dan dfsDiag untuk menemukan penyebab sebenarnya dari penundaan.

Itu membantu saya menemukan masalah saya. Yang ternyata bukan izin Baca di direktori berbagi untuk Pengguna Domain.

HTH, Daniel

Berbau seperti masalah DNS tetapi semuanya berjalan. Saya lebih suka FRS lama karena alat diagnostik seperti Ultrasound sangat berguna: 7

Apakah Anda mendapatkan sesuatu di Log Acara Replikasi DFS pada target? (laporan DFS Health akan menarik peringatannya dari log peristiwa)

Menjalankan tanpa MENANG adalah tujuan yang bagus dan mengagumkan, meskipun saya cukup menentang ini jika ada sistem Windows pra-Vista / 2008 sekitar karena hal-hal tidak selalu berfungsi seperti yang diharapkan atau secepat tanpa MENANG dalam pengalaman saya - meskipun itu benar-benar seharusnya tidak masalah.

Klien cache referensi DFS, yaitu ketika Anda memasukkan \ domain.name \ namespace itu akan cache yang merujuk ke server.name domain aktual. Setelah rujukan kedaluwarsa dari cache, klien pada dasarnya harus "menemukan" topologi DFS Anda lagi, karena itu penundaan.

Lihat di sini: http://technet.microsoft.com/en-us/library/cc758234(WS.10).aspx dan di sini http://blogs.technet.com/filecab/archive/2006/01/20 /417832.aspx untuk info lebih lanjut tentang cara kerjanya.

Solusi yang memungkinkan? Cara yang sulit untuk menyelesaikannya mungkin dengan menulis program kecil yang "tetap hidup" setiap beberapa menit; misalnya program C yang membuka file pertama yang ditemukannya dan langsung menutupnya. Saya belum mencoba atau menguji ini, dan Anda pasti perlu memberikan pertimbangan hati-hati jika Anda akan melakukannya.

Kami memiliki masalah yang terdengar serupa, di mana pengguna akan mengalami keterlambatan (hingga satu menit) antara mengklik drive yang dipetakan ke share DFS, dan dapat melihat dan menelusuri folder di dalam share.

Pengguna juga memiliki drive rumah yang dipetakan ke berbagi DFS yang berbeda pada volume yang sama, dan tidak memiliki penundaan saat mengakses folder di sana.

Perbedaan antara keduanya adalah Access-Based Enumeration (ABE) - pembagian masalah mengaktifkannya (ini adalah drive yang umum untuk pengguna, dengan ribuan folder - ABE berarti pengguna hanya melihat folder yang memiliki izin).

Menonaktifkan ABE sepenuhnya menghilangkan masalah. Jelas ini bukan solusi karena pengguna kemudian melihat semua folder, membingungkan mereka. Saya telah mereplikasi share DFS ke server dengan beberapa disk cadangan sebagai tindakan sementara, dan bahkan dengan ABE diaktifkan pada target baru ini, penundaan telah hilang.

Server masalahnya adalah 2k3R2, dan memiliki waktu aktif lebih dari 150 hari (!), Jadi itu akan di-boot ulang dan CHKDSK dijalankan pada volume yang menyinggung. Saya akan mengirim kembali ke sini jika ini ada bedanya dengan masalah. Target baru ada di server 2k8.

dfsutil / spcflush dan dfsutil / pktflush dapat menjadi solusi juga di jaringan multi-situs, pastikan bahwa tautan DFS dari situs rumah datang dari server lokal dan bukan dari cache.

Saya tahu poster asli tidak menggunakan WINS, tetapi saya memposting untuk kepentingan orang lain karena kami paling banyak menggunakan posting ini untuk membantu memecahkan masalah yang sangat mirip. Bagi kami itu akhirnya seseorang memutuskan untuk memberi nama workstation mereka dengan nama yang sama dengan domain. Jadi, setiap kali DC melakukan pencarian pada nama domain untuk rujukan DFS, ia ingin menyelesaikan ke workstation itu dan akan menyebabkan penundaan beberapa detik selama 10 detik. Entri statis 20 ditempatkan ke WINS menunjuk ke DC dan ini telah memecahkan masalah. Jika Anda tidak memiliki WINS, Anda dapat bereksperimen dengan menempatkan nama domain sebagai nama mesin di file LMHOSTS yang menunjuk ke DC untuk mendapatkan pencarian 20, dan menetapkan prioritas agar LMHOSTS menjadi tempat pertama yang harus dicari untuk menyelesaikan nama netbios.

http://technet.microsoft.com/en-us/library/cc780950(v=ws.10).aspx Halaman ini sebenarnya menyebutkan Pengontrol Domain dan DFSN, jika itu membantu.

DFS Domain Controller dan Entri Registry Server Root

Entri registri berikut ini berada di bawah

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs 

pada server root dan pengontrol domain. Semua entri adalah REG_DWORD.

Jadi saya menggunakan artikel ini dalam pencarian saya. Saya mengatur semuanya dan masih memiliki masalah. Setelah menghabiskan beberapa hari mencari masalah dan mengecualikan semuanya 'Microsoft' saya kira itu terkait Jaringan. Ternyata akselerator WAN kami adalah masalah. Saya meminta orang Networking kami mematikan akselerasi untuk Pengontrol Domain kami dan semuanya menjadi lebih baik.

Punya banyak pengontrol, begitu pula skrip ( dnsdfs.cmd servername):

dfsutil server registry dfsdnsconfig set %1
sc \\%1 stop dfs
sc \\%1 start dfs

Anda menyebutkan bahwa Anda memiliki 20 server DFS namun gagal menyebutkan jika semua server berada di fasilitas yang sama.

Jika server ini tidak dalam fasilitas yang sama dan masing-masing situs lain memiliki domain sendiri, Anda mungkin ingin memastikan kegagalan klien diaktifkan.

Bagi mereka yang berakhir di sini melalui pencarian google dan yang memiliki masalah yang sama ...

Pertama periksa apakah semua tautan di Namespace Anda tersedia dan bagus. Itulah yang terjadi dalam kasus saya, masih ada tautan di namespace ke server yang turun, sehingga jeda yang lama ketika membuka DNS adalah karena sedang mencari server itu dan gagal. Setelah saya menonaktifkan tautan itu di DFS jeda panjang hilang.

Verifikasi bahwa grup Pengguna yang Diotentikasi memiliki akses ke daftar isi direktori root yang Anda petakan. Sebagai contoh jika drive x: dipetakan ke \ domain.local \ departents \ Marketing maka pengguna akan memerlukan izin daftar untuk \ domain.local \ departemen. Pada 2008/2012 Anda dapat menentukan di bawah izin lanjutan yang berlaku untuk "Folder ini saja" sehingga mereka tidak diizinkan untuk membuat daftar konten dari setiap folder yang mungkin mewarisi izin.