I am trying to troubleshoot an issue on a Windows 2008 server where running attempting to connect to a "Timberline Data Source" ODBC driver crashes if the call is in a "service" context, but succeeds if the call is initiated manually in a Remote Desktop session.
I have set the service to run as my user.
I'm wondering if, all else being equal (user, machine, etc), are there any fundamental security/environment differences between running a process as a service vs manually?
— Implementation Details —
In case it is helpful for anyone, I had a system that started as an attempt to connect to a Timberline Database using ODBC and a Python CGI script called via IIS 7. The script itself works fine, however, as soon as I attempt to perform the ODBC connect function, the script crashes without throwing an exception. The script was able to connect fine when executed via command line.
The same thing happened when using a C#/.net service, attempting to run via Apache, Windows Scheduler or even a 3rd party scheduling tool.
With the last option (the 3rd party scheduling tool, pycron) The service is configured to log in as my domain user and had the same issue (I confirmed via Task Manager that the process running user was, in fact, me).
Also, if it's important, the Timberline DSN is configured to locate the database via UNC ("\\timberline-server\Timberline Office\Accounts\AT" or something to that effect)
The DSN is set up at the "System DSN" level which, according to the ODBC Administration Tool, means that the DSN is available to users and services
I also realized that, as Joel pointed out, the server DOES have a mapped drive ("Y:" which is mapped to "\\timberline-server\Timberline Office")
Best Answer
It looks like the database is on the share. By default service is running under System on Network account and most likely does not have access to share where database is. When you run it under your account, script can access database because you can access windows share.