Главная

Tuesday, 12 June 2018

Обслуживание WSUS.

Привет.

Решил себе составить краткий мануал по обслуживанию WSUS. Возможно вам будет полезно.

Распределение по группам: hosts как все станции, servers как сервера, pilotHosts это устойчивые клиенты и testGroup как "мальчики для битья".

Оснастка WSUS, ветка Обновления.

*Автоматические утверждения включены только на подгруппы testGroup.

1. Подветка "Критические Обновления".

1.1 Для подгрупп testGroup. 
Внимание: включить отображение колонок "Число необходимых установок" и "Замена".

1.1.1. Оценка какие хосты нуждаются в пришедших за ночь апдейтах:
Утверждение "Не утверждено", состояние "Требуется".
Оцениваем каждое обновление: оно не заменяется другим, подходит под версию ОС, Office или SQL-сервера: если Да (Число необходимых установок > 0), то утверждаем на соответствующую группу в testGroup.

Внимание: в подгруппе testGroup может отсутствовать хост, который нуждается в выбранном обновлении.

1.1.2. Оценка как успешно прошли предыдущие утверждения:
 а) утверждение "Не утверждено", состояние "Установленный/неприменимо/нет состояния".
 В идеале здесь не должно быть ничего.
 б) утверждение "Утверждено", состояние "Установленный/неприменимо/нет состояния".
 В идеале здесь могут быть только обновления по которым информация от хостов еще не получена.

1.2. Для подгрупп hosts, servers, pilotHosts. 
1.2.1. Оценка какие хосты нуждаются в протестированных апдейтах:
Утверждение "Утверждено", состояние "Требуется". Оцениваем каждое обновление как: оно не заменяется другим, подходит под версию ОС, Office или SQL-сервера. Если Да, то утверждаем на соответствующую группу. Для ускорения операции утверждения можно использовать опцию "Применить к дочерним".

1.2.2. Оценка как успешно прошли предыдущие утверждения:
утверждение "Утверждено", состояние "Установлeнный/ неприменимо/нет состояния" или "Любой". В идеале здесь могут быть только обновления по которым информация от хостов еще не получена.

2. Подветка Обновления Безопасности.
2.1.1 Для подгрупп testGroup. 
Повторить шаги по аналогии выше.
2.1.2. Для подгрупп hosts, servers, pilotHosts. 
Повторить шаги по аналогии выше.

Ветка Компьютеры.

3. Группа "Все компьютеры". Состояние "Неудача". 
Оцениваем количество сбоев по каждому хосту. Открываем отчет, жмем "Неудача" напротив каждой ошибки,  смотрим Код ошибки и ее Описание. Смотрим дату последнего отчета о состоянии. Делаем выводы, предпринимаем ответные действия.

Коды многих ошибок WSUS здесь

4. Группа "Неназначенные компьютеры". Состояние "Любой". 
Оцениваем причину появления хоста здесь: смотрим его дату последнего отчета о состоянии. Сверяем политику принадлежности хоста к целевой группе в AD. Делаем выводы, предпринимаем ответные действия.

Оснастка "Диспетчер серверов":

5. меню WSUS, закладка "События". Оцениваем события категории "Ошибка".
Cмотрим oписание ошибок. Делаем выводы, предпринимаем ответные действия.

6. меню Средства/Диспетчер служб ISS. MYUPDATE, Пулы приложений, пул WSUSpool.
Здесь можно править параметры пула или перегружать его. 
Ограничения для работы пула по использованию памяти сервера и ресурсов процессора.


Troubleshooting: 

1) Периодическая проверка на сервере состояния служб:
"Wsus Service" запущена.
"BITS" запущена.
"CryptSvc" запущена.
"Wuauserv" остановлена.

2) Проверка состояния сервера штатными средствами Wsusutil: 
Код ошибки любой. Wsusutil healthcheck – проверка состояния сервера. Результат контролируется в журнале «Приложения», источник “Windows Server Update Services”.
Код ошибки 10032. Решение: Wsusutil reset – рестарт сервера. Результат контролируется в журнале «Приложения», источник “Windows Server Update Services”.

3) Ошибка с источника «Windows Error Reporting» с кодом 1001, файлы:
C:\Windows\WindowsUpdate.log
C:\Windows\SoftwareDistribution\ReportingEvents.log
перекладывает в:
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\*  где в конце файлов можно прочитать причину ошибки.

