Problembehandlung im Microsoft-Computersuchdienst

SPRACHE AUSWÄHLEN SPRACHE AUSWÄHLEN
Artikel-ID: 188305 - Produkte anzeigen, auf die sich dieser Artikel bezieht
Dieser Artikel wurde zuvor veröffentlicht unter D41566
Dieser Artikel ist eine Übersetzung des folgenden englischsprachigen Artikels der Microsoft Knowledge Base:
188305 Troubleshooting the Microsoft Computer Browser Service
Bitte beachten Sie: Bei diesem Artikel handelt es sich um eine Übersetzung aus dem Englischen. Es ist möglich, dass nachträgliche Änderungen bzw. Ergänzungen im englischen Originalartikel in dieser Übersetzung nicht berücksichtigt sind. Die in diesem Artikel enthaltenen Informationen basieren auf der/den englischsprachigen Produktversion(en). Die Richtigkeit dieser Informationen in Zusammenhang mit anderssprachigen Produktversionen wurde im Rahmen dieser Übersetzung nicht getestet. Microsoft stellt diese Informationen ohne Gewähr für Richtigkeit bzw. Funktionalität zur Verfügung und übernimmt auch keine Gewährleistung bezüglich der Vollständigkeit oder Richtigkeit der Übersetzung.
Alles erweitern | Alles schließen

Auf dieser Seite

Zusammenfassung

Es gibt kein zentrales Verfahren, um herauszufinden, ob die Suchliste über das WAN hinweg vollständig ist. Es gibt jedoch Techniken, um zu ermitteln, ob die Server in einem bestimmten Segment in der Suchliste für ein Remote-Segment vertreten sind. Diese Techniken können für alle Segmente im gesamten WAN verwendet werden. Die Ergebnisse dieser Tests können sich jedoch ändern, wenn sich die Rollen der Server bei der Suchdienstwahl ändern. Die Ergebnisse sind nur dann aussagekräftig, wenn alle Server einer Domäne im gesamten WAN vollkommen statisch sind und kein Server online oder offline geschaltet wird.

Die im Folgenden beschriebenen Tests basieren auf dem Dienstprogramm "Browstat.exe", das im Microsoft Windows Resource Kit zur Verfügung steht. Die Beispielausgabedaten beziehen sich ausschließlich auf das TCP/IP-Protokoll. Wie meistens bei der Diagnose von Netzwerkproblemen muss der Administrator auch zur Problembehandlung im Suchdienst die Segmentgrenzen und Routerkonfigurationen im Netzwerk kennen. Stellen Sie sich beispielsweise vor, dass ein Client in einem Remote-Segment einen Server nicht in seiner Suchliste enthält, der in einem anderen Segment liegt.

Wegen der Zeitabhängigkeit des Suchdienstes und der Verwendung von Broadcast-Datagrammen sollten Sie diese Schritte erst nach Ablauf des 48-minütigen Zyklus ausführen (vollständiger Übermittlungszyklus in einer Domänenumgebung mit mehreren Segmenten).

Denken Sie daran, dass die Namensauflösung zwischen allen Suchdiensten von entscheidender Bedeutung ist und dass als vorrangige Aufgabe zunächst eine robuste Infrastruktur für die Namensauflösung mit WINS einzurichten ist. Für die Diagnose von Suchdienstproblemen, die eigentlich durch Probleme mit der Namensauflösung verursacht werden, kann viel Zeit vergeudet werden.

