Проверка windows server 2008 на ошибки

Апр 28, 2017 14:37

Время прочтения
8 мин

Просмотры 164K

Авторское примечание: Статья в первую очередь написана для начинающих системных администраторов, опытные вряд ли почерпнут для себя здесь что-нибудь новое и полезное. Навеяно статьей про GPUPDATE /force (спасибо mrHobbY).

Active Directory – это большой и сложный организм (даже если он состоит и двух контроллеров домена и одного сайта), и для системного администратора очень важно в любой момент времени провести диагностику для анализа работы этого организма.
Ну, а так как по оснасткам ходить и смотреть малоэффективно, по логам системы тоже не всегда поймешь, что происходит, поэтому на помощь приходят различные утилиты. Одна из них – dcdiag от компании Microsoft.
Посмотрим на нее внимательно – ибо полезность данной утилиты трудно переоценить. Я не буду приводить многочисленные ключи данной команды – про них при желании можно и в справке прочитать — а остановлюсь только на тех, – которые использую сам при диагностике на практике.

Первое, что нужно сделать, чтобы работать с этой утилитой – это установить ее к себе на рабочую станцию или на сам сервер (тут каждый волен выбирать сам, но в последних версиях dcdiag – уже в помощи написано, что проверки необходимо запускать на самих серверах — контроллерах домена, за исключением тестов dcPromo и RegisterInDNS). Для Windows 2003 необходимо установить пакет Support Tools c дистрибутива операционной системы, для Windows 7 и 8 – необходимо установить пакет Remote System Administration Tools (они разные для win7, win7sp1, и win8 – будьте внимательны, когда будете скачивать). Кстати, RSAT — сам по себе полезный продукт – внутри много утилит, которые просто необходимы в повседневной жизни администратора домена.
После установки пакета команда уже доступна из командной строки.
Но не торопитесь запускать ее сразу, на рабочей станции ничего не получится без указания контроллера домена, к которому надо подключиться. Утилита выдаст соответствующее предупреждение:

Примечание: начиная с Windows 7 сообщения dcdiag переведены на русский. До этого – все только на английском. Может будет кому полезно. Хотя и в старых версиях очень простой и понятный английский язык.

Замечательно – мы выяснили – что желательно указать контроллер домена с помощью ключа /s: или контекст именования – /n:. Какой сервер указывать понятно – тот контроллер домена, который вы хотите проверить – а вот если указать контекст именования домена – (имя домена другими словами – можно указывать в форматах Netbios, DNS или DN.), то будет найден ближайший (в пределах сайта) контроллер домена (далее КД).
Проведем самую простую проверку: dcdiag /s:dc01-local
И опять беда, хотя кое-что уже видно:

dcdiag /s:dc01-local.local

Диагностика сервера каталогов

Выполнение начальной настройки:
   * Идентифицирован лес AD.
   Сбор начальных данных завершен.

Выполнение обязательных начальных проверок

   Сервер проверки: Localdc01-local
      Запуск проверки: Connectivity
         ......................... DC01-LOCAL - пройдена проверка Connectivity

