liquidbase
Goto Top

Windows 10 - Netzwerklaufwerke verlieren immer wieder Verbindung zum Server

Guten Morgen alle zusammen face-smile

Ich habe seit längerem ein Problem wo ich jetzt an die Grenze der Ideen stoße.
Bei dem Problem handelt es sich darum das Netzwerklaufwerke die in Windows 10 Pro 20H2 gemappt werden immer wieder mal die Verbindung verlieren. Mal passiert das einmal am Tag, mal erst nach mehreren Tagen und dann auch wieder mehrmals am Tag. Die Fehlermeldung ist dabei immer wieder identisch und lautet:

Der Angegebene Netzwerkname ist nicht mehr verfügbar.

Wenn man dann das entsprechende Netzwerklaufwerk trennt und neu verbinden will, wird das direkt von Windows mit der identischen Fehlermeldung blockiert. Erst wenn ich einen entsprechenden ping auf die IP oder den Namen ausführe und dann die Laufwerke wieder verbinde funktioniert es.
Bei dem Zielserver handelt es sich um eine Linuxbox mit einem RIS-System für Radiologien auf der drei Freigaben existieren, welche die Mitarbeiter für die tägliche Arbeit benötigen. Das interessante dabei ist das andere Anwendungen welche die gleiche IP oder Namen Benutzen (andere Ports, z. B. 80) einwandfrei funktionieren.

Mittlerweile habe ich auch einiges an Troubleshooting durch um das Problem zu fixen, aber bisher gab es nur temporär einer Besserung. Also was hab ich bisher gemacht?

  • FastBoot Deaktiviert nach folgenden Thread
  • SMBv1 nachinstalliert (an sich unpraktisch)
  • GPO Beim Neustart des Computers und bei der Anmeldung immer auf das Netzwerk warten aktiviert
  • Energie-Einstellung der Netzwerkkarte angepasst, so dass Windows diese nicht in den Standby schickt
  • Veraltete AV-Lösung deinstalliert (Trend Micro)
  • PowerShell-Script implementiert was per Batch-File bei einem Neustart oder neu Anmelden ausgeführt wird
  • Eintrag in der hosts-File mit IP und Name (läuft kein DNS im Netzwerk)

Ja das war es erstmal soweit.
Problem was ich dabei habe, ist das ich nicht an die Linuxbox rankomme. Die wird von dem Softwarehersteller für das RIS-System verwaltet und hier geben die Techniker zurück das alles Ordnungsgemäß funktioniert.

Daher bin ich ehrlich gesagt ein wenig am Ende was Ideen betrifft.

Sollten euch noch Informationen fehlen, welche euch das Problem genauer einschätzen lassen einfach fragen.
Danke schon mal im voraus für sämtlichen Input der kommen wird.

Content-ID: 667076

Url: https://administrator.de/contentid/667076

Ausgedruckt am: 21.11.2024 um 19:11 Uhr

chgorges
Lösung chgorges 26.05.2021 um 09:46:11 Uhr
Goto Top
Moin,

Schnellstart deaktivieren, das ist mit 20H2 und Netzlaufwerken wieder eine absolute Katastrophe.

VG
liquidbase
liquidbase 26.05.2021 aktualisiert um 09:51:52 Uhr
Goto Top
Zitat von @chgorges:

Moin,

Schnellstart deaktivieren, das ist mit 20H2 und Netzlaufwerken wieder eine absolute Katastrophe.

VG
Wurde bereits gemacht, nachdem das Update Manuell installiert wurde (auf allen Rechnern). Kenne ja das Verhalten das sich zuvor gesetzte Einstellungen gerne wieder auf die Default-Werte zurücksetzt. An sich sollte das auch durch den Eintrag in der Registry permanent sein (funktioniert nur nicht immer).

21H1 hat für die Praxis noch keine Freigabe.
Franz-Josef-II
Lösung Franz-Josef-II 26.05.2021 um 10:30:52 Uhr
Goto Top
Servas

Es löst zwar nicht das Problem, ist nur ein "WürgAround" 😊

Lege ein Scriptdatei auf den Desktop der User mit folgenden Inhalt:
net use X: \\server\freigabe\undsoweiter

