Task Scheduler Bug Fix
You can schedule repeating jobs in Windows 2000 using the Control Panel Scheduled Tasks applet's New Task wizard. However, Task Scheduler (mstask.exe), the service that implements the tasks you define, has an intermittent problem that causes mstask.exe to stop running jobs and to incorrectly display the status of scheduled jobs as "Running." According to Microsoft article Q272022, when a job doesn't run, Task Scheduler creates a list of jobs to resubmit based on the end time of the last job on the list— usually midnight. If any of the tasks don't complete, the Task Scheduler bug prevents the scheduler from resubmitting the job. You can temporarily work around the problem by manually restarting the Task Scheduler service. For a permanent solution, call Microsoft Support and ask for the new version of mstask.exe released September 27. The article indicates that Windows NT 4.0 also has this problem and that no bug fix is available for the legacy OS.
Downloadable Hotfix for Win2K
Microsoft article Q275286 indicates that Microsoft has bundled three fixes into a self-installing hotfix for Internet Security and Acceleration (ISA) Server 2000 systems. If you implement Quality of Service (QOS)-based service controls on your ISA servers, you should install this hotfix. It corrects two QoS problems and eliminates excessive client socket use. You can download the Q275286_w2k_sp2_x86_en.exe, which bundles the three hotfixes I describe below, from the Microsoft Web site.
- Q270921. The Windows 2000 QoS Packet Scheduler service doesn't classify forwarded IP packets to a traffic control flow, which means that the QoS filter and flow can't be applied to a connection that's being routed through Win2K. This limitation prevents a program such as Microsoft Proxy Server from controlling IP traffic when it's using Win2K routing services with the QoS Packet Scheduler service
- Q270923. The Win2K QoS Packet Scheduler might send the wrong checksum in the packet when the system's network adapter has hardware checksums enabled. This problem, which significantly slows packet scheduler processing, occurs only when the network adapter supports RxChecksumOffload and TxChecksumOffload and you have both features enabled.
- Q271067. When a client computer reaches a high open-and-close connection rate--about 600 connections per second— a timing problem in the IP Network Address Translation (NAT) driver prevents the connections from closing in a timely fashion, resulting in a large number of open sockets.
Win2K NAT Crash
Here’s a problem that you'll have to live with for a while. When you implement Network Address Translation (NAT) to redirect an IP address and port number, Windows 2000 might crash and display a Stop code of 0x000000D1(0x0070005D,0x00000002,0x00000000,0xF7197795. Microsoft article Q281292 indicates that the crash results from a race condition and that no workaround or bug fix is available.
Win2K Logon Script Bug Fix
Microsoft article Q275506 describes a Winlogon problem that occurs only if your logon scripts take longer than 10 minutes to execute— which, I suspect, happens only in rare circumstances. When you configure logon scripts, you can define the maximum interval that the logon script can run and whether the logon script runs synchronously. When a logon script runs synchronously, the user doesn't have access to the desktop until the script terminates.
You control how long a logon script can run with the Active Directory (AD) account setting "Maximum wait time for Group Policy scripts," specifying the interval in seconds. If you enter a duration greater than 10 minutes (600 seconds) and you run the logon script synchronously, Win2K gives the user access to the desktop after 10 minutes even if the logon script hasn't completed. This problem occurs because a timer is hard-coded for 10 minutes; when the timer activates, the user sees the desktop even though the logon script is still running. Microsoft Support has a new version of winlogon.exe released October 26 that eliminates the hard-coded timer issue and ensures that synchronous logon scripts follow the rules.
NT 4.0 Replication Issue
If an export server exports a ntconfig.pol file to its own import directory and if you change the file by adding or removing a privilege, the export server fails to replicate the modified file. This problem is difficult to identify because NT doesn't write an error message in the Event log and because the replication process reports the replication status as successful. In addition, NT changes the date and timestamp on the export directory but not on the import directory file. To diagnose this problem on your system, place a small text file in the export folder. When you edit the text file, NT replicates all files in the directory. However, if you modify only the ntconfig.pol file, it won't replicate. No errors appear, and the replication status reads as OK.
To work around the problem, rename ntconfig.pol but keep the .pol extension. Let replication occur and then change the filename back to the original (ntconfig.pol or config.pol). Replication should occur normally. You can now change the file as needed; replication continues unless a file is open. Microsoft article Q172445 documents this problem and the workaround; no bug fix is available.