Выполнение основных проверок

   Сервер проверки: Localdc01-local
      Запуск проверки: Advertising
         ......................... DC01-LOCAL - пройдена проверка Advertising
      Запуск проверки: FrsEvent
         Ошибка 5 при открытии File Replication Service журнала событий
         \DC01-LOCAL:File Replication Service:
          Отказано в доступе.
         ......................... DC01-LOCAL - не пройдена проверка FrsEvent
      Запуск проверки: DFSREvent
         ......................... DC01-LOCAL - пройдена проверка DFSREvent
      Запуск проверки: SysVolCheck
         ......................... DC01-LOCAL - не пройдена проверка SysVolCheck
      Запуск проверки: KccEvent
         Ошибка 5 при открытии Directory Service журнала событий
         \DC01-LOCAL:Directory Service:
          Отказано в доступе.
         ......................... DC01-LOCAL - не пройдена проверка KccEvent
      Запуск проверки: KnowsOfRoleHolders
         ......................... DC01-LOCAL - пройдена проверка
         KnowsOfRoleHolders
      Запуск проверки: MachineAccount
         ......................... DC01-LOCAL - пройдена проверка MachineAccount
      Запуск проверки: NCSecDesc
         ......................... DC01-LOCAL - пройдена проверка NCSecDesc
      Запуск проверки: NetLogons
         [DC01-LOCAL] В учетных данных пользователя отсутствует разрешение на
         выполнение данной операции.
         Учетная запись, используемая для этой проверки, должна иметь права на
         вход в сеть
         для домена данного компьютера.
         ......................... DC01-LOCAL - не пройдена проверка NetLogons
      Запуск проверки: ObjectsReplicated
         ......................... DC01-LOCAL - пройдена проверка
         ObjectsReplicated
      Запуск проверки: Replications
         [Проверка репликации,DC01-LOCAL] Сбой функции
         DsReplicaGetInfo(PENDING_OPS, NULL), ошибка 0x2105
         "Доступ к репликации отвергнут."
         ......................... DC01-LOCAL - не пройдена проверка Replications
      Запуск проверки: RidManager
         ......................... DC01-LOCAL - пройдена проверка RidManager
      Запуск проверки: Services
         Не удалось открыть диспетчер управления службой в
         dc01-local.local, ошибка 0x5 "Отказано в доступе."
         ......................... DC01-LOCAL - не пройдена проверка Services
      Запуск проверки: SystemLog
         Ошибка 5 при открытии System журнала событий \DC01-LOCAL:System:
          Отказано в доступе.
         ......................... DC01-LOCAL - не пройдена проверка SystemLog
      Запуск проверки: VerifyReferences
         ......................... DC01-LOCAL - пройдена проверка VerifyReferences


   Выполнение проверок разделов на: Schema
      Запуск проверки: CheckSDRefDom
         ......................... Schema - пройдена проверка CheckSDRefDom
      Запуск проверки: CrossRefValidation
         ......................... Schema - пройдена проверка
         CrossRefValidation

   Выполнение проверок разделов на: Configuration
      Запуск проверки: CheckSDRefDom
         ......................... Configuration - пройдена проверка
         CheckSDRefDom
      Запуск проверки: CrossRefValidation
         ......................... Configuration - пройдена проверка
         CrossRefValidation

   Выполнение проверок разделов на: LOCAL
      Запуск проверки: CheckSDRefDom
         ......................... LOCAL - пройдена проверка CheckSDRefDom
      Запуск проверки: CrossRefValidation
         ......................... LOCAL - пройдена проверка
         CrossRefValidation

   Выполнение проверок предприятия на: LOCAL.local
      Запуск проверки: LocatorCheck
         ......................... LOCAL.local - пройдена
         проверка LocatorCheck
      Запуск проверки: Intersite
         ......................... LOCAL.local - пройдена
         проверка Intersite

Как мы видим, часть тестов пройдена – но части отказано в доступе. Это из-за того, что dcdiag я запускал из-под обычной учетной записи домена, без администраторских прав. Понятно – что часть проверок пройти под ней просто невозможно. Поэтому, что бы получить правильную диагностику, необходимо запускать утилиту с административными полномочиями – либо запустить командную строку от имени администратора, либо использовать ключи /u: имя доменаимя пользователя и /p: пароль. Попробуем:
dcdiag /s:dc01-local /u:localuser19 /p:Password

Диагностика сервера каталогов

Выполнение начальной настройки:
   * Идентифицирован лес AD.
   Сбор начальных данных завершен.

Выполнение обязательных начальных проверок

   Сервер проверки: MagadanDC01-LOCAL
      Запуск проверки: Connectivity
         ......................... DC01-LOCAL - пройдена проверка Connectivity

Выполнение основных проверок

   Сервер проверки: MagadanDC01-LOCAL
      Запуск проверки: Advertising
         ......................... DC01-LOCAL - пройдена проверка Advertising
      Запуск проверки: FrsEvent
         ......................... DC01-LOCAL - пройдена проверка FrsEvent
      Запуск проверки: DFSREvent
         ......................... DC01-LOCAL - пройдена проверка DFSREvent
      Запуск проверки: SysVolCheck
         ......................... DC01-LOCAL - пройдена проверка SysVolCheck
      Запуск проверки: KccEvent
         ......................... DC01-LOCAL - пройдена проверка KccEvent
      Запуск проверки: KnowsOfRoleHolders
         ......................... DC01-LOCAL - пройдена проверка
         KnowsOfRoleHolders
      Запуск проверки: MachineAccount
         ......................... DC01-LOCAL - пройдена проверка MachineAccount
      Запуск проверки: NCSecDesc
         ......................... DC01-LOCAL - пройдена проверка NCSecDesc
      Запуск проверки: NetLogons
         ......................... DC01-LOCAL - пройдена проверка NetLogons
      Запуск проверки: ObjectsReplicated
         ......................... DC01-LOCAL - пройдена проверка
         ObjectsReplicated
      Запуск проверки: Replications
         ......................... DC01-LOCAL - пройдена проверка Replications
      Запуск проверки: RidManager
         ......................... DC01-LOCAL - пройдена проверка RidManager
      Запуск проверки: Services
            Недопустимый тип службы: RpcSs на DC01-LOCAL, текущее значение -
            WIN32_OWN_PROCESS, ожидаемое значение - WIN32_SHARE_PROCESS
         ......................... DC01-LOCAL - не пройдена проверка Services
      Запуск проверки: SystemLog
         ......................... DC01-LOCAL - пройдена проверка SystemLog
      Запуск проверки: VerifyReferences
         ......................... DC01-LOCAL - пройдена проверка VerifyReferences


   Выполнение проверок разделов на: Schema
      Запуск проверки: CheckSDRefDom
         ......................... Schema - пройдена проверка CheckSDRefDom
      Запуск проверки: CrossRefValidation
         ......................... Schema - пройдена проверка
         CrossRefValidation

   Выполнение проверок разделов на: Configuration
      Запуск проверки: CheckSDRefDom
         ......................... Configuration - пройдена проверка
         CheckSDRefDom
      Запуск проверки: CrossRefValidation
         ......................... Configuration - пройдена проверка
         CrossRefValidation

   Выполнение проверок разделов на: LOCAL
      Запуск проверки: CheckSDRefDom
         ......................... LOCAL - пройдена проверка CheckSDRefDom
      Запуск проверки: CrossRefValidation
         ......................... LOCAL - пройдена проверка
         CrossRefValidation

   Выполнение проверок предприятия на: LOCAL.Local
      Запуск проверки: LocatorCheck
         ......................... LOCAL.Local - пройдена
         проверка LocatorCheck
      Запуск проверки: Intersite
         ......................... LOCAL.Local - пройдена
         проверка Intersite

ак видим, проверки пройдены почти все – кроме проверки Services. Но тут у меня есть вполне логичное объяснение – я с помощью новой утилиты (из пакета для windows 7) пытаюсь проверять контроллер домена на базе win2003 – и вполне возможно, название службы может отличаться.

Лирическое отступление №1. При подготовке статьи я столкнулся с

epic fail

забавным феноменом, может в комментариях обсудим? :). В общем, запуская dcdiag из-под обычной учетной записи другого домена (связанного доверительными отношениями с исследуемым доменом local) и задавая параметры /u и /p – (имя пользователя и пароль административной учетной записи домена local) – утилита выдавала ошибки в части проверок — например sysvolchek (в версии dcdiag 2003 – frssysvol). Если же на рабочую станцию зайти под учетной записью с административными полномочиями в домене local — проверки прекрасно проходятся. Так что – может быть, все-таки не лишним будет проводить проверку на самом сервере. Конец лирического отступления №1.

