windowsupdate log что это

Быстрый анализ ошибок обновления Windows

Точно неизвестно, какое количество пользователей и системных администраторов сталкиваются с проблемами обновления на компьютерах Windows постоянно или периодически.

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

Ранее Microsoft выпустила несколько некорректных обновлений, которые вызвали проблемы на машинах Windows 10. Самыми известными, пожалуй, являются KB3081424 и KB3194496, который вызвали ошибки на компьютерах по всему миру.

На сайте Microsoft Technet доступна утилита Reset Windows Update Agent, разработанная специально для исправления распространенных проблем обновления. Инструмент успешно справляется с проблемами работы центра обновления Windows, но не сможет помочь, если проблема вызвана на стороне Microsoft.

Быстрая проверка ошибок обновления Windows

Быстрая проверка ошибок обновления Windows» />

Windows сохраняет журнал обновлений, который содержит все события, связанные с обновлением. Эти журналы можно найти по пути C:\Windows\Logs\WindowsUpdate. Логи имеют формат ETW (Event Trace for Windows) и могут быть проанализированы с помощью специализированных инструментов.

Пользователь может также использовать простую команду PowerShell, чтобы преобразовать файлы Event Trace в простой текст, который можно исследовать на предмет ошибок и проблем, связанных с обновлением Windows.

Преобразование журнала обновления:

Затем начнется парсинг файлов Event Trace, который может занять некоторое время, зависящее от количества и размеров файлов журналов.

После этого на рабочем столе появится файл WindowsUpdate.log. Размер файла может достигать нескольких мегабайт. Файл можно открыть в любом текстовом редакторе, например, в Notepad++.

Быстрая проверка ошибок обновления Windows» />

Можно исследовать файл по строкам, а можно немного ускорить процесс:

Несмотря на то, что анализ журнала обновления Windows может занять приличное время, то может быть один из самых лучших способов определить причину сбоя обновления. К тому же, компания Microsoft представила руководство по исправлению ошибок обновления Windows 10, которое также может помочь в решении найденных проблем.

А что вы предпринимаете в случае сбоя обновления Windows?

Источник

Как посмотреть лог обновлений (WindowsUpdate.log) в Windows 10

Если в предыдущих версиях ОС Windows лог файл, в котором фиксируются все этапы установки того или иного обновления, можно было посмотреть без особых трудностей – просто найдя в папке Windows системного диска файл под названием WindowsUpdate.log, то в Windows 10 данный файл отсутствует.

Но это отнюдь не значит, что данная информация в Windows 10 не может быть получена, просто необходимо воспользоваться инструкцией, что будет приведена в данном материале. Давайте приступим.

Получаем файл журнала обновлений в Windows 10

И нажмите клавишу Enter, дабы команда была выполнена.

Требуемый результат достигнут.

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

Просматриваем файл журнала обновлений в Windows 10 с помощью «Просмотр событий»

Будучи там, в правой части окна вы увидите лог с событиями в процессе установки того или иного обновления в операционной системе Windows 10. Кликнув по какому-либо пункту, вы увидите подробности с технической информацией.

В свою очередь, Вы тоже можете нам очень помочь.

Просто поделитесь статьей в социальных сетях и мессенджерах с друзьями.

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

Источник

Файлы журнала

Область применения

Это тема уровня 400 (расширенный).
Полный список тем в этой статье см. в разделе Устранение ошибок при обновлении до Windows 10.

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

Кроме того, отчеты об ошибках Windows разделе в этом документе для справки по поиску кодов ошибок и файлов журналов.

В следующей таблице описаны некоторые файлы журнала и способы их использования для устранения неполадок.

Структура записи журнала

Запись setupact.log или setuperr.log (файлы расположены в C:\Windows) содержит следующие элементы:

См. перечисленные ниже примеры.

Анализ файлов журнала

Следующие инструкции предназначены для специалистов по ИТ. См. также раздел Коды ошибок обновления данного руководства, чтобы ознакомиться с кодами результатов и кодами расширения.

Анализ файлов журнала установки Windows

