Настройка диагностических данных windows в вашей организации (windows 10 и windows 11)

Необязательные данные

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

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

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

Внимание!

Приведенные в этой статье сведения относятся к Windows 11 и Windows 10 версии 1903 и более поздних версий.

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

IRP-система штатными средствами Windows

Как мы увидели, встроенный функционал подсистемы журналирования Windows позволяет весьма гибко осуществлять поиск по зафиксированным событиям аудита ИБ, комбинируя различные условия поиска. Однако, у Windows есть еще одна интересная «фишка», которая позволяет использовать сформированные описанным выше образом правила поиска событий — мы говорим про создание задач с определенным триггером в «Планировщике заданий» Windows, что также является штатным функционалом ОС.

Как мы знаем, задачи в ОС Windows могут выполнять совершенно разные функции, от запуска диагностических и системных утилит до обновления компонент прикладного ПО. В задаче можно не только указать исполняемый файл, который будет запущен при наступлении определенных условий и триггеров, но и задать пользовательский PowerShell/VBS/Batch-скрипт, который также будет передан на обработку. В контексте применения подсистемы журналирования интерес для нас представляет функционал гибкой настройки триггеров выполнения задач. Открыв «Планировщик заданий» (taskschd.msc), мы можем создать новую задачу, в свойствах которой на вкладке «Триггеры» мы увидим возможность создать свой триггер. При нажатии на кнопку «Создать» откроется новое окно, в котором в drop-down списке следует выбрать вариант «При событии», а в открывшейся форме отображения установить radio-button «Настраиваемое». После этих действий появится кнопка «Создать фильтр события», нажав на которую, мы увидим знакомое меню фильтрации событий, на вкладке XML в котором мы сможем задать произвольное поисковое условие в синтаксисе XPath-запроса.

Например, если мы хотим выполнять некоторую команду или скрипт при каждом интерактивном входе в систему пользователя Username, мы можем задать в качестве триггера задачи следующее поисковое выражение, уже знакомое нам по примеру выше:

Другой пример: оповещение администратора при подозрительном обращении к системному процессу lsass.exe, который хранит в своей памяти NTLM-хэши и Керберос-билеты пользователей Windows, что может говорить об использовании утилиты Mimikatz или аналогичных ей:

Сбор данных UAL

В дополнение к командлетам PowerShell, описанным в предыдущем разделе, для получения данных UAL можно использовать 12 дополнительных командлетов:

Get-UalOverview: предоставляет сведения, относящиеся к UAL, а также журнал установленных продуктов и ролей.
Get-UalServerUser: предоставляет данные о доступе пользователя клиента на локальный или целевой сервер.
Get-UalServerDevice: предоставляет данные о доступе устройства клиента на локальный или целевой сервер.
Get-UalUserAccess: предоставляет данные о доступе пользователя клиента к каждой роли или продукту, установленным на локальном или целевом сервере.
Get-UalDeviceAccess: предоставляет данные о доступе устройства клиента к каждой роли или продукту, установленным на локальном или целевом сервере.
Get-UalDailyUserAccess: предоставляет данные о доступе пользователя клиента за каждый день года.
Get-UalDailyDeviceAccess: предоставляет данные о доступе устройства клиента за каждый день года.
Get-UalDailyAccess: предоставляет данные о доступе как пользователя, так и устройства клиента за каждый день года.
Get-UalHyperV: предоставляет данные о виртуальной машине, относящиеся к локальному или целевому серверу.
Get-UalDns: предоставляет специальные данные DNS-клиента локального или целевого DNS-сервера.
Get-UalSystemId: предоставляет специальные системные данные для уникальной идентификации локального или целевого сервера.

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

Примечание

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

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

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

Значение «Активитикаунт» для каждого уникального клиента ограничено 65 535 в день. Вызов WMI из PowerShell также необходим только при запросе по дате. Все остальные параметры командлета UAL могут использоваться в рамках запросов PowerShell, как в следующем примере:

UAL позволяет хранить историю в течение двух лет. Чтобы разрешить получение данных UAL администратором при запуске службы, UAL создает копию активного файла базы данных Current. mdb в файле с именем GUID. mdb каждые 24 часа для использования поставщиком WMI.

В первый день года UAL создает новый GUID.mdb. Старый GUID. mdb сохраняется в качестве архива для использования поставщиком. По прошествии двух лет исходный GUID.mdb будет перезаписан.

Важно!

Следующая процедура должна выполняться только опытным пользователем или разработчиком, тестирующими свой собственный инструментарий интерфейсов программирования приложений UAL…

Настройка 24-часового интервала по умолчанию так, чтобы данные стали видимы поставщику WMI

Выполните вход на сервер с помощью учетной записи с правами локального администратора.
Нажмите клавишу с эмблемой Windows + R, а затем введите cmd, чтобы открыть окно командной строки.
Добавьте значение реестра: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\WMI\AutoLogger\Sum\PollingInterval (REG_DWORD).

Предупреждение

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

В следующем примере показано, как добавить двухминутный интервал (не рекомендуется в качестве долгосрочного рабочего состояния). REG ADD HKLM\System\CurrentControlSet\Control\WMI\AutoLogger\Sum /v PollingInterval /t REG_DWORD /d 120000 /F

Единица измерения времени — миллисекунды. Минимальное значение — 60 секунд, максимальное — семь дней, а значение по умолчанию — 24 часа.
Для остановки и перезапуска службы ведения журнала доступа пользователей используйте консоль служб.

Настройка сервера для отправки логов на центральный сервер

Первым делом вы должны настроить ваши сервера на отправку событий. Я для примера это буду делать для контроллеров домена. Чтобы у вас все работало, вам нужно включить службу для удаленного управления WinRM. Открывайте командную строку от имени администратора и введите команду:

winrm qc или winrm quickconfig

Либо так же через PowerShell:

Enable-PSRemoting

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

Вы предоставите нужные права учетной записи компьютера, что по мне правильнее
Либо можно производить подключение от имени доменной учетной записи (Можно и не доменной, но я рассматриваю исключительно окружение Active Directory)

Все, что нам нужно это предоставить учетной записи членство в локальной группе «Читатели журнала событий (Event Log Readers)»

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

Для того чтобы дать права, откройте оснастку «Active Directory — Пользователи и компьютеры» и перейдите в раздел Bultin. Тут будет группа «Читатели журнала событий (Event Log Readers)». Добавьте в нее пользователя или учетную запись компьютера, кому вы назначаете права (Члены этой группы могут читать журналы событий с локального компьютера)

Еще очень важно дать учетной записи Network Service право на чтение, иначе вы будите получать ошибку 0x138C:

Error — Last retry time: 02.09.2022 12:40:22. Code (0x138C): <f:ProviderFault provider=»Event Forwarding Plugin» path=»C:\Windows\system32\wevtfwd.dll» xmlns:f=»http://schemas.microsoft.com/wbem/wsman/1/wsmanfault»><t:ProviderError xmlns:t=»http://schemas.microsoft.com/wbem/wsman/1/windows/EventLog»>Windows Event Forward plugin can’t read any event from the query since the query returns no active channel. Please check channels in the query and make sure they exist and you have access to them.</t:ProviderError></f:ProviderFault> Next retry time: 02.09.2022 13:00:22.

Причина ошибки 0x138C, заключается в том, что служба удаленного управления Windows запускается под учетной записью сетевой службы. Нужно добавить SID учетной записи сетевой службы в разрешения на доступ к каналу журнала событий безопасности. Для начала давайте на контроллере домена, с которого я буду отправлять логи посмотрим текущие разрешения, сделать это можно в командной строке Windows.

wevtutil gl security или Wevtutil get-log security

Видим текущий канал безопасности:

channelAccess: O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)

Нам нужно в самый конец добавить SID Network Service. Это стандартный SID (A;;0x1;;;S-1-5-20). Команда будет выглядеть вот так:

