WINDOWS 2000 TROUBLE SHOOTING TCP/I P phần 5 pot

If there is no response from the registered owner of theNetBIOS name, the WINS server will return a “Positive NetBIOS NameRegistration Response” to the WINS client, and its name and IP a

Figure 6.4 Configuring Advanced TCP/IP Properties settings.

Figure 6.5 Enabling the use of an LMHOSTS file for NetBIOS name resolution.

The Windows 2000 Windows Internet Name Service (WINS)

The Windows 2000 WINS server is fully RFC-compliant and includesmany extra features that optimize its use on Windows networks TheWindows 2000 WINS server is also interoperable with “downlevel” (NT)WINS servers, which allows it to peacefully coexist in hybrid Windows2000/Windows NT 4.0 networks

In this section, we’ll examine the types of exchanges that takeplace between the WINS client and WINS server, and look at the WINSProxy Agent

NetBIOS Name RegistrationWhen a WINS client starts up, it will register its NetBIOS name with aconfigured WINS server via a “NetBIOS Name Registration Request.” If theWINS client’s name does not already exist in the WINS server’s database,the WINS server will send a “Positive NetBIOS Name Registration

Response” to the WINS client

If the WINS client’s name is already in the WINS database, the WINSserver returns a WACK (wait for acknowledgement) message to the WINSclient The WINS server then issues a “challenge” (NetBIOS Node AdapterStatus message) to the IP address associated with that NetBIOS name inits database If there is no response from the registered owner of theNetBIOS name, the WINS server will return a “Positive NetBIOS NameRegistration Response” to the WINS client, and its name and IP address

will be recorded in the WINS database If the owner does respond to the

challenge, the WINS client that is attempting to register the name willreceive a “Negative NetBIOS Name Registration Response” and will not beable to initialize its TCP/IP stack

If the computer that is registering its name and the IP address is the same

as the one in the WINS database, it will be treated as a refresh of the WINSdatabase entry, and the renewal date will be updated for the entry

A WINS database entry must be renewed periodically The amount oftime that can pass before the WINS client must renew its name is the

“renewal interval,” which is configured at the WINS server The default forthe Windows 2000 WINS server is 6 days, or 144 hours (This is correct

NOTE

Six days is 144 hours If you have read some of the Windows NT 4.0

books on the market, you might have noticed that many of them state theWindows NT 4.0 WINS server’s default renewal interval was “4 days, or

144 hours.” While you might have figured this was just “WINS new math,”

it was in fact an error in the Windows NT WINS server help file which wasthen perpetuated by the authors of several popular books.)

Figure 6.6 shows the default settings on a Windows NT 4.0 WINS server

Figure 6.6 Default interval settings on a Windows NT 4.0 WINS server.

NOTE

The renewal interval for WINS entries was 96 hours, or 4 days, for the WINSserver included with Windows NT 3.5

Figure 6.7 shows the help file entry for the WINS server This machine

is running Service Pack 5

If a name is not renewed within the renewal interval, the record is

marked as “Released” in the WINS database A released record can be

updated without challenge If the record is not renewed or updated for aperiod of time called the “extinction interval,” the record will be tombstonedand removed from the WINS database during scavenging We’ll cover scav-enging and tombstoning later in the chapter

Figure 6.7 Help file on the Windows NT 4.0 WINS Server renewal intervals.

NetBIOS Name Query RequestWhen a WINS client needs the IP address of a destination host, it will

send a NetBIOS Name Query Request to the WINS server If the WINS

server has a mapping for the NetBIOS name sought after, it will return

the IP address in a Positive NetBIOS Name Query Response If it does not have the name ,it will return a Negative NetBIOS Name Query Response.

If the first WINS server that is queried does not contain a mapping,the WINS client will move through a list of “Secondary WINS servers” andquery each one of those in turn until one of the Secondary WINS serversreturns a Positive Name Query Response The Windows 2000 WINS clientservices allow you to enter up to 12 Secondary WINS servers While thisleads to a greater degree of fault tolerance for your WINS queries, youshould exercise care when assigning multiple WINS servers If you config-ure a client to use 10 Secondary WINS servers, and none of them have amapping for the destination host, you will have to wait for all of these

WINS servers to be queried before moving to the next step in the NetBIOSname resolution process Multiple Secondary WINS servers, therefore,should be considered a double-edged sword.

NetBIOS Name Release

When a WINS client is shut down “gracefully,” it will issue a NetBIOS

Name Release message to the WINS server with which it registered its

name This will mark the NetBIOS name as inactive and will allow othermachines to use the name without a challenge If the WINS client is notshut down gracefully, the release message will not be sent, and anothercomputer will not be able to use the name without first going through thechallenge process

Multihomed Computers and WINS

What about multihomed machines? How do they register their name with

a WINS server?

There are different types of multihomed machines One type has tiple IP addresses bound to a single network card In this arrangement,only the first IP address assigned to the machine will be registered withthis machine’s NetBIOS name in the WINS database

mul-The second type of multihomed machine is more common: a machinewith multiple network adapters, each with a single IP address assigned to

it Each adapter will register its NetBIOS name and IP address with theWINS server, and the WINS server will mark these entries for the multi-

homed computer as a multihomed name registration

When the WINS server receives a NetBIOS Name Query Request forthe NetBIOS name of the multihomed machine, it will send all the IPaddresses it has registered to that NetBIOS name Now that the client has

a bunch of IP addresses to choose from, how will it decide which one touse?

If one of the IP addresses returned by the WINS server is on the samesubnet as the computer that made the request, it will try to connect tothat IP address first If multiple IP addresses are returned that are on thesame subnet, it will pick one of those at random If none of those in the list are on the same subnet, then, again, an IP address will be chosen atrandom

For multihomed WINS servers, Windows 2000 does not guarantee thebinding order for NetBIOS when more than one connection is present andactive A multihomed WINS server should have all installed connectionsconfigured as routable interfaces

A multihomed WINS server must have its primary IP addressesassigned to each network connection (assuming you’ve configured morethan one IP address per connection), and you should configure eachprimary IP address as Push and Pull partners at other servers that willreplicate with the multihomed WINS server Each IP address should beconfigured as a replication partner to all other WINS servers that it will

be partnering with When configuring replication partners, you canensure that a specific network connection is used if you specify an IPaddress for the remote multihomed server you are adding at a WINSserver

If you enter a NetBIOS name instead of IP addresses, when replicationpartners are specified and resolved by a name entered in the WINS con-sole, it is possible that a packet generated by WINS could use any of theinterfaces and their respective IP addresses This apparently randombehavior results from WINS referring to its local IP routing table, whichcontains all of the installed interfaces, before it sends packets to theremote server

WINS Proxy Agents

A WINS Proxy Agent is a machine configured to listen for NetBIOS NameQuery Requests and forward these to a WINS server WINS Proxy Agentsare useful when you have non-WINS-enabled machines on a segment thatneed NetBIOS name resolution services

When a non-WINS-enabled machine (which includes b-node clients)issues a NetBIOS Name Query Request, the WINS Proxy Agent interceptsthe request and forwards it to its configured WINS server If the WINSserver contains a mapping for the NetBIOS name in question, it will send

a Positive NetBIOS Name Query Response to the WINS Proxy Agent,which in turn sends the answer to the machine that issued the broad-cast The WINS Proxy Agent also caches the successful query If a subse-quent request for the same NetBIOS name is broadcast again, the WINSProxy Agent will be able to answer the request from its cache, rather thanreferring the request to a WINS server

A question that comes up from time to time is how to alter the Proxy’sname cache timeout The WINS Proxy Agent uses the NetBIOS RemoteName Cache Table for that computer, thus you can configure theCacheTimeout parameter in the Registry, mentioned earlier, to customizethe WINS Proxy Agent’s cache settings

WINS Configuration Issues

After a WINS server is installed, a certain amount of configuration needs

to be accomplished While this book isn’t about installation and ration of Network Services, some configuration issues are worth mention-ing in the context of trouble prevention and troubleshooting (For

configu-complete coverage of installation and configuration of Windows 2000Network services, we highly recommend “Managing Windows 2000

Networking Services” published by Syngress Media.)

Static Mappings

One of the great strengths of WINS is that it is a dynamic database.Unlike an LMHOSTS file that has to be manually updated every time amachine changes its IP address, WINS clients automatically update theirrecords in WINS This is especially wonderful in an environment that uti-lizes DHCP, where managing LMHOSTS files would quickly wear down theresolve of even the staunchest of network administrators

However, non-WINS clients are not able to register themselves with theWINS server If you have non-WINS clients running NetBIOS applications,you may want to include their names in the WINS database so that WINS-enabled clients can query the database and find the IP addresses of thenon-WINS enabled clients To do this, you must enter a “static mapping”for each non-WINS client into the WINS database

Static mappings allow WINS clients to find these non-WINS ers’ IP addresses by performing WINS queries This circumvents the need

comput-to create and distribute LMHOSTS file entries for the non-WINS clients

TIP

WINS servers do not respond to NetBIOS Name Query Request Broadcastmessages Several times, we have encountered a “problem” with a WINSserver that was not “responding.” In each case, the WINS server was on thesame segment as the WINS clients The administrators felt that since theWINS server was on the same segment as the clients, the WINS servershould be able to respond to the Name Query Request This is not the case.Therefore, if you have non-WINS clients that must resolve NetBIOS namesfor remote nodes, you should install a WINS Proxy Agent on the subnetwith the non-WINS clients, regardless of whether there is a WINS server onthat subnet or not

Problems with Static WINS Entries

Static mappings should only be used for non-WINS clients thatintend to stay non-WINS clients Some administrators may importLMHOSTS files and create static mappings for computers that havethe capability to be WINS clients If you do this, you should enablethe “Migrate On” setting

By default, static entries are not overwritten by dynamic nameregistrations If you decide to WINS-enable clients that were not for-merly WINS-enabled, they will not be able to dynamically updatetheir WINS records However, if you enable Migrate On at the WINS

servers, static entries will be overwritten by dynamic name

This problem is further exacerbated by replication of the staticentry When a static record is replicated, its status as a static record

is replicated with it This means that you must delete the record at

all WINS servers, to prevent it from being rereplicated back to a

machine from which it had been deleted In NT 4.0, after the entrywas deleted from all the WINS servers, you had to restart the domaincontroller However, Windows 2000 allows you to reregister theWINS client by using the nbtstat –RR command

For IT Professionals

WINS ReplicationNetworks with more than a single WINS server will need to synchronizethe contents of the WINS database among all WINS servers on the net-

work This process of database synchronization is accomplished via WINS

replication.

The WINS replication process ensures that every WINS server on anetwork has WINS database records for all the WINS servers on the net-work In this way, it shouldn’t matter what WINS server you query,

because all WINS servers will contain the same database records

When a computer registers its NetBIOS name and IP address with itsPrimary WINS server, that server is called the “owner” of that record Therecord is also given a “version ID.” The most recent record registered at aWINS server defines the most recent version ID of the WINS database.When a WINS server replicates its records to other WINS servers, onlyrecords with higher version IDs than the ones contained on the otherWINS servers are replicated, because those are the only ones that havechanged since the previous replication The owner of a WINS record hasthe highest version ID for each record that it owns If this is not the case,then something strange is going on, and you need to investigate!

Partnership Agreements

WINS servers replicate their information by forming partnerships Thereare two types of partnerships you can form between WINS servers: Pulland Push When a WINS server is a Pull partner of another WINS server,

it will send an update trigger to its partner on a periodic basis This is

configured at the WINS server that is the Pull partner When a WINS

serv-er is a Push partnserv-er to anothserv-er WINS sserv-ervserv-er, that WINS sserv-ervserv-er sends anupdate trigger when a certain number of records or “version IDs” havechanged

In general, Microsoft recommends that you configure Windows 2000 WINSservers to be both Push and Pull partners of each other However, there may

be times when you prefer to configure WINS servers to be only Pullpartners This would be the case when WINS servers are separated by slowWAN links, and you wish to minimize the traffic on the WAN link duringbusy times of the workday In this case, you configure the WINS servers to

be Pull partners of each other, and configure the replication trigger to besent during the quiet times of the evening or early morning

Each WINS record is about 40 bytes when replicated If you have 1000updated WINS records to replicate, that would require about 40,000bytes, or 40KB That’s not very much traffic, even for a 56 Kbps WANlink However, if you had 10,000 WINS updates to send during a replica-tion, that would be about 400,000 bytes, or 400KB This would make animpact on a 56 Kbps WAN link, since it transfers less than 7 KBps

NOTE

In actual practice, the transfer of 400KB would take about two minutes

on a typical analog modem Depending on the type of responsiveness youexpect from your link, this may or may not be acceptable Remember that it

is unlikely that an organization of 10,000 computers will have all of themupdate their records simultaneously The only time this might occur is ifthere was a large-scale power outage, and all the machines updated theirWINS records at the same time when coming back online This is somewhatunlikely, but you should be prepared in case it happens