Например, предположим, что код ошибки — 0x8007042B — 0x2000D. Если выполнить поиск «8007042B», мы обнаружим следующее содержимое из файла setuperr.log:

Некоторые строки в тексте ниже сокращены для удобства. Дата и время в начале каждой строки (например, 2016-10-05 15:27:08) сокращены до минут и секунд, а имя файла сертификата, которое задано как длинная текстовая строка, сокращено до «CN».

Содержимое файла setuperr.log :

В первой строке указано, что произошла ошибка 0x00000570 с файлом C:\ProgramData\Microsoft\Crypto\RSA\S-1-5-18 [CN] (как показано ниже):

0x00000570 — это код ошибки Win32, соответствующий ошибке «ERROR_FILE_CORRUPT. Файл или папка повреждены. Чтение невозможно».

Поэтому программе установки Windows не удалось перенести поврежденный файл C:\ProgramData\Microsoft\Crypto\RSA\S-1-5-18\ [CN]. Этот файл — локальный сертификат системы, и его можно удалить. После поиска в файле setupact.log дополнительных сведений найдена фраза «Приложение оболочки запросило отмену» в расположении с такой же меткой времени, как у строк в файле setuperr.log. Это подтверждает наши подозрение, что этот файл — причина сбоя обновления:

Содержимое файла setupact.log :

Этот анализ показывает, что ошибку обновления Windows можно устранить, удалив файл C:\ProgramData\Microsoft\Crypto\RSA\S-1-5-18\ [CN]. Примечание. В этом примере полное имя файла — C:\ProgramData\Microsoft\Crypto\RSA\S-1-5-18\be8228fb2d3cb6c6b0ccd9ad51b320b4_a43d512c-69f2-42de-aef9-7a88fabdaa3f.

Источник

«Неуловимый» список установленных обновлений Windows

Вы когда-нибудь задумывались, с помощью чего формируется список установленных обновлений Windows? А через какое API его достать? Ответы на эти и другие возникающие вопросы я постараюсь дать в своём небольшом исследовании.

Предыстория или с чего всё началось.

В нашей компании каждый год проходит конференция молодых специалистов, где каждый участник может решить проблему какого-либо отдела (список тем заранее предлагается).

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

Бывают ситуации, когда АРМ или сервер «падает» и приходится его восстанавливать из образа, созданного некоторое время назад. При восстановлении из образа есть вероятность того, что мы можем потерять нужные нам обновления (которые пришли в виде изолированных пакетов), которые устанавливались до падения машины. Объяснил максимально подробно насколько мог, потому что уточнения будут уже коммерческой тайной.

Вот поэтому и возникла идея создать программу, которая бы могла извлечь этот список обновлений (желательно удаленно по локальной сети), записать в файл/базу, сравнить текущий перечень с неким шаблоном и выдать сообщение на SCADA систему через один из протоколов — SNMP, OPC.

Как вы могли догадаться из названия статьи, уже на выборе метода получения списка у меня возникла непростая задача. Я, как обычно, решил поискать нужное в поисковике, задал вопросы на профильных ресурсах (раз, два, на английском stackoverflow почему-то не понравился мой вопрос и его пришлось удалить), но все ответы не давали нужного результата. Поэтому пришлось разбираться самому, о чем и пойдет речь далее.

Консольные команды

Начнем с простого и воспользуемся тем, что предлагает нам Windows без использования сторонних средств. Это можно сделать с помощью следующих команд:

Вывод консольной команды можно перенаправить в файл и дальше начать его парсить, но это неправильно, плюс вызов программы (по правилам СБ не пройдет) и об удаленном получении списка речь не идёт. Поэтому предлагаю вам просто вызвать команды, сравнить количество обновлений в каждом списке, со списком через Панель управления и продолжить наше расследование дальше.

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

Все методы проверялись на чистых образах систем (Windows 7, 8, Server 2012 R2) с интегрированными обновлениями, после каждого обновления через Центр обновления с официальных серверов Microsoft проводилась дополнительная проверка. Остановимся на каждом из них подробнее.

Примечание: далее для своего удобства все результаты я буду вставлять в List. Это, возможно, не рационально, но тогда мне это казалось хорошей идеей.