В идеале в журнале «Приложения», источник “Windows Server Update Services” должны быть события только с кодом 10000.

4) поиск обновления которого нет в списке сервера: по меню оснастки WSUS «Обновления/ Импортировать обновления». Найти, добавить нужное обновление в корзину, открыть корзину, установить опцию «Import directly into Windows Server Update Serviсе», нажать «Импорт». Дождаться загрузки, найти их в списке сервера. Утвердить если требуется.

5) Журналы сервиса WSUS здесь:
C:\Program Files\Update Services\LogFiles\Change.log 
C:\Program Files\Update Services\LogFiles\SoftwareDistribution.log 
Журналы сервера здесь:
C:\Windows\WindowsUpdate.log 
C:\Windows\SoftwareDistribution\ReportingEvents.log 

Для WSUS-клиентов  в домене.

Служба "BITS" запущена.
Служба "CryptSvc" запущена.
Cлужба "Wuauserv" запущена.

Журналы клиента здесь:
C:\Windows\WindowsUpdate.log 
C:\Windows\SoftwareDistribution\ReportingEvents.log 

1) Проверка состояния клиента в отчетах сервера:
Код ошибки 0х80070643. Решение: выполнить .NET repair tool на клиенте. 
Код ошибки 0х80244022. Решение: в GP AD уменьшить частоту повторного обращения к серверу до 3 часов. 
Код ошибки 0х80070564. Решение: выполнить скрипт на клиенте

rem === Останавливаем службу Windows Update
net stop wuauserv
sc sdset wuauserv D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)
rem === очистка кеша клиента Windows Update
del /f /s /q %windir%\SoftwareDistribution\download\*.*
rem === Удаляем идентификационные данные клиента Windows Update
REG DELETE "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v AccountDomainSid /f
REG DELETE "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v PingID /f
REG DELETE "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v SusClientId /f 
reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v SusClientIDValidation /f
net start wuauserv && net start bits && net start cryptsvc
rem === Вызываем форсированную перерегистрацию клиента Windows Update
rem === обнуление авторизации, обнаружение нового WSUS и генерацией отчета на сервер.
wuauclt /resetauthorization /detectnow /reportnow

2) Удалить проблемное обновление у клиента: wusa.exe /uninstall /kb:2790655
Тоже самое сделать в тихом режиме: wusa.exe /quiet /uninstall /kb:2790655 /promptrestart
В журнале ОС будет запись типа Windows update «Security Update for Microsoft Windows (KB2790655)» was successfully uninstalled. (Command line: «wusa.exe  /quiet /uninstall /kb:2790655 /promptrestart»)

3) Удалить (отменить) проблемное обновление можно на сервере WSUS, но только для всей группы хостов.

Вопросы которые у меня пока без ответа:

1) почему при управлении членства ПК политиками из AD ПК в группы назначения попадают, но сами группы в WSUS предварительно надо создавать руками?

2) почему новые ПК которые попадали в группе "Неназначенные" были с попыткаии успешных и не очень установок апдейтов? Автоутверждение было полностью отключено!

3) должен ли я видеть апдейты в консоли со статусом "Не утверждено" которые попадают под правило "Автоутверждение"?

Что вспомню, например про автоматизацию некоторых операций напишу завтра.
Успехов.

4 comments:

  1. Больше озадачило то что группы из домена в WSUS надо создавать руками.(

    ReplyDelete
  2. #Query for Failed updates per Host
    Get-PSWSUSUpdateSummaryPerClient -ComputerScope (New-PSWSUSComputerScope) -UpdateScope (New-PSWSUSUpdateScope) | Where {$_.Failed -gt 0} | ft

    ReplyDelete
  3. Нашел такое - при большом количестве клиентов WSUS, получающих обновления с SCCM Software Update Point, в расширенных настройках пула можно увеличить следующие параметры:
    Queue Length с 1000 до 25000
    “Service Unavailable” Response Type — c HttpLevel на TcpLevel
    Failure Interval (minutes) – с 5 до 30
    Change ‘Maximum Failures’ – с 5 to 60

    Кроме того, рекомендуется установить на WSUS 4.0 на Windows Server 2012 R2 обнову:
    KB2919442
    KB2919355
    KB3095113
    KB3159706.

    ReplyDelete
  4. Wsusutil в C:\Program Files\Update Services\Tools\

    ReplyDelete

А что вы думаете по этому поводу?