Weitere Informationen

  1. Suchen Sie den Hauptsuchdienst in dem Segment, in dem der Server liegt. Führen Sie den folgenden Befehl in dem Segment aus, in dem der fehlende Server liegt:
    browstat status
    Die Ausgabe sieht etwa so aus:
    Status for domain Domänenname on transport \Device\NetBT_IEEPRO1

    Browsing is active on domain.
    Master browser name is: Hauptsuchdienst
    Master browser is running build 1381
    1 backup servers retrieved from master Sicherungssuchdienst
    \\SmallerServer
    There are 100 servers in domain Domänenname on transport
    \Device\NetBT_IEEPRO1
    There are 1500 domains in domain Domänenname on transport
    \Device\NetBT_IEEPRO1
    Diese Informationen sollten Ihnen anzeigen, welcher Server als Hauptsuchdienst im Segment fungiert. Falls der lokale Hauptsuchdienst jedoch langsam reagiert hat, kann diese Information von einem anderen Hauptsuchdienst kommen.

    Die Ergebnisse dieses Befehls liefern die Zeichenfolge "\Device\Protocol_NIC" und können für andere browstat-Befehle genutzt werden.

    Führen Sie den folgenden Befehl aus, um den lokalen Hauptsuchdienst im Client-Segment zu finden:
    browstat getmaster \device\netbt_el59x1 Domänenname
    Die Option Status oder Getmaster schickt eine Domänennamen<1d>-Abfrage und gibt den aktuellen Hauptsuchdienst für dieses Segment zurück. Der Suchdienst wird nicht verwendet, um herauszufinden, welcher Computer als Hauptsuchdienst fungiert. Dieser Schritt kann remote ausgeführt werden, wenn der Suchdienst selbst verwendet wird, um zu ermitteln, welche Computer als Hauptsuchdienste im Segment verwendet werden. Das setzt jedoch voraus, dass der Administrator alle Server in jedem der Segmente kennt. Außerdem ist dies keine besonders gute Technik zur Problembehandlung, da der Suchdienst selbst verwendet wird, um ein Suchdienstproblem zu beheben. Selbst dann, wenn es in diesem Bereich des Suchdienstes kein Problem gibt, kann die zurückgegebene Liste bis zu 36 Minuten veraltet sein. Führen Sie den folgenden Befehl aus, um die Liste der Hauptsuchdienste in der Domäne remote zu ermitteln:
    browstat view \device\netbt_ieepro1 \\pdcname | findstr /i mbr
    Jetzt muss der Administrator herausfinden, welcher Hauptsuchdienst sich in dem Segment befindet, das den Namen des fehlenden Servers enthält.

    Wenn kein Hauptsuchdienst gefunden wird, kann eine Auswahl erzwungen werden, indem man den Suchdienst auf einem Domänencontroller, der sich im Segment des Servers befindet, stoppt und wieder startet. Wiederholen Sie diesen Test nach einigen Minuten. Alternativ kann eine Auswahl erzwungen werden, indem man von der Konsole eines Servers im Segment des Servers den folgenden Befehl ausführt:
    browstat elect \device\netbt_ieepro1 Domänenname
  2. Stellen Sie fest, ob der Hauptsuchdienst den Servernamen in seiner Liste führt. Der Hauptsuchdienst ist der erste Server in der Kommunikationskette, der den Namen des fehlenden Servers enthalten muss. Dieser Test ermittelt, ob der Hauptsuchdienst den Ankündigungsrahmen des Serverhosts erhalten hat. Beachten Sie, dass die Zeichenfolge "\device..." aus der obigen Ausgabe stammt. Führen Sie den folgenden Befehl aus:
    browstat view \device\netbt_ieepro1 \\masterbrowser | findstr /i FehlenderServer
    Wenn der Hauptsuchdienst den Server in seiner Liste führt, gibt der Befehl Ausgabedaten zurück, die etwa so aussehen:
    \\FehlenderServer NT 04.00 (W,S,NT,PBR,DFS) "Description" of server
    \\FehlenderServer
    Wenn der lokale Hauptsuchdienst den Servernamen nicht in seiner Liste führt, kann der folgende Befehl von einem beliebigen Computer im Segment des fehlenden Servers ausgeführt werden:
    browstat forceannounce \device\netbt_el59x1 Domänenname
    Der folgende Befehl kann auch von der Konsole des fehlenden Servers ausgeführt werden:
    browstat announce \device\netbt_el59x1 Domänenname
    Es kann hilfreich sein, festzustellen, ob der fehlende Server ein Netzlaufwerk mit dem Hauptsuchdienst verbinden kann, um die Netzwerkverbindungen zu überprüfen.

    Zusätzlich kann der Server neu gestartet werden, um einen Host-Ankündigungsrahmen zu erzwingen.

  3. Stellen Sie fest, ob der PDC den Servernamen vom Hauptsuchdienst erhalten hat. Führen Sie den folgenden Befehl aus:
    browstat view \device\netbt_ieepro1 \\pdc | findstr /i FehlenderServer
    Die Ausgabe sollte etwa so aussehen:
    \\FehlenderServer NT 04.00 (W,S,NT,PBR,DFS) "Description" of server
    \\FehlenderServer
    Wenn der Servername fehlt, so ist dies wahrscheinlich auf Probleme mit der Namensauflösung zurückzuführen. Damit der PDC die Serverliste vom Hauptsuchdienst erhält, muss der Hauptsuchdienst des Servers in der Lage sein, den Domänennamen<1b> aufzulösen, damit er den zugewiesenen Hauptankündigungsrahmen über UDP-Port 138 schicken kann. Der PDC kann nur dann auf diese Ankündigung reagieren und den Servernamen erhalten, wenn er den Computernamen des Hauptsuchdienstes auflösen kann. (Damit der Hauptsuchdienst des Servers die domänenweite Liste vom PDC erhalten kann, muss er ebenfalls den Computernamen des PDC auflösen können).

    Die Namensauflösung in beiden Richtungen ist von entscheidender Bedeutung. Führen Sie den folgenden Befehl aus, um zu überprüfen, ob der Hauptsuchdienst des Servers den Domänennamen<1b> auflösen kann:
    browstat getpdc \device\netbt_el59x1 Domänenname
    Stellen Sie eine Netzlaufwerkverbindung vom Hauptsuchdienst zum PDC und vom PDC zum Hauptsuchdienst her, um zu überprüfen, ob der PDC und der Hauptsuchdienst ihre Computernamen gegenseitig auflösen können. Wenn einer dieser Schritte scheitert, beheben Sie das Problem mit der Namensauflösung.

  4. Ermitteln Sie den Hauptsuchdienst im Client-Segment. Dazu führen Sie dieselben Schritte aus wie in Abschnitt 1 beschrieben, jedoch im Client-Segment.
  5. Stellen Sie fest, ob der Hauptsuchdienst den Namen des fehlenden Servers im Client-Segment führt. Führen Sie den folgenden Befehl aus:
    browstat view \device\netbt_ieepro1 \\mbclientseg | findstr /i FehlenderServer
    Wenn der Server den Eintrag in seiner Liste führt, sollte die Ausgabe etwa so aussehen:
    \\FehlenderServer NT 04.00 (W,S,NT,PBR,DFS) "Description" of server
    \\FehlenderServer
    Wenn der Hauptsuchdienst den Namen des fehlenden Servers nicht in seiner Liste führt, so ist das wahrscheinlich auf ein Problem mit der Namensauflösung zurückzuführen. Überprüfen Sie, ob der Hauptsuchdienst im Client-Segment den Domänennamen<1b> auflösen kann, indem Sie den folgenden Befehl ausführen:
    browstat getpdc \device\netbt_el59x1 Domänenname
    Außerdem muss der Hauptsuchdienst in der Lage sein, den Computernamen des PDC aufzulösen. Überprüfen Sie dies, indem Sie ein Netzlaufwerk mit dem PDC verbinden.

    Wenn einer dieser Schritte scheitert, beheben Sie das Problem mit der Namensauflösung.

  6. Ermitteln Sie die Sicherungssuchdienste im Client-Segment. Wenn ein Client eine Suchliste anfordert, wählt er - sofern verfügbar - einen Sicherungssuchdienst, um die Anforderungen an den Hauptsuchdienst des Segments zu reduzieren. Es ist deshalb wahrscheinlich, dass alle Clients Sicherungssuchdienste verwenden. Es gibt zwei Möglichkeiten, die lokalen Sicherungssuchdienste für dieses Segment zu finden.

    Führen Sie von der Konsole des Hauptsuchdienstes den folgenden Befehl aus:
    browstat locallist \device\netbt_ieepro1 | findstr /i bbr
    Eine Liste mit Einträgen wird zurückgegeben, die etwa so aussieht:
    \\Sicherungssuchdienst NT 04.00 (W,S,BDC,NT,BBR,DFS) "Description" of server
    \\Sicherungssuchdienst
    Um diesen Befehl remote an den Hauptsuchdienst zu schicken, führen Sie den folgenden Befehl aus:
    browstat view \device\netbt_ieepro1 \\Sicherungssuchdienst 0x40000000 | findstr /i bbr
    Hinweis: Diese Flags sind im CIFS-Browsing-Protokolldokument definiert:

    ftp://ftp.microsoft.com/developr/drg/cifs/cifsbrow.doc
  7. Stellen Sie fest, ob die Sicherungssuchdienste den Namen des fehlenden Servers führen. Damit alle Clients in diesem Segment eine zuverlässige Suchliste erhalten, muss jeder Sicherungssuchdienst auf den Namen des fehlenden Servers überprüft werden. Führen Sie den folgenden Befehl für jeden Sicherungssuchdienst aus:
    browstat view \device\netbt_ieepro1 \\Sicherungssuchdienst | findstr /i FehlenderServer
    Wenn ein Sicherungssuchdienst den Namen des fehlenden Servers nicht enthält, überprüfen Sie, ob der Sicherungssuchdienst dem Hauptsuchdienst ein Netzlaufwerk zuordnen kann. Die Rolle des Sicherungssuchdienstes ist die dynamischste Suchdienstrolle. Hauptsuchdienste weisen mögliche Suchdienste an, abhängig von der Suchdienstlast als Sicherungssuchdienste zu fungieren. Warten Sie 12 Minuten, und wiederholen Sie die Schritte 6 und 7.
