У меня есть исполняемый файл, который запускается службой Windows, эта программа будет запускаться на компьютере клиента, и для выполнения определенной задачи потребуется подключение к удаленному общему ресурсу. Эта доля указывается клиентом через пользовательский интерфейс, поэтому мы не знаем об этом заранее, что означает, что она не может быть «жестко запрограммирована», или доля заранее назначена.

Ранее мы требовали, чтобы клиент входил в систему на своем компьютере и запускал исполняемый файл при входе в систему, но мы всегда хотели, чтобы наша программа работала внутри службы и не требовала входа в систему, в первую очередь, чтобы сделать ее проще для клиента. и предотвратить случайные выходы из системы, закрывающие наше программное обеспечение. Таким образом, это также означает, что мы не знаем, какие локальные учетные записи пользователей существуют на компьютере клиента, поэтому мы должны запустить службу с использованием локальной системной учетной записи.

Теперь у нас есть, как упоминалось выше, сервис-оболочка для запуска исполняемого файла и выполнения различных задач. Похоже, что это работает нормально в большинстве случаев и обеспечивает доступ к базовой сети - цель нашего программного обеспечения в основном заключается в захвате пакетов и т. Д.

Однако, когда программное обеспечение пытается подключиться к общему ресурсу Windows (имя UNC), оно не может подключиться. Тогда как, если исполняемый файл был запущен вручную, он подключается нормально.

Похоже, что предложения, которые я обычно видел для решения подобных проблем, используют учетную запись пользователя, поскольку системная учетная запись не может получить доступ к сетевым ресурсам, но в нашем случае это невозможно. Есть ли другой способ заставить это работать?

Изменить: я забыл упомянуть, что это приложение может (и чаще всего будет) работать на Win2K не XP, и я думаю, что я прав, говоря, что учетная запись локальной сети недоступна до XP?