wevtutil set-log security /ca:O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20)

или

wevtutil sl security /ca:O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20)

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

Чтобы назначить массово права для Network Service, вы можете воспользоваться преимуществами Active Directory и создать на нужном OU групповую политику, в которой нужно перейти:

(Computer Configuration — Policies — Windows Settings — Security Settings — Restricted Groups)

Тут вам нужно через правый клик добавить группу «Event Log Readers».

Далее вам нужно ее отредактировать, добавив туда Network Service и все остальные группы, для которых вы выдаете права.

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

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

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet \Services\EventLog\Security

Тут будет ключ реестра CustomSD. В CustomSD вы увидите ту самую строку channelAccess. При желании вы можете отредактировать ключ, добавив нужный SID. Так же данный ключ можно менять централизованно через GPO, но это сложнее, чем Restricted Groups.

На этом настройка серверов отдающих логи Windows можно считать законченным, переходим к настройке сервера сборщика логов.

Включение конфигурации обработчика диагностических данных Windows

Важно!

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

Конфигурация обработчика диагностических данных Windows позволяет вам быть управляющим (в соответствии с определением в Общем регламенте Европейского Союза по защите данных (GDPR)) диагностическими данными Windows, собранными с ваших устройств Windows, которые соответствуют требованиям к конфигурации.

Предварительные условия

Использование поддерживаемой версии Windows 10 или Windows 11
Поддерживаются следующие выпуски:
- Корпоративная
- Профессиональная
- Education
Устройство должно быть присоединено к Azure Active Directory (может использоваться гибридное присоединение к Azure AD).

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

Для параметра диагностических данных на устройстве следует задать значение «Обязательные диагностические данные» или выше. Должны быть доступны следующие конечные точки:

v10c.events.data.microsoft.com
umwatsonc.events.data.microsoft.com
kmwatsonc.events.data.microsoft.com
settings-win.data.microsoft.com
*.blob.core.windows.net

Включение конфигурации обработчика диагностических данных Windows

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

Чтобы включить конфигурацию обработчика диагностических данных Windows средствами групповой политики, перейдите в раздел Конфигурация компьютера > Административные шаблоны > Компоненты Windows > Сбор данных и предварительные сборки и переключите параметр Разрешить конвейер коммерческих данных в положение Включено.

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

Чтобы использовать решение MDM (например, Microsoft Intune) для развертывания конфигурации обработчика диагностических данных Windows на поддерживаемых устройствах, используйте следующую конфигурацию настройки OMA-URI.

Имя: System/AllowCommercialDataPipeline
OMA-URI: ./Vendor/MSFT/Policy/Config/System/AllowCommercialDataPipeline
Тип данных: целое число

В разделе Значение выберите 1, чтобы включить службу.

Если вы хотите ее отключить, можно в любой момент переключить параметр на . Значение по умолчанию — .

Примечание

Если у вас есть дополнительные политики, которые позволяют быть управляющим диагностическими данными Windows, например политики перечисленных ниже служб, необходимо отключить все применимые политики, чтобы перестать быть управляющим диагностическими данными Windows.
Диагностические данные Windows, собранные с устройства до включения с конфигурацией обработчика диагностических данных Windows, будут удалены при включении этой конфигурации.
Когда вы включите устройства с конфигурацией обработчика диагностических данных Windows, пользователи смогут и дальше отправлять отзывы через различные каналы, такие как Центр отзывов о Windows или о Microsoft Edge. Однако к данным отзывов не применяются условия конфигурации обработчика диагностических данных Windows. Если это нежелательно, рекомендуется отключить обратную связь с помощью доступных политик или решений для управления приложениями.

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

Сведения об этих службах и настройке групповых политик можно найти в следующей документации:

Аналитика компьютеров:

Включение общего доступа к данным для Аналитики компьютеров
Конфиденциальность данных в Аналитике компьютеров
Параметры групповой политики для Аналитики компьютеров

