Planning for NetBIOS Name Resolution


EXAM 70-293 OBJECTIVE 2.8

In a Windows 2000 or Windows Server 2003 environment, DNS is the primary method for name resolution. However, even in these environments, NetBIOS name resolution might still be extensively used. For example, if the network consists of older clients such as Windows NT 4 and Windows 9x clients, you must still support NetBIOS name resolution. Also, certain applications such as Microsoft Exchange Server, still rely on NetBIOS for their functionality. So, even if the domain is upgraded to AD and all of the clients on the network are upgraded to Windows 2000 or Windows XP, it might still be necessary to support NetBIOS name resolution.

Planning for NetBIOS name resolution means designing a NetBIOS name resolution infrastructure that ensures clients can always resolve NetBIOS names in a fault-tolerant and timely manner. The primary means for ensuring fault-tolerant and timely name resolution is through the implementation of WINS. Through its ability to replicate information with other WINS servers, WINS provides a distributed database that allows NetBIOS clients to register their NetBIOS names to ensure uniqueness and to resolve NetBIOS-to-IP address mappings consistently throughout the network infrastructure. Because WINS servers are capable of replicating database information to one another, this means that multiple WINS servers can provide both fault tolerance and availability of records for NetBIOS resolution to even very large networks that involve many different sites.

Understanding NETBIOS Naming

A NetBIOS name is a 16-character string that is used to identify computers, groups, or services on the network. The first 15 characters of the name are configured on the computer by the user or the administrator. This name serves as a mnemonic to assist users in connecting to computers and resources on the network. The sixteenth and last character of a NetBIOS name identifies a resource type associated with the NetBIOS-related services that are running on the computer. For example, Windows XP and Windows 2000 clients will register a name for the messenger service, the workstation service, and the server service. Additionally, the resource type can indicate whether the computer is a domain master browser.

There are two kinds of NetBIOS names:

  • Unique names These names are used to uniquely identify computers and the NetBIOS-related services running on them.

  • Group names These names are used primarily to support browsing and browser elections.

Collectively, NetBIOS names comprise a flat namespace. This differs from a DNS namespace, which provides a hierarchical namespace. And, while it is possible to group NetBIOS names according to a workgroup or domain name for display by the browser service, NetBIOS names must be unique within the NetBIOS namespace.

NetBIOS Name Resolution Process

In a NetBIOS environment that does not employ LMHOSTS files or WINS servers, NetBIOS is completely dependent on broadcasts to register names and to resolve NetBIOS names to addresses. When one computer uses a NetBIOS application to communicate with another computer, it must first determine the address for that computer. For a client configured to use a WINS server, the typical steps for NetBIOS name resolution are as follows:

  1. The computer checks its own name.

  2. The computer checks its NetBIOS remote name cache to see if it has a mapping cached in memory.

  3. The computer sends name resolution requests to WINS servers it is configured to use.

  4. The computer checks its LMHOSTS files.

  5. The computer sends a NetBIOS broadcast on the local subnet to find the address.

  6. The computer can then use the hosts file, followed by DNS.

start sidebar
Head of the Class...
NetBIOS Node Types

The order of NetBIOS name resolution is actually governed by the NetBIOS node type. There are four possible NetBIOS node types:

  • b-node (broadcast node) A b-node client will not contact a WINS server and will rely on broadcasts, an LMHOSTS file, and host name resolution.

  • p-node (peer node) A p-node client will use a WINS server, but will not use broadcasts.

  • h-node (hybrid node) An h-node client will contact a WINS server first before using an LMHOSTS file and broadcasts. The order of resolution for an h-node client is shown in the previous steps for NetBIOS name resolution, and it is the default configuration for a client configured to use a WINS server.

  • m-node (mixed node) An m-node client will use broadcasts before it contacts a WINS server.

You can configure NetBIOS node types by specifying the use of a WINS server in the WINS tab of the Advanced TCP/IP property pages, through Registry settings, or through DHCP options. The node types are stored as a REG_DWORD at HKLM:System\CurrentControlSet\Services\NetBT\Parameters, as follows:

  • b-node = 0x1

  • p-node = 0x2

  • h-node = 0x8

  • m-node = 0x4

end sidebar

Without the presence of WINS or LMHOSTS files to assist in name resolution, NetBIOS name resolution would generate considerable broadcast traffic for name resolution, adding to the traffic generated to support NetBIOS registration and the browser service. Furthermore, since NetBIOS broadcast traffic normally does not cross routers, it would not be possible to resolve computer names on remote subnets.

To support NetBIOS name resolution on a segmented network, you can use two methods. The first relies on the deployment of LMHOSTS. The second relies on the deployment of WINS servers. A third method, opening routers to forward NetBIOS broadcast traffic, is neither a sensible nor a viable solution in most instances, with the exception of small networks that must use separate networks because they are in different physical locations. That said, it is generally recommended that routers not be configured to forward NetBIOS broadcast traffic and that LMHOSTS files or WINS servers be used to support NetBIOS name resolution across subnets.

Understanding the LMHOSTS File

EXAM 70-293 OBJECTIVE 2.8.2

The LMHOSTS file is similar in purpose to the hosts file used for host name resolution. Both are text files that provide static mappings of names to IP addresses. However, the LMHOSTS file has added functionality that can be implemented with the use of special “tags” that can provide additional information. For example, you can use the #PRE tag (it is case-sensitive) to instruct the computer to always cache the record in the NetBIOS name cache. You can use the #DOM tag (it is also case-sensitive) to identify the computer as a domain controller.

LMHOSTS files are simple to create. They are created in the same folder where the hosts file is located. The complete path to the LMHOSTS file is %systemroot%\system32\drivers\etc\lmhosts, where %systemroot% is a variable used to identify the folder where the operating system is installed, such C:\Winnt or C:\Windows. When you open the %systemroot%\system32\drivers\etc folder, you will notice that a file named Lmhosts.SAM has been provided for you as a sample. This file contains instructions and sample records for creating an LMHOSTS file. You can modify this file for use as your LMHOSTS file, but it is important to remember that you must save the file without the .SAM extension in order for the file to work for NetBIOS resolution. As with the hosts file, the LMHOSTS file should have no extension.

LMHOSTS files are parsed from top to bottom, so you can optimize the operation of LMHOSTS files by placing any entries with the #PRE tag at the bottom of the file. These entries need to be read only once to be cached.

It is also possible to use a centrally located LMHOSTS file to provide name resolution for clients through the use of the #INCLUDE, #BEGIN_ALTERNATE, and #END_ALTERNATE tags in the LMHOSTS file. The #INCLUDE tag is used to indicate the NetBIOS UNC share name and path to the LMHOSTS file. Multiple #INCLUDE statements can be listed between the #BEGIN_ALTERNATE and #END_ALTERNATE statements.

In order for the client computers to be able to access the share specified in the #INCLUDE statement, the computers hosting the remote LMHOSTS files must have support for NullSessionShares enabled, which allows anonymous connections to the share. This is a weakening of file sharing security, so you need be careful when using LMHOSTS files in this way.

LMHOSTS files are a good solution in small environments that have a segmented network. In addition, they can be useful in situations where you want some computers to communicate with others across a WAN link, but you do not want to combine the NetBIOS namespace of the offices on either side of the link. However, in large environments, LMHOSTS files are difficult to maintain. An LMHOSTS file must be present on each computer that needs it for name resolution. You can create centralized LMHOSTS files, but the client computers must first have an LMHOSTS file to gain access to the centralized LMHOSTS files. Also, you must manually enter NetBIOS name-to-IP address mappings, increasing the possibility for error. Finally, the use of LMHOSTS files is not possible in an environment that uses DHCP to assigned TCP/IP address configurations to client computers.

To support NetBIOS name resolution in a segmented network or one that uses multiple broadcast domains, a better approach than LMHOSTS files is to use WINS. If a network has been using LMHOSTS files extensively, it is relatively easy to migrate to WINS by importing LMHOSTS files to the database to create static mappings. However, you need to exercise care to ensure that these mappings can be overwritten by WINS clients that use dynamic mappings. We discuss this issue in more detail later in the chapter.

Exam Warning

Planning NetBIOS name resolution by using LMHOSTS files is part of the objective domain for Exam 70-293. Therefore, you might encounter questions that require a knowledge of the LMHOSTS file.

Understanding WINS

In segmented network environments that use DHCP, the best solution to allow for proper NetBIOS name resolution is to use WINS servers. A WINS server provides a database that NetBIOS clients can use to register their NetBIOS names and resolve NetBIOS-to-IP address mappings. Furthermore, WINS traffic is unicast-based. This means that instead of relying on broadcasts to register and resolve names, WINS clients will send unicast messages directly to the WINS server, whether on the same or different subnet. The use of unicast helps to reduce the amount of broadcast traffic on the network that is the result of NetBIOS name resolution.

The ability for different WINS servers to replicate database information with each other is another significant advantage in that the replication of this information ensures that clients can resolve NetBIOS names regardless of their location or the WINS server they contact.

WINS Name Registration, Renewal, and Release Process

When a WINS-configured client starts up, it will attempt to register its NetBIOS names (that is, its computer name and other resource types indicated by the sixteenth byte of the NetBIOS name) using a unicast message to the primary WINS server that is configured in the Advanced properties of the TCP/IP protocol object. (If the client cannot contact the primary WINS server, it will contact the alternate WINS servers it is configured with. Up to 12 WINS servers can be specified on Windows 2000 and Windows XP clients.) The registration will be accepted or denied based on the presence of a preexisting registration for the same name.

If the name does not exist in the WINS database, the registration is accepted with a new version ID, given a timestamp, and marked with the owner ID of the WINS server. The timestamp is determined by adding the renewal interval (by default, six days) to the WINS server’s current date and time. The WINS server then sends a positive response to the client with a TTL value that is based on the timestamp.

If the name already exists in the WINS server, the WINS server will perform a number of steps based on whether the record is active and whether the IP address is the same or different as the record in the database:

  • If the name registration is for the same IP address and the WINS entry is marked as active and owned by the WINS server, a new timestamp is assigned and a positive response is sent back to the WINS client.

  • If the name registration is for a different IP address and the record is marked as being inactive, or tombstoned, or is owned by a different WINS server, the registration is treated as a new registration.

  • If the name registration is for a different IP address but the record is still marked as active, the WINS server will send a Wait for Acknowledgment (WACK) packet with a short TTL to the client trying to register the name. The WINS server will then issue a series of challenges in 500-millisecond intervals to the active node listed in its database (in the case of a multihomed computer, the challenges will be issued to every IP address listed for the node). If the node does not respond after three challenges, the WINS server treats the registration attempt as a new registration and sends a positive response to the client. However, if the client node in the WINS database responds to the challenge from the WINS server, the WINS server will send a negative response to the client attempting to register the duplicate NetBIOS name.

When a NetBIOS registration is successful, the WINS server stores the name mapping with the following information:

  • Record Name The NetBIOS name of the computer, group, or service registered in the database.

  • Type The resource type associated with the name. Common resource types are [00h] for the workstation service, [03h] for the messenger service, [020h] for the server service, and [1Ch] for the domain name.

  • IP Address The IP address for the registered name.

  • State The state of the registration, such as Active, Released, or Tombstoned.

  • Static Indicates if record is a static mapping (column entry marked with an x).

  • Owner Indicates the owner (specific WINS server where the record was registered) of the record.

  • Version Indicates the version ID of the record.

  • Expiration Indicates the date and time the record will expire, if it is not refreshed.

NetBIOS clients that do not use a WINS server must constantly register and defend their NetBIOS names. However, the registration occurs by means of a broadcast and, thus the registrations are local to the subnet. Whenever a computer attempts to register a duplicate name, it will receive a negative response from the computer that actively possesses the name. Whenever NetBIOS name registration fails, the computer receives an error message and NetBT won’t initialize on the computer until the problem is resolved.

Whenever a WINS client is gracefully shut down, it sends a name release request to the WINS server. The WINS server marks the entry as released and gives it a timestamp of the current time plus the extinction interval. This interval indicates the time that must elapse before the record is marked as extinct (or tombstoned) and can be scavenged from the database. However, if the WINS server that receives the release request is not the original owner of the name registration, it will immediately mark the record as extinct. The reason for this is to prevent inconsistencies between primary and secondary servers configured as replication partners.

start sidebar
Head of the Class...
Tombstoned Records

A tombstoned record is one that is marked as extinct and can be scavenged (removed) from all WINS databases in which the record appears; that is, both the local and all replicated instances of the object will be removed. Tombstoning, which is a feature introduced with Windows NT 4.0 Service Pack 4 and carried over to Windows 2000, is a method by which an inactive record is allowed to remain in the WINS database so that its inactive state can be replicated to WINS replication partners. In the past, manual deletion of dynamic records was difficult and required extra administrative effort to prevent the record from reappearing on the original WINS server as a result of replication.

For manual deletion of dynamic records, WINS gives you the option of deleting only the local copy of the record or tombstoning the record; that is, replicating the deletion of the object to other WINS servers. To ensure that the record is properly removed, it is recommended that the manual tombstoning of the record take place on the WINS server that owns the record.

end sidebar

What’s New for WINS in Windows Server 2003

The WINS service was significantly improved in Window 2000, which introduced a number of significant enhancements, such as enhanced filtering and searching for records display and burst handling of WINS registrations. The WINS service in Windows Server 2003 maintains these improvements and adds two more improvements:

  • Filtering records It is now possible to combine filters used to query the WINS database. The available filters include record owner, record type, NetBIOS name, and IP address with or without subnet mask. You can also cache the results of queries in the RAM of the local computer from which the query is performed, improving performance for subsequent queries and reducing network traffic.

  • Accepting replication partners For pull replication, you can configure the WINS server to either accept or reject only the name records that are owned by a list of predetermined WINS servers. (Figure 6.24 later in this chapter shows the Advanced replication property page where accepting replication partners are configured.) In Windows 2000, it was possible to create only a list of replication partners to block.

Planning WINS Server Deployment

Planning for a WINS server deployment means designing a WINS server infrastructure that provides a fault-tolerant and highly available solution for clients to register and resolve NetBIOS computer names. Clients can be configured to use multiple WINS servers (up to 12) to register and resolve computer names in the event that the primary WINS server is unavailable.

WINS servers can be configured to replicate with one another to ensure both fault tolerance and the availability of records for name resolution in a distributed environment where WINS clients are registering with different WINS servers. The number of WINS servers that should be deployed depends on several complex factors such as the number of WINS clients that will be registering and resolving names and the network topology (in particular, the presence, number, and capacity of WAN links). If you require WINS replication to meet the goals of fault tolerance and availability, the WINS replication topology needs to be designed to ensure optimal performance in the replication of WINS records and the currency of those records, as well as to ensure optimal query response times, given the constraints of the network topology.

Server Number and Placement

The number of WINS servers you deploy will be determined by the number of WINS clients and the network topology. In general, you should try to design the WINS infrastructure to minimize the number of WINS servers. Having too many WINS servers can complicate network problems, so Microsoft recommends a conservative approach in determining the number of WINS servers and Microsoft further recommends one primary and one backup WINS server set up as replication partners to each other for every 10,000 clients.

In capacity testing for WINS, Microsoft configured a dedicated WINS service on Window Server 2003 machine running on a single-processor Pentium II with 128MB of RAM and a standard IDE hard drive. The server was able to process approximately 300 registrations per second and 350 queries per second. WINS is a disk- and CPU-intensive service, and these estimates will vary depending on the hardware that is in place. A dual-processor CPU will increase WINS performance by up to 25 percent. Placing the WINS database on its own separate disk spindle, using fast disks, and using RAID arrays can improve the performance of disk I/O required for WINS.

The WINS traffic between clients and servers is relatively small, about 40 bytes, which is the average size of a WINS registration for a client. So, 10,000 WINS records would be approximately 400KB. Through a 56 Kbps WAN link, this amount of data would take a minute to transfer, assuming you could transfer at this rate. It is more likely, though, that the effective bandwidth is somewhat lower than 56 Kbps, and the transfer of 400KB of information would take longer. This delay might or might not be acceptable. However, it is unlikely that 10,000 WINS registrations or 10,000 updated WINS records would need to be transferred simultaneously across the WAN.

To determine the actual number of WINS servers to deploy, you will need to take into account server hardware, WAN links, the number of clients, and the need for redundancy and availability. You should also take into account peak-load conditions that could occur, for example, if the power to client computers were suddenly terminated and then resumed, resulting in a large number of simultaneous registration requests.

Exercise 6.02: Installing the WINs Service

start example

In order to follow along with the discussion of WINS, you might find it helpful to install the WINS service on a Windows Server 2003 server. If you haven’t already installed Windows Server 2003, see Exercise 6.01 for some advice on how to get an evaluation copy of Windows Server 2003 and how to run it in a virtual machine.

Before installing the WINS service, you need to ensure that the server meets a couple of prerequisites:

  • The server needs to be configured with a static IP address.

  • The WINS TCP/IP properties must be configured so that the server uses itself as a primary WINS server.

  • You should not configure a WINS server to register with any other WINS server.

Here are the steps for installing WINS service:

  1. Select Start | Control Panel | Add or Remove Programs.

  2. Select Windows Components.

  3. In the Windows Component Wizard window, scroll down the list of Windows components, Highlight Networking Services, and then click Details.

  4. In the Network Service Services dialog box, click Windows Internet Name Service (WINS) and then click OK.

  5. If prompted, insert the Windows Server 2003 source CD to provide the installation files for the DNS service.

After you have installed the WINS server, make sure that the WINS server has a registration for itself. You can do this by following these steps:

  1. Open the WINS console by selecting Start | Administrative Tools | WINS.

  2. Expand the WINS server node, right-click Active Registrations, and select Display Records from the context menu.

  3. In the Display Records page, click Find Now. (Note that by not entering any query information, you are causing all records to be displayed. On a large network, you would want to limit the scope of the result set by entering query filters.)

If you don’t see a record, you can force the registration of the server in the WINS database. Assuming that the WINS TCP/IP properties have been configured so that the server points to itself as the primary WINS server, open a command prompt and enter the command nbtstat –RR (you must use uppercase Rs to achieve the desired results). Executing this command will cause the Windows Server 2003 to register itself in the WINS database without needing to restart.

end example

Note

It is not necessary to use the WINS console to configure WINS servers and to view records. Anything that can be accomplished using the WINS console can be accomplished from a command line using the Netsh utility. You can find more information about the Netsh utility in the Windows Server 2003 help files.

Planning for WINS Replication

EXAM 70-293 OBJECTIVE 2.8.1

Even in simple environments, it is a good idea to have two WINS servers configured as replication partners to provide greater fault tolerance and availability. This kind of replication is relatively easy to set up, for example by specifying configuration, and requires little planning.

In larger and more complex networks, however, the replication topology will need to be carefully designed to ensure an optimal convergence time for the replication of WINS records, given the size, topology, and available bandwidth of the network. Convergence time refers to the maximum amount of time it takes for an updated record to be replicated to all WINS servers in the infrastructure. Generally, convergence time is a function of replication pull schedules and the number of hops in a given replication path that a changed object must travel.

In reality, the amount of time it will take for a record to be synchronized depends on a number of factors. For example, a WINS server configured to send push notifications immediately upon receiving an update will replicate the record faster than the time determined by the replication schedule of the WINS servers that have configured it as a pull partner. Factors that can affect convergence time include the following:

  • The kind of replication partnership that is configured. A push/pull replication partnership is more efficient for replicating records than a limited partnership (push or pull only).

  • The settings for pull and push partnerships that determine the frequency of replication between servers.

  • The ability to use persistent connections for push and pull replication partners (this setting is the default and found in the Replication properties pages of the WINS server console.) The ability to use this setting depends on the presence of stable, high-speed links.

  • The particular replication model. The longer the replication path that a replicated object must travel, the longer the convergence time. In a complex replication environment involving multiple WINS servers, a hub-and-spoke replication topology provides the shortest replication paths.

  • The particular kind of update that occurs in the WINS database. For example, a name release update will not propagate as quickly as a name registration update because it is more common for a name-to-IP address mapping to be reused by the same computer, even in an environment that uses DHCP. Since this kind of update is not as urgent as a new name registration, the WINS server provides it with a greater latency period for replication.

Along with these factors, you will need to take into account the network topology in planning for WINS replication. Your WINS replication design should, if possible, mirror your network topology. For example, if the organization has a centrally located head office that is connected by high-speed, persistent WAN links to satellite branch offices, you should consider a hub-and-spoke replication model with full push/pull partnerships. In this model, the WINS server in the head office receives replicated records through the push/pull partnership and then propagates updates it receives from its own WINS clients and those changes it receives from the individual branch offices to the other branch offices.

To plan for WINS replication, it is important to first understand partnership agreements and the settings that can be configured on them.

start sidebar
Head of the Class...
WINS Change-Only Replication

After the initial replication that occurs between two WINS servers that have been set up as replication partners, all subsequent replication between WINS servers replicates only the updates to the database since the last replication cycle, reducing the load on the network and the WINS servers.

An update is defined by an increment in the highest version ID in the local WINS database for records the WINS server owns. An incremental update will occur, for example, when a new registration is added to the database or a previously registered client updates its IP address (a refresh of a previously registered name with the same IP address does not cause a change in the version ID). WINS replication partners use these version IDs to determine how many WINS records need to be exchanged in order to synchronize databases using incremental updates.

Unlike the version number that is found in a DNS SOA RR and applies to the entire zone file (rather than individual RRs), a version ID is associated with every WINS record. Version IDs are incremented across the entire set of records that a WINS server owns. For example, imagine a WINS server that owns client records with the following version IDs: Client-A, version ID = 64; Client B, version ID = 65; and Client C, version ID = 66. The highest version ID on the WINS server is 66. (Version IDs are stored as hexadecimal numbers, so these numbers represent 100, 101, 103, and 104 in decimal, respectively.) If Client B registers a new IP address with the WINS server, it is assigned the next highest incremental value in the database, in this case 67. WINS servers configured as replication partners would compare the version ID they had for this WINS server and request only those records that would bring them up to date.

WINS servers also maintain an owner-mapping table to store the highest version IDs associated with various owners of records of which it is aware. This table is built dynamically and stored in memory at startup. WINS servers use this table when communicating with replication partners to determine how many records to transfer.

end sidebar

Replication Partnership Configuration

In order for WINS servers to replicate WINS records with each other, a replication partnership must be configured between them. There are three possible kinds of replication partnerships that can be configured between WINS servers: push/pull (also known as full), push-only, and pull-only (also known as limited). You can set up a replication partnership manually or implement it automatically.

Automatic Partner Configuration

Automatic partner configuration is an option that can be implemented on small networks to eliminate the administrative effort for configuring replication partnerships between WINS servers. When the automatic partner configuration is enabled, the WINS server will send announcements using the multicast Internet Group Messaging Protocol (IGMP) address at 224.0.1.24, which is the well-known multicast address for WINS servers. When the WINS server discovers other WINS servers that are announcing themselves, the WINS server will automatically configure a partnership agreement between itself and the discovered WINS server. (Both must be enabled for automatic partner configuration.) When the WINS server discovers another WINS server, it will add the server to its list of replication partners, configure push/pull replication between the servers, and set the pull replication interval for every two hours.

Note

Automatic replication partners are removed from the list of replication partners when they are shut down gracefully. If you want the replication partnership to persist across restarts, you should manually configure the replication partnership.

Figure 6.24 shows the Advanced tab of the Replication Partners Properties dialog box, which contains the Enable automatic partner configuration option. To view this page, you need to view the properties of the Replication Partners node in the WINS console.

click to expand
Figure 6.24: Enabling Automatic Partner Configuration

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.

Note

By default, automatic partnership configuration is limited to two hops in Windows 2000 and Windows Server 2003, which is reduced from the default six hops for WINS autodiscovery in Windows NT 4. You can extend this limit by changing the McastTtl Registry entry. You can find this entry at HKLM:System\CurrentControlSet\Services\Wins\Parameters. Note that this entry is not visible unless you enable automatic partner configuration.

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), indicating 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 replication is initiated between the replication partners.

Push replication is not schedulable according to an interval of time. Rather, the WINS administrator 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 6.25 shows the Push Replication tab of the Replication Partners Properties dialog box with the default settings for push replication.

click to expand
Figure 6.25: Push Replication Settings

The settings that you enter here will determine the threshold trigger for the push notification. In the configuration shown in Figure 6.25, 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 connections 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 6.26. 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 replication 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.

click to expand
Figure 6.26: Manually Starting Push Notification

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.

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 6.27 shows the settings for pull replication that an administrator can configure for individual replication partners.

click to expand
Figure 6.27: Choosing Replication Partnership Type and Push/Pull Settings

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

In general, you should use pull replication partnerships in the following situations:

  • There is limited bandwidth between WINS servers that requires replication to be scheduled 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 simplicity 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 factors. 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 network topology. In the following sections, we will discuss each of these models in more detail.

Ring Model

In a ring model, three or more WINS servers are configured to replicate with one another in a circular fashion. The ring model provides for good convergence times for all replication partners when there are no more than four WINS servers. Figure 6.28 shows a ring replication model.

click to expand
Figure 6.28: Ring Replication Model for WINS Servers

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-D 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 6.29 shows a typical hub-and-spoke implementation.

click to expand
Figure 6.29: Hub-and-Spoke Replication Model for WINS Servers

Even though there are five WINS servers that replicate information, there are only four replication 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.

To enhance fault tolerance in this situation, you could set up a backup WINS server in the same location as WINS-A and configure a replication partnership agreement between them. This solution, however, increases administrative complexity for the maintenance of replication partnerships. An alternative solution that still provides a high degree of availability is to use Windows clustering for the hub WINS server.

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 advantageous 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 6.30 shows a conceptual representation of a hybrid model. Many other variations are possible. A hybrid replication model can employ any mixture of full and limited replication partnerships, driven by the contingencies of the network topology.

click to expand
Figure 6.30: Hybrid Replication Model

WINS Issues

After establishing the need for WINS planning for the replication topology of the WINS infrastructure, the WINS servers need to be installed and configured. In this section, we will look at the various 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.

Exam Warning

Exam 70-293 is mainly concerned with planning a WINS replication environment. However, it is important that you understand the WINS configuration issues involved with WINS replication.

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 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 6.31 shows the Replication Partners Properties dialog box where the Overwrite unique static mappings at this server (migrate on) setting is enabled.

click to expand
Figure 6.31: Configuring Static Entries to Be Overwritten

Note

Even though the Migrate On setting can prevent a number of problems associated with the ability to overwrite static entries, this setting does not affect all NetBIOS record types. For example, the domain [1Ch] record type is never overwritten, regardless of this setting.

In general, static entries should never be created for WINS-capable client computers. However, for security purposes it is sometimes desirable to use static entries for mission-critical servers to prevent 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 mappings 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.

The problem is that the WINS service binds to a single IP address. In theory, WINS is supposed to bind itself to the primary IP address of the first adapter listed in the binding order for adapters bound to the TCP/IP. However, Microsoft does not guarantee this behavior. It is important that all adapters be properly configured with routable IP addresses to avoid problems that might arise if WINS binds to an adapter with an improperly configured IP address.

Multihomed WINS servers also introduce potential problems with replication. The issue is that when a replication partner sends a pull request to the multihomed server, it uses a WinSock interface and specifies that the reply can come from any IP address. If the multihomed WINS server replies from an IP address that isn’t in the list the replication partner has for the multihomed computer, replication will fail. This is a consequence of specifying the name of the multihomed computer in a replication partner configuration. If the replication partner specifies the NetBIOS name of the multihomed WINS server, it will associate this name with an IP address. If the response to the pull request comes from a different IP address than the expected one, replication will fail. We can’t rely on the binding order to determine what IP address will be used on the reply, since WINS will consult its routing table to determine which IP address to use for sending the packet. This behavior is by design. The workaround for this is to configure all replication partners of the multihomed WINS server to replicate with each of its configured IP addresses.

Client Configuration

WINS client configuration is accomplished either through a DHCP server or manually by configuring the settings in the WINS tab of the Advanced TCP/IP Settings property pages of the TCP/IP properties. Figure 6.32 shows these settings for a Windows XP client.

click to expand
Figure 6.32: Advanced TCP/IP Settings for WINS Client Configuration

With the configuration shown in Figure 6.32, the client will use an LMHOSTS file if WINS name resolution fails. This is the default configuration. Also, the client is configured to get information 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 resolve local NetBIOS names before contacting the remote WINS server. (NetBIOS node types and name resolution were discussed earlier in this chapter.)

Figure 6.33 shows the configuration of DHCP server options to support WINS client configurations.

click to expand
Figure 6.33: DHCP Options for WINS Client Configurations

start sidebar
Head of the Class...
Using the nbtstat Command to Verify and Troubleshoot WINS Registration

You can use the nbtstat –n command to verify client registration with the WINS server. The Status column in the output of the command will show whether the name is registered, registering, or in conflict with another name. Here is an example of using this command:

C:\>nbtstat -n Local Area Connection: Node IpAddress: [192.168.100.20] Scope Id: []                 NetBIOS Local Name Table        Name               Type         Status     ———————————————————————     ADC1           <00>  UNIQUE      Registered     WORKGROUP      <00>  GROUP       Registered     ADC1           <20>  UNIQUE      Registered     WORKGROUP      <1E>  GROUP       Registered     WORKGROUP      <1D>  UNIQUE      Registered     ..__MSBROWSE__.<01>  GROUP       Registered C:\>

It is not necessary to restart a client computer to register NetBIOS names. Registration of NetBIOS names can be accomplished through the use of the nbtstat –RR (Refresh Release) command, which is invoked from a command prompt. This is useful in situations where you have just configured a WINS address in the TCP/IP properties or changed the TCP/IP address and wish to register the computer name immediately without rebooting.

The nbtstat command is also useful for troubleshooting problems with NetBIOS name resolution. You can use it to look at the contents of the NetBIOS remote name cache or to purge and reload the cache. The following are the options that can be used with the nbtstat command:

  • nbstat -a <name> List the NetBIOS name table for the remote computer specified.

  • nbstat -A <ip address> Same as above, except the IP address is specified.

  • nbstat –c List the names in a NetBIOS remote name cache.

  • nbstat –n List the NetBIOS names in use by the computer. This will show the NetBIOS names that have been registered by WINS.

  • nbstat –r Show statistical information and a list of names that have been resolved by broadcast and the WINS server.

  • nbstat –R Purge and reload the name cache.

  • nbstat –RR Refresh and renew NetBIOS registrations.

  • nbstat –s List the currently open NetBIOS sessions by name.

  • nbstat –S List the currently open NetBIOS sessions by IP address.

The nbtstat commands are case-sensitive, so you need to make sure that you use the correct case to receive the desired results.

end sidebar

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 broadcasts, 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 potentially improved by lengthening the amount of time an entry would persist in cache beyond the default 10 minutes.

Preventing Split WINS Registrations

A WINS server is also a WINS client to itself. A common configuration error is to specify a different WINS server to use as an alternate WINS server. The problem with doing this is that during startup of the WINS server, it will try to register its names with the WINS servers configured in the TCP/IP properties. Because the WINS server service won’t start until NetBT has initialized, this causes the WINS server to attempt to register its [00h], [03h], [20h], and other mappings (depending on any additional services present on the WINS server) with the alternate or secondary WINS. However, it will continue to try to register these mappings in the local WINS database. Once the local WINS database is available, the WINS server will switch to it to register the remaining mappings. This results in what is known as a split registration, where name mappings are registered in and owned by two different WINS servers. The remote WINS server configured as a secondary might own the [00h] and [03h] name mappings, whereas the local WINS server owns the [20h] name mapping.

A split registration for WINS servers can cause intermittent problems with WINS name resolution. For example, suppose that one WINS server owned the mapping for the file server service [20h] and another WINS server owned the mapping for the workstation service [00h]. Clients that used the first WINS server would be able to connect to file shares on the server, while users who used the second WINS server would not be able to do this. If the WINS servers replicated with one another, eventually the records would converge and the symptoms would disappear. However, the underlying problem would remain.

Note

In configuring the WINS client properties on the WINS server, you should specify only the IP address of the WINS server itself as the primary and secondary WINS server. However, even if you specify no WINS server IP addresses in the WINS client configuration, WINS will eventually register its mappings in the local WINS database.

Performance Issues

As mentioned earlier in the chapter, a typical WINS server can handle WINS registrations and name resolution requests for up to 10,000 clients, even if the WINS server has only modest amounts of CPU power and RAM. WINS traffic for each registration and name resolution request is relatively small. However, a number of factors can affect the performance of WINS server. These factors include the presence of other services running on the WINS server, the performance of database maintenance on the WINS server, various WINS server settings, and the flooding of the network with NetBIOS name registration requests. In this section, we’ll look at WINS server performance issues.

Hardware Considerations

Even a modestly powered computer can handle a large number of registrations and name resolution requests. However, WINS can generate intensive CPU and disk activity. WINS server performance is therefore, significantly improved by using fast disks and multiple CPUs. For mission-critical WINS servers that handle large amounts of data, it is a good idea to use RAID arrays to enhance fault tolerance and performance. If you don’t use a RAID array, you should consider placing the WINS database on a separate hard disk from the operating system. You can specify the location of the database on the Advanced tab of the property pages for the WINS server (see Figure 6.34 in the next section).

Moving the database to a separate spindle will improve disk I/O and the performance of the WINS server for not only name registration and renewal, but also for the performance of other tasks related to the maintenance of the database. You should be aware, however, that if you move the database files to a different location they will lose their security protection, and you will need to take additional measures to secure access to the database. We will discuss this issue later in this chapter.

If the organization requires a very high degree of fault tolerance and availability, you should consider using a Windows Server 2003 server cluster for the WINS service. This will require at least two WINS servers configured as cluster nodes to use a shared SCSI or Fibre Channel storage device.On large networks, adding more WINS servers to distribute the load will improve response times for WINS queries, but will add more replication traffic and require more administration.

To verify the need for additional or more powerful hardware, it is useful to take baseline measurements of the WINS servers using the Window Server 2003 Performance console. When you install a WINS server, approximately 15 performance-related counters are installed to gather data on the performance of your WINS server. You should regularly monitor these counters, along with those that measure overall system and network performance, to establish baselines that will help you determine the need to upgrade or add hardware. Looking at WINS counters without considering them in the overall context of system performance can potentially cause you to draw incorrect inferences with regard to the performance of the WINS servers. Some of the relevant WINS-specific counters you might wish to look at include the following:

  • Queries/sec Measures the rate at which the WINS server receives queries.

  • Total Number of Renewals/sec Measures the rate at which the WINS server receives renewals and is the sum of unique and groups renewals per second.

  • Total Number of Registrations/sec Measures the rate of registrations per second and is the sum of unique and group registrations per second.

Burst Handling

Since Windows NT 4.0 Service Pack 3, WINS servers have been capable of burst handling. Burst handling, which is enabled by default, allows the WINS server to handle a large volume of simultaneous registration requests. This situation can occur, for example, when power is suddenly returned to many computers after a power outage. With burst handling configured, the WINS server will respond positively to name registration and refresh requests before it writes them to the database. However, it will supply the WINS clients with varied and short TTLs for the name registrations to stagger the load for subsequent WINS client refresh attempts.

By default, burst handling occurs when the server has more than 500 requests in its queue. However, you can adjust this setting in the WINS console. As shown in Figure 6.34, the Advanced tab for the properties of the WINS server allows you to select a Low (300 requests), Medium (500), High (1000), or Custom (where you specify the number of requests). If the WINS server has more than 25,000 requests in its queue, it will start dropping queries.

click to expand
Figure 6.34: Configuring Burst Handling

It’s a good idea to ensure that burst handling is enabled for reasons other than improving the performance of the WINS server under peak-load conditions. When burst handling is enabled, it writes events to the event log. The presence of burst handling events can provide an indication that the WINS server hardware is not adequate. Furthermore, the presence of burst handling events can indicate a possible DoS attack on the WINS server. You can use Network Monitor or some other tool for analyzing network traffic to capture packets and track down the possible causes of the presence of burst handling events.

Scavenging of WINS Records

Performance of a WINS server will be affected by the settings that are used to determine how frequently clients refresh their registrations, how long it takes for a released or deleted registration to be removed from the database, and how frequently the database verifies its records to ensure the integrity of data. Scavenging is the process by which WINS records are removed from the database. More specifically, scavenging is a preset process that periodically runs on the WINS server and either deletes or changes the status of WINS records based on their timestamps and current state. For example, the status of an active record that has an expired TTL is changed by the scavenging process to a status of released. The status of a released record, in turn, is changed to tombstoned after the extinction interval for the released record has expired. The tombstone record is deleted (scavenged) from the database after the extinction timeout period has elapsed. The settings that control these intervals are found in the Intervals tab in the property pages of the WINS server. It might be useful to change these settings to improve the performance of the WINS server:

  • Renewal interval Governs the TTL of the client registration. WINS clients will attempt to renew registrations after half the renewal interval has elapsed. Increasing this interval will reduce the frequency of client renewal attempts and reduce the load on the WINS server. However, increasing the interval also makes the database less consistent with the network over time when computer names are changed. The renewal interval should be the same for all WINS servers when they are replicating with one another.

  • Extinction interval Governs the period that must elapse from when a name is marked as released and when it is marked as tombstoned.

  • Extinction timeout Governs the period that must elapse from when a name marked as tombstoned and is subsequently scavenged (removed) from the database.

  • Verification interval Dependent on the previous values and governs when a WINS server must validate active records it does not own; that is, records learned of via replication with other WINS servers.

Figure 6.35 shows the Intervals tab with the default settings.

click to expand
Figure 6.35: Interval Settings for Registration Renewal, Removal, and Verification

Database Compaction

When records are deleted from the WINS database, the space formerly occupied by them should be recovered to ensure optimal performance of the database. The process of recovering this space is referred to as compaction. The WINS service automatically and periodically performs online compaction of the WINS database. However, online compaction of the WINS database is not as efficient as offline compaction. It is, therefore, sometimes desirable for the WINS administrator to stop the WINS service (take the database offline) and perform a manual compaction of the database.

The WINS administrator can use Jetpack.exe, found in the System32 folder, for manual database compaction. The Jetpack utility works by creating a temporary database in which to compact the records, and then replacing the original database with the compacted one. To manually compact the database, the WINS administrator must first stop the WINS service and then issue the jetpack command, using the following syntax:

jetpack %systemroot%\system32\Wins\Wins.mdb [name_of_temp_database.mdb]

After running the jetpack command, the WINS administrator can start the WINS service again.

Using the net stop and net start commands, the WINS administrator can automate offline compaction in a batch file. For example, you can create a simple batch file that contains the following three lines:

net stop wins jetpack %systemroot%\system32\Wins\Wins.mdb [name_of_temp_database.mdb] net start wins

Once you have created the batch file, you can configure it to run at preconfigured intervals using the Task Scheduler or the AT command-line utility. For example, you could configure the batch file to run once a month during off hours to ensure that the database uses space optimally.

Scheduling Consistency Checking

In order to maintain database integrity in environments that employ replication, it is recommended that automatic periodic consistency checking be enabled. Consistency checking is the process whereby a local WINS server compares local entries that it has acquired by replication with the entries in WINS servers that own the record. If a WINS server detects that the records are identical between its locally stored copy and the remote database, it will update the record with a new timestamp. However, if the record has a lower version ID in the local database, it will pull the updated record from its replication partner and mark the original one for deletion.

Because consistency checking puts a significant load on the resources of a WINS server, it should be scheduled to run during off-peak hours. Figure 6.36 shows the Database Verification tab of the property pages of the WINS server, where you can set the schedule for consistency checking.

click to expand
Figure 6.36: Enabling and Scheduling Consistency Checking

In Figure 6.36, consistency checking is enabled and scheduled to run every 24 hours at 2:00 a.m. Additional settings allow the WINS administrator to specify the maximum number of records to verify and to select randomly selected replication partners. Consistency checking can also be manually initiated from the context menu of the WINS server in the WINS server console.

Security Issues

As with any service that you implement on your servers and your network, it is important for you to understand the service and take measures that mitigate the risk to the service and the network as a whole. These measures include setting up restricted ACLs, logging, auditing, and monitoring, as well as using VPNs or IPSec to secure WINS replication traffic. In the next section, we briefly examine issues related to the security of the WINS service.

NetBIOS Security Issues

With regard to NetBIOS in general and the WINS service in particular, administrators need to be aware that NetBIOS is an unauthenticated protocol. That is, users are not required to submit credentials before using the services provided by a WINS server such as name registration, renewal, release, and queries. This makes WINS susceptible to a number of different kinds of attacks, primarily DoS attacks and redirection attacks.

In a DoS attack, an attacker attempts to tie up the WINS service with a large number of requests that compromise the WINS server’s ability to process legitimate requests. To mitigate the risk of DoS attacks, you should do the following:

  • Secure the physical network from unauthorized access.

  • Enable burst handling. When burst handling is enabled, burst handling events are recorded in Event Viewer, providing an alert to a possible DoS attack. (This is set in the Advanced tab for the properties of the WINS server, shown in Figure 6.34 earlier in this chapter.)

  • Enable detailed WINS logging to provide more complete and specific logging of WINS events in the System log. (Also set in the Advanced tab for the properties of the WINS server, shown in Figure 6.34.)

  • Use a protocol-analysis tool, such as Network Monitor, to analyze traffic in the case of a suspected attack.

In a redirection attack, an attacker tries to register a rogue computer that has the same name mappings as a previously registered computer. If the previously registered computer is down for maintenance or is otherwise unable to respond to the challenge from the WINS server (for example, if it is also a victim of a specific DoS attack), the rogue computer will be able to register the name mappings with its own IP address. WINS clients will then subsequently be redirected to the rogue computer. To mitigate the risk of redirection attacks, you should do the following:

  • Identify mission-critical systems and assign them static mappings in the WINS database.

  • Ensure that the migrate on setting is disabled to prevent the WINS server from overwriting the static mappings with dynamic mappings. (This is controlled by the Overwrite unique static mappings at this server (migrate on) setting in the Replication Partners Properties dialog box, shown in Figure 6.31 earlier in this chapter.)

Protecting the WINS Database and Log Files

The WINS databases and log files contain important information about your network. The information in these files could be used by attackers to glean confidential information about your company. For example, by an analysis of the number of computers, the attacker could learn the names of those computers, the NetBIOS applications running on the computers, and so on. Furthermore, the integrity and availability of the WINS database and the log files are critical to the operation of the network.

It is particularly important to note that, if you change the default location of the WINS database files, they will inherit the ACLs of the new destination folder, removing the effective security they inherited by virtue of being located in a subfolder of the System32 folder. Also, the WINS backup files inherit the ACL of the folder used to store the backup files. To mitigate the risks to the confidentiality, integrity, and availability of WINS databases, you should consider doing the following:

  • Do not store WINS database files on anything except an NTFS formatted partition.

  • Ensure that the ACLs for the WINS database, backup, and log files are restricted to allow access to only the Local System Account and the Administrators group.

  • Enable file auditing on the WINS files to track attempts of objects that try to access these files.

  • Ensure that the WINS server is physically secured from remote access.

  • Do not transfer WINS database files over the network using FTP or other unsecured protocols.

WINS Users Group

Only members of the Administrators group can modify the settings for WINS servers. However, it is desirable, in some situations to provide read-only access to the configuration and database information of WINS servers. To provide users with read-only access to the WINS server, you can use the special WINS Users group. Users who are members of this group are able to query the WINS server database to find records and to view configuration information.

Planning for WINS Database Backup and Restoration

Although it is possible to rely on replicated copies of WINS records to restore a corrupted database, you should only do so as a method of last resort. It is far better to back up the WINS database, either manually or automatically, and restore WINS records from the backup, if necessary.

By default, the WINS database is not backed up automatically. To back up a WINS database automatically, you need to do the following:

  1. Specify a backup directory in the General tab of the WINS server properties. (WINS will create a folder called Wins_bak under this folder to store the backups.)

  2. Perform a manual backup of the WINS database to the specified location. You can do this by choosing the Backup Up Database option from context menu of the WINS server object in the WINS console tree.

After you have performed these steps, backups will occur every 24 hours or upon service shutdown (if so configured). In the event that the WINS service detects a corrupt WINS database upon startup, it will automatically restore the backed up version from the location that you specified for the WINS backups. You cannot use a network drive for this location. Figure 6.37 shows the settings for configuring automatic backups.

click to expand
Figure 6.37: WINS Backup Configuration

Note

As part of a comprehensive restoration policy, you should also ensure that you have recent backups of the Registry, such as a backup of the System State.

To restore the WINS database, you can stop the WINS service, delete the original database, and restore the backup. If you do not stop the WINS service, the option to restore the WINS database will be grayed out.




MCSE Planning and Maintaining a Windows Server 2003 Network Infrastructure. Exam 70-293 Study Guide and DVD Training System
MCSE Planning and Maintaining a Windows Server 2003 Network Infrastructure: Exam 70-293 Study Guide and DVD Training System
ISBN: 1931836930
EAN: 2147483647
Year: 2003
Pages: 173

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net