16
W2003Server kein Zugriff über NetBIOS-Name
Bei einem W2003 Server der als PDC arbeitet, habe ich eine Freigabe eingerichtet. Die liegt auf C:\Test. Ich habe als Zugriffsberechtigungen sowohl im NTFS als auch in der Freigabe "Jeder" auf "Vollzugriff" (ist nur zum Testen). Passwörter sind demzufolge keine gesetzt. Die Freigabe heißt auch "Test"
Wenn ich jetzt am Server selbst per Explorer auf \\SERVER\Test zugreife klappt das problemlos (angemeldet als Domänen-Admin). Keine Passwortabfrage und ich kann lesen, schreiben, löschen, alles.
Wenn ich aber an einen Netzwerk-Client gehe, mich dort als Domänen-Admin anmelde und versuche auf \\SERVER\Test zuzugreifen, dann kommt immer das Passwort-Abfragefenster. Da kann ich eingeben was ich will, es erscheint immer wieder. Gebe ich im Explorer jedoch die FQDN \\SERVER.DOMAIN.TLD\Test an, so kann ich auch hier ganz normal zugreifen.
Über net view sieht das genauso aus: net view \\SERVER listet nichts auf, net view \\SERVER.domain.tld dagegen alles.
Ich vermute einen Fehler im NetBIOS. Jedoch kann ich am Server keine Probleme feststellen. Keine verdächtigen Einträge im Eventlog. NetBIOS für die Netzwerkkarte ist aktiviert. Firewall ist off.
Das Problem ist, daß sich durch diesen Fehler kein Netzdrucker mehr ansprechen läßt und die Ordnerumleitungen für die Eigenen Dateien ebenso ins Leere laufen und Fehler melden.
Wenn ich jetzt am Server selbst per Explorer auf \\SERVER\Test zugreife klappt das problemlos (angemeldet als Domänen-Admin). Keine Passwortabfrage und ich kann lesen, schreiben, löschen, alles.
Wenn ich aber an einen Netzwerk-Client gehe, mich dort als Domänen-Admin anmelde und versuche auf \\SERVER\Test zuzugreifen, dann kommt immer das Passwort-Abfragefenster. Da kann ich eingeben was ich will, es erscheint immer wieder. Gebe ich im Explorer jedoch die FQDN \\SERVER.DOMAIN.TLD\Test an, so kann ich auch hier ganz normal zugreifen.
Über net view sieht das genauso aus: net view \\SERVER listet nichts auf, net view \\SERVER.domain.tld dagegen alles.
Ich vermute einen Fehler im NetBIOS. Jedoch kann ich am Server keine Probleme feststellen. Keine verdächtigen Einträge im Eventlog. NetBIOS für die Netzwerkkarte ist aktiviert. Firewall ist off.
Das Problem ist, daß sich durch diesen Fehler kein Netzdrucker mehr ansprechen läßt und die Ordnerumleitungen für die Eigenen Dateien ebenso ins Leere laufen und Fehler melden.
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: 94753
Url: https://administrator.de/forum/w2003server-kein-zugriff-ueber-netbios-name-94753.html
Ausgedruckt am: 16.02.2025 um 22:02 Uhr
16 Kommentare
Neuester Kommentar
Vermutlich hast du dir deine Frage gerade selbst richtig beantwortet. Das die Freigabe über den FQDN aufrufbar ist sagt ja ganz klar aus, dass dein DNS korrekt funktioniert.
Wenn deine Freigabe über die Netzwerkumgebung über den (NetBIOS-)Computernamen nicht gefunden oder aufgelöst wird, liegt es an WINS bzw. an der Übersetzung NetBIOS zu TCP/IP.
Du könntest das Problem entweder dadurch lösen indem du einen WINS-Server installierst und konfigurierst (dadurch schaffst du gleichzeitig auch eine Sicherheit/Redundanz falls DNS mal ausfallen sollte) oder aber in den Eigenschaften deines Netzwerkadapters->Eigenschaften von TCP/IP->Erweitert->Registerreiter WINS->NetBIOS-Einstellung->"NetBIOS über TCP/IP aktivieren" anklicken und alle Fenster mit OK wieder schließen.
Wenn deine Freigabe über die Netzwerkumgebung über den (NetBIOS-)Computernamen nicht gefunden oder aufgelöst wird, liegt es an WINS bzw. an der Übersetzung NetBIOS zu TCP/IP.
Du könntest das Problem entweder dadurch lösen indem du einen WINS-Server installierst und konfigurierst (dadurch schaffst du gleichzeitig auch eine Sicherheit/Redundanz falls DNS mal ausfallen sollte) oder aber in den Eigenschaften deines Netzwerkadapters->Eigenschaften von TCP/IP->Erweitert->Registerreiter WINS->NetBIOS-Einstellung->"NetBIOS über TCP/IP aktivieren" anklicken und alle Fenster mit OK wieder schließen.
Wenn es doch so einfach wäre 
Ich kann den NetBIOS-Namen nämlich problemlos aus dem Netz anpingen und NetBIOS in der Abteilung WINS ist aktiviert. Dort ist folgendes eingestellt:
WINS-Adressen: [IP des Servers]
LMHOSTS-Abfrage aktivieren: Ja
NetBIOS-Einstellung: NetBIOS über TCP/IP aktivieren
Alle anderen Windows-Hosts im Netz sind problemlos über ihre NetBIOS-Namen erreichbar.
dcdiag meldet keine Fehler.
Das Ganze ist auch nicht bei einem neu installierten Server passiert sondern bei einem, der schon ne ganze Weile läuft und das bisher ohne Probleme.
Einen wichtigen Punkt habe ich im Eingangspost noch vergessen: Nicht alle Domänen-User sind von dem Problem betroffen. Drucken können zwar alle nicht, aber manche können sehr wohl noch über den NetBIOS-Namen auf die Shares vom Server zugreifen.
Ich kann den NetBIOS-Namen nämlich problemlos aus dem Netz anpingen und NetBIOS in der Abteilung WINS ist aktiviert. Dort ist folgendes eingestellt:
WINS-Adressen: [IP des Servers]
LMHOSTS-Abfrage aktivieren: Ja
NetBIOS-Einstellung: NetBIOS über TCP/IP aktivieren
Alle anderen Windows-Hosts im Netz sind problemlos über ihre NetBIOS-Namen erreichbar.
dcdiag meldet keine Fehler.
Das Ganze ist auch nicht bei einem neu installierten Server passiert sondern bei einem, der schon ne ganze Weile läuft und das bisher ohne Probleme.
Einen wichtigen Punkt habe ich im Eingangspost noch vergessen: Nicht alle Domänen-User sind von dem Problem betroffen. Drucken können zwar alle nicht, aber manche können sehr wohl noch über den NetBIOS-Namen auf die Shares vom Server zugreifen.
Tricky! Auf jeden Fall faszinierend!
Okay, wenns nicht WINS ist, dann wäre meine nächste Überlegung ein expliziter Host (A)-Eintrag in der primären DNS-Zone für den/die Drucker (sofern nicht schon vorhanden) und/oder Löschung des DNS-Caches auf dem Server bzw. einen ipconfig /flushdns auf den problematischen Clients. Möglicherweise hilft auf den Clients auch ein manueller Eintrag in der Datei "lmhosts".
Ein Blick in das WINS-SnapIn des Servers offenbart vielleicht auch interessante Einblicke?! Mach mal in WINS einen Rechtsklick auf "Aktive Registrierungen", dann auf 'Datensätze anzeigen' und anschließend einfach nur auf den Button 'Suche starten' klicken. Schau doch mal ob da irgendwelche (fehlerhafte?) Einträge drin sind oder ob da Einträge generell fehlen.
Okay, wenns nicht WINS ist, dann wäre meine nächste Überlegung ein expliziter Host (A)-Eintrag in der primären DNS-Zone für den/die Drucker (sofern nicht schon vorhanden) und/oder Löschung des DNS-Caches auf dem Server bzw. einen ipconfig /flushdns auf den problematischen Clients. Möglicherweise hilft auf den Clients auch ein manueller Eintrag in der Datei "lmhosts".
Ein Blick in das WINS-SnapIn des Servers offenbart vielleicht auch interessante Einblicke?! Mach mal in WINS einen Rechtsklick auf "Aktive Registrierungen", dann auf 'Datensätze anzeigen' und anschließend einfach nur auf den Button 'Suche starten' klicken. Schau doch mal ob da irgendwelche (fehlerhafte?) Einträge drin sind oder ob da Einträge generell fehlen.
Mahlzeit Codehaunter,
werden IP-Adressen per DHCP verteilt?
Clients alle im selben SubNetz, kein Router / Firewall dazwischen?
Was spuckt ein "ipconfig /all" an nem "Problemkind"
und an nem normal funzenden Client aus?
Fragen über Fragen....
salut
werden IP-Adressen per DHCP verteilt?
Clients alle im selben SubNetz, kein Router / Firewall dazwischen?
Was spuckt ein "ipconfig /all" an nem "Problemkind"
und an nem normal funzenden Client aus?
Fragen über Fragen....
salut
Hallo,
guck Dir doch mal die erweiterten Sicherheitseinstellungen von Deinem freigegebenen Ordner an, mitunter gibts da Drehereien zwischen "von oben" vererbten Rechten und händisch dazu gefügten. Die Frage lautet also: Wie sehen die erweiterten Sicherheitsenstellungen, z.B. für den User "Administrator" auf C:\Test aus.
Grüße,
Ralf.
guck Dir doch mal die erweiterten Sicherheitseinstellungen von Deinem freigegebenen Ordner an, mitunter gibts da Drehereien zwischen "von oben" vererbten Rechten und händisch dazu gefügten. Die Frage lautet also: Wie sehen die erweiterten Sicherheitsenstellungen, z.B. für den User "Administrator" auf C:\Test aus.
Grüße,
Ralf.
@absolut2cool4u: flushdns am Server und Client bewirkt bei dem Problem nichts. Im WINS-Plugin gibts für den betreffenden Server folgendei Einträge, die auf die Server-IP zeigen ("Dateiserver", "Workstation", "--__MSBROWSE__-", "Normaler Gruppenname", "Domänencontroller", "Hauptsuchdienst der Domäne" und "Arbeitsgruppe")
@floetenfranz: Die IP-Adressen werden per DHCP vom Problemserver verteilt. Das funktioniert problemlos. Alle Teilnehmer im selben Netz, keine Router, NAT, Proxy oder sonstwas. ipconfig /all sieht bei gesunden und kranken Clients exakt identisch aus, abgesehen von der Client-IP und ich seh da nichts verdächtiges.
@Ricky99: Dann dürfte es doch keinen Unterschied machen ob ich über den NetBIOS-Name oder über den FQDN auf das Share zugreife oder? Vorallem, warum geht der Zugriff über NetBIOS am Server lokal, aber nicht an Netzmaschinen?
EDIT: Interessant auch: In der Netzwerkumgebung -> Arbeitsgruppe taucht der Problemserver zweimal auf. Einmal mit seinem NetBIOS-Namen und darunter einer Freigabe die ich auf dem Server schon lange gelöscht habe. Für diese Freigabe kann ich an einer Netzmaschine keine Eigenschaften aufrufen (Fehlermeldung "Der Server 'SERVER' ist nicht für Remoteanfragen konfiguriert"). Dann taucht der Server ein zweites Mal in der Arbeitsgruppe auf, hier mit seiner langen Beschreibung und dem FQDN als Namen. Darunter sind die gewohnten Shares, die normalerweise über NetBIOS erreichbar wären. Hier kann ich auf die Ordnereigenschaften normal zugreifen.
@floetenfranz: Die IP-Adressen werden per DHCP vom Problemserver verteilt. Das funktioniert problemlos. Alle Teilnehmer im selben Netz, keine Router, NAT, Proxy oder sonstwas. ipconfig /all sieht bei gesunden und kranken Clients exakt identisch aus, abgesehen von der Client-IP und ich seh da nichts verdächtiges.
@Ricky99: Dann dürfte es doch keinen Unterschied machen ob ich über den NetBIOS-Name oder über den FQDN auf das Share zugreife oder? Vorallem, warum geht der Zugriff über NetBIOS am Server lokal, aber nicht an Netzmaschinen?
EDIT: Interessant auch: In der Netzwerkumgebung -> Arbeitsgruppe taucht der Problemserver zweimal auf. Einmal mit seinem NetBIOS-Namen und darunter einer Freigabe die ich auf dem Server schon lange gelöscht habe. Für diese Freigabe kann ich an einer Netzmaschine keine Eigenschaften aufrufen (Fehlermeldung "Der Server 'SERVER' ist nicht für Remoteanfragen konfiguriert"). Dann taucht der Server ein zweites Mal in der Arbeitsgruppe auf, hier mit seiner langen Beschreibung und dem FQDN als Namen. Darunter sind die gewohnten Shares, die normalerweise über NetBIOS erreichbar wären. Hier kann ich auf die Ordnereigenschaften normal zugreifen.
Och Menno, du machst es uns auch schon echt schwierig!
Ich denke aber weiterhin das es an WINS bzw. NetBIOS liegt. Versuch das Problem dann doch mal von der DNS-Seite aus anzugehen. Ruf dir mal dein DNS-SnapIn auf deinem Server auf und dann die Eigenschaften deiner primären DNS-Zone. Aktivier auf dem Registerreiter 'WINS' mal "WINS-Forward-Lookup", evtl. muss du dann noch die entsprechende IP-Adresse dort hinzufügen.
BTW: Der Server ist kein AD-Domänencontroller, nein?
Ich denke aber weiterhin das es an WINS bzw. NetBIOS liegt. Versuch das Problem dann doch mal von der DNS-Seite aus anzugehen. Ruf dir mal dein DNS-SnapIn auf deinem Server auf und dann die Eigenschaften deiner primären DNS-Zone. Aktivier auf dem Registerreiter 'WINS' mal "WINS-Forward-Lookup", evtl. muss du dann noch die entsprechende IP-Adresse dort hinzufügen.
BTW: Der Server ist kein AD-Domänencontroller, nein?
Der Server ist kein AD-Domänencontroller, nein?
Doch ist er. Den Rest probiere ich dann morgen aus. Danke schon mal.
Dann denke ich mal das die Zone auch AD-integriert ist und nur sichere Updates zulässt?! Falls nicht, stell das mal so ein.
Ich kann bei den dynamischen Updates nur wählen zwischen "Keine" und "Nicht sichere und sichere". Was passiert wenn ich keine dynamischen DNS-Updates zulasse?
EDIT: Das mit dem WINS Forward Lookup scheint wirklich was gebracht zu haben. Nach einem Neustart des Clients sieht man unter dem NetBIOS-Namen in der Netzwerkumgebung wieder alle Shares und hat mit den entsprechenden, schon vor dem Problem konfigurierten Rechten Zugriff wie früher.
Die dynamischen DNS-Updates habe ich derzeit auf "Keine" stehen, ist das ok?
Mit einem Aufruf von \\SERVER (also ohne Domain-Angabe) in der Netzwerkumgebung lande ich wieder wie früher auf dem Eintrag mit dem FQDN in der Hostliste. Der Server taucht auch nicht mehr doppelt in der Netzwerkumgebung auf. Das ist schon mal sehr erfreulich.
So ganz ausgestanden scheint das alles aber noch nicht zu sein. Wenn ein Client neu gestartet ist und ich die Netzwerkumgebung das erste Mal öffne, so sehe ich nur eine Liste mit den zuletzt geöffneten Shares. Der Eintrag "Gesamtes Netzwerk" fehlt zunächst. Erst wenn ich in der Adresszeile \\SERVER eingebe, blendet sich die Netzwerkumgebung wieder ein.
Die Drucker-Shares sind aber nach wie vor alle offline
EDIT: Das mit dem WINS Forward Lookup scheint wirklich was gebracht zu haben. Nach einem Neustart des Clients sieht man unter dem NetBIOS-Namen in der Netzwerkumgebung wieder alle Shares und hat mit den entsprechenden, schon vor dem Problem konfigurierten Rechten Zugriff wie früher.
Die dynamischen DNS-Updates habe ich derzeit auf "Keine" stehen, ist das ok?
Mit einem Aufruf von \\SERVER (also ohne Domain-Angabe) in der Netzwerkumgebung lande ich wieder wie früher auf dem Eintrag mit dem FQDN in der Hostliste. Der Server taucht auch nicht mehr doppelt in der Netzwerkumgebung auf. Das ist schon mal sehr erfreulich.
So ganz ausgestanden scheint das alles aber noch nicht zu sein. Wenn ein Client neu gestartet ist und ich die Netzwerkumgebung das erste Mal öffne, so sehe ich nur eine Liste mit den zuletzt geöffneten Shares. Der Eintrag "Gesamtes Netzwerk" fehlt zunächst. Erst wenn ich in der Adresszeile \\SERVER eingebe, blendet sich die Netzwerkumgebung wieder ein.
Die Drucker-Shares sind aber nach wie vor alle offline
Aus Sicherheitsgründen würde ich persönlich immer 'nur sichere' dynamische Updates einstellen. Das geht aber auch nur dann, wenn die primäre Zone Active Directory-integriert ist. Warum ich das empfehle? Ganz einfach:
Dadurch das die Zone AD-integriert ist, greift auch automatisch die AD-Sicherheit - die administrative Verwaltung per Active Directory läßt dir viel mehr Spielraum beim Einstellen von Berechtigungen, außerdem kann die AD (mit allen Informationen) mit NTBACKUP mittels Sichern des Systemstates weggesichert werde.
'Nur sichere' dynamische Updates bedeutet, dass einzig und allein _NUR_ autentifizierte Rechner deiner AD-Domäne ihre Einträge im DNS aktualisieren dürfen (hier speziell: Windows 2000/XP und Server 2000/2003).
Falls aus irgendeinem unbekannten Grund jemand von außerhalb versuchen würde dein Netz zu kompromittieren um einen eigenen Rechner ins DNS einzuschleusen ("Man-in-the-middle"-Attacke) könnte er ganz schön viele Informationen abgreifen. Deshalb nach Möglichkeit 'Nur sichere' einstellen! Das geht natürlich aber auch nur dann, wenn du in den Eigenschaften deiner primären Zone auf dem Registerreiter 'Allgemein' bei "Typ" auch 'Active Directory-integriert' stehen hast. Wenn nicht, dann klick auf "Ändern" und setz unten den Haken bei 'Die Zone in Active Directory speichern ...'.
'Keine' bedeutet: du musst jedes Mal, wenn sich eine IP oder ein Hostname in deinem Netzwerk ändern sollte, die Host (A)-Einträge deiner primären Zone bzw. die PTR-Einträge deiner Reverse-Lookupzone manuell anpassen! Darauf hätte ich persönlich in einem großen Netzwerk keinen Bock.
'Nicht sichere und sichere' Updates ist meinen Augen eher ein unausgegorener Mischmasch: du hättest damit keine 100%ige Kontrolle über deinen DNS-Server (aus o. g. Gründen).
Selbst wenn in deinem Netzwerk noch alte NT-Rechner stehen sollten (die die AD ja nicht kennen), kannst du 'Nur sichere' dynamische Updates verwenden. Dazu musst du nur in deinem DHCP-SnapIn die Eigenschaften des festgelegten Bereichs aufrufen, gehst dann auf den Registerreiter 'DNS' und setzt zusätzlich dort den Haken bei "DNS-A- und PTR-Einträge für DHCP-Clients, die keine Updates anfordern (z. B. Clients, die Windows NT 4.0 ausführen), dynamisch aktualisieren".
Wo wir schon mal beim Thema 'DHCP' sind: Ziehen sich deine Netzwerkdrucker denn auch IP-Adressen von deinem DHCP-Server oder hast du dort statische IPs verwendet?
Dadurch das die Zone AD-integriert ist, greift auch automatisch die AD-Sicherheit - die administrative Verwaltung per Active Directory läßt dir viel mehr Spielraum beim Einstellen von Berechtigungen, außerdem kann die AD (mit allen Informationen) mit NTBACKUP mittels Sichern des Systemstates weggesichert werde.
'Nur sichere' dynamische Updates bedeutet, dass einzig und allein _NUR_ autentifizierte Rechner deiner AD-Domäne ihre Einträge im DNS aktualisieren dürfen (hier speziell: Windows 2000/XP und Server 2000/2003).
Falls aus irgendeinem unbekannten Grund jemand von außerhalb versuchen würde dein Netz zu kompromittieren um einen eigenen Rechner ins DNS einzuschleusen ("Man-in-the-middle"-Attacke) könnte er ganz schön viele Informationen abgreifen. Deshalb nach Möglichkeit 'Nur sichere' einstellen! Das geht natürlich aber auch nur dann, wenn du in den Eigenschaften deiner primären Zone auf dem Registerreiter 'Allgemein' bei "Typ" auch 'Active Directory-integriert' stehen hast. Wenn nicht, dann klick auf "Ändern" und setz unten den Haken bei 'Die Zone in Active Directory speichern ...'.
'Keine' bedeutet: du musst jedes Mal, wenn sich eine IP oder ein Hostname in deinem Netzwerk ändern sollte, die Host (A)-Einträge deiner primären Zone bzw. die PTR-Einträge deiner Reverse-Lookupzone manuell anpassen! Darauf hätte ich persönlich in einem großen Netzwerk keinen Bock.
'Nicht sichere und sichere' Updates ist meinen Augen eher ein unausgegorener Mischmasch: du hättest damit keine 100%ige Kontrolle über deinen DNS-Server (aus o. g. Gründen).
Selbst wenn in deinem Netzwerk noch alte NT-Rechner stehen sollten (die die AD ja nicht kennen), kannst du 'Nur sichere' dynamische Updates verwenden. Dazu musst du nur in deinem DHCP-SnapIn die Eigenschaften des festgelegten Bereichs aufrufen, gehst dann auf den Registerreiter 'DNS' und setzt zusätzlich dort den Haken bei "DNS-A- und PTR-Einträge für DHCP-Clients, die keine Updates anfordern (z. B. Clients, die Windows NT 4.0 ausführen), dynamisch aktualisieren".
Wo wir schon mal beim Thema 'DHCP' sind: Ziehen sich deine Netzwerkdrucker denn auch IP-Adressen von deinem DHCP-Server oder hast du dort statische IPs verwendet?
Also ich fang mal hinten an: Die Drucker laufen alle mit statischen IP-Adressen weil mir das ehrlich gesagt auf den Keks ging daß alle paar Wochen ein Drucker sich ne andere IP gezogen hat und die Leute mich deshalb angebimmelt haben weil das Druckershare am Server auf den falschen IP-Anschluss zeigte. Außerdem gibt es einige WLAN-APs die beherrschen ja gar kein DHCP (Client). Darum habe ich den Adresspool für .100 bis .250 vergeben. Darunter tummeln sich die Drucker und WLANs, darüber die Gateways.
In meinem Netz gibt es zum Glück nur XP Pro Clients und nichts anderes.
Bei dem AD-DNS habe ich jetzt ein kleines Verständnisproblem. Einfach ausgedrückt: Die Benutzeranmeldung läuft ja sozusagen im Userspace, die Abteilung DNS und DHCP im Systemspace. Wenn jetzt kausale Bedingungen des DNS-Handlings von Benutzeranmeldungen abhängig gemacht werden, bedeutet das im Umkehrschluß, daß sich ein Client-Rechner erst dann mit frischen IP-Konfigurationen versorgt wenn sich ein berechtigter Benutzer anmeldet? Was ist dann mit Netzwerkdiensten, die im Systemspace laufen? Die laufen ja dann u.U. aus dem Ruder wenn die IP-Konfig des Client-Rechners zufällig ungültig werden sollte weil das DNS sich ändert. Oder habe ich jetzt was falsch verstanden?
In meinem Netz gibt es zum Glück nur XP Pro Clients und nichts anderes.
Bei dem AD-DNS habe ich jetzt ein kleines Verständnisproblem. Einfach ausgedrückt: Die Benutzeranmeldung läuft ja sozusagen im Userspace, die Abteilung DNS und DHCP im Systemspace. Wenn jetzt kausale Bedingungen des DNS-Handlings von Benutzeranmeldungen abhängig gemacht werden, bedeutet das im Umkehrschluß, daß sich ein Client-Rechner erst dann mit frischen IP-Konfigurationen versorgt wenn sich ein berechtigter Benutzer anmeldet? Was ist dann mit Netzwerkdiensten, die im Systemspace laufen? Die laufen ja dann u.U. aus dem Ruder wenn die IP-Konfig des Client-Rechners zufällig ungültig werden sollte weil das DNS sich ändert. Oder habe ich jetzt was falsch verstanden?
Ich habe jetzt persönlich ein kleines Verständnisproblem was du mit User- u. Systemspace meinst.
Was den DHCP-Ablauf der IP-Release angeht ist die Sache ja technisch klar formuliert:
1. Der (noch IP-lose) Client "brüllt" per Broadcast ins Netz ob da ein DHCP-Server ist von dem er eine IP bekommen könnte, er autentifiziert sich in dieser Phase noch über seine MAC-Adresse.
2. Sofern ein DHCP-Server im Netz steht, sendet dieser ein IP-Adresspaket (mit der Absender-MAC-Adresse) per Broadcast zurück ins Netz und wartet ob es sich ein potentieller Abnehmer dafür meldet.
3. Jetzt merkt der Client: "Hey, die IP-Adresse könnte ich gebrauchen!", und stellt nun eine Anfrage an den Server ob er das Paket bekommen kann.
4. Der DHCP-Server wiederrum emfängt den 'Request' für die Abnahme und teilt nun dem Client die IP-Adresse zu.
5. Der Client übernimmt nun die IP-Adresse gemäß den Voreinstellungen im DHCP-Server (Leasezeiten, etc.)
Damit findet eine (dynamische) Autentifizierung des Clientcomputers statt - an dieser Stelle ist es noch vollkommen unerheblich welcher User sich am System anmeldet.
Darüber hinaus kannst du im DHCP-Adresspool doch auch einen Ausschlussbereich festlegen von IPs die aus dem Pool _nicht_ verteilt werden sollen. Anschließend fügst du dann noch unter 'Reservierungen' eine (oder mehrere) IP-Adresse(n) für den/die Client/s fest (MAC-Adresse des Clients ist ganz wichtig!), und schon haben deine Drucker immer die gleiche IP-Adresse, so, als würdest du sie statisch festlegen. Das funktioniert für alle Geräte gleich (ob WLAN-APs, Drucker, Clients, etc.).
Da sich DHCP und DNS (sofern AD-integriert) ständig 'absprechen' kann es aus technischer Sicht eigentlich gar nicht dazu kommen, dass irgendwas aus dem Ruder läuft.
Die Drucker sollten demnach in der Netzwerkumgebung auf zu sehen sein, u. U. nochmal kontrollieren ob in den Eigenschaften des Druckers auf dem Registerreiter 'Freigabe' auch der Haken gesetzt ist bei "Im Verzeichnis anzeigen".
Was die Ordnerumleitung für die Eigenen Dateien angeht wirds schon etwas komplizierter. Habe ich in meiner Domäne auch versucht einzurichten, bislang aber noch nicht hinbekommen. Grundsätzlich legt man das ja per Gruppenrichtlinie fest. Wichtig ist aber vor allem das dafür DNS 100%ig läuft.
Schau dir dazu doch einfach mal folgende Links an:
http://technet2.microsoft.com/windowsserver/de/library/42607d0b-5d44-4f ...
http://www.wintotal.de/Artikel/w2003server4/w2003server4.php
Was den DHCP-Ablauf der IP-Release angeht ist die Sache ja technisch klar formuliert:
1. Der (noch IP-lose) Client "brüllt" per Broadcast ins Netz ob da ein DHCP-Server ist von dem er eine IP bekommen könnte, er autentifiziert sich in dieser Phase noch über seine MAC-Adresse.
2. Sofern ein DHCP-Server im Netz steht, sendet dieser ein IP-Adresspaket (mit der Absender-MAC-Adresse) per Broadcast zurück ins Netz und wartet ob es sich ein potentieller Abnehmer dafür meldet.
3. Jetzt merkt der Client: "Hey, die IP-Adresse könnte ich gebrauchen!", und stellt nun eine Anfrage an den Server ob er das Paket bekommen kann.
4. Der DHCP-Server wiederrum emfängt den 'Request' für die Abnahme und teilt nun dem Client die IP-Adresse zu.
5. Der Client übernimmt nun die IP-Adresse gemäß den Voreinstellungen im DHCP-Server (Leasezeiten, etc.)
Damit findet eine (dynamische) Autentifizierung des Clientcomputers statt - an dieser Stelle ist es noch vollkommen unerheblich welcher User sich am System anmeldet.
Darüber hinaus kannst du im DHCP-Adresspool doch auch einen Ausschlussbereich festlegen von IPs die aus dem Pool _nicht_ verteilt werden sollen. Anschließend fügst du dann noch unter 'Reservierungen' eine (oder mehrere) IP-Adresse(n) für den/die Client/s fest (MAC-Adresse des Clients ist ganz wichtig!), und schon haben deine Drucker immer die gleiche IP-Adresse, so, als würdest du sie statisch festlegen. Das funktioniert für alle Geräte gleich (ob WLAN-APs, Drucker, Clients, etc.).
Da sich DHCP und DNS (sofern AD-integriert) ständig 'absprechen' kann es aus technischer Sicht eigentlich gar nicht dazu kommen, dass irgendwas aus dem Ruder läuft.
Die Drucker sollten demnach in der Netzwerkumgebung auf zu sehen sein, u. U. nochmal kontrollieren ob in den Eigenschaften des Druckers auf dem Registerreiter 'Freigabe' auch der Haken gesetzt ist bei "Im Verzeichnis anzeigen".
Was die Ordnerumleitung für die Eigenen Dateien angeht wirds schon etwas komplizierter. Habe ich in meiner Domäne auch versucht einzurichten, bislang aber noch nicht hinbekommen. Grundsätzlich legt man das ja per Gruppenrichtlinie fest. Wichtig ist aber vor allem das dafür DNS 100%ig läuft.
Schau dir dazu doch einfach mal folgende Links an:
http://technet2.microsoft.com/windowsserver/de/library/42607d0b-5d44-4f ...
http://www.wintotal.de/Artikel/w2003server4/w2003server4.php
Kurze Erklärung zum System- und Userspace: Das kommt aus der Linux-Welt und meint den Kontext, in dem ein Prozess läuft. Im Systemspace läuft alles, was nicht von irgendeiner Benutzerauthentifikation abhängig ist und eben zum Betrieb des Systems gebraucht wird.
Mit deiner Erklärung verstehe ich das nun so, daß AD sowohl System- als auch Userspace verwaltet. Ich bin davon ausgegangen, es würde nur den Userspace verwalten.
Zu meinem ursprünglichen Problem: Im Moment sieht es so aus als hätte sich das erledigt wobei die Ursache nicht gefunden wurde sondern nur ein Workaround. Ich habe zunächst alle DHCP-Leases, die DHCP-Bereichsoptionen 44 und 46, sowie alle dynamisch angelegten A-Host-Einträge im DNS gelöscht sowie den WINS-Dienst beendet. Danach die DHCP- und DNS-Dienste neu gestartet und seither läuft der Laden wieder wie früher, nur viel flotter
Ich denke mal, in einem reinen W2003- und XP Pro Netz mit AD kann man auf WINS gut verzichten.
Das einzige was jetzt noch nicht gescheit läuft ist die Sache mit der Ordnerumleitung. Ich habe die in einem separaten, erzwungenen GPO definiert welches direkt mit der Domäne verknüpft ist. Hier habe ich immer noch den Effekt, daß manche User diese Vorgabe sofort übernehmen, manche überhaupt nicht. Neu angelegte User die sich das erste Mal einloggen übernehmen die Einstellung nicht (hätte eigentlich gedacht daß gerade die das machen sollten). Aber ich denke, dazu muss ich noch ein bisschen nachlesen und ggf. einen eigenen Thread dazu aufmachen.
Danke daß du bzw. ihr euch so viel Zeit genommen habt und mein Maschinchen erstmal wieder läuft.
Mit deiner Erklärung verstehe ich das nun so, daß AD sowohl System- als auch Userspace verwaltet. Ich bin davon ausgegangen, es würde nur den Userspace verwalten.
Zu meinem ursprünglichen Problem: Im Moment sieht es so aus als hätte sich das erledigt wobei die Ursache nicht gefunden wurde sondern nur ein Workaround. Ich habe zunächst alle DHCP-Leases, die DHCP-Bereichsoptionen 44 und 46, sowie alle dynamisch angelegten A-Host-Einträge im DNS gelöscht sowie den WINS-Dienst beendet. Danach die DHCP- und DNS-Dienste neu gestartet und seither läuft der Laden wieder wie früher, nur viel flotter
Ich denke mal, in einem reinen W2003- und XP Pro Netz mit AD kann man auf WINS gut verzichten.Das einzige was jetzt noch nicht gescheit läuft ist die Sache mit der Ordnerumleitung. Ich habe die in einem separaten, erzwungenen GPO definiert welches direkt mit der Domäne verknüpft ist. Hier habe ich immer noch den Effekt, daß manche User diese Vorgabe sofort übernehmen, manche überhaupt nicht. Neu angelegte User die sich das erste Mal einloggen übernehmen die Einstellung nicht (hätte eigentlich gedacht daß gerade die das machen sollten). Aber ich denke, dazu muss ich noch ein bisschen nachlesen und ggf. einen eigenen Thread dazu aufmachen.
Danke daß du bzw. ihr euch so viel Zeit genommen habt und mein Maschinchen erstmal wieder läuft.
Na ja, das mit der Ordnerumleitung per Gruppenrichtlinie ist auch schon ein anderes Kaliber, wie gesagt: das habe ich bei mir auch noch nicht zum Laufen bekommen.
Um abschließend noch auf den Satz "Ich denke mal, in einem reinen W2003- und XP Pro Netz mit AD kann man auf WINS gut verzichten." zurückzukommen:
Die Antwort dazu lautet: 'Im Prinzip, Ja', ABER:
Auch wenn die BETRIEBSSYSTEME untereinander darauf verzichten können, heißt das noch lange nicht, dass auch die ANWENDUNGEN das nicht brauchen. Es gibt heutzutage noch immer viele Windowsanwendungen die benötigen zur korrekten Funktion auch noch die WINS-Auflösung. Und, wie ich in einem der letzten Postings auch schon schrieb, ohne WINS gibts auch keine Computer in der Netzwerkumgebung zu sehen! Ist tatsächlich so... leider.
Ich habe selbst lange Zeit ein reines DNS-Netz gefahren, mittlerweile habe ich aber auch WINS wieder am Laufen, aus genannten Gründen. Netter Zusatzeffekt: Sollte DNS mal aus irgendwelchen unerfindlichen Gründen ausfallen, hast du immer noch WINS als "Backup" für die Namensauflösung!
Um abschließend noch auf den Satz "Ich denke mal, in einem reinen W2003- und XP Pro Netz mit AD kann man auf WINS gut verzichten." zurückzukommen:
Die Antwort dazu lautet: 'Im Prinzip, Ja', ABER:
Auch wenn die BETRIEBSSYSTEME untereinander darauf verzichten können, heißt das noch lange nicht, dass auch die ANWENDUNGEN das nicht brauchen. Es gibt heutzutage noch immer viele Windowsanwendungen die benötigen zur korrekten Funktion auch noch die WINS-Auflösung. Und, wie ich in einem der letzten Postings auch schon schrieb, ohne WINS gibts auch keine Computer in der Netzwerkumgebung zu sehen! Ist tatsächlich so... leider.
Ich habe selbst lange Zeit ein reines DNS-Netz gefahren, mittlerweile habe ich aber auch WINS wieder am Laufen, aus genannten Gründen. Netter Zusatzeffekt: Sollte DNS mal aus irgendwelchen unerfindlichen Gründen ausfallen, hast du immer noch WINS als "Backup" für die Namensauflösung!
Also im Moment ist WINS am Server deaktiviert und in der Netzwerkumgebung an den Clients läuft trotzdem alles wie gehabt. Auch der Server taucht dort ganz normal auf. Und selbst wenn nicht, ich hab damit wenig Schmerzen. Die normalen User brauchen die Netzwerkumgebung nicht, die haben ihre Netzlaufwerke. Solange nicht, wie du sagst, eine Anwendung auf WINS pocht, lass ich den erstmal aus. Im Moment fehlt mir einfach die Zeit, in den Kram tiefer einzusteigen, leider.
