Не обновляется Windows Server, алгоритм действий

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

Список ошибок при попытке установить обновления на Windows Server 2022

Анализируя отчеты по уязвимостям меня привлек сервер у которого их оказалось 1002 штуки. Мне стало любопытно почему так, думал может быть еще не было перезагрузки, после того как SCCM накатил месячный пакет, но оказалось, что время работы сервера было небольшим, и свежих обновлений не было. Я стал копаться дальше.

Первое, что вы должны сделать это обратиться к логам Windows Server 2022, а конкретно журнал "Setup (Установка)". Там я обнаружил такие события и ошибки:

Event ID 1: Initiating changes for package KB5063880. Current state is Absent. Target state is Installed. Client id: WindowsUpdateAgent.

Event ID 3: Package KB5063880 failed to be changed to the Installed state. Status: 0x8007000d.

Было много предупреждений, что повреждено хранилище компонентов.

ID 1015: 0 of 14 instances of system store corruption have been repaired. Unrepaired corruptions may lead to failures in future system servicing.

Иван, тогда какие есть причины этих ошибок?

Из основных причин такого поведения Windows Server я могу выделить:

✅Повреждение системных файлов и хранилища компонентов

✅Много мусора от старых установочных пакетов

✅Старые артефакты при миграции с Windows Server 2019 и ниже до Windows Server 2022, путем обновления поверх

✅Проблема со службой обновления и ее компонентами

✅Нехватка дискового пространства

✅Антивирусные решения

✅Ваша карма 😅

Какой алгоритм действий по устранению?

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

Простая перезагрука сервера

В своей практике я не перестаю повторять сложившуюся поговорку, которая в случае операционных систем Windows может все починить:

Семь бед, один ресет

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

Установка обновления в ручном режиме

Если по каким-то причинам у вас не смогло установиться обновление, попавшее через "Центр обновления Windows", то я всегда советую попробовать установить его вручную, в большинстве случаев это помогает, если только нет серьезных повреждений в системе. У компании Microsoft есть отдельный сервис-каталог, где вы можете найти практически, что угодно, главное знать номер нужной KB либо семейство вашей ОС.

https://www.catalog.update.microsoft.com/

В поисковой строке введите либо нужный вам пакет, у меня это сентябрьское накопительное обновление KB5065432, либо введите искомый продукт, например Microsoft server operating system version 21H2. Далее просто нажмите загрузить.

На выходе у вас получиться пакетwindows10.0-kb5065432-x64_a714744bd7eedbcc58a38130e1307fb4c7fa020b.msu. На нужном сервере просто запустите его. Согласитесь с установкой пакета, нажав "Yes".

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

Если хотите отслеживать, что конкретно происходит при данной установке пакета, то запустите Resource Monitor, перейдя на вкладку диска. Тут должно быть много обращений и записей к WinSxS папке.

В 99% случаев это всегда работает, но это был не он 🙂 У меня появилось окно с ошибкой:

Some updates were not installed

С чего начинать диагностику проблем по установке обновлений в Windows

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

CBS.log — это один из ключевых журналов Windows для диагностики проблем с целостностью системы и установкой обновлений.

CBS расшифровывается как Component-Based Servicing (Компонентное обслуживание). Это подсистема Windows, которая отвечает за установку, обновление и восстановление критически важных компонентов системы. По сути это подробный текстовый журнал, в который подсистема CBS записывает все свои действия и ошибки.

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

• Какие файлы проверяются.
• Какие файлы заменяются.
• Какие обновления загружаются и устанавливаются.
• С какими ошибками процесс столкнулся и на каком именно этапе.

Где находится CBS.log и пример анализа?

Операционная система Windows Server по традиции все файлы с логами хранит в папке Windows и CBS.log не исключение.

C:\Windows\Logs\CBS\CBS.log

Из-за постоянной работы системы этот файл может становиться очень большим. Чтобы управлять его размером, Windows периодически создает его сжатые архивные копии в той же папке с именами CBS.persist.log, CBS.persist00.log и т.д.

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

Для удобства парсинга и поиска именно ошибок, вы можете запустить PowerShell и воспользоваться там такой командой: Select-String -Path "C:\Windows\Logs\CBS\CBS.log" -Pattern

Критическая ошибка применения дельты-обновления. Windows использует технологию "дельт" (разностных обновлений) для экономии трафика. Вместо полных файлов загружаются только изменения (дельта) от старой версии файла к новой. Процесс DeltaDecompressBuffer отвечает за "наложение" этого патча на существующий файл. Ошибка ERROR_INVALID_DATA указывает, что либо сам патч (дельта), либо исходный файл, на который он применяется, повреждены и не соответствуют ожидаемому формату.

2025-09-05 11:16:16, Error CSI 00002395@2025/9/5:08:16:16.081 (F) onecore\base\wcp\rtllib\win32lib\delta_library.cpp(350): Error NTSTATUS_FROM_WIN32(ERROR_INVALID_DATA) originated in function Windows::Rtl::DeltaDecompressBuffer expression: g_pfnApplyDeltaB(( (DELTA_FLAG_TYPE)0x00000000 ), ReferenceInput, CompressedInput, &UncompressedOutput)
[gle=0x80004005]
2025-09-05 11:16:16, Info CBS Added C:\Windows\Logs\CBS\CBS.log to WER report.
2025-09-05 11:16:16, Info CBS Added C:\Windows\Logs\CBS\CbsPersist_20250904060127.log to WER report.
2025-09-05 11:16:16, Info CBS Added C:\Windows\Logs\CBS\CbsPersist_20250903140427.log to WER report.
2025-09-05 11:16:16, Info CBS Added C:\Windows\Logs\CBS\CbsPersist_20250903100750.log to WER report.
2025-09-05 11:16:16, Info CBS Added C:\Windows\Logs\CBS\CbsPersist_20250902110222.log to WER report.
2025-09-05 11:16:16, Info CBS Added C:\Windows\Logs\CBS\CbsPersist_20250902080222.log to WER report.
2025-09-05 11:16:16, Info CBS Not able to add pending.xml to Windows Error Report. [HRESULT = 0x80070002 - ERROR_FILE_NOT_FOUND]
2025-09-05 11:16:16, Info CBS Not able to add pending.xml.bad to Windows Error Report. [HRESULT = 0x80070002 - ERROR_FILE_NOT_FOUND]
2025-09-05 11:16:16, Info CBS Not able to add SCM.EVM to Windows Error Report. [HRESULT = 0x80070002 - ERROR_FILE_NOT_FOUND]
2025-09-05 11:16:16, Error CSI 00002396 (F) Hydration failed with error NTSTATUS_FROM_WIN32(ERROR_INVALID_DATA) . Delta Type: Reverse Delta , IntegrityState Valid: true , RetrievedChecksum: 3850220828 , ComputedChecksum: 3850220828[gle=0x80004005]

Далее в логе идут серии ошибок, указывающие на конкретные проблемные файлы. Система пыталась обновить компонент Microsoft-Windows-Fax-MAPI с версии 1906 на 2849, но не смогла. "Hydration" — это процесс восстановления или сборки правильной версии файла из хранилища компонентов. Процесс завершился неудачей из-за той же ошибки применения дельты.

Самое важное это несовпадение хеш-сумм. Система проверила файл FXSEXT32.dll на диске и вычислила его криптографический хеш (SHA-256). Этот хеш не совпал с тем, который должен быть у корректной версии файла. Это прямое указание на повреждение файла. Аналогичные ошибки произошли и с другими файлами службы факсов: FXSSVC.exe FXSEVENT.dll.

Модуль целостности компонентов (CSI) понимает, что проблема критическая, и пытается пометить хранилище компонентов C:\Windows\WinSxS как поврежденное. Это защитный механизм, предотвращающий дальнейшую установку неправильных версий файлов.

2025-09-05 11:16:16, Error CSI 00002397 (F) Hydration failed for component Microsoft-Windows-Fax-MAPI, version 10.0.20348.2849, arch Host= amd64 Guest= x86, nonSxS, pkt {l:8 b:31bf3856ad364e35} on file FXSEXT32.dll with NTSTATUS -1073283059. Matching Component = Microsoft-Windows-Fax-MAPI, version 10.0.20348.1906, arch Host= amd64 Guest= x86, nonSxS, pkt {l:8 b:31bf3856ad364e35}. FileHasForwardReverseDeltas = true, GenerateReverseDelta = true[gle=0x80004005]
2025-09-05 11:16:16, Error CSI 00002398@2025/9/5:08:16:16.535 (F) Attempting to mark store corrupt with category [l:18 ml:19]'CorruptPayloadFile'[gle=0x80004005]
2025-09-05 11:16:16, Info CSI 00002399 PossibleCorruption: Component: Microsoft-Windows-Fax-MAPI, version 10.0.20348.1906, arch Host= amd64 Guest= x86, nonSxS, pkt {l:8 b:31bf3856ad364e35}, file: FXSEXT32.dll
2025-09-05 11:16:16, Info CSI 0000239a Hashes for file member [l:12]'FXSEXT32.dll' do not match.
Expected: {l:32 ml:33 b:cdf4978c1faae2fcc0f31ed13b73cd8e7464a58192af49b5e162b3a7284c90c6}.
Actual: {l:32 b:5c9b37300155c1f3338bc88f17d69c51fb248b0de0155630962ca6504d789bba}.

2025-09-05 11:16:16, Info CSI 000023a2 Component Microsoft-Windows-Fax-Service, version 10.0.20348.2849, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35} does not have a winner but has 2 other component version(s)
2025-09-05 11:16:16, Error CSI 000023a3@2025/9/5:08:16:16.566 (F) onecore\base\wcp\rtllib\win32lib\delta_library.cpp(350): Error NTSTATUS_FROM_WIN32(ERROR_INVALID_DATA) originated in function Windows::Rtl::DeltaDecompressBuffer expression: g_pfnApplyDeltaB(( (DELTA_FLAG_TYPE)0x00000000 ), ReferenceInput, CompressedInput, &UncompressedOutput)
[gle=0x80004005]
2025-09-05 11:16:16, Error CSI 000023a4 (F) Hydration failed with error NTSTATUS_FROM_WIN32(ERROR_INVALID_DATA) . Delta Type: Reverse Delta , IntegrityState Valid: true , RetrievedChecksum: 4125817457 , ComputedChecksum: 4125817457[gle=0x80004005]
2025-09-05 11:16:16, Error CSI 000023a5 (F) Hydration failed for component Microsoft-Windows-Fax-Service, version 10.0.20348.2849, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35} on file FXSSVC.exe with NTSTATUS -1073283059. Matching Component = Microsoft-Windows-Fax-Service, version 10.0.20348.1547, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35}. FileHasForwardReverseDeltas = true, GenerateReverseDelta = true[gle=0x80004005]
2025-09-05 11:16:16, Error CSI 000023a6@2025/9/5:08:16:16.566 (F) Attempting to mark store corrupt with category [l:18 ml:19]'CorruptPayloadFile'[gle=0x80004005]
2025-09-05 11:16:16, Info CSI 000023a7 PossibleCorruption: Component: Microsoft-Windows-Fax-Service, version 10.0.20348.1547, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35}, file: FXSSVC.exe
2025-09-05 11:16:16, Info CSI 000023a8 Hashes for file member [l:10]'FXSSVC.exe' do not match.
Expected: {l:32 ml:33 b:123d62dc854fa24c8818b25fe0a2a6cae06c77d2137608cd026a03ca01fa3ea2}.
Actual: {l:32 b:a2bc0d17974ab423cd51bd97f73e5324c910ec434ddb896dc81f56fafd777cfc}.
2025-09-05 11:16:16, Info CSI 000023a9 Component Microsoft-Windows-Fax-Service, version 10.0.20348.2849, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35} does not have a winner but has 2 other component version(s)
2025-09-05 11:16:16, Error CSI 000023aa@2025/9/5:08:16:16.581 (F) onecore\base\wcp\rtllib\win32lib\delta_library.cpp(350): Error NTSTATUS_FROM_WIN32(ERROR_INVALID_DATA) originated in function Windows::Rtl::DeltaDecompressBuffer expression: g_pfnApplyDeltaB(( (DELTA_FLAG_TYPE)0x00000000 ), ReferenceInput, CompressedInput, &UncompressedOutput)
[gle=0x80004005]
2025-09-05 11:16:16, Error CSI 000023ab (F) Hydration failed with error NTSTATUS_FROM_WIN32(ERROR_INVALID_DATA) . Delta Type: Reverse Delta , IntegrityState Valid: true , RetrievedChecksum: 3396304258 , ComputedChecksum: 3396304258[gle=0x80004005]
2025-09-05 11:16:16, Error CSI 000023ac (F) Hydration failed for component Microsoft-Windows-Fax-Service, version 10.0.20348.2849, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35} on file FXSEVENT.dll with NTSTATUS -1073283059. Matching Component = Microsoft-Windows-Fax-Service, version 10.0.20348.1547, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35}. FileHasForwardReverseDeltas = true, GenerateReverseDelta = true[gle=0x80004005]
2025-09-05 11:16:16, Error CSI 000023ad@2025/9/5:08:16:16.581 (F) Attempting to mark store corrupt with category [l:18 ml:19]'CorruptPayloadFile'[gle=0x80004005]
2025-09-05 11:16:16, Info CSI 000023ae PossibleCorruption: Component: Microsoft-Windows-Fax-Service, version 10.0.20348.1547, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35}, file: FXSEVENT.dll
2025-09-05 11:16:16, Info CSI 000023af Hashes for file member [l:12]'FXSEVENT.dll' do not match.

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

