Contents

Overview 1
Introducing WINS 2
Designing a Functional WINS Solution 8
Securing a WINS Solution 19
Enhancing a WINS Design for Availability 22
Optimizing a WINS Design
for Performance 27
Lab A: Designing a WINS Solution 31
Review 38 Module 5: WINS as a
Solution for NetBIOS
Name Resolution
Information in this document is subject to change without notice. The names of companies,
products, people, characters, and/or data mentioned herein are fictitious and are in no way intended
to represent any real individual, company, product, or event, unless otherwise noted. Complying
with all applicable copyright laws is the responsibility of the user. No part of this document may
be reproduced or transmitted in any form or by any means, electronic or mechanical, for any
purpose, without the express written permission of Microsoft Corporation. If, however, your only
means of access is electronic, permission to print one copy is hereby granted.


Group Product Manager: Robert Stewart

Other product and company names mentioned herein may be the trademarks of their respective
owners.
Module 5: WINS as a Solution for NetBIOS Name Resolution iii Instructor Notes
This module provides students with the information and decision-making
experience needed to develop a solution for resolving network basic
input/output (NetBIOS) names by using WINS in Microsoft
® Windows® 2000.
Students will evaluate and create WINS solutions for the name resolution of
NetBIOS resources in Transmission Control Protocol/Internet Protocol
(TCP/IP) networks.
At the end of this module, students will be able to:
 Evaluate WINS as a solution for NetBIOS name resolution.
 Evaluate and create a functional design for baseline name resolution.
 Select appropriate strategies to secure a WINS solution.
 Select appropriate strategies to enhance a WINS design for availability.
 Select appropriate strategies to improve a WINS design for performance.

Upon completion of the lab, students will be able to evaluate and design WINS
solutions that meet the requirements for resolving NetBIOS names in a variety
of organizations.
Course Materials and Preparation
This section provides you with the materials and preparation needed to teach

 Introducing WINS
The use of NetBIOS names in a TCP/IP network requires resource names to
be resolved into IP addresses. WINS provides an RFC-compliant NetBIOS
Name Service (NBNS) to resolve resource names throughout a network
infrastructure.
In this section:
• Reinforce the continuing need for WINS in networking environments
that have NetBIOS resources.
• Emphasize that the first steps in designing a WINS solution are to
establish the need for WINS, and to identify the design decisions. The
design decisions depend on the number of hosts, the number of
resources, and the network configuration.
• Review the four distinct phases of name resolution provided by the
WINS service in Windows 2000: registration, resolution, renewal, and
release. Mention that WINS removes names if the client fails to renew
its entries.
• Emphasize that the integration of WINS with DHCP and DNS solves a
major networking issue by providing DNS name resolution for hosts
with dynamic IP address allocations.
 Designing a Functional WINS Solution
A functional WINS solution supports both WINS and non-WINS clients in a
local area network (LAN) or a routed network. A WINS solution can be
designed to control replication of the WINS databases when multiple WINS
servers are required.
In this section:
• Highlight that WINS uses a unicast protocol, thereby eliminating
NetBIOS-related broadcast traffic in a LAN. Emphasize that client
counts and response times depend on the configuration of the hardware.
• Point out that the unicast protocol used by WINS meets the routed
network requirement for a nonbroadcast-based NetBIOS name service.

• Stress that the decision whether to use L2TP/IPSec or PPTP VPN
tunnels must be based on the existing network configuration and the
public networks used to transfer data.
• Point out that screened subnets can be used to avoid exposing NetBIOS
names and WINS data to a public network. Suggest students consider
using pull replication only if replication is required from the WINS
server in the screened subnet to the WINS server(s) within the corporate
intranet. Remind students that a Common Internet File System (CIFS)
and WINS solution is simple by comparison to Web-based solutions.
 Enhancing a WINS Design for Availability
Ideally, a WINS Service would be available whenever it is required. To
enhance the availability of the service, a WINS solution can be designed to
provide support for multiple WINS servers that use WINS replication, and
to include WINS servers that are configured to use Windows Clustering.
In this section:
• Emphasize that when using multiple WINS servers, the placement of
servers depends on the network infrastructure, service performance, and
location constraints. Point out that adding additional WINS servers to
remote locations provides name service redundancy in case a server
fails.
• Emphasize that installing WINS servers on a cluster provides immediate
recovery in the event of hardware or service failure.
• Make sure that students understand the scenario description and the
instructions for the Discussion. Direct them to read through the scenario
and answer the questions. Be prepared to clarify if necessary. Lead a
class discussion on the students’ responses.
vi Module 5: WINS as a Solution for NetBIOS Name Resolution

 Remind students to consider any functionality, security, availability, and
performance criteria provided in the scenario, and how they will incorporate
strategies to meet these criteria in their design.
 Allow some time to discuss the solutions after the lab is completed. A
solution is provided in your materials to assist you in reviewing the lab
results. Encourage students to critique each other’s solutions and to discuss
any ideas for improving their designs. Module 5: WINS as a Solution for NetBIOS Name Resolution 1 Overview
 Introducing WINS
 Designing a Functional WINS Solution
 Securing a WINS Solution
 Enhancing a WINS Design for Availability
 Optimizing a WINS Design for PerformanceThe use of network basic input/output system (NetBIOS) names in a
Transmission Control Protocol/Internet Protocol (TCP/IP) network requires
resource names to be resolved throughout a network infrastructure. WINS in
Microsoft
® Windows® 2000 implements an RFC-compliant NetBIOS name
service (NBNS).
At the end of this module, you will be able to:
 Evaluate WINS as a solution for NetBIOS name resolution.
 Evaluate and create a functional design for baseline name resolution.
 Select appropriate strategies to secure a WINS solution.

Clients
Exchange
Server
Windows 95
Using NetBIOS
Client Running
Outlook
NetBIOS name resolution is
required by many clientsWithin an organization’s intranet, the potentially large number of available
NetBIOS resources, such as file and print services, creates the need for
meaningful device and logical resource names to simplify the user’s access to
resources. WINS resolves NetBIOS resource names to IP addresses. WINS can
also integrate with other Windows 2000 services to extend name resolution
capabilities.
To design a strategy for locating NetBIOS resources by using WINS, you must:
 Collect the network and host configuration data required to make the design
decisions necessary for developing a WINS solution.
 Identify the features provided by WINS and how these features support the
design requirements.
 Identify the benefits provided by integrating WINS with other services in
Windows 2000.

Slide Objective
To introduce WINS as a
solution for NetBIOS name
resolution.
Lead-in

CD Server
WAN Link
Router
RouterTo successfully develop a WINS solution, you must assess the number of hosts,
the number of resources, and the routing or network configuration. When you
understand the configuration of the network, resources, and hosts for the
infrastructure, you can make decisions on the requirements for a WINS-based
NetBIOS name resolution service.
Establishing the Need for WINS
In a TCP/IP routed or switched network, where broadcast packets may not pass
between segments, a nonbroadcast-based service is required to accommodate a
dynamic NetBIOS name resolution and registration service. WINS meets this
service need by providing unicast NetBIOS name registration and resolution.

In a simple, nonrouted TCP/IP network, such as a single-segment local
area network (LAN), WINS may be optional. A non-WINS solution works in
those instances where the broadcast domain is small, broadcast traffic is
acceptable, and hosts are configured as b-node (broadcast nodes).

Identifying the Design Decisions
After you have established the network infrastructure requirements and
configuration, the design decisions you must make include the:
 Number and placement of WINS servers within the network.
 Plan for replication schedules, and architecture and configuration options
for multi-WINS server environments.
 Configuration of WINS Client.
 Placement of WINS Proxy Agents to ensure unique non-Windows host

Features of a WINS Service
 Name Resolution Services
 RFC Compliance
 DNS Integration
 Burst-Mode Name Registration
 Secure and Centralized
Administration
 Multiple WINS Servers
WINS
Server
WINS Client
WINS Client
Register
Renew
Release
Resolve
WINS Database
Client1 10.0.1.11
Client2 10.0.3.12
Client3 10.0.3.13
RemoveWhen designing a WINS-based NetBIOS name resolution service, you must
understand the WINS features and how you can use these features to support
the needs of your network infrastructure.
Name Resolution Services
A WINS infrastructure builds and maintains a database of available NetBIOS
resources and resolves NetBIOS names to IP addresses based on client requests.
WINS accomplishes name resolution in four distinct phases:

