Serverzugriff per Name erst nach gewissen Zeit möglich

qlubtempo

Lieutenant
Registriert
Dez. 2007
Beiträge
911
Guten Morgen Zusammen,

folgendes problem besteht aktuell an einem neuen Client im Netzwerk.

Ich habe ein Netzlaufwerk gemappt: \\server\daten auf F:
Wenn ich nun den PC neustartet, steht bei dem Laufwerk F: ein X für nicht verfügbar.
Per Doppelklick kommt die Meldung: Der lokale Gerätename wird bereits verwendet.
Wenn ich im explorer \\server eingebe kommt die Meldung: Auf \\server konnte nicht zugefriffen werden (0x80004005)
Per IP komme ich aber ohne Probleme drauf. Nach ca. 3-5 Minuten kkannh ich aber auch wieder über den Namen, also \\server zugriffen.

Client: Windows 10
Server: Server 2012 R2 Foundation
 
Läuft auf dem Server ein AD? Falls ja, ist der Client ebenfalls Mitglied von dem AD?

Was erhältst du denn am Client (direkt nach Start) bei:
ping servername
nslookup servername

und gleiches später nochmal, wenn du per Namen auf den Share zugreifen konntest.
 
mach mal'n flushdns. vielleicht hat er da was altes im cache.
 
Ja, ist in der Domäne.
Habe euch mal ein Bild mit einigen Infos angehangen
 

Anhänge

  • maz.JPG
    maz.JPG
    198,9 KB · Aufrufe: 292
Mich irritiert das "der lokale Gerätename wird bereits verwendet"... Betrifft das nur einen User an dem Rechner?

Ich würde mal alle Mappings löschen, am besten über die Registry: HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2 komplett trausschmeißen, User neu anmelden, Laufwerk(e) neu verbinden, falls sie nicht übers loginscript kommen.
 
  • Gefällt mir
Reaktionen: kartoffelpü
derlorenz schrieb:
mach mal'n flushdns. vielleicht hat er da was altes im cache.
Nach PC-Neustart kann da nix mehr im Cache hängen...

@qlubtempo Danke, sieht erst mal normal aus.

Dann würde mir nur noch einfallen, dass aus irgend einem Grund Netbios-Namensauflösung statt DNS dafür genutzt wird, wobei eigentlich DNS vor Netbios versucht wird: https://support.microsoft.com/de-de/topic/reihenfolge-der-microsoft-tcp-ip-hostnamensauflösung-dae00cc9-7e9c-c0cc-8360-477b99cb978a

Edit: Ach, Meldung ist ja, dass der Name bereits verwendet wird. Daher wird es in die Richtung von @SHIVAno1 gehen...
 
Habe die EInträge aus der Registry gelöscht und Netbios deaktiviert. Leider kein Erfolg.

Weitere Anmerkung:
Wenn ich \\server\daten per F: verbinde und neustarte geht \\server nicht
dafür aber \\192.168.15.1\daten

Wenn ich \\192.168.15.1\daten per F: verbinde und neustarte geht \\192.168.15.1 nicht
dafür aber \\server\daten
 
Hm... das es so und so rum geht/nicht geht, ist schon etwas dubios...

Wie verhält es sich denn, mit einem anderen Domainuser am gleichen Rechner? Und haben andere Rechner, oder der gleiche User an einem anderen Rechner, auch dieses Problem?

Was mir noch einfällt wäre, die Laufwerkszuordnung in der Datenträgerverwaltung zu prüfen und Einträge zu dem Netzlaufwerk unter HKLM\SYSTEM\MountedDevices zu löschen, sofern da etwas vorhanden ist.

@Tornhoof Groß-/Kleinschreibung spielt bei DNS oder NetBT m.E. keine Rolle
 
Geht es mit server.praxis.local? Kann es sein, dass dein Client nicht den Suffix anhängt? Vllt. hast im DHCP vergessen, den Suffix dort noch zu hinterlegen.
 
b1nb4sh schrieb:
Geht es mit server.praxis.local? Kann es sein, dass dein Client nicht den Suffix anhängt? Vllt. hast im DHCP vergessen, den Suffix dort noch zu hinterlegen.
Der Client hat eine feste IP-Adresse. Die Daten sind korrekt. Per DHCP ist es aber das gleiche verhalten.

@SHIVAno1 werde es mal mit einen anderen User testen

*EDIT

mit einem neuen AD-User scheint es zu klappen, warum auch immer...
 
Zuletzt bearbeitet:
Der "lokale Gerätename" ist wenn ich mich nicht irre der Laufwerksbuchstabe.

Mach bitte mal ein cmd auf und gib folgendes ein:

net use

Interessant ist die erste Zeile. Dort steht der aktive Modus für's temporäre bzw. permanente verbinden von Netzlaufwerken.


