Appendix C: Known NetBIOS Suffix Values


NetBIOS Name Suffix Bytes

The table below classifies NetBIOS names according to their base-names, the suffix byte, and their status as a unique or group name. The list was gathered from sources scattered around the Internet, old documentation, and hear-say. There are many references out there, and a good deal of variation among them. As usual, what is available is at times both contradictory and incomplete. As a result, the information presented below should be viewed with suspicion. If you have updates or comments which you can share freely, please send them to warranty, expressed or implied...
-- relevant disclaimer

Name Format Suffix Group/Unique Service/Description
machine <00> unique Workstation Service
Known as the NetBIOS Computer Name or the Client Service Name because it is typically sent as the CALLING NAME (NBT source address) in NBT Session requests. Some of the documentation indicates that the purpose of the Workstation Service is to receive mailslot messages directed at the node.
machine <01> unique Messenger Service
Under some versions of Windows, this name is registered by the Messenger Service and used as the CALLING NAME (NBT source address) when creating an NBT session with the Messenger Service on another node.

Not all implementations use this name as the CALLING NAME when setting up a Messenger Service session. Samba uses the machine<00> name, and Windows2000 uses the machine<03> name.

machine <03> unique Messenger Service
This name is registered by the Messenger Service, which is used to exchange "WinPopup" messages. Like the Server Service the Messenger Service speaks SMB protocol, but it uses a different set of SMB messages and is a distinct service.

When creating an NBT session, the Messenger Service client uses either the username<03> or machine<03> name as the CALLED NAME (NBT destination address) in the NBT SESSION REQUEST. The choice, of course, depends upon whether the message is being sent to a user or a node.

Some, but not all, implementations of the Messenger Service client will also use the client's machine<03> name as the CALLING NAME in the NBT SESSION REQUEST.

See also machine<01> and username<03>.

machine <06> unique RAS Server Service
machine <1F> unique NetDDE Service
machine <20> unique File Server Service
This, of course, is the Server Service, which is the primary recipient of SMB connections. SMB services may be offered under any name, but this is the standard. Clients expect that the Server Service name will have a suffix value of 0x20.
machine <21> unique RAS Client Service
machine <22> unique Microsoft Exchange
machine <23> unique Microsoft Exchange
machine <24> unique Microsoft Exchange
machine <2B> group Lotus Notes Server Service
machine <30> unique Modem Sharing Server Service
machine <31> unique Modem Sharing Client Service
machine <42> unique McAfee anti-virus.
Several sites list this suffix as being used by McAfee (or, incorrectly, McCaffee) anti-virus software, but no further documentation was found to support the claim. The information may be out of date.
machine <43> unique SMS Client Remote Control
machine <44> unique SMS Administration Remote Control Tool
machine <45> unique SMS Client Chat
machine <46> unique SMS Client Remote Transfer
machine <4C> unique DEC Pathworks TCP/IP Service for WindowsNT
machine <52> unique DEC Pathworks TCP/IP Service for WindowsNT
machine <6A> unique Microsoft Exchange
machine <87> unique Microsoft Exchange
machine <BE> unique Network Monitor Agent
Microsoft's Network Monitor (NetMon) is split into two pieces: the "Agent", and the "Client Application".

The agent does the work of capturing packets, and the NetMon client provides the user interface. The advantage of this architecture is that agents and clients may run on separate machines. A single NetMon client can, therefore, have access to the capture services of multiple agents, scattered all around an intranet (or, in theory, the Internet). Putting aside the obvious security problems associated with having live capture agents on networks, this can be a useful for testing and monitoring purposes.

The Network Monitor Agent name is composed of the machine name padded with the value 0xBE (rather than the normal space padding) and ending with a suffix value of 0xBE. Microsoft's nbtstat utility has a strange habit of displaying this special padding character as a plus sign ('+').

machine <BF> unique Network Monitor Client Application
The Network Monitor Client Application is the GUI front-end that is used to control, filter, and display NetMon captures.

The Network Monitor Client name is composed of the machine name padded with the value 0xBF (rather than the normal space padding or the 0xBE value used by the agent) and ending with a suffix value of 0xBF. Microsoft's nbtstat utility still has a strange habit of displaying this special padding character as a plus sign ('+').

The NetMon NetBIOS names may not be in use any longer. Newer versions of NetMon (starting with 2.0?) appear to use a different mechanism for communicating.

workgroup <00> group LAN Manager Browse Service
This name is a remnant of an older Browse List distribution mechanism. There are still references to the older system in documents such as the Leach/Naik Internet Draft for Browsing (draft-leach-cifs-browser-spec-00.txt), copies of which can be found by searching the web.
<1B> unique Domain Master Browser
This name identifies the Domain Master Browser (DMB).

A Samba server can behave as a DMB without also being a Primary Domain Controller (PDC). The existence of a PDC promotes the Workgroup to NT Domain status, in which case we write nt_domain<1B> instead of workgroup<1B>. If there is a PDC, it must provide the DMB service for the NT Domain.

Domain Controllers (both Primary and Backup) register the nt_domain<1C> Internet Group name. Registration of the nt_domain<1B> name effectively distinguishes the PDC from all of the other DCs in the domain. The NBNS will ensure that the IP address of the (unique) <1B> name is the first in the list of IP addresses

nt_domain <1C> Internet group Domain Controller
Every domain controller in the NT Domain will register this group name. The NBNS (WINS server) is expected to store all of the IP addresses associated with the name, though it will report at most 25 IP addresses in a NAME QUERY RESPONSE.