Module 5: WINS as a Solution for NetBIOS Name Resolution 5
Burst-Mode Name Registration
When a large number of WINS clients simultaneously try to register their
NetBIOS names, the WINS server can become saturated. Burst-mode name
registration supports a high volume of WINS client name registrations.
By default, when the queue of registration requests exceeds 500, a WINS server
begins to positively respond to new registration requests with a shorter (5 – 50
minutes) Time to Live (TTL). The short TTL lease forces these WINS clients to
reregister after the excessive WINS registration traffic has subsided.
Secure and Centralized Administration
You can centrally administer WINS, thereby reducing name resolution–related
support issues. WINS clients automatically register and release their NetBIOS
names, so no other administration is necessary. Administration is secure
because only specific Windows 2000–based groups can modify a WINS server
configuration or database.
Multiple WINS Servers
WINS provides a critical service for the network, so availability and
performance are key design goals. Multiple WINS servers provide greater
availability and improve the performance of any WINS implementation. The
WINS architecture supports multiple servers that you can configure to replicate
their database information. In addition, you can configure WINS clients with a
list of available WINS servers that are sequentially referenced in the case of a
server failure.
6 Module 5: WINS as a Solution for NetBIOS Name Resolution

automated registration eliminates manual administration and configuration
errors.
You can select registration of the NetBIOS names in WINS to be completed by:
 The DHCP Client.
 The DHCP Server.
 The DHCP Client and DHCP Server.

Slide Objective
To describe the benefits of
integrating WINS with other
services in Windows 2000.
Lead-in
WINS integrates with other
services in Windows 2000,
such as DHCP and DNS.
This integration allows the
other services to use
dynamic registrations.
Emphasize that the
integration of DHCP, WINS,
and DNS solves a major
networking issue by
providing DNS name
resolution for hosts with
dynamic IP address
allocations.
Note
Module 5: WINS as a Solution for NetBIOS Name Resolution 7
as a solution.
Lead-in
You can design a WINS
solution for a LAN or a
routed network that supports
WINS or non-WINS clients.
You can incorporate multiple
WINS servers if required.
Module 5: WINS as a Solution for NetBIOS Name Resolution 9
Designing a WINS Service for a LAN
 LAN Considerations
 Client Considerations
h-node
Register, Renew, Release,
and Query by Unicast
traffic then use Lmhosts
and Broadcasts
h-node
Register, Renew, Release,
and Query by Unicast
traffic then use Lmhosts
and Broadcasts
WINS
Server
Client B Client A Client C
WINS Clients
(h-node)

Slide Objective
To describe the factors to
consider when designing a
WINS solution for a LAN.
Lead-in
WINS provides services for
LANs by using unicast
protocol, which minimizes
broadcast traffic.
Remind students that client
counts and response times
are hardware-dependent.
Recommend that students
read any relevant capacity
planning white papers or
perform testing to determine
the capacity of a server.
10 Module 5: WINS as a Solution for NetBIOS Name Resolution
If your entire network supports broadcasts and is made up of a single, non-
routed LAN that occupies one physical segment or a single, non-routed LAN
that occupies switched network segments with few clients, you probably do not
need a WINS server. For these small networks, using Lmhosts entries and
broadcasts may be an effective and simple solution for providing NetBIOS
name service to a small number of clients.
Module 5: WINS as a Solution for NetBIOS Name Resolution 11
number and placement of WINS servers.
In a routed LAN, it is best to position servers to minimize cross-subnet query
and registration traffic, and to maximize performance and fault tolerance for
client queries.
In a geographically dispersed wide area network (WAN), in which there may be
restricted bandwidth between locations, you must place the WINS servers to:
 Maximize client response to registrations and queries.
 Minimize database convergence times between WINS partners.

In a multiple WINS server solution, database convergence
affects decisions on replication. In a LAN environment, persistent
connections allow incremental replication updates. Restricted bandwidth
WAN environments may require the use of schedules or database change
counts to trigger replication updates, which increases convergence times.

 Minimize the number of WINS servers required by using only as many
WINS servers as you need to support all clients.

Slide Objective
To describe the factors to
consider when designing a
WINS service for a routed
network.
Lead-in
In a routed network, you
need to position WINS
servers to provide the best
client performance while
reducing cross-router traffic.
Emphasize that in a well-

WINS Client
Subnet 1
Subnet 2
Subnet 3
WINS
Clients
Unicast
communications
through routers
RouterAll versions of Windows support a WINS client, resulting in reduced broadcast
traffic.
WINS Client Features
The WINS client in Windows 2000 provides the following features:
 Communication with a WINS server by using unicast packets to reduce
broadcast traffic.
 Support of up to 12 WINS servers for redundancy.

Earlier Windows versions support either one or two WINS servers.

 Support for multiple node types as defined in RFC 1001.

WINS Client Considerations
When designing a WINS Service that supports WINS clients, consider doing
the following:
 Specifying multiple WINS servers for clients to provide service redundancy.
 Increasing the NetBIOS name registration renewal period—the default is six
days—to reduce client-to-server renewal traffic.

