SQL access problems over Terminal Services

[Craig Pilkington]

Ok, here we go >>>

We have a strange problem - We have 2 Servers, Server1 is
a Terminal Server and Server 2 is a SQL server. We also
have a piece of VB

software that derives information from our SQL databases.
This is how it is all set-up and how it SHOULD work >

- Terminal Services clients connect to the Terminal Server
- The Terminal Server has VB Software installed along with
the appropriate ODBC/DSN links that link on to Server2
(SQL Server)
- The users can then access the database via the software

We also have users connecting via 'thick client' ie NOT
via Terminal Services client < Now these users can connect
with no problems whatsoever.

However the users connecting via Terminal Services CANNOT
access properly and we get access denied error messages
etc when trying to

use the application. The ONLY thing that lets the
Terminal Services users access the system is if I add
those particular users to the Domain

Admins group via AD Users & Computers - obviously this is
NOT good. does 'anyone' know of 'anything' I can do to
diagnose this problem ?... is

this a 'known' type of issue when trying to access SQL
over terminal services and are there any simple workarounds

I installed the VB application on the Terminal Server
in 'Application Install' mode on the Terminal Server and
then switched back to 'Apllication

Execute' mode...so I don't think this could be the problem

ANY help at all would be fantastic

many many thanks in advance guys

cheers - Craig

 

[Vera Noest [MVP]]

This is not a known bug and should work (we have exactly the same
setup without any problem).
I would have a look at your ODBC link first, possibly use the
tracing option there. If that doesn't help, I would download
FileMon and RegMon from http://www.sysinternals.com/.
Run them as administrator, start a TS session as a normal user and
try to run the application.

FileMon and RegMon will show you all "access denied" errors
that occur, so that you can give your users the necessary
permissions on a file-to file or Registry subkey basis.

 

[TomCast]

Just ran into this same problem.

The permissions for SQL server for the database needed to reflect the users intended.