TCP/IP-Grundlagen für Microsoft Windows
Anhang C: Computersuchdienst
Zusammenfassung In diesem Anhang wird beschrieben, wie der Computersuchdienst auf Computern, auf denen die Betriebssysteme Microsoft® Windows® XP oder Windows Server™ 2003 ausgeführt werden, die Liste der Arbeitsgruppen und Domänen und der darin enthaltenen Server anzeigt. Mit diesen Listen wird für die Fenster Microsoft Windows-Netzwerk und verwandte Fenster von Netzwerkumgebung Inhalt erstellt. Netzwerkadministratoren müssen wissen, wie der Computersuchdienst in einem IPv4-Netzwerk funktioniert, wenn sie feststellen möchten, warum manche Domänen, Arbeitsgruppen oder die darin enthaltenen Servercomputer nicht angezeigt werden. Auf dieser Seite
Der Computersuchdienst im ÜberblickDer Computersuchdienst in Windows XP und Windows Server 2003 führt eine ständig aktualisierte Liste der Domänen, Arbeitsgruppen und Servercomputer, die sich im Netzwerk befinden, und sendet diese Liste bei Anforderung an Clientcomputer. Eine Domäne ist eine Gruppierung aus Computern. Eine Domäne zeichnet sich zudem durch eine zentralisierte Kontendatenbank und Datensicherheit aus. Im Zusammenhang mit Computersuche ist der Begriff "Domäne" anders definiert als im Zusammenhang mit dem Verzeichnisdienst Active Directory®. Im Zusammenhang mit Active Directory ist eine Domäne eine Auflistung von Computer-, Benutzer- und Gruppenobjekten, die vom Administrator definiert sind. Diese Objekte nutzen die gleiche Verzeichnisdatenbank sowie die gleichen Sicherheitsrichtlinien und Sicherheitsverhältnisse wie andere Domänen. Eine Arbeitsgruppe ist eine logische Gruppierung von Computern, mit deren Hilfe Benutzer gemeinsam genutzte Ressourcen wie beispielsweise Ordner und Drucker finden können. Arbeitsgruppen zeichnen sich nicht durch zentralisierte Benutzerkonten und Datensicherheit aus, wie dies bei Domänen der Fall ist. Eine LAN-Gruppe ist entweder eine Domäne oder eine Arbeitsgruppe. Der Computersuchdienst führt verteilte Listen, in denen verfügbare Netzwerkressourcen aufgeführt sind. So zeigen Sie die Listen auf unterschiedlichen Oberflächen an:
Bei beiden Vorgehensweisen zeigt das Fenster Microsoft Windows-Netzwerk eine Liste der LAN-Gruppen an. Die Liste der LAN-Gruppen und der darin enthaltenen Server wird an automatisch gewählte Suchservercomputer verteilt. Wenn Computer als Suchserver gewählt sind, brauchen nicht mehr alle Computer eine Liste führen, auf der alle LAN-Gruppen und ihre Netzwerkserver verzeichnet sind. Zudem kommt beim Erstellen und Führen der Netzwerkcomputerlisten weniger Netzwerkverkehr zustande. Die Suchliste (also die Liste der LAN-Gruppen und der darin enthaltenen Server, die vom Computersuchdienst gesammelt und verteilt werden) stimmt nicht mit der Computerliste von Active Directory überein. Wenn Sie z. B. im Fenster Netzwerkumgebung im Bereich Netzwerkaufgaben auf Active Directory durchsuchen klicken, wird das Dialogfeld Benutzer, Kontakte und Gruppen angezeigt. Abfragen, die über dieses Dialogfeld gestartet werden, richten sich an Active Directory, nicht an die Suchlisten, die von Computern geführt werden, die den Computersuchdienst ausführen. Der Computersuchdienst tauscht bei der Suche einen Satz von Broadcast- und Unicastnachrichten im Format NetBIOS über TCP/IP (NetBT) aus. Computer können nicht über IPv6 gesucht werden. Wenn NetBT deaktiviert ist, kann der Computersuchdienst nicht genutzt werden. Wenn in Ihrem Netzwerk also NetBT deaktiviert ist und das Domain Name System (DNS) und Active Directory verwendet werden, können Sie im Fenster Gesamtes Netzwerk keine LAN-Gruppen oder LAN-Server anzeigen. Sie müssen in Active Directory die Funktion "Computer suchen" verwenden. Die Computersuche über RAS-Verbindungen wird in Windows Server 2003 durch den neuen NetBT-Proxy unterstützt. Dieser ist standardmäßig für das Routing und den Fernzugriff auf alle Schnittstellen aktiviert, die nicht mit dem Internet verbunden sind. Weitere Informationen über NetBT finden Sie in Kapitel 11, "NetBIOS über TCP/IP" und Kapitel 12 "Übersicht über WINS (Windows Internet Name Service)". Der Computersuchdienst in Windows XP und Windows Server 2003 führt folgende drei Prozesse aus:
Sammeln und Verteilen von SuchinformationenBeim Sammeln und Verteilen von Suchinformationen sind die dafür vorgesehen Suchservercomputer beteiligt. Folgende Suchservertypen sind definiert:
Computer werden infolge eines automatischen Wahlprozesses als Hauptsuchserver und Sicherungssuchserver bestimmt. Für jede LAN-Gruppe gibt es nur einen Hauptsuchserver und 0 oder mehr Sicherungssuchserver. Wie viele Sicherungssuchserver existieren, hängt von der Anzahl der Server in der LAN-Gruppe ab. Weitere Informationen finden Sie unter Windows 2000 Browser Service (in englischer Sprache). Computer, auf denen Windows XP und Windows Server 2003 ausgeführt werden, können als Hauptsuchserver und Sicherungssuchserver fungieren. Nur Windows Server 2003-Computer, die als Domänencontroller fungieren, können auch als Domänen-Hauptsuchserver fungieren. Der SammelprozessDer Hauptsuchserver führt den Sammelprozess aus, indem er die folgenden Informationen in seiner Suchliste zusammenträgt:
Der VerteilungsprozessDer Hauptsuchserver verteilt die Suchliste an die Sicherungssuchservercomputer, die die Suchclientanforderungen bearbeiten. Dies geschieht folgendermaßen:
In Abbildung C-1 ist der Sammel- und Verteilungsprozess dargestellt.  Abbildung C-1: Der Sammel- und Verteilungsprozess des Computersuchdienstes Bearbeiten von SuchclientanforderungenNachdem die Suchliste vom Hauptsuchserver erstellt und an die Sicherungssuchserver verteilt wurde, steht sie zum Bearbeiten von Suchclientanforderungen zur Verfügung. Suchclients fordern folgende Informationen an:
Aufrufen der Listen mit den Servern der eigenen LAN-GruppeWenn auf einem Computer Windows XP oder Windows Server 2003 ausgeführt wird und dieser Computer zu einer Arbeitsgruppe gehört, können Sie eine Liste anzeigen, auf der die Server der Arbeitsgruppe aufgeführt sind. Klicken Sie dazu im Fenster Netzwerkumgebung im Bereich Netzwerkaufgaben auf Arbeitsgruppencomputer anzeigen. Wenn auf einem Computer Windows XP oder Windows Server 2003 ausgeführt wird und dieser Computer zu einer Domäne gehört, können Sie eine Liste anzeigen, auf der die Server der Domäne aufgeführt sind. Doppelklicken Sie dazu im Fenster Microsoft Windows-Netzwerk auf Ihren Domänennamen. Der Suchclient führt folgende Schritte aus, wenn er die Liste mit Servern seiner LAN-Gruppe aufruft:
In Abbildung C-2 ist der beschriebene Prozess dargestellt.  Abbildung C-2: Bearbeiten von Suchclientanforderungen Bei weiteren Anforderungen von Listen LAN-Gruppen-interner Server verwendet der Client weiterhin die Liste der Sicherungssuchservernamen, die er beim Start erhalten hat. Er sendet keinen neuen Broadcast, in dem eine neue Liste der Sicherungssuchserver angefordert wird. Ob die Suchclientanforderung erfolgreich ist, hängt zum einen davon ab, ob der Client vom Hauptsuchserver eine Antwort erhält. Zum anderen ist entscheidend, ob der Client den Computernamen des nach dem Zufallsprinzip ausgewählten Sicherungssuchservers in seine IPv4-Adresse auflösen kann. Aufrufen einer Liste mit den Servern einer anderen LAN-GruppeWenn auf einem Computer Windows XP oder Windows Server 2003 ausgeführt wird und dieser Computer zu einer Arbeitsgruppe gehört, können Sie eine Liste anzeigen, auf der die Server einer anderen LAN-Gruppe aufgeführt sind. Klicken Sie dazu im Dialogfeld Ordner suchen auf den Namen der LAN-Gruppe. Wenn auf einem Computer Windows XP oder Windows Server 2003 ausgeführt wird und dieser Computer zu einer Domäne gehört, können Sie eine Liste anzeigen, auf der die Server einer anderen LAN-Gruppe aufgeführt sind. Doppelklicken Sie dazu im Fenster Microsoft Windows-Netzwerk auf den Namen der LAN-Gruppe. Um die Liste mit den Servern einer anderen LAN-Gruppe zu erhalten, sendet der Client ein Broadcastpaket an den NetBIOS-Namen LANGroup[1D], in dem er die Liste der Sicherungssuchserver anfordert. Der Hauptsuchserver, der für die LAN-Gruppe zuständig ist, antwortet auf die Clientanforderung mit einer Liste, auf der die Computernamen der Sicherungssuchserver der LAN-Gruppe aufgeführt sind. Der Client wählt dann einen beliebigen Sicherungssuchserver aus und fordert ihn auf, die Liste der Server in der LAN-Gruppe herunterzuladen. Die Antwort des ausgewählten Sicherungssuchservers enthält die Liste mit den Servern der LAN-Gruppe. Ob dieser Vorgang erfolgreich durchgeführt werden kann, hängt zum einen davon ab, ob der Client vom Hauptsuchserver, der für die LAN-Gruppe zuständig ist, eine Antwort erhält. Zum anderen ist entscheidend, ob der Client den Computernamen des nach dem Zufallsprinzip ausgewählten Sicherungssuchservers der LAN-Gruppe in eine IPv4-Adresse auflösen kann. Abrufen der Liste der Freigaben auf einem ServerWenn auf einem Computer Windows XP oder Windows Server 2003 ausgeführt wird, können Sie eine Liste anzeigen, auf der die Freigaben eines ausgewählten Servers aufgeführt sind. Doppelklicken Sie dazu im LAN-Gruppen-Fenster auf den entsprechenden Computer. Über die Anzeige des Befehls net view \\servername können Sie aber auch eine Liste mit den Freigaben eines bestimmten Computers anzeigen. Wenn der Computer die Liste mit den Freigaben eines Servers abruft, versucht er den NetBIOS-Namen für den Serverdienst des gewünschten Computers aufzulösen (entspricht ComputerName[20]). Nach der Namensauflösung werden zwischen dem Suchclient und dem Dateifreigabeserver Sitzungen der Typen TCP, NetBIOS und SMB erstellt. Sobald die SMB-Sitzung erstellt ist, fordert der Client eine Freigabenliste an. Obwohl bei der Anforderung der Serverliste der Computersuchdienst bzw. der Suchserver nicht zum Einsatz kommen, gehört die Anforderung zu den Suchvorgängen, die über die Netzwerkumgebung durchgeführt werden. Ob die Clientanforderung erfolgreich ist, hängt zum einen davon ab, ob der Client den Computernamen des ausgewählten Computers in seine IPv4-Adresse auflösen kann. Zum anderen ist entscheidend, dass eine authentifizierte SMB-Sitzung mit dem Server hergestellt werden kann. Der Computersuchdienst in einem IPv4-NetzwerkDer Computersuchdienst funktioniert nur, wenn Broadcasts versendet werden, die NetBIOS-über-TCP/IP-Pakete enthalten. In diesem Zusammenhang kann der Standort von IPv4-Routern Probleme verursachen. IPv4-Router leiten Broadcastpakete nicht weiter, der Client muss aber in allen Netzwerkressourcen eines IPv4-Netzwerks suchen können. Deshalb sind Mechanismen erforderlich, die die Sammlung, Verteilung und Bearbeitung von Suchinformationen regeln, wenn ein Client Suchlisten anfordert und Server, Suchserver und Suchclients aber auf unterschiedlichen Subnetzen installiert sind. Damit das Sammeln und Verteilen von Suchinformationen und das Bearbeiten von Clientanforderungen über IPv4-Router möglich ist, ist eine Kombination aus Unicast- und Broadcast-IPv4-Verkehr erforderlich (statt reinem Broadcast-IPv4-Verkehr). Damit in IPv4-Netzwerken nach Computern gesucht werden kann, nutzt der Computersuchdienst Folgendes:
In den folgenden Abschnitten wird untersucht, wie der Computersuchdienst bei den folgenden Suchkonstellationen IPv4-Netzwerke absucht:
Domäne ist auf zwei Seiten eines IPv4-Routers verteiltIn Abbildung C-3 sehen Sie eine Domäne, die auf zwei Seiten eines IPv4-Routers verteilt ist. Die Domänenmitglieder befinden sich auf mindestens zwei Subnetzen eines IPv4-Routers.  Abbildung C-3: Domäne auf zwei Seiten eines IPv4-Routers Lesen Sie im Zusammenhang mit dieser Konfiguration die folgenden Abschnitte:
Der Sammel- und VerteilungsprozessWenn Domänen über mehrere Router verteilt sind, werden in jedem Subnetz Suchserver gewählt. Jedes Subnetz ist in diesem Fall ein eigenständiges Suchgebiet mit eigenem Hauptsuchserver und eigenen Sicherungssuchservern. Jeder Hauptsuchserver sammelt auf seinem eigenen Subnetz die folgenden Informationen:
Wären alle Server der Domäne auf einem Subnetz untergebracht, wäre der Domänen-Hauptsuchserver zugleich der Hauptsuchserver der Domäne. In der Konfiguration in Abbildung C-3 ist der Domänen-Hauptsuchserver mit nur einem Subnetz verbunden. Damit aber die Informationen zu den Suchlisten besser über den IPv4-Router geleitet werden, müssen die Hauptsuchserver auf anderen Subnetzen mit dem Domänen-Hauptsuchserver kommunizieren. Die Kommunikation zwischen dem Domänen-Hauptsuchserver und dem Hauptsuchserver findet auf zweierlei Art und Weise statt:
Beide Methoden führen zu dem Ergebnis, dass jeder Hauptsuchserver die Suchliste des Domänen-Hauptsuchservers erhält. Die Sicherungssuchserver der einzelnen Subnetze laden die Suchliste von ihrem lokalen Hauptsuchserver herunter. Der Hauptsuchserver und der Domänen-Hauptsuchserver kommunizieren regelmäßig per IPv4-Unicastverbindung. Die Hauptsuchserver der Subnetze nehmen zwecks Informationsaustausch Kontakt zum Domänen-Hauptsuchserver auf. Der Hauptsuchserver löst die IPv4-Adresse des Domänen-Hauptsuchservers auf. Die geschieht mit Hilfe von:
Bearbeiten von SuchclientanforderungenBeim Bearbeiten von Suchclientanforderungen kann der Suchclient folgende Informationen anfordern:
Konfigurieren der Lmhosts-Datei, wenn eine Domäne auf zwei Seiten von IPv4-Routern verteilt istFür Hauptsuchserver auf Remotesubnetzen und Domänen-Hauptsuchserver von Computern, die nicht WINS-fähig sind, kann eine direkte Kommunikation eingerichtet werden. Konfigurieren Sie dazu die Lmhosts-Datei mit den NetBIOS-Namen und den IPv4-Adressen der Suchservercomputer. Die Lmhosts-Datei befindet sich auf den Hauptsuchservern aller Subnetze. Sie sollte Einträge für alle Domänencontroller der Domäne enthalten. Jeder Eintrag muss die folgenden Angaben aufweisen:
Nachstehend sehen Sie einen Beispieleintrag: 131.107.7.80 DC100 #PRE #DOM:EXAMPLE Bei diesem Lmhosts-Eintrag hat ein Domänencontroller für die Domäne EXAMPLE DC100 die IPv4-Adresse 131.107.7.80 und heißt DC100. Wenn Sie Einträge für alle Domänencontroller hinzufügen, brauchen Sie auf den Hauptsuchservercomputern an den Lmhosts-Dateien keine Änderungen vorzunehmen. Dabei spielt es keine Rolle, welcher Domänencontroller zum Domänen-Hauptsuchserver wird. Wenn für den gleichen Domänennamen mehrere Lmhosts-Einträge vorhanden sind, ermittelt ein Computer (Windows XP oder Windows Server 2003), der als Hauptsuchserver fungiert, welcher der Einträge den Domänen-Hauptsuchserver identifiziert, indem er eine Abfrage an die jeweiligen IPv4-Adressen sendet. Nur der Domänen-Hauptsuchserver antwortet auf die Abfrage. Der Computer nimmt anschließend Kontakt mit dem Domänen-Hauptsuchserver auf und tauscht mit diesem Suchlisteninformationen aus. Auf jedem Domänencontroller muss die Lmhosts-Datei mit Einträgen für alle Hauptsuchserver konfiguriert werden, die sich auf Remotesubnetzen befinden. Der Hauptsuchservercomputer wird standardmäßig anhand verschiedener Wahlkriterien gewählt. Wenn Sie sicherstellen möchten, dass ein bestimmter Computer als Hauptsuchserver gewählt wird, legen Sie den Registrierungswert HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Browser\Parameters\IsDomainMaster auf TRUE (REG_SZ) fest. Wenn bei einem Computer "IsDomainMaster" auf TRUE festgelegt ist, wird er nur dann nicht als Domänen-Hauptsuchserver gewählt, wenn auch auf anderen Computern "IsDomainMaster" auf TRUE festgelegt ist. Wenn Sie auf jedem Subnetz den Registrierungswert "IsDomainMaster" des ausgewählten Servercomputers konfiguriert haben, fügen Sie auf jedem Domänencontroller der Lmhosts-Datei für jeden der ausgewählten Hauptsuchserver einen Eintrag hinzu. Anhand dieser Einträge ermittelt der Domänen-Hauptsuchserver, zu welchen Computern er Kontakt aufnehmen muss, wenn er die Suchlisten des Domänen-Hauptsuchservers verteilt. Mehrere Domänen durch IPv4-Router getrenntIn Abbildung C-4 sehen Sie mehrere Domänen, die durch einen IPv4-Router getrennt sind.  Abbildung C-4: Mehrere Domänen durch einen IPv4-Router getrennt Lesen Sie im Zusammenhang mit dieser Konfiguration die folgenden Abschnitte:
Der Sammel- und VerteilungsprozessHauptsuchserver sammeln zum einen die Server, die in ihrer Domäne installiert sind, zum anderen sammeln sie die Namen anderer LAN-Gruppen, die sich auf ihrem Subnetz befinden. All diese Informationen werden an den Domänen-Hauptsuchserver gesendet und dort an die anderen Hauptsuchserver dieser Domäne verteilt. Für Suchclients in dieser Domäne ist die Liste aller LAN-Gruppen, die gesammelt wurden, sichtbar. Eine der Funktionen, mit der WINS den Sammelmechanismus für LAN-Gruppen-Namen verbessert, ist die regelmäßige Abfrage des WINS-Servers durch einen WINS-fähigen Domänen-Hauptsuchserver. Diese Abfrage ergibt eine Liste aller Domänen aus der WINS-Datenbank. Der Domänen-Hauptsuchserver fragt WINS nach allen NetBIOS-Namen ab, die mit "0x1B" enden. Alle NetBIOS-Namen dieses Typs sind nämlich NetBIOS-Domänennamen, die vom Domänen-Hauptsuchserver registriert wurden. Die Liste der Domänen, die per WINS-Abfrage abgerufen wurden, enthält nur die Domänennamen und die dazugehörigen IP-Adressen. Nicht auf der Liste enthalten sind die Namen der Domänen-Hauptsuchserver, die diese Namen registriert haben. Der Computer, auf dem sich der Domänen-Hauptsuchserver befindet, kann den Namen des Domänen-Hauptsuchservers der Domäne abrufen. Dazu sendet er für jede Domäne, die er über die WINS-Abfrage gesammelt hat, eine NetBIOS-Adapterstatus-Nachricht an die IPv4-Adressen, die für den NetBIOS-Computernamen Domain[1B] hinterlegt sind. Die Antwort auf die NetBIOS-Adapterstatus-Nachricht enthält den Computernamen des Computers, der den Domänennamen registriert hat. Auf diese Weise vervollständigt der Domänen-Hauptsuchserver die Liste der Domänennamen und ihrer dazugehörigen Domänen-Hauptsuchserver. Dieser Prozess hat den Vorteil, dass dem Domänen-Hauptsuchserver jeder Domäne nun eine Liste aller Domänen zur Verfügung steht (sofern diese Domänen-Hauptsuchserver WINS-Clients sind oder statische WINS-Einträge haben). Dies umfasst auch Domänen auf den Remotesubnetzen, die nicht Teil seiner Domäne sind. Bearbeiten von WINS-fähigen Clientanforderungen für RemotedomänenWenn ein Client eine Liste mit den Servern einer fremden Domäne anfordert, hängt vom Clienttyp ab, wie der Hauptsuchserver der Domäne aufgelöst wird. Bei WINS-Clients sendet der Client ein Broadcastpaket an den NetBIOS-Namen LANGroup[1D] und fordert so vom lokalen Hauptsuchserver die Liste der Sicherungssuchserver an. Weil der Suchclient eine Liste mit den Sicherungssuchservern einer Remotedomäne anfordert, erhält er keine Antwort auf das Broadcastpaket mit der Anforderung zum Zusenden der Sicherungssuchserverliste. Der Client fordert anschließend die IPv4-Adresse des Domänen-Hauptsuchservers der Domäne von WINS an, indem er den NetBIOS-Namen Domain[1B] abfragt. Die WINS-Namensabfrage ist nur bei Domänen erfolgreich, deren Domänen-Hauptsuchserver ein WINS-Client ist oder einen statischen WINS-Eintrag aufweist. Wenn der Suchclient auf die Namensabfrage vom WINS-Server eine positive Antwort erhält, geschieht Folgendes:
In Abbildung C-5 ist der beschriebene Prozess dargestellt.  Abbildung C-5: Bearbeiten von WINS-fähigen Clientanforderungen bei einer positiven Antwort des WINS-Servers Der Suchclient kann für die NetBIOS-Namensabfrage LANGroup[1B] auch eine negative Antwort erhalten. Dies ist beispielsweise der Fall, wenn es sich bei der LAN-Gruppe um eine Arbeitsgruppe handelt, wenn der Domänencontroller der Domäne kein WINS-Client ist bzw. keinen statischen WINS-Eintrag aufweist, oder wenn der Domänencontroller der Domäne ein WINS-Client ist und der Domänencontroller und der Suchclient nicht die gleiche WINS-Datenbank nutzen. Wenn der Suchclient auf die Namensabfrage vom WINS-Server eine negative Antwort erhält, geschieht Folgendes:
In Abbildung C-6 ist der beschriebene Prozess dargestellt.  Abbildung C-6: Bearbeiten von WINS-fähigen Clientanforderungen bei einer negativen Antwort des WINS-Servers Bearbeiten von Remotedomänenanforderungen nicht WINS-fähiger SuchclientsBei Suchclients, die nicht WINS-fähig sind, wird eine Liste mit den Servern einer Remotedomäne folgendermaßen abgerufen:
In Abbildung C-7 ist der beschriebene Prozess dargestellt.  Abbildung C-7: Bearbeiten einer Anforderung einer Remotedomäne durch einen Suchclient, der nicht WINS-fähig ist Dieser Prozess ist auf Domänen und Arbeitsgruppen anwendbar. Ob er erfolgreich ist, hängt von den folgenden Faktoren ab:
Wenn die Domänen-Hauptsuchserver unterschiedlicher Domänen nicht WINS-fähig sind und die Domänen nicht auf ein gemeinsames Subnetz verteilt sind, isolieren sich die Domänen, tauchen also nie in den Suchlisten der anderen Domänen auf. Isolierte Domänen können namensspezifisch mit dem Befehl net view /d:domain gesucht werden. Dieser Befehl ist jedoch nur dann erfolgreich, wenn der Suchclient den NetBIOS-Namen Domain[1B] auflösen kann. Bei Suchclients, die nicht WINS-fähig sind, können Sie der Lmhosts-Datei einen Eintrag hinzufügen. Dieser verweist mit der IPv4-Adresse des Domänen-Hauptsuchservers für diese Domäne auf den NetBIOS-Namen Domain[1B]. Arbeitsgruppe ist auf zwei Seiten eines IPv4-Routers verteiltWenn eine Arbeitsgruppe auf zwei Seiten eines IPv4-Routers verteilt ist, sind die beiden Zweige separate Arbeitsgruppen. Bei Arbeitsgruppen gibt es keinen Mechanismus, der die Liste der Server, die vom Hauptsuchserver auf dem einen Subnetz gesammelt wurden, an den Hauptsuchserver auf dem anderen Subnetz überträgt. Hauptsuchserver für Arbeitsgruppen registrieren in WINS keinen speziellen NetBIOS-Namen, der von Hauptsuchservern/Suchclients von Arbeitsgruppen genutzt werden könnte. Es gibt keine speziellen Lmhosts-Einträge, die dafür sorgen, dass Suchlisteninformationen von Unicastarbeitsgruppen zwischen Hauptsuchservern weitergeleitet werden. In Abbildung C-8 ist beispielhaft eine Arbeitsgruppe dargestellt, die auf zwei Seiten eines IPv4-Routers verteilt ist.  Abbildung C-8: Arbeitsgruppe ist auf zwei Seiten eines IPv4-Routers verteilt Es gibt zwei Möglichkeiten, alle Server der beiden Arbeitsgruppenhälften links und rechts vom Router für Suchclients sichtbar zu machen. Zum einen kann die Weiterleitung von NetBIOS-über-TCP/IP-Broadcasts aktiviert werden und zum anderen kann die Arbeitsgruppe zu einer Domäne aufgewertet werden. Von ersterer Lösung wird jedoch stark abgeraten. Mehrere Arbeitsgruppen durch IPv4-Router getrenntHauptsuchserver von Arbeitsgruppen können sich selbst nicht über die Grenzen ihres Subnetzes ankündigen. Domänen dagegen können sich mit dem speziellen Domain[1B] NetBIOS-Namen (vom Domänen-Hauptsuchserver mit WINS registriert) über die Grenzen ihres Subnetzes selbst ankündigen. Für Arbeitsgruppen existiert kein entsprechender Mechanismus. Die Kombination von Verteilung und Ankündigungsverhalten von Domänen einerseits und das Fehlen entsprechender Mechanismen in Arbeitsgruppen andererseits kann zu Verwirrung führen. Abbildung C-9 zeigt eine Beispielkonfiguration.  Abbildung C-9: Mehrere Arbeitsgruppen durch einen IPv4-Router getrennt CORP ist eine Domäne, die auf die Subnetze 1 und 2 verteilt ist. R&D_WG befindet sich auf Subnetz 1 und MKTG_WG auf Subnetz 2. Wegen der Sammlungs- und Verteilungsvorgänge zwischen MB1 (Hauptsuchserver für CORP auf Subnetz 1) und DC1 (Domänen-Hauptsuchserver für CORP auf Subnetz 2) setzt sich die Suchliste, anhand derer Suchclients die CORP-Domäne absuchen, folgendermaßen zusammen:
Für Suchclients in der Arbeitsgruppe R&D_WG sind in der Suchliste nur folgende Elemente sichtbar:
Die Arbeitsgruppe MKTG_WG erscheint weder zum aktuellen Zeitpunkt noch später in der Suchliste für R&D_WG. Das hat folgende Gründe:
Diese Konstellation führt zu dem Problem der isolierten Arbeitsgruppen. Das bedeutet, dass die Existenz einer Arbeitsgruppe nur innerhalb ihres Subnetzes und in Domänen bekannt ist, die ihr Subnetz beinhalten.(Die Arbeitsgruppe ist also nur in den Suchlisten von Arbeitsgruppen sichtbar, die sich auf demselben Subnetz befinden und in Suchlisten von Domänen, die das Subnetz der gesuchten Arbeitsgruppe beinhalten). Für LAN-Gruppen auf anderen Subnetzen ist die isolierte Arbeitsgruppe nicht in den Suchlisten sichtbar. Das Problem der isolierten Arbeitsgruppen lässt sich nur dadurch lösen, dass NetBIOS-über-TCP/IP-Broadcasts weitergeleitet werden (nicht empfehlenswert) oder dass die Arbeitsgruppen zu Domänen aufgewertet werden. Für große Unternehmen, die mithilfe von Domänen sowohl die logische Gruppierung von Computern als auch die Sicherheits- und Konteninfrastruktur für Authentifizierung und Zugangssteuerung sicherstellen, sind isolierte Arbeitsgruppen in Subnetzen, die durch Router verbunden sind, in der Regel kein Problem.
|
In diesem Beitrag
|
