Estou tentando solucionar um problema em um servidor Windows 2008 em que a tentativa de se conectar a um driver ODBC "Fonte de Dados Timberline" falha se a chamada estiver em um contexto de "serviço", mas será bem-sucedida se a chamada for iniciada manualmente uma sessão de área de trabalho remota.
Eu configurei o serviço para ser executado como meu usuário.
Gostaria de saber se, sendo o restante igual (usuário, máquina, etc), existem diferenças fundamentais de segurança / ambiente entre a execução de um processo como um serviço vs manualmente?
--- Detalhes da implementação ---
Caso seja útil para qualquer pessoa, eu tive um sistema que começou como uma tentativa de conexão a um banco de dados Timberline usando ODBC e um script CGI chamado Python via IIS 7. O script em si funciona bem, no entanto, assim que eu tentativa de executar a função de conexão ODBC, o script falha sem gerar uma exceção. O script foi capaz de se conectar bem quando executado via linha de comando.
A mesma coisa aconteceu ao usar um serviço C # / .net, tentando executar via Apache, Windows Scheduler ou até mesmo uma ferramenta de agendamento de terceiros.
Com a última opção (a ferramenta de agendamento de terceiros, pycron) O serviço está configurado para fazer login como meu usuário de domínio e teve o mesmo problema (confirmei através do Gerenciador de Tarefas que o processo executando o usuário foi, na verdade, eu).
Além disso, se for importante, o DSN do Timberline é configurado para localizar o banco de dados via UNC ("\\ timberline-server \ Timberline Office \ Contas \ AT" ou algo parecido)
O DSN está configurado no nível "DSN do Sistema" que, de acordo com a Ferramenta de Administração ODBC, significa que o DSN está disponível para usuários e serviços
Eu também percebi que, como Joel apontou, o servidor tem uma unidade mapeada ("Y:" que é mapeada para "\\ timberline-server \ Timberline Office")
Parece que o banco de dados está no compartilhamento. Por padrão, o serviço está sendo executado na conta do System on Network e, provavelmente, não tem acesso para compartilhar onde o banco de dados está. Quando você o executa na sua conta, o script pode acessar o banco de dados porque você pode acessar o compartilhamento do Windows.
Você desejará configurar o serviço para ser executado com uma conta de serviço (ou seja, criar um usuário para esse fim chamado algo como YOURDOMAIN \ svc_timberline) e conceder direitos de conta de serviço à pasta que contém o banco de dados.
Deve funcionar depois disso.
Como alguns usuários mencionaram, as unidades mapeadas são configuradas somente por meio de uma sessão de login interativa , i. e., não disponível em serviços de segundo plano. Depois de analisar isso, percebi que, enquanto meu DSN se referia a um local de rede via UNC, o conector ODBC real foi projetado para se referir a uma unidade mapeada .
Como não foi possível alterar a configuração do driver nesta instância, consegui atualizar meu serviço para mapear a unidade em tempo real. Assim, quando meu script python era chamado, ele mapeava a unidade antes de chamar a conexão ODBC, o que, por sua vez, resolveu a falha.
Se alguém tiver um problema semelhante, usei essas funções do python para mapear a unidade no meu script. p>
Obrigado por toda a ajuda!