Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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")

share|improve this question
    
Does it depend on any mapped drives or other things that do not run until you log in? –  Joel Coel Sep 6 '12 at 17:48
    
Not that I am aware of. The database is on a network computer (not referenced via a mapped drive) and the ODBC DSN is listed under "System DSN" so I'm assuming it's persistent. Is there a way to tell using procmon or anything like that? –  zashu Sep 6 '12 at 17:59
    
ACTUALLY: It might. While the DSN refers directly to the network machine location ("\\timberline-server\Timberline Office\Accounts\AT") I am noticing that I do have "Timberline (\\timberline-server) (Y:)" showing in "My Computer". I'm not super familiar with network drives, unfortunately, but does this sound problematic? –  zashu Sep 6 '12 at 18:07

3 Answers 3

up vote 2 down vote accepted

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.

share|improve this answer
    
That was one of the things that I tried. However, I can get the service to log in as my user (and the service process shows as running as my user). In addition, I was able to test file permissions by attempting to open a file. While an important troubleshooting step, it isn't my issue. –  zashu Sep 6 '12 at 19:18
    
From post here I see that DSN is per user. –  Serhiy Sep 6 '12 at 19:45
    
Also a good point, but the DSN is configured at System level which should keep it safe for services (if the UI is to be trusted). Honestly, I think it was related to the mapped drive thing –  zashu Sep 6 '12 at 20:32
    
Mapped drives are available only thru interactive login. Hence, services must use UNC. –  Alfabravo Sep 6 '12 at 21:30

You'll want to set the service to run with a service account (i.e. create a user for this purpose called something like YOURDOMAIN\svc_timberline), then grant that service account rights to the folder containing the database.

It should work after that.

share|improve this answer

As some users mentioned, mapped drives are only set up through an interactive login session, i. e., not available in background services. After looking into this, I realized that, while my DSN referred to a network location via UNC, the actual ODBC connector was designed to refer to a mapped drive.

Since it wasn't possible for me to alter the driver configuration in this instance, I was able to update my service to map the drive on the fly. Thus, when my python script was called, it would map the drive prior to calling ODBC connect which, in turn, resolved the crash.

If anyone is having a similar problem, I used these python functions to map the drive in my script.

Thanks for all of the help!

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.