Applying computer settings windows 2008 r2 висит
Обновлено: 07.07.2024
Установка очередного внепланового обновления для Windows Server 2008 или Windows Server 2008 R2 приводит к дальнейшей невозможности загрузки сервера с этой ОС. После установки обновления KB4539602, выпущенного Microsoft для исправления проблем с фоновыми заставками рабочего стола (обоями), происходит автоматическое удаление загрузочного файла Windows. Первыми о новой проблеме сообщили пользователи Reddit и портал Bleeping Computer.
Обновление KB4539602 было выпущено Microsoft 7 февраля 2020 г., то есть, уже после официального окончания технической поддержки Server 2008 и Windows 7. Некоторые посетители Reddit отметили возникновение проблемы сразу на нескольких серверах под управлением Windows Server 2008; другие пользователи также сообщили, что обновление KB4539602 приводит к невозможности загрузки ПК под Windows 7.
Список потенциальных причин, приводящих к невозможности загрузки системы после установки KB4539602, включает отсутствие в системе установки предыдущих важных патчей для Server 2008 или наличие их старых версий, а также наличие старых версий подписей алгоритм хеширования SHA-2 и обновлений стека обслуживания.
Вчера CNews также рассказал о массовой проблеме пользователей ПК и ноутбуков под Windows 7, которые столкнулись с невозможностью выключить или перезагрузить компьютер, а также о вариантах решения этой проблемы.
Как избежать проблем с Server 2008
Обновление KB4539602 для Windows Server 2008 является необязательным, то есть, его отсутствие никак не влияет на работу основных функций операционной системы. Самым простым способом избежать возникновения проблем с загрузкой ОС является полное игнорирование его существования.
В описании обновления KB4539602 для Windows 7 (SP1) и 2008 R2 с пакетом обновления SP1 на сайте техподдержки Microsoft отмечается, что перед установкой этого обновления в обязательном порядке необходимо предварительно установить обновление KB4474419 от 23 сентября 2019 г. для нормального функционирования SHA-2, а также обновление KB4490628 от 12 марта сентября 2019 г. для стека обслуживания (SSU), или более поздние их версии.
Оба эти обновления автоматически предлагаются для установки «Центром обновления Windows». После установки обновлений также необходимо перезагрузить систему.
Как спасти уже пострадавшую систему
Пока что Microsoft не представила никаких официальных исправлений для тех, кто уже столкнулся с невозможностью загрузки системы после неудачной установки обновления KB4539602. Тем не менее, администраторы Windows с подачи портала Bleeping Computer уже придумали два неофициальных способа восстановления серверов под ОС Windows Server 2008 с неудачной установкой KB4539602.
Один из вариантов предлагает зайти в «Восстановление системы» (Recovery), затем выбрать букву диска для установки Windows, и далее запустить следующую команду:
Разделяй и зарабатывай: сегментация сети создает новые источники дохода
dism.exe /image:C:\ /cleanup-image / revertpendingactions
Другой вариант подразумевает загрузку в консоли «Восстановление системы», затем выбор и копирование файлов winload.efi и winload.exe, взятых из резервных копий или из другой инсталляции Windows Server 2008, в папку C:\windows\system32. Затем необходимо перезагрузить систему.
Слухи о смерти преувеличены?
Бесплатная техническая поддержка операционных систем Windows 7, Server 2008 и 2008 R2 завершена 14 января 2020 г. В Microsoft официально объявили о том, что эти системы больше не будут получать обновлений и «на прощание» выпустили общедоступный патч KB4534310.
Именно это бесплатное ежемесячное накопительное обновление привело к проблемам с фоновыми заставками рабочего стола, поэтому Microsoft была вынуждена выпустить незапланированное февральское обновление KB4539602.
В Microsoft заявили о том, что проблема в настоящее время находится в стадии расследования, сообщил портал Bleeping Computer. Не исключено, что Microsoft придется еще раз нарушить обещание не выпускать обновлений для Windows 7 и Windows Server 2008, и все же представить еще одну «заплатку на заплатку».
Абсолютно идентичные результаты:
Microsoft (R) Windows (R) Operating System Group Policy Result tool v2.0
Copyright (C) Microsoft Corp. 1981-2001
Created On 10/13/2010 at 08:09:29
OS Type: Microsoft(R) Windows(R) Server 2003, Enterprise Edition
OS Configuration: Primary Domain Controller
OS Version: 5.2.3790
Terminal Server Mode: Remote Administration
Site Name: Default-First-Site
Roaming Profile:
Local Profile: C:\Documents and Settings\dimakh
Connected over a slow link?: No
COMPUTER SETTINGS
------------------
CN=DCNEW,OU=Domain Controllers,DC=metal,DC=local
Last time Group Policy was applied: 10/13/2010 at 08:05:47
Group Policy was applied from: dcnew.metal.local
Group Policy slow link threshold: 500 kbps
Domain Name: metal
Domain Type: Windows 2000
Applied Group Policy Objects
-----------------------------
Default Domain Policy
Default Domain Controllers Policy
The following GPOs were not applied because they were filtered out
-------------------------------------------------------------------
Local Group Policy
Filtering: Not Applied (Empty)
The computer is a part of the following security groups
-------------------------------------------------------
BUILTIN\Administrators
Everyone
Cert Publishers
BUILTIN\Pre-Windows 2000 Compatible Access
BUILTIN\Users
Windows Authorization Access Group
NT AUTHORITY\NETWORK
NT AUTHORITY\Authenticated Users
This Organization
DCNEW$
Domain Controllers
NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS
Cert Publishers
USER SETTINGS
--------------
CN=DimaKh,OU=Administrators,DC=metal,DC=local
Last time Group Policy was applied: 10/13/2010 at 07:47:55
Group Policy was applied from: dcnew.metal.local
Group Policy slow link threshold: 500 kbps
Domain Name: METAL
Domain Type: Windows 2000
Applied Group Policy Objects
-----------------------------
Default Domain Policy
The following GPOs were not applied because they were filtered out
-------------------------------------------------------------------
Local Group Policy
Filtering: Not Applied (Empty)
The user is a part of the following security groups
---------------------------------------------------
Domain Admins
Everyone
CERTSVC_DCOM_ACCESS
BUILTIN\Administrators
BUILTIN\Backup Operators
BUILTIN\Users
BUILTIN\Pre-Windows 2000 Compatible Access
REMOTE INTERACTIVE LOGON
NT AUTHORITY\INTERACTIVE
NT AUTHORITY\Authenticated Users
This Organization
LOCAL
Domain Users
Enterprise Admins
Terminal
Group Policy Creator Owners
Sec
Schema Admins
CERTSVC_DCOM_ACCESS
Уже не первый раз сталкиваюсь с такой проблемой в Windows Server 2008 R2 / Windows Server 2012/R2: после установки обновлений или неких ролей/компонентов сервер запрашивает перезагрузку, во время которой на экране появляется надпись “ Preparing to configure Windows. Do not turn off your computer ” или “ Подготовка к настройке Windows. Не выключайте компьютер ”. На этом этапе сервер замирает и эта надпись может висеть часами. При этом сервер продолжает быть доступен по сети, но часть служб, в том числе доступ к RDP, не доступны.
Как правило, в этом случае самый быстрый способ решить проблему – перезагрузить сервер по питанию (хардрезет). Например, удаленно перезагрузить физический сервер можно из консоли HP ILO , Dell iDRAC и .т.п, или из консоли Hyper-V , vSphere для виртуальных машин. Но в таком случае есть вероятность нарушить работу ОС. Лучше использовать более «мягкий» способ сброса зависшего при перезагрузке сервера.
С другого компьютера при помощи оснастки Службы (Services) – services.msс удаленно подключимся к зависшему серверу.
В списке служб сервера несложно найти службу Windows Modules Installer (Установщик модулей Windows), находящуюся в состоянии Stopping . Очевидно, именно эта служба мешает выполнению процедуры корректной перезагрузки сервера.
Кнопки управления службой при этом не доступны. В свойствах службы можно узнать имя исполняемого файла: C:\Windows\servicing\TrustedInstaller.exe
Наша задача – принудительно завершить данный процесс. Проще всего воспользоваться сценарием, описанным в статье Как принудительно завершить зависшую службу с учетом того, что эти действия придется выполнить удаленно.
На любом компьютере откройте окно командой строки и для завершения процесса TrustedInstaller.exe на сервере с именем corp-man02 выполнить следующую команду.
taskkill.exe /s corp-man02 /u corp\admin_name /p P@ssw0rd! /im TrustedInstaller.exe
То же самое действие можно выполнить с помощью утилиты Pskill из набора PSTools:
pskill.exe \\corp-man02 TrustedInstaller.exe
psexec \\corp-man02 taskkill /IM TrustedInstaller.exe /F
После этого на экране зависшего сервера должна появиться надпись Shutting down и через несколько мгновений он должен корректно перезагрузится.
Проблема встречается не только на серверных версиях Windows, но и на клиентских Windows 7 / Windows 8 / Windows 10.
Медленная загрузка компьютера, вызванная долгим применением групповых политик, является одной из частых проблем в домене, на которые жалуются пользователи. С точки зрения пользователя компьютер загружается очень долго, и как будто зависает на несколько минут на этапе «Применение параметров компьютера / пользователя». В этой статье я попробую собрать полезные диагностические инструменты и приемы, позволяющие администратору выявить причины медленного применения GPO на компьютерах домена.
На самом деле причин, из-за которых на компьютере долго применяются групповые политики может быть множество: это и проблемы с DNS, доступностью и скоростью подключения к DC, неправильной настройкой сайтов AD или проблемы с репликацией, неверно настроенные групповых политики и кривые скрипты и т.п. Проблематично описать универсальный алгоритм по диагностике всех этих проблем. При решении таких проблем, как правило, большую роль имеет опыт и навыки специалиста, производящего диагностику. В этой статье мы остановимся только на диагностики проблем, связанных с самими механизмами работы GPO и клиента GPClient.
Блокирование наследования групповой политик
Перезагрузите компьютер и проверьте, сохранилась ли проблема с долгим применением GPO. Если сохранилась, вероятнее всего проблема с самим компьютером или локальными политиками (попробуйте их сбросить на дефолтные).
В Windows на экране загрузки системы можно включить отображение расширенной статусной информации, позволяющей пользователям и администратору визуально понять на каком этапе загрузки компьютера наблюдается наибольшая задержка. При включении данной политики, в том числе, начинает отображаться информация о применяемых компонентах GPO.
Включить эту политику можно в следующем разделе GPO:
- в Windows 7 / Vista : Computer Configuration -> Policies -> System -> Verbose vs normal status messages = Enabled
- в Windows 8/10 : Computer Configuration -> Policies -> System -> Display highly detailed status messages = Enabled
Этот же параметр можно активировать через реестр, создав в ветке HKEY_LOCAL_MACHINE\SOFTWARE Microsoft \Windows \CurrentVersion\ Policies\System параметр типа DWORD с именем verbosestatus и значением 1.
Отчет GPResult
Результирующую политику, которая была применена к компьютеру, стоит проанализировать с помощью HTML отчета gpresult, создать который можно такой командой, запущенной с правами администратора:
gpresult /h c:\ps\gpreport.html
Этот отчет достаточно удобен для анализа и может содержать ссылки на различные ошибки при применении GPO.
Кроме того, в разделе отчета Computer Details -> Component Status присутствуют полезные данные о времени (в мс) применения различных компонентов GPO в виде:
Group Policy Files (N/A) 453 Millisecond(s) 18.01.2017 14:10:01 View Log
Group Policy Folders (N/A) 188 Millisecond(s) 18.01.2017 14:10:00 View Log
Group Policy Local Users and Groups (N/A) 328 Millisecond(s) 18.01.2017 14:10:00 View Log
Group Policy Registry (N/A) 171 Millisecond(s) 18.01.2017 14:10:01 View Log
Group Policy Scheduled Tasks (N/A) 343 Millisecond(s) 18.01.2017 14:10:01 View Log
Scripts (N/A) 156 Millisecond(s) 18.01.2017 14:09:04 View Log
Security (N/A) 3 Second(s) 495 Millisecond(s) 18.01.2017 14:09:08 View Log
Реестр (N/A) 18 Second(s) 814 Millisecond(s) 18.01.2017 14:10:00 View Log
Анализ событий от Group Policy в системных журналах Windows
В журнале приложений о медленном применении политик может свидетельствовать событие с EventID 6006 от источника Winlogon с текстом:
Подписчик уведомлений winlogon <GPClient> потратил 3594 сек. на обработку события уведомления (CreateSession). The winlogon notification subscriber <GPClient> took 3594 seconds to handle the notification event (CreateSession).
Судя по данному событию, пользователю пришлось ждать применения групповых политик при загрузке компьютера в течении почти часа…
В Windows 7 / Windows 2008 R2 и выше все события, касающиеся процесса применения групповых политик на клиенте доступны в журнале событий Event Viewer (eventvwr.msc) в разделе Applications and Services Logs –> Microsoft -> Windows -> Applications and Services Logs -> Group Policy -> Operational.
Примечание. В журнале System остались только события, относящиеся к функционирования самой службы Group Policy Client (gpsvc).Для анализа времени применения политик будут полезны следующие EventID:
-
События 4016 и 5016 показывают время начала и завышения процесса обработки расширений применения GPO, причем в последнем указано общую длительность обработки расширения.К примеру, на скриншоте ниже был включен фильтр журнала Group Policy -> Operational по событиям 4016 и 5016. По тексту события 5016 можно увидеть время обработки этого компонента GPO
При анализе журнала стоит также обращать на время, прошедшее между двумя соседними событиями, это может помочь обнаружить проблемный компонент.
Отладочный журнал службы GPSVC
Отладочные журналы Group Policy Preferences
Расширения Group Policy Preferences также могут вести подробные лог загрузки каждого компоненте CSE (Client-Side Extensions). Отладочные журналы CSE можно включить в разделе GPO: Computer Configuration -> Policies -> Administrative Templates->System->Group Policy -> Logging and tracing
Как вы видите, доступные индивидуальные настройки для каждого CSE. В настройках политики можно указать тип событий, записываемых в журнал (Informational, Errors, Warnings или все), максимальный размер журнала и местоположение лога:
- Трейс файл пользовательских политик %SYSTEMDRIVE%\ProgramData\GroupPolicy\Preference\Trace\User.log
- Трейс файл политик компьютера %SYSTEMDRIVE%\ProgramData\GroupPolicy\Preference\Trace\Computer.log
После сбора логов нужно проанализировать их на ошибки, а также попытаться найти соседние события, время между которыми отличается на несколько минут.
Итак, в этой статье мы рассмотрели основные способы диагностики проблем долгого применения групповых политик на компьютерах домена. Надеюсь, статья будет полезной.
Читайте также: