Назад | Перейти на главную страницу

Учетные данные учетной записи домена не позволяют запускать запланированные задачи

У меня есть 2 сервера Windows 2000 в домене «DC», которые запускают множество запланированных задач Windows под учетной записью «DC \ Task-User». Эти задачи успешно выполняются и успешно выполняются последние пару лет без каких-либо изменений учетной записи / пароля.

Вчера задачи перешли в статус «Не удалось запустить». У меня есть учетная запись администратора, и я мог запускать эти задачи с моими учетными данными. Сегодня я снова запустил задачи под учетной записью DC \ Task-User, и, похоже, они работают нормально, без каких-либо проблем.

Так было и раньше. Я не занимаюсь сетями, поэтому не очень разбираюсь в основной проблеме. Связано ли это с аутентификацией учетной записи контроллера домена?

Любые указатели подойдут!

Начиная с Server 2008, иногда вам необходимо войти в учетную запись svc, чтобы сначала создать профиль. Проверьте журнал событий и посмотрите, есть ли событие, связанное с входом в вашу учетную запись svc с временным профилем. ЕСЛИ это так, войдите в систему с учетной записью svc, и все будет в порядке.

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

Это действительно похоже на то, что учетная запись не может быть аутентифицирована по какой-то причине. Журналы событий безопасности контроллеров домена предоставят вам дополнительную информацию. Кроме того, журнал системных событий локального сервера мощь даю подсказку, но я бы сделал ставку на DC. Единственная проблема здесь заключается в том, что вам необходимо проверить все журналы контроллеров домена. Однако, если вы знаете, в какую дату / время не удалось выполнить задание, это не должно быть слишком сложно диагностировать.

Последняя мысль: ваш рядовой сервер показывает какие-либо признаки ухода часов. Синхронизирован ли он с контроллерами домена. Причина вопроса заключается в том, что Kerberos, основной механизм аутентификации, полагается на согласованное время между клиентами / рядовыми серверами и контроллерами домена. Насчет Windows 2000 Server не уверен, но на Win2k3 он был макс. По умолчанию 5 минут.

В Win2k3 и выше проблемы с часами будут видны в журнале системных событий с источником (я думаю) W32Time.