Центр обновления windows реестр. Обеспечение своевременной установки обновлений в рабочих группах

Решая проблемы безопасности вычислительной системы, приходится учитывать целый комплекс проблем, одна из которых – своевременное обновление операционных систем и программного обеспечения.

Введение

Для поддержания актуального состояния операционных систем и ПО информационной системы компании следует осуществлять их регулярные обновления. Эти действия могут выполняться с сайта Microsoft Update каждым клиентским компьютером или посредством использования сервера/серверов Windows Server Update Services (WSUS). Если мы говорим о корпоративной сети, то рекомендованный вариант – использование сервера WSUS. При работе с вышеупомянутой службой достигается значительное снижение Интернет трафика и обеспечивается возможность централизованного управления процессом развертывания исправлений системы и ПО, получаемых от Microsoft.

Хотелось бы дополнительно отметить, что на 23 марта 2011 года компания Microsoft анонсировала выход нового продукта «Windows Intune», одной из функций которого будет выполнение тех задач, за которые раньше отвечал WSUS.

Для обеспечения возможности обновления компьютеров клиентов необходимо:

1. Выполнить проектирование решения

2. Осуществить развертывание сервера/серверов WSUS;

3. Обеспечить регулярную синхронизацию сервера WSUS с ресурсом Microsoft Update;

4. Настроить параметры работы сервера/серверов WSUS;

5. Создать целевые группы и поместить компьютеры клиентов в целевые группы на сервере WSUS.

6. Настроить клиентов на использование серверов WSUS;

7. Обеспечить безопасность сервера/серверов WSUS.

В настоящей статье мы не рассматриваем этапы проектирования и развертывания, синхронизации, речь пойдет о настройке клиентов и обеспечении безопасности сервера WSUS.

Настройка клиентов сервера обновлений без использования групповых политик

Настройка клиентов на использование сервера WSUS возможна тремя способами:

  1. Использование групповой политики;
  2. Использование локальной политики компьютера;
  3. Непосредственное внесение изменений в реестр станций клиентов.

Наилучшим способом является использование Объектов Групповой Политики см. рис. 1, привязанных к требуемому контейнеру AD (для Windows 2003) или AD DS (для Windows 2008), однако этот вариант возможен только в случае, если в организации развернута служба каталога Active Directory. Возможности групповой политики по настройке взаимодействия с сервером управления и по управлению процедурами обновления клиентов полностью обеспечивают потребности администратора. В чем мы можем удостовериться взглянув на рис. 1. Перечень доступных настроек достаточно широк.

Рис. 1. Параметры настройки клиента WSUS.

Если служба каталога в организации не развернута, то реализовать возможность взаимодействия клиента с WSUS можно либо посредством локальной политики, либо путем «прямого» внесения изменений в системный реестр рабочей станции, или сервера, актуальность состояния которого мы хотим обеспечить. В сущности, политика есть ни что иное, как интерфейс к реестру.

Обстоятельства, при которых рабочие станции и серверы не являются клиентами AD, могут возникать в целом ряде случаев, например:

· Использование службы каталога третьих фирм, однако, в качестве серверов приложений, файловых серверов, рабочих станций клиентов используются решения на базе операционных систем Microsoft;

· Необходимость построения «гостевой» зоны для предоставления доступа «внешних» пользователей, к сети Интернет;

· Не достаточная «зрелость» компании, ввиду которой централизованная служба каталога не развернута, или отсутствие потребности в указанной службе.

1. Необходимо размещение службы обновлений в интрасети и сервер статистики, а также распределить клиентов по группам.

В разделе реестра

потребуется указывать адрес, или имя сервера обновлений, к которому будет выполняться подключение клиента и номер порта, который избран для работы с сервером WSUS. По умолчанию подразумевается 80-ый порт.

«WUStatusServer»=http://192.168.1.100

Поскольку требуется помещение компьютеров клиентов в целевые группы, то мы должны указать в какую из целевых групп должен быть помещен компьютер:

«TargetGroupEnabled»=dword:00000001

В нашем варианте целевая группа называется «WSUS-Test-WKS». Для клиентов, имя целевой группы которых будет иным, в этом поле указывается другое значение. Параметр TargetGroupEnabled в данном случае обеспечивает управление помещением в группу со стороны клиента.