Полностью описывать результаты работы команды я не вижу смысла. Это прекрасно описано в помощи к утилите (dcdiag /h). Видно главное – с данным контроллером домена проблем нет и все тесты пройдены. Но из проверки одного сервера – не следует факт, что AD сейчас находится в

шоколаде

работоспособном состоянии. И вот здесь нам на помощь придет ключ для проверки всех серверов предприятия.
Это ключ /e. Данный ключ заставляет утилиту обойти все КД в домене с запуском всех тестов на каждом сервере. Полезно вместе с этим применить /v – вывод расширенной информации по каждому тесту. Ну и чтобы проанализировать все это – полезно данные вывести в файл – причем лог отдельно, сообщения об ошибках – отдельно. Помогут в этом ключи /f: имя_файла_лога и ferr:/имя_файла_лога_ошибок (в новых версиях ключ /ferr убран). Если вы хотите провести проверку не того домена, в котором находитесь сейчас – добавите ключ для указания наименования контекста /n:.

Полностью команда выглядит так:
dcdiag /n:local /e /v /f:c:logsadtest.log /ferr:c:logsaderrors.log /u:localuser19 /p:Password

Внимание! В версиях dcdiag, начиная с windows 2008 ключ /ferr: убран из поддерживаемых (специально повторился :)).
Если у вас сложная структура леса, да еще и с медленными каналами связи приготовьтесь подождать. Да даже и если несложная – скажем у меня в одном реальном лесе – 10 КД, 5 сайтов и каналы 256 кбит/сек. Выполнение данной команды занимает в среднем до 20 минут.
Результат исполнения очень рекомендуется внимательно просмотреть на наличие проблем. Ну и очень желательно запускать данную утилиту регулярно для диагностики здоровья AD.
Для хардкора можно еще добавить ключ /fix – внесение безопасных исправлений, но бездумно все-таки этого делать не стоит.

Вот собственно и все что я хотел сегодня рассказать. А как часто вам приходится пользоваться данной утилитой на производстве? Какие альтернативы вы знаете?

update 1: Что-то вспомнилось, опять же из личного опыта: если у вас большой домен, связанный небыстрыми (например, спутниковыми) каналами связи — утилита будет выдавать массу ошибок в случае ее отсутствия — чаще всего, что недоступен RPC. Это нормально, и про это надо знать. Если большинство тестов оканчивается подобным сообщением — значит нет связи, необходимо применять меры по устранению сбоя. Вторая часто распространенная проблема — ошибки в DNS — но это тема уже для отдельной статьи.
p.s. к update 1 -dcdiag /fix — в том числе регистрирует по новой записи в dns службы netlogon — это тоже бывает полезно знать!

Sfc /scannow — это команда командной строки, которая позволяет сканировать вашу систему Windows на наличие ошибок и исправлять их.

sfc /scannow

sfc /scanfile=c:windowssystem32ieframe.dll

sfc /scannow /offbootdir=c: /offwindir=c:windows

sfc /verifyonly

Как использовать инструмент Scannow SFC в Windows XP

Windows XP имеет возможность защитить себя от нестабильности системы, вызванной сторонним программным обеспечением, переписывающим важные системные файлы.

Раньше это было (и по-прежнему на самом деле), проблема с Windows 95 и Windows 98.

С введением Windows Millennium Edition Microsoft предприняла настоящие усилия, чтобы остановить это.

Теперь в Windows XP у нас есть гораздо более совершенная защита этих важных файлов …

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

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

Для этого просто перейдите в поле «Выполнить» в меню «Пуск» и введите:

sfc /scannow.

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

В идеальном мире, который станет концом истории … Любые поврежденные, отсутствующие или неправильные файлы будут заменены этим процессом.

Как использовать Sfc /Scannow для восстановления Windows 7

