Berbagi Windows: Nama jaringan yang ditentukan tidak lagi tersedia

8

Kami memiliki kotak EMC NX4 SAN yang melayani pembagian CIFS ke sejumlah server aplikasi Windows Server 2008 R2. Server aplikasi menggunakan share CIFS untuk menyajikan banyak file gambar (~ 2500 ops / dtk pada share), namun baik SAN maupun server aplikasi tidak menunjukkan tanda-tanda stres yang jelas.

Kadang-kadang server aplikasi akan, tampaknya tiba-tiba, memutuskan koneksi ke SAN. Kode .NET yang mencoba menyajikan file dari SAN gagal dengan:

System.IO.IOException: The specified network name is no longer available

Jika saya RDP ke server aplikasi dan mencoba mengakses "\ san-name" melalui explorer, saya mendapatkan kesalahan yang sama. Semua server aplikasi lain dapat mengaksesnya dengan baik. Saya juga dapat mengakses "\ ip-of-san" dengan sempurna, ping juga berfungsi.

Reboot server aplikasi memperbaiki masalah ini, tetapi itu adalah ukuran yang agak drastis untuk masalah tersebut, mengingat sepertinya SAN berfungsi dengan baik dan komputer dapat mengaksesnya - sepertinya akses "\ san-name" memiliki muntah.

Ini telah terjadi pada dua server aplikasi yang berbeda selama minggu lalu, jadi saya tidak curiga satu server aplikasi menjadi penyebabnya. Mengabaikan penyebabnya untuk saat ini - bagaimana cara mengembalikan koneksi "\ san-name" tanpa me-reboot mesin? Dan bisakah saya menanyakan apa yang salah?

Log peristiwa tidak menunjukkan apa-apa (selain kesalahan ASP.NET terkait yang disebabkan oleh masalah ini), baik pada server aplikasi maupun pada SAN.

Pembaruan:
Berdasarkan saran saya akan mencoba restart layanan Workstation di waktu berikutnya dan melihat apakah itu membantu masalah. Jelas bukan perbaikan, tetapi lebih cepat dilakukan daripada me-reboot seluruh mesin seperti yang saya lakukan saat ini. Adakah cara untuk menanyakan status koneksi yang dipertahankan oleh layanan Workstation?

Pembaruan 2:
Dikonfirmasi bahwa memulai kembali layanan Workstation "memperbaiki" masalah. Langkah selanjutnya adalah mencoba perubahan reg untuk meningkatkan nilai MaxCmds. Tidak akan dapat mengkonfirmasi apakah itu masalah, hanya bisa berasumsi jika berjalan untuk jangka waktu yang lama tanpa masalah.

— Mark S. Rasmussen
sumber

Apakah ada indikasi log peristiwa di server aplikasi, khususnya di log sistem, yang mengarah ke kegagalan sementara atau beberapa mekanisme lain yang dipicu (misalnya perlindungan DOS di LanManagerService seperti yang dijelaskan di sini blog.mreza.info/archive/ 2007/09/26 / ... ). Juga pengaturan AV apa yang ada dan bagaimana Celerra terintegrasi dengan itu.

— Helvick

@Helvick Tidak ada entri yang relevan di log peristiwa, baik aplikasi maupun sistem. Kami tidak menjalankan AV baik di server maupun di Celerra. Saya mencari log peristiwa untuk acara perlindungan DOS LanManagerService juga, tetapi kembali kosong.

— Mark S. Rasmussen

7

Ini sepertinya MaxCmds telah habis. Berikut adalah dua artikel bagus tentang itu: di sini dan di sini .

Ini dia sekarang untuk mengubahnya. Buat file bernama update.reg dan letakkan yang berikut di dalamnya:

Windows Registry Editor Version 5.00 

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanworkstation\parameters] 
"MaxCmds"=dword:00000800

Simpan dan kemudian klik dua kali dan terima konfirmasi. Diperlukan reboot.

— Scott Forsyth - MVP
sumber