2025-09-05 11:19:25, Error CBS Failed to resolve package 'Microsoft-Windows-ServerDatacenterEdition~31bf3856ad364e35~amd64~~10.0.20348.2527' [HRESULT = 0x80070490 - ERROR_NOT_FOUND]
2025-09-05 11:19:25, Info CBS Failed to resolve package: Microsoft-Windows-ServerDatacenterEdition~31bf3856ad364e35~amd64~~10.0.20348.2527 [HRESULT = 0x80070490 - ERROR_NOT_FOUND]
2025-09-05 11:19:25, Info CBS Plan: Start to process package watchlist.

2025-09-05 11:04:55, Info CBS Failed to extract file TOC.xml from cabinet \\?\C:\Windows\SoftwareDistribution\Download\bda22b65490dc19761e9c375ff783c1f\inst\Windows10.0-KB5063880-x64.cab [HRESULT = 0x80070002 - ERROR_FILE_NOT_FOUND]
2025-09-05 11:04:55, Info DPX Started DPX phase: Resume and Download Job

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

Только чистая установка

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

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

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

$registryPath = 'HKLM:\software\microsoft\windows\currentversion\component based servicing\packages'

# Получаем все подпапки
$packages = Get-ChildItem -Path $registryPath -Recurse | Where-Object {$_.PSIsContainer}

$results = @()
$counter = 0

foreach ($package in $packages) {
$counter++
Write-Progress -Activity "Проверка пакетов CBS" -Status "Обработано: $counter из $($packages.Count)" -PercentComplete (($counter / $packages.Count) * 100)

$currentState = Get-ItemProperty -Path $package.PSPath -Name "CurrentState" -ErrorAction SilentlyContinue

if ($currentState -and $currentState.CurrentState -eq 0x40) {
$installLocation = Get-ItemProperty -Path $package.PSPath -Name "InstallLocation" -ErrorAction SilentlyContinue
$lastError = Get-ItemProperty -Path $package.PSPath -Name "LastError" -ErrorAction SilentlyContinue

$packageInfo = [PSCustomObject]@{
PackageName = $package.PSChildName
CurrentState = "0x40"
InstallLocation = if ($installLocation) { $installLocation.InstallLocation } else { "N/A" }
LastError = if ($lastError) { "0x$([convert]::ToString($lastError.LastError, 16).ToUpper())" } else { "N/A" }
RegistryPath = $package.PSPath
}

$results += $packageInfo
}
}

Write-Progress -Activity "Проверка пакетов CBS" -Completed

# Вывод результатов
if ($results.Count -gt 0) {
$results | Format-Table -AutoSize
Write-Host "`nНайдено пакетов: $($results.Count)" -ForegroundColor Green
} else {
Write-Host "Пакеты не найдены." -ForegroundColor Yellow
}

Обратите внимание, что в моем примере найдено 100 сбойных пакетов с кодом 0x40.

Ветка реестра HKLM:\software\microsoft\windows\currentversion\component based servicing\packages для каждого установленного пакета (например, пакета обновления безопасности, исправления, драйвера или языкового пакета) создает собственный подраздел. Имя подраздела обычно соответствует имени файла .cab или .msu, из которого был установлен пакет.

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

CurrentState: Главный параметр, указывающий текущее состояние пакета.

• 112 (0x70) — Пакет установлен и активен.
• 128 (0x80) — Пакет ожидает установки (например, после скачивания через Центр обновления Windows).
• 160 (0xA0) — Пакет ожидает удаления.
• 192 (0xC0) — Пакет установлен, но отложен до перезагрузки.
• 240 (0xF0) — Пакет полностью удален.
• 64 (0x40 и 0x50) - Указывает на сбой в процессе установки этого конкретного обновления. Классический симптом проблемы с установкой обновления, что часто leads к ошибкам Центра обновления Windows (например, с кодами 0x80073712, 0x800f081f).

InstallClient: Указывает, какая программа установила пакет (например, Windows Update или DISM).

InstallName: Путь к исходному файлу пакета "C:\Windows\SoftwareDistribution\Download\...\windows10.0-kb5001330-x64.msu"

InstallTime: Время установки пакета в формате YYYYMMDDHHMMSS.

Visibility: Определяет, виден ли пакет пользователю (обычно значение 0 — не виден).

Version: Версия пакета.

Dependents: Список пакетов, которые зависят от данного.

Именно в эту ветку реестра обращаются утилиты по починке пакетов и целостности системы.

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

# Создание папки для экспорта
$exportDir = "C:\Temp\RegistryExports"
$exportFile = Join-Path $exportDir "CBS_Packages_$(Get-Date -Format 'yyyyMMdd_HHmmss').reg"

# Создаем директорию если не существует
if (-not (Test-Path $exportDir)) {
New-Item -ItemType Directory -Path $exportDir -Force
}