Damit kann der User selber die Netzlaufwerke wiederherstellen.


Ansonsten: Was sagt das Ereignisprotokoll in Bezug auf das Netzwerk? Wenn Du einen (relativ) genauen Verbindungsabbruchszeitpunkt (geniales Wort 😊 ) hast, dann kontrolliere das Protokoll in dem Zeitrahmen.

Es sind drei Freigaben, verliert der Client alle drei oder "nur" ein oder zwei Verbindungen zur gleichen Zeit? Verliert er überhaupt die Netzwerkverbindung? (Kartentreiber aktúell?)
ukulele-7
ukulele-7 26.05.2021 um 11:14:52 Uhr
Goto Top
Wie bekommt der Client seine Netzlaufwerke zugewiesen, per GPO? Ist da als Aktion eventuell "Ersetzen" in der GPO konfiguriert?
liquidbase
liquidbase 26.05.2021 aktualisiert um 11:25:24 Uhr
Goto Top
Zitat von @Franz-Josef-II:
Lege ein Scriptdatei auf den Desktop der User mit folgenden Inhalt:
net use X: \\server\freigabe\undsoweiter

Existiert bereits.
Im Endeffekt ist es so gestaltet das sich der User einmal Abmelden muss und dann wieder anmeldet. Anders ließ sich das nicht realisieren, da bei laufender Sitzung die Laufwerke nicht wiederhergestellt werden können. An sich geht das, aber eine korrekt funktionierende Lösung sieht anders aus :/


Zitat von @Franz-Josef-II:
Ansonsten: Was sagt das Ereignisprotokoll in Bezug auf das Netzwerk? Wenn Du einen (relativ) genauen Verbindungsabbruchszeitpunkt (geniales Wort 😊 ) hast, dann kontrolliere das Protokoll in dem Zeitrahmen.

Es sind drei Freigaben, verliert der Client alle drei oder "nur" ein oder zwei Verbindungen zur gleichen Zeit? Verliert er überhaupt die Netzwerkverbindung? (Kartentreiber aktúell?)
Das Ereignisprotokoll zeigt nur den Fehler, den man auch über die GUI bekommt. War auch der erste Anlaufpunkt um zu ermitteln was die Ursache ist. Es sind dann auch alle Freigaben die zu dem Server führen, die man dann nicht mehr benutzen kann. Will man das ganze manuell beheben braucht es die folgenden Schritte:
  • Ping auf den Host
  • Trennen der alten Freigaben
  • Freigaben erstellen über IP-Adresse oder Name (abhängig davon was vorher konfiguriert war)

Das Logon-Script macht das effektiv automatisch, hat aber ein Akzeptanzproblem, da es keiner einsieht sich ständig ab- und anzumelden (was ich durchaus verstehen kann, würd mich auf Dauer auch nerven). Das entsprechend Logon-Script was ich da benutze ist das folgende PowerShell-Script (hab ich bei der Suche nach einer Lösung gefunden):
$i = 3
$target = "xxx.xxx.xxx.xxx"  

while($True){
    $error.clear()
    $MappedDrives = Get-SmbMapping | Where-Object -property Status -Value Unavailable -EQ | Select-Object LocalPath,RemotePath
    ping $target
    foreach( $MappedDrive in $MappedDrives)
    {
        try {
            New-SmbMapping -LocalPath $MappedDrive.LocalPath -RemotePath $MappedDrive.RemotePath -Persistent $True
        } catch {
            Write-Host "There was an error mapping $MappedDrive.RemotePath to $MappedDrive.LocalPath"  
        }
    }
    $i = $i - 1
    if($error.Count -eq 0 -Or $i -eq 0) {break}

    Start-Sleep -Seconds 30
}


Zitat von @ukulele-7:

Wie bekommt der Client seine Netzlaufwerke zugewiesen, per GPO? Ist da als Aktion eventuell "Ersetzen" in der GPO konfiguriert?
Die Zuweisung geschieht Manuell über den Windows Explorer (Netzlaufwerk verbinden), da es so keine Domain gibt wo man das über eine GPO konfigurieren kann. Die im Eingangspost erwähnte GPO für das Netzwerk wurde manuell auf allen Rechnern konfiguriert.
Franz-Josef-II
Franz-Josef-II 26.05.2021 aktualisiert um 11:31:56 Uhr
Goto Top
Das "net use" geht nicht im laufenden Betrieb? Sollte es aber. Was kommt da für eine Fehlermeldung?

