OK, this one had me puzzled for an hour or two. My main test box having failed, I had taken one of the older machines hanging around my office and given it a once-over; some extra RAM, a bigger hard disk drive, that sort of thing. I noticed the motherboard battery had died, but figured I could live without it. What the hey; the machine stays connected to the mains most of the time anyway.
So I go to install Windows 7 on the box, using our automated install system on my USB stick. This is a Windows PE image which runs Windows Setup in unattended mode over the network. It also includes a bit of in-house code so that you can provide an administrator password to join the machine to the domain in advance; once this password has been accepted, everything else happens automatically. A few hours later the machine will be ready to use, software and all. This sort of streamlining may seem unnecessary, but it does make life easier.
Except that this time the domain controller wouldn’t accept my password. Typed it in again; no luck. After trying once more, well, okay, several times more, and logging in on another machine to make sure I hadn’t gotten confused about which password went with which account, I realised there really was something wrong.
So I try it on another machine, and it works perfectly. I try booting the first machine from a copy on CD instead of the one on my USB stick; no difference. Bringing up a command line window allows me to explicitly attempt to connect to the domain controllers as well as other network servers, with both my own account and a test account with a simpler password – just in case!
The results were puzzling to say the least. Error code 86 – the network password is not correct – for any user account but only from that one machine and only when connecting to a domain controller. The file server, by comparison, was perfectly happy to accept the supposedly “incorrect” passwords. In case there was something wrong with the Windows PE image, I repeated the experiment using the standard Windows 7 install DVD, but this exhibited the same problem. Swapping the keyboards and network cables between the machines was a long shot at best, this didn’t pan out either. The event log on the domain controller showed the logon failures but provided no additional information. For some reason, the problem didn’t occur when booted to a copy of Windows PE 2 (which is based on Vista rather than Windows 7) but this didn’t help me much.
Eventually it dawned on me that the flat motherboard battery meant that the on-board clock would have been reset; the computer thought the year was 2004. Mismatched clocks have been known to cause authentication problems, and sure enough, once I had corrected the date and time via the BIOS the domain controller accepted my password and the automated installer set to work.
I’m not sure what the moral of this story is exactly. I suppose I should have remembered the failed battery as soon as the machine started behaving oddly, and stopped to think about whether there could be a connection. Anyway, I’ve tagged this as a bug, not because the authentication should necessarily have worked, but because the error code (or at least the event log!) should have indicated the actual problem instead of insisting that the password was wrong.