Wsus windows 7 не было отчета - Доктор Windows - ваш надежный помощник

21.06.2021 – Пожалуйста, ищите последнюю версию этого документа по ссылке Как починить Windows Update?

Обновлено 12.03.2021 – добавлен скрипт для восстановление доступов к реестру и системным папкам

Ранее, я уже писал, как сверить список компьютеров, которые есть в AD с теми, которые есть во WSUS. Если эти списки не совпадают, то у вас проблема и часть компьютеров не обновляется.

В самом простом случае, вы забыли сделать групповую политику, которая настраивает клиентские компьютеры и серверы на обновление со WSUS, или сконфигурировали ее так, что она не применяется. Ручная настройка параметров через gpedit.msc тоже допустима, но только для тех компьютеров, которые не входят в домен.

Итак, политика применяется, но все равно компьютер не обновляется. Что делать и как лечить?

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

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

wsus_detect_manual.cmd

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

del /f /s /q %windir%SoftwareDistributiondownload*.*

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%SoftwareDistributiondownload*.*

ren %systemroot%System32Catroot2 Catroot2.old
ren %systemroot%SoftwareDistribution SoftwareDistribution.old

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

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

%windir%system32regsvr32.exe /U /s %windir%system32vbscript.dll
%windir%system32regsvr32.exe /U /s %windir%system32mshtml.dll
%windir%system32regsvr32.exe /U /s %windir%system32msjava.dll
%windir%system32regsvr32.exe /U /s %windir%system32msxml.dll
%windir%system32regsvr32.exe /U /s %windir%system32actxprxy.dll
%windir%system32regsvr32.exe /U /s %windir%system32shdocvw.dll
%windir%system32regsvr32.exe /U /s %windir%system32Mssip32.dll
%windir%system32regsvr32.exe /U /s %windir%system32wintrust.dll
%windir%system32regsvr32.exe /U /s %windir%system32initpki.dll
%windir%system32regsvr32.exe /U /s %windir%system32dssenh.dll
%windir%system32regsvr32.exe /U /s %windir%system32rsaenh.dll
%windir%system32regsvr32.exe /U /s %windir%system32gpkcsp.dll
%windir%system32regsvr32.exe /U /s %windir%system32sccbase.dll
%windir%system32regsvr32.exe /U /s %windir%system32slbcsp.dll
%windir%system32regsvr32.exe /U /s %windir%system32cryptdlg.dll
%windir%system32regsvr32.exe /U /s %windir%system32Urlmon.dll
%windir%system32regsvr32.exe /U /s %windir%system32Oleaut32.dll
%windir%system32regsvr32.exe /U /s %windir%system32msxml2.dll
%windir%system32regsvr32.exe /U /s %windir%system32Browseui.dll
%windir%system32regsvr32.exe /U /s %windir%system32shell32.dll
%windir%system32regsvr32.exe /U /s %windir%system32Mssip32.dll
%windir%system32regsvr32.exe /U /s %windir%system32atl.dll
%windir%system32regsvr32.exe /U /s %windir%system32jscript.dll
%windir%system32regsvr32.exe /U /s %windir%system32msxml3.dll
%windir%system32regsvr32.exe /U /s %windir%system32softpub.dll
%windir%system32regsvr32.exe /U /s %windir%system32wuapi.dll
%windir%system32regsvr32.exe /U /s %windir%system32wuaueng.dll
%windir%system32regsvr32.exe /U /s %windir%system32wuaueng1.dll
%windir%system32regsvr32.exe /U /s %windir%system32wucltui.dll
%windir%system32regsvr32.exe /U /s %windir%system32wups.dll
%windir%system32regsvr32.exe /U /s %windir%system32wups2.dll
%windir%system32regsvr32.exe /U /s %windir%system32wuweb.dll

%windir%system32regsvr32.exe /s %windir%system32vbscript.dll
%windir%system32regsvr32.exe /s %windir%system32mshtml.dll
%windir%system32regsvr32.exe /s %windir%system32msjava.dll
%windir%system32regsvr32.exe /s %windir%system32msxml.dll
%windir%system32regsvr32.exe /s %windir%system32actxprxy.dll
%windir%system32regsvr32.exe /s %windir%system32shdocvw.dll
%windir%system32regsvr32.exe /s %windir%system32Mssip32.dll
%windir%system32regsvr32.exe /s %windir%system32wintrust.dll
%windir%system32regsvr32.exe /s %windir%system32initpki.dll
%windir%system32regsvr32.exe /s %windir%system32dssenh.dll
%windir%system32regsvr32.exe /s %windir%system32rsaenh.dll
%windir%system32regsvr32.exe /s %windir%system32gpkcsp.dll
%windir%system32regsvr32.exe /s %windir%system32sccbase.dll
%windir%system32regsvr32.exe /s %windir%system32slbcsp.dll
%windir%system32regsvr32.exe /s %windir%system32cryptdlg.dll
%windir%system32regsvr32.exe /s %windir%system32Urlmon.dll
%windir%system32regsvr32.exe /s %windir%system32Oleaut32.dll
%windir%system32regsvr32.exe /s %windir%system32msxml2.dll
%windir%system32regsvr32.exe /s %windir%system32Browseui.dll
%windir%system32regsvr32.exe /s %windir%system32shell32.dll
%windir%system32regsvr32.exe /s %windir%system32Mssip32.dll
%windir%system32regsvr32.exe /s %windir%system32atl.dll
%windir%system32regsvr32.exe /s %windir%system32jscript.dll
%windir%system32regsvr32.exe /s %windir%system32msxml3.dll
%windir%system32regsvr32.exe /s %windir%system32softpub.dll
%windir%system32regsvr32.exe /s %windir%system32wuapi.dll
%windir%system32regsvr32.exe /s %windir%system32wuaueng.dll
%windir%system32regsvr32.exe /s %windir%system32wuaueng1.dll
%windir%system32regsvr32.exe /s %windir%system32wucltui.dll
%windir%system32regsvr32.exe /s %windir%system32wups.dll
%windir%system32regsvr32.exe /s %windir%system32wups2.dll
%windir%system32regsvr32.exe /s %windir%system32wuweb.dll

net start bits
net start wuauserv
net start cryptsvc

wuauclt /detectnow

exit

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

wsus_resetaut_detect_manual.cmd

wuauclt.exe /resetauthorization /detectnow

4. Если нужно просто обнулить авторизацию, то можно воспользоваться конструкцией из предыдущего скрипта. Практика показала, что еще лучше удалять лишние ключи из реестра, для чего мы используем следующий скрипт

AU_Clean_SID.cmd

@echo on
net stop wuauserv
REG DELETE “HKLMSOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdate” /v AccountDomainSid /f
REG DELETE “HKLMSOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdate” /v PingID /f
REG DELETE “HKLMSOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdate” /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

Скрипт был найден в статье базы знаний Microsoft

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

notepad.exe %windir%windowsupdate.log

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

Итак, вернемся к логу, коды ошибок WSUS 3 могут помочь в разбирательстве.

Одна из распространенных проблем со wsus клиентом на серверах может заключаться в том, что сам сервис может подключаться к WSUS через прокси, а этого не нужно и наоборот. Манипулировать этим поведением можно с помощью команды proxycfg

Доступ без прокси: proxycfg –d
Доступ через прокси с опциональным указанием байпас листа: proxycfg –d
Проимпортировать пользовательские настройки: proxycfg –u

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

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

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

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

Довелось наблюдать следующую картину: некоторые рабочие станции вдруг стали отваливаться от WSUS. При этом, по мере увеличения парка ПК с Windows 10, случаи стали происходить чаще, т.е. примечательно то, что данная проблема происходила только на компьютерах с Windows 10.

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

Есть, однако, предположение, что это как-то связано с установкой или попыткой установки Feature Upgrade (переход к новому билду ОС), но 100% подтверждения этому нет.

В консоли WSUS при этом можно наблюдать одну из следующих картин:

Рис. 1 — ПК в какой-то момент перестал отчитываться о своем состоянии

Рис. 2 — ПК есть на WSUS, но отчетов вообще не отправляет

РЕШЕНИЕ:

1. Первым делом нужно убедиться в правильной настройке адреса сервера WSUS на клиентской машине

Для этого проверяем ветку реестра:

HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdate

2. Убеждаемся в доступности самого сервера WSUS с клиентской машины

ping, tracert, проверка порта telnet-ом и т.д.

3. Если предыдущие два пункта выполнены успешно, выполняем команду:

wuauclt /detectnow /resetauthorization

РЕКОМЕНДАЦИЯ: перед этим лучше удалить ПК на WSUS’е

Данная команда должна заново перерегистрировать станцию на сервере WSUS

ВАЖНО: Скорее всего, клиент «отрепортится» не сразу, и может пройти значительное количество времени (от нескольких десятков минут и более)

4. Командой

wuauclt /reportnow

можно попробовать отправить статистику на WSUS вручную.

После успешного проделывания команд, рабочая станция на WSUS актуализируется:

Рис. 3 — ПК зарегистрировался на WSUS и корректно отправляет информацию

В галерее скриптов Technet есть довольно полезный и простой скрипт для сброса компонентов центра обновлений — Reset Windows Update Agent. Скрипт универсальный и подходит для всех версий Windows: начиная с Windows XP и заканчивая последними версиями Windows 10. Рассмотрим, как им пользоваться.

