PRB: ODBC User DSNs Not Visible on Terminal Server

ODBC User Data Source Names (DSNs) created for a user account on Windows 2000 Terminal Server in Application Server mode may not be seen. This can result in the user being prompted with a dialog box to create a DSN each time that they establish a session on the Terminal Server, or in other errors caused by a missing DSN.

When an application is installed on a Terminal Server in Change User Install mode, Windows places the registry keys for created ODBC User DSNs in the Terminal Server software cache. When a user with User DSNs defined tries to log on to the Terminal Server, the system first looks in the Terminal Server software cache to find the keys to use for HKEY_CURRENT_USER hive. If ODBC data sources have been created in "install" mode, those entries in the software cache will consistently take effect when the user logs in to the Terminal Server and other DSNs will not be seen.

Manually remove the entries from the Terminal Server software cache. The location of the software cache is as follows: The key to be removed is "ODBC Data Sources".

Note that any DSNs specified under this key will no longer be seen to users, but any DSNs that the user has created will now be seen. You may need to re-create the DSNs you removed from the Terminal Server cache at a system or user level.

This behavior is by design.

An ODBC User DSN is a collection of registry keys stored under the HKEY_CURRENT_USER hive when a given user is logged on. During the logon process on a computer without Terminal Server, Windows loads the values into the HKEY_CURRENT_USER hive from the user's profile path.

With Terminal Services, however, this process becomes more complicated. Terminal Server allows applications to be installed in Change User Install mode. In this mode, registry keys that normally would be written to a user's "HKEY_CURRENT_USER" hive are instead written to the Terminal Server software cache registry hive. When a user logs on to a Terminal Server, Windows first looks in this hive to see if the user's profile keys are located there. If they are, Windows copies those keys to HKEY_CURRENT_USER. If they are not there, Windows populates HKEY_CURRENT_USER with the values from the user's profile path, as in the non-Terminal Server scenario.