Поддержка обновлений:

Конфиденциальность в Поддержке обновлений

Компьютеры, управляемые Майкрософт:

Конфиденциальность и персональные данные

Центр обновления Windows для бизнеса:

Как включить защиту развертывания

Настройка сбора данных о событиях

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

Настройка автономного датчика Defender для удостоверений для прослушивания событий SIEM
настройка пересылки событий Windows.

Примечание

Автономные датчики Defender для удостоверений не поддерживают сбор записей журнала трассировки событий Windows (ETW), которые предоставляют данные для нескольких обнаружений. Для полного охвата среды рекомендуется развернуть датчик Defender для удостоверений.

Как определить подозрительную активность на сервере Windows

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

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

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

На что обращать внимание в отчетах Windows

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

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

Как уже говорилось выше, события записываются в журнал событий в Windows. Три основных типа собственных журналов:

Безопасность.
Заявка.
Система.

XpoLog7

XpoLog7 автоматизированный инструмент управления журналами, обеспечивающий:

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

Базовый план бесплатный навсегда за 0,5 ГБ / день. Для тех, кто нуждается в большем количестве функций, Xpolog7 также предлагает несколько уровней варианты ценообразования,

Соответствующие события Windows

Для событий служб федерации Active Directory (AD FS)

1202 — служба федерации проверила новые учетные данные.
1203 — службе федерации не удалось проверить новые учетные данные.
4624 — учетная запись успешно использована для входа в систему.
4625 — учетную запись не удалось использовать для входа в систему.

Для других событий

1644 — поиск LDAP
4662 — с объектом выполнена операция
4726 — удаление учетной записи пользователя
4728 — добавление участника в глобальную группу безопасности
4729 — удаление участника из глобальной группы безопасности
4730 — удаление глобальной группы безопасности
4732 — добавление участника в локальную группу безопасности
4733 — удаление участника из локальной группы безопасности
4741 — добавление учетной записи компьютера
4743 — удаление учетной записи компьютера
4753 — удаление глобальной группы рассылки
4756 — добавление участника в универсальную группу безопасности
4757 — удаление участника из универсальной группы безопасности
4758 — удаление универсальной группы безопасности
4763 — удаление универсальной группы рассылки
4776 — попытка проверки данных учетной записи контроллером домена (NTLM)
5136 — изменен объект службы каталогов
7045 — установка новой службы
8004 — проверка подлинности NTLM

Централизованный сбор логов в Windows

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

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

Что я хочу:

Иметь один сервер на который будут складываться все события с контроллеров домена и нужного мне списка серверов
Настроить нужные мне серверы на отправку определенных событий на заданный сервер
Возможность предоставления прав на централизованный сервер хранения логов для представителей хелпдеска
Не устанавливать никакой дополнительный софт

Выглядит схематично это вот так. Тут у нас будут вот такие сущности:

Сервер собирающий события (Collector Initiated) — Это и есть наш центральный сервер по сбору событий, мы будим его еще называть коллектор логов. В качестве данного сервера будет выступать виртуальная машина с Windows Server 2022.
Сервер отправляющий события на центральный сервер (Source initiated). Тут по сути может выступать любая операционная система Windows.

Проверьте свою историю веб-поиска

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

Программы для Windows, мобильные приложения, игры — ВСЁ БЕСПЛАТНО, в нашем закрытом телеграмм канале — Подписывайтесь:)

Используя Google Chrome, нажмите на три точки в верхнем правом углу и нажмите «История».

Другой способ получить доступ к истории вашего компьютера в Chrome — использовать сочетание клавиш Ctrl + H.
В Firefox перейдите к значку в верхней панели, который похож на изображение ниже, и щелкните по нему.

В Microsoft Edge в правом верхнем углу окна найдите и щелкните значок падающей звезды. Затем нажмите на историю.

Сценарий установки Windows

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

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