Для этого в разделе реестра

"TargetGroup"="WSUS-Test-WKS"

"TargetGroupEnabled"=dword:00000001

"WUServer"="http://192.168.1.100"

"WUStatusServer"="http://192.168.1.100"

"NoAutoUpdate"=dword:00000000

"AUOptions"=dword:00000004

"ScheduledInstallDay"=dword:00000000

"ScheduledInstallTime"=dword:00000009

"UseWUServer"=dword:00000001

"RescheduleWaitTime"=dword:00000001

" NoAutoRebootWithLoggedOnUsers"= dword:00000000

Обеспечив доставку и выполнение указанного файла, мы сможем настроить клиентов сервера WSUS, не прибегая к использованию групповых политик. Описание всех переменных реестра, которые могут быть использованы для работы с сервером обновлений и их возможных значений приводится в Windows Server Update Services 3.0 SP2 Deployment Guide.

Для обеспечения безопасности самого сервера обновлений имеет смысл выполнить ряд простых рекомендаций:

1. Если нам требуется обеспечить безопасный информационный обмен между клиентами и серверами и/или между серверами WSUS, то предусматривается возможность использования протокола SSL. См. раздел «Securing WSUS with the Secure Sockets Layer» в Windows Server Update Services Deployment Guide (). При отсутствии сетевого обмена между серверами перенос данных обеспечивается посредством внешнего носителя. Альтернативным способом защиты, при невозможности использования SSL, является применение протокола IPsec. См. «Overview of IPsec Deployment» http://go.microsoft.com/fwlink/?LinkId=45154.

2. Сервер WSUS, который синхронизируется с Microsoft Update, следует размещать за брандмауэром и предоставлять доступ к нему только тем узлам, которые действительно в этом нуждаются. См. раздел «Configure the Firewall» в Windows Server Update Services Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=79983).

3. Что касается, файлового доступа, то не следует предоставлять избыточных разрешений на ресурсы, описание требований к правам доступа приводится в разделе «Before You Begin» в Windows Server Update Services Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=79983).

4. Если сервер обновлений имеет доступ в Интернет (в ряде случаев этого может и не быть, например, выполняется синхронизация с другим сервером WSUS, который обладает такой возможностью), то его БД рекомендовано размещать на другом компьютере, доступ из вне к которому невозможен. См. «Appendix B: Configure Remote SQL» в the Windows Server Update Services Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=79983).

5. Для управления сервером WSUS, разумно использовать встроенную группу WSUS Administrators, которая будет создана при развертывании.

Леонид Шапиро.

Список литературы.

Anita Taylor Windows Server Update Services 3.0 SP2 Deployment Guide.

Anita Taylor Windows Server Update Services 3.0 SP2 Operations Guide

[i] DMZ - demilitarized zone

Здесь рассматриваются не все, а только основные параметры настройки клиента WSUS.

Указать путь к искомым серверам можно как с помощью адреса, что было сделано в приведенном примере, так и с помощью имени сервера, предусмотрев при этом возможность разрешения имени сервера в его IP-адрес.

Здесь приводится абстрактное имя тестовой группы.

В одной из предыдущих статей мы подробно описали процедуру . После того, как вы настроили сервер, нужно настроить Windows-клиентов (сервера и рабочие станции) на использование сервера WSUS для получения обновлений, чтобы клиенты получали обновления с внутреннего сервера обновлений, а не с серверов Microsoft Update через Интернет. В этой статье мы рассмотрим процедуру настройки клиентов на использование сервера WSUS с помощью групповых политик домена Active Directory.

Групповые политики AD позволяют администратору автоматически назначить компьютеры в различные группы WSUS, избавляя его от необходимости ручного перемещения компьютеров между группами в консоли WSUS и поддержки этих групп в актуальном состоянии. Назначение клиентов к различным целевым группам WSUS основывается на метке в реестре на клиенте (метки задаются групповой политикой или прямым редактированием реестра). Такой тип соотнесения клиентов к группам WSUS называется client side targeting (Таргетинг на стороне клиента).

Предполагается, что в нашей сети будут использоваться две различные политики обновления — отдельная политика установки обновлений для серверов (Servers ) и для рабочих станций (Workstations ). Эти две группы нужно создать в консоли WSUS в секции All Computers.

Совет . Политика использования сервера обновлений WSUS клиентами во многом зависит от организационной структуры OU в Active Directory и правил установки обновлении в организации. В этой статье мы рассмотрим всего лишь частный вариант, позволяющий понять базовые принципы использования политик AD для установки обновлений Windows.

В первую очередь необходимо указать правило группировки компьютеров в консоли WSUS (targeting). По умолчанию в консоли WSUS компьютеры распределяются администратором по группам вручную (server side targeting). Нас это не устраивает, поэтому укажем, что компьютеры распределяются в группы на основе client side targeting (по определенному ключу в реестре клиента). Для этого в консоли WSUS перейдите в раздел Options и откройте параметр Computers . Поменяйте значение на Use Group Policy or registry setting on computers (Использовать на компьютерах групповую политику или параметры реестра).

Теперь можно создать GPO для настройки клиентов WSUS. Откройте доменную консоль управления групповыми политиками (Group Policy Management) и создайте две новые групповые политики: ServerWSUSPolicy и WorkstationWSUSPolicy.

Групповая политика WSUS для серверов Windows

Начнем с описания серверной политики ServerWSUSPolicy .

Настройки групповых политик, отвечающих за работу службы обновлений Windows, находятся в разделе GPO: Computer Configuration -> Policies -> Administrative templates -> Windows Component -> Windows Update (Конфигурация компьютера -> Административные шаблоны -> Компоненты Windows -> Центр обновления Windows).

В нашей организации мы предполагаем использовать данную политику для установки обновлений WSUS на сервера Windows. Предполагается, что все попадающие под эту политику компьютеры будут отнесены к группе Servers в консоли WSUS. Кроме того, мы хотим запретить автоматическую установку обновлений на серверах при их получении. Клиент WSUS должен просто скачать доступные обновления на диск, отобразить оповещение о наличии новых обновлений в системном трее и ожидать запуска установки администратором (ручной или удаленной с помощью ) для начала установки. Это значит, что продуктивные сервера не будут автоматически устанавливать обновления и перезагружаться без подтверждения администратора (обычно эти работы выполняются системным администратором в рамках ежемесячных плановых регламентных работ). Для реализации такой схемы зададим следующие политики:

  • Configure Automatic Updates (Настройка автоматического обновления): Enable . 3 – Auto download and notify for install (Автоматически загружать обновления и уведомлять об их готовности к установке) – клиент автоматически скачивает новые обновлений и оповещает об их появлении;
  • Specify Intranet Microsoft update service location (Указать размещение службы обновлений Майкрософт в интрасети): Enable . Set the intranet update service for detecting updates (Укажите службу обновлений в интрасети для поиска обновлений): http://srv-wsus.сайт:8530 , Set the intranet statistics server (Укажите сервер статистики в интрасети): http://srv-wsus.сайт:8530 – здесь нужно указать адрес вашего сервера WSUS и сервера статистики (обычно они совпадают);
  • No auto-restart with logged on users for scheduled automatic updates installations (Не выполнять автоматическую перезагрузку при автоматической установке обновлений, если в системе работают пользователя): Enable – запретить автоматическую перезагрузку при наличии сессии пользователя;
  • Enable client -side targeting (Разрешить клиенту присоединение к целевой группе): Enable . Target group name for this computer (Имя целевой группу для данного компьютера): Servers – в консоли WSUS отнести клиенты к группе Servers.

Примечание . При настройке политики обновления советуем внимательно познакомиться со всеми настройками, доступными в каждой из опций раздела GPO Windows Update и задать подходящие для вашей инфраструктуры и организации параметры.

Политика установки обновлений WSUS для рабочих станций

Мы предполагаем, что обновления на клиентские рабочие станции, в отличии от серверной политики, будут устанавливаться автоматически ночью сразу после получения обновлений. Компьютеры после установки обновлений должны перезагружаться автоматически (предупреждая пользователя за 5 минут).

В данной GPO (WorkstationWSUSPolicy) мы указываем:

  • Allow Automatic Updates immediate installation (Разрешить немедленную установку автоматических обновлений): Disabled - запрет на немедленную установку обновлений при их получении;
  • Allow non -administrators to receive update notifications (Разрешить пользователям, не являющимся администраторами, получать уведомления об обновлениях): Enabled - отображать не-администраторам предупреждение о появлении новых обновлений и разрешить их ручную установку;
  • Configure Automatic Updates: Enabled . Configure automatic updating: 4 - Auto download and schedule the install. Scheduled install day: 0 - Every day . Scheduled install time: 05:00 – при получении новых обновлений клиент скачивает в локлаьный кэш и планирует их автоматическую установку на 5:00 утра;
  • Target group name for this computer: Workstations – в консоли WSUS отнести клиента к группе Workstations;
  • No auto-restart with logged on users for scheduled automatic updates installations: Disabled - система автоматически перезагрузится через 5 минут после окончания установки обновлений;
  • Specify Intranet Microsoft update service location : Enable. Set the intranet update service for detecting updates: http://srv-wsus.сайт:8530 , Set the intranet statistics server: http://srv-wsus.сайт:8530 –адрес корпоративного WSUS сервера.

В Windows 10 1607 и выше, несмотря на то, что вы указали им получать обновления с внутреннего WSUS, все еще могут пытаться обращаться к серверам Windows Update в интернете. Эта «фича» называется Dual Scan . Для отключения получения обновлений из интернета нужно дополнительно включать политику Do not allow update deferral policies to cause scans against Windows Update ().

Совет . Чтобы улучшить «уровень пропатченности» компьютеров в организации, в обоих политиках можно настроить принудительный запуск службы обновлений (wuauserv) на клиентах. Для этого в разделе Computer Configuration -> Policies-> Windows Setings -> Security Settings -> System Services найдите службу Windows Update и задайте для нее автоматический запуск (Automatic ).

Назначаем политики WSUS на OU Active Directory

Следующий шаг – назначить созданные политики на соответствующие контейнеры (OU) Active Directory. В нашем примере структура OU в домене AD максимально простая: имеются два контейнера – Servers (в нем содержаться все сервера организации, помимо контроллеров домена) и WKS (Workstations –компьютеры пользователей).

Совет . Мы рассматриваем лишь один довольно простой вариант привязки политик WSUS к клиентам. В реальных организациях возможно привязать одну политику WSUS на все компьютеры домена (GPO с настройками WSUS вешается на корень домена), разнести различные виды клиентов по разным OU (как в нашем примере – мы создали разные политики WSUS для серверов и рабочих станций), в больших распределенных доменах можно привязывать , или же назначать GPO на основании , или скомбинировать перечисленные способы.

Чтобы назначить политику на OU, щелкните в консоли управления групповыми политиками по нужному OU, выберите пункт меню Link as Existing GPO и выберите соответствующую политику.

Совет . Не забудьте про отдельную OU с контроллерами домена (Domain Controllers), в большинстве случаев на этот контейнер следует привязать «серверную» политику WSUS.

Точно таким же способом нужно назначить политику WorkstationWSUSPolicy на контейнер AD WKS, в котором находятся рабочие станции Windows.

Осталось обновить групповые политики на клиентах для привязки клиента к серверу WSUS:

Все настройки системы обновлений Windows, которые мы задали групповыми политиками должны появится в реестре клиента в ветке HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate .

Данный reg файл можно использовать для переноса настроек WSUS на другие компьютеры, на которых не удается настроить параметры обновлений с помощью GPO (компьютеры в рабочей группе, изолированных сегментах, DMZ и т.д.)

Windows Registry Editor Version 5.00

"WUServer"="http://srv-wsus.сайт:8530"
"WUStatusServer"="http://srv-wsus.сайт:8530"
"UpdateServiceUrlAlternate"=""
"TargetGroupEnabled"=dword:00000001
"TargetGroup"="Servers"
"ElevateNonAdmins"=dword:00000000

"NoAutoUpdate"=dword:00000000 –
"AUOptions"=dword:00000003
"ScheduledInstallDay"=dword:00000000
"ScheduledInstallTime"=dword:00000003
"ScheduledInstallEveryWeek"=dword:00000001
"UseWUServer"=dword:00000001
"NoAutoRebootWithLoggedOnUsers"=dword:00000001

Также удобно контролировать применённые настройки WSUS на клиентах с помощью rsop.msc.

И через некоторое время (зависит от количества обновлений и пропускной способности канала до сервера WSUS) нужно проверить в трее наличие всплывающего оповещений о наличии новых обновлений. В консоли WSUS в соответствующих группах должны появиться клиенты (в табличном виде отображается имя клиента, IP, ОС, процент их «пропатченности» и дата последнего обновлений статуса). Т.к. мы политиками привязали компьютеры и серверы к различным группам WSUS, они будут получать только обновления, одобренные к установке на соответствующие группы WSUS.

Примечание . Если на клиенте обновления не появляются, рекомендуется внимательно изучить на проблемном клиенте лог службы обновлений Windows (C:\Windows\WindowsUpdate.log). Обратите внимание, что в Windows 10 (Windows Server 2016) используется . Клиент скачивает обновления в локальную папку C:\Windows\SoftwareDistribution\Download. Чтобы запустить поиск новых обновлений на WSUS сервере, нужно выполнить команду:

wuauclt /detectnow

Также иногда приходится принудительно перерегистрировать клиента на сервере WSUS:

wuauclt /detectnow /resetAuthorization

В особо сложных случаях можно попробовать починить службу wuauserv . При возникновении , попробуйте изменить частоту проверки обновлений на сервере WSUS с помощью политики Automatic Update detection frequency.

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

Эта статья объединяет известные мне способы починки агента WSUS.

1. Первый скрипт самый простой, и, на самом деле, даже не для лечения используется, а для того, чтобы принудительно запустить проверку на обновление, ну и, заодно, чистит папку, в которой накапливаются дистрибутивы уже установленных обновлений:

wsus_detect_manual.cmd

net stop wuauserv && net stop bits && net stop cryptsvc

net start wuauserv && net start bits && net start cryptsvc

wuauclt.exe /detectnow exit

2. Второй скрипт нужен для того, чтобы “оживить” неработающий сервис WSUS. В нем идет чистка от старых обновлений, после чего папки SoftwareDistribution и Catroot2 переименовываются, что при перезапуске сервиса приведет к их пересозданию. Затем системные dll библиотеки перерегистрируются.

fix_wsus_service.cmd

net stop bits
net stop wuauserv
net stop cryptsvc

del /f /s /q %windir%\SoftwareDistribution\download\*.*

ren %systemroot%\System32\Catroot2 Catroot2.old
ren %systemroot%\SoftwareDistribution SoftwareDistribution.old

REM del /f /s /q %windir%\SoftwareDistribution\*.*

del /f /s /q %windir%\windowsupdate.log

%windir%\system32\regsvr32.exe /U /s %windir%\system32\vbscript.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\mshtml.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\msjava.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\msxml.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\actxprxy.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\shdocvw.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\wintrust.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\initpki.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\dssenh.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\rsaenh.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\gpkcsp.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\sccbase.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\slbcsp.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\cryptdlg.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\Urlmon.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\Oleaut32.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\msxml2.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\Browseui.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\shell32.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\Mssip32.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\atl.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\jscript.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\msxml3.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\softpub.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\wuapi.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\wuaueng.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\wuaueng1.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\wucltui.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\wups.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\wups2.dll
%windir%\system32\regsvr32.exe /U /s %windir%\system32\wuweb.dll

%windir%\system32\regsvr32.exe /s %windir%\system32\vbscript.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\mshtml.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\msjava.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\msxml.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\actxprxy.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\shdocvw.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\wintrust.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\initpki.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\dssenh.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\rsaenh.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\gpkcsp.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\sccbase.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\slbcsp.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\cryptdlg.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\Urlmon.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\Oleaut32.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\msxml2.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\Browseui.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\shell32.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\Mssip32.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\atl.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\jscript.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\msxml3.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\softpub.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\wuapi.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\wuaueng.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\wuaueng1.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\wucltui.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\wups.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\wups2.dll
%windir%\system32\regsvr32.exe /s %windir%\system32\wuweb.dll

net start bits
net start wuauserv
net start cryptsvc

