Condivisione Windows: il nome di rete specificato non è più disponibile

Abbiamo una scatola SAN EMC NX4 che serve una condivisione CIFS a numerosi server di app Windows Server 2008 R2. I server delle app utilizzano la condivisione CIFS per servire molti file di immagine (~ 2500 operazioni al secondo sulla condivisione), tuttavia né la SAN né i server delle app mostrano evidenti segni di stress.

Di tanto in tanto un server delle app, apparentemente all'improvviso, interromperà la connessione alla SAN. Qualsiasi codice .NET che tenta di servire un file dalla SAN non riesce con:

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

Se eseguo il RDP sul server delle app e provo ad accedere a "\ san-name" tramite explorer, visualizzo lo stesso errore. Tutti gli altri server di app possono accedervi perfettamente. Posso anche accedere perfettamente a "\ ip-of-san", anche il ping funziona.

Un riavvio del server delle app risolve il problema, ma questa è una misura un po 'drastica per il problema, dato che sembra che la SAN funzioni correttamente e che il computer possa accedervi - sembra proprio che l'accesso "\ san-name" abbia incrinato.

Questo è successo a due diversi server di app durante l'ultima settimana, quindi non sospetto che la causa sia un singolo server di app. Ignorando la causa per ora - come potrei ripristinare la connessione "\ san-name" senza riavviare la macchina? E posso in qualche modo interrogare cosa è andato storto?

I registri eventi non mostrano nulla (oltre agli errori ASP.NET correlati causati dal problema), né sui server delle app né sulla SAN.

Aggiornamento: in
base ai suggerimenti, la prossima volta proverò a riavviare il servizio Workstation e vedrò se questo risolve il problema. Sicuramente non è una soluzione, ma molto più veloce da fare che riavviare l'intera macchina come ho fatto attualmente. Qualche modo per interrogare lo stato delle connessioni gestite dal servizio Workstation?

Aggiornamento 2:
confermato che il riavvio del servizio Workstation "risolve" il problema. Il prossimo passo è provare la modifica del reg per aumentare il valore MaxCmds. Non riuscirò a confermare se si tratta del problema, posso solo supporre che venga eseguito per un lungo periodo senza problemi.

Sembra che siano finiti i MaxCmds. Ecco due buoni articoli a riguardo: qui e qui .

Ecco ora per cambiarlo. Creare un file chiamato update.reg e inserirvi quanto segue:

Windows Registry Editor Version 5.00 

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

Salvare, quindi fare doppio clic e accettare il prompt. È richiesto un riavvio.

forse riavviare il servizio workstation sul server app!

Ho avuto casi come questo prima, anche se non con un back-end EMC. Per le applicazioni userland, la chiusura forzata della connessione al server remoto e la riapertura lo riporterà, anche se potrebbe essere necessario provare un paio di volte prima che si comporti. Per le applicazioni serverland, il riciclaggio del pool di applicazioni per quel servizio funziona. In caso contrario, il riciclaggio del servizio Workstation può evitare un riavvio, ma è altrettanto drastico.

Sulla fonte:

Potresti fornire maggiori dettagli sul software installato sul server delle app? In rete troverai che di solito è un problema con un AV ma dal momento che non esegui ... forse un'altra app in modalità kernel come un software di backup?

Il firewall è attivo? Hai controllato i log degli eventi sul controller di dominio per l'app server difettoso?

Dovresti anche annusare il traffico di rete CIFS quando sorge il problema per vedere cosa succede.

Le uniche volte in cui mi sono imbattuto in questo errore sono stati quando il server / workstation in qualche modo "ha perso" il suo collegamento con il dominio. Il re-forzamento dell'appartenenza al dominio ha fatto il trucco (netdom / resetpwd). È possibile accedere ad altre condivisioni di rete (dalla sessione RDP al server delle app) quando si presenta il problema?

Questo può essere un problema con la risoluzione dei nomi. Puoi verificare con il tuo server DNS? Se ciò non consente di risolvere il nome e dopo aver riavviato il server delle applicazioni, consentirebbe l'accesso.

Ho avuto lo stesso problema quando alcuni utenti di workstation si sono lamentati del fatto che non erano in grado di accedere all'applicazione memorizzata in un altro server, abbiamo fatto lo stesso provando ad accedere con server-ip che avrebbe funzionato ma non con il nome, quindi abbiamo controllato DNS. Abbiamo apportato modifiche nell'applicazione per accedere a un altro server per utilizzare l'indirizzo IP poiché disponiamo di una rete IP statica.

Fammi sapere se il mio suggerimento funziona per te.

Ho riscontrato un problema simile. Non sono stato in grado di mappare una condivisione su Windows Server 2012 da un server Windows 2003.

Il gruppo di rete aveva implementato un criterio AD che aveva isolato le versioni inferiori di Windows in un contenitore AD che non consentiva la versione inferiore di TLS di connettersi ai server che eseguono versioni superiori di TLS. Lo spostamento del server indietro o la disabilitazione del criterio per connettersi con la versione precedente di TLS ha corretto questo problema.

Ecco alcuni errori che ho riscontrato nel registro di sistema:

Il certificato ricevuto dal server remoto è stato emesso da un'autorità di certificazione non attendibile. Per questo motivo, nessuno dei dati contenuti nel certificato può essere convalidato. La richiesta di connessione SSL non è riuscita. I dati allegati contengono il certificato del server.

È stato generato un avviso irreversibile che è stato inviato all'endpoint remoto. Ciò può comportare la chiusura della connessione. Il codice di errore irreversibile definito dal protocollo TLS è 48. Lo stato di errore di Windows SChannel è 552.

Spero che ti aiuti a risolvere il tuo problema.