# Выполняем экспорт
Write-Host "Экспортирую ветку Packages..." -ForegroundColor Yellow
& reg.exe export "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages" $exportFile /y

if ($LASTEXITCODE -eq 0) {
Write-Host "✓ Успешно сохранено в: $exportFile" -ForegroundColor Green
} else {
Write-Error "✗ Ошибка экспорта. Код ошибки: $LASTEXITCODE"
}

Или более простой метод

# Экспорт всей ветки Packages
reg export "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages" "C:\CBS_Packages.reg" /y

# Зааем путь экспорта
$exportPath = "C:\Temp\CBS_Packages.reg"
reg export "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages" $exportPath /y

Починка ветки реестра от поврежденных записей

Далее когда все готово, можно производить чистку данной ветки

$name = 'CurrentState'

$check=(get-childitem -Path 'HKLM:\software\microsoft\windows\currentversion\component based servicing\packages' -Recurse).Name

foreach($check1 in $check)

{

$check2=$check1.replace("HKEY_LOCAL_MACHINE","HKLM:")

if((Get-ItemProperty -Path $check2).$name -eq 0x50 -or (Get-ItemProperty -Path $check2).$name -eq 0x40 )

{

write-host (Get-ItemProperty -Path $check2).PSChildName

Set-ItemProperty -Path $check2 -Name $name -Value 0

}

}

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

Сброс компонентов Центра обновления Windows в PowerShell

Со временем Windows может накапливать в себе поврежденные данные от предыдущих обновлений, что может приводить к текущим ошибкам. В таких ситуациях, вседа полезно произвести сброс компонентов Центра обновлений, я об этом уже рассказывал в статьях, где  решал ошибки 0x8007050a или 80244010. Там  приводил вам скрпит, который производил:

1. Остановку стека служб, которые используются центром обновления Windows (BITS, wuauserv, appidsvc и cryptsvc). Делается, это для того, чтобы можно было на следубщих шагах производить замену папок и файлов.
2. Удаление данных служб. Удаляются файлы состояния службы BITS и старые журналы Центра обновлений.
3. Создание резервных копий. Выполняется резервное копирование папок SoftwareDistribution (с загруженными обновлениями) и CatRoot (с базой данных каталогов).
4. Сбрасывание настроек на стеке служб цетра обновлений. Производится сброс параметров служб Центра обновлений, перерегистрация связанных DLL-библиотек, а также сброс сетевых компонентов (WinSock и прокси).
5. Перезапуск всех служб отвечающих за установку обновлений

Для современных систем, к которым относится Windows Server 2022 и последующие cmd скрипт мог отрабатывать не до конца, и даже, где-то с ошибками. Поэтому я всегда теперь использую для этой цели модуль PowerShell.

Модуль PSWindowsUpdate это большой комбайн позволяющий вам производить управление обновлениями Windows через PowerShell (Скачивание, установка, скрытие, удаление и многое другое) нас тут будет интересовать автоматизация сброса компонентов Центра обновления Windows. Запустите PowerShell в режиме администратора.

Теперь вам необходимо скачат ьи установить модуль PSWindowsUpdate, для этого введите команду:

Install-Module -Name PSWindowsUpdate -Force

Нажмите "Y", чтобы подтвердить установку, если вас спросит.

Теперь, чтобы у вас не выскакивало ошибок при выполнении скрипта по сбросу компонентов Windows Update, нужно выполнить команду:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -force

RemoteSigned - разрешает выполнение: Локальных скриптов (созданных на этом компьютере) - без ограничений Скачанных скриптов - только если они подписаны доверенным издателем
-Force - применяет изменение без запроса подтверждения. (Более подробно про различные режимы запуска скриптов PowerShell читайте по ссылке)

Теперь, когда предварительная подготовка выполнена, вы можете импортировать модуль PSWindowsUpdate. Для этого выполните команду:

Import-Module PSWindowsUpdate

Ну и остается ввести волшебную команду, которая за полминуты произведет полноценный сброс компонентов Центра обновления Windows.

Reset-WUComponents -Verbose

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

Step 3: Backup softare distribution folders
VERBOSE: Renaming Software Distribution folder to C:\Windows\SoftwareDistribution.bak
VERBOSE: Renaming CatRoot folder to C:\Windows\System32\Catroot2.bak3

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

Если у вас нет интернета на сервере, то вы можете заранее скачать модуль PSWindowsUpdate и установить его офлайн. Ссылка на модуль - https://www.powershellgallery.com/packages/PSWindowsUpdate/2.2.1.5

Очистка центрального хранилища всех компонентов и библиотек системы

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

