Наличие Windows Server 2016 (размещенного в Amazon AWS EC2), который успешно работает в течение многих лет.
С какого-то месяца я обнаружил, что запланированные задачи (например, задача, настроенная для ежедневного запуска) не выполняются. Нет сообщений об ошибках в истории задач. Нет записи в журнале событий. Ничего такого.
Задачи просто не запускаются, а в столбце «Время следующего выполнения» стоит дата в будущем, например. завтра. При повторном просмотре завтра та же картина: не выполнялись никакие задачи, «Следующее время выполнения» снова указывает на будущее.
Вот еще один пример того, как выглядят шансы в моем системном времени:
Выше на снимке экрана Центра обновления Windows показано, что обновление SQL Server, которое я установил 5-го числа февраль 2022 на самом деле ошибочно отображается как установленный на 5-м Маршировать 2022. Один месяц в будущем.
Я только что назвал это в командной строке:
C:\>w32tm/запрос/статус
Который напечатал этот результат:
Индикатор скачка: 0 (без предупреждения)
Слой: 4 (вторичная ссылка - синхронизировано (S)NTP)
Точность: -6 (15,625 мс на тик)
Корневая задержка: 0,0096024 с
Корневая дисперсия: 0,0493815 с
ReferenceId: 0x28779426 (исходный IP-адрес: 40.119.148.38)
Время последней успешной синхронизации: 08.02.2022 08:41:13
Источник: time.windows.com, 0x8
Интервал опроса: 10 (1024 с)
Ничего подозрительного на меня не смотрит.
Я также проверил на вирусы без каких-либо положительных результатов. Я также запустил Инструмент "МРТ" без всяких плюсов.
В последний раз, когда это произошло, может быть, месяц назад, я перезагрузил свою систему, и я думаю, что это (временно) решило проблему. Лишь бы сейчас снова появиться.
Имея несколько других серверов EC2 AWS Windows 2016 и десятки других серверов Windows для администрирования в течение многих лет, я никогда столкнулся с таким странным поведением.
Мой вопрос
Кто-нибудь знает, что может происходить на этом сервере и как это решить?
Обновление 1
Кажется, это впервые произошло после автоматического перехода на летнее время (сервер и часовой пояс в Германии).
У некоторых задач было это сообщение как «Результат последнего запуска»:
Оператор или администратор отклонил запрос. (0x800710E0)
На немецком:
Die Anforderung wurde vom Operator Oder Administrator zurückgewiesen. (0x800710E0)
Все предложения, которые я нашел об этой ошибке (например, Вот этот) должен был снова редактировать и сохранять задачи. Я попробую это сейчас.
Обновление 2
Запланированные задачи снова не запускались, и я обнаружил несколько записей, подобных приведенным ниже, в журнале событий:
Системное время изменилось на «2022» - «03» - «20T01:25:40.348000000Z» с «2022» - «02» - «16T14:47». :49.130142400Z.
Причина изменения: приложение или компонент системы изменили время.
Поэтому он был изменен на один месяц в будущем.
А позже она снова была изменена на правильную дату:
Системное время изменилось на «2022» - «02» - «16T12:04:30.541000000Z» с «2022» - «03» - «20T01:37». :24.558311600Z.
Причина изменения: приложение или компонент системы изменили время.
Таким образом, это изменило дату на один месяц вперед и обратно. Кажется, этого достаточно, чтобы запутать мои задачи, чтобы больше никогда не запускаться.
Я до сих пор не знаю причину.
Одно предложение, которое я нашел относительно этих записей в журнале событий, заключалось в том, чтобы перерегистрировать службу времени:
чистая остановка w32time
w32tm /отменить регистрацию
w32tm /регистр
чистый старт w32time
Так как сервер работает на EC2 на Amazon, AWS, пробовать не буду эта команда:
w32tm/config/manualpeerlist:169.254.169.123/syncfromflags:manual/update
А также эта команда:
reg add "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TimeZoneInformation" /v RealTimeIsUniversal /d 1 /t REG_DWORD /f
Затем, чтобы снова запустить запланированные задачи, я открою каждое из них и снова сохраню.
Обновление 3
Теперь мы снова столкнулись с изменением времени, и вот как выглядят записи в журнале аудита.
Во-первых, изменение произошло на 133 дня вперед:
Выбранная запись в «17.03.22 06:47:44» имеет следующие данные:
Создан новый процесс.
Тема создателя:
Идентификатор безопасности: СИСТЕМА
Имя учетной записи: EC2AMAZ-K5BI954$
Домен учетной записи: WORKGROUP
Идентификатор входа: 0x3E7
Целевая тема:
Идентификатор безопасности: NULL SID
Имя учетной записи: -
Домен учетной записи: -
Идентификатор входа: 0x0
Обрабатывать информацию:
Новый идентификатор процесса: 0x3478
Имя нового процесса: C:\Windows\System32\conhost.exe
Тип повышения токена: %%1936
Обязательная метка: Обязательная метка\Системный обязательный уровень
Идентификатор процесса-создателя: 0x44bc
Имя процесса-создателя: C:\Windows\System32\wbem\WMIC.exe
Командная строка процесса: ??\C:\Windows\system32\conhost.exe 0xffffffff -ForceV1
Тип повышения уровня маркера указывает тип маркера, назначенного новому процессу в соответствии с политикой контроля учетных записей.
Тип 1 — это полный токен без удаленных привилегий или отключенных групп. Полный токен используется только в том случае, если контроль учетных записей пользователей отключен или если пользователь является встроенной учетной записью администратора или учетной записью службы.
Тип 2 — это токен с повышенными правами без удаленных привилегий или отключенных групп. Маркер с повышенными правами используется, когда включен контроль учетных записей пользователей и пользователь выбирает запуск программы с помощью функции «Запуск от имени администратора». Маркер с повышенными правами также используется, когда приложение настроено на постоянное требование прав администратора или всегда требует максимальных прав, а пользователь является членом группы администраторов.
Тип 3 — это ограниченный токен с удаленными административными привилегиями и отключенными административными группами. Токен с ограниченным доступом используется, когда включен контроль учетных записей, приложение не требует прав администратора и пользователь не выбирает запуск программы с помощью функции «Запуск от имени администратора».
И первая запись на новую (неверную) дату в будущем "28.07.22 13:52:50" была:
Создан новый процесс.
Тема создателя:
Идентификатор безопасности: СИСТЕМА
Имя учетной записи: EC2AMAZ-K5BI954$
Домен учетной записи: WORKGROUP
Идентификатор входа: 0x3E7
Целевая тема:
Идентификатор безопасности: NULL SID
Имя учетной записи: -
Домен учетной записи: -
Идентификатор входа: 0x0
Обрабатывать информацию:
Новый идентификатор процесса: 0x1f64
Имя нового процесса: C:\Program Files (x86)\Google\Update\GoogleUpdate.exe
Тип повышения токена: %%1936
Обязательная метка: Обязательная метка\Системный обязательный уровень
Идентификатор процесса создателя: 0x4a8
Имя процесса-создателя: C:\Windows\System32\svchost.exe
Командная строка процесса: "C:\Program Files (x86)\Google\Update\GoogleUpdate.exe" /ua/installsource scheduler
я гуглил для "??\C:\Windows\system32\conhost.exe 0xffffffff -ForceV1" и нашел несколько статей, в которых утверждается, что это мощь быть злонамеренным:
Позже системное время было автоматически установлено обратно системой:
На самом деле оно было сначала слишком сильно изменено на 16.03.2022, а сразу после этого снова на правильное время 17.03.2022.
Детали записи выглядят так:
Системное время было изменено.
Предмет:
Идентификатор безопасности: ЛОКАЛЬНАЯ СЛУЖБА
Имя учетной записи: ЛОКАЛЬНАЯ СЛУЖБА
Домен учетной записи: NT AUTHORITY
Идентификатор входа: 0x3E5
Обрабатывать информацию:
Идентификатор процесса: 0x4a0
Имя: C:\Windows\System32\svchost.exe
Предыдущий раз: â2022â-â07â-â28T11:59:14.787568600Z
Новое время: «2022» - «03» - «16T15:02:28.443000000Z».
Это событие генерируется при изменении системного времени. Служба времени Windows, работающая с системными привилегиями, регулярно изменяет системное время. Другие изменения системного времени могут свидетельствовать о попытках взлома компьютера.
Так что теперь, даже после того, как я активировал аудит, я все еще совершенно не понимаю, что происходит в моей системе.
Обновление 4
В конце концов мы сдались и настроили еще одну машину AWS EC2, на этот раз Windows Server 2022.
Я вручную перенес все со старого сервера на новый сервер (файлы, базы данных, веб-сайты IIS и т. д.).
Работает с ок. 2 недели уже без проблем.
Хотя это не техническое решение, но, по крайней мере, рабочее.