Прежде чем перейти к сбросу конфигурации центра обновления Windows настоятельно рекомендуем сначала попробовать более простое и эффективное средство для автоматического исправления проблем в службе обновления Windows – средство устранения неполадок Центра обновления Windows (Windows Update Troubleshooter).

Источник

В консоли WSUS при этом можно наблюдать одну из следующих картин:

Рис. 1 — ПК в какой-то момент перестал отчитываться о своем состоянии

Рис. 2 — ПК есть на WSUS, но отчетов вообще не отправляет

РЕШЕНИЕ:

1. Первым делом нужно убедиться в правильной настройке адреса сервера WSUS на клиентской машине

Для этого проверяем ветку реестра:

HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdate

параметры WUServer и WUStatusServer должны содержать корректный адрес вашего сервера WSUS (например: http://mywsus.mycorp.com:8530)

2. Убеждаемся в доступности самого сервера WSUS с клиентской машины

ping, tracert, проверка порта telnet-ом и т.д.

3. Если предыдущие два пункта выполнены успешно, выполняем команду:

wuauclt /detectnow /resetauthorization

РЕКОМЕНДАЦИЯ: перед этим лучше удалить ПК на WSUS’е

Данная команда должна заново перерегистрировать станцию на сервере WSUS

ВАЖНО: Скорее всего, клиент «отрепортится» не сразу, и может пройти значительное количество времени (от нескольких десятков минут и более)

4. Командой

wuauclt /reportnow

можно попробовать отправить статистику на WSUS вручную.

После успешного проделывания команд, рабочая станция на WSUS актуализируется:

Рис. 3 — ПК зарегистрировался на WSUS и корректно отправляет информацию

Источник

Remove From My Forums

Общие обсуждения
В один прекрасный день клиенты перестали слать ВСУС серверу отчеты о состоянии.
При этом ВСУС пишет что мол клиенты давно не подключались.
Если подключиться руками, то клиент подключается, говорит Нет новых обновлений, но сервер
статус не меняет — говорит клиент не подключался давно.
Если завести нового клиента ВСУС, то он находится, но в статусе написано что мол клиент не посылал еще
отчет о состоянии. И так бесконечно долго.

Лог на всех клиентах примерно одинаковый. см. ниже. Подскажите плиз, че случилось то?? (

————

2008-02-11 15:12:40:324 860 b2c AU Triggering AU detection through DetectNow API
2008-02-11 15:12:40:324 860 b2c AU Triggering Online detection (non-interactive)
2008-02-11 15:12:40:324 860 1024 AU #############
2008-02-11 15:12:40:324 860 1024 AU ## START ## AU: Search for updates
2008-02-11 15:12:40:324 860 1024 AU #########
2008-02-11 15:12:40:324 860 1024 AU <<## SUBMITTED ## AU: Search for updates [CallId = {A3278692-6BC7-4CA1-AD6B-7783D7C734DF}]
2008-02-11 15:12:40:324 860 1e38 Agent *************
2008-02-11 15:12:40:324 860 1e38 Agent ** START ** Agent: Finding updates [CallerId = AutomaticUpdates]
2008-02-11 15:12:40:324 860 1e38 Agent *********
2008-02-11 15:12:40:324 860 1e38 Agent   * Online = Yes; Ignore download priority = No
2008-02-11 15:12:40:324 860 1e38 Agent   * Criteria = «IsHidden=0 and IsInstalled=0 and DeploymentAction=’Installation’ and IsAssigned=1 or IsHidden=0 and IsPresent=1 and DeploymentAction=’Uninstallation’ and IsAssigned=1 or IsHidden=0 and IsInstalled=1 and DeploymentAction=’Installation’ and IsAssigned=1 and RebootRequired=1 or IsHidden=0 and IsInstalled=0 and DeploymentAction=’Uninstallation’ and IsAssigned=1 and RebootRequired=1»
2008-02-11 15:12:40:324 860 1e38 Agent   * ServiceID = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}
2008-02-11 15:12:40:324 860 1e38 Misc Validating signature for C:WINDOWSSoftwareDistributionSelfUpdateDefaultwuident.cab:
2008-02-11 15:12:40:355 860 1e38 Misc Microsoft signed: Yes
2008-02-11 15:12:42:885 860 1e38 Misc Validating signature for C:WINDOWSSoftwareDistributionSelfUpdateDefaultwuident.cab:
2008-02-11 15:12:42:885 860 1e38 Misc Microsoft signed: Yes
2008-02-11 15:12:42:901 860 1e38 Misc Validating signature for C:WINDOWSSoftwareDistributionSelfUpdateDefaultwsus3setup.cab:
2008-02-11 15:12:42:917 860 1e38 Misc Microsoft signed: Yes
2008-02-11 15:12:42:917 860 1e38 Setup *********** Setup: Checking whether self-update is required ***********
2008-02-11 15:12:42:917 860 1e38 Setup   * Inf file: C:WINDOWSSoftwareDistributionSelfUpdateDefaultwsus3setup.inf
2008-02-11 15:12:42:917 860 1e38 Setup Update NOT required for C:WINDOWSsystem32cdm.dll: target version = 7.0.6000.381, required version = 7.0.6000.374
2008-02-11 15:12:42:917 860 1e38 Setup Update NOT required for C:WINDOWSsystem32wuapi.dll: target version = 7.0.6000.381, required version = 7.0.6000.374
2008-02-11 15:12:42:917 860 1e38 Setup Update NOT required for C:WINDOWSsystem32wuapi.dll.mui: target version = 7.0.6000.381, required version = 7.0.6000.374
2008-02-11 15:12:42:917 860 1e38 Setup Update NOT required for C:WINDOWSsystem32wuauclt.exe: target version = 7.0.6000.381, required version = 7.0.6000.374
2008-02-11 15:12:42:917 860 1e38 Setup Update NOT required for C:WINDOWSsystem32wuaucpl.cpl: target version = 7.0.6000.381, required version = 7.0.6000.374
2008-02-11 15:12:42:917 860 1e38 Setup Update NOT required for C:WINDOWSsystem32wuaucpl.cpl.mui: target version = 7.0.6000.381, required version = 7.0.6000.374
2008-02-11 15:12:42:917 860 1e38 Setup Update NOT required for C:WINDOWSsystem32wuaueng.dll: target version = 7.0.6000.381, required version = 7.0.6000.374
2008-02-11 15:12:42:917 860 1e38 Setup Update NOT required for C:WINDOWSsystem32wuaueng.dll.mui: target version = 7.0.6000.381, required version = 7.0.6000.374
2008-02-11 15:12:42:917 860 1e38 Setup Update NOT required for C:WINDOWSsystem32wucltui.dll: target version = 7.0.6000.381, required version = 7.0.6000.374
2008-02-11 15:12:42:917 860 1e38 Setup Update NOT required for C:WINDOWSsystem32wucltui.dll.mui: target version = 7.0.6000.381, required version = 7.0.6000.374
2008-02-11 15:12:42:917 860 1e38 Setup Update NOT required for C:WINDOWSsystem32wups.dll: target version = 7.0.6000.381, required version = 7.0.6000.374
2008-02-11 15:12:42:917 860 1e38 Setup Update NOT required for C:WINDOWSsystem32wups2.dll: target version = 7.0.6000.381, required version = 7.0.6000.374
2008-02-11 15:12:42:917 860 1e38 Setup Update NOT required for C:WINDOWSsystem32wuweb.dll: target version = 7.0.6000.381, required version = 7.0.6000.374
2008-02-11 15:12:42:917 860 1e38 Setup   * IsUpdateRequired = No
2008-02-11 15:12:44:010 860 1e38 PT +++++++++++ PT: Synchronizing server updates +++++++++++
2008-02-11 15:12:44:010 860 1e38 PT   + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://server1:8530/ClientWebService/client.asmx
2008-02-11 15:12:44:088 860 1e38 PT WARNING: Cached cookie has expired or new PID is available
2008-02-11 15:12:44:088 860 1e38 PT Initializing simple targeting cookie, clientId = 7c3a516c-7081-4ab1-8971-f1820d33c7d1, target group = SERVERS, DNS name = garant.sever.transtk.ru
2008-02-11 15:12:44:088 860 1e38 PT   Server URL = http://server1:8530/SimpleAuthWebService/SimpleAuth.asmx
2008-02-11 15:12:44:104 860 1e38 PT WARNING: GetCookie failure, error = 0x8024400D, soap client error = 7, soap error code = 300, HTTP status code = 200
2008-02-11 15:12:44:104 860 1e38 PT WARNING: SOAP Fault: 0x00012c
2008-02-11 15:12:44:104 860 1e38 PT WARNING:     faultstring:Fault occurred
2008-02-11 15:12:44:104 860 1e38 PT WARNING:     ErrorCodeerverChanged(4)
2008-02-11 15:12:44:104 860 1e38 PT WARNING:     Messageerver rolled back since last call to GetCookie
2008-02-11 15:12:44:104 860 1e38 PT WARNING:     Method:»http://www.microsoft.com/SoftwareDistribution/Server/ClientWebService/GetCookie»
2008-02-11 15:12:44:104 860 1e38 PT WARNING:     ID:081d2be1-96d8-480d-870d-3cb3b1e213ed
2008-02-11 15:12:44:104 860 1e38 PT WARNING: PTError: 0x80244015
2008-02-11 15:12:44:104 860 1e38 PT WARNING: GetCookie_WithRecovery failed : 0x80244015
2008-02-11 15:12:44:104 860 1e38 PT WARNING: RefreshCookie failed: 0x80244015
2008-02-11 15:12:44:104 860 1e38 PT WARNING: RefreshPTState failed: 0x80244015
2008-02-11 15:12:44:104 860 1e38 PT WARNING: Sync of Updates: 0x80244015
2008-02-11 15:12:44:166 860 1e38 PT WARNING: Cached cookie has expired or new PID is available
2008-02-11 15:12:44:166 860 1e38 PT Initializing simple targeting cookie, clientId = 7c3a516c-7081-4ab1-8971-f1820d33c7d1, target group = SERVERS, DNS name = garant.sever.transtk.ru
2008-02-11 15:12:44:166 860 1e38 PT   Server URL = http://server1:8530/SimpleAuthWebService/SimpleAuth.asmx
2008-02-11 15:12:44:385 860 1e38 Agent   * WARNING: Failed to synchronize, error = 0x80244015
2008-02-11 15:12:44:385 860 1e38 DnldMgr File locations for service 3DA21691-E39D-4DA6-8A4B-B43877BCB1B7 changed
2008-02-11 15:12:44:385 860 1e38 Agent Server changed and need resyncing with server
2008-02-11 15:12:44:432 860 1e38 PT +++++++++++ PT: Synchronizing server updates +++++++++++
2008-02-11 15:12:44:432 860 1e38 PT   + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://server1:8530/ClientWebService/client.asmx
2008-02-11 15:12:47:463 860 1e38 PT +++++++++++ PT: Synchronizing extended update info +++++++++++
2008-02-11 15:12:47:463 860 1e38 PT   + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://server1:8530/ClientWebService/client.asmx
2008-02-11 15:12:47:603 860 1e38 Agent   * Found 0 updates and 38 categories in search; evaluated appl. rules of 484 out of 533 deployed entities
2008-02-11 15:12:47:603 860 1e38 Agent *********
2008-02-11 15:12:47:603 860 1e38 Agent ** END ** Agent: Finding updates [CallerId = AutomaticUpdates]
2008-02-11 15:12:47:603 860 1e38 Agent *************
2008-02-11 15:12:47:603 860 15f4 AU >>## RESUMED ## AU: Search for updates [CallId = {A3278692-6BC7-4CA1-AD6B-7783D7C734DF}]
2008-02-11 15:12:47:603 860 15f4 AU   # 0 updates detected
2008-02-11 15:12:47:603 860 15f4 AU #########
2008-02-11 15:12:47:603 860 15f4 AU ## END ## AU: Search for updates [CallId = {A3278692-6BC7-4CA1-AD6B-7783D7C734DF}]
2008-02-11 15:12:47:603 860 15f4 AU #############
2008-02-11 15:12:47:603 860 15f4 AU AU setting next detection timeout to 2008-02-11 18:02:23
2008-02-11 15:12:52:602 860 1e38 Report REPORT EVENT: {A3F402E3-A3DA-400A-B03B-F6B8868FE30C} 2008-02-11 15:12:47:603+0300 1 147 101 {00000000-0000-0000-0000-000000000000} 0 0 AutomaticUpdates Success Software Synchronization Windows Update Client successfully detected 0 updates.
2008-02-11 15:12:52:602 860 1e38 Report REPORT EVENT: {A52765D9-59E3-412B-81B8-AB70620CE869} 2008-02-11 15:12:47:603+0300 1 156 101 {00000000-0000-0000-0000-000000000000} 0 0 AutomaticUpdates Success Pre-Deployment Check Reporting client status.

Источник

Симптомы

Клиентские компьютеры предоставляют отчет обратно на сервер Microsoft Windows Software Update Services (WSUS). Кроме того могут возникнуть следующие неполадки:

Сообщение об ошибке записывается в файл журнала Windowsupdate.log на клиентских компьютерах:

Предупреждение: Не удалось отправить событий на сервер с hr = 80244008
Сообщения об ошибках времени ожидания для Microsoft SQL Server, отображаются в консоли администрирования на сервере WSUS.
Файл SoftwareDistribution.log, расположенный в папке %programfiles%Microsoft ServicesLogFiles обновления Windows содержит сообщения, подобные приведенным ниже:

<DATE>
<TIME>
W3wp.130DBConnection.LogSqlExceptionDBLAYER ошибка UTC: ошибки [0]: поставщик данных .net SqlClient источника, сервер OPC-AD-WSUS1NWSUS, число -2, класс 10, состояние 0, процедура ConnectionRead (WrapperRead()).,
LineNumber 0: Истекло время ожидания. Время ожидания истекло до завершения операции или сервер не отвечает.

Причина

Эта проблема возникает, если количество отчетов событий в таблице tbEventInstance превышает 1 миллион строк.

Сервер WSUS, с помощью оборудования можно поддерживать максимальное число 15 000 клиентов, используя цикл обнаружения по умолчанию 22 часа. Количество событий, отчетности, добавляемого в таблицу tbEventInstance зависит от количества клиентов и частоту, установленную для каждого определения цикла. Автоматическое удаление строк из таблицы tbEventInstance начинается, когда клиент пытается отправить отчет. Процесс автоматического удаления запускается только в том случае, если события отчетов в таблице tbEventInstance превышает 1 миллион строк.

Процесс автоматического удаления происходит очень медленно и блокирует клиентских компьютеров из отчетов обратно на сервер WSUS. По умолчанию WSUS настроена для удаления события, которые старше, чем за 15 дней на рабочих станциях, которые старше, чем 90 дней на серверах. WSUS удаляет старые события со скоростью 1000 событий каждые 12 часов.

Для получения сведений о том, как определить, является ли таблица tbEventInstance превысило 1 миллион строк обратитесь к разделу «Дополнительная информация».

Решение

Сведения об исправлении

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

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

Примечание. Если наблюдаются другие проблемы или необходимо устранить неполадки, вам может понадобиться создать отдельный запрос на обслуживание. Стандартная оплата за поддержку будет взиматься только за дополнительные вопросы и проблемы, которые не соответствуют требованиям конкретного исправления. Полный список телефонов поддержки и обслуживания клиентов корпорации Майкрософт или создать отдельный запрос на обслуживание посетите следующий веб-узел корпорации Майкрософт:

http://support.microsoft.com/contactus/?ws=supportПримечание. В форме «Пакет исправлений доступен для скачивания» отображаются языки, для которых доступно исправление. Если нужный язык не отображается, значит исправление для данного языка отсутствует.

Предварительные условия

Для установки предварительные компоненты не требуются.

Необходимость перезагрузки

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

Сведения о замене исправлений

Это исправление не заменяет других исправлений.

Сведения о файлах

Английская версия данного исправления содержит атрибуты файла (или более поздние атрибуты файлов), приведенные в следующей таблице. Дата и время для этих файлов указаны в формате общего скоординированного времени (UTC). При просмотре сведений о файле, он преобразуется в локальное время. Чтобы узнать разницу между временем по Гринвичу и местным временем, откройте вкладку Часовой пояс элемента «Дата и время» панели управления.

Имя файла	Версия файла	Размер файла	Дата	Время	Платформа
Eventinstancesfix.dll	Неприменимо	41,272	07-Nov-2005	11:36	x86
Eventinstancesfix.sql	Неприменимо	14,442	01-Nov-2005	10:42	Неприменимо
Runeventinstancesfix.vbs	Неприменимо	1,433	08-Nov-2005	12:16	Неприменимо

Временное решение

Чтобы обойти эту проблему, измените цикл обнаружения на значение в разрешенном диапазоне. С помощью групповой политики можно управлять время между каждого цикла обнаружения от 1 часа до 22 часов. Например при изменении частоты цикл обнаружения по умолчанию 22 часа на 11 часов, 7 500 клиентов уменьшается количество клиентов, которые могут поддерживать сервер WSUS.

Если клиентские компьютеры не отчет обратно на сервер WSUS после изменения частоты цикл обнаружения, необходимо удалить все текущие события из таблицы tbEventInstance. Чтобы сделать это, выполните следующую команду в анализаторе запросов SQL:

Инструкция TRUNCATE TABLE dbo.tbEventInstanceКроме того можно остановить процесс автоматического удаления, а затем увеличить частоту процесс удаления. После увеличения частоты процесс удаления, WSUS удаляет строки в более мелкие части, но сохраняет размер таблицы tbEventInstance.

Чтобы остановить процесс автоматического удаления и задать частоту процесс удаления до 1 часа, выполните следующую команду в анализаторе запросов SQL:

Обновление dbo.tbConfigurationB НАБОР AutoPurgeDetectionPeriod = 1Эта команда запускает процесс удаления каждый час. После запуска этой команды WSUS удаляет 24 000 событий в день со скоростью 1000 событий в час. Это максимальная частота, можно задать для процесса удаления.

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

Используйте следующие формулы для расчета минимальную частоту процесс удаления и частоту обнаружения цикла:

Минимальное удаление процесса частоты: (24/DF) x CL

Частота обнаружения цикла: (CL/PF) x 24Примечание. DF равна частоте цикл обнаружения, CL — количество клиентов WSUS и PF-это частота очистки минимальное.

Например при наличии 4 000 клиентов WSUS и частоту обнаружения цикла равным 8 циклов в день, около 32 000 событий могут регистрироваться в таблицу tbEventInstance. Максимальное число событий, которые могут быть удалены в процессе удаления в день — 24 000 событий, если задать частоту удаления до 1 часа. Таким образом можно снизить частоту обнаружения цикла, таким образом, количество событий, созданных клиентами меньше 24 000.

Статус

Корпорация Майкрософт подтверждает, что это проблема продуктов Майкрософт, перечисленных в разделе «Относится к».

Дополнительные сведения

Как определить, является ли таблица tbEventInstance превысило 1 миллион строк

Запустите SQL Query Analyzer и подключитесь к локальному серверу.
В списке баз данных выберите SUSDB.
В окне запроса вставьте следующий запрос SQL:

select count(*) from tbEventInstance
Нажмите кнопку Выполнить запрос для выполнения запроса.

При запуске Microsoft SQL Server Desktop Engine (WMSDE) (Windows), также можно использовать команду osql для проверки, является ли таблица tbEventInstance превысило 1 миллион строк. Чтобы сделать это, введите в командной строке следующую команду и нажмите клавишу ВВОД:


"%programfiles%Update Servicestoolsosqlosql.exe" -S %COMPUTERNAME%WSUS -E -dSUSDB -Q"SELECT COUNT(*) FROM dbo.tbEventInstance"

Для получения дополнительных сведений щелкните следующий номер статьи базы знаний Майкрософт:

Описание 824684 Стандартные термины, используемые при описании обновлений программных продуктов Майкрософт

Нужна дополнительная помощь?

Источник

Не смотря на то, что сейчас всё больше и больше пользователей переходят на Windows 10 c Windows 7 или Windows 8.1 тем не менее в корпоративном секторе остаются проблемы: совместимость некоторого ПО (например, КриптоПро) с Windows 10, а так же отсутствие бюджета на обновление лицензий операционной системы.

На днях я решил провести аудит информационных систем в компании и уладить лицензионные вопросы. В частности мне пришлось избавиться от уже привычной Windows 10 на рабочих ПК и вернуть OEM версии ОС, которые были предустановлены при копупке компьютеров. К сожалению, ПК оснащались в то время (2010г) Windows Vista Business и легально проапгрейдить

бесплатно

до Windows 10 её нельзя (должна быть минимум Windows 7).

Смирившись с этим досадным фактом, я ввёл в домен компании компьютеры на базе Windows Vista Business Edition (версия 6.0.6000).

В нашей доменной организации существует локальный WSUS (Windows Server Update Services), который работает под управлением Windows Server 2012 Standard. Обращаю внимание, что версия сервера без R2, потому что железо относительно старенькое и не поддерживает 2012 R2 из-за устаревшего BIOS. WSUS работает исправно, все компьютеры на базе Windows 7, 8.1 и 10 без проблем получают обновления и рапортуют о своём состоянии.

Теперь переходим к сути данной статьи.

Однако, я заметил, что появилась одна проблемка, компьютер на базе Vista Business почему-то не шлёт WSUS серверу отчет о состоянии. На WSUS постоянно сообщается, что данный компьютер «Not Yet Reported». А так же WSUS определяет и отображает в списке, что на этом компьютере установлена «Windows 6.0» вместо «Windows Vista Business».

При попытке выполнить

wuauclt /detectnow
wuauclt /reportnow

внешне ничего не меняется. Windows Update сообщает, что новых обновлений не найдено. На WSUS обновлений, которые нужно одобрить тоже не появляется.
Если заглянуть в журнал обновлений, то видно, что 3 обновления всё-таки были установлены: два обновления Definition Update for Windows Defender и одно Microsoft Silverlight.

Чтобы разобраться в этой проблеме почитаем лог событий Windows Update.
Стандартно он расположен в C:WindowsWindowsUpdate.log

Что же там можно увидеть? — Очень много различных записей. Но нас интересуют, прежде всего, записи об ошибках ERROR и FATAL.

Самое начало лога я пропускаю, там никаких серьёзных ошибок не было и трассировки описывали успешность загрузок обновлений в папку C:WindowsSoftwareDistributionDownload.
Нужно начинать смотреть с ключевого выражения «Logging initialized», обозначающее начало работы службы Windows Update.

Например:

2016-06-22   03:28:20:577   1148   bc4   Misc   =========== Logging initialized (build: 6.0.6000.16386, tz: +0400) ===========
2016-06-22   03:28:20:640   1148   bc4   Misc      = Process: C:Windowssystem32svchost.exe
2016-06-22   03:28:20:718   1148   bc4   Misc      = Module: c:windowssystem32wuaueng.dll
2016-06-22   03:28:20:577   1148   bc4   Service   *************
2016-06-22   03:28:20:796   1148   bc4   Service   ** START ** Service: Service startup
2016-06-22   03:28:20:874   1148   bc4   Service   *********
2016-06-22   03:28:20:953   1148   bc4   Agent      * WU client version 6.0.6000.16386
2016-06-22   03:28:20:953   1148   bc4   Agent      * Base directory: C:WindowsSoftwareDistribution
2016-06-22   03:28:21:031   1148   bc4   Agent      * Access type: No proxy
2016-06-22   03:28:21:109   1148   bc4   Agent      * Network state: Connected

Из этих данных нам интересна версия агента обновлений, установленного на ПК — WU client version 6.0.6000.16386. Далее скажу зачем.

Смотрим дальше по логу:

2016-06-22   03:29:06:277   1148   bc4   Agent   *********** Agent: Initializing global settings cache ***********
2016-06-22   03:29:06:277   1148   bc4   Agent      * WSUS server: http://wsus.abcde.ru:8530
2016-06-22   03:29:06:277   1148   bc4   Agent      * WSUS status server: http://wsus.abcde.ru:8530
2016-06-22   03:29:06:277   1148   bc4   Agent      * Target group: (Unassigned Computers)
2016-06-22   03:29:06:277   1148   bc4   Agent      * Windows Update access disabled: No
2016-06-22   03:29:06:387   1148   bc4   Agent      * Found 98 persisted download calls to restore

Видим, что агент получает настройки для обращения к локальному WSUS и что найдено 98 запросов на возобновление загрузок.
Затем идёт блок с подробным описанием, какие загрузки обновлений возобновляются:

2016-06-22   03:29:06:512   1148   bc4   DnldMgr   Download manager restoring 6 downloads
2016-06-22   03:29:06:794   1148   bc4   DtaStor   Update service properties: service registered with AU is {9482F4B4-E343-43B6-B170-9A65BC822C77}
2016-06-22   03:29:06:794   1148   bc4   Agent      * Succeeded to load 98 persisted download calls
2016-06-22   03:29:06:810   1148   bc4   DnldMgr   Retrieved 13 persisted download jobs
2016-06-22   03:29:06:810   1148   bc4   DnldMgr   *********** DnldMgr: Restoring download [no. 0] ***********
2016-06-22   03:29:06:810   1148   bc4   DnldMgr      * BITS JobId = {B175BE09-FF70-4710-A303-420DBA88E8DF}
2016-06-22   03:29:06:810   1148   bc4   DnldMgr      * ServiceId = {9482F4B4-E343-43B6-B170-9A65BC822C77}
2016-06-22   03:29:06:810   1148   bc4   DnldMgr      * UpdateId = {C0183617-4BF7-47EB-B7BA-7EB4738943C7}.101
2016-06-22   03:29:06:935   1148   bc4   DnldMgr      * Restored download job.
2016-06-22   03:29:06:935   1148   bc4   DnldMgr   *********** DnldMgr: Restoring download [no. 1] ***********
………………..
2016-06-22   03:29:07:326   1148   bc4   DnldMgr   *********** DnldMgr: Restoring download [no. 12] ***********
2016-06-22   03:29:07:326   1148   bc4   DnldMgr      * BITS JobId = {6CCF2AFD-0C79-489D-9EF1-135834CB7F3C}
2016-06-22   03:29:07:326   1148   bc4   DnldMgr      * ServiceId = {9482F4B4-E343-43B6-B170-9A65BC822C77}
2016-06-22   03:29:07:342   1148   bc4   DnldMgr      * UpdateId = {03B49CBC-210D-4451-AD36-85464A076C1B}.101
2016-06-22   03:29:07:373   1148   bc4   DnldMgr      * Restored download job.

Видим начало инициализации Автоматического обновления и получения настроек

2016-06-22   03:29:07:389   1148   bc4   AU   ########### AU: Initializing Automatic Updates ###########
2016-06-22   03:29:07:389   1148   bc4   AU      # WSUS server: http://wsus.abcde.ru:8530
2016-06-22   03:29:07:389   1148   bc4   AU      # Detection frequency: 1
2016-06-22   03:29:07:389   1148   bc4   AU      # Approval type: Scheduled (Policy)
2016-06-22   03:29:07:389   1148   bc4   AU      # Scheduled install day/time: Every day at 20:00
2016-06-22   03:29:07:389   1148   bc4   AU      # Auto-install minor updates: Yes (Policy)
2016-06-22   03:29:07:405   1148   bc4   AU   Setting AU scheduled install time to 2016-06-22 16:00:00

И инициализацию основных данных для рапорта

2016-06-22   03:29:07:405   1148   bc4   Report   *********** Report: Initializing static reporting data ***********
2016-06-22   03:29:07:405   1148   bc4   Report      * OS Version = 6.0.6000.0.0.65792
2016-06-22   03:29:07:405   1148   bc4   Report      * OS Product Type = 0x00000006
2016-06-22   03:29:07:593   1148   bc4   Report      * Computer Brand = R-StyleComputers
2016-06-22   03:29:07:593   1148   bc4   Report      * Computer Model = Proxima_
2016-06-22   03:29:07:593   1148   bc4   Report      * Bios Revision = ECG3510M.86A.0118.2010.0113.1426
2016-06-22   03:29:07:593   1148   bc4   Report      * Bios Name = Default System BIOS
2016-06-22   03:29:07:593   1148   bc4   Report      * Bios Release Date = 2010-01-13T00:00:00
2016-06-22   03:29:07:593   1148   bc4   Report      * Locale ID = 1049

Дальше идёт блок трассировки поиска обновлений, где нас ожидают различные проблемы:

2016-06-22   03:29:07:593   1148   bc4   AU   AU finished delayed initialization
2016-06-22   03:29:07:593   1148   bc4   AU   #############
2016-06-22   03:29:07:593   1148   bc4   AU   ## START ## AU: Search for updates
2016-06-22   03:29:07:593   1148   bc4   AU   #########
2016-06-22   03:29:07:608   1148   c14   DnldMgr   *********** DnldMgr: Downloading regulation Odf ***********
2016-06-22   03:29:07:608   1148   c14   DnldMgr      * ServiceId = {9482F4B4-E343-43B6-B170-9A65BC822C77}
2016-06-22   03:29:07:608   1148   c14   DnldMgr      * URL = http://www.update.microsoft.com/odf/v6odf.xml
2016-06-22   03:29:07:608   1148   bc4   AU   <<## SUBMITTED ## AU: Search for updates [CallId = {EB34F6FE-A78E-4B5E-9B04-048C5F02DCEF}]
2016-06-22   03:29:10:379   1148   c14   Misc   WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x80190194
2016-06-22   03:29:10:379   1148   c14   Misc   WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x80190194
2016-06-22   03:29:10:379   1148   c14   DnldMgr   FATAL: DM:CDownloadRegulator::DownloadOdf: WinHttpDownloadFile failed with 0x80244019.
2016-06-22   03:29:10:379   1148   c14   DnldMgr      * Last proxy send request succeeded
2016-06-22   03:29:10:379   1148   c14   DnldMgr   FATAL: DM:CDownloadRegulator::Refresh: DownloadOdf failed with 0x80244019.
2016-06-22   03:29:10:379   1148   c14   DnldMgr   FATAL: DM:CAgentDownloadManager::ProcessWorkItem: Refresh failed with 0x80244019.
2016-06-22   03:29:10:379   1148   c14   Service   WARNING: GetUserTokenFromSessionId failed with error 800703f0 for session 0
2016-06-22   03:29:10:379   1148   c14   Service   WARNING: GetUserTokenFromSessionId failed with error 800703f0 for session 0
2016-06-22   03:29:10:411   1148   c14   DnldMgr   *********** DnldMgr: New download job [UpdateId = {297050CF-1305-4EC2-A00D-A173DE49C416}.101] ***********
2016-06-22   03:29:10:411   1148   c14   DnldMgr      * Update is not allowed to download due to regulation.
2016-06-22   03:29:10:426   1148   c14   DnldMgr   *********** DnldMgr: New download job [UpdateId = {CE468411-BD85-4FBB-9D20-FABCF391F29D}.101] ***********
2016-06-22   03:29:10:426   1148   c14   DnldMgr      * Update is not allowed to download due to regulation.
2016-06-22   03:29:10:442   1148   c14   Service   WARNING: GetUserTokenFromSessionId failed with error 800703f0 for session 0

В этой части блока первая проблема связана с попыткой получить файл http://www.update.microsoft.com/odf/v6odf.xml

DnldMgr   FATAL: DM:CDownloadRegulator::DownloadOdf: WinHttpDownloadFile failed with 0x80244019.
DnldMgr   FATAL: DM:CDownloadRegulator::Refresh: DownloadOdf failed with 0x80244019.
DnldMgr   FATAL: DM:CAgentDownloadManager::ProcessWorkItem: Refresh failed with 0x80244019.

Ошибка 0x80244019 описывается как «Серверу не удалось найти запрошенный универсальный код ресурса (URI)».

А перед этим мы замечаем

Misc WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x80190194
Misc WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x80190194

Ошибка 0x80190194 описывается как «404 — File or directory not found».

Что ещё интересного:

Service WARNING: GetUserTokenFromSessionId failed with error 800703f0 for session 0

Сессия 0 зарезервирована под неинтерактивные (фоновые) пользовательские процессы и службы типа Local System.

Ошибки могут возникать из-за:
1. отсутствия прав доступа к узлу (блокировака брандмауэром, например, или использование прокси-сервера proxycfg -d),
2. сбоями в настройках виртуального каталога SelfUpdate на IIS (проверяется скачкой файла http://имя_wsus_сервера/selfupdate/wuident.cab),
3. неправильных настроек агента, ссылающие его по неверному адресу (проверяются в логе),
4. сбоями на ПК в службах Фоновая интеллектуальная служба передачи (BITS) и Центр обновления Windows (WUAUSERV) (должны быть запущены в режиме Авто) и в службе Установщик модулей Windows (TrustedInstaller должен быть в режиме Вручную).
Кое что здесь

И далее замечаем пару строк:

DnldMgr * Update is not allowed to download due to regulation.

Что означает, не разрешено закачивать из-за правил регулирования, то есть либо запрещено политиками обращаться на внешний Windows Update, либо узел перегружен/не доступен.
В моём случае узел сообщал 404 — File or directory not found.

Спрашивается, а почему агент обновлений лезет на внешний узел Windows Update?
Предполагаю, для того чтобы продолжить закачки, которые были прерваны до переключения агента на WSUS, но попытка получить v6odf.xml сведения о регулировании клиентских подключений к системе обновлений, чтобы все пользователи Windows не перегружали узел одновременно заканчиваются провалом, так как такого файла не существует.
Итак, обратиться к внешнему узлу не получилось, едем дальше.

2016-06-22   03:29:10:724   1148   c14   Agent   ** START ** Agent: Finding updates [CallerId = AutomaticUpdates]
2016-06-22   03:29:10:724   1148   c14   Agent   *********
2016-06-22   03:31:47:659   1148   c14   Handler   FATAL: UH: 0x800f0823: CreatePackage failed in CCbs::CreatePackage
2016-06-22   03:31:47:659   1148   c14   Agent   WARNING: Failed to evaluate Installed rule, updateId = {8D15E24B-503C-4DA5-B317-8C7DD4B1EA50}.100, error = 0x80242017
2016-06-22   03:31:47:659   1148   c14   Handler   FATAL: UH: 0x800f0823: CreatePackage failed in CCbs::CreatePackage
2016-06-22   03:31:47:659   1148   c14   Agent   WARNING: Failed to evaluate Installable rule, updateId = {8D15E24B-503C-4DA5-B317-8C7DD4B1EA50}.100, error = 0x80242017
2016-06-22   03:31:47:659   1148   c14   Handler   FATAL: UH: 0x800f0823: CreatePackage failed in CCbs::CreatePackage
2016-06-22   03:33:11:547   1148   c14   Agent   WARNING: Failed to evaluate Installed rule, updateId = {FC6F72E1-B263-4B65-AF49-1121C7CC5E9D}.101, error = 0x800F0900
2016-06-22   03:33:11:547   1148   c14   Handler   FATAL: UH: 0x800f0900: CreatePackage failed in CCbs::CreatePackage
2016-06-22   03:33:11:782   1148   c14   Agent   WARNING: Failed to evaluate Installed rule, updateId = {407B6B44-298C-42BE-83BD-9A473A74F17A}.101, error = 0x800F0900
2016-06-22   03:33:13:455   1148   c14   Handler   FATAL: UH: 0x800f0900: CreatePackage failed in CCbs::CreatePackage
2016-06-22   03:33:13:455   1148   c14   Agent   WARNING: Failed to evaluate Installed rule, updateId = {28152B93-6549-49D2-82BE-F6F980C1F52A}.101, error = 0x800F0900
2016-06-22   03:33:13:471   1148   c14   Handler   FATAL: UH: 0x800f0900: CreatePackage failed in CCbs::CreatePackage
2016-06-22   03:33:18:709   1148   c14   Agent      * Found 0 updates and 79 categories in search
2016-06-22   03:33:18:709   1148   c14   Agent   *********
2016-06-22   03:33:18:709   1148   c14   Agent   ** END ** Agent: Finding updates [CallerId = AutomaticUpdates]

Согласно Список кодов ошибок Центра обновления Windows

Ошибка 0x800f0823 соответствует 0xf0823 CBS_E_NEW_SERVICING_STACK_REQUIRED (Package needs a newer version of the servicing stack).
Ошибка 0x80242017 означает WU_E_UH_NEW_SERVICING_STACK_REQUIRED (The OS servicing stack must be updated before this update is downloaded or installed).
То есть требуется обновление Обслуживающего стека (OS servicing stack) KB955430.

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

Ошибка 0x800f0900 соответствует 0xf0900 CBS_E_XML_PARSER_FAILURE unexpected internal XML parser error.
То есть возникает какая-то внутренняя ошибка при разборе XML файла. Вероятно, есть проблемы с MSXML Parser (не установлен, старая версия).

И дальше идёт концовка блока проверки обновлений:

2016-06-22   03:33:18:724   1148   c14   Report   REPORT EVENT: {45A0C7AA-9B17-4CD8-93E7-F04F3A8898CD}   2016-06-22 03:29:07:405+0400   1   202   102   {00000000-0000-0000-0000-000000000000}   0   0   AutomaticUpdates   Success   Content Install   Reboot completed.
2016-06-22   03:33:18:724   1148   e84   AU   >>## RESUMED ## AU: Search for updates [CallId = {EB34F6FE-A78E-4B5E-9B04-048C5F02DCEF}]
2016-06-22   03:33:18:724   1148   e84   AU      # 0 updates detected
2016-06-22   03:33:18:724   1148   e84   AU   #########
2016-06-22   03:33:18:724   1148   e84   AU   ## END ## AU: Search for updates [CallId = {EB34F6FE-A78E-4B5E-9B04-048C5F02DCEF}]
2016-06-22   03:33:18:724   1148   e84   AU   #############
2016-06-22   03:33:18:724   1148   e84   AU   Setting AU scheduled install time to 2016-06-22 16:00:00
2016-06-22   03:41:14:186   1148   420   Report   Uploading 1 events using cached cookie, reporting URL = http://wsus.abcde.ru:8530/ReportingWebService/ReportingWebService.asmx
2016-06-22   03:41:16:436   1148   420   Report   Reporter successfully uploaded 1 events.

Сообщающий о том, что обнаружено 0 обновлений и рапорт был выгружен на WSUS, хотя на самом WSUS никаких сведений о рапорте не получено.

Попробуем выполнить обновление в интерактивном режиме, то есть выполнить команду wuauclt /detectnow и посмотрим лог.

2016-06-22   03:44:00:782   1148   fd8   AU   Triggering AU detection through DetectNow API
2016-06-22   03:44:00:782   1148   fd8   AU   Triggering Online detection (interactive)
2016-06-22   03:44:00:782   1148   bc4   AU   #############
2016-06-22   03:44:00:782   1148   bc4   AU   ## START ## AU: Search for updates
2016-06-22   03:44:00:782   1148   bc4   AU   #########
2016-06-22   03:44:00:782   1148   bc4   AU   <<## SUBMITTED ## AU: Search for updates [CallId = {9980C425-6BBF-404E-A82B-F64212C725EA}]
2016-06-22   03:44:00:782   1148   6e0   Agent   *************
2016-06-22   03:44:00:782   1148   6e0   Agent   ** START ** Agent: Finding updates [CallerId = AutomaticUpdates]
2016-06-22   03:44:00:782   1148   6e0   Agent   *********
2016-06-22   03:44:00:782   1148   6e0   Setup   Checking for agent SelfUpdate
2016-06-22   03:44:00:782   1148   6e0   Setup   Client version: Core: 6.0.6000.16386 Aux: 6.0.6000.16386
2016-06-22   03:44:03:095   1148   6e0   Setup   Skipping SelfUpdate check based on the /SKIP directive in wuident
2016-06-22   03:44:03:095   1148   6e0   Setup   SelfUpdate check completed. SelfUpdate is NOT required.
2016-06-22   03:44:05:986   1148   6e0   PT   +++++++++++ PT: Synchronizing server updates +++++++++++
2016-06-22   03:44:05:986   1148   6e0   PT      + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://wsus.abcde.ru:8530/ClientWebService/client.asmx
2016-06-22   03:46:38:421   1148   6e0   Handler   FATAL: UH: 0x800f0823: CreatePackage failed in CCbs::CreatePackage
2016-06-22   03:46:38:421   1148   6e0   Agent   WARNING: Failed to evaluate Installed rule, updateId = {8D15E24B-503C-4DA5-B317-8C7DD4B1EA50}.100, error = 0x80242017
2016-06-22   03:46:38:421   1148   6e0   Handler   FATAL: UH: 0x800f0823: CreatePackage failed in CCbs::CreatePackage
2016-06-22   03:46:38:421   1148   6e0   Agent   WARNING: Failed to evaluate Installable rule, updateId = {8D15E24B-503C-4DA5-B317-8C7DD4B1EA50}.100, error = 0x80242017
2016-06-22   03:46:38:437   1148   6e0   Handler   FATAL: UH: 0x800f0823: CreatePackage failed in CCbs::CreatePackage
2016-06-22   02:47:54:802   1148   6e0   Agent   WARNING: Failed to evaluate Installed rule, updateId = {FC6F72E1-B263-4B65-AF49-1121C7CC5E9D}.101, error = 0x800F0900
2016-06-22   02:47:54:802   1148   6e0   Handler   FATAL: UH: 0x800f0900: CreatePackage failed in CCbs::CreatePackage
2016-06-22   02:47:55:036   1148   6e0   Agent   WARNING: Failed to evaluate Installed rule, updateId = {407B6B44-298C-42BE-83BD-9A473A74F17A}.101, error = 0x800F0900
2016-06-22   02:47:56:724   1148   6e0   Handler   FATAL: UH: 0x800f0900: CreatePackage failed in CCbs::CreatePackage
2016-06-22   02:47:56:724   1148   6e0   Agent   WARNING: Failed to evaluate Installed rule, updateId = {28152B93-6549-49D2-82BE-F6F980C1F52A}.101, error = 0x800F0900
2016-06-22   02:47:56:724   1148   6e0   Handler   FATAL: UH: 0x800f0900: CreatePackage failed in CCbs::CreatePackage
2016-06-22   02:48:00:224   1148   6e0   PT   +++++++++++ PT: Synchronizing extended update info +++++++++++
2016-06-22   02:48:00:224   1148   6e0   PT      + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://wsus.abcde:8530/ClientWebService/client.asmx
2016-06-22   02:48:05:099   1148   6e0   Agent      * Found 0 updates and 79 categories in search
2016-06-22   02:48:05:099   1148   6e0   Agent   *********
2016-06-22   02:48:05:099   1148   6e0   Agent   ** END ** Agent: Finding updates [CallerId = AutomaticUpdates]
2016-06-22   02:48:05:099   1148   6e0   Agent   *************
2016-06-22   02:48:05:115   1148   1e8   AU   >>## RESUMED ## AU: Search for updates [CallId = {9980C425-6BBF-404E-A82B-F64212C725EA}]
2016-06-22   02:48:05:115   1148   1e8   AU      # 0 updates detected
2016-06-22   02:48:05:115   1148   1e8   AU   #########
2016-06-22   02:48:05:115   1148   1e8   AU   ## END ## AU: Search for updates [CallId = {9980C425-6BBF-404E-A82B-F64212C725EA}]
2016-06-22   02:48:05:115   1148   1e8   AU   #############

Получаем ту же картину, что и в неинтерактивном режиме: ошибки 0x800f0823 и 0x800F0900.

2016-06-22 02:48:10:100 1148 6e0 Report REPORT EVENT: {2BC87E9D-D36B-441A-BCC7-6E575F313FF0} 2016-06-22 02:48:05:099+0400 1 147 101 {00000000-0000-0000-0000-000000000000} 0 0 AutomaticUpdates Success Software Synchronization Windows Update Client successfully detected 0 updates.
2016-06-22 02:48:10:100 1148 6e0 Report REPORT EVENT: {BFC579C6-B4FD-4D86-B4F5-90FD27F74EB9} 2016-06-22 02:48:05:099+0400 1 153 101 {00000000-0000-0000-0000-000000000000} 0 0 AutomaticUpdates Success Pre-Deployment Check Reporting client status.

Видно, что агент посылает рапорт, но WSUS его либо не получает, либо не понимает. И ещё странно, что WSUS не понимает, что у меня на ПК установлена Windows Vista, а определяет её как Windows 6.0.

Вначале я погуглил.
Предлагалось выполнить wuauclt /resetauthorization /detectnow но это не помогло.
Предлагалось проверить настройки IIS, но всё было корректно.
Предлагалось кардинально переустановить WSUS, но я был не согласен в виду того, что другие ПК без проблем получают обновления.

Я решил пойти для начала самым простым и логичным способом — попробовать обновить агент обновлений WUA в надежде, что свежая версия агента корректно работает с последней версией WSUS и избавлен от багов. Как мы видели выше, текущая версия агента WU client version 6.0.6000.16386.

На данный момент последняя версия WUA — The latest version of the Windows Update Agent for Windows 7, Windows Vista, and Windows XP is 7.6.7600.256.

Однако, автономного установщика у последней версии агента обновления Windows 7.6.7600.256 не существует. Можно скачать и установить агент обновления Windows версии 7.4.7600.226, а затем последняя версия установится самостоятельно через систему обновлений. Скачать WUA 7.4.7600.226.

После установки новой версии WUA мой WSUS начал правильно определять, что на ПК установлена Windows Vista Business и стал получать рапорты состояния в результате чего WSUS определил какие обновления необходимы для данного ПК.

В логе теперь пишется версия WU client version 7.4.7600.226:

2016-06-22   22:20:17:756   1156   580   Service   ** START ** Service: Service startup
2016-06-22   22:20:17:756   1156   580   Service   *********
2016-06-22   22:20:18:100   1156   580   Agent      * WU client version 7.4.7600.226
2016-06-22   22:20:18:100   1156   580   Agent      * Base directory: C:WindowsSoftwareDistribution
2016-06-22   22:20:18:100   1156   580   Agent      * Access type: No proxy
2016-06-22   22:20:18:115   1156   580   Agent      * Network state: Connected

Далее видим, что в новой версии изменился путь до файла сервера регулирования (Regulation server)

2016-06-22   22:21:20:387   1156   e18   DnldMgr   Regulation server path: https://www.update.microsoft.com/v6/UpdateRegulationService/UpdateRegulation.asmx.
2016-06-22   22:21:21:059   1156   e18   DnldMgr      * Regulation call complete. 0x00000000
2016-06-22   22:21:21:355   1156   e18   DnldMgr   *********** DnldMgr: New download job [UpdateId = {297050CF-1305-4EC2-A00D-A173DE49C416}.101] ***********
2016-06-22   22:21:21:371   1156   e18   DnldMgr      * All files for update were already downloaded and are valid.
2016-06-22   22:21:21:449   1156   e18   DnldMgr   *********** DnldMgr: New download job [UpdateId = {CE468411-BD85-4FBB-9D20-FABCF391F29D}.101] ***********
2016-06-22   22:21:21:465   1156   e18   DnldMgr      * All files for update were already downloaded and are valid.
2016-06-22   22:21:21:933   1156   d44   DnldMgr   BITS job {A353D8B3-E90E-4AF0-8E6D-62B4FFB2B826} completed successfully

Видим, что приостановленные закачки успешно закачивают обновления с внешнего Windows Update:

2016-06-22   22:22:38:022   1156   d44   DnldMgr   *********** DnldMgr: New download job [UpdateId = {5C4CEF27-75EB-4A9A-A000-EE515FA4FF0B}.101] ***********
2016-06-22   22:22:40:364   1156   d44   DnldMgr      * BITS job initialized, JobId = {68D84BF8-76F2-4211-8345-1830ECEC3EEE}
2016-06-22   22:22:40:442   1156   d44   DnldMgr      * Downloading from http://au.download.windowsupdate.com/msdownload/update/software/crup/2009/01/windows6.0-kb958481-x86_bb04066c04a58d50e2634654ea79ac19e21d0bb5.psf to C:WindowsSoftwareDistributionDownload39587d8a1d7edb0e533dac1ad0b51969bb04066c04a58d50e2634654ea79ac19e21d0bb5-1 (17 subranges).
2016-06-22   22:22:40:520   1156   f24   DnldMgr   BITS job {B175BE09-FF70-4710-A303-420DBA88E8DF} completed successfully
2016-06-22   22:22:40:613   1156   f24   Misc   Validating signature for C:WindowsSoftwareDistributionDownload88c2b87e4d67f91e2b681a8a841ad45a8b5036b48590c52e3edba8e297cd3017b7a3043c:
2016-06-22   22:22:40:645   1156   f24   Misc   Microsoft signed: Yes
2016-06-22   22:22:40:645   1156   f24   DnldMgr      Download job bytes total = 1424736, bytes transferred = 1424736

Но, несмотря на значительные подвижки, мы пока всё ещё видим ошибки 0x800f0823 и 0x800f0900:

2016-06-23   02:24:40:074   1156   854   PT   +++++++++++ PT: Synchronizing server updates +++++++++++
2016-06-23   02:24:40:074   1156   854   PT      + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://wsus.abcde.ru:8530/ClientWebService/client.asmx
2016-06-23   02:25:35:155   1156   854   Handler   FATAL: UH: 0x800f0900: CreatePackage failed in CCbs::CreatePackage
2016-06-23   02:25:35:155   1156   854   Agent   WARNING: Failed to evaluate Installed rule, updateId = {FC6F72E1-B263-4B65-AF49-1121C7CC5E9D}.101, hr = 800F0900
2016-06-23   02:25:35:155   1156   854   Handler   FATAL: UH: 0x800f0900: CreatePackage failed in CCbs::CreatePackage
2016-06-23   02:25:35:296   1156   854   Handler   FATAL: UH: 0x800f0900: CreatePackage failed in CCbs::CreatePackage
2016-06-23   02:25:35:296   1156   854   Agent   WARNING: Failed to evaluate Installed rule, updateId = {407B6B44-298C-42BE-83BD-9A473A74F17A}.101, hr = 800F0900
2016-06-23   02:25:35:296   1156   854   Handler   FATAL: UH: 0x800f0900: CreatePackage failed in CCbs::CreatePackage
2016-06-23   02:25:36:217   1156   854   Handler   FATAL: UH: 0x800f0900: CreatePackage failed in CCbs::CreatePackage
2016-06-23   02:25:36:217   1156   854   Agent   WARNING: Failed to evaluate Installed rule, updateId = {28152B93-6549-49D2-82BE-F6F980C1F52A}.101, hr = 800F0900
2016-06-23   02:25:36:217   1156   854   Handler   FATAL: UH: 0x800f0900: CreatePackage failed in CCbs::CreatePackage
2016-06-23   02:26:11:860   1156   854   Handler   FATAL: UH: 0x800f0823: CreatePackage failed in CCbs::CreatePackage
2016-06-23   02:26:11:860   1156   854   Agent   WARNING: Failed to evaluate Installed rule, updateId = {8D15E24B-503C-4DA5-B317-8C7DD4B1EA50}.100, hr = 80242017
2016-06-23   02:26:11:860   1156   854   Handler   FATAL: UH: 0x800f0823: CreatePackage failed in CCbs::CreatePackage
2016-06-23   02:26:11:860   1156   854   Agent   WARNING: Failed to evaluate Installable rule, updateId = {8D15E24B-503C-4DA5-B317-8C7DD4B1EA50}.100, hr = 80242017
2016-06-23   02:26:11:860   1156   854   Handler   FATAL: UH: 0x800f0823: CreatePackage failed in CCbs::CreatePackage
2016-06-23   02:26:17:844   1156   854   PT   +++++++++++ PT: Synchronizing extended update info +++++++++++

Переходим к WSUS и проверяем какие обновления требует наша Windows Vista Business.
Обнаруживаем 151 обновление для Vista и одобряем их установку. Через некоторое время Windows Vista обнаруживает обновления и предлагает их установить.

На этом всё. Удачи!

Источник

На чтение 4 мин. Просмотров 1.1k. Опубликовано 14.07.2019

Службы обновлений Windows Server Update Services или WSUS отвечают за ваши обновления, но иногда вы можете столкнуться с ошибкой при создании отчета . Это может быть вызвано просто нестабильным сетевым подключением.

Но в большинстве случаев это связано с недавними изменениями программного обеспечения, из-за которых ваша машина находилась в состоянии ожидания перезагрузки. И перезапуск, похоже, не совсем подходит. Однако у нас есть несколько решений, которые могут вам помочь, так что давайте начнем.

Как исправить ошибку, возникшую при создании отчета об ошибке WSUS? Первое, что вы должны сделать, это сбросить Winsock и перезапустить сервер WSUS с помощью командной строки. Если это не сработает, убедитесь, что брандмауэр Windows не оказывает никакого влияния на WSUS.

Содержание

Что делать, если отчеты WSUS не работают?
1. Сброс Winsock
2. Перезапустите сервер WSUS.
3. Проверьте свой брандмауэр
4. Редактирование реестра
5. Решение для удаленного рабочего стола
6. Обновите или переустановите сетевые драйверы

Что делать, если отчеты WSUS не работают?

Сброс Winsock
Перезагрузите сервер WSUS
Проверьте свой брандмауэр
Редактирование реестра
Решение для удаленного рабочего стола
Обновите или переустановите сетевые драйверы

1. Сброс Winsock

Чтобы исправить ошибку, возникшую при генерации отчета , необходимо сбросить Winsock, выполнив следующие действия:

Запустите Командную строку от имени администратора.
Введите netsh каталог сброса winsock в Командная строка , нажмите и нажмите Enter .
Введите netsh int ip reset reset.log и нажмите Enter .
Перезагрузите компьютер и попробуйте снова запустить службы обновления.

2. Перезапустите сервер WSUS.

Для этого выполните следующие действия:

В меню «Пуск» откройте командную строку с правами администратора.

Теперь введите следующую команду:

  C: Program FilesUpdate ServicesTools

А теперь введите:

  WsusUtil.exe после установки/обслуживания

Теперь перезапустите сервер WSUS.

3. Проверьте свой брандмауэр

Вы можете отключить брандмауэр Windows и проверить, устраняет ли это ошибку при создании отчета .

Откройте Панель управления .
Затем нажмите Брандмауэр Windows .
Теперь нажмите Разрешить приложение или функцию через брандмауэр Windows .
Теперь откроется окно Разрешенные приложения .
Нажмите кнопку Изменить настройки .
Установите флажки рядом с приложениями или программами, которые вы хотите разрешить через брандмауэр Windows.
Нажмите ОК , чтобы сохранить новые настройки.

4. Редактирование реестра

Следующее исправление включает в себя редактирование некоторых разделов реестра. Для этого выполните следующие действия:

Сначала нажмите Пуск , нажмите Запустить , введите regedit , а затем нажмите ОК .
Найдите и нажмите, чтобы выбрать следующий раздел реестра: HKEY_LOCAL_MACHINE> SYSTEM> CurrentControlSet> Элемент управления> Диспетчер сеансов .
После выбора подключа щелкните правой кнопкой мыши PendingFileRenameOperations и выберите Удалить .
Найдите следующий раздел реестра и нажмите на него: HKEY_LOCAL_MACHINE> ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ> Microsoft> Windows> CurrentVersion> WindowsUpdate> Auto Update .
После выбора этого ключа нажмите правой кнопкой мыши RebootRequired и выберите Удалить .
В разделе меню Файл нажмите Выход , чтобы закрыть редактор реестра.
Перезагрузите машину.

5. Решение для удаленного рабочего стола

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

Нажмите Пуск , затем перейдите в Администрирование и Открыть управление компьютером .
В разделе консоли перейдите на вкладку Локальные пользователи и Группы .
На вкладке сведений откройте Группы .
Нажмите Пользователи удаленного рабочего стола , а затем нажмите Добавить .
В диалоговом окне «Выбор пользователей» нажмите «Местоположения», чтобы указать местоположение поиска.
Нажмите Типы объектов , чтобы указать типы объектов, которые вы хотите найти.
Введите имя, которое вы хотите добавить, в поле Введите имена объектов для выбора .
Нажмите Проверить имена .
Найдя имя, нажмите ОК .

6. Обновите или переустановите сетевые драйверы

Если все остальное не удалось, вы можете исправить Ошибка при создании отчета , обновив или переустановив сетевые драйверы.

Во-первых, чтобы обновить их, выполните следующие действия:

В окне поиска на панели задач выберите Диспетчер устройств .
Выберите категорию, чтобы увидеть названия устройств, затем щелкните правой кнопкой мыши ту, которую хотите обновить.
Выберите Обновить драйвер .
Теперь нажмите Автоматический поиск обновленного программного обеспечения драйвера .
Когда обновление завершено, все готово.

Если этот метод не работает, вы можете использовать сторонние приложения, такие как TweakBit Driver Updater . Используя этот инструмент, вы автоматически обновите все свои драйверы всего за пару кликов.

Чтобы переустановить сетевые драйверы, выполните следующие действия.

Повторите первый шаг из предыдущего обходного пути.
Щелкните правой кнопкой мыши на имени устройства и выберите Удалить .
Теперь перезагрузите вашу машину.
Windows попытается переустановить драйвер при запуске.

Итак, вот 6 решений, которые могут помочь вам исправить Произошла ошибка при создании отчета . Если наши решения помогли вам, не стесняйтесь сообщить нам в разделе комментариев ниже.

Источник

Remove From My Forums

Question
We run WSUS Server on a w2k12r2 and have clients configured through GPO accordingly. Most of the clients (all win10, different builds), do properly get their updates. In total we have about less then 100 clients. Some of them are listed in WSUS console
with «This computer (Server) has not reported status in «x» number of days». Despite this fact they still get updates (not all of them, but lets focus first on these who get their updates without any issue). So my question is, how can a
PC not report his status but in the same time it’s getting updates from the very same WSUS?
Any idea? I have double-checked if GPO is assigned ok, it is HKCU…. is correct and also Get-WindowsUpdateLog shows that this PC gets his updates from the WSUS in charge.
I have googeld a lot and also have tried several fixes, for some machines it helps, for some not. Like I have had a few 1607 builds which had an issue with WSUS, I have applied that patch, if only this was the issue, it was fixed afterwards. But right now it
is my own machine, which is a Creators Update (1703) with all patches applied, and it claims that it has not reported status for 326 days.
To me this whole WSUS thing seems to be a bit of a thing where one can be lucky or not, whether it works good, somehow, or not at all.

ANy idea how I can particularly check for this status reporting thing? And again, WSUS itself should not be wrong configured, since 85 % of the clients work well. It also is not a matter fo firewall etc, at least not that I wold be aware of.

kind regards,
Dieter Tontsch
mobileX AG

Answers

My script will most likely fix your problem. My script does way more than what you showed.

Also, Anne’s comment about «Generally, if the clients not report for 326 days, they will be removed when run Server Cleanup Wizard» — This is true on the COMMUNICATION side, but not the reporting side. I’m guessing your computer is communicating
with WSUS, just not reporting back.

Anyways, without further adieu:

Have a peek at my Adamj Clean-WSUS script. It is the last WSUS Script you will ever need.

http://community.spiceworks.com/scripts/show/2998-adamj-clean-wsus

What it does:

1. Remove all Drivers from the WSUS Database.
2. Shrink your WSUSContent folder’s size by declining superseded updates.
3. Remove declined updates from the WSUS Database.
4. Clean out all the synchronization logs that have built up over time (configurable, with the default keeping the last 14 days of logs).
5. Compress Update Revisions.
6. Remove Obsolete Updates.
7. Computer Object Cleanup (configurable, with the default of deleting computer objects that have not synced within 30 days).
8. Application Pool Memory Configuration to display the current private memory limit and easily increase it by any configurable amount.
9. Run the Recommended SQL database Maintenance script on the actual SQL database.
10. Run the Server Cleanup Wizard.

It will email the report out to you or save it to a file, or both.

Although the script is lengthy, it has been made to be super easy to setup and use. There are some prerequisites and instructions at the top of the script. After installing the prerequisites and configuring the variables for your environment, simply run:

.Clean-WSUS.ps1 -FirstRun

and then

.Clean-WSUS.ps1 -InstallTask

If you wish to view or increase the Application Pool Memory Configuration, you must run it with the required switch. See Get-Help .Clean-WSUS.ps1 -Examples

If you’re having trouble, there’s also a -HelpMe option that will create a log so you can send it to me for support.

Adam Marshall, MCSE: Security
http://www.adamj.org
- Marked as answer by
  
  Monday, July 3, 2017 12:38 PM

Источник

Remove From My Forums

Question
We run WSUS Server on a w2k12r2 and have clients configured through GPO accordingly. Most of the clients (all win10, different builds), do properly get their updates. In total we have about less then 100 clients. Some of them are listed in WSUS console
with «This computer (Server) has not reported status in «x» number of days». Despite this fact they still get updates (not all of them, but lets focus first on these who get their updates without any issue). So my question is, how can a
PC not report his status but in the same time it’s getting updates from the very same WSUS?
Any idea? I have double-checked if GPO is assigned ok, it is HKCU…. is correct and also Get-WindowsUpdateLog shows that this PC gets his updates from the WSUS in charge.
I have googeld a lot and also have tried several fixes, for some machines it helps, for some not. Like I have had a few 1607 builds which had an issue with WSUS, I have applied that patch, if only this was the issue, it was fixed afterwards. But right now it
is my own machine, which is a Creators Update (1703) with all patches applied, and it claims that it has not reported status for 326 days.
To me this whole WSUS thing seems to be a bit of a thing where one can be lucky or not, whether it works good, somehow, or not at all.

ANy idea how I can particularly check for this status reporting thing? And again, WSUS itself should not be wrong configured, since 85 % of the clients work well. It also is not a matter fo firewall etc, at least not that I wold be aware of.

kind regards,
Dieter Tontsch
mobileX AG

Answers

My script will most likely fix your problem. My script does way more than what you showed.

Also, Anne’s comment about «Generally, if the clients not report for 326 days, they will be removed when run Server Cleanup Wizard» — This is true on the COMMUNICATION side, but not the reporting side. I’m guessing your computer is communicating
with WSUS, just not reporting back.

Anyways, without further adieu:

Have a peek at my Adamj Clean-WSUS script. It is the last WSUS Script you will ever need.

http://community.spiceworks.com/scripts/show/2998-adamj-clean-wsus

What it does:

1. Remove all Drivers from the WSUS Database.
2. Shrink your WSUSContent folder’s size by declining superseded updates.
3. Remove declined updates from the WSUS Database.
4. Clean out all the synchronization logs that have built up over time (configurable, with the default keeping the last 14 days of logs).
5. Compress Update Revisions.
6. Remove Obsolete Updates.
7. Computer Object Cleanup (configurable, with the default of deleting computer objects that have not synced within 30 days).
8. Application Pool Memory Configuration to display the current private memory limit and easily increase it by any configurable amount.
9. Run the Recommended SQL database Maintenance script on the actual SQL database.
10. Run the Server Cleanup Wizard.

It will email the report out to you or save it to a file, or both.

Although the script is lengthy, it has been made to be super easy to setup and use. There are some prerequisites and instructions at the top of the script. After installing the prerequisites and configuring the variables for your environment, simply run:

.Clean-WSUS.ps1 -FirstRun

and then

.Clean-WSUS.ps1 -InstallTask

If you wish to view or increase the Application Pool Memory Configuration, you must run it with the required switch. See Get-Help .Clean-WSUS.ps1 -Examples

If you’re having trouble, there’s also a -HelpMe option that will create a log so you can send it to me for support.

Adam Marshall, MCSE: Security
http://www.adamj.org
- Marked as answer by
  
  Monday, July 3, 2017 12:38 PM

Источник

Общие обсуждения

Симптомы

Причина

Решение

Сведения об исправлении

Предварительные условия

Необходимость перезагрузки

Сведения о замене исправлений

Сведения о файлах

Временное решение

Статус

Дополнительные сведения

Как определить, является ли таблица tbEventInstance превысило 1 миллион строк

Нужна дополнительная помощь?

Что делать, если отчеты WSUS не работают?

1. Сброс Winsock

2. Перезапустите сервер WSUS.

3. Проверьте свой брандмауэр

4. Редактирование реестра

5. Решение для удаленного рабочего стола

6. Обновите или переустановите сетевые драйверы

Question

Answers

Question

Answers