One of our Windows 2000 Professional users reported that some features on her machine weren't working properly. She had logged on to the domain without error, but the Help desk reported that her logon script hadn't run; the domain controller (DC) was down when the user logged on to the domain. How could the domain logon have been successful?

During logon, Win2K saves a copy of each user's credentials. If Win2K can't find a DC during subsequent logons, the OS uses those cached credentials to log the user on to the domain. The user doesn't see an error message that says the DC couldn't be found, but the absence of features that the DC provides (e.g., home directories, policies, logon scripts) might cause functional problems.

You can look for certain clues that identify this situation. Logon takes longer. The Event Viewer records event ID 5719. If you open a command prompt window and type


the entry that names LOGONSERVER displays the local machine's name instead of the DC's name. Although mapping drives to shares on DCs is uncommon, if you've mapped a persistent mapped drive to a share on the DC, you'll get an error notifying you that the drive couldn't be found.

If a DC is unavailable, you have two remedies, both of which involve registry changes to the user's computer. (Before you attempt these changes, read the sidebar "Back Up Before You Hack.") You can prevent the domain logon from proceeding and let the user log on to the local machine instead of the domain. Or, you can let the user log on to the domain with cached credentials but force the system to notify the user that the DC is unavailable.

To implement the first remedy, use a registry editor to go to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon subkey and find the data item CachedLogonsCount. This registry entry specifies how many user account entries the computer can cache. The value can range from 0 to 50; the default is 10 users. Change the value to 0 to stop Win2K from saving user account information in the logon cache. You must reboot to put the new setting into effect. After you make this registry change, if no DC is available when a user tries to log on to the domain, Win2K will display the following message: The system cannot log you on now because the domain DomainName is not available. The user can click OK to return to the Log On to Windows dialog box and can use the available drop-down list to select the local computer.

To implement the second remedy, you must make two changes to the registry. The first change configures the computer to display information about missing DCs, and the second change enables this display feature for a particular user. (You'll need to repeat the second step for each person who uses the computer.)

To configure the computer to display an error message when it can't locate a DC, go to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon subkey and manually add a ReportControllerMissing REG_SZ data item. To enable the function, set the data item's value to TRUE. This value is case sensitive and you must enter it in uppercase letters.

To inform the current user that Win2K can't find a DC during logon, go to the HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Winlogon subkey and change the value of the ReportDC REG_DWORD data item to 1. (A value of 1 displays the error message; a value of 0 suppresses the error message.) Usually, adding the ReportControllerMissing data item automatically adds the ReportDC data item (although it doesn't automatically change the value to 1), but if you can't find the ReportDC data item, you'll need to add it manually.

The result of these two user-based registry entries is the following message: Windows cannot connect to a server to confirm your logon settings. You have been logged on using previously stored account information. If you changed your account information since you last logged on to this computer, those changes will not be reflected in this session.

I read an article that said the paging file contains sensitive data such as passwords, which intruders can access by booting the computer from a 3.5" disk. How can I delete this data from the paging file when the computer shuts down so that the information isn't available to an intruder?

I've seen those articles, and I've also seen articles by security experts who claim that removing data from the paging file isn't important because the problem you describe almost never arises. Physically securing the computer is a better (and easier) security method. However, if you want to delete the inactive pages, a registry entry accomplishes the task for both Windows 2000 and Windows NT computers. Be aware that you can't delete all the data in the paging file because the shutdown process uses the data in some pages; therefore, those pages are active during shutdown. However, you can zero-fill inactive pages, which include the information you're worried about. Zero filling overwrites any existing data in those pages—with zeros, of course.

To zero-fill inactive pages in the paging file during shutdown, use a registry editor to go to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager subkey. Add a new ClearPageFileAtShutdown REG_DWORD data item, and set the value to 1. (Incidentally, this change slows the shutdown process.) To stop using this function, either change the value of ClearPageFileAtShutdown to 0 or delete the item from the registry subkey.

When I use regedit.exe in Windows 2000, it opens to the key I worked on previously. How do I stop this silly behavior?

This new Win2K "feature" occurs because regedit stores your most recent action. So, to prevent this behavior, you need to delete the stored information, then stop any subsequent efforts to save the information. Because preventing these writes involves permissions and because regedit has no security functions, you must use regedt32 to perform this task.

Open regedt32 and go to the HKEY_CURRENT_USER\Software\Microsoft\Windows\ CurrentVersion\Applets\Regedit subkey. (The Regedit subkey exists only if you've already run regedit on the computer. If you can't find the Regedit subkey, don't manually add it to the registry. Instead, open and close regedit to create the subkey.) Open the LastKey data item and delete the value, creating an empty string. Click OK to close the String Editor. To prevent regedit from replacing the empty string with new data, select the Regedit subkey again and choose Security, Permissions from the menu bar. In the Permissions for Regedit dialog box, click Advanced to open the Access Control Settings dialog box. Select your user account, then click View/Edit.

For the Set Value item, select the Deny check box and click OK to return to the Access Control Settings dialog box. As Figure 1 shows, a new item of the type Deny now exists for your user account. Select that item and click View/Edit, then select the option at the bottom of the dialog box to apply the permissions only within this container. This option limits the Set Value denial to the Regedit subkey and prevents the denial from affecting the Favorites subkey—a useful key that you want regedit to write data to when you save oft-visited registry keys in your Regedit Favorites list. (The Favorites menu item is new in Win2K, and the Favorites subkey appears in the registry only after you use this new feature.)