Tài liệu Module 5: WINS as a Solution for NetBIOS Name Resolution doc

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.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual
property rights covering subject matter in this document. Except as expressly provided in any
written license agreement from Microsoft, the furnishing of this document does not give you any
license to these patents, trademarks, copyrights, or other intellectual property.

 2000 Microsoft Corporation. All rights reserved.

Microsoft, Active Directory, ActiveX, BackOffice, FrontPage, JScript, MS-DOS, NetMeeting,
PowerPoint, Visual Basic, Visual C++, Visual Studio, Win32, Windows, Windows Media,
Windows NT, are either registered trademarks or trademarks of Microsoft Corporation in the
U.S.A. and/or other countries/regions.

Project Lead: Don Thompson (Volt Technical)
Instructional Designers: Patrice Lewis (S&T OnSite), Renu Bhatt NIIT (USA) Inc.
Instructional Design Consultants: Paul Howard, Susan Greenberg
Program Managers: Jack Creasey, Doug Steen (Independent Contractor)
Technical Contributors: Thomas Lee, Bernie Kilshaw, Joe Davies
Graphic Artist: Kirsten Larson (S&T OnSite)
Editing Manager: Lynette Skinner
Editor: Kristen Heller (Wasser)
Copy Editor: Kaarin Dolliver (S&T Consulting)
Online Program Manager: Debbi Conger
Online Publications Manager: Arlo Emerson (Aditi)
Online Support: Eric Brandt (S&T Consulting)
Multimedia Development: Kelly Renner (Entex)
Production Support: Lori Walker (S&T Consulting)
Manufacturing Manager: Rick Terek (S&T OnSite)
Manufacturing Support: Laura King (S&T OnSite)
Lead Product Manager, Development Services: Bo Galford
Lead Product Manager: Ken Rosen

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

this module.
Required Materials
To teach this module, you need the following materials:
 Microsoft PowerPoint® file 1562B_05.ppt

Preparation Tasks
To prepare for this module, you should:
 Review the contents of the module.
 Be familiar with RFCs 1001 and 1002.
 Review any relevant information in the Windows 2000 Help files, the
Windows 2000 Resource Kit, or in documents provided on the Instructor
CD.
 Review the discussion material and be prepared to lead class discussions on
the topics.
 Complete the lab, and be prepared to elaborate beyond the solutions found
there.
 Read the review questions, and be prepared to elaborate beyond the answers
provided in the text.

Presentation:
45 Minutes

Lab:
45 Minutes
iv Module 5: WINS as a Solution for NetBIOS Name Resolution



Module Strategy
Use the following strategy to present this module:

 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.

Emphasize that client performance issues, and the requirements for
redundancy and replication, determine the number and placement of
WINS servers.
• Emphasize that all versions of Windows support a WINS client
component. Explain that this component further reduces broadcast
traffic.
• Emphasize that non-WINS clients can be supported by including WINS
Proxy Agents and static WINS or Lmhosts entries, and by enabling
NetBIOS traffic across all routers.
Module 5: WINS as a Solution for NetBIOS Name Resolution v



• Explain that when using multiple WINS servers, the locally acquired
entries must be replicated to configured partners. Caution students that
multicast announcements between WINS servers add traffic to the
network.
• 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.
 Securing a WINS Solution
Because replication and client traffic often occur across public networks, the
security of the NetBIOS names and IP addresses of hosts within the
organization is at risk. A WINS solution can be secured by using Layer Two
Tunneling Protocol (L2TP)/Internet Protocol Security (IPSec) or Point-to-
Point Tunneling Protocol (PPTP)-based virtual private network (VPN)
tunnels. There may also be scenarios that would benefit from the integration
of WINS servers into screened subnets.
In this section:

• 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

 Optimizing a WINS Design for Performance
Reducing response times to client requests, and reducing the time taken to
replicate between servers, can maximize the performance of the WINS
service.
In this section:
• Emphasize that WINS in Windows 2000 supports the use of multiple
CPUs, an optimized database, burst-mode client registrations, and
multiple WINS servers to optimize the performance of the WINS
service.
• Point out that replication traffic between servers in a multiple-server
environment reduces the performance of the WAN links. Emphasize that
the replication schedule can be planned to minimize replication traffic
while meeting the goals for convergence time.

Lab Strategy

Use the following strategy to present this lab.
Lab A: Designing a WINS Solution
In the lab, students will design a WINS solution based on specific requirements
outlined in the given scenario.
Students will review the scenario and the design requirements and read any
supporting materials. They will use this information, and the knowledge gained
from the module, to develop a detailed design that uses WINS as a solution.
To conduct the lab:
 Read through the lab carefully, paying close attention to the instructions and
the details of the scenario.
 Divide the class into teams of two or more students.
 Present the lab and make sure students understand the instructions and the
purpose of the lab.
 Direct students to use the planning worksheet to record their solutions.

 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 Performance


The 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.

 Select appropriate strategies to enhance a WINS design for availability.
 Select appropriate strategies to improve a WINS design for performance.

Slide Objective
To provide an overview of
the module topics and
objectives.
Lead-in
In this module, you will
evaluate and design WINS
solutions for locating
NetBIOS resources.
2 Module 5: WINS as a Solution for NetBIOS Name Resolution





 Introducing WINS
 Design Decisions
 WINS Features
 Integration Benefits
A
A
B
B
Share
Shared
Resource
Windows

Clients
Exchange
Server
Windows 95
Using NetBIOS
Client Running
Outlook
NetBIOS name resolution is
required by many clients


Within 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

NetBIOS permits client
computers to access
network hosts by using a
NetBIOS name instead of
the host’s IP address. WINS
translates the NetBIOS
name to the resource IP
address.
Explain that a network host
can be defined as any
device or computer that
participates in a TCP/IP
network. Host may describe
a client or server.
Module 5: WINS as a Solution for NetBIOS Name Resolution 3



Design Decisions for a WINS Solution
 Establishing the Need for WINS
 Identifying the Design Decisions
File
Servers
Exchange
Server
Broadcast
Domain
Broadcast
Domain
NetBIOS

CD Server
WAN Link
Router
Router


To 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

names.

Slide Objective
To introduce the decisions
required for a WINS
solution.
Lead-in
The design of a NetBIOS
name resolution service
based on WINS depends on
the number of hosts, the
number of resources, and
the network configuration.
Use the slide to discuss the
decisions required to design
a WINS solution.

Explain that WINS is not
required in a single-segment
LAN within a single
broadcast domain, but is
beneficial in any
environment to reduce the
dependence on broadcast
traffic.
Note
4 Module 5: WINS as a Solution for NetBIOS Name Resolution

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
Remove


When 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:

 Registers new network device names as they become available.
 Resolves NetBIOS names to IP addresses for WINS clients.
 Renews name registrations for WINS clients.
 Releases NetBIOS names during normal WINS client computer shutdown.

And, in addition, the WINS service:
 Removes names from the registration database if the client fails to renew its
entries.

RFC Compliance
WINS provides NetBIOS name service support that is compliant with RFC
1001 and RFC 1002. The implementation of WINS in Windows 2000 extends
the RFC-compliant NetBIOS name service by supporting multiple distributed
servers with replicated databases.
DNS Integration
To fulfill DNS client queries, the WINS service integrates with DNS in
Windows 2000 to allow forward and reverse lookup of NetBIOS resources by
DNS servers. You can also configure WINS clients to support name resolution
by using both DNS and WINS records.
Slide Objective
To introduce the features in
WINS.
Lead-in
To develop a WINS solution,
you need to understand the
WINS features.
Mention that this is not a
complete list of the WINS
features; additional features
will be discussed later.

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

Integration Benefits
 DHCP Integration
 DNS Integration
DHCP
Server
DNS
Server
Name Registration
Name Resolution
WINS
Server


WINS clients that have DHCP-allocated IP addresses must be registered in
WINS to allow other clients to resolve resources. The integration of WINS with
other Windows 2000 networking services such as DHCP and DNS allows the
other services to use these dynamic registrations.
The integration of WINS with DHCP and DNS allows:
 DNS servers to forward unresolved DNS queries to WINS servers for
resolution of host names that have dynamic IP addresses.
 DNS resolution for resources located on other operating systems, such as
previous versions of Microsoft Windows.