It’s easy to get confused when we start talking about kilobits (abbreviated

as “kb”) and kilobytes (abbreviated as “KB”) Just remember that (in mostcomputer systems) a byte equals eight bits A bit consists of a single binarydigit, 0 or 1

WINS partnerships are configured in the WINS management console,which you can access via the Administrative Tools menu (see Figure 6.8).Note the “Unknown” WINS server names These WINS servers were addedvia WINS Autodiscovery, and their NetBIOS names are not included onthe Replication Partners list, just the IP addresses

NOTE

Figure 6.8 The WINS management console.

Right-clicking the Replication Partners node in the left pane of theconsole and clicking Properties will bring up the Replication PartnersProperties dialog box Click the Push Replication tab and you will see thedialog box shown in Figure 6.9

Now click the Pull Replication tab and you see something similar toFigure 6.10.

Figure 6.9 The Push Replication settings in the Replication Partners Properties

dialog box

Figure 6.10 The Pull Replication settings in the Replication Partner Properties

dialog box

This all seems pretty straightforward However, after you have ured Push and Pull partners, right-click on one of the partners in theright pane, and then click Properties You will see the box shown inFigure 6.11.

config-Figure 6.11 Replication Properties for a specific replication partner.

If you’re thinking the figures appear to be different, you are correct Inthis first case, when you right-clicked on the Replication Partners node in

the left pane, you were setting defaults for all replication partners for this

WINS server You can get more granular control over replication ters by setting replication parameters for each WINS server separately

parame-This is something to keep in mind when replication intervals do notappear to be what you thought they should be

WINS Partner Autodiscovery

Do you find the whole process of figuring out what WINS servers to makepartners, and then configuring the replication parameters, a little confus-ing? There may be some help for you Windows 2000 WINS servers can beconfigured to find other WINS servers by using an Autodiscovery process

A WINS server configured to find its own replication partners will cast IGMP messages to a multicast group with the group address of224.0.1.24

broad-The 224.0.1.24 group address is reserved for Microsoft WINS servers

This multicast will take place every 40 minutes by default, but theinterval can be configured via the WINS console Each member of thegroup will respond to the multicast announcement with its IP address.After the partners are automatically discovered, they will be set up asPush and Pull partners Then Pull replication triggers will be sent everytwo hours to discovered partners

Autodiscovery is best used in small LANs where two WINS servers arelocated on a single segment You can use automatic partner configuration

in a routed environment by opening up the routers to IGMP multicasttraffic to the WINS group address The amount of broadcast traffic for anetwork with two or three segments would be minimal After the partnersare discovered, you can then configure replication parameters on anindividual basis

If you choose to take advantage of WINS autoconfiguration on a mented network, you can control how many hops the multicast messagewill extend Go to the Registry and open:

seg-HKLM\System\CurrentControlSet\Services\WINS\Parameters

Open the McastTtl entry The default value is two hops, with a limit

of 32 Note that this is different from the default value of six hops seen inWindows NT 4.0

In a larger WINS network with many routed subnets, WINS automaticreplication would create more problems than it’s worth, both from themulticast traffic standpoint, and the WINS replication architectural view-point

WINS Network Topologies

According to Microsoft recommendations, you only need one PrimaryWINS server and one Secondary WINS server for every 10,000 computers

on your network

NOTE

TIP

Microsoft documentation even goes so far as to recommend that you callMicrosoft Consulting Services if your network installation consists of morethan 20 WINS servers In reading this documentation, you almost get a sense

of urgency about this issue Why would Microsoft be so concerned about thenumber of WINS servers deployed by an organization? Based on our ownconsulting experiences, here’s a guess: Many organizations employ far toomany WINS servers than they actually need, and in the process of deployingthese redundant WINS servers, problems in WINS database synchronization

“pop up.” Many companies with multiple WINS servers create Push and Pullpartner relationships in an almost arbitrary fashion

This does not optimize WINS database consistency throughout theorganization Microsoft may be trying to “head trouble off at the pass” byurging customers to call before getting themselves into this sort of situation

A WINS network topology needs to be defined for any company withmore than two WINS servers The preferred WINS topology is the “Spokeand Hub” arrangement

Spoke and Hub topology

In the Spoke and Hub model, one WINS server is chosen to be a “Hub” WINSserver This Hub collects WINS updates from all the other “Spoke” WINSservers After collecting all the WINS changes on the network, the Hub WINSserver is able to replicate the collective knowledge of all the WINS servers onthe network This model is similar to the relationships between the DomainMaster Browser and Master Browser(s) on a multiple segment network

If your organization contains multiple, geographically disparate sites,you will need to put together a WINS replication model for each site, andanother model for intersite WINS replication

Intrasite replication should be based on the Spoke and Hub model Asingle WINS server at each site is selected as a Hub WINS server All otherWINS servers are Spoke servers, and they are configured to be both Pushand Pull partners of the Hub WINS server By employing the Hub andSpoke model, you can simplify the replication partnerships, and beassured that all WINS servers will receive updates to changes in eachWINS server’s database

Push and Pull Partnerships

Microsoft recommends that you always configure machines as Push andPull partners when they are separated by fast LAN connections WhenWINS servers are located across relatively slow WAN links, it is

NOTE

sometimes preferred to have them configured as Pull partners only.For example, imagine that your company consists of 7500 computersdistributed among three geographically separated sites The main head-quarters is located in Dallas, Texas, where there are 3500 machines Youalso have regional headquarters located in Los Angeles, California andPortland, Oregon Each of the regional offices has 2000 computers Yournetwork is a Windows-based network, and all computers are capable ofbeing WINS clients.

You have been asked to create a WINS network to accommodate two ferent scenarios The first scenario has the remote sites connected to theDallas site, but not to each other The second scenario has all the sites con-nected to each other with WAN links of equal speed

dif-In this first scenario, we would select a single WINS server as a site Hubfor Dallas, Los Angeles, and Portland The remaining Spoke WINS serverswithin each site would be configured as Push and Pull partners of theirrespective Hub server This configuration assures full replication of WINSdatabase entries among all WINS servers within each site

To ensure WINS database consistency among all WINS servers inthe organization, the Hub servers need to replicate their WINS data-bases We will create another Spoke and Hub arrangement among thesite Hubs, using the Dallas WINS server as the “Hub of the Hubs.”Dallas is chosen as the Hub-Hub server because each remote site isconnected to Dallas via WAN links, but the remote sites are not con-nected to each other The remote sites are configured as Pull partners

to the Dallas hub to minimize impact on the WAN links By using thisconfiguration, all changes are pooled at the Dallas WINS server Thesechanges are then distributed back to the remote Hub servers, whichthen distribute the changes back to their respective Spoke WINS

servers This design is seen in Figure 6.12

The major drawback of using a single central Hub server for nizing all the Hubs across the WAN is that it there is a single point of fail-ure If the Dallas server becomes unavailable, no WINS database

synchro-replication takes place across the WAN until it comes back online Thiscan have a major impact in destabilizing the WINS synchronization

scheme, because in order to bring all the WINS servers back into rium, we have to take into account not only the time to bring the downedWINS back online, but also the convergence time for all the sites We’lltalk about convergence time a little later in this chapter

equilib-In the second scenario, we have WAN links of equal speed connectingall three sites Intrasite replication would be configured in the same fash-ion as seen in the first scenario, using a central Hub server setup as aPush and Pull replication partner to the remaining Spoke servers Thisdesign is seen in Figure 6.13

Figure 6.12 Hub servers replicating with a central server.

Los Angeles Hub Portland Hub

Dallas Hub

Spoke Server

Spoke Server

Spoke Server

Spoke Server

Spoke Server

Spoke Server

Spoke Server

Central Hub

Remote WINS act as Spokes for Dallas Central Hub WINS

Figure 6.13 Each site Hub replicates with adjacent Hubs.

Los Angeles Hub Portland Hub

Dallas Hub

Spoke Server

Spoke Server

Spoke Server

Spoke Server

Spoke Server

Spoke Server

Spoke Server

Ring Replication

Each Hub Server Replicates with its Adjacent Hub Server

However, the Hub servers would be configured in a “Ring,” whereeach adjacent member in the ring is configured as a Pull partner of theother This arrangement avoids a single point of failure Also, in thisthree-site scenario, convergence of the WINS database takes place morequickly.

Convergence Time

Convergence time represents the total time it would take for a

changed WINS record to be replicated to all the WINS servers on thenetwork Let’s continue with the scenarios we’ve been working with

In the first scenario, all site Hubs were connected to the central

Dallas Hub If the intrasite Pull interval was 5 minutes, and the site Pull interval was 15 minutes, what is the maximum time required

inter-to get an updated WINS record from a machine in Portland inter-to a

machine in Los Angeles?

The answer is 40 minutes It would take 5 minutes to get thechanged record from a Spoke server in Portland to the Portland Hub.Then it would take up to 15 minutes to get the record from the

Portland Hub to the Dallas Hub Then another 15 minutes would pass

to get the record from the Dallas Hub to the Los Angeles Hub, andfinally another 5 minutes to replicate the record from the Los AngelesHub to the Los Angeles Spoke The WINS intersite “hop count” wastwo: one hop to the Dallas Hub, and a second hop from the Dallas tothe Los Angeles Hub

What is the convergence time in the second scenario? All site Hubsare only one hop away from any other site Hub For a changed WINSrecord to get to Los Angeles, it would take 5 minutes for the PortlandSpoke to get the information to the Portland Hub, then 15 minutes forthe Portland Hub to the Los Angeles Hub, and then 5 minutes fromthe Los Angeles Hub to the Los Angeles Spoke, for a total of 25 min-utes It would appear that the Ring model is more efficient, as well asbeing fault tolerant

However, the speed of convergence is related to the number ofintersite hops (assuming all intrasite hops are always equal to 1, andthe Pull interval is the same for all intrasite servers) A ring of fourintersite Hubs would have a maximum hop count of 2 and a maxi-mum convergence time of 40 minutes, as seen in Figure 6.14 Thesame would be true of a five-node intersite setup So, using the Ringreplication model appears to be equal, or superior to the Hub modelfor networks of up to five sites

But what happens in our five-intersite model if one of the sites goesdown? The maximum hop count is no longer 2; it is now 3, as shown inFigure 6.15.

The convergence time in the five-intersite Hub model with one downedsite is now 50 minutes and requires three hops! In the example in Figure6.15, the convergence time is now 50 minutes

When planning your WINS networks, think about the level of fault erance required for NetBIOS name resolution using WINS

tol-As time passes, reliance on WINS and NetBIOS should lessen as cations and network clients are upgraded to Windows 2000 In a pureWindows 2000 environment, WINS can be done away with entirely as theWindows 2000 computers will be able to use DDNS (which, like WINS, isupdated dynamically) instead

appli-Figure 6.14 A four-node Ring has a maximum intersite hop count of 2.

Backing Up the WINS Database

The Windows 2000 WINS server automatically backs up the WINS database

to a folder of your choice every three hours The rub here is that you mustconfigure this directory first before the WINS server will automatically back

up the WINS database To configure WINS backup, open the WINS console,right-click on the name of your WINS server in the left pane, and click

Properties You will see the dialog box that appears in Figure 6.16

In Figure 6.16, you can see that a directory named WINSBAK on driveC: is dedicated to the WINS backup files The WINS server does not createthis directory You must first create the physical directory on the server’shard drive, and then come to this dialog box and type in the path to thebackup directory that you created

For fault tolerance reasons, you might think it would be a good idea toput the backup files on a mapped network drive In that way, you couldquickly access them in case of a hard disk crash Unfortunately, thiswon’t work, as the WINS service will not save backup copies of the WINSdatabase to a remote location Be sure to include your backup directory

in your normal tape backup procedure, and all will be well

Figure 6.15 A five-node Ring with one downed site has a maximum hop count of 3.

5 min

15 min

15 min

The best practice is to have the WINS server back up its database,and then you “back up the backup.” You might even consider a specialbackup schedule for the files in the WINS backup folder that you’ve speci-fied On more than one occasion, we’ve seen the look of dismay on theface of a network administrator after a server crash when there were noWINS backups on hand It’s not a pretty sight.

Backing Up the WINS Registry Settings

If you have a relatively complex WINS replication scheme, you should alsoback up the WINS server’s Registry settings You can do this by openingregedt32 from the run command, and then navigating to:

HKLM\System\CurrentControlSet\Service\WINS

Some people have told me that they don’t think backing up a WINSdatabase is that important Their reasoning is that all the WINS clients willend up reregistering themselves again with the WINS server, and the rebuiltWINS server will get replicated copies of all other WINS entries as well

While this is all true, be forewarned that you will end up with quite a bit ofadditional network traffic if you choose this option Replication partnerswill have to send all the records that they own, as well as records withversion IDs higher than ones that have already been replicated to therebuilt WINS server This can take quite some time as the WINS database isreconverged Also, WINS clients that reregister with the rebuilt WINS serverwill need to create new WINS records on that server, and these records willneed to be replicated as new version ID records with the rebuilt server’sreplication partners

NOTE