Есть замечательная папка WinSxS  (Windows Side by Side). Это системная папка, которая служит хранилищем для всех критически важных системных компонов (библиотек DLL, драйверов и т.д.). Windows хранит здесь несколько версий одного и того же компонента для совместимости со старыми программами. Когда вы устанавливаете обновление Windows, система не удаляет старые версии компонентов сразу. Она сохраняет их в WinSxS на случай, если новое обновление вызовет проблему и его потребуется откатить. Со временем в этом хранилище накапливается много устаревших и ненужных файлов.

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

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

   Dism.exe /Online /Cleanup-Image /AnalyzeComponentStore

   Обращу ваше внимание, что данная операция может выполняться минут 10-15, а то и более, тут все зависит от размера папки WinSxS. Если вы зайдете в этот момент в "Монитор ресурсов", то заметите огромное количество операций чтения к данной папке.

2. После выполнения анализа, посмотрите текущие значения. Общий размер 8 ГБ, из них резервные и неиспользуемые копии 2,42 ГБ.
3. Теперь произведем саму оптимизацию. Она может занимать еще больше времени.

Dism.exe /online /Cleanup-Image /StartComponentCleanup

Запустите потом повторный анализ папки WinSxS, чтобы понять сколько в результате оптимизации вы высвободили места. В результате очищено 500 МБ, но не думайте, что это мало, в это пространство могло бытьумещено сотни папок от старых обновлений. Теперь я рекомендую перезагрузить сервер.

Команда SFC /scannow и восстановление системных файлов Windows

Чтобы точно понимать, нет ли проблем на уровне системных файлов, на первом этапе желательно бы их проверить. Для этого есть старая утилита командной строки sfc. Данная утилита проверяет:

• Файлы ядра Windows (например, ntoskrnl.exe): "Сердце" операционной системы, управляющее памятью, процессами и драйверами.
• Библиотеки DLL (Dynamic Link Library): Файлы, содержащие код и данные, которые используются множеством разных программ. Повреждение одной DLL может привести к сбоям в нескольких приложениях.
• Файлы драйверов устройств (например, disk.sys): Обеспечивают связь между операционной системой и hardware (железом) — видеокартой, принтером, мышкой и т.д.
• Файлы конфигурации (например, в папке C:\Windows\System32\config\): Хранят настройки системы и реестра.
• Исполняемые файлы системных утилит (например, svchost.exe, explorer.exe).

Что делает команда sfc /scannow?

Её задача — проверить целостность всех защищенных системных файлов и автоматически восстановить те из них, которые повреждены или были изменены. Как она это делает?

1. Сканирование: Утилита проходит по всем защищенным системным файлам и вычисляет их криптографическую хэш-сумму (уникальный цифровой отпечаток).
2. Сравнение: Полученные хэш-суммы сравниваются с эталонными, хранящимися в специальном кэше (C:\Windows\System32\dllcache) или в сжатом виде внутри папки C:\Windows\WinSxS (хранилище компонентов).
3. Восстановление: Если файл поврежден, не совпадает с эталоном или отсутствует, sfc автоматически заменяет его на правильную копию из хранилища.

Запустите командную строку от имени администратора и введите команду:

sfc /scannow

Тут нужно запастись терпением, так как команда может отрабатывать долго, все зависит от степени проблем.

Если все хорошо, то у вас должно быть вот такое сообщение:

Beginning system scan. This process will take some time.

Beginning verification phase of system scan.
Verification 100% complete.

Windows Resource Protection did not find any integrity violations.

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

Windows resource Protection found corrupt files but was unable to fix some of them. Details are included in the CBS.log windir\Logs\CBS\CBS.log. (Программа защиты ресурсов Windows обнаружила повреждённые файлы, но не может восстановить некоторые из них)

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

Проверяем целостность хранилища компонентов Windows утилитой DISM

Во многих статьях на данном блоге я использовал всем известную утилиту DISM, например когда создавал ISO в командной строке.

Утилита DISM (Deployment Image Servicing and Management) -  это "хирургический инструмент" для работы с "здоровьем" вашей Windows на глубинном уровне. Мощнейшая утилита командной строки, встроенная в современные версии Windows (начиная с Windows 7 и особенно важная в для Windows 10/11), предназначенная для обслуживания и подготовки образов Windows.

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

DISM /Online /Cleanup-Image /CheckHealth

• Ключ /Online сообщает, что  все операции нужно проводить с текущей работающей системой, а не с каким-либо внешним файлом образа (.wim или .esd)
• Ключ /Cleanup-Image основная команда для задач обслуживания и "очистки" образа Windows.
• Ключ /CheckHealth конкретное действие, которое нужно выполнить — проверить "здоровье" образа.

В идеальном варианте вы должны получить сообщение:

The component store is repairable.
The operation completed successfully.

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

DISM /Online /Cleanup-Image /ScanHealth

