Kerberos and Mapped Drives
In a Win2K domain, the Kerberos authentication functions determine whether you can access shares. Kerberos relies on the Windows Time Service during authentication, and if the local computer's clock doesn't show the same time (within a certain tolerance) as the remote computer's clock, Kerberos won't let you access shares on the remote computer.
The default behavior of a Win2K computer in a Win2K domain is to sync its time with the DC's time every 45 minutes. When the clock times match, the synchronization interval is incrementally extended until it reaches 8 hours or until the clocks don't match. (For details about how Windows Time Service works, see Windows 2000 Ready, "Windows Time Synchronization Service," http://www.winnetmag.com, InstantDoc ID 8383.) If you've changed that paradigm, if a computer's clock is losing time because of semiconductor problems, or if the DC's time is wrong, Kerberos settings cause mapped drives to be disconnected.
I learned this accidentally while writing a book about accounting software. Every transaction window in accounting software has a date, so to make sure the book's figures would match the publication date, I set the date on the computer that was running the accounting software to the next year. I saved the figure files to a mapped drive on the computer on which I do my writing. When I finished writing the paragraphs and returned to the computer that was running the accounting software, I found that it had reset its date to the current year. I remembered that the workstation was syncing its time to the DC. The solution, I decided, was to change the system time, then grab the figure before the system next checked its time against the DC's time. However, when I attempted to save the figure file to the mapped drive, I received an error message about security and learned that the mapped drive was disconnected. I couldn't reconnect the drive until I fixed the time. Finally, I logged on to the local computer instead of the domain, saved the figure files locally, logged on to the domain again, then used Windows Explorer to transfer the files to the mapped drive.
A Mapped-Drive Bug
When you map a drive from the GUI, Windows opens a window for the new mapped share as soon as you click Finish. Thereafter, whenever you map that same drive letter, even from the command line, Windows opens a window and displays the contents of the shared resource. If you subsequently use a batch file to map the drive, the appearance of the window interrupts processing (defeating the purpose of an "unattended" job).
To prevent this behavior, Microsoft issued a downloadable fix, which you can obtain by calling Microsoft support. (If you report this problem, you won't be charged for the call.) The support technician will direct you to the proper FTP download of a replacement for the shell32.dll file. The Microsoft article "Mapping a Drive from a Command Prompt May Open a New Windows Explorer Window" (http://support.microsoft.com/?kbid=290703) discusses this problem and suggests a registry fix. However, the suggested registry modification doesn't work.
One way to prevent this behavior is to use only the Net Use command, never the GUI, to map drives. Alternatively, if you use the GUI, press and hold Shift when you click Finish and continue to hold down Shift for at least 10 seconds.
A Powerful Combination
Mapped drives combine computing power with ease of use—a potent combination. Use batch files and logon scripts to share this often overlooked power tool with your users—or teach them to map their own drives—and you as well as they will reap the rewards.
End of Article
Prev. page
1
2
3
[4]
next page -->
