NetBIOS Namensauflösung unter Windows funktioniert nicht

Einer unserer Anwender arbeitet in einer Außenstelle, die aus lediglich einem Switch, einem Router und zwei Rechnern besteht: Dem Notebook des Mitarbeiters und einem „Server“, beide mit Windows XP. Mittels Offlinedateien synchronisiert das Notebook Daten mit einer Freigabe des Servers. Das klappte plötzlich nicht mehr.

Nach einigen Tests stellte sich als Ursache schnell eine kaputte Namensauflösung heraus. Der in der Offlinesynchronisation verwendete Hostname des Servers konnte vom Notebook nicht aufgelöst werden und das Resulat war eine nicht mehr funktionierende Synchronisation.

Weil eine (interne) DNS-Auflösung im Netzwerk nicht existiert, musste der Fehler irgendwo bei der Namensauflösung via NetBIOS liegen. Und in der Tat förderte ein nbtstat -a hostname kein Ergebnis zu Tage:

C:\>nbtstat -a xp-server

LAN-Verbindung:
Knoten-IP-Adresse: [192.168.61.10] Bereichskennung: []

    Host nicht gefunden.

…während der Hostname via IP-Adresse erfolgreich ausgekundschaftet werden konnte:

C:\nbtstat -A 192.168.61.1

LAN-Verbindung:
Knoten-IP-Adresse: [192.168.61.10] Bereichskennung: []

      NetBIOS-Namentabelle des Remotecomputers

       Name               Typ          Status
    ---------------------------------------------
    XP-SERVER        EINDEUTIG   Registriert
    WORKGROUP        GRUPPE      Registriert
    XP-SERVER        EINDEUTIG   Registriert
    WORKGROUP        GRUPPE      Registriert
    WORKGROUP        EINDEUTIG   Registriert
    ..__MSBROWSE__.  GRUPPE      Registriert

    MAC Adresse = 00-1A-4D-5C-CB-65

Um das nun weiter zu untersuchen, muss man zunächst den Prozess der Namensauflösung in Windows verstehen. Der Normalfall sieht hier folgende Reihenfolge vor [1]:

    When an application uses Windows Sockets and either the application or a user specifies a host name, TCP/IP for Windows XP and Windows Server 2003 attempts to resolve the name in the following order when NetBIOS over TCP/IP is enabled:

    1. Windows checks whether the host name is the same as the local host name.
    2. If the host name and local host name are not the same, Windows searches the DNS client resolver cache.
    3. If the host name cannot be resolved using the DNS client resolver cache, Windows sends DNS Name Query Request messages to its configured DNS servers.
    4. If the host name is a single-label name (such as server1) and cannot be resolved using the configured DNS servers, Windows converts the host name to a NetBIOS name and checks its local NetBIOS name cache.
    5. If Windows cannot find the NetBIOS name in the NetBIOS name cache, Windows contacts its configured WINS servers.
    6. If Windows cannot resolve the NetBIOS name by querying its configured WINS servers, Windows broadcasts as many as three NetBIOS Name Query Request messages on the directly attached subnet.
    7. If there is no reply to the NetBIOS Name Query Request messages, Windows searches the local Lmhosts file.

    The name resolution process stops when Windows finds the first IP address for the name. If Windows cannot resolve the host name using any of these methods, name resolution fails, and the only way to communicate with the destination host is to specify either its IP address or another name associated with the host that Windows can resolve to an IP address.

Was hier scheinbar noch fehlt, sind die Einträge aus der Hosts-Datei. Tatsächlich findet dies aber bereits im zweiten Schritt statt. Denn, was vermutlich größtenteils unbekannt ist [1]:

    TCP/IP for Windows XP and Windows Server 2003 does not search the Hosts file directly when performing name resolution. Rather, the entries in the Hosts file are automatically loaded into the DNS client resolver cache.

Für den gegebenen Fall wird es allerdings erst ab Schritt 4 interessant – nämlich ab dem Zeitpunkt, wann die Namensauflösung via NetBIOS startet.

Zuerst wird im NetBIOS Cache nachgesehen. Der war leer. Anschließend wird ein WINS-Server gefragt. Den es nicht gibt. Spätestens mit dem Broadcast im sechsten Schritt hätte es aber funktionieren müssen – hat es aber nicht! Warum?

Weil der Prozess der Namensauflösung via NetBIOS unterschiedlich sein kann und nicht in jedem Fall der oben beschriebenen Reihenfolge entspricht. Festgelegt wird das durch den in Windows konfigurierten NetBIOS node type – auf deutsch „Knotentyp“ [2]:

    B-node (broadcast)
    Uses broadcasts for name registration and resolution. Because routers typically do not forward NetBT broadcasts, NetBIOS resources that are located on remote subnets cannot be resolved.

    P-node (peer-peer)
    Uses an NBNS such as WINS to resolve NetBIOS names. P-node does not use broadcasts but queries the NBNS directly. Because broadcasts are not used, NetBIOS resources located on remote subnets can be resolved. However, if the NBNS becomes unavailable, NetBIOS name resolution fails for all NetBIOS names, even for NetBIOS applications that are located on the local subnet.

    M-node (mixed)
    A combination of B-node and P-node. By default, an M-node functions as a B-node. If the broadcast name query is unsuccessful, NetBT uses an NBNS.

    H-node (hybrid)
    A combination of P-node and B-node. By default, an H-node functions as a P-node. If the unicast name query to the NBNS is unsuccessful, NetBT uses a broadcast.

    Microsoft enhanced B-node
    A combination of B-node and the use of the local Lmhosts file. If the broadcast name query is not successful, NetBT checks the local Lmhosts file.

Standardmäßig verwendet Windows den Knotentyp „Microsoft enhanced B-node“, also eine Kombination aus Broadcasts und Lmhosts. Sobald ein WINS Server konfiguriert ist, wird auf „H-node (hybrid)“ umgestellt.

Der Knotentyp des Notebooks stand dagegen auf „P-node (peer-peer)“, womit die Namensauflösung via Broadcast komplett abgeschaltet war:

C:\>ipconfig /all

Windows-IP-Konfiguration

   Hostname  . . . . . . . . . . . . : xp-notebook
   Primäres DNS-Suffix . . . . . . . :
   Knotentyp . . . . . . . . . . . . : Peer-Peer
   IP-Routing aktiviert  . . . . . . : Nein
   WINS-Proxy aktiviert  . . . . . . : Nein

Zum Ändern des Knotentyps muss folgender DWORD Eintrag in der Registrierung hinzugefügt und auf einen der vier möglichen Werte gestellt werden:

    HKLM\SYSTEM\CurrentControlSet\Services\Netbt\Parameters\NodeType

    1 = B-Knoten (Broadcast)
    2 = P-Knoten (Peer-Peer)
    4 = M-Knoten (Mixed)
    8 = H-Knoten (Hybrid)

Nach Änderung des Wertes auf 1 (Broadcast) und einem anschließenden Neustart wurde der Name des Servers wieder aufgelöst und die Synchronisation erfolgreich gestartet.

[1] Technet: TCP/IP Fundamentals for Microsoft Windows; Chapter 7 – Host Name Resolution
[2] Technet: TCP/IP Fundamentals for Microsoft Windows; Chapter 11 – NetBIOS over TCP/IP

1 Response to “NetBIOS Namensauflösung unter Windows funktioniert nicht”


  1. 1 Martin Mai 8, 2012 um 7:33 pm

    Super Blog. Nach langem Suchen hat er mein Problem gelöst. Und das bei einem neuen Laptop.
    Danke!!


Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s





%d Bloggern gefällt das: