Systems administrators have waited a long time for Windows NT 4.0's Service Pack 4. SP4 has received publicity primarily for its Security Configuration Editor (SCE—for more information about SCE, see Mark Joseph Edwards, "Service Pack 4's New Security Configuration Editor," October 1998), but don't let the service pack's real benefits pass you by. SP4 includes significant bug fixes and new features for three core NT networking technologies—Dynamic Host Configuration Protocol (DHCP), Windows Internet Naming Service (WINS), and Domain Name System (DNS). Here's a roundup of these technologies' failures and how SP4 fixes those problems.
Number of DHCP Scopes Expands
Some firms place a lot of scopes on one DHCP server—one large firm put 1200 scopes on one machine to centralize its DHCP services. The result of this setup is interesting. The system's 1200 scopes require 1200 subnets. When the server receives a DHCP discover message, it must find the scope for that particular subnet, then figure out which (if any) IP addresses are available for that subnet. Microsoft didn't build DHCP to handle 1200 scopes; when a DHCP query comes to the server, the server locks up the DHCP database and ignores incoming DHCP requests while it searches for the scope. This method isn't as goofy as it sounds; Microsoft expected customers to put no more than a dozen scopes on a DHCP server. If you have only a dozen scopes, the lock-and-search process doesn't take long. However, if you have 1200 scopes, the process can be time-consuming, and the fact that every DHCP search queries the database on disk worsens the problem.
SP4 fixes the DHCP slowness in two ways. First, it stores the DHCP database in RAM (which makes DHCP a little more—but not much more—RAM-thirsty). Second, SP4 offers a redesign of DHCP; the program is now multithreaded, so it can search the database and listen for new DHCP queries at the same time.
DHCP Handles More Reservations
SP4 offers more good news for big-network DHCP administrators. I've never run across this problem on my network, but if you don't have SP4 and you give a DHCP server more than 570 DHCP reservations, DHCP Manager displays only the past 570 reservations. This limitation makes managing lots of reservations impossible. Presumably, SP4 makes the sky the limit.
DHCP Server Rechecks Bad Addresses
When a DHCP server gives a DHCP client an IP address, the client verifies that no other machine is using that IP address before the client gets comfortable with the new address. Suppose a DHCP client receives the IP address 200.200.100.200. When it receives the address, it uses an Address Resolution Protocol (ARP) request to broadcast on the local subnet, asking the question, "Is anyone out there using 200.200.100.200?" If no computer responds to the ARP request, the DHCP client knows that it can use the address. But if a machine responds to the broadcast, the client knows that the DHCP server gave it a bad address. The client tells the DHCP server that its address is bad by sending the server a DHCP_DECLINE message (which basically tells the server, "Keep your IP address; I don't want it!"). When a DHCP server receives a DHCP_DECLINE message, it needs to note the bad address so that it won't offer another client the bad address. The DHCP server stores IP addresses that DHCP clients decline in its reserved addresses database; IP addresses in the reserved addresses database have the machine name BAD_ADDRESS.
So far, so good: Keeping track of bad IP addresses makes sense. But addresses that DHCP marks as bad might not stay bad—and once DHCP marks an address as bad, it always thinks the address is bad. The reserved addresses database's lack of a time limit can cause problems. In some large organizations, DHCP databases lock up bazillions of unused IP addresses because the addresses caused an IP address conflict at one time.
SP4 solves this potential problem by treating BAD_ADDRESS records as if they were any other DHCP lease. SP4 expires BAD_ADDRESS records after the network's typical lease period. When you apply SP4, it immediately notices and eliminates a bunch of BAD_ADDRESS records that have existed for much longer than the lease period. One side effect of installing SP4 is that suddenly your DHCP scopes have a lot of new IP addresses available.
DHCP Client Is More Tenacious
If a DHCP client discovers through an ARP that the IP address that its DHCP server provides is bad, the client declines the address and asks for another. If the second address that the DHCP server offers is also bad, an NT client without SP4 just gives up. But under SP4, DHCP clients don't give up after receiving two bad addresses. Microsoft hasn't announced how many IP address attempts an SP4 client will make, but the number is higher than two.
DHCP Offers More Logs
To log all DHCP actions, open DHCP Manager; select a server; and choose Server, Properties. DHCP logging is useful, but it produces one huge log for each server. Such large logs can be cumbersome to review. SP4 updates DHCP Manager to create seven logs: DHCPSrvLog.Mon, DHCPSrvLog.Tue, and so on. The improvement isn't huge, but it makes DHCP logging more manageable. (For more information about DHCP logging, see Darren Mar-Elia, "WINS and DHCP Preventive Maintenance," page 61.)
DHCP Excludes Addresses When You Expand the Scope
When I originally set up my class C network, I created a DHCP scope that handed out addresses between .12 and .100, but I excluded .33 and .50, the addresses of a Primary Domain Controller (PDC) and a mail server, respectively. I later expanded the scope to offer addresses from .5 to .200. Shortly after I expanded my scope, the PDC reported a duplicate IP address. DHCP had given .33 to a client machine. I scratched my head and moved the PDC to .240, an address outside the DHCP scope. (I later also moved the mail server to an address outside the scope.)
In acquainting myself with SP4, I discovered that the problem I ran into has always been characteristic of DHCP servers: When you extend the scope, DHCP forgets about the addresses that you told it to exclude. SP4 supposedly fixes that problem, and so far the fix seems to work.
Reregister a WINS Server Without Rebooting
Machines that have static IP addresses tend to be up and running all the time. These machines, which you don't often reboot, fall prey to a WINS name-reregistration problem. WINS name registrations have a specific life span (6 days by default). At some time during its WINS life span, a machine with a static IP address must renew (or, in WINS-ese, refresh) its name registration. However, WINS clients with static IP addresses don't properly refresh their name registrations. Microsoft documentation isn't clear about why this happens, but apparently the code that performs the initial WINS registration when you boot a machine is more reliable than the code that refreshes the name registration. After a week or so, the WINS name records for a server with a static IP address might not be available, and other computers on the network might no longer find the server. This behavior is quite odd. All of a sudden, you can't access a server from across the network. You think that the server must have blue screened, but when you walk down to the server room, the server seems happy. It lets you log on interactively and displays no problematic entries in Event Viewer. Rebooting the server solves the problem. Why? According to a Microsoft representative I spoke with, this type of problem arises from name-resolution troubles, and the answer is to refresh the name registration.
You can get around the name-reregistration problem in a couple of ways. First, you can avoid static IP addresses. If the server's IP address is not a static address but a DHCP reservation, then DHCP periodically renews the server's address without a problem. Second, you can renew the machine's DHCP lease. Every time DHCP renews a lease, the computer that has that lease reregisters with WINS. You can use the ipconfig /release command and then the ipconfig /renew command to force a DHCP lease renewal and WINS reregistration. Neither of these methods requires rebooting the server.
SP4 offers a third method for reregistering a WINS name: nbtstat -RR. This new nbtstat option forces a machine to reregister with WINS. The RR option is case-sensitive, so be sure to use two capital Rs.
The WINS Manager GUI
Any WINS administrator has noticed an outdated or extraneous record in the WINS database. When you notice such a record, you think you should be able to delete it—but just try to figure out how. If you don't have SP4, you can delete individual records only with a Microsoft Windows NT Server 4.0 Resource Kit utility named WINSCL. (For information, see "WINSCL," August 1998.) SP4 changes WINS Manager to let you delete individual records. Just click Mapping, Show Database; select the record that you want to remove; and click Delete Mapping.
In addition, SP4 lets you tombstone records. The need to tombstone comes from WINS servers' replicating loops, which can lead to WINS records with eternal lives. Suppose server A creates a record about a client named Maple and replicates the record to server B. Server B tells server C that it knows about this new client that server C needs to add to its database. Eventually, Maple's record expires on server A, but if server C replicates with server A before server C gets the message that Maple's record expired, server C will tell server A, "I see you don't have a record about Maple; add it!" Server A will add Maple's record, and the record will live on.
Tombstoning is SP4's means to prevent this never-ending replication loop. Under tombstoning, when server A removes Maple's record, it doesn't delete the record. Instead, it modifies the record to a tombstone state. (WINS Manager uses a cross to mark records that WINS has tombstoned.) When server C next replicates to server A and tries to tell server A about Maple, server A knows that server C is clueless and refrains from creating a record for Maple. Server A eventually replicates the tombstoned Maple record to server B. Server B replicates Maple's tombstoned record to server C. Now all the WINS servers in the enterprise know that Maple's record expired, and they don't create any more Maple records. After all the WINS servers in the enterprise tombstone Maple's record, WINS deletes the record during the next WINS scavenging operation. In an SP4 environment with multiple WINS servers, don't delete records; tombstone them. (For details, see Alistair G. Lowe-Norris, "Tombstones Mark the Coming of the End for WINS," page 99.)
WINS Handles More Name Registrations
SP4's WINS server software includes what Microsoft calls burst mode handling, which helps WINS cope with the busiest part of the day—the morning, when everyone's logging on and registering names. WINS temporarily stores incoming name-registration requests in a queue. During busy periods, WINS might keep more requests in the queue than it can handle. The server might have the memory to store all the requests, but by the time the server gets around to addressing the requests at the end of the queue, the clients have timed out. How does a WINS server solve this problem?
The Microsoft article "DNS/DHCP/WINS Release Notes for Windows NT 4.0 SP4 Update" (at http://support.microsoft.com/ support/kb/articles/q184/6/93.asp) explains that burst mode handling lets WINS take care of all requests because when the WINS server becomes too busy, it responds to name-registration requests by saying, "Go ahead and take the name you want, but come back in X minutes to reregister it." WINS varies the value of X to stagger the times at which the clients return to reregister their names. (WINS typically tells clients to reregister their names in 5 to 10 minutes.) Don't believe me? The article says, "For burst handling, additional client requests beyond the amount specified by the burst queue size are immediately answered with a positive success response by the WINS server" (my italics). Microsoft seems to have developed this name-registration scheme under the assumption that blindly approving name registrations is bad, but that blindly approving names for only a few minutes is better than having workstations off bothering the secondary WINS server and potentially creating more overflowing queues.
WINS enters this approve-everything mode when its registration queue holds more than 500 requests. You can adjust the number of registration requests that set off burst mode handling through the BurstQueSize Registry entry of type REG_DWORD in the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Wins\Parameters. Alternatively, you can use the BurstHandling entry in the same key to tell WINS never to enter burst mode. BurstHandling is also a REG_DWORD entry; set it to 0 to prevent burst handling.
DNS Servers Use BOOT Update Zones Properly
By default, NT's DNS servers keep in the Registry a list of the zones for which they are the primary or secondary DNS server. To be more BIND-compliant, you can list the zones in an ASCII file named BOOT. A non-SP4 DNS server with a BOOT file starts just fine, but if you make the server a primary or secondary server for a zone that the original BOOT file didn't name, the server updates the Registry's list of zones but doesn't update the BOOT file to include the new zone. SP4 fixes this problem.
DNS Servers Handle Names with Many Addresses
When a DNS server attempts to resolve a name such as www.minasi.com, the server usually receives one or two IP addresses in response. But some sites respond with a lot of IP addresses. Just fire up an NT workstation that is attached to the Internet, open a command prompt, and type
nslookup
When you get nslookup's > prompt, type
www.microsoft.com
I recently tried this and got 11 responses. Why 11? Because Microsoft runs several identical Web servers (11 at the time I ran the query) to handle the immense amount of traffic to its Web site.
Some DNS name resolutions return considerably more than 11 responses, which causes DNS problems. When DNS receives queries for IP addresses that it associates with a particular name, the software responds in 512-byte packets. If all the IP addresses fit into a 512-byte packet, DNS has no problem. But if DNS finds too many addresses to fit in a 512-byte packet, it notes in the first packet that it has provided 512 bytes' worth of addresses but that it has other addresses and that the requesting machine needs to ask for the rest of the addresses. The "I have more addresses; come get them" message is the truncation flag in DNS argot.
| Don't let SP4's real benefits—improvements to DHCP, WINS, and DNS—pass you by. |
Secondary-to-Primary Role Transfer Works
Suppose you set up an NT DNS server as a secondary DNS server for a zone. Then, you decide to take that zone's primary DNS server offline, so you want to make the zone's secondary DNS server the primary DNS server for the zone. This change sounds simple, but it isn't always easy. The originally secondary DNS server sometimes refuses to see itself as the primary DNS server and searches in vain for the true primary. Upgrading a secondary DNS server to become a primary DNS server works better under SP4, although swapping the primary and secondary roles in DNS is still bumpy.
Responses for Nonexistent Records Are Faster
If you try to look up an IP address for a name that doesn't exist, you experience a delay while DNS figures out that no computers with that name exist. Without SP4, NT's DNS unnecessarily adds a 30-second delay to that wait. Under SP4, you still have to wait while DNS looks for IP addresses with the name you enter, but you don't have to wait the extra 30 seconds.
Caching DNS Servers Don't Need to Use Port 53
Part of what makes DNS standard is its port number, 53. If you query the Windows NT Magazine DNS server to find www.winntmag.com, you're querying some IP address at port 53.
Unfortunately, computer lowlifes have targeted DNS with attacks, so some firms have closed port 53 on their firewall. But folks inside the firewall also need DNS name resolution. Companies commonly install DNS servers that aren't authoritative—all they do is resolve DNS requests, using the Registry value for DNS name caching. But caching-only DNS servers don't solve the firewall problem because placing a caching server inside the firewall requires you to open port 53.
If your DNS server is a caching-only server, then you don't care which port DNS uses. SP4 lets you change the DNS port number for caching servers. After you install SP4, create a new Registry entry named SendOnNonDnsPort of type REG_DWORD in the HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\Services\DNS\Parameters key, and specify the new port value. Restart the DNS server, then ask the keepers of your company's firewall to open the new port. You can close port 53 to traffic but keep your caching DNS servers inside your firewall.
Worth the Wait
SP4 offers quite a few fixes for DHCP, WINS, and DNS. Better yet, SP4 is free, unless you place a price on the time that downloading the service pack's 35MB of fixes takes. SP4 was a long time coming, but it's worth the wait.