The first entry in the list should be the IP address of the Primary Domain Controller (PDC). The rest of the IPs are ordered most recent first. This is atypical handling for group names under WINS. WINS (and, therefore, any NBNS which is WINS-compatible) will usually report only the limited broadcast address ( when queried for a group name.

workgroup <1D> LAN unique Local Master Browser
This name identifies the Local Master Browser (LMB, sometimes called simply "Master Browser") for a subnet. WINS servers (and any NBNS which is WINS-compatible) will accept registration for <1D> unique names, but when queried will always reply with a NEGATIVE NAME QUERY RESPONSE. As a result, the LMB name is unique within its local subnet only.
workgroup <1E> group Browser Election Service
Every node that is capable of acting as a browser registers this group name so that it can listen for election announcements.
\x01\x02__MSBROWSE__\x02 <01> group Local Master Browser
This group name is registered by all Local Master Browsers (LMBs). It allows LMBs on a local LAN to find one another in order to exchange Browse Lists. This is how Browse Lists for multiple Workgroups and/or NT Domains are combined.
username <03> unique Messenger Service
This name is used in the same way as machine<03> described above. A client opens an SMB connection to the Messenger Service (just as would be done with the Server Service), and uses SMB protocol to send the body of the message. The client that displays these messages is known as "WinPopup", and there are dozens of third-party implementations out there.

Some Microsoft documentation lists this name as a group name, which would be nice. Unfortunately, in practice the name is a unique name which means that a single user logged on to multiple machines can only receive messages (sent to the username) on one of those machines.

See also machine<01> and machine<03>.

internetgroup <20> Internet Group User Defined
This name type was probably introduced with Windows2000. Group names with a suffix byte value of 0x20 can be defined as "Internet Group" names, which means that the NBNS must report up to 25 IP addresses per name when queried. The 0x20 Internet Group names are used to identify groups of systems for administrative purposes.
* <00> unspecified Wildcard Name
The wildcard name is composed of an asterisk ('*') followed by fifteen nuls (the last of which is the suffix byte). This name is never registered, so it is neither a unique nor a group name. The wildcard name may be used when sending NBT NAME QUERY REQUEST and NODE STATUS REQUEST messages.
*SMBSERVER <20> unspecified File Server Service
This name is never registered (it begins with an asterisk and is, therefore, an illegal name under NBT). Many implementations, however, will accept it as a valid CALLED NAME in an NBT Session Request message.
INet~Services <1C> [Internet] group Internet Information Server
This name is registered by IIS servers, and handled as an Internet Group name. Note that the name is in mixed UPPER/lower case. It is, in fact, encoded that way, which is a little awkward1.
IS~machine <00> unique Internet Information Server
This name is formed by adding the prefix "IS~" to the machine name, padding with nuls, and using a suffix byte value of 0x00.

The handling of NetBIOS names by IIS is a little unusual. Nul bytes are not supposed to be used as padding except in the wildcard name. There is also a bug (verified in testing against a set of Windows2000 systems running IIS) which causes the suffix byte to be overwritten if the name is longer than 15 bytes2.

For example, adding "IS~" to the machine name "AHOSETHIULLMAN" (13 bytes) would give "IS~AHOSETHIULLMAN", which is 16 bytes long. The correct thing to do is to truncate the string and register the name "IS~AHOSETHIULLMA<00>". Instead, the trailing 'N' in the machine name overwrites the suffix byte, giving "IS~AHOSETHIULLMA<4E>". (The hex value of 'N' is 0x4E.)

IRISMULTICAST <2F> group Lotus Notes
IRISNAMESERVER <33> group Lotus Notes
Forte_$ND800ZA <20> group DCA IrmaLan Gateway Server Service

Special Handling of NetBIOS Names in WINS

The Windows Internet Name Service (WINS) is Microsoft's implementation of the NetBIOS Name Server (NBNS) described in the RFCs. WINS does not match the RFC specifications, however, and its behavior is somewhat quirky. Known quirks are listed below.

Unique Names

Unique names are handled per the RFC specifications with two exceptions: Multi-homed host names and the Domain Master Browser name. Read on...

Multi-homed Host Names

Multi-homed hosts register unique names by sending a special MULTI-HOMED NAME REGISTRATION REQUEST packet to the NBNS. The procedure is described in section of this book. WINS servers (and WINS-compatible NBNS implementations) keep track of the list of IP addresses registered by a multi-homed host, and will report up to 25 IP addresses when queried for the multi-homed host name.

Group Names

By default, in reply to a NAME QUERY REQUEST for a group name, WINS will send the limited broadcast address: This is clearly not what the RFC authors had in mind.

Internet Group, Special Group, and Domain Group Names

There are a few things to be said about these:

Thing 1:  The terms "Internet Group" and "Special Group" are used interchangeably in much of the available documentation.
Thing 2:  Older references use the terms "Internet Group" and "Special Group" when referring to group names with the <1C> suffix. More recent sources add the term "Domain Group" specifically for the nt_domain<1C> names, and expand the use of the other terms to include groups defined by adding a special static entry, with a suffix value of <20>, to the WINS database3.
Thing 3:  Internet (aka. Special) and Domain Groups are defined by using the #SG and #DOM keywords in the LMHOSTS file, or via WINS configuration dialogs on Windows systems.

As with multi-homed host entries, the WINS server should keep track of as many IP addresses per name as it can handle. When queried, the POSITIVE NAME QUERY RESPONSE should list at most 25 IP addresses per Internet Group name.

Local Master Browser

The LMB registers the workgroup<1D> unique name. A WINS server will accept all such registrations, ignoring any conflicts, and will reply with a NEGATIVE NAME QUERY RESPONSE when queried for the name. This behavior forces M and H nodes to search for the LMB on the local IP subnet. If there is no LMB for the Workgroup on the local subnet, then the client that sent the request may call for a browser election. P nodes cannot talk to Local Master Browsers, so they communicate directly with the Domain Master Browser (if there is one).

Domain Master Browser

The DMB registers the unique nt_domain<1B> name. The WINS server will ensure that the IP address associated with the nt_domain<1B> name is always the first in the list of IPs associated with the nt_domain<1C> Domain Group name.

1 As of this writing, Samba's nmblookup tool always up-cases NetBIOS names, so it cannot send a successful query for the INet~Services<1C> name. (Yes, when I get time I'll try to fix that. Maybe. Note that the libcifs nbtquery tool can handle mixed-case NetBIOS names. See

2 I finally got to see this in the wild while trying to solve a browsing problem with Mike Langhus at the University of Minnesota. There were several IIS servers on the subnet, and roughly a third of them had names long enough to cause the suffix byte overwrite problem. I do not know which versions of IIS are affected, but it does not appear as though it causes any real trouble. It's more of a curiousity than a bug.

3 It was difficult to find more than superficial documentation regarding the <20> Internet Group names, which suggests that the feature is not widely used. If you want to dig deeper, search the web for information regarding the #SG and #DOM keywords as used in the LMHOSTS file.

<Previous] [Contents] [Next> [W3C Validated] Copyright © 2002 Christopher R. Hertel 
All rights reserved.   $Revision: 1.30 $