So, today I just want to bring to attention a fairly obscure, but, interesting problem that I ran into recently.
I had a client that had several desktop and laptops joined to a Windows Server 2003 domain. All of the computers were running Windows XP Sp2 and for the most part things were fairly smooth. However, one user, started experiencing intermittent failures where his mapped drives were not being setup. Needless to say, he was becoming quite frustrated.
All of the usual troubleshooting of the login scripts was performed, and at one point, some of my colleagues even re-wrote the login scripts from scratch. All of these could be manually executed under our credentials and the drives were successfully mapped, but would mostly fail when ran under the user's own login credentials. It was really odd.
The key point above, however, is that the script would "mostly fail" when run under that users credentials. Soon, it became apparent that anything that was supposed to be mapped from drives located on one particular server wouldn't work and would error out with "System 53" messages etc. Really odd indeed.
We started suspect larger issues were at play and that the domain controllers were not properly replicating. But this begged the question "Why only this one particular user?" Slow link problems might be stopping the login script from running then, we mused...but, on a gigabit connection? Nope, this doesn't make sense. The culprit?...something very obscure and virtually unthought of when dealing with computers in a domain.
What had happened was that the user had cached a blank password for a valid domain user account on his local laptop. The difference between this password and the valid password on the domain controller was causing "Kerebros errors" to appear in the event viewer but yet, would still allow him to log on and use the computer as normal. However, with this wrong password stored, the computer was essentially unable to connect to the domain controller until a valid password was supplied which, of course, would happen long after any login scripts (located on the domain controller he couldn't connect to) would have run and also explained why drives on other servers could be successfully mapped when the login script was manually run on the local machine.
So, where are these passwords stored? On a windows XP machine simply go to the control panel and click on user accounts, then click on advanced, and click on manage passwords. It is in this box where you can cache passwords for logging on to IT resources. Obviously, this feature might be really handy for home computer systems, but can wreak havoc on a machine joined to the domain.
I was thrilled that I had solved the problem and now I am equally excited to share this unusual scenario with my readers. If I can save any of you even 5 minutes in troubleshooting a strange issue like this - I am satisfied.