Я пытаюсь устранить проблему на сервере Windows 2008, при котором выполняется попытка подключиться к драйверу ODBC «Источник данных Timberline» сбой, если вызов находится в контексте «службы», но завершается успешно, если вызов инициируется вручную на удаленном рабочем столе. сеанс.
Я настроил службу для запуска от имени моего пользователя.
Мне интересно, если при прочих равных (пользователь, машина и т. Д.) есть ли какие-либо фундаментальные различия в безопасности / среде между запуском процесса как службы и вручную?
--- Детали реализации ---
В случае, если это будет полезно для кого-то, у меня была система, которая начиналась как попытка подключиться к базе данных Timberline с использованием ODBC и скрипта Python CGI, вызываемого через IIS 7. Сам скрипт работает нормально, однако, как только я пытаюсь выполнить при использовании функции подключения ODBC сценарий аварийно завершает работу, не вызывая исключения. Скрипт смог нормально подключиться при выполнении через командную строку.
То же самое произошло при использовании службы C # /. Net при попытке запуска через Apache, Windows Scheduler или даже сторонний инструмент планирования.
С последним вариантом (сторонний инструмент планирования, pycron) Служба настроен для входа в систему как пользователь моего домена и имел ту же проблему (я подтвердил через диспетчер задач, что на самом деле пользователем процесса был я).
Кроме того, если это важно, Timberline DSN настроен для поиска базы данных через UNC ("\\ timberline-server \ Timberline Office \ Accounts \ AT" или что-то в этом роде)
DSN настроен на Уровень «Системный DSN» что, согласно ODBC Administration Tool, означает, что DSN доступен пользователям и службам.
Я также понял, что, как указал Джоэл, на сервере ДЕЙСТВИТЕЛЬНО есть подключенный диск («Y:», который сопоставлен с «\\ timberline-server \ Timberline Office»)
Похоже, база данных находится на общем ресурсе. По умолчанию служба работает под учетной записью Система в сети и, скорее всего, не имеет доступа к общему ресурсу, где находится база данных. Когда вы запускаете его под своей учетной записью, скрипт может получить доступ к базе данных, потому что вы можете получить доступ к общему ресурсу Windows.
Как упоминали некоторые пользователи, подключенные диски настраиваются только через интерактивный сеанс входа в систему, я. е., недоступно в фоновых службах. Изучив это, я понял, что, хотя мой DSN ссылался на сетевое местоположение через UNC, фактический разъем ODBC был разработан для обозначения подключенного диска.
Поскольку в этом случае у меня не было возможности изменить конфигурацию драйвера, я смог обновить свой сервис, чтобы подключить диск на лету. Таким образом, когда мой скрипт python был вызван, он сопоставил диск до вызова ODBC connect, что, в свою очередь, разрешило сбой.
Если у кого-то есть похожая проблема, я использовал эти функции Python для отображения диска в моем скрипте.
Спасибо за помощь!
Вы хотите настроить службу для запуска с учетной записью службы (т.е. создать пользователя для этой цели, называемого что-то вроде YOURDOMAIN \ svc_timberline), а затем предоставить этой учетной записи службы права на папку, содержащую базу данных.
После этого он должен работать.