In addition to the server-to-server integration, you can configure the
WINS client to query a DNS server with unresolved WINS queries.

DHCP Integration
The integration of WINS and DHCP allows client computer name registrations
to be updated in WINS for clients with dynamically allocated IP addresses. This

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

DNS Integration
The integration of WINS and DNS allows you to select whether DNS can use
WINS to resolve host names. This integration allows resources not registered in
DNS to be resolved in the WINS namespace. The DNS server then returns the
resource’s IP address to the querying DNS client.

8 Module 5: WINS as a Solution for NetBIOS Name Resolution





 Designing a Functional WINS Solution
 Designing a WINS Service for a LAN
 Designing a WINS Service for a Routed Network
 Supporting WINS Clients
 Supporting Non-WINS Clients
 Supporting Multiple WINS Servers
 Discussion: Evaluating WINS Functional Requirements


You can create a WINS design for a LAN or routed network that supports both
WINS and non-WINS clients. If multiple WINS servers are required, you can
create a solution to control replication of the WINS databases between partners.

Slide Objective
To provide an overview of
the network configurations
in which WINS can be used

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)

Unicast
reduces
broadcasts


In a nonrouted LAN, you can register and resolve NetBIOS names by using
broadcasts, but all hosts must process these broadcasts, which reduces the
performance of the hosts. WINS provides a NetBIOS name service that uses a
unicast protocol, which can eliminate NetBIOS-related broadcast traffic.
LAN Considerations
When designing a WINS solution for a nonrouted LAN, consider doing the
following:
 Enable all clients to use WINS to reduce broadcast traffic on the LAN.
 Set conservative client counts for a WINS server to minimize client query
response times.

A single WINS server can support thousands of WINS clients, but the
performance depends on the configuration of the hardware. The WINS service
might be installed on a computer providing other services, which can further
reduce performance. In a larger network, you might need a dedicated WINS
server, or more than one WINS server.
Client Considerations
All Windows 2000–based clients—and most of the earlier Microsoft-based
WINS clients—are configured by default as hybrid node (h-node) clients. These
WINS clients use any of the following methods, in the order listed, to handle
requests to resolve names not already in the client NetBIOS name cache:
1. Direct (unicast) contact with a WINS server.
2. Host lookup by using the Lmhosts file.
3. Broadcast of the NetBIOS request to the local subnet.

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

Designing a WINS Service for a Routed Network
WINS
Clients
Sydney
WINS
Servers
WAN
Connection
WINS
Server
WINS
Server
WINS
Client
New
York
Replication
Replication
Router
Router
Router


In a routed network where broadcast domains are restricted, a nonbroadcast-
based NetBIOS name service is required to allow network-wide resource name
registration and resolution.
The unicast protocol used by WINS provides NetBIOS name resolution for
WINS clients in a routed TCP/IP environment. Client performance issues, and
WINS server redundancy and replication requirements, determine the required

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-

designed WINS Service,
there may be no NetBIOS
broadcast traffic unless a
failure occurs or non-WINS
clients are used.

Stress the fact that although
students may design with
convergence as the primary
issue, they must consider
connection and replication
traffic issues if the WAN
bandwidth is low.
Im
p
ortan
t
12 Module 5: WINS as a Solution for NetBIOS Name Resolution



Supporting WINS Clients
 WINS Client Features
 WINS Client Considerations
WINS Server
WINS
Client
Windows 2000 Router
WINS
Server

WINS Client
Subnet 1
Subnet 2
Subnet 3
WINS
Clients
Unicast
communications
through routers
Router


All 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.

Slide Objective
To describe the features of
the WINS client and the
design considerations for a
WINS service that supports
WINS clients.
Lead-in
All versions of Windows
provide a WINS client
component, which aids in
the reduction of broadcast
traffic.
Note
Module 5: WINS as a Solution for NetBIOS Name Resolution 13



Supporting Non-WINS Clients
 WINS Proxy Agent
 Static Entries
 NetBIOS Broadcasts
Non-WINS
Client
Non-WINS
Client
WINS Client with
WINS Proxy Agent
Subnet 1
Subnet 2

WINS
Clients
Windows 2000 Router
with WINS Proxy Agent
Broadcast
Unicast
Subnet 3
WINS
Server
Router