Figure 6.16 The WINS server Properties dialog box.

Then click the Registry menu, and click Save Key Back up the savedkey to a safe place When you need to rebuild the WINS server, open theRegistry editor on the new machine, click the Registry menu, and clickRestore This will copy the saved key into the new Registry.

Scavenging the Database

The WINS database contains both active and inactive records Over time,this database can grow very large, with many of the entries no longerbeing used In order to clean up the “garbage” in the database, the WINSserver goes through a periodic scavenging process When the database isscavenged, obsolete records are removed; this shrinks the size of the file.The advantage is that smaller WINS databases can be searched morequickly and will improve WINS record registrations and queries

WINS will automatically scavenge and remove tombstoned recordsbased on the intervals set in the WINS server Properties sheet If a WINSclient fails to renew its record during the period of time called the “renew-

al interval,” the record is marked as inactive The record will remain inthe inactive state for a period called the “extinction interval.” If the record

is not updated during the extinction interval, it will be tombstoned Therecord remains in the tombstoned state for a period called the “extinctiontimeout.” After the extinction timeout passes, the record will be automati-cally scavenged from the database (will be deleted)

After the records are removed, you may be surprised to find that thedatabase is still about the same size This is because empty fields are stillrepresented in the database You must compact the database to regaindisk space and speed database searches

If you choose to manually compact the database, be sure to stop theWINS server first You can stop the WINS server by opening a command

prompt and typing net stop wins, or from the WINS console by

right-clicking your WINS server in the left pane, tracing down to All Tasks, andthen tracing over and clicking Stop Then restart the WINS server aftercompacting by clicking Start at the same location you clicked Stop Or,

from the command prompt, type net start wins.

Interactions with DNS Servers

As discussed earlier, you can configure DNS servers to resolve NetBIOSnames to IP addresses Configuring a DNS server to do this is simple

WINS will automatically compact the database when the WINS server is not

in use If the database size reaches a size of more than about 40MB, youshould manually compact the database using the jetpack.exe commandfrom the command prompt

TIP

Figure 6.17 The WINS tab in the forward lookup zone Properties dialog box.

Searching the Windows 2000 Help files and TechNet for guidance on how

to compact the Windows 2000 WINS database will leave you with an emptyfeeling inside To manually compact the Windows 2000 database, do thefollowing:

■ At the command prompt, type net stop wins and press ENTER

■ Change to the %systemroot%\system32\wins directory

■ Type jetpack wins.mdb tmp.mdb.

■ The jetpack engine will inform you that the process has completed successfully

■ Restart the WINS service by typing net start wins at the command

prompt

Configuring the DNS Server to Use WINS Forward Lookup

Open the DNS management console, and right-click one of your forwardlookup zones Note here that in order to enable a DNS server to do a WINS for-ward lookup, you must have at least one forward lookup zone enabled Afterright-clicking one of the forward lookup zones, click Properties and then clickthe WINS tab You will see a dialog box like the one in Figure 6.17

After you’ve put a check mark in the “Use WINS forward lookup” andentered an IP address in the “IP address” box, the DNS server will searchfor NetBIOS name and IP address mappings at a WINS server

However, it’s not always quite as simple as that You might wonderhow the DNS server knows that you are searching for a NetBIOS name

And how does it know when it’s time to check the WINS server database

to resolve a NetBIOS name? Does the DNS server just strip off everything

to the right of the leftmost period in a fully qualified domain name

(FQDN), and send what’s left to the WINS server? Does it send everyunqualified name to a WINS server directly?

Wow, those are good questions To answer them, we need to get a ter idea of how DNS clients send queries to a DNS server, and what kind

bet-of information is sent to the DNS server from the DNS client when itsends a DNS query

Examining DNS Configuration Settings

Open the TCP/IP Properties sheet, and click ADVANCED as you did earlier

in the chapter Click the DNS tab You will see a dialog box like the onethat appears in Figure 6.18

Figure 6.18 The DNS tab in the Advanced TCP/IP Settings Properties sheet.

The DNS server addresses section is straightforward: Those are the IPaddresses that DNS queries are sent to The top one is the first DNS serv-

er to be queried, and if it returns a “host not found” message, the nextDNS server will be queried Those other settings have been somewhat of a

mystery to some NT administrators in the past, and for the most part,were usually ignored However, if you know the meanings of the otheroptions, you will be able to troubleshoot problems with your WINSlookups (and DNS lookups) more easily.

Resolution of Unqualified Names

The first option button that says “Append primary and connection specific

DNS suffixes” causes a DNS query for an unqualified DNS request to

automatically append the machine’s domain membership and a tion-specific domain membership to the request

connec-For example, if my machine belongs to the tacteam.net domain, and I

type http://blah in my browser’s address box, this represents an

unqual-ified domain name, because no domain suffix is included in the request.Since DNS servers need to know what zone database to check, you mustinclude a domain name in the request My machine belongs to thetacteam.net domain, so the request issued to the DNS server is actuallyfor blah.tacteam.net, and the DNS server will attempt to resolve thatname first (If I had included another domain name in the “DNS suffix forthis connection:” text box, it would send another query for blah.<connec-tion_specific_domain>.)

Each network interface card (NIC) can be assigned its own domainsuffix to send that is independent of the machine’s domain member-ship

Determining Domain Membership

How do you know your machine’s domain membership? Right-click on

My Computer, click Properties, then click the Network Identificationtab You will see something similar to the dialog box shown in Figure 6.19

All right, now that we’ve got all that down, let’s look at another

unqualified DNS query This time, we’ll type http://DAEDALUS into the

Web browser’s address box The DNS query is sent to the Preferred DNSserver as daedalus.tacteam.net The tacteam.net domain does not contain

a resource record for a computer named DAEDALUS, so it strips offeverything to the right of the leftmost period in the FQDN and only sendsthe host name portion to the WINS server The WINS server will check for

“DAEDALUS” in its database, and if a NetBIOS mapping exists, it isreturned to the DNS server The DNS server then returns the IP address

to my computer, and the http request is made to that IP address

Problems with Heterogeneous DNS Environments

If you are running a mixed DNS environment that includes both Microsoftand non-Microsoft servers, you might have trouble with zone databasereplication between a Microsoft Primary DNS server and non-MicrosoftSecondary DNS servers if the “Do not replicate this record” check box isnot marked Non-Microsoft DNS servers won’t know what to do with theWINS-enabled zone, and may reject it So, if you have a mixed DNS envi-ronment, you must leave that box checked, and not allow WINS lookupsfor the zone

The way around this problem is to create a zone dedicated for WINSlookups For example, if we were running a mixed DNS environment here,