Сразу оговорюсь, что оно может длиться от 10 и более минут. ПО результатам вы получите один из трех ответов.

Deployment Image Servicing and Management tool Version: 10.0.20348.681 Image Version: 10.0.20348.2527
[==========================100.0%==========================]
The component store is repairable. The operation completed successfully.

• The component store is repairable - Утилита DISM нашла повреждения в хранилище компонентов и сможет попытаться их исправить, получиться или нет зависит от других факторов.
• No component store corruption detected - Самый идеальный вариант, при котором у вас все отлично и нечего восстанавливать и ремонтировать
• The component store is not repairable - Тут утилита DISM видит серьезные повреждения в хранилище, но не может их исправить, тут долгий путь с танцами и бубном, иногда быстрее и проще переустановить систему, или сделать миграцию сервера на чистую установку. (Тут вы можете наблюдать ошибки "1726. Сбой при удалённом вызове процедуры" и "1910. Не найден указанный источник экспорта объекта")

Если у вас еще до сих пор используется старая версия ОС, например Windows 7 или Windows Server 2008R2, то вам необходимо загрузить отдельное KB2966583 с последующей установкой. В противном случае вы будите получать "Ошибка 87. Параметр ScanHealth не распознан в этом контексте" если использовать параметр /ScanHealth

Ссылка на KB2966583 - https://www.microsoft.com/ru-ru/download/details.aspx?id=43524 (Если вдруг уже не будет напишите мне я вам скину скачанный)

Как восстановить хранилище компонентов Windows с помощью DISM

Мы с вами воспользуемся параметром /RestoreHealth, он позволит исправить повреждения в хранилище компонентов образа Windows. DICM с этим параметром найдет ошибки в образе системы, скачает нужные файлы на замену поврежденных или отсутствующих. На ксервере должен быть интернет, так как все файлы будут загружаться оттуда. Если у вас используется WSUS, то лучше сервер переключить с него на сервера Microsoft. Обратите внимание, что данная операция может выполняться еще дольше, до 30+ минут.

DISM /Online /Cleanup-Image /RestoreHealth

В идеале вы тут должны получить статус:

Восстановление выполнено успешно. Операция успешно завершена.

The restore operation completed successfully.

Но может быть и другое:

Error: 0x800f081f

The source files could not be found.
Use the "Source" option to specify the location of the files that are required to restore the feature. For more information on specifying a source location, see https://go.microsoft.com/fwlink/?LinkId=243077.

The DISM log file can be found at C:\Windows\Logs\DISM\dism.log

Обратите внимание, что у DISM свой лог файл, в нем я вижу немного деталей:

2025-09-16 14:17:44, Info DISM DISM Package Manager: PID=1900 TID=7956 Error in operation: source for package or file not found, ResolveSource() unsuccessful. (CBS HRESULT=0x800f081f) - CCbsConUIHandler::Error
2025-09-16 14:17:44, Error DISM DISM Package Manager: PID=1900 TID=5304 Failed finalizing changes. - CDISMPackageManager::Internal_Finalize(hr:0x800f081f)
2025-09-16 14:17:44, Error DISM DISM Package Manager: PID=1900 TID=5304 The source files could not be found; their location must be specified using the /source option to restore the feature. - GetCbsErrorMsg
2025-09-16 14:17:44, Error DISM DISM Package Manager: PID=1900 TID=5304 Failed processing package changes with session option CbsSessionOptionRepairStoreCorruption - CDISMPackageManager::RestoreHealth(hr:0x800f081f)
2025-09-16 14:17:44, Error DISM DISM Package Manager: PID=1900 TID=5304 The source files could not be found; their location must be specified using the /source option to restore the feature. - GetCbsErrorMsg
2025-09-16 14:17:44, Error DISM DISM Package Manager: PID=1900 TID=5304 Failed to restore the image health. - CPackageManagerCLIHandler::ProcessCmdLine_CleanupImage(hr:0x800f081f)
2025-09-16 14:17:44, Error DISM DISM Package Manager: PID=1900 TID=5304 Failed while processing command cleanup-image. - CPackageManagerCLIHandler::ExecuteCmdLine(hr:0x800f081f)

Как исправить ошибку 0x800f081f, 0x800f0906, 0x800f0950 с помощью установочного диска

Чтобы попытаться обойти данную ошибку нам понадобиться установочный дистрибутив данной операционной системы, из которого нужно взять wim или ESD файл.

Посмотреть какая у вас версия и билд можно командой Winver или другими методами

То о чем я писал выше, что вероятно у вас сервер в домене и поиск обновлений идет из внутреннего сервера WSUS. Все эти ошибки, это их производные.

