7
Laufwerke werden nicht immer gemappt (Windows)
Mahlzeit!
Nehmen wir mal an, ich hätte ein Netzwerk mit einem DC, einem Fileserver und zwei Terminalservern, allesamt unter Windows Server 2008R2, auf aktuellem Patch-Stand und mit aktuellen Treibern, auch von VMware, weil eben virtuell. Aus irgendeinem Grund werden dort die Laufwerke nicht per GPO, sondern oldschool per Login-Script verteilt. Bei manchen Usern funktioniert das problemlos und bei anderen wieder nur manchmal. Hin und wieder sind die Laufwerke da, und dann mal wieder nicht. Ereignisanzeige und so die Basissachen haben nichts gebracht: es gibt keinerlei Info bisher, warum das so ist. Während man normalerweise von einem Netzwerkproblem ausgehen könnte, kommt hier noch eine Sache dazu: klicke ich als Admin in der Netzwerkumgebung auf einen Server, bekomme ich die Meldung, dass ich evtl. keine Berechtigung hätte... eine der Standardmeldungen also. Gebe ich einen Freigabenamen komplett in die Adresszeile ein, komme ich am Ziel an. Vielleicht. Klicke ich dann wieder auf den Server, komme ich drauf. Oder auch nicht. Je nachdem, wie ihm gerade ist.
Da es zwei Terminalserver betrifft, suche ich natürlich zuerst am Fileserver. Da es aber auch unterschiedliche und nicht alle User betrifft, suche ich... wo?
Es ist egal, ob ich gerade morgens als erster anmelde (von wegen "warten bis das Netzwerk bereit ist") oder im Laufe des Tages. Die Batch-Datei meldet in dem Fall immer den Systemfehler 53, "Netzwerkpfad nicht gefunden". Namensauflösung wurde bereits durch WINS erweitert, keine Änderung.
Und jetzt ein weiteres Kuriosum: gebe ich als Pfad den kompletten FQDN oder die IP-Adresse an, besteht das Problem nicht. Es scheint also was mit der Namensauflösung zu tun zu haben. Oder?
Wir haben rund 160 praktisch baugleiche Netzwerke bei unseren Kunden im Einsatz, mal größer, schon mal andere Anwendungen, aber von der Technik her vergleichbar. Das passiert nur in einem einzigen Netzwerk und es sieht genauso aus, wie die anderen auch. Was übersehe ich?
Grüße
Jörg
Nehmen wir mal an, ich hätte ein Netzwerk mit einem DC, einem Fileserver und zwei Terminalservern, allesamt unter Windows Server 2008R2, auf aktuellem Patch-Stand und mit aktuellen Treibern, auch von VMware, weil eben virtuell. Aus irgendeinem Grund werden dort die Laufwerke nicht per GPO, sondern oldschool per Login-Script verteilt. Bei manchen Usern funktioniert das problemlos und bei anderen wieder nur manchmal. Hin und wieder sind die Laufwerke da, und dann mal wieder nicht. Ereignisanzeige und so die Basissachen haben nichts gebracht: es gibt keinerlei Info bisher, warum das so ist. Während man normalerweise von einem Netzwerkproblem ausgehen könnte, kommt hier noch eine Sache dazu: klicke ich als Admin in der Netzwerkumgebung auf einen Server, bekomme ich die Meldung, dass ich evtl. keine Berechtigung hätte... eine der Standardmeldungen also. Gebe ich einen Freigabenamen komplett in die Adresszeile ein, komme ich am Ziel an. Vielleicht. Klicke ich dann wieder auf den Server, komme ich drauf. Oder auch nicht. Je nachdem, wie ihm gerade ist.
Da es zwei Terminalserver betrifft, suche ich natürlich zuerst am Fileserver. Da es aber auch unterschiedliche und nicht alle User betrifft, suche ich... wo?
Es ist egal, ob ich gerade morgens als erster anmelde (von wegen "warten bis das Netzwerk bereit ist") oder im Laufe des Tages. Die Batch-Datei meldet in dem Fall immer den Systemfehler 53, "Netzwerkpfad nicht gefunden". Namensauflösung wurde bereits durch WINS erweitert, keine Änderung.
Und jetzt ein weiteres Kuriosum: gebe ich als Pfad den kompletten FQDN oder die IP-Adresse an, besteht das Problem nicht. Es scheint also was mit der Namensauflösung zu tun zu haben. Oder?
Wir haben rund 160 praktisch baugleiche Netzwerke bei unseren Kunden im Einsatz, mal größer, schon mal andere Anwendungen, aber von der Technik her vergleichbar. Das passiert nur in einem einzigen Netzwerk und es sieht genauso aus, wie die anderen auch. Was übersehe ich?
Grüße
Jörg
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: 322945
Url: https://administrator.de/contentid/322945
Ausgedruckt am: 24.11.2024 um 15:11 Uhr
7 Kommentare
Neuester Kommentar
Hallo,
bereinige das DNS.
Stelle von Script auf reine GPO Verteilung um.
Ansonsten, wenn Du weißt das es per FQDN immer geht, dann stelle die Scripte für die Freigabe doch auf \\FQDN\Freigabe oder \\IP\Freigabe um.
Ist DFS im Einsatz oder nur ein normaler Fileserver?
Gruß
Chonta
bereinige das DNS.
Stelle von Script auf reine GPO Verteilung um.
Ansonsten, wenn Du weißt das es per FQDN immer geht, dann stelle die Scripte für die Freigabe doch auf \\FQDN\Freigabe oder \\IP\Freigabe um.
Ist DFS im Einsatz oder nur ein normaler Fileserver?
Gruß
Chonta
Hi Chonta,
umstellen au FQDN oder IP geht nicht, weil es eine Anwendung gibt, die eben auf den NetBios-Namen angewiesen ist. Da es sich hier freundlicherweise um DATEV-Software handelt, ist das mit Alternativen auch nicht mal eben so gemacht.
DFS ist nicht im Einsatz, nur ein einfacher FS, ist ein kleines Netz für acht oder neu Leute. Der zweite Terminalserver ist schon ein Test-Gerät, um eben feststellen zu können, ob es dort genauso ist. An sich ist da nur einer im Netz.
Das mit dem Umstellen auf GPO mache ich jetzt mal testhalber, was deswegen ein wenig blöd ist, weil die ganzen anderen Netze genauso laufen und dann wieder die Kollegen vom First-Level irritiert werden, wenn die da mal was suchen. Aber gut, was sein muss... dann müssen die eben mitdenken
Gruß
Jörg
umstellen au FQDN oder IP geht nicht, weil es eine Anwendung gibt, die eben auf den NetBios-Namen angewiesen ist. Da es sich hier freundlicherweise um DATEV-Software handelt, ist das mit Alternativen auch nicht mal eben so gemacht.
DFS ist nicht im Einsatz, nur ein einfacher FS, ist ein kleines Netz für acht oder neu Leute. Der zweite Terminalserver ist schon ein Test-Gerät, um eben feststellen zu können, ob es dort genauso ist. An sich ist da nur einer im Netz.
Das mit dem Umstellen auf GPO mache ich jetzt mal testhalber, was deswegen ein wenig blöd ist, weil die ganzen anderen Netze genauso laufen und dann wieder die Kollegen vom First-Level irritiert werden, wenn die da mal was suchen. Aber gut, was sein muss... dann müssen die eben mitdenken
Gruß
Jörg
Hi
Was passiert den wenn du in der Hosts Datei einen Fixen eintrag für den FS machst? ist dann der Fehler noch da ?
LG Andy
Was passiert den wenn du in der Hosts Datei einen Fixen eintrag für den FS machst? ist dann der Fehler noch da ?
LG Andy
Bei der hosts hilft das noch nichts. Mache ich den Eintrag allerdings in die lmhosts, also in die ganz alte Datei, die es seit 2000 eigentlich nicht mehr wirklich geben sollte, funktioniert es. Allerdings hätte ich gerne die Ursache gefunden und nicht am Symptom herumgeschraubt. Es geht wie gesagt um recht viele Netze, die sich in solchen Dingen möglichst nicht unterscheiden sollten.
Nebenbei haben wir inzwischen von Script auf GPO umgestellt, um die Laufwerke zu verbinden: keine Änderung.
VG
Jörg
Nebenbei haben wir inzwischen von Script auf GPO umgestellt, um die Laufwerke zu verbinden: keine Änderung.
VG
Jörg
Mache ich den Eintrag allerdings in die lmhosts
Die lmhosts ist auch für Netbios/WINS daDie hosts ist für DNS da.
Einer der Dienste für die Namensauflösung hat ne Macke/ dienst neu starten, Cache löschen usw.
Gruß
Chonta
Dienste bzw. auch Server neu starten ist schon durch. Cache löschen einzeln ebenfalls, so haben wir die Tests recht schnell machen können. Für NetBios gibt's aber nicht etwa noch eine Datenbank oder sowas? Das ist alles immer flüchtig, oder?
Wie ist das mit der Reihenfolge der Namensauflösung? Zuerst kommt die Abfrage an den Cache, dann lmhosts, dann WINS und anschließend dann Hosts und DNS und irgendwann kommt auch noch ein Broadcast dazwischen. Jedenfalls, wenn das eingestellt ist, was es in unserem Fall ist (Knotentyp 8, Hybrid). Bedeutet aber doch auch, dass gleich das erste zurückgelieferte Ergebnis - tja, falsch ist? Kann ja so auch nicht stimmen, denn er sagt ja nicht, dass er da was nicht findet, sondern dass der Zugriff verweigert wird.
Heute Abend wird erstmal die Netzwerkumgebung am Fileserver komplett bereinigt. Weil das VMware ist, kann es ja immerhin sein, dass mal die Netzwerkkarte geändert wurde und da irgendwo so ein Schatteneintrag übriggeblieben ist, der das verursacht.
Egal für heute, ich melde gelegentlich, was wir so finden.
Nen chilligen Feierabend wünsche ich!
Jörg
Wie ist das mit der Reihenfolge der Namensauflösung? Zuerst kommt die Abfrage an den Cache, dann lmhosts, dann WINS und anschließend dann Hosts und DNS und irgendwann kommt auch noch ein Broadcast dazwischen. Jedenfalls, wenn das eingestellt ist, was es in unserem Fall ist (Knotentyp 8, Hybrid). Bedeutet aber doch auch, dass gleich das erste zurückgelieferte Ergebnis - tja, falsch ist? Kann ja so auch nicht stimmen, denn er sagt ja nicht, dass er da was nicht findet, sondern dass der Zugriff verweigert wird.
Heute Abend wird erstmal die Netzwerkumgebung am Fileserver komplett bereinigt. Weil das VMware ist, kann es ja immerhin sein, dass mal die Netzwerkkarte geändert wurde und da irgendwo so ein Schatteneintrag übriggeblieben ist, der das verursacht.
Egal für heute, ich melde gelegentlich, was wir so finden.
Nen chilligen Feierabend wünsche ich!
Jörg
Moin
Das war mir klar das du das Problem so nicht lösen willst aber eingrenzen kann man es zumindest und man hat einen besseren Ansatz bei der Fehlersuche !
Der Wins hat eine Datenbank hier wird also auch gespeichert man kann aber das Ausaltern der Enträge im Wins einstellen. Manuell löschen würde ich nur wenn du nur einen Wins Server hast den wenn du eine Replikation hast und auf einem Server löscht bleibt am 2 Server die leiche liegen.
Interessant wäre auch um welche Clients es sich handelt sind das alles Terminalserver 2008 R2 ? Oder gibt es auch Windows 10,8,7 PCs auf denen das Problem auftritt ?
Im Wins bzw. Broadcast bereich darf es keine Doppelten Macadressen, hostnamen oder IP Adressen geben aber ich denke das wirst du bereits geprüft haben. Ich würde auch testweise am FileServer die Packetgröße ( MTU Size ) auf 1500 stellen um hier irgendwelche Fehlerhaften Broadcast Pakete auszuschliesen.
Um das genauer zu sehen kannst du auch am Fileserver einen Sniffer wie Wireshark installieren und mitprotokollieren lassen was für Anfragen ankommen.
LG Andy
Das war mir klar das du das Problem so nicht lösen willst aber eingrenzen kann man es zumindest und man hat einen besseren Ansatz bei der Fehlersuche
!Der Wins hat eine Datenbank hier wird also auch gespeichert man kann aber das Ausaltern der Enträge im Wins einstellen. Manuell löschen würde ich nur wenn du nur einen Wins Server hast den wenn du eine Replikation hast und auf einem Server löscht bleibt am 2 Server die leiche liegen.
Interessant wäre auch um welche Clients es sich handelt sind das alles Terminalserver 2008 R2 ? Oder gibt es auch Windows 10,8,7 PCs auf denen das Problem auftritt ?
Im Wins bzw. Broadcast bereich darf es keine Doppelten Macadressen, hostnamen oder IP Adressen geben aber ich denke das wirst du bereits geprüft haben. Ich würde auch testweise am FileServer die Packetgröße ( MTU Size ) auf 1500 stellen um hier irgendwelche Fehlerhaften Broadcast Pakete auszuschliesen.
Um das genauer zu sehen kannst du auch am Fileserver einen Sniffer wie Wireshark installieren und mitprotokollieren lassen was für Anfragen ankommen.
LG Andy
