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