• Ошибка: 0x800F081F - На русском она звучит как "Не удалось найти исходные файлы. Укажите расположение файлов, необходимых для восстановления компонента, с помощью параметра Источник". Означает, что утилита DISM не может автоматически найти и скачать с серверов Microsoft исходные файлы, необходимые для восстановления повреждённых системных компонентов.
• Ошибка: 0x800f0950 - Сбой DISM. Операция не выполнена (0x800f0950 — DISM failed. No operation was performed);
• Ошибка 0x800f0906 - "The source files could not be downloaded. Use the source option to specify the location of the files that are required to restore the feature" (Не удалось скачать исходные файлы. Укажите расположение файлов, необходимых для восстановления компонента, с помощью параметра Источник)

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

# Создаем папку назначения
New-Item -Path "C:\Temp\Windows_ISO" -ItemType Directory -Force

# Монтируем ISO файл
$isoPath = "C:\Temp\SW_DVD9_Win_Server_STD_CORE_2022_2108.29_64Bit_English_DC_STD_MLF_X23-68105.ISO" # Укажите полный путь к вашему ISO
$mountResult = Mount-DiskImage -ImagePath $isoPath -PassThru

# Получаем букву диска монтированного образа
$driveLetter = (Get-DiskImage -ImagePath $isoPath | Get-Volume).DriveLetter + ":"

# Копируем все файлы
Copy-Item -Path "$driveLetter\*" -Destination "C:\Temp\Windows_ISO" -Recurse -Force

# Размонтируем ISO
Dismount-DiskImage -ImagePath $isoPath

Write-Host "ISO успешно распакован в C:\Temp\Windows_ISO" -ForegroundColor Green

Кстати если у вас физический сервер, то вы легко в него можете воткнуть загрузочную флешку с нужной версией Windows Server

Тут вам понадобится файл по пути C:\Temp\Windows_ISO\sources\install.wim. Запустите PowerShell и проверьте, какие версии редакций есть в вашем дистрибутиве и подходят ли они вам для использования. Обратите внимание, что у вас путь до файла install.wim свой исходя из его расположения.

Get-WindowsImage -ImagePath "C:\Temp\Windows_ISO\sources\install.wim"

Вижу, что есть необходимая мне "Windows Server 2022 Standard (Desktop Experience)". У него ImageIndex 2.

Чтобы с его помощью нужного ImageIndex восстановить хранилище компонентов вам потребуется выполнить вот такую команду для WIM файла.

DISM /online /cleanup-image /restorehealth /source:WIM:C:\Temp\Windows_ISO\sources\install.wim:2 /limitaccess

И выполнить команду если у вас ESD файл.

DISM /online /cleanup-image /restorehealth /source:ESD:C:\Temp\Windows_ISO\sources\install.esd:2 /limitaccess

В ряде случаев, когда есть хвосты в реестре, вы можете получать ошибку "Error: 50: DISM does not support servicing Windows PE with the /Online option", исправить ее можно путем удаления ветки реестра:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\MiniNT

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

sfc /scannow

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

Загрузка с WinPE

Обновление ОС с установочного ISO образа

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

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

Хочу отметить, что если сервер присоединен к домену, то он так и останется в нем быть, у него останется тот же SID.

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

Запустите установочный файл setup.exe, который расположен на смонтированоом образе Windows Server. У вас откроется мастер установки. Советую галку отправки лога установки не ставить. Нажимаем "Next".

На следующем шаге если ключ продукта не определится, то просто введите GVLK ключ, который есть в открытом доступе.

Выбираем нужную редакцию, в моем случае это Windows Server Standard (desktop Experience)

Принимаем лицензионное соглашение, нажмите кнопку "Accept".

Далее обязательно оставляем галку "Keep files, settings and apps", это позволит вам сохранить текущее состояние всего того, что есть на сервере.

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

Теперь остается только нажать кнопку "Install".

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

После успешного установления поверх вашей ОС и авторизации. Я сразу пошел проверять возможность установить свежий KB ручным методом, и в 99% случаев оно работает.

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

Дополнительные ссылки

• https://www.reddit.com/r/WindowsServer/comments/1i0kwmv/server_2022_failing_to_update/
• https://www.servertrouble.com/windows-update-from-sccm-software-center-the-installation-fails/
• https://learn.microsoft.com/ru-ru/answers/questions/4115121/windows-11-version-22h2-x64-2023-0 `9-(kb5030219)-0x
• https://www.reddit.com/r/sysadmin/comments/bp77f1/windows_server_2016_ltsc_updates_being_aborted_by/?tl=ru
• https://learn.microsoft.com/ru-ru/windows-hardware/manufacture/desktop/clean-up-the-winsxs-folder?view=windows-11