wuauclt /detectnow

exit

3. Этот скрипт применяется в тех случаях, когда компьютер был недавно клонирован, или в тех, когда регистрации в WSUS у компьютера так и не произошло. Он отличается от предыдущего только предпоследней строчкой, в которой производится обнуление авторизации с перегенерацией идентификатора. Приведу только эту строчку:

wsus_resetaut_detect_manual.cmd

wuauclt.exe /resetauthorization /detectnow

AU_Clean_SID.cmd

@echo on
net stop wuauserv
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
net start wuauserv
wuauclt /resetauthorization /detectnow

5. Иногда, для того, чтобы все заработало нужно переустановить агента WSUS . Вначале нужно скачать latest Windows Update Agent , ну а затем установить соответствующую редакцию

для x32 версий Windows

windowsupdateagent30-x86.exe /wuforce

для x64 версий Windows

windowsupdateagent30-x64.exe /wuforce

Если вы счастливый обладатель Itanium – догадаетесь сами:-)

После установки агента нужно обязательно перезагрузиться.

6. Для “лечения” ошибок 0x80070005, т.е. ошибок доступа может пригодиться нижеприведенный скрипт. Он восстанавливает доступы для администраторов и системы к реестру и системным папкам.

Для выполнения этого скрипта понадобится майкрософтовская утилита subinacl.exe. Она входит в resource kit для Windows Server 2003, но пользоваться той версией, что входит туда не стоит, т.к. там неприятные ошибки. Следует скачать subinacl.exe версии 5.2.3790.1180 .

Restore_registry_and_system_permission.cmd

@echo off
REM Применять при ошибках 0x80070005 Windows Update
subinacl /subkeyreg HKEY_LOCAL_MACHINE /grant=administrators=f
subinacl /subkeyreg HKEY_CURRENT_USER /grant=administrators=f
subinacl /subkeyreg HKEY_CLASSES_ROOT /grant=administrators=f
subinacl /subdirectories %SystemDrive% /grant=administrators=f
subinacl /subkeyreg HKEY_LOCAL_MACHINE /grant=system=f
subinacl /subkeyreg HKEY_CURRENT_USER /grant=system=f
subinacl /subkeyreg HKEY_CLASSES_ROOT /grant=system=f
subinacl /subdirectories %SystemDrive% /grant=system=f

Все эти скрипты можно выполнять практически автоматически, в случае возникновения проблем. Если в результате проблема таки не решена, то приходится разбираться уже плотнее. И тут нам пригодится тот самый windowsupdate.log, который лежит в корне папки Windows. Если компьютер проблемный, то файл этот большого размера. Для простоты, желательно его удалить перед тем как запускать скрипты. Почти во всех скриптах предусмотрена команда его удаления, но не все так просто. Не смотря на остановку сервиса wuauserv, обычно, его продолжают держать открытые IE и т.п. Поэтому, есть хитрый способ. Запускаю

notepad.exe %windir%\windowsupdate.log

Выделяю весь текст, удаляю его и сохраняю вместо старого файла (не забыть в диалоге сохранения поменять тип файла на *.*, а то по умолчанию – *.txt)

Стоит заметить, что есть случаи, когда заставить клиента обновляться со wsus так и не получается. У меня есть прецеденты с парочкой Windows Server 2003 R2, которые мне побороть так и не удалось. Поэтому я их обновляю через интернет:-)

Свежие операционные системы типа Windows 7, Windows 2008 иногда “заводятся” с трудом. Для таких случаев, эмпирическим путем, был найден алгоритм типа:
1. Обновляемся первый раз с сайта microsoft с обновлением агента
2. Потом обновляем агента уже локально
3. А потом все начинает работать

Надеюсь, что плоды наших трудов кому-нибудь помогут.

Для простоты, выкладываю все эти скрипты в уже готовом виде:

Published on Февраль 18, 2009 by · Комментариев нет

В этой статье я расскажу вам о некоторых ключах реестра (registry keys), которые связаны с обновлением Windows (Windows Update). Я покажу вам различные параметры, которые могут принимать эти ключи реестра.

Если вы пропустили вторую часть этой статьи, то, пожалуйста, прочитайте

Хотя и обновление Windows (Windows Update) и WSUS, в общем, достаточно легко настраивать, иногда вы можете получить более подробный контроль, путем внесения некоторых изменений в реестре Windows. В этой статье, я покажу вам некоторые ключи реестра, которые связаны с обновлением Windows (Windows Update). Я покажу вам различные параметры, которые могут принимать эти ключи реестра.

Для начала

Для начала, я осчастливлю юристов и предупрежу, что внесение изменений в реестр (registry) может быть очень опасным. Внесение неправильных параметров реестр, может привести к уничтожению Windows и/или любых запущенных приложений на машине. Перед попыткой внесения изменений в реестр необходимо сделать полную резервную копию системы я готов показать вам, как это делается.

Есть еще одна вещь, о которой я должен вам рассказать. Тонкая настройка, о которой я хочу вам рассказать, применяется только для компьютеров, работающих под управлением Windows XP. Вы можете вносить изменения для определенных машин напрямую, или может их применить как часть сценария при входе (login script). Также некоторые ключи, о которых я расскажу, могут не существовать по умолчанию. Если вы хотите использовать ключ, который не существует, то вы должны для начала создать его. Вы также должны знать, что поведением обновления Windows можно управлять с помощью политики группы (group policy). Политики групп могут иногда модифицировать ключи реестра таким образом, что они следуют заданному ими поведению.

Повышение привилегий

Одна из проблем при получении обновлений от сервера WSUS заключается в том, что пользователи не могут утверждать или отказываться от обновлений до тех пор, пока они не являются членами группы локальных администраторов (local administrators group). Однако, вы можете использовать реестр, для того чтобы повысить привилегии пользователей таким образом, чтобы они имели возможность устанавливать или отказываться от установки изменений вне зависимости, являются ли они членами группы локальных администраторов (local administrator) или нет. С другой стороны, вы также можете запретить пользователям устанавливать обновления и оставить это право администратору (Admin).

Ключ реестра, который отвечает за это: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\ElevateNonAdmins

Ключ ElevateNonAdmins имеет два возможных значения. Значение по умолчанию, равное 1, позволяет пользователям, не являющимися администраторами, устанавливать обновления. Если вы измените это значение на 0, то только администраторы смогут устанавливать обновления.

Target Groups

Одна из замечательных вещей с WSUS заключается в том, что он позволяет использовать позиционирование клиентской стороны (client side targeting). Идея с позиционированием клиентской стороны заключается в том, что вы можете задавать различные компьютерные группы, и раздавать права на установку обновлений в зависимости от членства в группе. По умолчанию позиционирование клиентской стороны не используется, но если вы решите использовать его, то существуют два ключа реестра, которые помогут вам это сделать. Первый из этих ключей включает позиционирование клиентской стороны (client side targeting), а другой указывает название группы, к которой принадлежит компьютер. Оба из этих ключей должны быть созданы в: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\

Первый ключ – это DWORD ключ под названием TargetGroupEnabled. Вы можете присвоить этому ключу значение 0, тем самым отключив client side targeting, или 1, что включает позиционирование клиентской стороны (client side targeting).

Другой ключ, который вы должны создать, должен называться TargetGroup и иметь строковое значение. Значением этого ключа должно быть название группы, к которой должен быть приписан компьютер.

Установка сервера WSUS

Если вы немного были вовлечены в работу с сетью, то вы, вероятно, знаете, что дизайн сети имеет тенденцию изменяться со временем. Такие вещи, как рост компании, новые требования к безопасности и корпоративные ограничения, часто лежат в основе для изменения сети. А как это касается обновления Windows? WSUS масштабируем и может устанавливаться иерархическим способом. Это значит, что в организации может быть несколько установленных серверов WSUS. Если PC перемещен в другую часть компании, то сервер WSUS, который изначально был определен для этого компьютера, может больше не подходить для нового места. К счастью, несколько простых модификаций реестра помогут изменить сервер WSUS, от которого PC получает обновления.

Есть два ключа, которые используются для определения сервера WSUS. Каждый из них расположен в: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\. Первый ключ называется WUServer. Для этого ключа необходимо задать текстовое значение, описывающее URL сервера WSUS (например: http://servername).

Другой ключ, который вы должны изменить – это ключ под названием WUStatusServer. Идея с этим ключом заключается в том, что компьютер (PC) должен сообщать о своем статусе серверу WSUS таким образом, чтобы сервер WSUS мог знать, какие изменения были установлены на компьютере. Ключ WUStatusServer обычно содержит точное такое же значение, как и ключ WUServer (например: http://servername).

Агент автоматического обновления (Automatic Update Agent)

Итак, я рассказал о том, как подключить компьютер (PC) к определенному серверу WSUS или для определенной группы (target group), но это только половина процесса. Обновление Windows Update использует агент обновления (update agent), который в действительности устанавливает обновления. Есть несколько ключей реестра, которые располагаются в HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU и контролируют агента автоматического обновления (automatic update agent).

Первый из этих ключей – это ключ AUOptions. Этому DWORD параметру может быть присвоено значение 2, 3, 4 или 5. Значение 2 значит, что агент должен уведомлять пользователя при загрузке обновлений. Значение 3 значит, что обновление будет загружено автоматически, а пользователю будет сообщено об установке. Значение 4 значит, что обновление должно быть автоматически загружено и установлено в соответствии с планом. Для того, чтобы работала эта опция, необходимо также установить значения для ключей ScheduledInstallDay и ScheduledInstallTime. Подробнее я расскажу об этих ключах позднее. И наконец, значение 5 означает, что автоматическое обновление требуется, но он может быть настроено конечными пользователями.

Следующий ключ, о котором я хочу поговорить – это ключ AutoInstallMinorUpdates. Это ключ может принимать значения 0 или 1. Если значение ключа 0, то незначительные обновления (minor updates) обрабатываются также как и любые другие обновления. Если значение ключа 1, то незначительные обновления (minor updates) тихо устанавливаются в фоновом режиме.

Другой ключ, относящийся к агенту автоматического обновления (Automatic Update Agent) – это ключ DetectionFrequency. Этот ключ позволяет вам задать, как часто агент должен обращаться за обновлениями. Значением ключа должно быть целое число от 1 до 22, что отражает количество часов между попытками обращения за обновлением.

Связанный с ним ключ реестра – это ключ DetectionFrequencyEnabled. Как видно из названия, этот ключ позволяет подключить или отключить функцию Detection Frequency. Если установить значение этого ключа равным 0, то значение ключа DetectionFrequency будет игнорироваться, а если установить значение ключа равным 1, то агент должен будет использовать значение ключа DetectionFrequency.

Следующий ключ, о котором я хочу рассказать – это ключ NoAutoUpdate. Если значение этого ключа 0, то автоматическое обновление подключено. Если значение ключа равно 1, то автоматическое обновление отключено.

Последний ключ реестра, о котором я хочу поговорить – это ключ NoAutoRebootWithLoggedOnUsers. Как вы, вероятно, знаете, некоторые обновления не могут вступить в силу без перезагрузки системы. Если пользователь в это время работает, то перезагрузка может быть очень нежелательной. Это особенно верно, если пользователь отошел от своего рабочего места и не сохранил свою работу. В этом случае поможет ключ NoAutoRebootWithLoggedOnUsers. Значение этого ключа может быть 0 или 1. Если значение ключа равно 0, то пользователи получат 5 минутное предупреждение перед тем, как система автоматически уйдет на перезагрузку. Если значение ключа равно 1, то пользователи просто получат сообщение, в котором спрашивается разрешение на перезагрузку, но пользователи могут осуществить его на свое усмотрение.

Заключение

Существует гораздо больше ключей реестра, касающиеся обновления Windows. Об остальных из них я расскажу во второй части этой статьи.

www.windowsnetworking.com


Смотрите также:

Readers Comments (Комментариев нет)

Exchange 2007

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Проведение мониторинга Exchange 2007 с помощью диспетчера System ...

Введение В этой статье из нескольких частей я хочу показать вам процесс, который недавно использовал для перехода с существующей среды Exchange 2003 ...

Если вы пропустили первую часть этой серии, пожалуйста, прочтите ее по ссылке Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (Часть...

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Мониторинг Exchange 2007 с помощью диспетчера System Center Operations ...