The Best Damn Windows Server 2003 Book Period- P76 ppt

Normally, routers do not forward IGMP traffic, so this configuration is best used on small,
unsegmented LANs. However, it is possible to configure routers to forward this traffic, allowing
automatic partner configuration to be used in a routed environment. If there are only a few routers
in the environment, the amount of multicast broadcast traffic should be minimal.
Push Partnerships
As the name implies, when a push partnership is configured, changes in the WINS database are
pushed to the remote WINS server. More accurately, a WINS server with records to replicate sends a
push notification to target servers (those configured to use it as a pull partner), alerting them that it
has records to update on the target WINS servers.The push notification includes an owner table
that lists the owner IDs and the highest version ID for each owner.The target servers compare this
information with their own owner tables to determine which records to replicate.The target servers
reply to the push notification with a pull request, and the transfer of records takes place.
Accordingly, since a transfer of records will not take place until a pull request has been received by
the server that sent the push notification, pull replication is the single mechanism for replication.
The process for push replication occurs as follows:
1. The source WINS server receives updates to its database and, based on a configurable
threshold, sends a push notification to the destination WINS server (its push partner), indi-
cating that it has updates to replicate.
2. The destination WINS server for the notification (the push partner) responds by initiating
a pull request to its pull partner (the WINS server that sent the notification), and the repli-
cation is initiated between the replication partners.
Push replication is not schedulable according to an interval of time. Rather, the WINS adminis-
trator configures an update threshold that will trigger a push notification. For example, the WINS
server could be configured to send a notification to its push partner after it has received 100
updates. Figure 20.21 shows the Push Replication tab of the Replication Partners Properties
dialog box with the default settings for push replication.
716 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy
Figure 20.21 Push Replication Settings
301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 716
The settings that you enter here will determine the threshold trigger for the push notification.
In the configuration shown in Figure 20.21, a push notification is sent to the replication partner as

soon as an update occurs in the WINS database.This is the result of setting the value for Number
of changes in version ID before replication to 0. However, the value could be set to a higher
number, such as 100. It is also possible to configure a push notification to occur when the service
starts up or when there is an address change in a WINS registration.
The setting to Use persistent connections for push replication partners allows the con-
nections between WINS servers to remain open.This is a useful feature when the WINS servers are
connected by a high-speed LAN. Earlier versions of WINS would close the connection after each
replication cycle. Opening the connection to initiate a new replication cycle could cause delays,
however modest, that are not acceptable in an environment where records need to be synchronized
as soon as possible.
It is also possible to manually initiate the push notification, as shown in Figure 20.22. When you
manually initiate the push notification, you can choose to push the notification to the replication
partner or to trigger the replication to send a notification to all of its partners as well.As an
example, consider a replication topology where three WINS servers are configured as push replica-
tion partners. WINS-A replicates to WINS-B, which replicates to WINS-C. So, if you manually sent
a push notification from WINS-A to its replication partner, WINS-B, you could force WINS-B to
also send a push notification to its other replication partner, WINS-C.
In certain rare situations, it might be desirable to use a push-only replication partnership for one-
way replication, for example, from a head office to a branch office. For example, suppose that
WINS-A in the head office configures WINS-B in the branch office as its push-only partner.
(WINS-B should also configure WINS-A as its pull-only partner.) When WINS-A receives updates
to its records, it notifies WINS-B, which sends an update (pull) request to WINS-A for the changed
records since the last replication cycle. In this scenario, WINS-B never sends its updated records to
WINS-A.
Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 717
Figure 20.22 Manually Starting Push Notification
301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 717
Push partnerships are generally configured in LAN environments where bandwidth is not an
issue, and it is not necessary to schedule replication to occur during off-peak hours. In general, you
should use push replication partnerships in the following situations:

■
There is ample bandwidth over LAN or WAN connections.
■
There is a need to ensure that updates are replicated as soon as possible and the frequency
of replication traffic is not a consideration.
Pull Partnerships
Pull replication differs from push replication in that the replication frequency is defined as an
interval of time.At regularly scheduled intervals, a pull partner requests updates from other WINS
servers (those configured to use it as a push partner) for updated records that have a higher version
ID than the ones it currently has in its database.
Pull replication is configured similarly to push replication.The primary difference is that the
WINS administrator schedules the times that the pull replication will take place. Figure 20.23 shows
the settings for pull replication that an administrator can configure for individual replication partners.
In some situations, it might be desirable to configure pull-only replication between replication
partners. Usually, this configuration is implemented where WAN links are operating close to
capacity and there is a need to schedule WINS replication during off-peak hours. Pull-only replica-
tion has an advantage over push-only replication in that the replication schedule can be known in
advance. With push-only replication, replication is triggered by reaching a configured threshold of
updates, and you can only estimate when this would occur based on experience with the network.
However, a disadvantage of pull-only replication is that the WINS server could potentially have
acquired a large number of updates to replicate between cycles.
718 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy
Figure 20.23 Choosing Replication Partnership Type and Push/Pull Settings
301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 718
In general, you should use pull replication partnerships in the following situations:
■
There is limited bandwidth between WINS servers that requires replication to be sched-
uled during off hours.
■
There is a need to consolidate updates and reduce frequency and amount of replication

traffic.
■
There is a need to exercise finer control over the timing and frequency of replication
traffic.
Push/Pull Partnerships
A push/pull partnership is the default when you configure replication between WINS servers. In
fact, Microsoft recommends a push/pull partnership as a best practice and it further recommends
that all WINS partnerships be set up this way, unless there is an overriding need to implement a
limited partnership.The only need that Microsoft cites for a limited partnership is the presence of a
large network connected by relatively slow WAN links. Microsoft often stresses the need for sim-
plicity in a WINS environment.
With a push/pull partnership, a WINS server will be configured both to send push notifications
and to make pull requests to its replication partner.The replication partner will also be configured in a
similar way. Such a configuration helps to ensure that synchronization among WINS server is optimal,
depending on the pull schedule and the configured threshold for push notifications, among other fac-
tors. For example, suppose that a WINS server that suddenly experiences a large number of updates
immediately sends a push notification to its push partner.The push partner would immediately request
these updates, without waiting for the request to be triggered by its pull schedule. Conversely, a WINS
server always pulls up-to-date records from its pull partner according to the replication schedule,
regardless of how few records have been updated on the pull partner WIN server.
You should always try to deploy a push/pull partnership, unless there is an overriding concern
that requires the implementation of a limited partnership.
Replication Models
As we mentioned earlier, the replication model you design will have an effect on the convergence
time for replicated WINS records and fault tolerance for replicated records.A replication model that
is appropriate for your network topology will ensure the shortest convergence time for replicated
WINS records. Where possible, it is recommended that your replication model mirror your network
topology and that you keep this model as simple as possible.
In WINS environments where there are three or more WINS servers, you can employ either a
ring replication model or a hub-and-spoke replication model. In more complex environments, these

models can be combined to ensure optimal convergence time and fault tolerance for a given net-
work topology. In the following sections, we will discuss each of these models in more detail.
Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 719
301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 719
Ring Model
In a ring model, three or more WINS servers are configured to replicate with one another in a cir-
cular fashion.The ring model provides for good convergence times for all replication partners when
there are no more than four WINS servers. Figure 20.24 shows a ring replication model.
In this model, fault tolerance for replication of WINS records is given priority. Imagine that a
record is updated on WINS-A.The record must travel through either WINS-B or WINS-B before
it is replicated to WINS-C. However, suppose that the WAN link connecting WINS-A and WINS-
D fails.The updated record can still arrive at WINS-C and WINS-D (via WINS-C). Conversely, a
record created on WINS-D can still be replicated to WINS-A via WINS-C and WINS-B.
Hub-and-Spoke Model
In the hub-and-spoke model, all WINS servers replicate with a centrally located hub WIN server.
The hub-and-spoke model provides for the shortest convergence time in a replication environment
that comprises five or more WINS servers, because it provides for the shortest replication paths
between any two WINS servers. Furthermore, by implementing a hub-and-spoke model, you
reduce the number of replication partnership agreements that you need to maintain. Figure 20.25
shows a typical hub-and-spoke implementation.
720 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy
Figure 20.24 Ring Replication Model for WINS Servers
Push/Pull
Partnership
Push/Pull
Partnership
Push/Pull
Partnership
Push/Pull
Partnership

WINS-A
WINS-B
WINS-C
WINS-D
301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 720
Even though there are five WINS servers that replicate information, there are only four replica-
tion agreements to maintain. Furthermore, no server is more than two hops from any other server,
regardless of the number of servers added to the topology.
A disadvantage of this model is that it is not as fault tolerant as the ring model. If WINS-A fails,
no WINS server will be able to replicate its records to other WINS servers. Furthermore, depending
on the average number of records the spoke WINS servers need to replicate and the settings for the
push and pull triggers, WINS-A can be continuously replicating with other servers and processing
updates. It should be well connected to the other WINS servers and have the capacity to handle
the load.
A Windows cluster gives you the ability to set up separate WINS servers, known as cluster nodes,
that use the same database located in a shared SCSI or Fibre Channel device. When the WINS
server that is the active node in the cluster fails, the services will failover to another node. Failover is
the process of taking resources offline in one node and bringing them online on a new node.The
primary advantage of using a Windows cluster is that in the event of a failure of a WINS server, no
subsequent replication needs to occur to synchronize records when the failed server is brought
online, since only a single database is used. Windows Server 2003 Standard, Enterprise, and
Datacenter editions support clustering. For more information about clustering, see the Windows
Server 2003 help files.
Hybrid Replication Model
In many situations, it is desirable to combine replication models. As an example, consider a large
organization that has three divisions in different geographic locations. Each of these divisions has a
number of branch offices that are connected to their respective divisional offices. It might be advan-
tageous to use a ring model of WINS replication among the divisional offices and use hub-and-
spoke replication for replication between the divisional offices and their respective branch offices.
Figure 20.26 shows a conceptual representation of a hybrid model. Many other variations are

Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 721
Figure 20.25 Hub-and-Spoke Replication Model for WINS Servers
WINS-A
WINS-B
WINS-D
WINS-E
push/pull
partnership
push/pull
partnership
push/pull
partnership
WINS-D
push/pull
partnership
301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 721
possible.A hybrid replication model can employ any mixture of full and limited replication partner-
ships, driven by the contingencies of the network topology.
WINS Issues
After establishing the need for WINS planning for the replication topology of the WINS infrastruc-
ture, the WINS servers need to be installed and configured. In this section, we will look at the var-
ious configuration issues that a WINS administrator needs to be familiar with to ensure an efficient
and secure WINS infrastructure, such as handing static WINS entries, client configurations, database
maintenance, and WINS infrastructure security.
Static WINS Entries
One of the advantages of using WINS is that it provides a way to dynamically register NetBIOS
names, eliminating the need for static entries in LMHOSTS files. However, there are situations that
require the use of static mappings in the WINS server database. For example, if you have non-
WINS clients that are running NetBIOS applications, you might find it desirable to have entries for
these clients in the WINS database, so that you can allow WINS clients to resolve the NetBIOS

names of those clients. Static mappings are superior to entries in an LMHOSTS file because they
can be replicated throughout the WINS infrastructure.
The use of static mappings can create problems on your network. Unlike dynamic mappings,
static mappings stay in the WINS database until they are manually removed. (The expiration date for
the static mapping entry in the WINS database is labeled as infinite.) Furthermore, unless the migrate
on setting is enabled, static mappings are not overwritten by dynamic mappings. For example, a
client computer might be given a static mapping in the WINS database, or an LMHOSTS file
might be imported to the WINS database, creating a number of static WINS entries. If the clients
722 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy
Figure 20.26 Hybrid Replication Model
Hub and spoke
replication
Hub and spoke
replication
Hub and spoke
replication
Toronto
London
Dallas
301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 722
that are associated with the static mappings were later configured as WINS clients, they would not
be able to perform dynamic registration of their NetBIOS names, unless the migrate on setting was
enabled. Figure 20.27 shows the Replication Partners Properties dialog box, where the
Overwrite unique static mappings at this server (migrate on) setting is enabled.
In general, static entries should never be created for WINS-capable client computers. However,
it is sometimes desirable for security purposes to use static entries for mission-critical servers to pre-
vent redirection.
Using Static Entries to Prevent Redirection
Unlike with Active Directory-integrated DNS zones, you cannot restrict clients from dynamically
registering names according to Windows group memberships.The only mechanism by which

WINS prevents clients from registering duplicate names is to send a challenge to the IP address of
the active record. If the client responds to the challenge, the duplicate name registration is denied.
However, during periods when WINS clients are offline for maintenance or are being rebooted, a
rogue computer could register the same name as the original computer, with the malicious intent of
redirecting traffic to the rogue computer. In high-security environments, it might be desirable to
enter static mappings for critical computers and to ensure that the Overwrite unique static map-
pings at this server (migrate on) setting is disabled.
Multihomed WINS Servers
A multihomed WINS server is one that has more than one active network connection.You should
avoid this configuration of a WINS server. Name resolution and replication problems are often the
result of using a multihomed computer as a WINS server.
Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 723
Figure 20.27 Configuring Static Entries to Be Overwritten
301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 723
Client Configuration
WINS client configuration is accomplished either through a DHCP server or manually by config-
uring the settings in the WINS tab of the Advanced TCP/IP Settings property pages of the
TCP/IP properties. Figure 20.28 shows these settings for a Windows XP client.
With the configuration shown in Figure 20.28, the client will use an LMHOSTS file if WINS
name resolution fails.This is the default configuration. Also, the client is configured to get informa-
tion about whether NetBT should be enabled from the DHCP server. (This information is provided
by a special Microsoft-specific DHCP option.) If the client does not get this information from the
DHCP server, it will default to enabling NetBT.You would disable NetBT only when you need to,
such as on the Internet-facing interface of a multihomed server or if you have determined that the
interface does not need to be able to provide access to NetBIOS applications.
If you are using a DHCP server, you do not need to specify static addresses for WINS servers in
this dialog box. If you do configure WINS addresses here, these settings will override those that are
supplied by the DHCP server. If you are using DHCP to supply the client settings, you will need to
configure two DHCP options:
■

Option 044 WINS/NBNS Servers You use this option to provide DHCP clients with
the IP addresses of WINS servers to contact.
■
Option 046 WINS/NBT Node Type This option governs the order of NetBIOS name
resolution mechanisms that will be used.The hybrid setting option (0x08) is the one most
commonly used. With the hybrid node option specified, the WINS client will contact a
WINS server before using broadcasts and other methods to resolve names.The mixed
node setting option (0x04) forces WINS clients to use broadcasts before contacting the
WINS server.This setting is useful in situations where there is a single subnet in a small
branch office connected by a slow WAN link. In this case, you might want broadcasts to
724 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy
Figure 20.28 Advanced TCP/IP Settings for WINS Client Configuration
301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 724
resolve local NetBIOS names before contacting the remote WINS server. (NetBIOS node
types and name resolution were discussed earlier in this chapter.)
Figure 20.29 shows the configuration of DHCP server options to support WINS client
configurations.
Multiple WINS Server Addresses
If you specify multiple WINS server addresses in the client configuration, the client will try to use
the first WINS server in the list for registration and name resolution requests. If the primary server
fails to respond, the client will then attempt to contact the alternate WINS servers in the order
listed. Up to 12 WINS servers can be specified for Windows XP and Windows 2000 clients.
WINS Proxy Agent
For the rare case where you have a NetBIOS client that is not capable of querying a WINS server
for NetBIOS name resolution, you can set up a WINS proxy agent.The WINS proxy agent is a
WINS client that is set up on a subnet to provide limited WINS support for b-node and non-
WINS NetBIOS clients. A WINS proxy agent listens for name registration and name query broad-
casts, and it forwards these to its configured WINS server.This process ensures that the b-node
client does not initialize with a duplicate name that is already registered in the WINS database and
provides name resolution on behalf of the b-node client.

A common misconception is that a WINS proxy client will register the name on behalf of the
non-WINS client.This is not the case.The WINS proxy merely contacts the WINS server to verify
that the non-WINS client name does not exist. If there is a duplicate name in the WINS database,
the WINS proxy client will send a negative response to the b-node client.
The proxy agent will use its NetBIOS name cache to temporarily store the results of responses
to its queries to the WINS server. Performance of the WINS proxy agent could, therefore, be
Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 725
Figure 20.29 DHCP Options for WINS Client Configurations
301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 725