Николай Савельев, Да, поведение, когда DNS-сервер Windows (особенно если это контроллер домена) отвечает не всем клиентам одинаково, может быть связано с несколькими вещами. Раз ты уже отключил DNSSEC и это помогло — это уже большой шаг, но давай разберёмся подробнее, почему dig может работать по-разному с разных машин.
Проверь, с каких IP всё-таки отвечает, а с каких нет.
На тех машинах, где запросы проходят, и где не проходят — выполни:
dig @192.168.2.4 ad2.dom.local +norecurse
и сравни, есть ли разница в ответах. Это нужно, чтобы исключить кэширование, пересылки и попытки рекурсии.
Сделай это и отпиши: с каких IP не работает, и какой точный вывод dig.
Nikara-Gua-305, Если после того, как ты отключил энергосбережение для USB Root Hub, всё стало работать нормально, то, возможно, система на фоне обновлений или других изменений настроек начала активировать эту функцию на USB портах. Отключение возможности энергосбережения должно устранить проблему, так как система больше не будет отключать питание портов для экономии энергии.
Однако вопрос остаётся — почему это вдруг случилось. Вероятно, причина в изменениях драйверов, обновлениях системы или какой-то другой корректировке в настройках питания, которые могли активировать это поведение.
Для дальнейшего анализа, если проблема снова возникнет, можно:
Проверить, были ли установлены какие-либо обновления Windows, драйверов или обновлений BIOS/UEFI.
Проверить настройки питания в BIOS/UEFI, которые могут включать подобные параметры управления питанием для USB.
Обратить внимание на другие изменения в системе, такие как новые устройства или программы, которые могли повлиять на работу USB.
Если настройки не менялись, скорее всего, это было какое-то обновление, которое автоматически включило энергосбережение на USB портах.
supablex, 1. "With logged on users" — что это значит?
Когда политика "No auto-restart with logged on users" активна, то Windows не будет перезагружать компьютер, если кто-то залогинен. Однако важно понять, что это не зависит от активности пользователя, а от состояния его сессии.
Если пользователь нажал Win+L (заблокировал компьютер) или не двигал мышью/клавишами, система всё равно будет считать его залогиненным. Это также означает, что если на компьютере открыт сеанс, то перезагрузка не произойдёт, даже если пользователь не активен.
Если пользователь не залогинен (например, экран заблокирован и сессия неактивна длительное время или пользователь вышел), то Windows будет считать его неактивным, и перезагрузка может быть выполнена в неактивное время, если политика позволяет это.
Итог: Если пользователь заблокировал экран, но сессия не завершена, то система всё равно считает его залогиненным, и перезагрузка не произойдёт. Когда сессия пользователя завершена (в том числе по таймауту), то система может перезагрузить ПК.
2. О "Turn off auto-restart for updates during active hours"
В Windows действительно есть ограничение на максимальное время, которое можно задать для активных часов — это 12 часов, а 11 PM — это максимальная граница для последнего часа.
Если вы установите 11 PM как конечное время, то с 11:00 PM до 00:00 (полночь) будет считаться неактивным временем.
Включительно: если вы устанавливаете активные часы, например, 12:00 AM до 12:00 AM, это означает, что с 12:00 ночи и до 12:00 следующего дня будет активное время, и в этот период перезагрузка не произойдёт.
Однако, если вы хотите исключить перезагрузку в любое время в течение суток (например, с 12:00 AM по 12:00 AM), лучше поставить активные часы с 12:00 AM по 11:59 PM, а с 11:59 PM до 12:00 AM будет неактивное время.
Задача состоит в том, чтобы перезагрузка не произошла во время активных исследований. Если активные часы будут установлены, например, с 6 AM до 11 PM, система не будет делать перезагрузку в эти часы. Если вам нужно максимально безопасное время, скорее всего, нужно задать более раннее время в 6 AM — 11 PM или даже раньше, чтобы минимизировать риски.
План действий:
Задать активные часы с 12:00 AM до 11:59 PM.
Убедиться, что политика "No auto-restart with logged on users" включена.
Оставить перезагрузку на усмотрение пользователя.
Дай знать, получилось ли корректно настроить активные часы, или есть сомнения по диапазону времени.
Сообщение current winpe[amd64] isn't match target image [x86] говорит о том, что Starnet считает, будто целевая система — x86 (32-битная), в то время как текущая среда WinPE — amd64 (64-битная). Такое может происходить по следующим причинам:
Давай начнем с первого шага:
Проверь, действительно ли установочный образ Windows содержит только 64-битную версию системы.
Подключи ISO-файл или флешку с образом Windows.
Открой sources\install.wim (или install.esd) с помощью программы, например, dism или Wimlib, чтобы посмотреть список доступных образов.
Если используешь Windows, то открой PowerShell или CMD от имени администратора и выполни:
dism /Get-WimInfo /WimFile:D:\sources\install.wim
Заменив D: на букву своего накопителя.
Напиши, что получилось — какие Edition и Architecture показывает.
«Пользователь удалён», Windows вроде не позволяет задать 00:00–00:00 как активные часы, потому что интервал не может быть равен нулю — он должен быть хотя бы 1 час. Максимум, который можно установить, — это 18 часов (на момент актуальных версий Windows 10).
Поэтому идея задать 00:00–23:59 — это скорее теоретическая концепция, но на практике:
Если вы задаёте, например, 00:00–18:00, то система будет считать с 18:00 до 00:00 "неактивными часами", когда перезагрузка допустима.
Значит, даже при включении политики "No auto-restart with logged on users", перезагрузка всё равно может произойти, если никто не сидит за ПК в "неактивные часы".
Поэтому, чтобы по-настоящему исключить авто-перезапуск, придётся комбинировать:
Активные часы на максимально допустимые 18 часов, например, 06:00–23:59.
Политику “No auto-restart with logged on users” — вы уже включили.
Настройку “Configure auto-restart required notification for updates” → Method: 2 – User Action — вы тоже включили, это хорошо: перезагрузка будет ждать пользователя.
Проверь, с каких IP всё-таки отвечает, а с каких нет.
На тех машинах, где запросы проходят, и где не проходят — выполни:
dig @192.168.2.4 ad2.dom.local +norecurse
и сравни, есть ли разница в ответах. Это нужно, чтобы исключить кэширование, пересылки и попытки рекурсии.
Сделай это и отпиши: с каких IP не работает, и какой точный вывод dig.