У меня есть исполняемый файл .NET (который я создал), который использует MicrosoftИнтерфейсы службы Active Directory(через System.DirectoryServices.AccountManagement) для выполнения запросов LDAP. Внутри ADSI,он загружает схему Active Directory и сохраняет ее локально. Предполагается, что эта схема будет храниться в папке %LOCALAPPDATA%\Microsoft\Windows\SchCache\.
Когда я планирую этот исполняемый файл вДиспетчер задачв Windows Server 2012 R2 и настройте его на запуск от имени «UserA»даже если этот пользователь не вошел в систему, программа запускается, но она пытается записать указанный выше файл кэша впапка буквально названа%LOCALAPPDATA%\Microsoft\Windows\SchCache\в пределахначинатьпапка запланированной задачи (которая намеренно установлена в папку моего исполняемого файла). Другими словами, он пишет во что-то вроде C:\MyApp\%LOCALAPPDATA%\Microsoft\Windows\SchCache\. Мне пришлось предоставить UserA явные права на запись в эту папку, чтобы программа могла работать должным образом.
Я наблюдал за процессом задачи с помощью Process Monitor, и он немедленно отправляется в эту папку. Это не так, как будто он сначала пытается что-то сделать, C:\Users\но терпит неудачу.
Когда я вхожу на сервер как мой собственный пользователь и вручную запускаю исполняемый файл как UserA, используяЗапустить как другой пользователь, исполняемый файл запускается и успешно записывает файл кэша в C:\Users\UserA\AppData\Local\Microsoft\Windows\SchCache\.
Почему это происходит с Task Scheduler и что я могу сделать, чтобы исправить это? Я предполагаю, что это может быть связано с Task Scheduler, который выполняет программу в контексте UserA, но не инициализируется %LOCALAPPDATA%как переменная окружения. По прихоти я попробовал установитьЗапустить с наивысшими привилегиямипо заданию, но это не изменило результат.
решение1
Это ошибка в Windows Server 2012 R2 и 8.1; Microsoft задокументировала ее вКБ 2968540.
Проблема была устранена и исправлена.КБ 3133689доступен. Это исправление решает проблему.
Запланированные задачи, запускаемые с помощью UBPM, не имеют достаточных переменных среды, таких как APPDATA, USERPROFILE или TEMP, при запуске соответствующего процесса.
решение2
Я считаю, что в запланированных задачах Windows 7/2012 есть ошибка, из-за которой они не видят правильные переменные среды для пользователя, от имени которого они запущены:
https://stackoverflow.com/questions/32589381/
Чтобы подтвердить, что это происходит, вы можете запустить SET>test.txtпакетный файл в запланированной задаче в том же пользовательском контексте. Когда я пробую это, это происходитнетпоказать правильный, полный набор переменных среды для указанного пользователя; т. е. не тот же набор, который вы видите, если запускаете ту же команду (или пакетный файл), когда фактически вошли в систему как этот пользователь. (Еще более запутанно то, что это зависит от того, вошел ли пользователь в систему в данный момент или нет, когда выполняется запланированная задача; если он вошел в систему, то задачаделаетсм. правильные переменные.)
Я думаю, что такое поведение не документировано и не предусмотрено, и является ошибкой в способе обработки запланированных задач Windows Server 2012 (может быть, только R2?).
Примечание.Это применимо PATHи к переменной, поэтому запланированные задачи могут видеть только исполняемые файлы, которые находятся напо умолчаниюpath, или в текущем каталоге, или с полностью указанным путем. Вызов чего-либо, что находится на указанном пути пользователя, но не на пути по умолчанию, приведет к трудноотлаживаемой (поскольку это работает в тестировании!) ошибке.
решение3
Это следствие того, как Windows обрабатывает учетные записи пользователей. Когда учетная запись пользователя не вошла в систему, ее куст реестра пользователя — ключ, HKEY_USERSкоторый обычно отображается как HKEY_CURRENT_USER— не монтируется. Этот куст (который хранится в файле в профиле каждого пользователя, называемом NTUSER.DAT) хранит почти все данные для каждого пользователя, включая переменные среды для каждого пользователя. В Windows также есть системные переменные среды — некоторые переменные, такие как PATH, присутствуют в обоих местах и объединяются — поэтому они будут отображаться, даже если куст реестра пользователя не смонтирован. Однако ни один из пользовательских не будет.
Я не знаю, обрабатывал ли планировщик заданий этот сценарий по-другому в других версиях Windows. Онмогбудьте достаточно умны, чтобы смонтировать куст пользователя перед запуском задачи от имени этого пользователя. В Win7 / 2012R2, по-видимому, это не так.
Чтобы исправить это, вам нужно убедиться, что куст реестра пользователя смонтирован. Самый простой способ сделать это — просто убедиться, что пользователь вошел в систему, поскольку куст вошедшего в систему пользователя всегда смонтирован. Если этого нет, вы можете попробовать смонтировать куст самостоятельно (APIRegLoadKeyно я никогда не пробовал использовать его для этой цели).