12
Domäne: Verbindungsprobleme zu Freigabeordner - Drucker im Subnetz
Hallo miteinander,
folgendes Setup: Windows Server 2019, virtualisiert
VM: DC + VM: Terminalserver - läuft seit 2019 ohne Probleme durch, trotz Windows Updates. Clients sind Win10 Pro 22H2.
Befinden sich im 192.168.1.X Netz
Es gibt noch eine Filiale, welche sich im 192.168.2.X Netz befindet. Beide Standorte sind seit längerem über einen Site 2 Site VPN Tunnel (Drayteks) verbunden. Das läuft stabil und ohne Probleme
Die Filiale arbeitet via RDP auf dem Terminalserver. Die letzten Windows Updates wurden letzten Mittwoch überall ausgerollt. Als Sicherheitssoftware kommt ESET Endpoint Security zum Einsatz.
In der Filiale gibt es ein paar Nadeldrucker (USB) welche auf dem TS genutzt werden. Ebenso ein paar Freigaben der lokalen Clients (gdt -> Arztsoftware)
Bis auf die Win Updates wurde hier nichts geändert - keine GPO Änderungen oder ähnliches
Das Problem:
Seit gestern kommt der TS nicht mehr an die Freigaben ran und auch die lokalen Filial-Drucker sind über den Terminalserver nicht mehr ansprechbar. Öffne ich über den Windows Explorer am TS die lokale IP Adresse (\\192.168.2.13) kommt unbekannter Fehler. Ping auf IP und FQDN des Rechners läuft aber problemlos. Mache ich das am AD Server, kommt das gleiche, binde ich jedoch das Netzwerklaufwerk mit einem anderen Domänen Benutzer ein, klappt das ohne Probleme. Mach ich das analog am TS, klappt das nicht.
Die Netzwerk Problem Behandlung vom TS sagt, dass der Client erreichbar ist, jedoch auf dem Port 445 nicht antwortet.
Ein anderer Client hingegen kann mich den TS normal Daten austauschen. Öffne ich Powershell und gebe get-smbconnection ein kommt der Filial Client
P.S. die Filiale kommt ohne Probleme auf die Freigabe des TS drauf, auch die RDP Verbindung klappt problemlos und ist stabil.
Lösungsansätze:
Neustart Server + Client -> keine Änderung
VPN Tunnel neu aufgebaut - Router neu gestartet -> keine Änderung
Alle Firewalls (Client + TS) ausgeschaltet -> keine Änderung
Windows Update KB5044273 am Client entfernt -> keine Änderung
ESET am Client entfernt. -> keine Änderung
lokale Sicherheitsrichtlinien (hier vermute ich das Problem) - es wurde von mir zwar nichts geändert, evtl hat ein Update hier was kaputt gemacht. Auf den ersten Blick sehe ich aber kein Unterschiede bzw. Probleme.
Ich hoffe, dass Ihr mir hier weiterhelfen könnt, da ich grad auf dem Schlauch stehe. Vielen Dank schon mal.
folgendes Setup: Windows Server 2019, virtualisiert
VM: DC + VM: Terminalserver - läuft seit 2019 ohne Probleme durch, trotz Windows Updates. Clients sind Win10 Pro 22H2.
Befinden sich im 192.168.1.X Netz
Es gibt noch eine Filiale, welche sich im 192.168.2.X Netz befindet. Beide Standorte sind seit längerem über einen Site 2 Site VPN Tunnel (Drayteks) verbunden. Das läuft stabil und ohne Probleme
Die Filiale arbeitet via RDP auf dem Terminalserver. Die letzten Windows Updates wurden letzten Mittwoch überall ausgerollt. Als Sicherheitssoftware kommt ESET Endpoint Security zum Einsatz.
In der Filiale gibt es ein paar Nadeldrucker (USB) welche auf dem TS genutzt werden. Ebenso ein paar Freigaben der lokalen Clients (gdt -> Arztsoftware)
Bis auf die Win Updates wurde hier nichts geändert - keine GPO Änderungen oder ähnliches
Das Problem:
Seit gestern kommt der TS nicht mehr an die Freigaben ran und auch die lokalen Filial-Drucker sind über den Terminalserver nicht mehr ansprechbar. Öffne ich über den Windows Explorer am TS die lokale IP Adresse (\\192.168.2.13) kommt unbekannter Fehler. Ping auf IP und FQDN des Rechners läuft aber problemlos. Mache ich das am AD Server, kommt das gleiche, binde ich jedoch das Netzwerklaufwerk mit einem anderen Domänen Benutzer ein, klappt das ohne Probleme. Mach ich das analog am TS, klappt das nicht.
Die Netzwerk Problem Behandlung vom TS sagt, dass der Client erreichbar ist, jedoch auf dem Port 445 nicht antwortet.
Ein anderer Client hingegen kann mich den TS normal Daten austauschen. Öffne ich Powershell und gebe get-smbconnection ein kommt der Filial Client
P.S. die Filiale kommt ohne Probleme auf die Freigabe des TS drauf, auch die RDP Verbindung klappt problemlos und ist stabil.
Lösungsansätze:
Neustart Server + Client -> keine Änderung
VPN Tunnel neu aufgebaut - Router neu gestartet -> keine Änderung
Alle Firewalls (Client + TS) ausgeschaltet -> keine Änderung
Windows Update KB5044273 am Client entfernt -> keine Änderung
ESET am Client entfernt. -> keine Änderung
lokale Sicherheitsrichtlinien (hier vermute ich das Problem) - es wurde von mir zwar nichts geändert, evtl hat ein Update hier was kaputt gemacht. Auf den ersten Blick sehe ich aber kein Unterschiede bzw. Probleme.
Ich hoffe, dass Ihr mir hier weiterhelfen könnt, da ich grad auf dem Schlauch stehe. Vielen Dank schon mal.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 668806
Url: https://administrator.de/contentid/668806
Ausgedruckt am: 18.11.2024 um 15:11 Uhr
12 Kommentare
Neuester Kommentar
Moin,
Schon via DNS versucht? \\FQDN\ ?
Was sagt Wireshark?
Was sagt Eventvwr?
Gruß
lokale IP Adresse (\\192.168.2.13) kommt unbekannter Fehler
Ist Kerberos aktiv und verweigert nun solche Zugänge?Schon via DNS versucht? \\FQDN\ ?
Was sagt Wireshark?
Was sagt Eventvwr?
Gruß
Schon via DNS versucht? \\FQDN\ ?
Natürlich, leider das gleiche Problem. DNS ist aber voll funktionsfähig. Ich kann den FQDN auf beide Seiten auflösen.Innerhalb der Subnetze läuft alles ohne Probleme
Im Log sehe ich nichts auffälliges.
Wireshark habe ich noch nicht probiert, da ich kein direktes TCP/IP Netzwerkproblem vermute, sondern ein Berechtigungsproblem.
Berechtigungsproblem
Würde Dir WS mitteilen.Gruß
Okay, danke. Probiere ich dann mal
Moin
Gruß
Zitat von @zer0g2224:
Die Netzwerk Problem Behandlung vom TS sagt, dass der Client erreichbar ist, jedoch auf dem Port 445 nicht antwortet.
Was hast Du zu dieser Meldung unternommen? Wenn das wirklich so ist, dann ist es ja auch nicht wirklich verwunderlich, wenn es nicht funktionert...Die Netzwerk Problem Behandlung vom TS sagt, dass der Client erreichbar ist, jedoch auf dem Port 445 nicht antwortet.
Gruß
Was hast Du zu dieser Meldung unternommen? Wenn das wirklich so ist, dann ist es ja auch nicht wirklich verwunderlich, wenn es nicht funktionert...
Ein anderer lokaler Client vor Ort kommt drauf, ergo antwortet der Client auf Port 445 - er antwortet auch dem DC - wenn ich einen anderen User verwende. Nur dem TS antwortet er nicht. Der gleiche Client kommt aber auf die Freigabe des TSErgänzung: Ein Win11 Client geht ganz normal ohne Probleme, ein anderer, baugleicher Client geht, wie viele andere nicht.
Zitat von @zer0g2224:
Ein anderer lokaler Client vor Ort kommt drauf, ergo antwortet der Client auf Port 445
Ja.. Er antwortet dem anderen lokalen Client. Die Windows Problembehandung mag ja auch nicht der Weisheit letzter Schluss sein, aber ausführen und dann gefundene Fehler ignorieren?? ALso würde ich dann doch mal auf jeden Fall prüfen, ob ich vom Rechner mit dem Fehler den SMB-Port am Ziel erreichen kann.Ein anderer lokaler Client vor Ort kommt drauf, ergo antwortet der Client auf Port 445
ALso würde ich dann doch mal auf jeden Fall prüfen, ob ich vom Rechner mit dem Fehler den SMB-Port am Ziel erreichen kann.
Sorry, hatte ich vergessen reinzuschreiben: Mit Test-netconnection auf dem TS bekomme ich vom Client die Rückmeldung, dass der Port erreichbar ist.Mir fällt auf die schnelle kein anderer Test mehr ein...
Teste mal, ob es einen Unterschied macht, wenn Du über
E.
- FQDN
- NetBIOS
- IP-Adresse
E.
Teste mal, ob es einen Unterschied macht, wenn Du über
Ergebnis war das gleiche -> es ging nichts davon- FQDN
- NetBIOS
- IP-Adresse
Aber, Wireshark hat was geliefert. Da war ein Eintrag mit NO LOGON SERVER AVAILABLE.
Daraufhin habe ich mal die Firewall des DC ausgeschaltet (hatte ich noch nicht gemacht). Dann kam ich sofort via FQDN auf die Maschine. Komischerweise auch nachdem ich diese wieder angeschaltet habe.
Der Zugriff via IP Adresse geht aber immer noch nicht.
Komischerweise auch nachdem ich diese wieder angeschaltet habe.
Sicherlich nur solange, wie die SMB-Sitzung auf dem Fileserver noch gilt. Wenn diese abgelaufen ist, wird es wohl wieder nicht funktionieren.Das klingt so, als wenn der Fileserver den DC nicht erreichen kann, um die Sitzung für den Benutzer einzurichten.
Das kannst Du gegenprüfen, indem Du auf dem FS einen lokalen Benutzer erstellst und für die Freigabe berechtigst. Dann vom TS explizit mit diesem Benutzer verbinden, z.B. mit
net use \\server\freigabe /user:server\lokalerbenutzer
Das sollte dann funktionieren.NO LOGON SERVER AVAILABLE
here we go. Endlich eine vernünftige Aussage.Witzig: idR. fragt man zu erst: passt die FW? Mal ohne probiert? ... :D
Na dann bekommste das ja nun hin ;)
Gruß
