An Account Lockout Problem; A DHCP Server Issue

Win2K Account Lockout Problem
Network administrators usually set an account lockout policy to discourage malicious users from trying to hack account passwords. However, Windows 2000's domain controller (DC) replication code contains a bug that produces unexpected results when the system locks down a user account after a user enters the maximum number of bad passwords.

When a user enters the maximum number of bad passwords (e.g., three), the authenticating DC records the number of bad passwords and then locks the user account. Unfortunately, when the authenticating DC replicates, it replicates the account’s bad password count and its locked status.

You can log on as an Administrator and unlock the user account from a different DC (i.e., not the one that originally locked the user account). Doing so resets the bad password count to 0 and unlocks the user account. When the DC on which you unlocked the account next replicates, it correctly replicates the account's unlocked status, but it doesn't replicate new bad password count (0).

If the user subsequently logs on to the same DC where the account lockout occurred, the DC will still have the account’s bad password count because the replicating DC didn't replicate the new value. If that user doesn't enter the correct password the first time, the authenticating DC will lock the account again.

This problem exists on all Win2K systems, from the original release through Service Pack 2 (SP2). Call Microsoft Support for the code fix, which updates nine core OS components. See Microsoft article Q278299 for more information.

Win2K Incorrectly Calculates SFM File Sizes
Windows 2000 Server machines that run Services For Macintosh (SFM) might report that SFM files are larger than they actually are. When the server lists incorrect file sizes, Macintosh clients might report that the volume on the Win2K machine is full, which adversely affects file transfers. To correct the problem, call Microsoft Support and ask for the new version of sfmsrv.sys, which has a file release date of March 30. Microsoft article Q277862 indicates that this problem exists in Win2K Service Pack 1 (SP1) and SP2.

Win2K DHCP Server Assigns Reserved Addresses
If you configure a DHCP server with a scope that excludes several addresses, the server might make repeated attempts to assign reserved addresses to clients making address requests. When a DHCP client requests an address that's outside of the scope that you have defined on the DHCP server, the server incorrectly offers a reserved address. When the client then requests the reserved address, the server realizes that the requested address is on the reserved list and refuses to assign the address that it originally offered. In fact, the server might cycle through several reserved addresses, offering and then refusing to assign those addresses. Windows NT 4.0 and Windows 9x DHCP clients eventually stop requesting addresses from the Win2K DHCP server, but Win2K clients continue to make requests until the they receive valid addresses. The net result of this problem, which results from a DHCP server bug, is that all clients might go without valid addresses, either temporarily or permanently.

Microsoft article Q284145 indicates that Microsoft has a bug fix, q284145_w2k_sp3_x86_en.exe, which you can download if you can find it. I couldn't locate the file on the Web site; you might have to call Microsoft Support. This problem exists on all versions of Win2K, from the original release through Service Pack 2 (SP2).

Some LPR Print Jobs Disappear
If you log on with a guest account or an account that's local to a print server and print to an LPR printer, the spooler correctly queues the job for printing, but the job never actually prints. You can work around this problem by logging on to the print server with an Administrator account and printing a test page. Subsequent print jobs will print correctly, but the problem will reoccur after you reboot the print server. If you experience this problem on your system, you’ll find a message in the System event log with Event ID 45. Call Microsoft Support for the spooler update, new versions of localspl.dll and spoolss.dll with file release dates of February 22.

W32 Time Bug
Windows 2000 relies on an exact time and date to implement Kerberos authentication. To ensure that a Win2K system can always set the time, you can configure a system to query multiple Network Time Protocol (NTP) servers. If the first NTP server doesn’t respond, the time service can query each subsequent server until it receives a response. To define multiple NTP time servers, use the command net time/setsntp. The /setsntp argument accepts multiple time servers, and you can specify each with a Fully Qualified Domain Name (FQDN) (e.g., ts1.domain.com) or with a TCP/IP numeric address (e.g. 122.123.124.125).

If you specify the time servers by name, not numeric address, a time service bug causes the service to query only the first name on the list. When the time service doesn't receive a reply from the first server, it loops through the list but queries only the first server on the list. You can work around this problem by specifying the time servers by TCP/IP address. To permanently correct the problem, call Microsoft Support and ask for the time service update. The update contains two files, w32tm.exe and w32time.dll, with file release dates of March 12. This problem exists in all versions of Win2K, from the original release through Service Pack 2 (SP2). See Microsoft article Q285641 for more information.

Microsoft Support Web Site Reorganized
Get ready to change the way you research problems. Microsoft has put a completely new front end on the Microsoft Support Web site, so all your carefully saved and filed links are now defunct. Given that millions of readers from around the world consult Microsoft's site to research problems and obtain fixes, I think that the company should

The new support front end is oriented toward IT tasks, and our familiar Microsoft Support Online search page is now buried several layers deep. I’m not even sure how I found the new page. To spare you the trouble of struggling through the same exercise, I'll give you the new URL:
http://search.support.microsoft.com/kb/c.asp?FR=0&SD=tech&LN=EN-US