Weitere Informationen darüber, aus welchem Grund der Computername möglicherweise nicht in der Suchliste enthalten ist, finden Sie in folgendem Artikel der Microsoft Knowledge Base:
231312 Computer Name Missing in the Browsing List

Probleme bei mehrfacher Vernetzung

Damit der PDC eine domänenweite Liste aufbauen kann, darf er kein mehrfach vernetzter Server sein. Jeder Hauptsuchdienst für Remote-Segmente stellt eine Verbindung zum PDC her. Da es keine Gewähr gibt, dass jeder Hauptsuchdienst dieselbe Schnittstelle auf dem PDC wählt, muss der PDC einfach vernetzt sein, um eine domänenweite Liste erzeugen zu können. Auch alle Hauptsuchdienste müssen einfach vernetzt sein. Alle 12 Minuten stellt der Hauptsuchdienst eine Verbindung zum PDC her und fordert die domänenweite Liste an. Der Hauptsuchdienst gibt dann einen Hauptankündigungs-Suchdienstrahmen an den PDC aus, der ihm mitteilt, dass er eine Verbindung zum Hauptsuchdienst herstellen und seine lokalen Listen in Empfang nehmen soll. Da der PDC jedoch keine separaten IP-Adressen für jede Hauptsuchdienst-Schnittstelle führt, erhält er bei der Herstellung der Verbindung zum Hauptsuchdienst nur die Liste der Computer und Server für die jeweilige Schnittstelle.

