Windows update что это за файл
Windows Update — что это за программа и нужна ли она?
Windows Update — программа, которая ищет, скачивает и устанавливает обновления. Все автоматически, иногда вам нужно только подтверждать установку или загрузку.
В принципе все верно, однако Windows Update — слишком общее название, чтобы говорить о чем-то конкретном. Например есть прога с похожим названием — Windows Update MiniTool, она нужна для управления обновлениями, также умеет проверять наличие, скачивать их, устанавливать, удалять установленные, скрывать нежелательные, следить за историей.
Однако чаще всего под названием Windows Update имеют ввиду именно обновления Windows.
Важные моменты
Внешний вид Windows Update
Windows Update — важная часть винды. Присутствует во всех версиях — в Windows 10, в Windows 8, семерке, и даже в XP. Скорее всего в старых он тоже был, так как обновления — очень важны. Представьте Microsoft выпускает винду, через месяц оказывается что в ней есть косяк.. как его исправить? Не переустанавливать же систему… тогда разработчики Microsoft создают обновление (заплатку) и оно через Windows Update попадает на ПК, устанавливается и исправляет косяк.
Картинка — окно Windows Update в десятке, не знаю какой билд, но думаю свежий:
Сразу лайф-хак. Чтобы запустить обновление в десятке — зажмите Win + I, далее в самом низу будет Обновление и безопасность. Нажимаете и у вас сразу появится Центр обновления Windows — нужно просто нажать Проверить наличие.
Windows Update — вообще-то Центр обновления Windows, именно так он назывался в семерке:
Если есть обновы, то будет указано сколько их, размер, в общем вся важная нужная инфа:
В семерке Центр обновления находится в панели управления. Там нужно найти значок. Кстати панель управления можно запустить так: Win + R, далее команда control или control panel (способ работает чуть ли не во всех версиях винды).
В Windows 8 все похоже:
Также находится в панели управления. И только в десятке теперь все находится в окне Параметры.
Как отключить Windows Update?
В семерке — идете в панель управления, находите значок Центр обновлений Windows, запускаете, там будет Настройка параметров:
Потом собственно отключаете:
После — нажимаете ОК.
В десятке запускаете окно Параметры (Win + I), далее в самом низу Обновление и безопасность:
Нажмите кнопку Дополнительные параметры:
Далее можете их отключить, но только временно. Используйте настройки:
Можете выставить по максимум.. потом все равно придется обновиться.
На заметку. Я кстати использую утилиту DoNotSpy10, позволяющую отключить все лишнее/ненужное в винде. Пользуюсь давно, правда у меня еще версия Windows 10 LTSB.. где по умолчанию многое отключено. Короче возможно DoNotSpy10 может сделать так, что обновления вы будете получать только тогда когда нажмете на кнопку проверки их наличия. Попробуйте, винда быстрее даже станет работать после DoNotSpy10.
В принципе если на ПК установлен мощный антивирус, версия максимальная, например Касперский, лицензия, настроен на высокую безопасность.. то я думаю с таким антивирусом обновы можно временно отложить.
Заключение
Надеюсь информация оказалась полезной. Удачи, добра, до новых встреч господа!
«Неуловимый» список установленных обновлений 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 слишком усложнила тривиальную задачу по получению списка обновлений и сделала этот процесс не совсем явным. Всё это сделано для безопасности, но не для простоты использования. Соглашусь с автором статьи — в получении обновлений стали отсутствовать предсказуемость и прозрачность.
В результате исследования была написана следующая программа, демонстрацию работы которой можно увидеть в данном видео:
Принцип работы Центра обновления Windows
Область применения
Рабочий Windows Update имеет четыре основных области функций:
Скачать
Install
Фиксация
Как работает обновление
В процессе обновления оркестратор Windows обновления работает в фоновом режиме для сканирования, скачивания и установки обновлений. Он делает эти действия автоматически, в соответствии с вашими настройками, и молча, чтобы не нарушать использование компьютера.
Сканирование обновлений
Оркестратор Windows обновления на компьютере проверяет сервер Обновления Майкрософт или конечную точку WSUS на наличие новых обновлений с случайными интервалами. Рандомизация гарантирует, что сервер Windows обновления не перегружен запросами одновременно. Оркестратор обновления ищет только обновления, которые были добавлены с момента последнего поиска обновлений, что позволяет ему быстро и эффективно находить обновления.
При проверке обновлений Windows update Orchestrator проверяет, подходит ли обновление для вашего устройства. В нем используются рекомендации, определенные издателем обновления, например, Microsoft Office политики корпоративных групп.
Убедитесь, что вы знакомы со следующей терминологией, связанной с проверкой Windows обновления:
| Термин | Определение |
|---|---|
| Обновление | Мы используем этот термин, чтобы означать несколько разных вещей, но в этом контексте это фактически обновленный код или изменение. |
| Обновление пакета | Обновление, содержаное 1-N-обновления для детей; не содержит полезной нагрузки. |
| Обновление для детей | Обновление leaf, которое в комплекте с другим обновлением; содержит полезной нагрузки. |
| Обновление детектора | Специальное «обновление» с правилом применимости «IsInstalled» и без полезной нагрузки. Используется для предварительной оценки. |
| Обновление категории | Специальный «detectoid», который имеет правило IsInstalled, которое всегда верно. Используется для группировки обновлений и позволяет устройству фильтровать обновления. |
| Полная проверка | Сканирование с пустым магазином данных. |
| Сканирование Delta | Сканирование с помощью обновлений предыдущего сканирования, которые уже кэшировали в магазине данных. |
| Сканирование в Интернете | Сканирование, использующее сеть, и проверка сервера обновления. |
| Автономное сканирование | Сканирование, которое не использует сеть, а вместо этого проверяет локальный магазин данных. Полезно только в том случае, если веб-сканирование было выполнено раньше. |
| CatScan | Сканирование категорий, в котором вызываемая может указать категориюId для получения обновлений, опубликованных в этой категорииId. |
| AppCatScan | Сканирование категорий, в котором звоняга может указать AppCategoryId для получения публикации приложений в этом appCategoryId. |
| Синхронизация программного обеспечения | Часть проверки, которая проверяется только на наличие обновлений программного обеспечения (как приложений, так и операционной системы). |
| Синхронизация драйвера | Часть проверки, которая проверяет только обновления драйвера. Эта синхронизация необязательна и выполняется после синхронизации программного обеспечения. |
| ProductSync | Синхронизация на основе атрибутов, в которых клиент заранее предоставляет список атрибутов устройства, продукта и вызываемого, чтобы позволить службе проверить применимость в облаке. |
Работа Windows обновления
Windows update выполняет следующие действия при запуске сканирования.
Запускает сканирование обновлений
Когда пользователи начинают сканировать Windows с помощью Параметры панели, возникает следующее:
Обновления идентифицированы по различным ID («ID = 10», «ID = 11») и по различным номерам нитей.
Windows Update использует фильтрацию нитей, чтобы сосредоточиться на одной конкретной задаче.
Определяет идентификаторы службы
Коды служб указывают, какой источник обновления проверяется.
Двигатель Windows обновления рассматривает каждую службу как отдельную сущность, даже несмотря на то, что несколько служб могут содержать одинаковые обновления. 
ServiceId здесь определяет абстракцию клиента, а не определенную службу в облаке. Не следует делать предположений о том, на какой сервер указывают serviceId. Он полностью контролируется откликами службы локаторов службы.
Находит ошибки в сети
Распространенный сбой обновления вызван из-за проблем с сетью. Чтобы найти корень проблемы:
Посмотрите сообщения «ProtocolTalker», чтобы увидеть сетевой трафик синхронизируются с клиентом-сервером.
«Сбои SOAP» могут быть как с клиентской, так и с серверной стороны; прочитать сообщение.
Клиент Windows обновления использует службу локаторов службы для обнаружения конфигураций и конечных точек источников обновления сети Майкрософт: Windows обновления, Обновления Майкрософт или Flighting.
Если поиск ведется в отношении WSUS или Configuration Manager, можно игнорировать предупреждающие сообщения для службы локаторов службы.
На сайтах, которые используют только WSUS или Configuration Manager, служба локаторов службы может быть заблокирована на брандмауэре. В этом случае запрос сбой, и хотя служба не может сканировать с Windows или Microsoft Update, она по-прежнему может сканировать WSUS или Configuration Manager, так как она настроена локально. 
Загрузка обновлений
После того Windows как оркестратор обновления определяет, какие обновления применяются к вашему компьютеру, он начнет скачивать обновления, если вы выбрали вариант автоматической загрузки обновлений. Он работает в фоновом режиме, не прерывая нормальное использование устройства.
Чтобы другие загрузки не пострадали или не замедлились из-за скачивания обновлений, Windows Update использует оптимизацию доставки, которая загружает обновления и снижает потребление пропускной способности.
Установка обновлений
Когда применяется обновление, загружаются «Арбитр» и метаданные. В зависимости от параметров Windows обновления, когда загрузка будет завершена, арбитр соберет сведения с устройства и сравнит их с загруженными метаданными для создания «списка действий».
В списке действий описываются все файлы, необходимые из Windows Update, и то, что должен делать с ними агент установки (например, CBS или Setup). Список действий предоставляется агенту установки вместе с полезной нагрузкой для начала установки.
Совершение обновлений
При настройке параметра автоматической установки обновлений оркестратор обновления Windows в большинстве случаев автоматически перезапускает устройство для вас после установки обновлений. Оно должно перезапустить устройство, так как оно может быть небезопасным или не полностью обновлено, пока оно не перезапустится. Параметры групповой политики, управление мобильными устройствами (MDM) или реестр (не рекомендуется) можно настроить, когда устройства будут перезапущены после установки Windows 10 обновления.
Сведения о файле 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-файл публикации. В нем содержится идентификатор обновления и вся остальная информация, которая необходима для дальнейшего расследования этой ситуации.