I would create a wins.tacteam.net zone, and then I would configure theclients (either manually or using DHCP) to append the wins.tacteam.netdomain suffix to their DNS queries by including it in the DNS suffixsearch order Here’s how it works:

You type the name http://EXETER into your Web browser The

wins.tacteam.net domain suffix is appended to the DNS query When theDNS server receives the query, it will look for a resource record in thewins.tacteam.net zone database It won’t find one, because we will notinclude any host records in that zone

Figure 6.19 The Network Identification tab in the System Properties dialog box.

Since the wins.tacteam.net server doesn’t have any resource recordsfor that zone, it will then query the WINS server If the WINS server has amapping for that NetBIOS name, it will be returned to my computer, and

I can establish a connection to the Web server on EXETER In the domainsuffix search order, I would put tacteam.net on top of the list, and thenthe wins.tacteam.net under it This ensures that if there is a machinewith the name exeter.tactem.net on the network, its host name will beproperly resolved If I had placed wins.tacteam.net on the top of thedomain suffix search order, EXETER would have been sent immediately

to the WINS server for resolution

This brings up another problem What if I had two zones, such as:

dev.tacteam.net sales.tacteam.net

These are in addition to the wins.tacteam.net zone Now imagine thatthere is a host record for EXETER in the sales.tacteam.net zone For com-puters in the dev.tacteam.net domain, I want the DNS server search order

to be:

dev.tacteam.net sales.tacteam.net wins.tacteam.net

For machines in the sales.tacteam.net domain, I want the DNS serversearch order to be:

sales.tacteam.net dev.tacteam.net wins.tacteam.net

All zones are enabled to perform WINS lookups What happens when Isend a DNS query for EXETER from a machine located in the

sales.tacteam.net domain? Since all machines in the sales.tacteam.netzone will append sales.tacteam.net to unqualified domain names, it willfind a host record for EXETER and send the IP address of

EXETER.sales.tacteam.net

But what happens when I send a DNS query for EXETER from amachine in the dev.tacteam.net domain? The request will appenddev.tacteam.net to the DNS query, and send a request for

EXETER.dev.tacteam.net to the DNS server Since there is no host recordfor EXETER.dev.tacteam.net in the dev.tacteam.net zone, it will issue aquery to the WINS server If the WINS server has an entry for a machinethat has a NetBIOS name of EXETER, it will send that IP address Butwhat if the machine with the NetBIOS name of EXETER is not the samemachine as EXETER.sales.tacteam.net? Then, you will end up connecting

to a different IP address from the one that the computer located in thesales.tacteam.net domain connected to!

Although this is a rare problem that you would only see if you named

a computer with different NetBIOS and host names, we can avoid theproblem altogether by disabling WINS lookups on all zones but the WINSreferral zone

Enabling WINS Lookups on the Referral Zone Only

What happens when we only enable WINS lookups for the WINS referral zone?For the machine located in the sales.tacteam.net domain, the DNSquery will be sent as EXETER.sales.tacteam.net Since there is a hostrecord for that computer, the IP address will be returned to the request-ing client For a machine located in the dev.tacteam.net domain, a querywill first be sent for EXETER.dev.tacteam.net, and no record will be

found The machine will issue another query for

EXETER.sales.tacteam.net, and will receive the IP address for

EXETER.sales.tacteam.net Now everyone who issues an unqualified DNSquery will access the same machine!

Only when there are no host records for a machine in any of the zones willthe wins.tacteam.net domain suffix be appended Only then will the WINSserver be queried in response to a client’s DNS request

Pointing WINS Servers to Themselves

When you set up a new WINS server, you will eventually have to configureits TCP/IP properties One of the configuration options you routinelymust set is the Primary and Secondary WINS servers’ addresses Sinceyou know that it is good practice to set different WINS servers as a

Primary and a Secondary, you might configure the WINS server with itsown address as a Primary, and then another WINS server as a Secondary

If you have done this, you might have also experienced some unexplainedauthentication attempts and browser service problems And, if you’re likemost administrators, you’ve probably chalked it up to the vagaries of theNTLM authentication process and the equally unpredictable behavior ofthe browser service

However, some of the problems might lie in the fact that you didn’tconfigure the WINS server’s Primary and Secondary WINS server address-

es to point to itself This can lead to problems related to “split tions” of NetBIOS services The problems are compounded when thesesplit registrations are replicated to other WINS servers

registra-TIP

Problems Arising from Split Registrations

Let’s look at an example You are installing a new WINS server, and give itthe NetBIOS name NEWWINS You install the WINS service and then go tothe TCP/IP Advanced Properties dialog box on this new WINS server Youconfigure this new WINS server’s Primary WINS server address to point toitself, say 192.168.1.185 Then, because you want WINS resolution on thisserver to be fault-tolerant, you configure the Secondary WINS server’saddress to be 192.168.1.16, the address of another WINS server on yournetwork Now, just for laughs, imagine that the machine we’re setting up

is also the Primary Domain Controller (PDC) for your organization

When you restart NEWWINS, it will begin to register its NetBIOSnames with its Primary WINS server Since the WINS server service willnot have started when the machine begins registering its NetBIOS names,

it will switch over to the Secondary WINS server after three failedattempts But here’s the catch: While the computer is registering itsNetBIOS services with the Secondary WINS server, it is still trying to con-tact its Primary WINS server When the WINS service initializes on

NEWWINS, it will suddenly find that its Primary WINS server is now available and will begin to register its NetBIOS names with itself As youcan see, some of NEWWINS NetBIOS services have been registered withits Secondary WINS server over at 192.168.1.16, and some of its serviceshave been registered with itself (as its Primary WINS server) at

192.168.1.185 So what? Well, imagine that the following NetBIOS nameswere registered with NEWWINS:

On the network, some clients will have their Primary WINS server set

to look at NEWWINS at 192.168.1.185, and some clients will be ured to query NEWWINS’s Secondary server at 192.168.1.16 Now, let’ssay a machine needs to connect to a network share on NEWWINS, and itqueries the WINS server at 192.168.1.16 for the NetBIOS name

config-NEWWINS[20h] to the IP address mapping for its server service Whoops!There isn’t one! That NetBIOS name was registered over at

192.168.1.185 The client will not be able to connect to any networkshares on NEWWINS because it cannot find an entry for its server service

Now, let’s make it even more exciting Imagine that a Master Browser

on another subnet queries NEWWINS at 192.168.1.185 for the location ofthe Domain Master Browser Whoops again! The NetBIOS domain nameregistration for that service was sent to 192.168.1.16! Now the browse listcannot be synchronized with the Master Browser of that subnet