Если в программе установки Windows возникает сбой, сначала просмотрите записи в файле Setuperr.log, а затем второй файл Setupact.log, а затем другие файлы журнала по мере необходимости.

Файлы журналов Windows Setup-Related

Файл журнала
Описание
Расположение
Setupact.log
Основной файл журнала для большинства ошибок, которые происходят в процессе установки Windows. Существует несколько экземпляров файла Setupact.log в зависимости от того, какой момент в процессе установки происходит сбой

Важно знать, какую версию файла Setupact.log следует просмотреть на основе этапа, на котором вы находитесь.

Настройка (специализируется): X:\Windows\panther
Настройка (OOBE), LogonUI, OEM First Run:%windir%\panther
Интерфейс out-of-Box (OOBE): %windir%\panther\unattendGC

Setuperr.log
Общий список ошибок, возникших на этапе специализировать программу установки. Файл Setuperr.log не предоставляет никаких конкретных сведений.

Настройка (специализируется): %windir%\panther
Настройка (специализируется): %windir%\panther
Настройка (OOBE), LogonUI, OEM First Run: %windir%\panther

Setupapi.offline.log
Сбои драйвера во время подфазы специализации компонентов этапа специализации установки.
%windir%\inf
Cbs_unattend.log
Сбои обслуживания автоматической установки.
%windir%\panther
Setupapi.dev.log
Сбои драйвера на этапе запуска программы установки.
%windir%\inf
Sessions.xml
XML-файл журнала транзакций, который отслеживает все действия обслуживания на основе идентификатора сеанса, клиента, состояния, задач и действий

При необходимости файл Sessions.log будет указывать на файлы DISM.log и CBS.log для получения дополнительных сведений.
%windir%\servicing\sessions
CBS.log
Файл журнала обслуживания, который содержит дополнительные сведения о сбоях автономного обслуживания.
%windir%\panther

Управление диагностическими данными с помощью групповой политики и MDM

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

Важно!

Эти параметры диагностических данных применяются только к компонентам, функциям и приложениям, которые считаются частью операционной системы Windows. Устанавливаемые пользователями приложения сторонних разработчиков и другие приложения Майкрософт, такие как Microsoft Office, также могут собирать и отправлять диагностические данные с использованием собственных средств управления. Обратитесь к своим поставщикам приложений, чтобы изучить их политику диагностических данных и правила согласия и отказа. Дополнительные сведения об использовании диагностических данных в Microsoft Office см. в разделе Общие сведения об элементах управления конфиденциальностью в приложениях Microsoft 365 для предприятий. Сведения об управлении сбором данных Windows, отличных от диагностических данных Windows, см. в статье Управление подключениями компонентов операционной системы Windows к службам Майкрософт.

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

При настройке политики управления используйте соответствующее значение в таблице ниже.

Категория	Значение
Диагностические данные отключены (безопасность)
Обязательные (базовые)	1
Расширенный	2
Необязательные (полные)	3

Примечание

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

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

Для управления параметрами диагностических данных в организации можно использовать групповую политику:

В консоли управления групповыми политиками выберите Конфигурация компьютера > Административные шаблоны > Компоненты Windows > Сборки для сбора данных и предварительные сборки.
Дважды щелкните Разрешить телеметрию (или Разрешить диагностические данные в Windows 11 и Windows Server 2022).

Примечание

Если на устройствах в вашей организации используется Windows 10 версии 1803 или более поздней версии, пользователи по-прежнему могут устанавливать более строгие ограничения для диагностических данных с помощью параметров, когда не установлена политика Настройка пользовательского интерфейса для участия в сборе диагностических данных.
В окне Параметры выберите параметр, который нужно настроить, и нажмите кнопку ОК.

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

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

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

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

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

Используйте поставщика службы конфигурации (CSP) политики, чтобы применить указанные ниже политики MDM.

System/AllowTelemetry
System/LimitDumpCollection
System/LimitDiagnosticLogCollection

Примечание

Последние две политики доступны только в Windows 11 и Windows Server 2022.