16
Domain Join und Zugriff auf Server per SMB ohne Funktion
Hallo zusammen,
ich arbeite seit 10 Jahren in der IT-Branache und konnte bisher alle Probleme lösen. Nun habe ich aber seit ein paar Tagen einen Fehler, den ich einfach nicht gelöst bekomme. Den Fehler habe ich natürlich schonmal gegoogelt, aber ich nichts passendes gefunden. Vielleicht könnt ihr mir weiterhelfen, das würde mich sehr freuen und ich wäre sehr dankbar.
Aufbau des Netzwerk:
In meinem kleinen Netzwerk habe ich noch einen Windows Server 2012 R2, 2 Linux ThinClients und einen Windows 10 Pro PC.
Als Switch habe ich einen kleinen Netgear 8Port Gigabit Switch.
Server:
- Domain Controller
- File Server
- Print Server
- Terminal Server
- DHCP
IP: 192.168.2.10
SUB: 255.255.255.0
Gateway: 192.168.2.1 (FritzBox)
DNS: 192.168.2.10 / 127.0.0.1
Windows 10 PC:
Version: 20H2
IP: 192.168.2.200
SUbnet: 255.255.255.0
Gateway: 192.168.2.1
DNS: 192.168.2.10
Zum Fehler:
Ich kann von dem Windows 10 PC keine Netzwerkfreigabe vom Server aufrufen. Es kommt die Meldung "Auf \\192.168.2.10 konnte nicht zugriffen werden". Optionen dazu sind Diagnose, die keine Ergbenisse bringt, und Abbrechen. Ebenso kann ich mit diesem PC keinen Domain Join durchführen. Es kommt die Meldung "Bei dem Versuch der Domäne beizutreten, trat der folgende Fehler auf: Der angegebene Netzwerkname ist nicht mehr verfügbar". Allerdings kann der PC noch die Netzwerkfreigaben von der QNAP NAS öffnen. PING, Tracert und nslookup habe ich schon ausgeführt, alle geben ein positives Ergebnis zurück. SMB2 ist ebenfalls aktiviert und SMB1 deaktiviert, sowohl als auf der CLient als auch auf der Server Seite. Neustart der beiden Devices habe ich natürlich schon durch. Neuere Windows Updates gibt es auch keine. Firewall wurde auf beiden Geräten auch schon voll deaktiviert. AntiVirus ist auf dem Server 2012 R2 zur Zeit nicht installiert.
Fehler auftritt:
Der PC befand sich schon in der Domäne, d.h. es hatte schon mal funktioniert, er lief auch einige Tage. Dann habe ich einen Neustart gemacht, weil ich einen SIP Client (BRIA) installiert habe. Danach fing alles. Zuerst hatte ich eine Meldung in der Netzwerkkarte, das der Zugriff nicht authorisiert wäre. Diese Meldung ist allerdings weg. Den SIP Client habe ich wieder deinstalliert.
Was wurde am PC verändert?
Weil ich dachte , dass der Fehler sich beheben würde, wenn ich den PC aus der Domäne rausnehmen und wieder neu hinzufüge, ist der PC nicht mehr in der Domäne. Das Computerkonto wurde aber auch im AD nicht deaktiviert, dies musste ich manuell machen. Stand jetzt ist der PC in keiner Domäne.
Im Ereignislog konnte ich keinen entsprechenden Fehler finden. Vielleicht habe ich auch nicht nach dem richtigen gesucht.
Ich hoffe, ich habe nichts vergessen aufzuzählen.
Gruß
SaschaDrummer
PS: Das ist mein erster Eintrag hier, seit nachsichtig mit mir.
ich arbeite seit 10 Jahren in der IT-Branache und konnte bisher alle Probleme lösen. Nun habe ich aber seit ein paar Tagen einen Fehler, den ich einfach nicht gelöst bekomme. Den Fehler habe ich natürlich schonmal gegoogelt, aber ich nichts passendes gefunden. Vielleicht könnt ihr mir weiterhelfen, das würde mich sehr freuen und ich wäre sehr dankbar.
Aufbau des Netzwerk:
In meinem kleinen Netzwerk habe ich noch einen Windows Server 2012 R2, 2 Linux ThinClients und einen Windows 10 Pro PC.
Als Switch habe ich einen kleinen Netgear 8Port Gigabit Switch.
Server:
- Domain Controller
- File Server
- Print Server
- Terminal Server
- DHCP
IP: 192.168.2.10
SUB: 255.255.255.0
Gateway: 192.168.2.1 (FritzBox)
DNS: 192.168.2.10 / 127.0.0.1
Windows 10 PC:
Version: 20H2
IP: 192.168.2.200
SUbnet: 255.255.255.0
Gateway: 192.168.2.1
DNS: 192.168.2.10
Zum Fehler:
Ich kann von dem Windows 10 PC keine Netzwerkfreigabe vom Server aufrufen. Es kommt die Meldung "Auf \\192.168.2.10 konnte nicht zugriffen werden". Optionen dazu sind Diagnose, die keine Ergbenisse bringt, und Abbrechen. Ebenso kann ich mit diesem PC keinen Domain Join durchführen. Es kommt die Meldung "Bei dem Versuch der Domäne beizutreten, trat der folgende Fehler auf: Der angegebene Netzwerkname ist nicht mehr verfügbar". Allerdings kann der PC noch die Netzwerkfreigaben von der QNAP NAS öffnen. PING, Tracert und nslookup habe ich schon ausgeführt, alle geben ein positives Ergebnis zurück. SMB2 ist ebenfalls aktiviert und SMB1 deaktiviert, sowohl als auf der CLient als auch auf der Server Seite. Neustart der beiden Devices habe ich natürlich schon durch. Neuere Windows Updates gibt es auch keine. Firewall wurde auf beiden Geräten auch schon voll deaktiviert. AntiVirus ist auf dem Server 2012 R2 zur Zeit nicht installiert.
Fehler auftritt:
Der PC befand sich schon in der Domäne, d.h. es hatte schon mal funktioniert, er lief auch einige Tage. Dann habe ich einen Neustart gemacht, weil ich einen SIP Client (BRIA) installiert habe. Danach fing alles. Zuerst hatte ich eine Meldung in der Netzwerkkarte, das der Zugriff nicht authorisiert wäre. Diese Meldung ist allerdings weg. Den SIP Client habe ich wieder deinstalliert.
Was wurde am PC verändert?
Weil ich dachte , dass der Fehler sich beheben würde, wenn ich den PC aus der Domäne rausnehmen und wieder neu hinzufüge, ist der PC nicht mehr in der Domäne. Das Computerkonto wurde aber auch im AD nicht deaktiviert, dies musste ich manuell machen. Stand jetzt ist der PC in keiner Domäne.
Im Ereignislog konnte ich keinen entsprechenden Fehler finden. Vielleicht habe ich auch nicht nach dem richtigen gesucht.
Ich hoffe, ich habe nichts vergessen aufzuzählen.
Gruß
SaschaDrummer
PS: Das ist mein erster Eintrag hier, seit nachsichtig mit mir.
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: 664964
Url: https://administrator.de/contentid/664964
Ausgedruckt am: 24.11.2024 um 17:11 Uhr
16 Kommentare
Neuester Kommentar
Ich bin mir nicht ganz sicher ob das noch aktuell ist, aber vor etwa 2 Jahren oder 3 gab es dazu einen MS.Docs Artikel.
Darin ging es um die fehlende Abwärtskompatibilität zu SMB2 oder so von w10 ab Version 1803 (??). Und unter anderem um einen Patch TLS betreffend.
Ist nur noch ganz dunkel. Seit Server 2016 habe ich mich nicht mehr darum gekümmert. Könnte da der Zusammenhang liegen?
Darin ging es um die fehlende Abwärtskompatibilität zu SMB2 oder so von w10 ab Version 1803 (??). Und unter anderem um einen Patch TLS betreffend.
Ist nur noch ganz dunkel. Seit Server 2016 habe ich mich nicht mehr darum gekümmert. Könnte da der Zusammenhang liegen?
Hallo,
Konto deaktiviert oder gelöscht? Wenn deaktiviert wieder aktivieren vor dem JOIN.
ggf Konto löschen und PC auch auf Workgroup "forcen", danach join nochmal versuchen
und überprüfen ob auf dem Server und/oder Client ein Reboot ansteht auf Grund von Windows-Updates
Zu SMB hilft vlt. das hier:
https://docs.microsoft.com/de-de/windows-server/storage/file-server/trou ...
Gutes Nächtle
kh
Konto deaktiviert oder gelöscht? Wenn deaktiviert wieder aktivieren vor dem JOIN.
ggf Konto löschen und PC auch auf Workgroup "forcen", danach join nochmal versuchen
und überprüfen ob auf dem Server und/oder Client ein Reboot ansteht auf Grund von Windows-Updates
Zu SMB hilft vlt. das hier:
https://docs.microsoft.com/de-de/windows-server/storage/file-server/trou ...
Gutes Nächtle
kh
Hi,
was spricht denn ein ipconfig /all auf dem Windows 10 Client?
Ich vermute, dir spuckt IP V6 rein
was spricht denn ein ipconfig /all auf dem Windows 10 Client?
Ich vermute, dir spuckt IP V6 rein
Zitat von @Mosurama:
Hi,
was spricht denn ein ipconfig /all auf dem Windows 10 Client?
Ich vermute, dir spuckt IP V6 rein
Hi,
was spricht denn ein ipconfig /all auf dem Windows 10 Client?
Ich vermute, dir spuckt IP V6 rein
Oha! Der ist auch gut!
Moin,
mich stört zuallererst dies hier:
Mal ganz abgesehen vom Sicherheitsaspekt (TS-Benutzer arbeiten auf dem DC), kann das erhebliche Seiteneffekte nach sich ziehen und das auch erst nach einer Weile des vermeintlich problemlosen Betriebs.
Für die Terminalserver-Benutzer wird ja auch noch deren benötigte Software installiert sein, die voraussichtlich auch nichts auf einem DC zu suchen hat.
Wenn das AD nicht schon so stark beschädigt ist, ist es zum,indest zu spät, das noch aufzulösen.
Gruß
cykes
mich stört zuallererst dies hier:
Server:
- Domain Controller
[...]
- Terminal Server
auf einer Kiste.- Domain Controller
[...]
- Terminal Server
Mal ganz abgesehen vom Sicherheitsaspekt (TS-Benutzer arbeiten auf dem DC), kann das erhebliche Seiteneffekte nach sich ziehen und das auch erst nach einer Weile des vermeintlich problemlosen Betriebs.
Für die Terminalserver-Benutzer wird ja auch noch deren benötigte Software installiert sein, die voraussichtlich auch nichts auf einem DC zu suchen hat.
Wenn das AD nicht schon so stark beschädigt ist, ist es zum,indest zu spät, das noch aufzulösen.
Gruß
cykes
Ethernet-Adapter Ethernet:
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Gigabit-Netzwerkverbindung Intel(R) I210
Physische Adresse . . . . . . . . : 9C-5C-8E-4F-5C-A0
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja
Verbindungslokale IPv6-Adresse . : fe80::5404:a387:5908:7f2f%12(Bevorzugt)
IPv4-Adresse . . . . . . . . . . : 192.168.2.10(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . : 192.168.2.1
DHCPv6-IAID . . . . . . . . . . . : 211573902
DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-1E-99-18-B2-9C-5C-8E-4F-5C-A0
DNS-Server . . . . . . . . . . . : ::1
192.168.2.10
127.0.0.1
NetBIOS über TCP/IP . . . . . . . : Aktiviert
IPv6 hatte ich schon Testweise deaktiviert.
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Gigabit-Netzwerkverbindung Intel(R) I210
Physische Adresse . . . . . . . . : 9C-5C-8E-4F-5C-A0
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja
Verbindungslokale IPv6-Adresse . : fe80::5404:a387:5908:7f2f%12(Bevorzugt)
IPv4-Adresse . . . . . . . . . . : 192.168.2.10(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . : 192.168.2.1
DHCPv6-IAID . . . . . . . . . . . : 211573902
DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-1E-99-18-B2-9C-5C-8E-4F-5C-A0
DNS-Server . . . . . . . . . . . : ::1
192.168.2.10
127.0.0.1
NetBIOS über TCP/IP . . . . . . . : Aktiviert
IPv6 hatte ich schon Testweise deaktiviert.
Zitat von @GarfieldBonn:
Hallo,
Konto deaktiviert oder gelöscht? Wenn deaktiviert wieder aktivieren vor dem JOIN.
ggf Konto löschen und PC auch auf Workgroup "forcen", danach join nochmal versuchen
und überprüfen ob auf dem Server und/oder Client ein Reboot ansteht auf Grund von Windows-Updates
Zu SMB hilft vlt. das hier:
https://docs.microsoft.com/de-de/windows-server/storage/file-server/trou ...
Gutes Nächtle
kh
Hallo,
Konto deaktiviert oder gelöscht? Wenn deaktiviert wieder aktivieren vor dem JOIN.
ggf Konto löschen und PC auch auf Workgroup "forcen", danach join nochmal versuchen
und überprüfen ob auf dem Server und/oder Client ein Reboot ansteht auf Grund von Windows-Updates
Zu SMB hilft vlt. das hier:
https://docs.microsoft.com/de-de/windows-server/storage/file-server/trou ...
Gutes Nächtle
kh
Das Konto habe ich zuerst manuell deaktiviert und nachdem ich den PC umbenannt hatte im AD gelöscht.
Den Microsoft Artikel habe ich mir auch angeschaut. Über Powershell habe ich schon die SMB ausgelesen. Da ist es wie oben beschrieben.
SMB1 ist deaktiviert und SMB2 aktiviert.
Ich bin aber jetzt nochmal hergegangen und habe SMB1 aktiviert. Nun funktioniert der Zugriff auf das Share wieder, SMB1 ist auf dem Client aber weiterhin deaktiviert. Das kann aber nicht die Lösung sein. Ich hätte das gerne weiterhin deaktiviert.
Mit kommt es sovor als würde der Client SMB1 erzwingen.
Zitat von @cykes:
Moin,
mich stört zuallererst dies hier:
Mal ganz abgesehen vom Sicherheitsaspekt (TS-Benutzer arbeiten auf dem DC), kann das erhebliche Seiteneffekte nach sich ziehen und das auch erst nach einer Weile des vermeintlich problemlosen Betriebs.
Für die Terminalserver-Benutzer wird ja auch noch deren benötigte Software installiert sein, die voraussichtlich auch nichts auf einem DC zu suchen hat.
Wenn das AD nicht schon so stark beschädigt ist, ist es zum,indest zu spät, das noch aufzulösen.
Gruß
cykes
Moin,
mich stört zuallererst dies hier:
Server:
- Domain Controller
[...]
- Terminal Server
auf einer Kiste.- Domain Controller
[...]
- Terminal Server
Mal ganz abgesehen vom Sicherheitsaspekt (TS-Benutzer arbeiten auf dem DC), kann das erhebliche Seiteneffekte nach sich ziehen und das auch erst nach einer Weile des vermeintlich problemlosen Betriebs.
Für die Terminalserver-Benutzer wird ja auch noch deren benötigte Software installiert sein, die voraussichtlich auch nichts auf einem DC zu suchen hat.
Wenn das AD nicht schon so stark beschädigt ist, ist es zum,indest zu spät, das noch aufzulösen.
Gruß
cykes
Das es nicht schön weiß ich auch, aber leider geht manchmal nicht anders. Davon abgesehen hatte Microsoft dafür einen Foundation auf den Markt gebracht. Der User kann aufgrund seiner lesenden Rechte im AD nichts kaputt machen und die Software die drauf installiert ist nicht mal Datenbank basierend.
Ich habe aber auch die Rollen geprüft, die sind alle in Ordnung.
Wieso steht ipv4 auf autoconfig ?
Die IP wird auf dem Server statisch zugewiesen.
Der Fehler lag an dem Programm THeorg auch dem Client PC. Dort wurde zur Kompatibilität SMB1 erzwungen. Da es nicht auf dem Server aktiviert war funktionierte es natürlich auch nicht.
Eine neue Version der Software ist aber schon im Anflug.
Eine neue Version der Software ist aber schon im Anflug.
Versuch doch mal:
a) nicht auf jeden Beitrag separat zu antworten
b) Vollzitate möglichst zu vermeiden
Das ist eine (gefährliche) Ausrede. Das mag noch aus Interesse bzw. Spieltrieb in einer Heim- bzw. Testumgebung OK sein, aber was sagst Du einem Kunden, bei dem diese Konfiguration nach eine Zeit x Fehler verursacht, die zur Folge haben, dass 10, 20, 50, 100 usw. Mitarbeiter nicht arbeiten können. Zahlst Du dann den Ausfall?
a) nicht auf jeden Beitrag separat zu antworten
b) Vollzitate möglichst zu vermeiden
Das ist eine (gefährliche) Ausrede. Das mag noch aus Interesse bzw. Spieltrieb in einer Heim- bzw. Testumgebung OK sein, aber was sagst Du einem Kunden, bei dem diese Konfiguration nach eine Zeit x Fehler verursacht, die zur Folge haben, dass 10, 20, 50, 100 usw. Mitarbeiter nicht arbeiten können. Zahlst Du dann den Ausfall?
DHCP steht auf AUS. Was soll da zugewiesen werden ?
Nein das ist es nicht. Einen Kunden der 5 Mitarbeiter hat, für jeden Dienst einen einzelenen Server zu verkaufen wird sehr schwierig, fast sogar nicht machbar. Solltest du es allerdings schaffen diesem Kunden einen Server mit 2 Windows Server Std. zu verkaufen, dann hast du mein Respekt. Allerdings ist es eher meiner Erfahrung nach so, dass es der Kunde ablehnt. Der Kunde unterschreibt mir aber das ich ihn aufgeklärt habe.
Richtig, der Server bekommt auch keine IP über den DHCP zugewiesen. Das wäre ja fatal.
Zitat von @SaschaDrummer:
Nein das ist es nicht. Einen Kunden der 5 Mitarbeiter hat, für jeden Dienst einen einzelenen Server zu verkaufen wird sehr schwierig, fast sogar nicht machbar.
Du hast aber schon mal etwas von Virtualisierung gehört?Nein das ist es nicht. Einen Kunden der 5 Mitarbeiter hat, für jeden Dienst einen einzelenen Server zu verkaufen wird sehr schwierig, fast sogar nicht machbar.
Solltest du es allerdings schaffen diesem Kunden einen Server mit 2 Windows Server Std. zu verkaufen, dann hast du mein Respekt.
Alles eine Frage der (anfänglichen) Kommunikation, mit einer aktuellen Windows Server Lizenz kannst Du per Hyper-V den Host und 2 VMs installieren. Dann kommen nur noch die RDS CALs hinzu, die man aber sowieso benötigt.Verargumentieren kann man das zusätzlich damit, dass Drittanbieter und Microsoft keinen Support leisten, wenn ihre Dienste auf einem AD laufen. VMs machen auch u.a. das Backup einfacher.
Allerdings ist es eher meiner Erfahrung nach so, dass es der Kunde ablehnt. Der Kunde unterschreibt mir aber das ich ihn aufgeklärt habe.
Mit der Unterschrift bist Du aber nicht ganz aus der Sache raus, der Kunde sollte auch wissen, dass diese - ich nenne es mal Bastellöung - i.d.R. unsupported ist, Du leistest die Beratung und sprichst die Empfehlung aus, spätestens wenn dann die Katasthrophe passiert, ist das erstmal vergessen, schlimmer noch (und das passiert häufiger als man denkt) wenn der Kunde über Dritte erfährt, was er da produktiv betreibt.Nur mal ein konkretes Beispiel: einer der Terminalserver-Benutzer fängt sich einen Kryptotrojaner ein - und jetzt Du ...
Gruß
cykes
1
Ja natürlich habe ich das. Leider darf man einen Foundation Server aber nicht Virtualisieren und ich bräuchte drei VMs um die ganze Sache ordnetlich abzubilden, ergo 2 Standard Lizenz (1800 Euro).
Aber um das Thema mal abzuschließen.
Ich weiß was du meinst und kann das auch voll nachvollziehen. Ich würde es am liebsten auch immer so machen. Leider ist das aber auf Grund der Kundenmeinung nicht immer möglich. Damit muss er auch mit den Konsquenzen leben. Wenn er jetzt das Update auf Windows Server 2019 bekommt gibt es sowie nur noch Standard, mit Essentials geht keine Remotedesktopunterstützung.
Verargumentieren kann man das zusätzlich damit, dass Drittanbieter und Microsoft keinen Support leisten, wenn ihre Dienste auf einem AD laufen. VMs machen auch u.a. das Backup einfacher.
Selbst die Kommuniktaion ist meistens umsonst. Ich habe mit schon oft den Mund wund geredet. Aber wie es immer so ist, bei diesen Kunden passiert meistens nichts.Mit der Unterschrift bist Du aber nicht ganz aus der Sache raus, der Kunde sollte auch wissen, dass diese - ich nenne es mal Bastellöung - i.d.R. unsupported ist, Du leistest die Beratung und sprichst die Empfehlung aus, spätestens wenn dann die Katasthrophe passiert, ist das erstmal vergessen, schlimmer noch (und das passiert häufiger als man denkt) wenn der Kunde über Dritte erfährt, was er da produktiv betreibt.
Das es vergessen wird ist erstmal richtig. Nur habe ich diese Ding aufgelistet und habe auch kein Problem damit dem Kunden das so rüber zu bringen.Nur mal ein konkretes Beispiel: einer der Terminalserver-Benutzer fängt sich einen Kryptotrojaner ein - und jetzt Du ...
Ja du hast Recht. Das ist ein Risikofaktor, aber das ist leider nicht möglich. Der User hat nicht die Möglichkeit auf irgendeine Weise auf das Internet zuzugreifen. E-Mails z.B. werden nicht benötigt. Es wird nur eine Verwaltungssoftware benutzt, die nicht auf das Internet zugreift (nach Hause telefoniert).Aber um das Thema mal abzuschließen.
Ich weiß was du meinst und kann das auch voll nachvollziehen. Ich würde es am liebsten auch immer so machen. Leider ist das aber auf Grund der Kundenmeinung nicht immer möglich. Damit muss er auch mit den Konsquenzen leben. Wenn er jetzt das Update auf Windows Server 2019 bekommt gibt es sowie nur noch Standard, mit Essentials geht keine Remotedesktopunterstützung.