The problems become even more complex when the WINS serversbegin to replicate their databases Look at Figure 6.20 and examine thereplication layout and the locations of NEWWINS and its Secondary WINSserver at 192.168.1.16

Figure 6.20 Replication layout for NEWWINS and its Secondary WINS server.

resources

While this situation might seem unusual, something that we have notfound uncommon is disparate entries for the Primary and SecondaryWINS servers on a WINS server It’s also not unusual to find that organi-zations are running WINS servers on their PDCs (regardless of the wis-dom—or lack thereof—of this action)

Keep this possibility in mind the next time you run into “strange”

behaviors related to authentication and access to network shares for yourdownlevel clients

Authentication issues related to NetBIOS name registration problems arenot an issue for Windows 2000 clients, since they search the DNS server fordomain controllers, not WINS servers Additionally, Windows 2000 clientswill still be able to access shared resources that are published in theDirectory, even without WINS, since this is a DNS operation as well

However, many organizations will be running at least some Windows 9x

and NT client computers on their Windows 2000 networks for many years

to come

The Browser Service, WINS and Multihomed Masters

The Browser service is a NetBIOS-based service that provides a “browselist” for the user to access shared network resources via the “My NetworkPlaces” application

How the Browser Service Works

When a server on the network starts up, it broadcasts that it is runningthe server service, and its name is added to the browse list

In this context, “server” means any computer that is configured to share itsresources over the network It does not have to be running the Serveroperating system

A computer can take on one of several roles in order to make thebrowser service work Typically, the PDC Emulator will take on the role ofthe “Domain Master Browser.” The job of the Domain Master Browser is

to collect browse list information gathered from all subnets

NOTE

NOTE

A Master Browser is a computer designated on each segment to collectinformation about all servers on that segment Each segment will haveone Master Browser (on the segment where the Domain Master Browserresides, it will act as both Domain Master and Master Browser for its seg-ment) A “Backup Browser” receives the browse list from the MasterBrowser on its segment.

When a client requests the browse list, a broadcast is sent to the ment This broadcast message is intended for the Master Browser TheMaster Browser responds to the request by providing the client with thenames of up to three Backup Browsers The client then requests thebrowse list from a Backup Browser, which sends the list to the client All these communications take place via NetBIOS broadcast messages.Because these are NetBIOS broadcasts, they will not usually pass

seg-through the network gateways

Role of the Domain Master Browser

In order for all Master Browsers on the network to share the names of allservers on the network, a mechanism must be in place that allows theMaster Browsers to share information with each other This is the func-tion of the Domain Master Browser The Master Browser on each segmentshares the information it has for the servers on its segment with theDomain Master Browser The Domain Master Browser collates all theinformation from all the Master Browsers, and shares this synchronizedlist with all the Master Browsers on the network In this way, users onany segment will be able to find entries for servers that exist on all seg-ments in their browse lists

When a Domain Master Browser starts up, it registers its NetBIOSdomain name with its Primary WINS server using the [1Bh] service identi-fier Master Browsers on each subnet will query the WINS server for the[1Bh] to find the Domain Master Browser

Problems with Multihomed Masters

So what happens when the PDC emulator is a multihomed machine?

A multihomed machine has multiple network interface cards Each work interface will register its domain name and IP address with its PrimaryWINS server When a remote Master Browser on segment A queries theWINS database, it will receive the IP address for adapter 1, and exchange itsbrowse list with the Domain Master Browser on a connection establishedwith adapter 1 on the Domain Master Browser When a Master Browser onsegment B queries the WINS server for a Domain Master Browser, it receivesthe IP address for adapter 2 on the Domain Master Browser It then

net-exchanges its browse list with the Domain Master Browser by establishing aconnection with the Domain Master Browser’s adapter 2

This would all work very well except for one problem: The browse listsgathered on each interface on the Domain Master Browser are not

merged This leads to a disjointed browse list, and there is no way tobring the information gathered by adapter 1 and adapter 2 together

Unfortunately, there is also no way to point Master Browsers to a specificinterface on the Domain Master Browser machine, through which to

exchange browse lists Moral of the story: Do not multihome your PDC

emulator if you want the browse list to be complete.

In the same fashion, the Master Browser on each subnet cannot bemultihomed When servers on the multihomed Master Browser’s segmentstart up, they broadcast their server status to the segment If the MasterBrowser is multihomed, its first adapter may pick up some of theseannouncements, and the second adapter will pick up other announce-ments When the Domain Master Browser connects to the Master Browser

to exchange browse lists, it will connect to it via its NetBIOS name, via asingle IP address The Domain Master Browser therefore will obtain infor-mation from only one of the network interfaces on the Master Browser,and thus only the servers registered with that adapter’s IP address Again,

do not multihome Master Browsers Check out Figure 6.21 for an

illustra-tion of how this works

Figure 6.21 Multihomed Domain Master and Master Browsers.

WINS

PDC (Multihomed Domain Master)

BDC (Multihomed Master) Router

Multihomed

Solving the Multihomed Master Problem in Windows 2000

There is a way to make this work in Windows 2000 You can selectivelydisable NetBIOS on all adapters except one on the PDC emulator andeach segment’s Master Browser The remaining network interface will bethe only one to listen to server announcements, and the only one to regis-ter with a WINS server

This solves the problem with fragmented browse lists, but if you homed your servers to increase throughput for NetBIOS applications, you’vethen lost that benefit, and you might as well just use a single adapter

multi-Windows 2000 WINS Enhancements

Windows 2000 offers several improvements over its predecessor in

Windows NT 4.0 Many of these improvements are cosmetic, such as thenews WINS Management Console And some of them provide easier

access to configuration changes that in the past required editing the istry directly There are two improvements worth noting: persistent con-nections and manual tombstoning

reg-Persistent Connections

Windows 2000 WINS servers can be configured to maintain persistentconnections with their configured replication partners By always main-taining an open channel, the session setup process only needs to be doneonce This reduces the amount of overhead involved in creating and tear-ing down sessions between WINS replication partners on a frequent basis Microsoft states that this should have a salutary effect on overall serv-

er performance with a minimum of network overhead, since no data isbeing transferred over the open connection the majority of the time

Manual Tombstoning

How many Windows NT administrators have looked into the WINS manager,opened the WINS database of one of the servers, and seen little “crosses” inthe status field, and wondered, “What the heck does that mean?” Rightnow, go survey 10 MCSEs and ask them what those crosses mean Five ofthem will say, “What are you talking about?” and four will say, “Dunno.”One might know that they mean that the record was tombstoned If youask what “tombstoned” means, you’re likely to get a puzzled look