Есть и вторая вариация этого метода: Update Session — получение информации с помощью подключения к сессии обновления Windows Update Agent (в данном случае работаем не напрямую с библиотекой).

Microsoft подсказывает об удаленном использовании API.

Главный минусы этих двух методов — не позволяют найти исправления KB, которые не распространяются через Центр обновления Windows. Можно увидеть только то, что прошло через сам агент обновления, то есть данный вариант нас не устраивает.

Система обслуживания образов развертывания и управления ими (Deployment Image Servicing and Management) — это средство командной строки, которое может использоваться для обслуживания образа Windows или для подготовки образа среды предустановки Windows (Windows PE). Является заменой диспетчера пакетов (Pkgmgr.exe), PEimg и Intlcfg.

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

Количество обновлений совпадало с количеством из списка Панели управления до первого апдейта через центр управления — после него количество обновлений стало меньше (было 214, стало 209), хотя по логике они должны были увеличиться. Примеры вывода До обновления, После обновления.

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

Чуть позже я наткнулся на утилиту от китайцев DISM++, которая основана не на DISM API или DISM Core API, но имеющиеся в ней библиотеки не имеют нужных мне открытых методов, поэтому я забросил эту идею и продолжил поиски дальше.

Windows Server Update Services (WSUS) — сервер обновлений операционных систем и продуктов Microsoft. Сервер обновлений синхронизируется с сайтом Microsoft, скачивая обновления, которые могут быть распространены внутри корпоративной локальной сети. Опять же специальный инструмент, предназначенный для работы с обновлениями.

Распространяется только на серверных редакциях ОС Windows, поэтому был развернут следующий стенд:

Чтобы не выделять раздел жесткого диска для новой системы я пользуюсь WinNTSetup и устанавливаю систему в VHD диски — загрузчик, начиная с Windows 7 (редакций Professional/Ultimate), прекрасно справляется с загрузкой с образа диска. Полученные таким образом диски можно спокойно использовать и в Hyper-V — убиваете сразу двоих зайцев. Не забудьте только сделать заранее копию хранилища BCD через команду bcdedit /export e:\bcd_backup.bcd.

Настраивать AD для рассылки обновлений я не захотел, поэтому просто прописал в групповых политиках путь к WSUS серверу:

Обязательно уделите внимание на порт, я из-за опечатки (8350 вместо 8530) не мог получить обновления на клиентских машинах, хотя сделано было всё верно. Так же названия пунктов в групповых политиках на Windows 7 и Windows 8 различаются.

Для получения отчета средствами WSUS необходимо дополнительно установить пакет — система уведомит вас об этом.

Так как интернета нет, то ситуация с обновлениями выходит как на скриншоте ниже:

Поведение похоже на WUApi — если обновления не прошли через них, то они не знают об этом. Поэтому данный метод снова не подходит.

Windows Management Instrumentation (WMI) в дословном переводе — инструментарий управления Windows.

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

Данный метод позволяет получить данные как с локальной машины, так и удаленно в пределах локальной сети. Для обращения к объектам WMI используется специфический язык запросов WMI Query Language (WQL), который является одной из разновидностей SQL. Получать список мы будем через WMI класс win32_quickfixengineering.

Количественно всё совпадает (даже после обновлений), поэтому было решено использовать этот метод. Для программного создания WMI запросов советую использовать следующую утилиту — WMI Delphi Code Creator. Благодаря ей я немного по другому взглянул на свой код и решил использовать заготовку из этой программы.

Полученные данные методом WMI меня не остановили, и я решился на „поверхностный реверс-инжиниринг“. Воспользуемся утилитой Process Monitor из сборника программ Sysinternals Suite для выявления файлов и ветвей реестра, которые используются при вызове выше перечисленных консольных команд и обращению к пункту „Установленные обновления“ через Панель управления.

Моё внимание привлек файл wuindex.xml, расположенный в папке C:\Windows\servicing\Packages\. Для его анализа была написана следующая программа:

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

Вот мы подошли к тому, с чем связаны все эти методы. Продолжая анализ логов Process Monitor я выявил следующие папки и файлы.

