October 2005 Reader Challenge

September 2005 Reader Challenge Winners

Congratulations to the winners of our September 2005 Reader Challenge. First prize goes to Brian Frahm of Arizona. He wins a copy of copy of Windows XP Hacks, Second Edition (O’Reilly Publishing). Second prize, a copy of Home Networking for Dummies Third Edition, goes to Virginia McDevitt of California.

October 2005 Reader Challenge

October 2005 Reader Challenge Solve this month's Windows Client challenge, and you might win a prize! Email your solution (don't use an attachment) to [email protected] by October 26, 2005. You must include your full name and street mailing address (without that information, we can't send you a prize if you win, so your answer is eliminated, even if it’s correct). I choose winners at random from the pool of correct entries. I’m a sucker for humor and originality, and a cleverly written correct answer gets an extra chance. Because I receive so many entries each month, I can't reply to respondents, and I never respond to a request for a receipt. Look for the solutions to this month's problem here on October 27, 2005. Incidentally, many IT directors use the Reader Challenge as a trivia game in their IT department and have written to ask me for old Reader Challenge questions (this column has appeared in print and in UPDATE newsletters for many years). I don’t keep them, but you can search the Windowsitpro.com site, which archives columns.

The Challenge

A consultant who specializes in peer-to-peer networks for small businesses called to ask for help solving a puzzle he'd encountered. He explained that he'd switched one of his clients to a domain (to take advantage of client server technology offered by the client's new accounting application). Everything was working well. Last week, he went into the client's office early in the morning to add hardware to the domain controller (DC). He had just finished his work, and was about to restart the DC, when one of the client's employees walked into the office where the DC resides. The employee said, "I'm glad you're here, I can't print." The consultant replied, "You can't print? You mean you can't log on to the network, right?" The employee replied, "Oh, the computer started fine and logged on to the domain fine, and I've been working on documents, but they won't print. I turned on the printer, but Windows displays an error message that it can't access the printer."

The consultant wanted to know how a user could start Windows and join a domain when the DC was down? Can you answer his question?

The Answer

If no DC is available when a user on a Windows 2000 or Windows XP computer attempts to log on to the domain, the user is logged on with credentials that were cached from previous logons.

The user doesn’t see an error message that says the DC couldn’t be found (although there's usually a substantial delay in completing the logon process, which should provide a hint that something is wrong).

Problems crop up as the user attempts to get work done over the network, such as printing to a network printer or accessing a mapped drive. Those actions require real-time services from a DC.

If you're troubleshooting this problem from the workstation and you suspect that a missing DC might be the problem, open a command prompt and enter

set
Look for the entry LOGONSERVER=. The text on the right side of the equal sign should read \\DCName. If, instead, it has the name of the local computer, the DC wasn't available during logon, and the user is on the domain with cached credentials.

The solution is to reboot (after you make sure the DC is running and the network connection is working).

You have a couple of ways to ameliorate this occasional situation:

You can have Windows issue a message to the user that explains that a DC wasn't found, and the system is using cached credentials. However, few users understand what that means, so you'll have to send out a memo.

You can prevent the use of cached credentials, which means that users won't be able to log on until the DC is up and running. Send out a memo on this one, too, to avoid a lot of phone calls to the Help desk.

To force Windows to send a message to the user, you must make two changes to the registry. The first change turns on the “inform the user” feature; the second change enables this feature for the logging-on user.

To turn on the feature, go to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon registry subkey. Create a REG_SZ data item named ReportControllerMissing, with the data TRUE (must be all caps).

To enable the feature for the logging-on user, go to the HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon subkey. Create a REG_DWORD data item named ReportDC, and enter a data value of 1. (A value of 1 forces the message to display; a value of 0 suppresses the message.)

Usually, adding the ReportControllerMissing data item automatically adds the ReportDC data item, although it defaults to a value of 0. If the data item isn’t present, however, you must add it manually.

To prevent a computer from caching user logon information (so that if a DC isn’t found, the user cannot log on to the domain), go to HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon. Open the data item named CachedLogonsCount and change the value to 0.

If no DC is available, the system displays the message “The system cannot log you on now because the domain <DomainName> is not available”. You can instruct users to log on to the local machine if they have software installed that can be used locally. When the DC is available, they can restart Windows.

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish