We had a similar problem but found that the client was mapping the F: drive to their home folders which was available on their workstations but logging into the terminal server, the F: drive was already allocated to the CD-ROM drive.
Ensure that if you do folder redirection or profiles that the drive letter is not already taken by a physical disk or rom drive.
(MsGina event 1010 errors) for an article about this problem (and how it was fixed).
The data portion of the event contains the error code encountered during the attempt to map the drive. This can be an important clue as to what went wrong. For example, if the data contains 55 00 00 00, this corresponds to Error code 0x55
or Error code 85
(0x55 in hex is 85 decimal) and that means "The local device name is already in use". This error indicates that the drive letter that was attempted to be mapped was already in use.
Data: b3 04 00 00 - corresponds to Error code 0x4b3
or Error code 1203
in decimal meaning "No network provider accepted the given network path." - this may indicate that the path specified for the mapped drive is invalid.
I also had this issue and managed to resolve it. My environment consisted of a Terminal Server TS1, a Domain Controller and an Exchange/File Server SBS1. One user (out of several tens), after changing his password and logging in on the SBS1 server could not access any resources on SBS1, be that Exchange or files/folders. The user received an authentication question were no passwords were accepted. To fix the problem I opened the password applet from Control Panel -> User Accounts -> Stored User Names and Passwords and I removed the entry for SBS1.
An old ASP web admin application was used for user admin, which made use of the wts_Config.dll. When creating new users the TerminalServicesHomeDrive value was incorrectly set to T instead of T: . A script was created to query all AD user accounts and amend the value if incorrect. After this, we no longer receive this error.
This problem occured after installing Windows 2003 SP1 (terminal server). Users were not connected to their home drive (H:) and this event was logged. In the user profile, the home folder path pointed to a CNAME dns record instead of the real server. After changing this, the event was gone and the user could connect to its own H: drive during logon.