Файл DataStore.edb, расположенный в папке C:\Windows\SoftwareDistribution\DataStore. Это база данных, в которой содержится история всех обновлений установленной версии Windows, включая те обновления, которые только стоят в очереди.

Для анализа файла DataStore.edb использовалась программа ESEDatabaseView. В БД существует таблица tbUpdates, содержимое которой трудно интерпретировать.

После мое внимание привлек процесс TiWorker.exe, который вызывался каждый раз при открытии пункта в Панели управления. Он „ходил“ по многим папкам, одна из которых вывела меня на верный путь.

C:\Windows\SoftwareDistribution — это папка, используемая службой обновления Windows для загрузки обновлений на компьютер с последующей их установкой, а также хранит сведения обо всех ранее установленных обновлениях.

Папка WinSxS, расположенная по адресу C:\Windows\winsxs. Это служебная папка операционной системы Windows служащая для хранения ранее установленных версий системных компонентов. Благодаря ее наличию существует возможность отката к более старой версии обновления в случае необходимости.

C:\Windows\servicing — основная составляющая всей системы, имя которой Component-Based Servicing (CBS).

CBS — обслуживание на основе компонентов, составляющая Windows, интегрированная с службой Windows Update. В противоположность обслуживанию на основе файлов File-Based Servicing (FBS) (для ОС, предшествующих Windows Vista), в котором файлы обновлялись прямо в системных директориях, в CBS появилась целая иерархия директорий и целое семейство (стек) модулей/библиотек обслуживания.

CbsApi.dll — основная библиотека поддержки технологии CBS. Не имеет открытых методов, поэтому напрямую использовать её я не смог. Microsoft использует TrustedInstaller.exe и TiWorker.exe для доступа к методам данной библиотеки и уже через эти процессы выводит нужные нам данные. ‪Записи ведутся в C:\Windows\Logs\CBS\CBS.log.

На момент создания прототипа программы (на скриншотах можете увидеть май 2019) русскоязычной информации о CBS не было, но в конце августа нашлась очень хорошая статья в блоге — http://datadump.ru/component-based-servicing. Очень интересная статья, которая подтвердила мой опыт и собрала в себе нужную информацию. И ещё по теме: http://www.outsidethebox.ms/17988/

Вывод

Microsoft слишком усложнила тривиальную задачу по получению списка обновлений и сделала этот процесс не совсем явным. Всё это сделано для безопасности, но не для простоты использования. Соглашусь с автором статьи — в получении обновлений стали отсутствовать предсказуемость и прозрачность.

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

Источник

Сведения о файле Windowsupdate.log для опытных пользователей

Версия для пользователей

Эта статья предназначена для ИТ-специалистов. В ней описывается изучение файла Windowsupdate.log для устранения неполадок Центра обновления Windows. Пользователям домашних компьютеров рекомендуется статья Средство устранения неполадок Центра обновления Windows.

Аннотация

Если при работе Центра обновления Windows (WU) появляется сообщение об ошибке, то для устранения проблемы можно воспользоваться информацией в файле журнала Windowsupdate.log.

Начиная с Windows 8.1 (в том числе и в Windows 10), клиент Центра обновления Windows создает журналы диагностики с помощью трассировки событий для Windows (ETW). Данный способ повышает эффективность и сокращает использование дискового пространства. Однако журналы доступны для чтения не сразу после записи. Чтобы читать журналы как текстовые файлы, их нужно сначала расшифровать.

Создание файла WindowsUpdate.log

Чтобы объединить и преобразовать файлы трассировки WU (ETL-файлы) в единый читаемый файл WindowsUpdate.log, см. командлет Get-WindowsUpdateLog.

Примечание. При запуске командлета Get-WindowsUpdateLog создается копияфайла WindowsUpdate.log в виде статического файла журнала. В отличие от прежнего файла WindowsUpdate.log, такой файл не обновляется автоматически: чтобы получить актуальные данные, нужно запустить командлет Get-WindowsUpdateLog еще раз.

Компоненты журнала Центра обновления Windows

У модуля WU есть различные имена компонентов. Ниже описаны самые популярные компоненты, отображаемые в файле WindowsUpdate.log:

AGENT — агент Центра обновления Windows

AU — эту задачу выполняет служба автоматических обновлений

AUCLNT — взаимодействие между AU и вошедшим в систему пользователем

CDM — диспетчер устройств

CMPRESS — агент сжатия

COMAPI — API Центра обновления Windows

DRIVER — сведения о драйвере устройства

DTASTOR — обработка транзакций базы данных

EEHNDLER — обработчик выражений, используемый для оценки пригодности обновлений

HANDLER — управляет установщиками обновлений

MISC — общая служебная информация

OFFLSNC — обнаружение доступных обновлений без подключения к сети

PARSER — анализирует сведения выражений

PT — синхронизирует сведения об обновлениях с локальным хранилищем данных

REPORT — сбор сведений отчетов

SERVICE — запуск/выключение службы автоматических обновлений

SETUP — устанавливает новые версии клиента Центра обновления Windows по мере их выхода

SHUTDWN — функция установки при выключении

WUREDIR — файлы перенаправителя Центра обновления Windows

WUWEB — элемент управления ActiveX Центра обновления Windows

ProtocolTalker — синхронизация клиент/сервер

DownloadManager — создает и отслеживает скачивание полезной нагрузки

Handler, Setup — установка обработчиков (CBS и др.)

EEHandler — оценка правил применимости обновлений

DataStore — локальное кэширование данных обновлений

IdleTimer — отслеживание активных вызовов,остановка службы

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

Структура журнала Центра обновления Windows

В структуре журнала Центра обновления Windows выделяется четыре основных обозначения:

Идентификаторы процесса и потока

Идентификатор обновления и номер редакции

Структура файла WindowsUpdate.log обсуждается в следующих разделах.

Метка времени указывает время записи в журнал.

Обычно сообщения отображаются в хронологическом порядке, но возможны исключения.

Пауза в ходе синхронизации может свидетельствовать о проблеме с сетью, даже если проверка успешно завершилась.

Длинная пауза перед окончанием проверки может указывать на проблему в цепочке замены.

Идентификаторы процесса и потока — произвольные величины, которые могут отличаться в разных журналах и даже сеансах обслуживания в рамках одного журнала.

Первые четыре шестнадцатеричных цифры — идентификатор процесса.

Следующие четыре шестнадцатеричных цифры — идентификатор потока.

У каждого из компонентов, включая USO, модули WU, вызывающие API COM, и обработчики установщиков WU, есть свои идентификаторы процессов.

Поиск и определение компонентов, связанных с идентификаторами. Различным частям модуля WU соответствуют различные имена компонентов. Некоторые из них приводятся ниже.

ProtocolTalker — синхронизация клиент/сервер

DownloadManager — создает и отслеживает скачивание полезной нагрузки

Handler, Setup — установка обработчиков (CBS и др.)

EEHandler — оценка правил применимости обновлений

DataStore — локальное кэширование данных обновлений

IdleTimer — отслеживание активных вызовов,остановка службы

Идентификатор обновления и номер редакции

У одного обновления в разных контекстах существуют различные идентификаторы. Важно знать схемы назначения идентификаторов.

«Идентификатор обновления»: GUID (указанный на предыдущем снимке экрана), который назначается тому или иному обновлению в момент публикации

«Номер редакции»: номер увеличивается каждый раз, когда то или иное обновление (с заданным идентификатором обновления) изменяется или повторно публикуется в службе

Номера редакций повторно используются для различных обновлений (не считаются уникальными идентификаторами).

Идентификатор обновления и номер редакции обычно отображаются вместе как «.редакция».

Идентификатор редакции (не путать с «номером редакции») — серийный номер, присваиваемый обновлению при первоначальной публикации или изменении в той или иной службе.

После изменения существующее обновление сохраняет свой идентификатор обновления (GUID), при этом его номер редакции увеличивается на единицу (например, со 100 до 101), а идентификатор редакции изменяется полностью и никак не соотносится с предыдущим идентификатором.

Идентификаторы редакций уникальны только в рамках одного источника обновления.

У одной и той же редакции обновления могут быть совершенно разные идентификаторы редакций в службах WU и WSUS.

При этом одинаковые идентификаторы редакций могут соответствовать разным обновлениям в службах WU и WSUS.

«Локальный идентификатор» — серийный номер, присваиваемый обновлению при получении от службы тем или иным клиентом WU.

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

Различные клиентские компьютеры могут назначать одному и тому же обновлению различные локальные идентификаторы.

Чтобы узнать локальные идентификаторы, используемые клиентом, обратитесь к файлу %WINDIR%\SoftwareDistribution\Datastore\Datastore.edb.

Иногда в журналах термины используются непоследовательно. К примеру, список «InstalledNonLeafUpdateIDs» на самом деле содержит идентификаторы редакций, а не обновлений.

Идентификаторы можно распознать по форме и контексту:

GUID — идентификаторы обновлений

Небольшие целые числа рядом с идентификаторами обновлений — номера редакций

Большие числа — это обычно идентификаторы редакций

Небольшие целые числа (особенно в хранилище данных) могут быть локальными идентификаторами

Как работает проверка Центра обновления Windows

В процессе проверки Центр обновления Windows выполняет следующий набор действий.

Когда пользователи начинают проверку в Центре обновления Windows через панель настроек, наблюдается следующее поведение:

Сначала при проверке создается сообщение «ComApi». Вызывающий (Антивирусная программа «Защитник Windows») сообщает модулю WU о необходимости выполнить проверку обновлений.

«Сообщения» агента: создание очереди проверки и ее фактический запуск:

Обновления определяются различными идентификаторами («Id = 10», «Id = 11») и различными номерами идентификаторов потока.

Чтобы сосредоточиться на конкретной задаче, WU фильтрует эти идентификаторы потока.

После начала проверки агент Центра обновления Windows создает идентификаторы службы:

они указывают, какой источник обновления проверяется.

Примечание. На следующем снимке экрана показан Центр обновления Microsoft и службы фокус-тестирования.

Модуль WU рассматривает каждую службу как отдельный объект, несмотря на то что несколько служб могут содержать одинаковые обновления.

Типовые идентификаторы служб

: файлы, устанавливаемые пользователем в беспроводном режиме

<00000000-0000-0000-0000-000000000000>: служба по умолчанию. Обычно это службы WSUS или SCCM (если они настроены) либо Центр обновления Microsoft, если выбран параметр Центр обновления Microsoft, в противном случае — Центр обновления Windows.

Часто сбой обновления происходит из-за проблем с сетью. Чтобы найти причину проблемы:

В сообщениях «ProtocolTalker» посмотрите сетевой трафик синхронизации клиент/сервер.

«Сбои SOAP» могут быть вызваны проблемами на стороне клиента или сервера; прочитайте сообщение

Для обнаружения конфигураций и конечных точек сетевых источников обновлений Microsoft — WU, MU, службы фокус-тестирования и др. — клиент WU использует службу обнаружения SLS.
Примечание. Если поиск выполняется в службах WSUS/SCCM, то предупреждающие сообщения для SLS можно не учитывать.

На сайтах, где используются только службы WSUS/SCCM, служба SLS может блокироваться на брандмауэре. В этом случае произойдет сбой запроса SLS и проверка не будет выполнена для WU/MU и др., зато будет поддерживаться для служб WSUS/SCCM благодаря локальной настройке.

Вопрос. Почему не предлагается «обновление X»?

Запишите идентификатор отсутствующего обновления (GUID).

Найдите нужное обновление с помощью поиска.

Щелкните по его названию, чтобы открыть окно информации об обновлении.

Запишите идентификатор updateid, отображаемый в строке адреса.

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

Обновление не одобрено (даже для проверки) на сервере Windows Server Update Service (WSUS).

Предварительное требование не выполнено.

Примечание. Эти условия могут возникать в WU или MU только в том случае, если обновление выдается с учетом географического положения. Для WSUS и System Center Configuration Manager данное условие требует расследования на стороне сервера.

О предварительных требованиях

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

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

Также изучите XML-файл публикации. В нем содержится идентификатор обновления и вся остальная информация, которая необходима для дальнейшего расследования этой ситуации.

Источник