und wenn Du einen ping-Befehl als erste Zeile in das Script packst? Ich weiß, Pfusch und Co, nur ein derartiges Problem hatte ich noch nie.


Moment, moment, moment
Zitat von @liquidbase:
es so keine Domain gibt wo man das über eine GPO konfigurieren kann. Die im Eingangspost erwähnte GPO für das Netzwerk wurde manuell ....

Nix Domäne? Dann stell das Ganze in den lokalen Richtlinien ein.
Wie hast Du die GPO ..... ausgerollt? Zieht die überhaupt?
liquidbase
liquidbase 26.05.2021 aktualisiert um 11:58:12 Uhr
Goto Top
Zitat von @Franz-Josef-II:

Das "net use" geht nicht im laufenden Betrieb? Sollte es aber. Was kommt da für eine Fehlermeldung?
Kommt die gleiche Fehlermeldung als wenn man versucht auf das Netzwerklaufwerk zuzugreifen

.... und wenn Du einen ping-Befehl als erste Zeile in das Script packst? Ich weiß, Pfusch und Co, nur ein derartiges Problem hatte ich noch nie.
War auch mein erster Gedanke gewesen aber man muss das Laufwerk trotzdem manuell trennen und wiederverbinden. Alleine das man zuerst einen Ping absetzen MUSS bevor ich die Laufwerke wieder neu verbinden kann ist extrem verwirrend.
Automatisch funktioniert es nur wenn man sich einmal ab- und wieder anmeldet oder Windows neustartet.

Moment, moment, moment
Zitat von @liquidbase:
es so keine Domain gibt wo man das über eine GPO konfigurieren kann. Die im Eingangspost erwähnte GPO für das Netzwerk wurde manuell ....

Nix Domäne? Dann stell das Ganze in den lokalen Richtlinien ein.
Wie hast Du die GPO ..... ausgerollt? Zieht die überhaupt?
Kam vielleicht bei dem Kommentar etwas falsch an.
Es wurde durch eine lokale GPO konfiguriert das beim booten der Rechner immer auf das Netzwerk gewartet wird um auszuschließen das der Bootvorgang zu schnell ist. Das ist die GPO Beim Neustart des Computers und bei der Anmeldung immer auf das Netzwerk warten, die unter dem Punkt Computerkonfiguration => Administrative Vorlagen => System => Anmeldung zu finden ist.

Aber wäre mal eine Idee die Netzwerklaufwerke in der lokalen Gruppenrichtlinie auf jedem Rechner zu konfigurieren, vielleicht hilft das. Hab ich bisher noch nicht gemacht, da so keine Domain aufgesetzt ist.
Franz-Josef-II
Franz-Josef-II 26.05.2021 aktualisiert um 12:15:38 Uhr
Goto Top
Zitat von @liquidbase:

Zitat von @Franz-Josef-II:
und wenn Du einen ping-Befehl als erste Zeile in das Script packst? Ich weiß, Pfusch und Co, nur ein derartiges Problem hatte ich noch nie.
War auch mein erster Gedanke gewesen aber man muss das Laufwerk trotzdem manuell trennen und wiederverbinden. Alleine das man zuerst einen Ping absetzen MUSS bevor ich die Laufwerke wieder neu verbinden kann ist extrem verwirrend.
Automatisch funktioniert es nur wenn man sich einmal ab- und wieder anmeldet oder Windows neustartet.

Dann setze ein:
net use * /delete yes
davor in die erste Zeile

Zitat von @liquidbase:
man zuerst einen Ping absetzen MUSS bevor ....

Netzwerkkartentreiber wirklich aktuell?
liquidbase
liquidbase 26.05.2021 um 12:40:57 Uhr
Goto Top
Zitat von @Franz-Josef-II:
Dann setze ein:
net use * /delete yes
davor in die erste Zeile
Muss ich mal austesten, wenn der Fehler das nächste Mal auftritt.