The WINS Record Life Cycle

To understand tombstoning, we need to understand the WINS record lifecycle When a WINS client registers its NetBIOS names with a WINS serv-

er, a WINS database record is created for that client This record staysactive in the WINS database for a period of time determined by the

“renewal interval.” The WINS client must update its record with the WINSserver within the period defined by the renewal interval for it to remainactive If the WINS client does not renew its record before the renewalinterval expires, it will be marked Inactive The main difference between

an active and an inactive WINS database record is that when someoneelse tries to register the same name in the WINS database, if there is anactive record, the owner of the record will be challenged If the record ismarked as inactive, then no challenge is issued, and the new computer isable to register its NetBIOS name and IP address

A record will remain in the WINS database for a period known as the

“extinction interval.” The extinction interval defines how long the inactiverecord will remain in the WINS database in the inactive state Afterremaining in the inactive state for the period defined by the extinctioninterval, the record will be marked as “tombstoned.” The record willremain in the tombstoned state for a period defined by the “extinctiontimeout,” and then it is removed or scavenged by the WINS server thatowns it after the extinction timeout period runs out If a WINS server has

a copy of a replicated tombstoned record owned by another WINS server,

it will check with the owner WINS server after completion of the tion interval” to see if the record is valid or absent If the record is nolonger at the owner WINS server, it is then scavenged from the non-ownerWINS servers after completion of the verification interval

“verifica-One question most administrators come up with is, “Why doesn’t theWINS server just delete the record after the extinction interval haspassed? Why bother with this tombstoning stuff?” The reason we tomb-stone a record is to make sure that a record doesn’t “reappear” after it’sbeen deleted from the WINS database

The Value of Tombstoning

Imagine that we have three WINS servers in our WINS network: WINS-1,WINS-2, and WINS-3 Let’s make WINS-2 the Hub of the WINS network,and make WINS-1 and WINS-3 Spokes WINS-1 receives a NetBIOS nameregistration for a computer named VOYAGER After registering its

NetBIOS name, we decide that we’re going to take VOYAGER off the work Meanwhile, VOYAGER’s record is replicated to WINS-2, and WINS-2replicates the record to WINS-3

net-You don’t want extra records in your WINS database, so you openyour WINS Management Console and delete the record for VOYAGER, andnow you’re done with it You figure that the deletion will be replicatedover to the other WINS servers, and you can bid bye-bye to VOYAGERfrom your WINS network

When WINS-1 next replicates with WINS-2, it doesn’t replicateVOYAGER’s WINS record As a matter of fact, it doesn’t replicate anything

at all about VOYAGER, because the record has been removed from the

WINS-1 database What happens when WINS-2 replicates with WINS-1?Since WINS-2 still has VOYAGER’s record in its database, it replicates itback to WINS-1 And now VOYAGER has arisen from the dead and

appears again, marked active, in the WINS-1 database

Eventually, VOYAGER’s record will pass its renewal time, then itsextinction interval, then its extinction timeout, and finally will be deleted.But if you just delete records, it can take a lot longer than it should, andthey still take up room in the WINS database While deleting a single recordwon’t cause you much trouble, if you delete records on a regular basis (forexample, hundreds at a time), you are doing yourself a disservice

To tombstone a WINS record, open the WINS Management Consoleand click Active Registrations Right-click Active Registrations and selectFind by Owner On the Owners tab, select the option button for All own-ers, and click Find Now Right-click one of the records in the right paneand select Delete You will see a dialog box as shown in Figure 6.22

Figure 6.22 The Delete WINS Record dialog box.

Note that the dialog box offers you the option to “Replicate deletion ofthe record to other servers (tombstone).” This does a decent job of

explaining what tombstoning does for the record

Is WINS Ever Going to Go Away?

Microsoft makes it clear that NetBIOS is on the way out, and many pages

of documentation are dedicated to the “decommissioning” of WINS servers

on your Windows 2000 network The core networking services of Windows

2000 are not NetBIOS-dependent; therefore, you can run a Windows2000-only network without NetBIOS support

As a matter of fact, you can disable NetBIOS support for any of theadapters attached to the computer Go into the Advanced TCP/IPProperties dialog box and click the WINS tab You’ll see the dialog boxshown in Figure 6.23

Figure 6.23 The WINS tab in the Advanced TCP/IP Settings Properties box

When you disable NetBIOS on an interface, you disable all NetBIOS-basedcommunications going into and out of that interface Some programs thatyou might use regularly will no longer work

The browser service is a NetBIOS-based program, and you will nolonger see entries in the browse list after disabling NetBIOS This should

WARNING

be a significant boon to network administrators who have to deal withusers not being able to “see” computers over the network The only sharesthe users will be able to access via the My Network Places applet arethose that you explicitly publish to the Active Directory This will probablyreduce the number of support calls you get from hapless users and junioradministrators who believe the network is disconnected because the com-puter’s name doesn’t show up in the browse list.

After you disable NetBIOS, you would expect that popular based services such as the Workstation, Server, Net Send, and Net Usewouldn’t work anymore However, you will find that you can still shareresources without problems, and you can still access those shared

NetBIOS-resources without difficulty After you disable NetBIOS, a connection ismade to a share via TCP Port 445 When testing this, you may find that

access to shared data is faster with NetBIOS turned off The Net Send

con-tinues to work via the messenger service without problems However, inour tests, the Alerter service does not seem to function, so if you want toenable alerts based on Performance Monitoring, you’re going to need toenable NetBIOS at least temporarily

While the failure of the Alerter service to work after NetBIOS is abled is a bit annoying, the workaround isn’t difficult to implement

dis-Where you will find a profound impact from disabling NetBIOS is whenyou are working in a mixed-mode environment Mixed-mode environ-ments contain both Windows 2000 and downlevel domain controllers, andclients that authenticate with either a Windows 2000 domain controller or

a Windows NT domain controller

Windows 2000 machines that authenticate with a Windows 2000domain controller will have no problems, since they search DNS for a SRVentry pointing to the Windows 2000 domain controller to authenticateagainst However, downlevel clients use a NetBIOS-based Domain Locatormechanism, so if the downlevel client is to authenticate against a

Windows 2000 domain controller, the NetBIOS over TCP/IP services must

be in place If they’re not, the downlevel clients will not be able to accessthe Windows 2000 domain controller for authentication

Troubleshooting Common NetBIOS

Communication Problems

When troubleshooting NetBIOS name resolution problems, the first step

is to ask: What is the service that is causing the problem? Components ofnetwork communications that are involved with NetBIOS communicationsand name resolution include: