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 dif- ferent 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 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. A split registration for WINS servers can cause intermittent problems with WINS name resolution. 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 20.30 in the next section). 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. 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 simulta- 726 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 726 neous 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 20.30, 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. 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 pres- ence 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 fre- quently 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.The set- tings 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: Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 727 Figure 20.30 Configuring Burst Handling 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 727 ■ 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 replica- tion with other WINS servers. Figure 20.31 shows the Intervals tab with the default settings. 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 com- paction 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 728 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy Figure 20.31 Interval Settings for Registration Renewal, Removal, and Verification 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 728 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 fol- lowing 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 times- tamp. 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 20.32 shows the Database Verification tab of the property pages of the WINS server, where you can set the schedule for consistency checking. Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 729 Figure 20.32 Enabling and Scheduling Consistency Checking 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 729 In Figure 20.32, 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 cre- dentials 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, pri- marily 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 20.30 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 20.30). ■ 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 over- writing the static mappings with dynamic mappings. (This is controlled by the Overwrite 730 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 730 unique static mappings at this server (migrate on) setting in the Replication Partners Properties dialog box, shown in Figure 20.27 earlier in this chapter.) Protecting the WINS Database and Log Files The WINS databases and log files contain important information about your network.The informa- tion 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 confi- dentiality, 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 informa- tion 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). Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 731 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 731 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 shut- down (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 20.33 shows the set- tings for configuring automatic backups. 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. Troubleshooting Name Resolution Issues Proper name resolution is critical to the smooth operation of the network. When name resolution fails, for whatever reason, users might be inconvenienced, and connectivity to critical systems might be compromised. Usually, a name resolution failure requires immediate action on the part of the administrator, even if the failure is not widespread. Often, problems that appear to be related to name resolution are, in fact, the result of problems that occur further down in the OSI or DoD networking models for TCP/IP. For example, if a router fails, and the DNS or WINS servers are on the other side of the router from the client, clients will not be able to resolve names.The failure of a router occurs at Layer 3 (Network layer) of the ISO model. As part of a prudent and successful troubleshooting strategy, it is important to troubleshoot from the bottom of the OSI model up, ensuring the following: 732 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy Figure 20.33 WINS Backup Configuration 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 732 ■ The hardware is functioning properly. ■ The computer is configured properly. ■ The computer is able to communicate with hosts on the local subnet. ■ The computer is able to communicate with the router configured as the default gateway. ■ The computer can communicate with remote networks on the far side of the router. Usually, this troubleshooting will rely on tools such as Ipconfig to verify configuration and PING (using IP addresses) to test communication. Name resolution occurs further up in the OSI or DoD model.You need to discover if is the failure specific to NetBIOS or DNS (host name resolution).To make this determination, you can test name resolution using applications that are specific to these interfaces. For example, to test NetBIOS name resolution, try to connect to shares using a UNC path or the net commands, invoked from the command line.As long as the name you are trying to resolve does not include dots or is less than 15 characters long, Windows clients will default to using NetBIOS resolution first. If name resolution is successful, but you encounter a delay, chances are that NetBIOS resolution failed but that the fallback host name resolution was successful.To test host name resolution, you can use WinSock applications, such as NSLookup,Telnet, FTP, HTTP, and so on. You should also consider whether NetBT is enabled, either by means of a DHCP server option or as a configuration on the client computer. Some applications, such as Microsoft Exchange Server, still require that NetBT be enabled to work properly. In troubleshooting name resolution problems, you should therefore take into account the applications that may be involved and their dependence on either the WinSock or NetBT interfaces to work properly. It is sometimes obvious that the problem is specific to either host name or NetBIOS name res- olution. In any event, after you have made the determination, you can proceed to troubleshoot according to the interface (WinSock or NetBT) that is involved. Troubleshooting Host Name Resolution Assuming you have eliminated any antecedent causes that have to do with connectivity and com- munication on the network, troubleshooting host name resolution is easier if you can isolate whether the problem is caused by problems with client configuration or by problems with the DNS server. Problems with DNS clients include improperly entered addresses for the primary and sec- ondary DNS server, in addition to improperly configured DNS suffix search list settings. Problems with DNS servers include improperly configured delegations; improperly configured restrictions on zone transfers; missing, incorrect, or stale resource records; and so on. Effective troubleshooting of Microsoft DNS issues requires a familiarity with the process of DNS name resolution (for example, recursive versus iterative queries and authoritative versus nonauthoritative responses), dynamic updates, zone transfers, stub zones, forwarding, and so on. A familiarity with DNS-related troubleshooting tools, such as NSLookup, Ipconfig, Dnscmd, and DNSLint, will help to ensure that you can trace the source of the problem effectively. Using NSLookup, you can request either an authoritative or nonauthoritative response from the DNS server, which can help you to narrow down the problem further; for example, to determine whether a stale record is coming from the DNS cache or not. Furthermore, with NSLookup, you can use Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 733 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 733 debug mode to provide a great amount of detail in the output of the command.You can use DNSLint to check all your delegations and verify the correct configuration of well-known services, such as SMTP. Issues with dynamic registration can sometimes be resolved by using the command ipconfig /registerdns. Incorrect entries in the client DNS cache can be resolved with the ipconfig /displaydns and ipconfig /flushdns commands. Some tools that are not specific to DNS, such as Nltest, can help to troubleshoot DNS-related issues with domain controllers. Issues Related to Client Computer Configuration Many problems with DNS resolution have their origins in the client configuration, so verifying the correct client configuration is a good place to begin.To troubleshoot problems with client configu- ration, use the ipconfig /all command to verify the DNS configuration, and then use PING and NSLookup to verify communication with the DNS server. If you can ping the DNS servers, but an NSLookup query against them fails, the issue is most likely related to a problem with the DNS servers. (This is the kind of situation where troubleshooting from the bottom to the top of the OSI model really pays off in helping to narrow down the problem.) One of the more common and serious problems with client configuration is an improperly configured FQDN, which is set up in the properties of My Computer on Windows 2000 and Windows XP clients. If the FQDN is not present or is incorrectly configured on the client com- puter, name resolution can fail for domains that would otherwise be searched according to a domain suffix search list. For example, if the computer is a member of the corp.tacteam.net domain, and the user enters and uses an unqualified name (for example, PServer1) in a DNS query for a host in the tacteam.net domain, the query will fail unless the FQDN of the computer is properly configured. (An unqualified name is one that doesn’t have a trailing dot.) By default, the DNS client uses a domain suffix search list based on the FQDN. So, if the host name cannot be resolved in the corp.tacteam.net domain, the suffix will be devolved to tacteam.net to find the host.To troubleshoot problems with domain suffix search lists, try to resolve the name at the client using the FQDN (that is, include the trailing dot). If this query succeeds, but an unqualified query does not, the problem is related to the domain suffix search list. Clients that have improperly configured FQDNs might also have problems with dynamic registra- tion in the DNS zone.The client registration of a host record in a DNS requires that the primary suffix be properly configured. If the domain suffix is improperly configured, the client may be trying to register in a nonexistent or an unintended domain.To troubleshoot and resolve this problem, verify that the client computer is correctly configured with a primary domain suffix and that it can reach a name server that is authoritative for the domain name (you can simulate this by using NSLookup to perform an SOA RR query type for the authoritative zone). If the client receives its TCP/IP configu- ration from a DHCP server, verify that the DHCP server option for the domain suffix and other set- tings are configured correctly.Also, the client needs to be configured with the IP address of a DNS that contains the primary zone in order for the updates to occur. Meeting these conditions and then using the ipconfig /registerdns command to register the host in the domain might solve the problem. However, if the problem is still not resolved, chances are the source of the problem is the DNS server; for example, an ACL on the RR may be preventing the update. Using Event Viewer on the client computer can help you determine the nature of the problem. 734 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 734 If the DNS clients are getting incorrect responses to DNS queries, the problem might be related to their DNS cache.To clear the cache and force a new query to a DNS server for the host name, use the command ipconfig /flushdns. (Alternatively, you can use NSLookup to request an author- itative response.) If you have cleared the cache and are still getting incorrect responses to queries, it is likely the source of the problem has to do with the DNS server; for example, there might be an incorrect entry in the cache of the DNS server, a problem with zone transfers, or a delay in AD replication. Issues Related to DNS Services If you have determined that the problem you are experiencing is unrelated to DNS client settings or the client’s ability to communicate with the network, the problem is most likely related to DNS server configuration.To troubleshoot DNS server problems, you need to let the symptoms of the problem guide you to a likely cause and solution.Again, using a tool like NSLookup will help you get a clearer picture of the problem, since it can provide more detailed information and be used to get either authoritative or nonauthoritative responses from DNS servers.The following is a brief list of guidelines to help troubleshoot problems with DNS servers: ■ If clients cannot resolve names on the Internet or in domains for which their DNS servers are not authoritative using recursive queries, the problem might be related to the ability of the DNS server to perform recursion or to forward the query to a server that will perform recursion for it. In this case, check to make sure that the root hints file is present and the records are correct. If these settings are correct, your DNS server might be experiencing cache pollution. In this case, you should enable protection against cache pollution and restart the DNS service. ■ If clients do not get correct records or are getting stale records, the cause could be the cache on the DNS client or DNS server. Examining and clearing the cache will eliminate the problem. However, if the problem is unrelated to cache, the cause could be failed or slow zone transfers to the secondary zones. If you are using Active Directory-integrated zones, the cause could be related to problems with AD replication. Comparing the RRs in the various zone files and looking at events in Event Viewer will help to confirm zone transfers as being the cause or the problem. ■ If some clients cannot get responses to DNS queries from a multihomed DNS server but others can, the problem might be related to the listener settings on the DNS server.These settings can restrict which interfaces the DNS service will use to respond to queries. ■ If you are implementing a round-robin configuration to provide load balancing and are not getting the desired results, check the settings for subnet prioritization. Round robin is a kind of load balancing that can be configured using multiple host records that have the same name but different IP addresses. When round robin is enabled, the DNS server will rotate responses among all the records. However, if subnet prioritization is also enabled, the DNS server will try to respond with a record that is on the same subnet as the DNS client. ■ If zone transfers are failing between DNS servers, the cause could be improper restrictions on DNS servers that are authorized to pull zone information from the primary server. By Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 735 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 735 . 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. register the host in the domain might solve the problem. However, if the problem is still not resolved, chances are the source of the problem is the DNS server; for example, an ACL on the RR may. 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