Weitere Erwägungen

Wenn Sie eine unregelmäßige Suchdienstfunktionalität und die Durchführung dieser Tests vermeiden wollen, müssen Sie möglicherweise Computer für jedes Segment festlegen, um eine konsistente, domänenweite Liste zu erhalten. Wenn Server oft heruntergefahren und neu gestartet werden, ziehen Sie in Erwägung, einen BDC für jedes Segment vorzusehen, wenn die Anzahl der Segmente nicht groß ist, oder zumindest einen Windows NT-Mitgliedsserver, wobei die Registrierungseinstellung "IsDomainMaster" auf "True" gesetzt ist. Dadurch gewinnt der Server einen Vorteil, wenn es um die Wahl zum Hauptsuchdienst für das Segment geht.

Wenn Sie mit keinem dieser Vorschläge zum nächsten Schritt gehen können, stellen Sie sicher, dass auf keinem der Suchdienstserver, die Sie ermittelt haben, ein Namenskonflikt vorliegt. Führen Sie hierzu den folgenden Befehl aus:
nbtstat -n
Diesen Befehl können Sie mit den Optionen -A oder -a remote verwenden.

Der Suchdienst reagiert sehr empfindlich auf die Routerkonfigurationen im gesamten WAN. Da die Suchdienstrollen durch Broadcast-Wahlen ermittelt werden, dürfen UDP-Broadcasts nicht weitergeleitet werden. Es kann zu unerwarteten Reaktionen kommen, wenn UDP-Broadcast-Verkehr in eine Richtung weitergeleitet wird, jedoch nicht in die andere. Dadurch können "8003"-Suchdienstereignisse erzeugt werden, was einen fortdauernden Wahlzyklus zur Folge hat.

