Программа для логирования файл сервера на windows 2018: Просмотр и анализ логов RDP подключений в Windows

Просмотр и анализ логов RDP подключений в Windows

В этой статье мы рассмотрим, как получить и проанализировать логи RDP подключений в Windows. Логи RDP подключений позволяют администраторам терминальных RDS серверов/ферм получить информацию о том, какие пользователи подключались к серверу, когда был выполнен вход и когда сеанс завершен, с какого устройства (имя или IP адрес) подключался пользователь.

Описанные методики получения и исследования RDP логов применима как к Windows Server 2022/2019/2016/2012R2, так и для десктопных версий Windows 11, 10, 8.1 c.

Содержание:

• События RDP подключений в журналах Windows (Event Viewer)
• Получаем логи RDP подключений в Windows с помощью PowerShell
• Логи RDP подключений на клиентах Windows

События RDP подключений в журналах Windows (Event Viewer)

Когда пользователь удаленно подключается к RDS серверу или удаленному столу Windows (RDP), информация об этих событиях сохраняется в журналы Windows. Рассмотрим основные этапы RDP подключения и связанные с ними события в Event Viewer.

1. Network Connection
2. Authentication
3. Logon
4. Session Disconnect/Reconnect
5. Logoff

Network Connection: – событие установления сетевого подключение к серверу от RDP клиента пользователя. Событие с EventID – 1149 (Remote Desktop Services: User authentication succeeded). Наличие этого события не свидетельствует об успешной аутентификации пользователя. Этот журнал находится в разделе Applications and Services Logs -> Microsoft -> Windows -> Terminal-Services-RemoteConnectionManager -> Operational. Включите фильтр по данному событию (ПКМ по журналу-> Filter Current Log -> EventId 1149).

С помощью PowerShell моно вывести список всех попыток RDP подключений:

$RDPAuths = Get-WinEvent -LogName 'Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational' -FilterXPath '<QueryList><Query><Select>*[System[EventID=1149]]</Select></Query></QueryList>'
[xml[]]$xml=$RDPAuths|Foreach{$_. ToXml()}
$EventData = Foreach ($event in $xml.Event)
{ New-Object PSObject -Property @{
TimeCreated = (Get-Date ($event.System.TimeCreated.SystemTime) -Format 'yyyy-MM-dd hh:mm:ss K')
User = $event.UserData.EventXML.Param1
Domain = $event.UserData.EventXML.Param2
Client = $event.UserData.EventXML.Param3
}
} $EventData | FT

В результате у вас получится список с историей всех сетевых RDP подключений к данному серверу. В событии содержится имя пользователя, домен (если используется NLA аутентификация, при отключенном NLA текст события выглядит иначе) и IP адрес компьютера пользователя.

Authentication: – успешная или неудачная аутентификация пользователя на сервере. Журнал Windows -> Security. Здесь нас могут интересовать события с EventID – 4624 (успешная аутентификация — An account was successfully logged on) или 4625 (ошибка аутентификации — An account failed to log on). Обратите внимание на значение LogonType в событии.

• LogonType = 10 или 3 — при входе через терминальную службу RDP —.
• LogonType = 7, значит выполнено переподключение к уже существующему RDP сеансу.
• LogonType = 5 – событие RDP подключения к консоли сервера (в режиме mstsc.exe /admin)

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

При этом имя пользователя содержится в описании события в поле Account Name, имя компьютера в Workstation Name, а имя пользователя в Source Network Address.

Обратите внимание на значение поля LogonID – это уникальный идентификатор сессии пользователя, с помощью которого можно отслеживать дальнейшую активность данного пользователя. Но при отключении от RDP сессии (disconnect) и повторного переподключения к той же сессии, пользователю будет выдан новый TargetLogonID (хотя RDP сессия осталась той же самой).

Вы можете получить список событий успешных авторизаций по RDP (событие 4624) с помощью такой команды PowerShell.

