Provide feedback
Saved searches
Use saved searches to filter your results more quickly
Sign up
Appearance settings
Вы когда-нибудь задумывались, с помощью чего формируется список установленных обновлений Windows? А через какое API его достать? Ответы на эти и другие возникающие вопросы я постараюсь дать в своём небольшом исследовании.
Предыстория или с чего всё началось.
В нашей компании каждый год проходит конференция молодых специалистов, где каждый участник может решить проблему какого-либо отдела (список тем заранее предлагается).
Раньше на каждое «ТО» с помощью WSUS подтягивались все выпущенные обновления и распространялись на все машины. Также периодически выходили ТСБ (технические сервисные бюллетени), в которых указывалось, что требуется установить необходимые обновления в виде изолированных пакетов. В итоге у нас накапливаются обновления, которые в WSUS отследить нельзя, а можно было увидеть только через панель управления в разделе «Установленные обновления».
Бывают ситуации, когда АРМ или сервер «падает» и приходится его восстанавливать из образа, созданного некоторое время назад. При восстановлении из образа есть вероятность того, что мы можем потерять нужные нам обновления (которые пришли в виде изолированных пакетов), которые устанавливались до падения машины. Объяснил максимально подробно насколько мог, потому что уточнения будут уже коммерческой тайной.
Вот поэтому и возникла идея создать программу, которая бы могла извлечь этот список обновлений (желательно удаленно по локальной сети), записать в файл/базу, сравнить текущий перечень с неким шаблоном и выдать сообщение на SCADA систему через один из протоколов — SNMP, OPC.
Как вы могли догадаться из названия статьи, уже на выборе метода получения списка у меня возникла непростая задача. Я, как обычно, решил поискать нужное в поисковике, задал вопросы на профильных ресурсах (раз, два, на английском stackoverflow почему-то не понравился мой вопрос и его пришлось удалить), но все ответы не давали нужного результата. Поэтому пришлось разбираться самому, о чем и пойдет речь далее.
Консольные команды
Начнем с простого и воспользуемся тем, что предлагает нам Windows без использования сторонних средств. Это можно сделать с помощью следующих команд:
- wmic qfe list
- systeminfo
- dism /online /get-packages
- через PowerShell:
- Get-HotFix
- Get-SilWindowsUpdate (доступно только в серверных редакциях)
- Get-WmiObject -Class win32_quickfixengineering — через доступ к WMI классу win32_quickfixengineering (о WMI чуть позже)
Получить список через графический интерфейс можно через стандартный пункт Панели управления «Установка/удаление программ», но скопировать оттуда мы ничего не можем. Каждый инструмент панели управления представлен файлом .cpl в папке Windows\System. Файлы .cpl в системную папку Windows автоматически загружаются при запуске панели управления. За пункт Программы отвечает файл Appwiz.cpl. Его анализ ни к чему не привел.
Вывод консольной команды можно перенаправить в файл и дальше начать его парсить, но это неправильно, плюс вызов программы (по правилам СБ не пройдет) и об удаленном получении списка речь не идёт. Поэтому предлагаю вам просто вызвать команды, сравнить количество обновлений в каждом списке, со списком через Панель управления и продолжить наше расследование дальше.
Формально все методы получения списка обновлений можно разделить на две группы: локальные и сетевые.
Все методы проверялись на чистых образах систем (Windows 7, 8, Server 2012 R2) с интегрированными обновлениями, после каждого обновления через Центр обновления с официальных серверов Microsoft проводилась дополнительная проверка. Остановимся на каждом из них подробнее.
WUA
WUApi (Windows Update Agent API) — использование API агента обновления Windows. Самый явный вариант, название которого говорит само за себя. Использовать для этого будем библиотеку Wuapi.dll.
Примечание: далее для своего удобства все результаты я буду вставлять в List. Это, возможно, не рационально, но тогда мне это казалось хорошей идеей.
Пример реализации
using WUApiLib;
public static List<string> listUpdateHistory()
{
//WUApi
List<string> result = new List<string>(200);
try
{
UpdateSession uSession = new UpdateSession();
IUpdateSearcher uSearcher = uSession.CreateUpdateSearcher();
uSearcher.Online = false;
ISearchResult sResult = uSearcher.Search("IsInstalled=1 And IsHidden=0");
string sw = "Количество обновлений через WUApi: " + sResult.Updates.Count;
result.Add(sw);
foreach (WUApiLib.IUpdate update in sResult.Updates)
{
result.Add(update.Title);
}
}
catch (Exception ex)
{
result.Add("Что-то пошло не так: " + ex.Message);
}
return result;
}
Есть и вторая вариация этого метода: Update Session — получение информации с помощью подключения к сессии обновления Windows Update Agent (в данном случае работаем не напрямую с библиотекой).
Пример реализации
public static List<string> Sessionlist(string pc)
{
List<string> result = new List<string>(50); //не забудь изменить количество
object sess = null;
object search = null;
object coll = null;
try
{
sess = Activator.CreateInstance(Type.GetTypeFromProgID("Microsoft.Update.Session", pc));
search = (sess as dynamic).CreateUpdateSearcher();
int n = (search as dynamic).GetTotalHistoryCount();
int kol = 0;
//coll = (search as dynamic).QueryHistory(1, n);
coll = (search as dynamic).QueryHistory(0, n);
result.Add("Количество через Update.Session: " + n);
foreach (dynamic item in coll as dynamic)
{
if (item.Operation == 1) result.Add(item.Title);
kol++;
//Console.WriteLine("Количество: " + kol);
}
result.Add("Количество в цикле: " + kol);
}
catch (Exception ex)
{
result.Add("Что-то пошло не так: " + ex.Message);
}
finally
{
if (sess != null) Marshal.ReleaseComObject(sess);
if (search != null) Marshal.ReleaseComObject(search);
if (coll != null) Marshal.ReleaseComObject(coll);
}
return result;
}
Microsoft подсказывает об удаленном использовании API.
Главный минусы этих двух методов — не позволяют найти исправления KB, которые не распространяются через Центр обновления Windows. Можно увидеть только то, что прошло через сам агент обновления, то есть данный вариант нас не устраивает.
DISM
Система обслуживания образов развертывания и управления ими (Deployment Image Servicing and Management) — это средство командной строки, которое может использоваться для обслуживания образа Windows или для подготовки образа среды предустановки Windows (Windows PE). Является заменой диспетчера пакетов (Pkgmgr.exe), PEimg и Intlcfg.
Данная утилита используется для интеграции обновлений, сервис паков в образ системы. Обновления Windows представляют собой отдельные модули, которые могут быть представлены в нескольких вариантах:
- .cab-файлы (Cabinet) — архивы. Предназначены для распространения и установки при помощи модулей Центра обновлений Windows в автоматизированном режиме;
- .msu-файлы (Microsoft Update Standalone Package) — исполняемые файлы. Предназначены для распространения и установки самими пользователями в ручном режиме через каталог обновлений Microsoft. Фактически представляют собой упакованный набор, состоящий из .cab-, .xml, .txt-файлов.
Ранее упомянутая команда dism /online /get-packages отображает основную информацию обо всех пакетах в wim образе/текущей системе. Microsoft позаботилась о нас и предоставляет NuGet packages для удобного использования API.
Пример реализации
using Microsoft.Dism;
public static List<string> DISMlist()
{
List<string> result = new List<string>(220);
try
{
DismApi.Initialize(DismLogLevel.LogErrors);
var dismsession = DismApi.OpenOnlineSession();
var listupdate = DismApi.GetPackages(dismsession);
int ab = listupdate.Count;
//Console.WriteLine("Количество обновлений через DISM: " + ab);
string sw = "Количество обновлений через DISM: " + ab;
result.Add(sw);
foreach (DismPackage feature in listupdate)
{
result.Add(feature.PackageName);
//result.Add($"[Имя пакета] {feature.PackageName}");
//result.Add($"[Дата установки] {feature.InstallTime}");
//result.Add($"[Тип обновления] {feature.ReleaseType}");
}
}
catch (Exception ex)
{
result.Add("Что-то пошло не так: " + ex.Message);
}
return result;
}
Количество обновлений совпадало с количеством из списка Панели управления до первого апдейта через центр управления — после него количество обновлений стало меньше (было 214, стало 209), хотя по логике они должны были увеличиться. Примеры вывода До обновления, После обновления.
С чем это связано я могу только предполагать — возможно, какие-то обновления замещали предыдущие, следовательно, и количество стало меньше.
Чуть позже я наткнулся на утилиту от китайцев DISM++, которая основана не на DISM API или DISM Core API, но имеющиеся в ней библиотеки не имеют нужных мне открытых методов, поэтому я забросил эту идею и продолжил поиски дальше.
WSUS
Windows Server Update Services (WSUS) — сервер обновлений операционных систем и продуктов Microsoft. Сервер обновлений синхронизируется с сайтом Microsoft, скачивая обновления, которые могут быть распространены внутри корпоративной локальной сети. Опять же специальный инструмент, предназначенный для работы с обновлениями.
Распространяется только на серверных редакциях ОС Windows, поэтому был развернут следующий стенд:
- основная система – Windows Server 2016;
- а через систему виртуализации Hyper-V были развернуты две клиентские ОС:
- Windows 8.1
- Windows 7
Все системы соединены в единую виртуальную локальную сеть, но
без выхода в сеть Интернет
.
Немного советов
Чтобы не выделять раздел жесткого диска для новой системы я пользуюсь WinNTSetup и устанавливаю систему в VHD диски — загрузчик, начиная с Windows 7 (редакций Professional/Ultimate), прекрасно справляется с загрузкой с образа диска. Полученные таким образом диски можно спокойно использовать и в Hyper-V — убиваете сразу двоих зайцев. Не забудьте только сделать заранее копию хранилища BCD через команду bcdedit /export e:\bcd_backup.bcd.
Настраивать AD для рассылки обновлений я не захотел, поэтому просто прописал в групповых политиках путь к WSUS серверу:
Обязательно уделите внимание на порт, я из-за опечатки (8350 вместо 8530) не мог получить обновления на клиентских машинах, хотя сделано было всё верно. Так же названия пунктов в групповых политиках на Windows 7 и Windows 8 различаются.
Для получения отчета средствами WSUS необходимо дополнительно установить пакет — система уведомит вас об этом.
А теперь немного кода
//не забудьте добавить ссылку на библиотеку
using Microsoft.UpdateServices.Administration;
public static List<string> GetWSUSlist(params string[] list)
{
List<string> result = new List<string>(200); //не забудь изменить количество
string namehost = list[0]; //имя Пк, на котором будем искать string = "example1";
string servername = list[1]; //имя сервера string = "WIN-E1U41FA6E55";
string Username = list[2];
string Password = list[3];
try
{
ComputerTargetScope scope = new ComputerTargetScope();
IUpdateServer server = AdminProxy.GetUpdateServer(servername, false, 8530);
ComputerTargetCollection targets = server.GetComputerTargets(scope);
// Search
targets = server.SearchComputerTargets(namehost);
// To get only on server FindTarget method
IComputerTarget target = FindTarget(targets, namehost);
result.Add("Имя ПК: " + target.FullDomainName);
IUpdateSummary summary = target.GetUpdateInstallationSummary();
UpdateScope _updateScope = new UpdateScope();
// See in UpdateInstallationStates all other properties criteria
//_updateScope.IncludedInstallationStates = UpdateInstallationStates.Downloaded;
UpdateInstallationInfoCollection updatesInfo = target.GetUpdateInstallationInfoPerUpdate(_updateScope);
int updateCount = updatesInfo.Count;
result.Add("Кол -во найденных обновлений - " + updateCount);
foreach (IUpdateInstallationInfo updateInfo in updatesInfo)
{
result.Add(updateInfo.GetUpdate().Title);
}
}
catch (Exception ex)
{
result.Add("Что-то пошло не так: " + ex.Message);
}
return result;
}
public static IComputerTarget FindTarget(ComputerTargetCollection coll, string computername)
{
foreach (IComputerTarget target in coll)
{
if (target.FullDomainName.Contains(computername.ToLower()))
return target;
}
return null;
}
Так как интернета нет, то ситуация с обновлениями выходит как на скриншоте ниже:
Поведение похоже на WUApi — если обновления не прошли через них, то они не знают об этом. Поэтому данный метод снова не подходит.
WMI
Windows Management Instrumentation (WMI) в дословном переводе — инструментарий управления Windows.
WMI — реализованный корпорацией Майкрософт стандарт управления предприятием
через Интернет
для централизованного администрирования и слежения за работой различных частей компьютерной инфраструктуры под управлением платформы Windows. WMI является открытой унифицированной системой интерфейсов доступа к любым параметрам операционной системы, устройствам и приложениям, которые функционируют в ней.
Данный метод позволяет получить данные как с локальной машины, так и удаленно в пределах локальной сети. Для обращения к объектам WMI используется специфический язык запросов WMI Query Language (WQL), который является одной из разновидностей SQL. Получать список мы будем через WMI класс win32_quickfixengineering.
Пример реализации
using System.Management;
public static List<string> GetWMIlist(params string[] list)
{
List<string> result = new List<string>(200); //не забудь изменить количество
ManagementScope Scope;
string ComputerName = list[0];
string Username = list[1];
string Password = list[2];
int kol = 0;
if (!ComputerName.Equals("localhost", StringComparison.OrdinalIgnoreCase))
{
// Возвращает или задает полномочия, которые используются для проверки подлинности
// указанного пользователя.
ConnectionOptions Conn = new ConnectionOptions();
Conn.Username = Username;
Conn.Password = Password;
//Если значение свойства начинается со строки «NTLMDOMAIN:» аутентификация NTLM будет использоваться, и свойство должно содержать доменное имя NTLM.
Conn.Authority = "ntlmdomain:DOMAIN";
Scope = new ManagementScope(String.Format("\\\\{0}\\root\\CIMV2", ComputerName), Conn);
}
else
Scope = new ManagementScope(String.Format("\\\\{0}\\root\\CIMV2", ComputerName), null);
try
{
Scope.Connect();
ObjectQuery Query = new ObjectQuery("SELECT * FROM Win32_QuickFixEngineering");
ManagementObjectSearcher Searcher = new ManagementObjectSearcher(Scope, Query);
foreach (ManagementObject WmiObject in Searcher.Get())
{
result.Add(WmiObject["HotFixID"].ToString());
//Console.WriteLine("{0,-35} {1,-40}", "HotFixID", WmiObject["HotFixID"]);// String
//result.Add();
/*result.Add("{0,-17} {1}", "Тип обновления: ", WmiObject["Description"]);
result.Add("{0,-17} {1}", "Ссылка: ", WmiObject["Caption"]);
result.Add("{0,-17} {1}", "Дата установки: ", WmiObject["InstalledOn"]);*/
kol++;
}
result.Add("Количество равно " + kol);
}
catch (Exception ex)
{
result.Add("Что-то пошло не так: " + ex.Message);
}
return result;
}
Количественно всё совпадает (даже после обновлений), поэтому было решено использовать этот метод. Для программного создания WMI запросов советую использовать следующую утилиту — WMI Delphi Code Creator. Благодаря ей я немного по другому взглянул на свой код и решил использовать заготовку из этой программы.
XML
Полученные данные методом WMI меня не остановили, и я решился на „поверхностный реверс-инжиниринг“. Воспользуемся утилитой Process Monitor из сборника программ Sysinternals Suite для выявления файлов и ветвей реестра, которые используются при вызове выше перечисленных консольных команд и обращению к пункту „Установленные обновления“ через Панель управления.
Моё внимание привлек файл wuindex.xml, расположенный в папке C:\Windows\servicing\Packages\. Для его анализа была написана следующая программа:
Пример консольного приложения
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Xml;
using System.Text.RegularExpressions;
using System.IO;
namespace XMLviewer
{
class Program
{
static void Main(string[] args)
{
string writePath = AppDomain.CurrentDomain.BaseDirectory + "XML Обновлений " + Environment.MachineName + ".txt";
if (!File.Exists(writePath))
{
Console.WriteLine("Создаю пустой txt файл");
}
else
{
Console.WriteLine("Файл XML Обновлений.txt существует, он будет перезаписан");
File.Delete(writePath);
}
//регулярное выражение для поиска по маске KB
Regex regex = new Regex(@"KB[0-9]{6,7}");
//Regex(@"(\w{2}\d{6,7}) ?");
//SortedSet не поддерживает повторяющиеся элементы, поэтому повторяющиеся элементы мы "группируем" ещё на стадии добавления
SortedSet<string> spisok = new SortedSet<string>();
XmlDocument xDoc = new XmlDocument();
string path = "C:\\Windows\\servicing\\Packages\\wuindex.xml"; //путь до нашего xml
xDoc.Load(path);
int kol = 0; //кол-во компонентов
int total = 0; //кол-во дочерних элементов в xml
int total2 = 0; //кол-во полученных обновлений
XmlNodeList name = xDoc.GetElementsByTagName("Mappings");
foreach (XmlNode xnode in name)
{
//Console.WriteLine(xnode.Name);
kol++;
XmlNode attr = xnode.Attributes.GetNamedItem("UpdateId");
//Console.WriteLine(attr.Value);
foreach (XmlNode childnode in xnode.ChildNodes)
{
XmlNode childattr = childnode.Attributes.GetNamedItem("Package");
total++;
//Console.WriteLine(childattr.Value);
MatchCollection matches = regex.Matches(childattr.Value);
if (matches.Count > 0)
{
foreach (Match match in matches)
//Console.WriteLine(match.Value);
spisok.Add(match.Value);
}
else
{
//Console.WriteLine("Совпадений не найдено");
}
}
}
try
{
StreamWriter sw = new StreamWriter(writePath);
foreach (string element in spisok)
{
//Console.WriteLine(element);
sw.WriteLine(element);
total2++;
}
sw.Close();
}
catch (Exception ex)
{
Console.WriteLine("Ошибка: " + ex.Message);
}
//Console.WriteLine("\n");
Console.WriteLine("Количество пакетов: " +kol);
Console.WriteLine("Количество дочерних элементов в xml: " + total);
Console.WriteLine("Количество KB обновлений: " + total2);
Console.WriteLine("Нажмите любую клавишу для выхода.");
Console.Read();
}
}
}
К сожалению, данный файл встречается не на всех системах и принцип его генерирования и обновления остался для меня загадкой. Поэтому снова данный метод нам не подходит.
CBS
Вот мы подошли к тому, с чем связаны все эти методы. Продолжая анализ логов 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 слишком усложнила тривиальную задачу по получению списка обновлений и сделала этот процесс не совсем явным. Всё это сделано для безопасности, но не для простоты использования. Соглашусь с автором статьи — в получении обновлений стали отсутствовать предсказуемость и прозрачность.
В результате исследования была написана следующая программа, демонстрацию работы которой можно увидеть в данном видео:
В планах дописать:
- сравнение списка необходимых обновлений с полученным;
- передать результат по протоколу SNMP/OPC (если у кого есть опыт поделитесь в комментариях);
- организовать установку недостающих „офлайн“ обновлений из указанной папки.
Если вы знаете ещё методы получения списка не только обновлений, но и дополнительных компонентов (Adobe Flash, Acrobat Reader и т.д.) или у вас есть другие интересные предложения, напишите об этом в комментариях или в личные сообщения — буду рад любой обратной связи. И поучаствуйте в опросе к данной статье — так я буду знать, будет ли интересен мой опыт аудитории Habrahabr.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Продолжить тему о том, как всем этим управлять через SNMP/OPC?
11.85% Нет, не интересно16
17.04% Бессмысленное занятие, займись лучше другим23
Проголосовали 135 пользователей. Воздержались 50 пользователей.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
И пользуясь случаем ещё один опрос: рассказать про ЕГИССО — что это какое, как мучаются люди и что люди разрабатывают, чтобы с этим работать?
78.4% Интересно прочитать про ужасы от Пенсионного фонда (Да)98
21.6% Спасение утопающих — дело рук самих утопающих (Нет)27
Проголосовали 125 пользователей. Воздержались 44 пользователя.
- Forum
- Windows Programming
- Windows Update Agent API in C++
Windows Update Agent API in C++
Hi Everyone,
After exploring the various ways, I have found “Windows Update Agent API” is the better way to collect windows update information from any Windows OS post Windows 2000 SP3.
I have created a win32 console application in C++ to collect the windows update info with below mentioned approach.
1.Initialize COM.
2.Get Handle to Windows Update Session.
3.Create an Update Searcher (Used IUpdateSearcher interface).
4.Perform search with the search criteria “IsInstalled=1 or IsHidden=1 or IsPresent=1”. Here I am getting the results of both type “Software” and “Driver”.
5.Iterate through results.
6.Cleanup memory allocated to objects and Uninitialize COM.
Following are the results I have observed while testing the console application with Administrator previleges:
1.In Windows XP 64 bit, WUA API is returning less results when compared to “WMIC QFE GET”
2.In Windows Vista, WUA API is not returning any results.
3.In Windows 7, 2008, WUA API is returning more results than WMIC QFE GET.
I have taken the approach of using WUA API when compared to querying the “Win32_QuickFixEngineering” class with WMI because the latter gives the update entries that are updated with Component Based Servicing.
Could you please answer the following queries:
1.Are there any errors in my approach to retrieve the update information?
2.Could you please point to some good articles/information about using WUA API?
3.Are there any specific settings that need to be taken care in programming based on OS flavour?
4.Is there any specific build process with respect to 32 bit and 64 bit machines separately?
5.Should “Windows Update” service be mandatory enabled to run the WUA API code?
I have copied the sample code I am using. This code is written to collect the KB Numbers of installed updates:
|
|
Could someone please reply?
Topic archived. No new replies allowed.
It has become imperative for businesses to prioritize the security of their IT infrastructure. One of the foundational elements of this is ensuring that computers, and servers systems remain updated with the latest security patches. A significant proportion of cyberattacks exploit known vulnerabilities or flaws for which patches or fixes are already available.
For many acceptable reasons, specially in large company IT infrastructure, patch management solution like Microsoft WSUS, SCCM or Qualys for exemple, might not successfully patch all computers/servers in a requested short time (discovery issues, communication issues, client health, etc…). To fill this gap, IT Services might consider to create a parallele solution to patch faulty computers or servers. Windows Powershell can help to design your own patching process where the patch managment solution in place does not succeed.
On a Windows machine, computer or server, Windows OS give the ability to exploit the Windows Update Agent (WUA) through the Win32 WUA API. In PowerShell The WUA API can be accessed using Component Object Model interface (COM Objects) referered in Wuapi.dll.
Search Missing Windows Updates using ComObject
First of all, we need to create an Update Session, to do so let’s create a « Microsoft.Update.Session » COM Object inside a variable, and explore his members :
$objSession = New-Object -ComObject "Microsoft.Update.Session"
$objSession | Get-Member
Name MemberType Definition
---- ---------- ----------
CreateUpdateDownloader Method IUpdateDownloader CreateUpdateDownloader ()
CreateUpdateInstaller Method IUpdateInstaller CreateUpdateInstaller ()
CreateUpdateSearcher Method IUpdateSearcher CreateUpdateSearcher ()
CreateUpdateServiceManager Method IUpdateServiceManager2 CreateUpdateServiceManager ()
QueryHistory Method IUpdateHistoryEntryCollection QueryHistory (string criteria, int startIndex, int Count)
ClientApplicationID Property string ClientApplicationID () {get} {set}
ReadOnly Property bool ReadOnly () {get}
UserLocale Property uint UserLocale () {get} {set}
WebProxy Property IWebProxy WebProxy () {get} {set}
As we can see we get access to diferent usefull methods and properties.
Create your Update Searcher
We will use our initial Com Object « Microsoft.Update.Session » defined in $objSession, and call the method CreateUpdateSearcher(). This method will create an instance of object of type IUpdateSearcher.
$objSearcher = $objSession.CreateUpdateSearcher()
$objSearcher | Get-Member
Name MemberType Definition
---- ---------- ----------
BeginSearch Method ISearchJob BeginSearch (string criteria, IUnknown onCompleted, Variant state)
EndSearch Method ISearchResult EndSearch (ISearchJob searchJob)
EscapeString Method string EscapeString (string unescaped)
GetTotalHistoryCount Method int GetTotalHistoryCount ()
QueryHistory Method IUpdateHistoryEntryCollection QueryHistory (int startIndex, int Count)
Search Method ISearchResult Search (string criteria)
CanAutomaticallyUpgradeService Property bool CanAutomaticallyUpgradeService () {get} {set}
ClientApplicationID Property string ClientApplicationID () {get} {set}
IgnoreDownloadPriority Property bool IgnoreDownloadPriority () {get} {set}
IncludePotentiallySupersededUpdates Property bool IncludePotentiallySupersededUpdates () {get} {set}
Online Property bool Online () {get} {set}
SearchScope Property SearchScope SearchScope () {get} {set}
ServerSelection Property ServerSelection ServerSelection () {get} {set}
ServiceID Property string ServiceID () {get} {set}
Set properties to configure the behavior of your searcher
Now that we have an instance of IUpdateSearcher we have to configure diferent properties to control behavior of the searcher. In our case we need to set up the following properties with Int32 values.
ServerSelection => To determine where the updates are sourced from
The ServerSelection enumeration defines values that describe the type of server to use for an update search operation.
Here are the possible values for ServerSelection
:
- 0 (ssDefault): Search the default server for updates.
- 1 (ssManagedServer): Search only the managed server for updates, such as a Windows Server Update Services (WSUS) server that’s set up in an enterprise environment to distribute updates.
- 2 (ssWindowsUpdate): Search the Windows Update service over the Internet.
- 3 (ssOthers): Search another server, to be specified by other means.
In our case we will set the ServerSelection to 3 (ssOthers) in order to exclude the default server type, managed server type, and Windows Update service, in order to use the Microsoft Update service (which is not defined by a specific value).
$objSearcher.ServerSelection = 3
ServiceID => Represents a unique identifier (GUID) for the update service
With this property we can define which update service we want to use for the search. An update service is defined by his GUID. Basically the commonly used update services are :
- Windows Update: Windows Update service provide only Windows system patchs. The service will pull updates directly from internet. His GUID is consistent from Microsoft across all systems : 9482f4b4-e343-43b6-b170-9a65bc822c77
- Microsoft Update: Microsoft Update cover a larger scope whithin Windows system and Microsoft products such as Microsoft Office, Microsoft SQL server, etc… The service trigger the pull from Internet. His GUID is consistent from Microsoft across all systems : 7971f918-a847-4430-9279-4a52d1efe18d
- Windows Server Update Services (WSUS): If an enterprise has set up its own WSUS server, then the ServiceID would correspond to that WSUS instance. Each WSUS instance would typically have its own unique GUID.
In our case we will use the Microsoft Update service which provide us the most large scope of updates (Windows system, Office, etc…).
$objSearcher.ServiceID = '7971f918-a847-4430-9279-4a52d1efe18d'
Start searching missing updates
Now that our searcher is configured, we can start the search of update whith criterias.
As we saw above, the searcher object have a method called « Search ». This Search method accept criteria as filter to define which update you are looking for. Here is an exemple of search criteria to use for searching security updates that are not installed on the system :
$criteria = "IsInstalled=0 and Type='Software' and CategoryIDs contains '0fa1201d-4330-4fa8-8ae9-b877473b6441'"
The syntax used is similar to SQL, where you can define condition and logical operations. In this example we define not yet installed updates with "IsInstalled=0"
of type software "Type='Software'"
as opposed to driver updates, which would use Type='Driver'
. We filter the type of update with category ID '0fa1201d-4330-4fa8-8ae9-b877473b6441'
which correspond to Secrurity category update. You can find more details about types and categories classification with GUID on Microsoft online documentation.
Let’s start the search whitin a new variables that we will call $missingUpdates :
$missingUpdates = $objSearcher.Search($criteria)
After the search made, if updates are found, you will get a collection of updates returned by the service provider (Microsoft Udpdate in our case).
For example, here is an overview of an update object returned :
Title : Intel Corporation - Sensor - 5/10/2016 12:00:00 AM - 3.0.40.3258
AutoSelectOnWebSites : False
BundledUpdates : System.__ComObject
CanRequireSource : False
Categories : System.__ComObject
Deadline :
DeltaCompressedContentAvailable : False
DeltaCompressedContentPreferred : True
Description : Intel Corporation Sensor driver update released in May 2016
EulaAccepted : True
EulaText :
HandlerID : http://schemas.microsoft.com/msus/2002/12/UpdateHandlers/WindowsDriver
Identity : System.__ComObject
Image :
InstallationBehavior : System.__ComObject
IsBeta : False
IsDownloaded : False
IsHidden : False
IsInstalled : False
IsMandatory : False
IsUninstallable : False [...]
Install missing updates
Now that we get a collection of missing updates in our system, let’s see how we can install them to patch our computer. To do so, we need to introduce two new type of COM objects which are UpdateCollection
and IUpdateInstaller
. The UpdateCollection
object represents a collection of IUpdate
objects, essentially acting as a container to hold updates that you might want to download or install programmatically. The IUpdateInstaller
will give the ability to proceed to the installation of a specified updates collection set.
Let’s create an Update Collection inside a new variable and add on it our missing updates :
$updateCollection = New-Object -ComObject "Microsoft.Update.UpdateColl"
$missingUpdates.Updates | ForEach-Object { $updateCollection.Add($_) }
Our container is now ready…let’s create the installer using the initial session object, and inject it our update collection
$updateInstaller = $objSession.CreateUpdateInstaller()
$updateInstaller.Updates = $updateCollection
We can now start the installation :
$resultInstall = $updateInstaller.Install()
#Control the result of the installation
if ($installResult.ResultCode -eq 2) {
Write-Output "Updates installed successfully."
} else {
Write-Output "There was an issue installing the updates."
}
We’ve learned how to use Powershell and the Windows Update API to search an install missing windows updates.
I’ve made a Powershell module easy to use to help you to exploit the Windows Update Agent API, you can download it on github on following project : Powershell WUA.
Во второй половине прошлого месяца Microsoft выпустила обновление KB5039302 для Windows 11, представляющее собой необязательное обновление, не связанное с безопасностью. К сожалению, это обновление вызвало значительные проблемы как для пользователей, так и для ИТ-администраторов. От сбоев панели задач до системных аварий, KB5039302 стало настоящей головной болью для многих.
Новая проблема с Windows Update Agent API
Добавляя к списку проблем, Microsoft подтвердила еще одну проблему с Windows Update Agent API (WUA). Согласно официальной документации, KB5039302 может нарушить работу скриптов PowerShell или VBScript, использующих API, что приводит к пустым результатам запросов для определенных объектов и ошибке с кодом 0x8002802B “TYPEEELEMENTNOTFOUND.”
Этот баг специально затрагивает клиентские версии Windows 11, такие как 22H2 и 23H2, в то время как серверные издания остаются незатронутыми. Однако обычные домашние пользователи и организации с автоматическими обновлениями Windows не должны беспокоиться об ошибке 0x8002802B.
Использование Known Issue Rollback
Для решения этой проблемы Microsoft использовала функцию Known Issue Rollback (KIR). Хотя эта функция обычно решает проблемы бесшовно, ИТ-администраторам может понадобиться внедрить специальные групповые политики для устранения конкретных проблем, таких как ошибка 0x8002802B. Необходимую политику можно найти здесь, и она требует перезагрузки затронутых устройств и отмены изменений, вызывающих проблему.
Эта проблема решается с использованием Known Issue Rollback (KIR). ИТ-администраторы могут решить эту проблему, установив и настроив специальную групповую политику, указанную ниже. Специальная групповая политика находится в разделе Конфигурация компьютера -> Административные шаблоны -> .
Для получения информации о развертывании и настройке этих специальных групповых политик, пожалуйста, смотрите Как использовать групповую политику для развертывания Known Issue Rollback.
Скачивания групповой политики с именем групповой политики:
Для получения более подробной информации о последней известной ошибке в обновлениях Windows 11 за июнь 2024 года, не связанных с безопасностью, пожалуйста, обратитесь к официальной документации Microsoft.