Als weiteren Schritt zur Problemlösung können Sie den Netzwerkverkehr mit einem Protokollanalyseprogramm wie dem Microsoft-Netzwerkmonitor aufzeichnen. Zur direkten Anzeige der Suchdienstkommunikation können Sie den Suchdienst anhalten und wieder neu starten. Leider gibt es jedoch keine Gewähr, dass ein Suchdienst nach dem Anhalten und Neustart dieselbe Rolle übernimmt, die er vorher hatte. Dieses Verfahren kann jedoch besonders hilfreich zur Überprüfung der Kommunikation sein, wenn der Hauptsuchdienst die domänenweite Liste vom PDC anfordert, und direkt danach, wenn der PDC die lokale Liste vom Hauptsuchdienst anfordert. Nach dem Starten des Suchdienstes sollte der gesamte Austausch innerhalb von ein bis zwei Minuten stattfinden. Konfigurieren Sie Einstellungen für den Sammlungspuffer des Protokollanalyseprogramms und die Rahmengröße für dieses Verkehrsvolumen.

Die Serverliste, die vor Windows NT 4.0 vom Suchdienst zurückgegeben wurde, war auf eine Größe von 64 KB beschränkt. Wenn diese Größe überschritten wird, sieht der Benutzer eine abgeschnittene alphabetische Serverliste. Um dieses Problem umgehen zu können, müssen alle Suchdienste mit Windows NT 4.0 oder höher laufen.

Informationsquellen

Weitere Informationen finden Sie im Whitepaper "Microsoft Windows NT Browser" auf der folgenden Website von Microsoft:
http://technet.microsoft.com/en-us/library/cc767893.aspx

Eigenschaften

Artikel-ID: 188305 - Geändert am: Freitag, 23. September 2011 - Version: 6.0
Die Informationen in diesem Artikel beziehen sich auf:
  • Microsoft Windows Server 2003, Enterprise Edition (32-bit x86)
  • Microsoft Excel 4.0 für Macintosh
  • Microsoft PowerPoint 3.0 für Macintosh
  • Microsoft Windows Server 2003, Standard Edition (32-bit x86)
  • Microsoft Windows 2000 Server
  • Microsoft Windows 2000 Advanced Server
  • Microsoft Windows 2000 Professional Edition
  • Microsoft Windows NT Server 4.0 Standard Edition
  • Microsoft Windows NT Workstation 4.0 Developer Edition
  • Microsoft Windows NT Server 4.0 Enterprise Edition
Keywords: 
kbinfo kbnetwork kbtshoot KB188305
Microsoft stellt Ihnen die in der Knowledge Base angebotenen Artikel und Informationen als Service-Leistung zur Verfügung. Microsoft übernimmt keinerlei Gewährleistung dafür, dass die angebotenen Artikel und Informationen auch in Ihrer Einsatzumgebung die erwünschten Ergebnisse erzielen. Die Entscheidung darüber, ob und in welcher Form Sie die angebotenen Artikel und Informationen nutzen, liegt daher allein bei Ihnen. Mit Ausnahme der gesetzlichen Haftung für Vorsatz ist jede Haftung von Microsoft im Zusammenhang mit Ihrer Nutzung dieser Artikel oder Informationen ausgeschlossen.

Ihr Feedback an uns

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com