Windowsサービスの実行とシェルを介した実行の違いは何ですか？
「Timberlineデータソース」に接続しようとして実行中のWindows2008サーバーで問題のトラブルシューティングを試みていますODBC呼び出しが「サービス」コンテキストの場合、ドライバーがクラッシュしますが、次の場合は成功します呼び出しは、リモートデスクトップセッションで手動で開始されます。
ユーザーとして実行するようにサービスを設定しました。
他のすべてが等しい場合（ユーザー、マシンなど）、プロセスをサービスとして実行する場合と手動で実行する場合の間に基本的なセキュリティ/環境の違いはありますか？
---実装の詳細---
誰かに役立つ場合に備えて、ODBCおよびPython CGIスクリプトを介して呼び出されたTimberlineデータベースに接続する試みとして開始されたシステムがありましたIIS 7.スクリプト自体は正常に機能しますが、ODBC接続機能を実行しようとすると、例外をスローせずにスクリプトがクラッシュします。スクリプトは、コマンドラインを介して実行すると正常に接続できました。
同じことが、C＃/。netサービスを使用して、Apache、Windowsスケジューラ、またはサードパーティのスケジューリングツールを介して実行しようとしたときにも発生しました。
最後のオプション（サードパーティのスケジューリングツール、pycron）を使用すると、サービスはドメインユーザーとしてログインするように構成され、同じ問題が発生しました（タスクマネージャーを介してプロセスが確認されました）実行中のユーザーは、実際には私でした）。
また、重要な場合、Timberline DSNは、UNC（ "\\ timberline-server\Timberline Office\Accounts\AT"など）を介してデータベースを検索するように構成されています。
DSNは "システムDSN"レベル でセットアップされます。これは、ODBC管理ツールによると、DSNがユーザーとサービスで利用可能であることを意味します。
Joelが指摘したように、サーバーにはマップされたドライブ（ "\\ timberline-server\Timberline Office"にマップされている "Y："）があることにも気づきました。
データベースが共有されているようです。デフォルトでは、サービスはSystem on Networkアカウントで実行されており、データベースがある場所を共有するためのアクセス権がない可能性があります。アカウントで実行すると、Windows共有にアクセスできるため、スクリプトはデータベースにアクセスできます。
一部のユーザーが言及したように、 マップされたドライブは対話型ログインセッションを介してのみセットアップされます 、i。 e。、バックグラウンドサービスでは利用できません。これを調べた後、DSNがUNCを介してネットワークの場所を参照しているのに対し、実際のODBCコネクタはマップされたドライブを参照するように設計されていることに気付きました。
この場合、ドライバー構成を変更することはできなかったため、サービスを更新して、ドライブをオンザフライでマップすることができました。したがって、my pythonスクリプトが呼び出されると、ODBC connectを呼び出す前にドライブがマップされ、クラッシュが解決されました。
誰かが同様の問題を抱えている場合、私は これらのpython関数 を使用してスクリプトでドライブをマップしました。
すべての助けをありがとう！
サービスアカウントで実行するようにサービスを設定し（つまり、YOURDOMAIN\svc_timberlineのようなこの目的のためにユーザーを作成し）、データベースを含むフォルダーにそのサービスアカウントの権限を付与します。
その後は動作するはずです。