Karena bounty akan segera habis, saya akan menghadiahkannya untuk jawaban Anda sejauh ini merupakan taruhan terbaik, meskipun saya harus mengujinya sebelum menerimanya. Saya sebelumnya telah mengubah FCNMode untuk hanya mendaftarkan direktori bin karena saya memiliki kesalahan "batas perintah bios tercapai" pada beberapa aplikasi yang di-host di bagian UNC lainnya. Tapi saya kira pengaturan FCNMode tidak memengaruhi dirs di luar direktori aplikasi.

— Mark S. Rasmussen

FCNMode juga dapat membantu, tetapi struktur disk yang besar di atas UNC dapat menyebabkan keduanya ikut berperan. Saya 'percaya' bahwa FCN bertentangan dengan seluruh pohon direktori untuk .NET 2.0 dan lebih tinggi.

— Scott Forsyth - MVP

Lebih jauh dari itu: Saya telah melihat MaxCmds habis dengan beberapa node ujung depan dan banyak pengguna yang digunakan untuk folder yang berbeda. MaxCmds adalah pengaturan yang saya terapkan untuk semua pertanian web UNC saya. Saya belum pernah melihat kelemahan dari perubahan itu. Ada juga pengaturan server jika target berbagi CIFS adalah server windows, tetapi itu tidak berlaku untuk Anda.

— Scott Forsyth - MVP

Hanya untuk memperjelas komentar saya, aplikasi .NET yang sebenarnya disimpan di disk lokal. Tujuan utama aplikasi adalah untuk menyajikan data gambar, yang disimpan pada saham UNC. Pengaturan FCNMode, seperti yang saya mengerti, hanya berlaku untuk direktori aplikasi, sehingga tidak berdampak pada kasus saya. MaxCmds masih merupakan pelakunya. Semua aplikasi berjalan di bawah akun yang sama, tetapi dengan 500+ aplikasi web di setiap server, sepertinya saya kehabisan.

— Mark S. Rasmussen

Perilaku default di ASP.NET untuk FCN adalah untuk melintasi seluruh struktur direktori. Kunci registri HKLM \ Software \ Microsoft \ ASP.NET \ FCNMode bisa 0, 1 atau 2. 0 adalah default yang memiliki objek FCN untuk setiap folder. Jika Anda mengubahnya menjadi 2 maka akan menggunakan satu objek untuk root dan semua subdirektori. Pengaturan ke 1 mematikannya sepenuhnya. support.microsoft.com/kb/911272 . Anda juga dapat menemukan posting blog dan diskusi ini bermanfaat: weblogs.asp.net/owscott/archive/2006/02/21/ASP.NET-v2.0- 2D00 -AppDomain-recycles_2C00_ -lebih umum-daripada-sebelumnya.aspx .

— Scott Forsyth - MVP

1

mungkin restart layanan workstation di server aplikasi!

— tony roth
sumber

jika benar-benar kehilangan resolusi nama, Anda dapat mencoba sebagai percobaan menggunakan file host untuk menyingkat proses resolusi nama.

— tony roth

Saya mencoba untuk me-restart layanan, tidak berhasil, tetapi kemudian saya me-reboot server dan tampaknya berfungsi setelah itu.

— Circle Hsiao

0

Saya punya kasus seperti ini sebelumnya, meskipun tidak dengan EMC back end. Untuk aplikasi pengguna tanah, menutup paksa sambungan ke server jarak jauh dan membukanya kembali akan mengembalikannya, meskipun Anda mungkin harus mencoba beberapa kali sebelum dapat bekerja sama. Untuk aplikasi serverland, daur ulang Pool Aplikasi untuk layanan tersebut berfungsi. Jika gagal, mendaur ulang Layanan Workstation dapat menghindari reboot, tetapi hampir sama drastisnya.

— sysadmin1138
sumber

0

Pada sumber:

Bisakah Anda memberikan rincian lebih lanjut tentang perangkat lunak yang diinstal di server aplikasi? Di internet Anda akan menemukan bahwa itu biasanya masalah dengan AV tetapi karena Anda tidak menjalankan ... mungkin aplikasi mode kernel lain seperti perangkat lunak cadangan?

Apakah firewall aktif? Sudahkah Anda memeriksa log peristiwa pada DC untuk server aplikasi yang salah?

Anda juga harus mengendus lalu lintas jaringan CIFS ketika masalah muncul untuk melihat apa yang terjadi.

Satu-satunya kali saya mengalami kesalahan ini adalah ketika server / workstation entah bagaimana "kehilangan" tautannya dengan domain. Memberlakukan kembali keanggotaan domain melakukan trik (netdom / resetpwd). Bisakah Anda mengakses share jaringan lainnya (dari sesi RDP ke server aplikasi) ketika masalah muncul?

— Renik
sumber

Satu-satunya perangkat lunak yang berjalan di server adalah IIS yang menjalankan aplikasi .NET web. Firewall tidak aktif karena ini ada di belakang DMZ kami. Saya akan mencoba dan memeriksa log AD saat berikutnya terjadi. Kiat baik tentang CIFS - Saya akan mencoba dan menambahkan ISCSI LUN di lain waktu untuk melihat apakah itu terkait dengan hanya CIFS atau jika itu masalah konektivitas umum menggunakan nama host. Saya dapat mengakses semua mesin & saham lainnya menggunakan CIFS saat kesalahan ini terjadi.

— Mark S. Rasmussen

0

Apakah ini masalah dengan resolusi nama. Bisakah Anda memeriksa dengan Server DNS Anda? Jika itu tidak memungkinkan untuk menyelesaikan nama dan setelah me-reboot server aplikasi Anda, itu akan memungkinkan untuk mengakses.

Saya memiliki masalah yang sama ketika beberapa pengguna workstation mengeluh bahwa mereka tidak dapat mengakses aplikasi yang disimpan di server lain, kami telah melakukan hal yang sama dengan mencoba mengakses dengan server-ip yang akan bekerja tetapi tidak dengan nama sehingga kami telah memeriksa DNS. Kami telah membuat perubahan dalam Aplikasi untuk mengakses server lain untuk menggunakan alamat IP karena kami memiliki jaringan IP statis.

Beri tahu saya jika saran saya cocok untuk Anda.

— maniargaurav
sumber

Sementara saya mendapatkan pesan kesalahan, saya dapat melakukan nslookup dengan baik, mengembalikan IP yang benar dari DNS AD lokal kami. Saya juga bisa melakukan ping menggunakan nama host dan alamat IP.

— Mark S. Rasmussen

0

Saya mengalami masalah serupa. Saya tidak dapat memetakan share ke windows server 2012 dari server windows 2003.

Grup jaringan telah menerapkan kebijakan AD yang telah mengisolasi versi windows yang lebih rendah ke wadah AD yang tidak memungkinkan versi TLS yang lebih rendah untuk terhubung ke server yang menjalankan versi TLS yang lebih tinggi. Memindahkan server kembali atau menonaktifkan kebijakan untuk terhubung dengan versi TLS yang lebih rendah memperbaiki masalah ini.

Berikut adalah beberapa kesalahan yang saya temui di log sistem:

Sertifikat yang diterima dari server jarak jauh dikeluarkan oleh otoritas sertifikat yang tidak dipercaya. Karena itu, tidak ada data yang terkandung dalam sertifikat dapat divalidasi. Permintaan koneksi SSL telah gagal. Data terlampir berisi sertifikat server.

Lansiran fatal dihasilkan dan dikirim ke titik akhir jarak jauh. Ini dapat mengakibatkan pemutusan koneksi. Protokol TLS mendefinisikan kode kesalahan fatal adalah 48. Status kesalahan Windows SChannel adalah 552.

Semoga ini bisa membantu menyelesaikan masalah Anda.

— info_tech
sumber