For 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

functionality to a network segment. Any subnets that contain non-WINS clients,
and do not have any WINS servers, need to have at least one WINS Proxy
Agent.

If you plan multiple WINS Proxy Agents on a single segment for
redundancy, keep them to a minimum, because all WINS Proxy Agents on the
network segment forward each non-WINS client request to the server.

Slide Objective
To describe how to provide
support for non-WINS
clients in a routed network.
Lead-in
You can extend WINS name
resolution services to hosts
that use NetBIOS but are
not WINS-enabled.
Note
14 Module 5: WINS as a Solution for NetBIOS Name Resolution



Static WINS and Lmhosts Entries
Non-WINS client registrations are not added to the WINS database
automatically. To resolve these resources network-wide, you must manually
add the registrations as a static entry to the WINS database, or include them in
client Lmhosts files.
Static name entries for non-WINS resources that are added to the WINS
database allow WINS clients to resolve these resources.
In Windows-based computers that use TCP/IP, entries to resolve remote

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

192.168.3.5
WINS-C
WINS-E
WINS-D
WINS-A
192.168.2.5
TCP/IP Settings for WINS Clients on Subnet B
First WINS Server: 192.168.3.5
Second WINS Server: 192.168.2.5


Multiple WINS servers distribute the NetBIOS name service across LAN and
WAN environments, confining WINS client traffic to localized areas. To ensure
consistent network-wide name resolution, WINS servers must replicate their
locally acquired entries to configured partners.
WINS Replication
You can configure WINS replication by using:
 Scheduled push or pull intervals.
 Push, pull or push/pull partners.
 Automatic partner discovery with a two-hour schedule over a multicast
group (224.0.1.24).

Multicast announcements between WINS servers add traffic to
your network. Automatic partner replication is recommended only if you
have a small number of installed WINS servers (typically, three or fewer) on
the reachable network.

 Push updates based on the number of changes to the database.

Convergence Time

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

performance in high-bandwidth networks.
 Plan for a hub-and-spoke model for WINS replication. This provides the
shortest convergence times.

Module 5: WINS as a Solution for NetBIOS Name Resolution 17



Discussion: Evaluating WINS Functional Requirements
Remote Access Server
Windows 2000-based
Router
File and Print
Server
WINS Clients
Subnet 1
Subnet 2
Subnet 3
WINS
Clients
Non-WINS
Clients
Subnet 4
WINS
Clients
Router A2
Subnet 5
CD
Server
Router A1

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

proxy agents and how to
ensure names are resolved
for both WINS and non-
WINS clients.
18 Module 5: WINS as a Solution for NetBIOS Name Resolution



Questions
Answer the following questions to determine how WINS can be used to provide
a functional solution for this scenario.
Circle the correct answer or give a correct explanation.
1. Ignoring reliability considerations, how many WINS servers are required in
this design?
a. One server.
b. Two servers.
c. Five servers.
d. Six servers.
The correct answer is a. One server is required.
2. Which of the following choices are correct reasons to install a WINS proxy
agent?
a. To enable WINS clients to resolve names by using WINS servers.
b. To enable non-WINS clients to resolve names by using WINS servers.
c. To enable WINS clients to resolve names by using non-WINS clients.
d. To enable non-WINS clients to resolve names by using WINS clients.
The correct answer is b.
3. Which of the following network subnets requires a WINS proxy agent to be
enabled on at least one WINS client?
a. Subnets 1, 2, and 3.
b. Subnet 2.

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 Subnets


In 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

secures WINS traffic. Windows 2000 enhances WINS security by:
 Supporting Internet Protocol Security (IPSec) or virtual private network
(VPN) tunnels for data encryption.
 Integrating WINS servers into screened subnets.


For more information refer to Course 2150, Designing a Secure
Microsoft Windows 2000 Network.

Slide Objective
To describe strategies
available in Windows 2000
that secure WINS traffic.
Lead-in
Many multi-server WINS
implementations may be
required to operate across
unsecured networks such as
the Internet; therefore, you
must give consideration to
securing this traffic.
Refer students to course
2150, Designing a Secure
Microsoft Windows 2000
Network, which covers
security issues in much
greater depth.
Note