WINS
Clients
Windows 2000 Router
with WINS Proxy Agent
Broadcast
Unicast
Subnet 3
WINS
Server
RouterFor resources not on the local subnet, non-WINS clients that use NetBIOS need
to have name registrations and requests resolved. Name services extended to
these hosts deal with both registration and resolution issues.
You can use any combination of the following methods to support these non-
WINS clients:
 Including WINS Proxy Agents on the subnet containing non-WINS clients.
 Including static WINS or Lmhosts entries to enable remote name resolution.
 Enabling NetBIOS broadcast traffic across all routers.

WINS Proxy Agent
The WINS Proxy Agent receives the broadcast-based NetBIOS name service
interaction from non-WINS clients and forwards the requests to a WINS server.
The WINS Proxy Agent:
 Ensures unique NetBIOS names within the routed network.
 Extends name resolution services to the non-WINS clients.
 By default, does not register the resource names with WINS.

You can configure any WINS client to provide WINS Proxy Agent

resource names are made in an Lmhosts file. To minimize administration of
multiple Lmhosts files, you can enter resource names in a centrally maintained
Lmhosts file referenced as a #INCLUDE in the client Lmhosts file.
NetBIOS Broadcasts Across Routers
Enabling NetBIOS broadcasts across all routers in a network allows operation
without WINS, but is not recommended, because it increases the size of the
broadcast domain. This would only be considered a viable solution for small
network designs.
Module 5: WINS as a Solution for NetBIOS Name Resolution 15
Supporting Multiple WINS Servers
 WINS Replication
 Convergence Time
hub and spoke
replication minimizes
convergence times
hub and spoke
replication minimizes
convergence times
WINS clients access
multiple WINS Servers
WINS clients access
multiple WINS Servers
push/pull push/pull
push/pull
push/pull
Subnet B
WINS-B

Convergence time is the time it takes for a new entry in a WINS database to be
replicated from the originating WINS server to all other partner WINS servers.
When planning placement and replication for WINS servers, you must decide
an acceptable convergence time for your network.
Slide Objective
To describe the use of
WINS database replication
in multiple server
environments.
Lead-in
When you use multiple
WINS servers within a
network, replication is used
to synchronize the
databases.
Key Points
The recommended
configuration for WINS
replication is push/pull with
hub and spoke.
Caution
16 Module 5: WINS as a Solution for NetBIOS Name Resolution
To minimize replication paths and convergence times:
 Select push/pull when planning replication partners. Avoid the use of
limited replication partnerships (push only or pull only) between WINS
servers, unless required for slow WAN links.
 Select persistent connections between partners to improve replication
To provide a functional WINS solution for NetBIOS name resolution, you must
decide on the number and placement of servers, where and when to use proxy
agents, and how to ensure NetBIOS names are resolved for both WINS and
non-WINS clients.
The following scenario describes an organization’s current network
configuration. Read through the scenario and then answer the questions. Be
prepared to discuss your answers with the class.
Scenario
An organization has decided to restructure an existing network and include
WINS as a solution for NetBIOS name resolution. You are assigned the task of
evaluating how WINS can be used to provide a solution for this scenario.
The current network configuration provides:
 Intranet access to all shared folders and Web-based applications.
 Support for the existing infrastructure shown in the diagram.
 Support for a mission-critical Web-based application that requires 24-hours-
a-day, 7-days-a-week operation.
 Support for a non-WINS compliant CD server by using NetBIOS access in
Subnet 3.
 Support for non-WINS clients.

Slide Objective
To evaluate the functional
requirements of a WINS
solution.
Lead-in
To design a functional WINS
solution, you must decide
where to place servers and

c. Subnets 2 and 3.
d. Subnet 3.
e. Subnet 5.
The correct answer is c. Subnets 2 and 3 contain non-WINS clients.
4. What actions must you take to ensure that both WINS and non-WINS
clients can resolve the NetBIOS name of the CD server on Subnet 3?
Include the NetBIOS name for the CD server and the non-WINS clients
in an Lmhosts file, or add a static entry to the WINS database.

Module 5: WINS as a Solution for NetBIOS Name Resolution 19


 Securing a WINS Solution
WINS
Server
WINS
Server
Internet
Internet
 Securing WINS Traffic with Tunnels
 Integrating into Screened SubnetsIn a WINS solution, both replication and client traffic often occur across public
networks such as the Internet. Passing the NetBIOS names and IP addresses of
hosts within the organization over these public networks poses a security risk.
You can include strategies to support encryption in your WINS solution, which