Get-EventLog security -after (Get-date -hour 0 -minute 0 -second 0) | ?{$_.eventid -eq 4624 -and $_.Message -match 'logon type:\s+(10)\s'} | Out-GridView

Logon: – RDP вход в систему, EventID – 21 (Remote Desktop Services: Session logon succeeded. Это событие появляется после успешной аутентификации пользователя. Этот журнал находится в разделе Applications and Services Logs -> Microsoft -> Windows -> TerminalServices-LocalSessionManager -> Operational. Как вы видите, здесь можно узнать идентификатор RDP сессии для пользователя — Session ID.

Событие с EventID – 21 (Remote Desktop Services: Shell start notification received) означает успешный запуск оболочки Explorer (появление окна рабочего стола в RDP сессии).

Session Disconnect/Reconnect – события отключения и переподключения к сессии имеют разные коды в зависимости от того, что вызвало отключение пользователя (отключение по неактивности, заданному в таймаутах для RDP сессий; выбор пункта Disconnect в сессии; завершение RDP сессии другим пользователем или администратором и т.д.). Эти события находятся в разделе журналов Applications and Services Logs -> Microsoft -> Windows -> TerminalServices-LocalSessionManager -> Operational. Рассмотрим RDP события, которые могут быть полезными:

• EventID – 24 (Remote Desktop Services: Session has been disconnected) – пользователь отключился от RDP сессии.
• EventID – 25 (Remote Desktop Services: Session reconnection succeeded) – пользователь переподключился к своей имеющейся RDP сессии на сервере.
• EventID – 39 (Session <A> has been disconnected by session <B>) – пользователь сам отключился от своей RDP сессии, выбрав соответствующий пункт меню (а не просто закрыл окно RDP клиента). Если идентификаторы сессий разные, значит пользователя отключил другой пользователь (или администратор).
• EventID – 40 (Session <A> has been disconnected, reason code <B>). Здесь нужно смотреть на код причины отключения в событии. Например:
  • reason code 0 (No additional information is available) – обычно говорит о том, что пользователь просто закрыл окно RDP клиента.
  • reason code 5 (The client’s connection was replaced by another connection) – пользователь переподключился к своей старой сессии.
  • reason code 11 (User activity has initiated the disconnect) – пользователь сам нажал на кнопку Disconnect в меню.

Событие с EventID – 4778 в журнале Windows -> Security (A session was reconnected to a Window Station). Пользователь переподключился к RDP сессии (пользователю выдается новый LogonID).

Событие с EventID 4779 в журнале Windows -> Security (A session was disconnected from a Window Station). Отключение от RDP сеанса.

Logoff: – выход пользователя из системы. При этом в журнале Applications and Services Logs -> Microsoft -> Windows -> TerminalServices-LocalSessionManager -> Operational регистрируется событие с EventID 23 (Remote Desktop Services: Session logoff succeeded).

При этом в журнале Security нужно смотреть событие EventID 4634 (An account was logged off).

Событие Event 9009 (The Desktop Window Manager has exited with code (<X>) в журнале System говорит о том, что пользователь инициировал завершение RDP сессии, и окно и графический shell пользователя был завершен.

EventID 4647 — User-initiated logoff

Получаем логи RDP подключений в Windows с помощью PowerShell

Ниже представлен небольшой PowerShell скрипт, который выгружает из журналов терминального RDS сервера историю всех RDP подключений за текущий день. В полученной таблице указано время подключения, IP адрес клиента и имя пользователя (при необходимости вы можете включить в отчет другие типы входов). \s]+)\s+.*’,’$1′
})
} | sort TimeGenerated -Descending | Select TimeGenerated, ClientIP `
, @{N=’Username’;E={‘{0}\{1}’ -f $_.UserDomain,$_.UserName}} `
, @{N=’LogType’;E={
switch ($_.LogonType) {
2 {‘Interactive — local logon’}
3 {‘Network conection to shared folder)’}
4 {‘Batch’}
5 {‘Service’}
7 {‘Unlock (after screensaver)’}
8 {‘NetworkCleartext’}
9 {‘NewCredentials (local impersonation process under existing connection)’}
10 {‘RDP’}
11 {‘CachedInteractive’}
default {«LogType Not Recognised: $($_.LogonType)»}
}
}}

Этот способ позволяет получить RDP логи со отдельностоящего RDSH сервера. Если у вас несколько серверов в ферме RDS, можно опросить этим скриптом каждый из них, либо получить логи с сервера с ролью Remote Desktop Connection Broker.

Можно экспортировать логи RDP подключений из журнала в CSV файл (для дальнейшего анализа в таблице Excel). Экспорт журнала можно выполнить из консоли Event Viewer (при условии что логи не очищены) или через командную строку:

WEVTUtil query-events Security > c:\ps\security_log. txt

Или с помощью PowerShell:

get-winevent -logname "Microsoft-Windows-TerminalServices-LocalSessionManager/Operational" | Export-Csv c:\ps\rdp-log.csv  -Encoding UTF8

Если ваши пользователи подключаются к RDS серверам через шлюз удаленных рабочих столов Remote Desktop Gateway, вы можете обрабатывать логи подключений пользователей по журналу Microsoft-Windows-TerminalServices-Gateway по EventID 302. Например, следующий PowerShell скрипт выведет полную историю подключений через RD Gateway указанного пользователя:

$rdpusername="kbuldogov"
$properties = @(
@{n='User';e={$_.Properties[0].Value}},
@{n='Source IP Adress';e={$_.Properties[1].Value}},
@{n='TimeStamp';e={$_.TimeCreated}}
@{n='Target RDP host';e={$_.Properties[3].Value}}
)
(Get-WinEvent -FilterHashTable @{LogName='Microsoft-Windows-TerminalServices-Gateway/Operational';ID='302'} | Select-Object $properties) -match $rdpusername

Список текущих RDP сессий на сервере можно вывести командой:

qwinsta

Команда возвращает как идентификатор сессии (ID), имя пользователя (USERNAME)и состояние (Active/Disconnect). Эту команду удобна использовать, когда нужно определить ID RDP сессии пользователя при теневом подключении.

Список запущенных процессов в конкретной RDP сессии (указывается ID сессии):

qprocess /id:157

Логи RDP подключений на клиентах Windows

Также вы можете изучать логи исходящих подключений на стороне RDP клиента. Они доступны в журнале событий Application and Services Logs -> Microsoft -> Windows -> TerminalServices-ClientActiveXCore -> Microsoft-Windows-TerminalServices-RDPClient -> Operation.

Например, событие с Event ID 1102 появляется, когда компьютер устанавливает подключение с удаленным RDS хостом Windows Server или компьютером с Windows 10/11 с включенной службой RDP (десктопные версии Windows также поддерживают несколько одновременных rdp подключений).

The client has initiated a multi-transport connection to the server 192.168.31.102.

Следующий RDP скрипт выведет историю RDP подключений на указанном компьютере:

$properties = @(
@{n='TimeStamp';e={$_. TimeCreated}}
@{n='LocalUser';e={$_.UserID}}
@{n='Target RDP host';e={$_.Properties[1].Value}}
)
Get-WinEvent -FilterHashTable @{LogName='Microsoft-Windows-TerminalServices-RDPClient/Operational';ID='1102'} | Select-Object $properties

Скрипт возвращает SID пользователей, которые инициировали RDP подключения на этом компьютере и DNS имена/IP адреса серверов, к которым подключались пользователи. Вы можете преобразовать SID в имена пользователей.

Также история RDP подключений пользователя хранится в реестре.

Вертим логи как хотим ― анализ журналов в системах Windows / Хабр

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

В статье не будет про серьезные вещи вроде Splunk и ELK (Elasticsearch + Logstash + Kibana). Сфокусируемся на простом и бесплатном.

До появления PowerShell можно было использовать такие утилиты cmd как find и findstr. Они вполне подходят для простой автоматизации. Например, когда мне понадобилось отлавливать ошибки в обмене 1С 7.7 я использовал в скриптах обмена простую команду:

findstr "Fail" *.log >> fail.txt

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

Основным инструментом для работы с текстовыми журналами является командлет Get-Content, предназначенный для отображения содержимого текстового файла. Например, для вывода журнала сервиса WSUS в консоль можно использовать команду:

Get-Content -Path 'C:\Program Files\Update Services\LogFiles\SoftwareDistribution.log' | Out-Host -Paging

Для вывода последних строк журнала существует параметр Tail, который в паре с параметром Wait позволит смотреть за журналом в режиме онлайн. Посмотрим, как идет обновление системы командой:

>Get-Content -Path "C:\Windows\WindowsUpdate.log" -Tail 5 -Wait

Смотрим за ходом обновления Windows.

Если же нам нужно отловить в журналах определенные события, то поможет командлет Select-String, который позволяет отобразить только строки, подходящие под маску поиска. Посмотрим на последние блокировки Windows Firewall:

Select-String -Path "C:\Windows\System32\LogFiles\Firewall\pfirewall.log" -Pattern 'Drop' | Select-Object -Last 20 | Format-Table Line

Смотрим, кто пытается пролезть на наш дедик.

При необходимости посмотреть в журнале строки перед и после нужной, можно использовать параметр Context. Например, для вывода трех строк после и трех строк перед ошибкой можно использовать команду:

Select-String 'C:\Windows\Cluster\Reports\Cluster.log' -Pattern ' err ' ‑Context 3

Оба полезных командлета можно объединить. Например, для вывода строк с 45 по 75 из netlogon. log поможет команда:

Get-Content 'C:\Windows\debug\netlogon.log' | Select-Object -First 30 -Skip 45

Журналы системы ведутся в формате .evtx, и для работы с ними существуют отдельные командлеты. Для работы с классическими журналами («Приложение», «Система», и т.д.) используется Get-Eventlog. Этот командлет удобен, но не позволяет работать с остальными журналами приложений и служб. Для работы с любыми журналами, включая классические, существует более универсальный вариант ― Get-WinEvent. Остановимся на нем подробнее.

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

Get-WinEvent -ListLog *

Вывод доступных журналов и информации о них.

Для просмотра какого-то конкретного журнала нужно лишь добавить его имя. Для примера получим последние 20 записей из журнала System командой:

Get-WinEvent -LogName 'System' -MaxEvents 20

Последние записи в журнале System.

Для получения определенных событий удобнее всего использовать хэш-таблицы. Подробнее о работе с хэш-таблицами в PowerShell можно прочитать в материале Technet about_Hash_Tables.

Для примера получим все события из журнала System с кодом события 1 и 6013.

Get-WinEvent -FilterHashTable @{LogName='System';ID='1','6013'}

В случае если надо получить события определенного типа ― предупреждения или ошибки, ― нужно использовать фильтр по важности (Level). Возможны следующие значения:

• 0 ― всегда записывать;
• 1 ― критический;
• 2 ― ошибка;
• 3 ― предупреждение;
• 4 ― информация;
• 5 ― подробный (Verbose).

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

Get-WinEvent -FilterHashtable @{LogName='system'} | Where-Object -FilterScript {($_. Level -eq 2) -or ($_.Level -eq 3)}

Ошибки и предупреждения журнала System.

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

Подробнее почитать про работу обоих командлетов для работы с системными журналами можно в документации PowerShell:

• Get-EventLog.
• Get-WinEvent.

PowerShell ― механизм удобный и гибкий, но требует знания синтаксиса и для сложных условий и обработки большого количества файлов потребует написания полноценных скриптов. Но есть вариант обойтись всего-лишь SQL-запросами при помощи замечательного Log Parser.

Утилита Log Parser появилась на свет в начале «нулевых» и с тех пор успела обзавестись официальной графической оболочкой. Тем не менее актуальности своей она не потеряла и до сих пор остается для меня одним из самых любимых инструментов для анализа логов. Загрузить утилиту можно в Центре Загрузок Microsoft, графический интерфейс к ней ― в галерее Technet. О графическом интерфейсе чуть позже, начнем с самой утилиты.

О возможностях Log Parser уже рассказывалось в материале «LogParser — привычный взгляд на непривычные вещи», поэтому я начну с конкретных примеров.

Для начала разберемся с текстовыми файлами ― например, получим список подключений по RDP, заблокированных нашим фаерволом. Для получения такой информации вполне подойдет следующий SQL-запрос:

SELECT 
 extract_token(text, 0, ' ') as date, 
 extract_token(text, 1, ' ') as time,
 extract_token(text, 2, ' ') as action, 
 extract_token(text, 4, ' ') as src-ip,  
 extract_token(text, 7, ' ') as port 
FROM 'C:\Windows\System32\LogFiles\Firewall\pfirewall.log' 
WHERE action='DROP' AND port='3389'
ORDER BY date,time DESC

Посмотрим на результат:

Смотрим журнал Windows Firewall.

Разумеется, с полученной таблицей можно делать все что угодно ― сортировать, группировать. Насколько хватит фантазии и знания SQL.

Log Parser также прекрасно работает с множеством других источников. Например, посмотрим откуда пользователи подключались к нашему серверу по RDP.

Работать будем с журналом TerminalServices-LocalSessionManager\Operational.

Не со всеми журналами Log Parser работает просто так ― к некоторым он не может получить доступ. В нашем случае просто скопируем журнал из %SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx в %temp%\test.evtx.

Данные будем получать таким запросом:

SELECT
 timegenerated as Date, 
 extract_token(strings, 0, '|') as user,
 extract_token(strings, 2, '|') as sourceip 
FROM '%temp%\test.evtx'
WHERE EventID = 21
ORDER BY Date DESC

Смотрим, кто и когда подключался к нашему серверу терминалов.

Особенно удобно использовать Log Parser для работы с большим количеством файлов журналов ― например, в IIS или Exchange. Благодаря возможностям SQL можно получать самую разную аналитическую информацию, вплоть до статистики версий IOS и Android, которые подключаются к вашему серверу.

В качестве примера посмотрим статистику количества писем по дням таким запросом:

SELECT
 TO_LOCALTIME(TO_TIMESTAMP(EXTRACT_PREFIX(TO_STRING([#Fields: date-time]),0,'T'), 'yyyy-MM-dd')) AS Date,
 COUNT(*) AS [Daily Email Traffic] 
FROM 'C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\MessageTracking\*.LOG'
WHERE (event-id='RECEIVE') GROUP BY Date ORDER BY Date ASC

Если в системе установлены Office Web Components, загрузить которые можно в Центре загрузки Microsoft, то на выходе можно получить красивую диаграмму.

Выполняем запрос и открываем получившуюся картинку…

Любуемся результатом.

Следует отметить, что после установки Log Parser в системе регистрируется COM-компонент MSUtil.LogQuery. Он позволяет делать запросы к движку утилиты не только через вызов LogParser.exe, но и при помощи любого другого привычного языка. В качестве примера приведу простой скрипт PowerShell, который выведет 20 наиболее объемных файлов на диске С.

$LogQuery = New-Object -ComObject "MSUtil.LogQuery"
$InputFormat = New-Object -ComObject "MSUtil.LogQuery.FileSystemInputFormat"
$InputFormat.Recurse = -1
$OutputFormat = New-Object -ComObject "MSUtil.LogQuery.CSVOutputFormat"
$SQLQuery = "SELECT Top 20 Path, Size INTO '%temp%\output.csv' FROM 'C:\*.*' ORDER BY Size DESC"
$LogQuery.ExecuteBatch($SQLQuery, $InputFormat, $OutputFormat)
$CSV = Import-Csv  $env:TEMP'\output.csv'
$CSV | fl 
Remove-Item $env:TEMP'\output.csv'
$LogQuery=$null
$InputFormat=$null
$OutputFormat=$null

Ознакомиться с документацией о работе компонента можно в материале Log Parser COM API Overview на портале SystemManager.ru.

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

Интерфейс Log Parser Studio.

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

Вторая особенность ― возможность экспорта запроса в скрипт PowerShell.

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

Выборка наиболее активных ящиков.

При этом можно выбрать куда больше типов журналов. Например, в «чистом» Log Parser существуют ограничения по типам входных данных, и отдельного типа для Exchange нет ― нужно самостоятельно вводить описания полей и пропуск заголовков. В Log Parser Studio нужные форматы уже готовы к использованию.

Помимо Log Parser, с логами можно работать и при помощи возможностей MS Excel, которые упоминались в материале «Excel вместо PowerShell». Но максимального удобства можно достичь, подготавливая первичный материал при помощи Log Parser с последующей обработкой его через Power Query в Excel.

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

Обзор диспетчера ресурсов файлового сервера (FSRM)

Обратная связь

Редактировать

Твиттер

LinkedIn

Фейсбук

Эл. адрес

• Статья
• 29.07.2021
• 4 минуты на чтение

Применяется к: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2

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

Мелочь, но мы также добавили возможность отключать журналы изменений в Windows Server версии 1803.

Возможности

Диспетчер ресурсов файлового сервера включает следующие функции:

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

Инфраструктура классификации файлов

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

Отчеты о хранилище

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

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

Важно

Диспетчер ресурсов файлового сервера поддерживает только тома, отформатированные в файловой системе NTFS. Устойчивая файловая система не поддерживается.

Практические приложения

Некоторые практические приложения для диспетчера ресурсов файлового сервера включают:

• Использование инфраструктуры классификации файлов со сценарием динамического контроля доступа для создания политики, которая предоставляет доступ к файлам и папкам на основе того, как файлы классифицируются на основе файловый сервер.

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

• Срок действия любого файла, который не изменялся в течение последних 10 лет, истекает.

• Создайте квоту в 200 мегабайт для домашнего каталога каждого пользователя и уведомляйте их, когда они используют 180 мегабайт.

• Запретить хранение музыкальных файлов в личных общих папках.

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

Что нового: запретить FSRM создавать журналы изменений

Начиная с Windows Server версии 1803 теперь можно запретить службе диспетчера ресурсов файлового сервера создавать журнал изменений (также известный как журнал USN) на томах при запуске службы . Это может сэкономить немного места на каждом томе, но отключит классификацию файлов в реальном времени.

Более старые новые функции см. в разделе Что нового в диспетчере ресурсов файлового сервера.

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

1. Остановить службу SRMSVC. Например, откройте сеанс PowerShell от имени администратора и введите Stop-Service SrmSvc .

2. Удалите журнал USN для томов, на которых вы хотите сэкономить место, с помощью команды fsutil:

    fsutil usn deletejournal /d <имя тома>
    

   Например: fsutil usn deletejournal /d c:

3. Откройте редактор реестра, например, набрав regedit в том же сеансе PowerShell.

4. Перейдите к следующему разделу: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SrmSvc\Settings

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

   1. Щелкните правой кнопкой мыши ключ Settings и выберите New > DWORD (32-bit) Value .
   2. Назовите значение ПропуститьUSNCreationForSystem .
   3. Установите значение 1 (в шестнадцатеричном формате).

6. Чтобы при необходимости пропустить создание журнала изменений для определенных томов:

   1. Получите пути к томам, которые вы хотите пропустить, с помощью команды fsutil volume list или следующей команды PowerShell:

       Get-Volume | Таблица форматов DriveLetter, FileSystemLabel, Path
       

      Вот пример вывода:

       Путь к FileSystemLabel DriveLetter
       ----------- --------------- ----
                   Зарезервировано системой \\?\Volume{8d3c9e8a-0000-0000-0000-100000000000}\
       C \\?\Volume{8d3c9e8a-0000-0000-0000-501f00000000}\
       

   2. Вернувшись в редактор реестра, щелкните правой кнопкой мыши ключ HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SrmSvc\Settings и выберите New > Multi-String Value .

   3. Назовите значение SkipUSNCreationForVolumes .

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

       \\?\Объем{8d3c9e8a-0000-0000-0000-100000000000}\
      \\?\Объем{8d3c9e8a-0000-0000-0000-501f00000000}\
       

      Примечание

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

7. Запустите службу SRMSVC. Например, в сеансе PowerShell введите Запуск службы SrmSvc .

Дополнительные каталожные номера

• Динамический контроль доступа

Обратная связь

Отправить и просмотреть отзыв для

Этот продукт

Эта страница

Просмотреть все отзывы о странице

Включить ведение журнала установщика Windows — клиент Windows

Редактировать

Твиттер

LinkedIn

Фейсбук

Эл. адрес

• Статья
• 23.09.2021
• 3 минуты на чтение

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

Применимо к:   Windows 10 – все выпуски, Windows Server 2012 R2
Исходный номер базы знаний:   223300

Примечание

Запись реестра в этой статье действительна для всех операционных систем Windows.

Установщик Windows может использовать ведение журнала, чтобы помочь в устранении неполадок при установке пакетов программного обеспечения. Это ведение журнала включается путем добавления ключей и значений в реестр. После того, как записи будут добавлены и включены, вы можете повторить установку проблемы, и установщик Windows отследит ход выполнения и опубликует его в папке Temp. Имя файла нового журнала является случайным. Тем не менее, первые буквы Msi , а имя файла имеет расширение .log. Чтобы найти папку Temp, введите в командной строке следующую строку:

 cd %temp%
 

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

Важно

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

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

• Путь: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer
• Тип: Reg_SZ
• Значение: Регистрация
• Данные: voicewarmupx

Буквы в поле значения могут быть в любом порядке. Каждая буква включает отдельный режим регистрации. Фактическая функция каждой буквы для MSI версии 1.1 следующая:

• v — Подробный вывод
• o — Сообщения о нехватке места на диске
• i — Сообщения о состоянии
• c — Начальные параметры пользовательского интерфейса
• e — Все сообщения об ошибках
• w — Нефатальные предупреждения
• а — Запуск действий
• r — Записи, относящиеся к действию
• m — Недостаточно памяти или фатальная информация о выходе
• u — Запросы пользователей
• p — Свойства терминала
• + — Добавить к существующему файлу
• ! — Сбросить каждую строку в лог
• x — Дополнительная отладочная информация. Флаг x доступен только в операционных системах Windows Server 2003 и более поздних версиях, а также в распространяемом MSI версии 3.0 и в более поздних версиях распространяемого MSI.
• * — Подстановочный знак. Запишите всю информацию, кроме v и x. Чтобы включить параметры v и x, укажите /l*vx.

Примечание

Это изменение следует использовать только для устранения неполадок, и его не следует оставлять включенным, поскольку оно отрицательно скажется на производительности системы и дисковом пространстве. Каждый раз, когда вы используете Установка и удаление программ элемент Панель управления создается новый файл Msi*.log. Чтобы отключить ведение журнала, удалите значение реестра Logging .

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

Дважды щелкните Ведение журнала , а затем щелкните Включено .