What is the difference between running a Windows service vs. running through shell?
- by Zack
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) I set the service up log in as my user and had the same issue (I confirmed via Task Manager that the process running user was, in fact, me).
It just doesn't make sense to me why a service, which should be running as my user, appears to still be operating in a different security context or environment.
Also, if it's important, the Timberline database is referenced by computer name on the network ("\\timberline-server\Timberline Office\Accounts\AT" or something to that effect)
I also realized that, as Joel pointed out, the server DOES have a mapped drive ("Y:" which is mapped to "\\timberline-server\Timberline Office")
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
Since I'm not allowed to answer this question yet, I'll post the solution that I arrived on:
As Joel Coel mentioned, there actually was a mapped drive scenario. I
didn't realize this because the DSN specified a path using UNC.
However, it seems as though the actual Timberline Driver referred to a
mapped drive.
Since services don't start with the mapped drive, I was forced to add
the drive mapping code into my service. Since it was written in
python, I used code from a Stackoverflow
answer that was able to
map the drive on the fly.