1. Первый шаг — открыть окно с повышенными командами. Для Windows 7 нажмите «Пуск» и введите cmd в поле «Поиск». Щелкните правой кнопкой мыши на cmd, чтобы получить раскрывающийся список. В списке нажмите «Запуск от имени администратора».
2. Когда откроется окно командной строки, введите sfc /scannow и нажмите enter
   Процесс сканирования файлов поврежденных файлов занимает около 10-15 минут. Не закрывайте окно командной строки в течение этого времени.
3. После того, как система выполнит 100% сканирование, могут быть два результата. В случае, если не обнаружено ошибок, появится сообщение: «Защита Windows не обнаружила нарушений целостности».
   В случае обнаружения ошибки система обнаружит ошибки и устранит их.

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

В таких случаях команда sfc /scannow требует дополнительной информации о местонахождении диска, на котором установлена ​​Windows 7.

Запуск сканирование SFC /SCANNOW помимо командной строки

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

sfc /scannow /offbootdir=d: /offwindir=d:windows

Параметр /offbootdir = указывает букву диска, в то время как параметр / offwindir = указывает путь к Windows, снова включающий букву диска.

Примечание. В зависимости от того, как настроен ваш компьютер, командная строка при использовании извне Windows не всегда назначает буквы дисков так же, как вы видите их изнутри Windows. Другими словами, Windows может быть в C: Windows, когда вы ее используете, но D: Windows из командной строки в ASO или SRO.

В большинстве установок Windows 10, Windows 8 и Windows 7 C: обычно становится D: и в Windows Vista C: обычно остается C :. Чтобы убедиться в этом, найдите диск с папкой « Пользователи » на нем — это будет диск, на котором установлен Windows, если у вас нет нескольких установок Windows на нескольких дисках. Вы можете просматривать папки в командной строке с помощью команды dir .

DISM: проверка и восстановление системных компонентов образа Windows 10

DISM /Online /Cleanup-Image /ScanHealth

DISM /Online /Cleanup-Image /RestoreHealth

DISM /online /cleanup-image /restorehealth /source:F:sourcesinstall.wim

DISM /online /cleanup-image /restorehealth /source:F:sourcesinstall.esd

DISM /online /cleanup-image /restorehealth /source:F:sourcesinstall.wim /limitaccess

DISM /online /cleanup-image /restorehealth /source:F:sourcesinstall.esd /limitaccess

dism /online /cleanup-image /restorehealth /limitaccess

Восстановление поврежденного хранилища компонентов Windows 10/Server 2016 с помощью PowerShell

Repair-WindowsImage -Online –ScanHealth

Repair-WindowsImage -Online -RestoreHealth

Repair-WindowsImage -Online -RestoreHealth -Source F:sourcesinstall.wim:1

Get-WindowsImage -ImagePath "F:sourcesinstall.wim"

Для проверки целостности системных файлов и восстановления поврежденных файлов (библиотек) компонентов в Windows (Windows Server) можно использовать команды SFC и DISM. Эти две утилиты могут быть крайне полезными, если операционная система Windows работает нестабильно, появляются ошибки при запуске стандартных приложений или служб, после вирусного заражения и т.д.

В этой статье мы рассмотрим, как использовать команды
sfc /scannow
,
DISM /Online /Cleanup-Image /RestoreHealth
или
Repair-WindowsImage -Online -RestoreHealth
для восстановления образа и системных фалов в Windows 10/11 и Windows Server 2022/2019/2016.

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

Перед тем, как восстанавливать образ Windows с помощью DISM, рекомендуется сначала попробовать проверить целостность системных файлов с помощью утилиты SFC (System File Checker). Команда
sfc /scannow
позволяет проверить целостность системных файлов Windows. Если какие-то системные файлы отсутствуют или повреждены, утилита SFC попробует восстановить их оригинальные копии из хранилища системных компонентов Windows (каталог C:WindowsWinSxS).

