03.08.2023

2038

Auf Servername konnte nicht zugegriffen werden - SRV2022

Hallo,
nach dem Update eines Servers von Server 2016 auf 2022 kommt sporadisch der Fehler

Auf \\Server konnte nicht zugegriffen werden
Vergewissern sie sich, dass der Name richtig ...
Fehlercode 0x80004005

Servername und Pfad sind jedoch korrekt.

Gebe ich die IP des Servers ein komme ich direkt per SMB drauf.
Das Problem betrifft unterschiedliche Clients und auch nur diesen einen Server.

Der Server ist auch DC, auf diesem liegen nur Installationsdaten als Zusatz mit drauf auf die ich dann nicht zugreifen kann.

Dies tritt auch nur bei diesem System und auch nicht immer auf. Starte ich den Client PC neu, kann es direkt wieder funktionieren.

Gruß

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 8038656267

Url: https://administrator.de/forum/auf-servername-konnte-nicht-zugegriffen-werden-srv2022-8038656267.html

Ausgedruckt am: 24.12.2024 um 18:12 Uhr

20 Kommentare

Neuester Kommentar

Hi,
ich tippe mal auf ein Problem in der Namensauflösung.
Schau mal im DNS, ob da mehrere Records für diesen Server sind.

Oder:
Wenn der Client mal wieder nicht mit Servernamen will dann sofort danach eine CMD und Ping auf den Namen starten. Wird dabei die korrekte IP-Adresse ausgegeben?

E.

Zitat von @emeriks:

Hi,
ich tippe mal auf ein Problem in der Namensauflösung.
Schau mal im DNS, ob da mehrere Records für diesen Server sind.

Oder:
Wenn der Client mal wieder nicht mit Servernamen will dann sofort danach eine CMD und Ping auf den Namen starten. Wird dabei die korrekte IP-Adresse ausgegeben?

E.

Hi,
Namensauflösung klappt. Im DNS ist auch nur ein Eintrag vorhanden. (Wäre auch zu einfach gewesen)

Sehe ich das richtig? Du hast da auf einem DC ein Inplace Upgrade von Win2016 auf Win2022 gemacht?

Ja, ist soweit korrekt. Musste bei dem so sein. Bei anderen lief es ohne Probleme.
Das einzige was auftritt ist das SMB Problem, sonst läuft alles Problemlos.

Sind da noch weitere DC im Spiel?
Falls ja:
Mit diesen funktioniert alles? DNS, Replikation usw.

ja, sind noch weitere DC's im Spiel. die laufen problemlos. Das ist ja das was ich nicht verstehe...
Dachte auch erst an DNS, aber die Einträge sehen passend aus.
An dem Standort wo das ist sind 2 DC's die sich ohne Probleme replizieren. (Gerade auch noch mal kontrolliert an einem Bitlocker Schlüssel den er heute morgen geschrieben hat. Der ist auf beiden DC's vorhanden)

Du hast dieses Problem also nur mit Clients an einem bestimmten Standort?
Und Ihr habt mehrere Standorte?

Bei Auftreten:
Clients und dieser Server sind an verschiedenen Standorten?

Servus,
Den DNS Cash mal gelöscht? Da sammelt sich oft was an, und dann sucht er erst da .
Wer ist denn der DNS? was sagt nslookup?

Zitat von @emeriks:

Du hast dieses Problem also nur mit Clients an einem bestimmten Standort?
Und Ihr habt mehrere Standorte?

Bei Auftreten:
Clients und dieser Server sind an verschiedenen Standorten?

Aufgefallen ist es mir bisher nur an dem Standort, wo der Server auch ist. Von zwei anderen Standorten getestet konnte ich zugreifen.

Zitat von @Bingo61:

Servus,
Den DNS Cash mal gelöscht? Da sammelt sich oft was an, und dann sucht er erst da .
Wer ist denn der DNS? was sagt nslookup?

nslookup und auch ping liefern direkt immer das richtige Ergebnis. Den DNS Cache habe ich bisher nicht gelöscht. Müsste ich beim nächsten Auftreten mal testen. Wobei der Server ja auch eine statische IP hat und diese immer die selbe ist...

Interessant...
ich habe hier ein Laptop vorher mit ipconfig /flushdns den cache geleert, das System neu gestartet und gewartet.
Danach habe ich mich angemeldet und direkt \\server eingegeben -> Fehler
Dann habe ich ein ipconfig /Flsuhdns eingegeben und wieder \\erver eingegeben -> Dann ging es.

Probier mal mit \\server. und einem Punkt am Ende. Sobald man einen Punkt hinter den Servername setzt wird er richtig aufgeloest. Habe ich auch Zeitweise an einem Windows 2022 Server in Verbindung mit Windows 11 Clients festgestellt.

Das werde ich noch mal testen. Danke für den Tipp.

Zitat von @killtec:
Interessant...
ich habe hier ein Laptop vorher mit ipconfig /flushdns den cache geleert, das System neu gestartet und gewartet.
Danach habe ich mich angemeldet und direkt \\server eingegeben -> Fehler
Dann habe ich ein ipconfig /Flsuhdns eingegeben und wieder \\erver eingegeben -> Dann ging es.

Du hättest vor dem /flushdns mal in den DNS-Cache schauen sollen.

ipconfig /displaydns

Denn das von Dir Beschriebene ist oft ein Hinweis darauf, dass es im DNS mehrere Records mit verschiedenen IP-Adressen für den gleichen FQDN gibt und man durch Round Robin jedes Mal eine andere Adresse bekommt.
Falls das eine AD-integrierte Zone ist, dann schau mal mit ADSIEDIT nach, ob da nicht möglicherweise 2 Objekte für diesen Namen sind, aber in der DNS-MMC nur ein Record angezeigt wird. Sowas hatte ich selbst schon mal!

Edit:
In allen Replikaten (auf allen DC) einzeln nachsehen!

Edit 2:
DC=DomainDnsZones,DC=domain,DC=tld
oder
DC=ForestDnsZones,DC=rootdomain,DC=tld

Zitat von @Starmanager:
Probier mal mit \\server. und einem Punkt am Ende. Sobald man einen Punkt hinter den Servername setzt wird er richtig aufgeloest. Habe ich auch Zeitweise an einem Windows 2022 Server in Verbindung mit Windows 11 Clients festgestellt.

Das würde aber auf ein Problem mit der Auflösung von kurzen Namen hinweisen. Also die hinterlegten alternativen DNS-Suffixe.
Sowas kompensiert man sowieso am sichersten, indem man den Server mit FQDN angibt. Davon bin ich jetzt ausgegangen, dass @killtec das so gemacht hat!

Zitat von @emeriks:

Nein, war nur \\server nicht \\server.domain.tld

Zitat von @emeriks:

Du hättest vor dem /flushdns mal in den DNS-Cache schauen sollen.

ipconfig /displaydns

Im ForestDNS ist der Eintrag nur einmal drin,
im DomainDNSZones sehe ich nicht mal die DNS Zone...

Das mit dem FQDN habe ich eben mal gegen getestet.

Hier ist mal der Eintrag vom DNS Cache:

    Eintragsname . . . . . : _ldap._tcp.Standort._sites.domain.tld
    Eintragstyp  . . . . . : 33
    Gültigkeitsdauer . . . : 63
    Datenl„nge . . . . . . : 16
    Abschnitt. . . . . . . : Antwort
    SRV-Eintrag . . . . . : servername.domain.tld
                            0
                            100
                            389
							
    Eintragsname . . . . . : servername.domain.tld
    Eintragstyp  . . . . . : 1
    Gltigkeitsdauer . . . : 63
    Datenl„nge . . . . . . : 4
    Abschnitt . . . . . . : Weiteres
    (Host-)A-Eintrag  . . : 10.0.0.6
	
    servername.domain.tld
    ----------------------------------------
    Eintragsname . . . . . : servername.domain.tld
    Eintragstyp  . . . . . : 1
    Gltigkeitsdauer . . . : 2074
    Datenl„nge . . . . . . : 4
    Abschnitt. . . . . . . : Antwort
    (Host-)A-Eintrag  . . : 10.0.0.6

Könnte es ggfs. ein NETBIOS Problem / Fehler sein??

Der Zugriff direkt auf die FQDN geht.

Zitat von @killtec:
im DomainDNSZones sehe ich nicht mal die DNS Zone...

Das ist korrekt so, wenn die Zone auf alle Domaincontroller des Forest repliziert wird.

Wenn es mit FQDN immer geht, dann könntest Du ja erst einmal den pragmatischen Weg gehen und die Zugriffe auf FQDN umstellen. Dann hättest Du Ruhe und kannst weitersuchen.

Zitat von @emeriks:

Zitat von @killtec:
im DomainDNSZones sehe ich nicht mal die DNS Zone...

Dadurch das da primär nur "zeugs" für mich drauf lieg (Installationsdaten) ist das nicht so kritisch von der Zeit her.
Bin die nächsten zwei Wochen eh unterwegs, von daher wird die Lösung noch ein bisschen in Anspruch nehmen.

Wäre denn der Gedankengang Richtung NETBIOS überhaupt richtig?

Du könntest zumindest mal versuchen, ob es etwas bringt, wenn Du NetBIOS in den TCP/IP-Konfigurationen von Server und Clients explizit aktivierst oder deaktivierst.

NIC -> Eigenschaften von IPv4 --> Erweitert --> WINS --> NetBIOS-Einstellungen
Das steht standardmäßig auf "Standard".