Wenn dort sinngemäß steht "Neue Verbindungen werden gespeichert", dann sind die Netzlaufwerke persistent, werden also auch nach einem Neustart automatisch neu verbunden, ein net use F: ... im Autostart wäre also überflüssig bzw. würde zu deinem Fehlerbild passen, weil das Laufwerk ja bereits in Benutzung ist, F: exisitiert bereits.

Steht dort hingegen "Neue Verbindungen werden nicht gespeichert", werden Netzlaufwerke nur für die Dauer der aktuellen Sitzung verbunden, ein Neustart macht also alle Netzlaufwerke weg. In diesem Fall muss man im Autostart net use F: verwenden, weil das Laufwerk sonst nicht wiederhergestellt wird.


Die Eigenheit von net use ist dabei folgende: Wenn man net use .... /persistent:yes ausführt, wird dieser Modus gespeichert, das heißt, dass das nächste net use implizit immer mit /persistent:yes ausgeführt wird, auch wenn man es nicht explizit eingibt. Führt man net use nun einmal mit /persistent:no aus, werden alle folgenden net use Kommandos automatisch mit /persistent:no ausgeführt.

Das heißt, dass man im Zweifelsfalle IMMER /persistent mit angeben sollte, weil ansonsten nicht sichergestellt ist, dass das Netzlaufwerk nur temporär oder permanent verbunden wird.
 
@qlubtempo Dann ist da m.E. im Profil des Users wohl was hängengeblieben, dazu fällt mir adhoc leider auch nix weiter konkretes ein.

Falls es möglich ist, nimm einen anderen Buchstaben als F:, vielleicht kann man es damit umgehen (meiner Meinung nach ist es ein Problem beim Mappen des Laufwerks zum Netzpfad).

EDIT, eine Idee noch:
Prüfe beim betroffenen Benutzer in der (alten) Systemsteuerung unter Benutzerkonten\Anmeldeinformationsverwaltung, ob hier unter "Windows-Anmeldeinformationen" wiederum "Windows-Anmeldeinformationen" für den Server gespeichert sind und wenn ja, alle löschen. Evtl. kommt er da mit den Usern durcheinander.
Quasi: Lt. lokaler Registry des (angemeldeten) Benutzers, ist das Laufwerk bereits gemappt, er meldet sich aber beim Verbinden des Netzlaufwerkes mit einem anderem User, der in den Anmeldeinformationen gespeichert ist, am Server an. Er will es also noch einmal mit einem anderen User, aber dem gleichen Buchstaben verbinden. Bissl konstruiert, aber leicht auszuschließen.
 
Zuletzt bearbeitet:
Sollte es am Ende doch tatsächlich am Hostnamen des Servers liegen und die Meldung mit dem lokalen Gerätenamen Windows-cmd-typisch in die vollkommen falsche Richtung gehen (da ist net use sogar ein Extrembeispiel mit Falschmeldungen) und es mit IP problemlos gehen, binde das Laufwerk doch einfach immer mit IP an. Der Hostname des Servers ist doch unerheblich, wenn du eh auf ein Laufwerk mappst.
 
@Raijin Schau mal Post #7 im Thread an, es geht weder mit dem hostnamen, noch mit der IP, je nach dem was gemappt wurde.
 
@Tornhoof NetBIOS und NetBT sind nicht das Selbe... Aber ich korrigiere mich gern: Es ist in der Praxis völlig egal, ob du \\server, \\SERVER oder \\SeRvER eingibst, Windows kommt damit klar.
 
Zuletzt bearbeitet:
@SHIVAno1 Mir schon bewusst dass es nicht das selbe ist, der Link ist ja auch explizit für NetBT ;)
Es gibt halt genug Fälle wo angehängte Logik halt doch Case-Sensitive ist (u.A. Zertifikate).

Mir ist es bewusst das es in der Praxis egal sein sollte.
 
  • Gefällt mir
Reaktionen: SHIVAno1
SHIVAno1 schrieb:
@Raijin Schau mal Post #7 im Thread an, es geht weder mit dem hostnamen, noch mit der IP, je nach dem was gemappt wurde.
qlubtempo schrieb:
Per IP komme ich aber ohne Probleme drauf.
Wobei sich das im Kontext natürlich auch auf die Eingabe im Explorer beziehen kann.

Wie dem auch sei, fakt ist, dass sich die Meldung bezüglich des lokalen Gerätenamens auf den Laufwerksbuchstaben bezieht und nicht auf den Hostnamen oder die IP. Fehler hierbei würden mit "Netwerkpfad nicht gefunden" quittiert werden. Ich denke daher, dass wir zwei prinzipiell dieselbe Ursache vermuten: Ein doppelt angebundenes Laufwerk, wo auch immer es herkommt.
 
  • Gefällt mir
Reaktionen: SHIVAno1
Zurück
Oben