Если команда sfc /scannow возвращает ошибку “
Программа защиты ресурсов Windows обнаружила повреждённые файлы, но не может восстановить некоторые из них / Windows Resource Protection found corrupt files but was unable to fix some of them
”, скорее всего утилита не смогла получить необходимые файла из хранилища компонентов (образа) Windows.

В этом случае вам нужно попробовать восстановить хранилище компонентов вашего образа Windows с помощью DISM.

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

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

Утилита DISM (Deployment Image Servicing and Management) доступна во всех версиях Windows, начиная с Vista.

Для сканирования образа Windows на наличие ошибок и их исправления используется параметр DISM /Cleanup-image. Команды DISM нужно запускать из командной строки, с правами администратора.

Чтобы проверить наличие признака повреждения хранилища компонентов в образе Windows (флаг CBS), выполните команду (не применимо к Windows 7/Server 2008R2):

DISM /Online /Cleanup-Image /CheckHealth

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

В этом примере команда вернула, что с образом все хорошо:

No component store corruption detected.
The operation completed successfully.

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

DISM /Online /Cleanup-Image /ScanHealth

Команда проверки образа Windows может выполняться довольно долго (от 10 до 30 минут). И вернет один из трех результатов:

• No component store corruption detected – DISM не обнаружил повреждения в хранилище компонентов;
• The component store is repairable – DISM обнаружил ошибки в хранилище компонентов и может исправить их;
• The component store is not repairable – DISM не может исправить хранилище компонентов Windows (попробуйте использовать более новую версию DISM или вам придется восстанавливать образ Windows из резервной копии, сбрасывать или полностью переустанавливать вашу копию Windows.

В Windows 7 и Windows Server 2008 R2 для использования параметра DISM /ScanHealth нужно установить отдельное обновление KB2966583. Иначе при запуске DISM будет появляться “
Ошибка 87. Параметр ScanHealth не распознан в этом контексте
”.

Команда DISM /ScanHealth может вернуть ошибки:

• Ошибка: 1726. Сбой при удалённом вызове процедуры;
• Ошибка: 1910. Не найден указанный источник экспорта объекта.

Это однозначно говорит о том, что ваш образ Windows поврежден и его нужно восстановить.

Восстановление образа Windows с помощью DISM /RestoreHealth

Чтобы исправить повреждения в хранилище компонентов образа Windows нужно использовать опцию RestoreHealth команды DISM. Эта опция позволит исправить найденные в образе ошибки, автоматически скачать и заменить файлы повреждённых или отсутствующих компонентов эталонными версиями файлов из центра обновлений Windows (на компьютере должен быть доступ в Интернет). Выполните команду:

DISM /Online /Cleanup-Image /RestoreHealth

В Windows 7/2008 R2 эта команда выглядит по другому:
DISM.exe /Online /Cleanup-Image /ScanHealth

Процесс сканирования и восстановления компонентов может быть довольно длительным (30 минут или более). DISM автоматически загрузит недостающие или поврежденные файлы образа с серверов Windows Update.

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

The restore operation completed successfully.

DISM /Source: восстановление образа Windows с установочного диска

Если на компьютере (сервере) отсутствует доступ в Интернет или отключена/повреждена служба Windows Update (как восстановить клиент Windows Update), то при восстановлении хранилища компонентов появятся ошибки:

• 0x800f0906 — Не удалось скачать исходные файлы. Укажите расположение файлов, необходимых для восстановления компонента, с помощью параметра Источник (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);
• Ошибка: 0x800f0950 — Сбой DISM. Операция не выполнена (0x800f0950 — DISM failed. No operation was performed);
• Ошибка:0x800F081F. Не удалось найти исходные файлы. Укажите расположение файлов, необходимых для восстановления компонента, с помощью параметра Источник (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).

<

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

• Установочный диск/флешка/iso образ Windows
• Смонтированный файл wim
• Папка sourcesSxS с установочного диска
• Файл install.wim с установочным образом Windows

Вы можете указать WIM или ESD файл с оригинальным установочным образом Windows, который нужно использовать в качестве источника для восстановления файлов системы. Предположим, вы смонтировали установочный ISO образ Windows 11 в виртуальный привод D:.

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

С помощью следующей PowerShell команды проверьте, какая версия Windows установлена на вашем компьютере:

Get-ComputerInfo |select WindowsProductName,WindowsEditionId,WindowsVersion, OSDisplayVersion

Выведите список доступных версий Windows в установочном образе:

Get-WindowsImage -ImagePath "D:sourcesinstall.wim"

В нашем случае образ Windows 11 Pro в образе install.wim имеет
ImageIndex = 6
.

Для восстановления хранилища компонентов из локального WIM/ESD файла с блокированием доступа в интернет, выполните следующую команду (не забудьте указать ваш индекс версии Windows в файле):

DISM /online /cleanup-image /restorehealth /source:WIM:D:sourcesinstall.wim:6  /limitaccess

Или:
DISM /online /cleanup-image /restorehealth /source:ESD:D:sourcesinstall.esd:6  /limitaccess

Утилита DISM пишет подробный журнал сканирования и восстановления системных файлов в файл
C:WindowsLogsDISMdism.log
.

После восстановления хранилища компонентов вы можете запустить утилиту проверки системных файлов
sfc /scannow
. Скорее всего она успешно восстановит поврежденные файлы:

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

Windows Resource Protection found corrupt files and successfully repaired them.

Если все системные файлы целы, появится сообщение:

Windows Resource Protection did not find any integrity violations

Восстановление образа Windows с помощью PowerShell

В версии PowerShell в Windows 10/11 и Windows Server 2022/2019 есть аналоги рассмотренных выше команд DISM. Для сканирования хранилища компонентов и поиска повреждений в образе выполните:

Repair-WindowsImage -Online –ScanHealth

Если ошибок в хранилище компонентов не обнаружено, появится сообщение:

ImageHealth State: Healthy

Для запуска восстановления системных компонентов и файлов наберите:


Repair-WindowsImage -Online -RestoreHealth


При отсутствии доступа к интернету эта команда может зависнуть в процессе восстановления образа. Вы можете восстановить системные компоненты из локальной копии образа Windows в виде WIM/ESD файла, скопированного с установочного ISO образа Windows 10 (здесь также нужно указать индекс версии Windows в wim файле в качестве источника восстановления):

Repair-WindowsImage -Online -RestoreHealth -Source D:sourcesinstall.wim:5 –LimitAccess

DISM: восстановление поврежденного хранилища компонентов, если Windows не загружается

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

1. Для этого загрузите компьютер с установочного образа Windows (проще всего создать загрузочную USB флешку с Windows 10/11 с помощью Media Creation Tool) и на экране начала установки нажмите
   Shift + F10
2. Чтобы разобраться с буквами дисков, назначенных в среде WinPE, выполните команду
   diskpart
   ->
   list vol
   (в моем примере диску, на котором установлена Windows присвоена буква C:, эту букву я буду использовать в следующих командах);
3. Проверим системные файлы и исправим поврежденные файлы командой:
   sfc /scannow /offbootdir=C: /offwindir=C:Windows
   
   
4. Для исправления хранилища компонентов используйте следующую команду (в качестве источника для восстановления компонентов мы используем WIM файл с установочным образом Windows 10, с которого мы загрузили компьютер):
   Dism /image:C: /Cleanup-Image /RestoreHealth /Source:WIM:D:sourcesinstall.wim:6
   
5. Если на целевом диске недостаточно места, то для извлечения временных файлов нам понадобится отдельный диск достаточного размера, например F:, на котором нужно создать пустой каталог:
   mkdir f:scratch
   и запустить восстановление хранилища компонентов командой:
   Dism /image:C: /Cleanup-Image /RestoreHealth /Source:D:sourcesinstall.wim /ScratchDir:F:scratch