Zitat von @liquidbase:
man zuerst einen Ping absetzen MUSS bevor ....

Netzwerkkartentreiber wirklich aktuell?
Ja sind sie. Hab es mit den originalen Treibern von Realtek und den von Dell getestet. Das letzte Mal wurde der Treiber für den Chipsatz Ende 2020 aktualisiert, seitdem hat sich da nichts mehr getan.
em-pie
Lösung em-pie 26.05.2021 um 12:59:09 Uhr
Goto Top
Moin,

ich frage mal vorsichtig, da es mich auch mal etliche Nerven gekostet hat:
RIS-System für Radiologien
Die hier vergebene IP-Adresse ist auch tatsächlich nur einmal vergeben worden?
Sprich: ein Dauerping läuft ins Leere, wenn du das Netzwerkkabel am RIS-System ziehst?

Gibt es ansonsten vielleicht ein Session-Limit, auf der Linux-Büchse?
Sprich: maximal 10 Verbindungen (oder wie viele auch immer) und danach ist ende!?

Gruß
em-pie
liquidbase
liquidbase 26.05.2021 aktualisiert um 13:28:43 Uhr
Goto Top
Zitat von @em-pie:

Moin,

ich frage mal vorsichtig, da es mich auch mal etliche Nerven gekostet hat:
RIS-System für Radiologien
Die hier vergebene IP-Adresse ist auch tatsächlich nur einmal vergeben worden?
Sprich: ein Dauerping läuft ins Leere, wenn du das Netzwerkkabel am RIS-System ziehst?
Jips ist nur einmal vergeben. Das RIS-System was auf der Linuxbox läuft hat eine fest eingestellte IP-Adresse die ausserhalb des DHCP-Adressraumes liegt um zu vermeiden das aus Versehen die IP zweimal zugeteilt wird. Auf anderen Systemen ist die IP-Adresse auch nicht manuell konfiguriert wurden. War eine der ersten Dinge die ich kontrolliert habe, da meine Vermutung ebenfalls in die Richtung gingen als ich das erste Mal davon gehört habe. Selbst wenn ich per nmap / Wireshark das ganze teste bekomme ich auch immer wieder die gleiche MAC-Adresse zurück.

Gibt es ansonsten vielleicht ein Session-Limit, auf der Linux-Büchse?
Sprich: maximal 10 Verbindungen (oder wie viele auch immer) und danach ist ende!?

Gruß
em-pie
Laut dem Hersteller des RIS-System gibt es kein Session-Limit für die Freigaben. Aber du hast mich da gerade auf eine Idee gebracht. Die Freigaben auf dem RIS-System werden hier per Samba geregelt. Ich muss mal nachhaken wie der TCP_KeepAlive eingestellt ist.
Franz-Josef-II
Franz-Josef-II 26.05.2021 um 13:30:49 Uhr
Goto Top
Dann könnte es noch eine Hardwaregeschichte sein, die Kabel und Leitungen in Ordnung? Der Switch dazwischen, einen anderen Port nehmen?
liquidbase
liquidbase 26.05.2021 um 13:37:14 Uhr
Goto Top
Zitat von @Franz-Josef-II:

Dann könnte es noch eine Hardwaregeschichte sein, die Kabel und Leitungen in Ordnung? Der Switch dazwischen, einen anderen Port nehmen?
Verkabelung wurde neu aufgesetzt und entsprechende Messsignale gehen sauber von einem Punkt zum anderen. Einzig der Switch wäre eine Idee das man den mal tauscht. Da bin ich aber gerade dabei die Einstellungen auseinanderzupfriemeln bevor ich den wechsel.
eazy-isi
eazy-isi 27.05.2021 um 08:10:41 Uhr
Goto Top
Servus,

hast du schon auf der Realtek Netzwerkkarte folgende Einstellungen disabled ?

Energy-Efficient-Ethernet
Green-Ethernet
PowerSaving Mode

Ich hatte das Thema auch bei einigen Dell Optiplex mit Realtek Netzwerkkarten, die o.g. Einstellungen
haben das Problem bei mir behoben.

Grüße
eazy-isi
Archeon
Archeon 27.05.2021 um 10:54:25 Uhr
Goto Top
Was passiert denn, wenn du im Hintergrund vom betroffenen Client einen dauerhaften Ping auf die Box laufen lässt, trennt sich die Verbindung dann auch und wenn ja, hast du in der Zeit Pingaussetzer?
liquidbase
liquidbase 28.05.2021 aktualisiert um 21:12:58 Uhr
Goto Top
Sorry das ich mich erst jetzt melde, hatte die letzten Tage zuviel zutun.

Zitat von @eazy-isi:

Servus,

hast du schon auf der Realtek Netzwerkkarte folgende Einstellungen disabled ?

Energy-Efficient-Ethernet
Green-Ethernet
PowerSaving Mode

Ja die Optionen sind allesamt deaktiviert, da sie bereits an anderer Stelle Probleme verursacht haben und der alte ITler fand es gut die aktiv zu lassen um Strom zu sparen. Das es im normalen Betrieb dadurch zu Problemen kann hat er einfach ignoriert.

Zitat von @Archeon:

Was passiert denn, wenn du im Hintergrund vom betroffenen Client einen dauerhaften Ping auf die Box laufen lässt, trennt sich die Verbindung dann auch und wenn ja, hast du in der Zeit Pingaussetzer?
Der läuft sauber durch ohne Paketverlust. Dabei ist es egal ob man den Ping per IP oder Rechnername ausgelöst wird. War auch ein Ansatz gewesen den Dauerhaft durchzulaufen bis zu dem Zeitpunkt wo mich der RIS-Hersteller gefragt hat ob ich das ernst meine, da es bei denen die Netzwerklogs voll laufen ließ (wird aus irgendeinem Grund alle eingehenden Verbindungen protokolliert).

Ideen wie den Switch kann ich mittlerweile ausschließen, der arbeitet trotz einer komischen Config einwandfrei und baut auch keinen Loop oder ähnliches. Auch TCP_KeepAlive kann ausgeschlossen werdend, da der grundlegend höher eingestellt ist um verbindungsprobleme mit der RIS-Software auszuschließen (laut Auskunft des Softwarherstellers).

Muss im Endeffekt aber was an der Linuxbox sein, da es aktuell immer wieder andere Rechner erwischt und wieder andere einfach sauber durchlaufen ohne das die Freigaben Probleme machen.
liquidbase
liquidbase 09.06.2021 um 09:29:42 Uhr
Goto Top
So es ist raus woran es hing.
Fehler war die falsche SMB-Version auf der Linuxbox gewesen. Nachdem der RIS-Hersteller die auf eine höhere Version angepasst ist der Fehler jetzt seit 4 Arbeitstagen nicht mehr aufgetreten.
Am Ende dürfte es ein Problem zwischen Windows 10, welches ja so nativ kein SMBv1 mehr mitbringt, und der eingestellten Version auf der Linuxbox gewesen sein. Was mich dabei aber irritiert, ist das, trotz installiertem SMBv1 unter Windows 10, der Fehler aufgetreten ist. Dachte an sich das wenn man das Windows Feature hinzufügt man trotz alledem SMBv1-Verbindungen aufbauen kann um diese normal zu nutzen.

Vielen Dank an alle die mir ihre Ideen für eine Fehlerlösung dagelassen haben face-smile
ukulele-7
ukulele-7 09.06.2021 um 09:42:07 Uhr
Goto Top
Interessehalber: Hattest du die anderen SMB-Versionen auf der Windows Box deaktiviert?
liquidbase
liquidbase 10.06.2021 um 14:57:45 Uhr
Goto Top
Der IT-Verantwortliche vor mir hatte SMBv1 expliziert aktiviert gehabt und v2 sowie v3 nebenher mitlaufen lassen. Aktuell gehe ich davon aus, dass das eigentliche Problem von dem "Feature" SMB 1.0/CIFS automatisch entfernen verursacht wurde. Im Endeffekt waren auf allen Rechner die Features SMB 1.0/CIFS-Client und SMB 1.0/CIFS automatisch entfernen installiert gewesen.
Dann noch dazu das veraltete Protokoll auf der Linuxbox und das Chaos dürfte perfekt gewesen.