Windows 2000's Device Manager and Add Printer Wizard can update drivers automatically, which is handy when you want to take advantage of the newer features on network or video cards or when you install a new, high-speed color printer or scanner. But you might not know that Microsoft changed how Windows Update (http://windowsupdate.microsoft.com/default.htm) identifies and downloads driver updates. If you ask Windows Update to update your drivers today, the site will download and install only drivers released on or before November 15, 2002, even if newer drivers are available. To obtain the most current version, meaning all drivers released after November 15, 2002, you must first download and install the new version of the Windows Update Code Download Manager.
You can locate and download this update by using two different methods at Windows Update: the long way with a regular scan or the short way, by using the Windows Update Catalog. If you have enough patience to peruse a list of all the recommendations that don't apply to your system, click Scan for updates and browse the Critical Updates and Service Packs list. The entry Q329553: Critical Update is the new version of the Code Download Manager. For more details about the update, see the related Microsoft article "Cannot Obtain Device Driver Updates from the Windows Update Web Site" (http://support.microsoft.com/?kbid=329553). If you’re in a hurry, click Windows Update Catalog in the left pane (if you don't see the link to Windows Update Catalog, click Personalize Windows Update), select Windows 2000 SP3 as the OS, select the desired language, and click Advanced Search Options. Under Date posted to the Web, select past month and enter Code Download Manager as the search string. Microsoft released the new version of this utility on April 22, 2003; the download file q329553_w2k_sp4_x86.exe contains three files, cdm.dll, iuctl.dll, and iuengine.dll, with file release dates of April 3, April 1, and April 1, respectively.
While you’re at Windows Update, you might want to download and install a second Windows Update bug fix, 814033: Critical Update. You can read the related Microsoft article "Cannot Install Driver Updates from the Windows Update Web Site" at http://support.microsoft.com/?kbid=814033. This bug fix purports to correct a problem that causes Windows Update–based driver installs to fail. Although the explanation for this fix (too many .inf files in the %systemroot%\inf directory) doesn't make sense on a technical level, it might be nice to have the patch available if you experience problems installing Windows XP or Win2K drivers at the site. If you have this update, you can install it and see if it takes care of the problem. This fix is also available at the Microsoft Download Center: Get the XP version at http://microsoft.com/downloads/details.aspx?amp;displaylang=en&familyid=75ff4d9a-9b03-4c3b-9ea3-03f926a0bc50&displaylang=en and the Win2k version at http://microsoft.com/downloads/details.aspx?amp;displaylang=en&familyid=40d20923-8a66-4aea-b70a-95af6bf1a42c&displaylang=en.
Unsynchronized Computer Account Prevents Logon
On Win2K systems, I’m sure you’ve seen the infamous UserEnv event ID 1000 error message Windows cannot determine the user or computer name in the System event log on many occasions. The equivalent message on Windows NT systems is There are currently no logon servers available to service the logon request. The messages indicate that the machine was unable to log on to a Win2K or NT domain. Assuming the computer already has an account in the domain, there are two common reasons for this problem: Either the machine was unable to contact a DNS server to obtain the address of the nearest Win2K domain controller (DC), or the computer account is no longer valid. If the DNS server is the problem, adjust the TCP/IP configuration so that it points to the correct server or servers, and verify the DNS server is online and reachable with a Ping or Tracert command.
The situation is slightly more complicated when the machine’s account is no longer valid. All Windows server and client platforms cache domain credentials locally on the machine. Cached credentials let you log on even when your machine can't contact an authenticating DC. When a system logs you on with cached credentials, the log on is transparent (unless you make a registry modification that causes Winlogon to report the cached logon). Things appear fine until you try to access a shared resource in the domain. To access the shared resource, the machine hosting the share first authenticates the user and the machine account. Because the machine account is no longer valid, the password likely is no longer synchronized, the authentication fails, and you see the Userenv message in the System event log.
To reset the computer’s account, reconfigure the system to join a workgroup by using a generic name of Workgroup or any other name that appeals to you, and reboot. After the reboot, join the system to the desired domain and reboot a second time. During the second reboot, the system renegotiates its account password with the authenticating DC and is able to successfully join the domain. The environment variable LOGONSERVER always contains the name of the machine that authenticated the user and computer accounts. When you log on with cached credentials, echo %logonserver% displays the name of the local machine. So, for example, when you join the machine to a workgroup, LOGONSERVER contains the name of the local machine. When you successfully log on to a domain, the command echo %logonserver% displays the name of the authenticating DC. If you want to read more about this subject, I suggest you start with the Microsoft articles "Windows Cannot Determine the User or Computer Name" (http://support.microsoft.com/?kbid=329708) and "Windows 2000-Based or Windows Server 2003-Based Computer Is Inaccessible from the Domain" (http://support.microsoft.com/?kbid=306927).
