Как посмотреть логи windows server 2012

Просмотр и анализ событий (логов) Windows с помощью PowerShell

17.11.2022

itpro

PowerShell, Windows 10, Windows Server 2019

комментариев 7

Журнал событий Windows (Event Log) — это важный инструмент, который позволяет администратору отслеживать ошибки, предупреждения и другие информационные сообщения, которые регистрируются операционной системой, ее компонентами и различными программами. Для просмотра журнала событий Windows можно использовать графическую MMC оснастку Event Viewer ( eventvwr.msc ). В некоторых случаях для поиска информации в журналах событий и их анализа гораздо удобнее использовать PowerShell. В этой статье мы покажем, как получать информацию из журналов событий Windows с помощью командлета Get-WinEvent.

На данный момент в Windows доступны два командлета для доступа к событиям в Event Log: Get-EventLog и Get-WinEvent. В подавляющем большинстве случаев рекомендуем использовать именно Get-WinEvent, т.к. он более производителен, особенно в сценариях обработки большого количества событий с удаленных компьютеров. Командлет Get-EventLog является устаревшим и использовался для получения логов в более ранних версиях Windows. Кроме того, Get-EventLog не поддерживается в современных версиях PowerShell Core 7.x.

Получение логов Windows с помощью Get-WinEvent

Для использования команды Get-WinEvent нужно запустить PowerShell с правами администратора (при запуске Get-WinEvent от имени пользователя вы не сможете получить доступ к некоторым логам, например, к Security).

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

Get-WinEvent -LogName Application -MaxEvents 20

Чаще всего вам нужно будет получать информацию из журналов System, Application, Security или Setup. Но вы можете указать и другие журналы. Полный список журналов событий в Windows можно получить с помощью команды:

Например, чтобы вывести события RDP подключений к компьютеру, нужно указать лог Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational:

Get-WinEvent -LogName Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational

Или получить логи SSH подключений к Windows из журнала OpenSSH/Operational:

Get-WinEvent -LogName OpenSSH/Operational

Можно выбрать события сразу из нескольких журналов. Например, чтобы получить информацию о ошибках и предупреждениях из журналов System и Application за последние 24 часа (сутки), можно использовать такой код:

$StartDate = (Get-Date) — (New-TimeSpan -Day 1)
Get-WinEvent Application,System | Where-Object

Чтобы вывести только определенные поля событий, можно использовать Select-Object или Format-Table:

Get-WinEvent -LogName System | Format-Table Machinename, TimeCreated, Id, UserID

Можно выполнить дополнительные преобразования с полученными данными. Например, в этом примере мы сразу преобразуем имя пользователя в SID:

Get-WinEvent: быстрый поиск в событиях Event Viewer с помощью FilterHashtable

Рассмотренный выше способ выбора определенных событий из журналов Event Viewer с помощью Select-Object прост для понимая, но выполняется крайне медленно. Это особенно заметно при выборке большого количества событий. В большинстве случаев для выборки событий нужно использовать фильтрацию на стороне службы Event Viewer с помощью параметра FilterHashtable.

Попробуем сформировать список ошибок и предупреждений за 30 дней с помощью Where-Object и FilterHashtable. Сравнима скорость выполнения этих двух команд PowerShell с помощью Measure-Command:

Проверим скорость выполнения команды с Where-Object:

Аналогичная команда с FilterHashtable:

В данном примере видно, что команда выборки событий через FilterHashtable выполняется в 30 раз быстрее, чем если бы обычный Where-Object ( 2.5 сек vs 76 секунд).

Если вам нужно найти события по EventID, используйте следующую команду с FilterHashtable:

Get-WinEvent -FilterHashtable @|ft TimeCreated,Id,Message

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

В параметре FilterHashtable можно использовать фильтры по следующим атрибутам событий:

• LogName
• ProviderName
• Path
• Keywords (для поиска успешных событий нужно использовать значение 9007199254740992 или для неуспешных попыток 4503599627370496)
• ID
• Level (1=FATAL, 2=ERROR, 3=Warning, 4=Information, 5=DEBUG, 6=TRACE, 0=Info)
• StartTime
• EndTime
• UserID (SID пользователя)
• Data

Пример поиска события за определенный промежуток времени:

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

Get-WinEvent -FilterHashtable @|Where

Расширенный фильтры событий Get-WinEvent с помощью FilterXml

Фильтры Get-WinEvent с параметром FilterHashtable являются несколько ограниченными. Если вам нужно использовать для выборки событий сложные запросы с множеством условий, нужно использовать параметр FilterXml, который позволяет сформировать запрос на выбор событий в Event Viewer с помощью XML запроса. Как и FilterHashtable, фильтры FilterXml выполняется на стороне сервера, поэтому результат вы получите довольно быстро.

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

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

1. Запустите eventvwr.msc ;
2. Найдите журнал для которого вы хотите создать и выберите Filter Current Log;
3. Выберите необходимые параметры запроса в форме. В этом примере я хочу найти события с определенными EventID за последние 7 дней от определенного пользователя;
4. Чтобы получить код XML запроса для параметра FilterXML, перейдите на вкладку XML и скопируйте полученный код (CTRL+A, CTRL+C);
5. Если нужно, вы можете вручную отредактировать данный запрос.

Для экспорта списка событий в CSV файл нужно использовать командлет Export-CSV:

$Events= Get-WinEvent -FilterXML $xmlQuery
$events| Export-CSV «C:\ps\FilterSYSEvents.csv» -NoTypeInformation -Encoding UTF8

Получить логи Event Viewer с удаленных компьютеров

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

$computer=’msk-dc01′
Get-WinEvent -ComputerName $computer -FilterHashtable @ | select Message,Id,TimeCreated

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

$servers = Get-Content -Path C:\ps\servers.txt

Или из Active Directory:

$servers = (Get-ADComputer -Filter ‘operatingsystem -like «*Windows server*» -and enabled -eq «true»‘).Name
foreach ($server in $servers) Get-WinEvent -ComputerName $server -MaxEvents 5 -FilterHashtable @LogName = ‘System’; >> | Select-Object -Property ID, MachineName
>

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

$Username = ‘a.ivanov’
Get-ADDomainController -fi * | select -exp hostname | % $GweParams = @‘Computername’ = $_
‘LogName’ = ‘Security’
‘FilterXPath’ = «*[System[EventID=4740] and EventData[Data[@Name=’TargetUserName’]=’$Username’]]»
>
$Events = Get-WinEvent @GweParams
$Events | foreach
>

Еще несколько примеров использования Get-WinEvent для поиска событий:

• Удаления файла или папки на файловом сервере
• Истории запуска программы в Windows
• Поиска событий входа пользователя в Windows
• Задачки Active Directory: кто создал пользователя, кто сбросил пароль пользователя или добавил его в группу безопасности AD

Предыдущая статья Следующая статья

Как посмотреть логи shutdown и restart в Windows Server

Средство просмотра событий Windows обрабатывается основной службой журнала событий. Средство просмотра событий регистрирует историю запуска и завершения работы сервера. Так же она отслеживает действия каждого пользователя во время работы устройства. Записывает ошибки, и другие сообщения и предупреждения которые возникают на Windows Server.

В этой статье мы узнаем, как проверить журналы выключения/перезагрузки на VPS серверах Windows 2012, 2016 и 2019.

Рассмотрим некоторые наиболее распространенные коды связанные со временем запуска и завершения работы сервера.

41: показывает, что ваш сервер перезагрузился, но не выключился полностью.
6005: показывает, что служба журнала событий была запущена.
1074: это событие показывает, когда приложение принудительно выключает или перезагружает ваш VPS сервер. Благодаря этому можно узнать, когда вы, или кто-то другой перезапустил или выключил сервер из меню «Пуск» или через CTRL+ALT+DEL.
6008: это событие появляется если ваш компьютер был выключен, или ушел в перезагрузку, через синий экран смерти.
6006: это событие показывает когда сервер корректно завершил свою работу.

Как просмотреть данные события?

Нажмите Win + R и введите eventvwr

В левой части панели откройте «Журналы Windows => Система»

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

Для того что бы отсортировать нужные намо события, с правой стороны, выберем «Фильтр текущего журнала»

Теперь введите нужные нам события, через запятую, 41, 1074, 6006, 6008, 6006 и нажмите Ок.

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

Так же мы можем просмотреть журнал событий безотказной работы сервера. Этому соответствует идентификатор 6013.

Просмотр журнала выключения и перезапуска сервера с помощью PowerShell

Если нам нужно быстро просмотреть журналы выключения/перезагрузки сервера, можно воспользоваться коммандой Get-EventLog в оболочке PowerShell.

Что бы отфильтровать последнюю 1000 записей в журнале, и отобразить только те события которые нам нужны, (41, 1074, 6006, 6008, 6006) выполним эту команду в PowerShell:

Get-EventLog System -Newest 1000 | ` Where EventId -in 41,1074,6006,6008 | ` Format-Table TimeGenerated,EventId,UserName,Message -AutoSize -wrap

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

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

16.11.2022

itpro

PowerShell, Windows Server 2016, Windows Server 2019

комментариев 86

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

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

События 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 ‘*[System[EventID=1149]]‘
[xml[]]$xml=$RDPAuths|Foreach
$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) | ? | 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 has been disconnected by session ) – пользователь сам отключился от своей RDP сессии, выбрав соответствующий пункт меню (а не просто закрыл окно RDP клиента). Если идентификаторы сессий разные, значит пользователя отключил другой пользователь (или администратор).
• EventID – 40 (Session has been disconnected, reason code ). Здесь нужно смотреть на код причины отключения в событии. Например:
  • 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 () в журнале System говорит о том, что пользователь инициировал завершение RDP сессии, и окно и графический shell пользователя был завершен.

  EventID 4647 — User-initiated logoff

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

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

  

  Этот способ позволяет получить 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 указанного пользователя:

  

  Другие события, связанные с подключениями пользователей на RD Gateway в журнале Microsoft-Windows-TerminalServices-Gateway:

  • 300 — The user %1, on client computer %2, met resource authorization policy requirements and was therefore authorized to connect to resource %4
  • 302 — The user %1, on client computer %2, connected to resource %4
  • 303 — The user %1, on client computer %2, disconnected from the following network resource: %4. Before the user disconnected, the client transferred %6 bytes and received %5 bytes. The client session duration was %7 seconds.

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

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

  

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

  

  Логи 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 подключений на указанном компьютере (для получения событий Event Log используется командлет Get-WinEvent):

  

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

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

  Предыдущая статья Следующая статья

  Управление ведением журнала доступа пользователей

  В этом документе описываются принципы управления ведением журнала доступа пользователей (UAL).

  Ведение журнала доступа пользователей (UAL) — это компонент, который помогает администраторам сервера подсчитать количество уникальных клиентских запросов ролей и служб на локальном сервере.

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

  Дополнительные сведения о преимуществах UAL см. в разделе «Начало работы с ведением журнала доступа пользователей».

  В этом документе

  Параметры конфигурации, описываемые в данном документе, включают в себя следующее:

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

  Отключение и включение службы UAL

  UAL включен и выполняется по умолчанию при первом запуске компьютера под управлением Windows Server 2012 или более поздней версии. Для удовлетворения требований конфиденциальности или других рабочих нужд администратору может понадобиться отключить или запретить работу UAL. Вы можете отключить UAL с помощью консоли служб, из командной строки или с помощью командлетов PowerShell. Однако чтобы убедиться, что UAL не запускается еще раз при следующем запуске компьютера, необходимо также отключить службу. В следующих процедурах описывается отключение и отключение UAL.

  Для получения информации о службе UAL, включая сведения о том, работает или приостановлена служба, включена она или отключена, можно использовать командлет Get-Service UALSVC PowerShell.

  Остановка и отключение службы UAL через консоль службы

  1. Выполните вход на сервер с помощью учетной записи с правами локального администратора.
  2. В диспетчере серверов выберите Средства, затем щелкните Службы.
  3. Прокрутите вниз и выберите пункт Служба ведения журнала доступа пользователей. Щелкните Остановка службы.
  4. Правой кнопкой мыши щелкните имя службы и выберите Свойства. На вкладке Общие поменяйте Тип запуска на Отключенои нажмите кнопку ОК.

  Остановка и отключение UAL из командной строки

  1. Выполните вход на сервер с помощью учетной записи с правами локального администратора.
  2. Нажмите клавишу с эмблемой Windows + R, а затем введите cmd , чтобы открыть окно командной строки.

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

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

  Также остановить и отключить UAL можно с помощью команд Windows PowerShell: Stop-service и Disable-Ual.

  Stop-service ualsvc 

  Disable-ual 

  Если на более позднюю дату вы хотите перезапустить и повторно включить UAL, это можно сделать с помощью следующих процедур.

  Запуск и включение службы UAL через консоль служб

  1. Выполните вход на сервер с помощью учетной записи с правами локального администратора.
  2. В диспетчере серверов выберите Средства, затем щелкните Службы.
  3. Прокрутите вниз и выберите пункт Служба ведения журнала доступа пользователей. Щелкните Запуск службы.
  4. Правой кнопкой мыши щелкните имя службы и выберите Свойства. На вкладке Общие поменяйте Тип запуска на Автоматическии нажмите кнопку ОК.

  Запуск и включение UAL из командной строки

  1. Выполните вход на сервер с помощью учетной записи локального администратора.
  2. Нажмите клавишу с эмблемой Windows + R, а затем введите cmd , чтобы открыть окно командной строки.

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

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

  Также запустить и вновь включить UAL можно с помощью команд Windows PowerShell: Start-service и Enable-Ual.

  Enable-ual 

  Start-service ualsvc 

  Сбор данных 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: предоставляет специальные системные данные для уникальной идентификации локального или целевого сервера.

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

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

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

  PS C:\Windows\system32>Gwmi -Namespace "root\AccessLogging" -query "SELECT * FROM MsftUal_DeviceAccess WHERE LastSeen >='1/01/2013' and LastSeen  

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

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

  PS C:\Windows\system32> Get-UalDeviceAccess -IPAddress "10.36.206.112" ActivityCount : 1 FirstSeen : 6/23/2012 5:06:50 AM IPAddress : 10.36.206.112 LastSeen : 6/23/2012 5:06:50 AM ProductName : Windows Server 2012 Datacenter RoleGuid : 10a9226f-50ee-49d8-a393-9a501d47ce04 RoleName : File Server TenantIdentifier : 00000000-0000-0000-0000-000000000000 PSComputerName 

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

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

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

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

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

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

  Удаление данных, записанных службой UAL

  Служба UAL не задумывалась как компонент для решения критически важных задач. Данная служба спроектирована так, чтобы как можно меньше воздействовать на работу локальной системы и при этом обеспечивать высокий уровень надежности. Это также позволяет администратору при необходимости вручную удалять базу данных и поддерживающие файлы UAL (каждый файл в каталоге \Windows\System32\LogFiles\SUM\).

  Удаление данных, записанных службой UAL

  1. Остановите службу ведения журнала доступа пользователей.
  2. Откройте проводник.
  3. Перейдите в раздел \Windows\System32\Logfiles\SUM\.
  4. Удалите все файлы из этой папки.

  Управление UAL в крупномасштабных средах

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

  Максимальное количество доступов, которое может быть записано UAL, составляет 65 535 в день. UAL не рекомендуется использовать на серверах, которые подключены непосредственно к Интернету, таких как веб-серверы, напрямую подключенные к Интернету, или в тех случаях, когда предельно высокая производительность является основной функцией сервера (например, в средах с рабочими нагрузками высокопроизводительных вычислений). UAL в основном предназначен для небольших, средних и корпоративных сценариев интрасети, где ожидается большой объем, но не столько большого количества развертываний, которые служат объему трафика, доступного к Интернету, на регулярной основе.

  UAL в памяти: поскольку UAL использует расширяемый модуль служба хранилища (ESE), требования к памяти UAL будут увеличиваться со временем (или по количеству клиентских запросов). Но память будет освобождаться, поскольку это необходимо системе для минимизации воздействия на производительность.

  UAL на диске: требования к жесткому диску UAL примерно так же, как показано ниже:

  • 0 уникальных клиентских записей: 22 МБ
  • 50 000 уникальных клиентских записей: 80 МБ
  • 500 000 уникальных клиентских записей: 384 МБ
  • 1 000 000 уникальных клиентских записей: 729 МБ

  Восстановление из ошибочного состояния

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

  Служба UAL использует ESE для оптимизации использования системных ресурсов и обеспечения их устойчивости к повреждению. Дополнительные сведения о преимуществах ESE см. в разделе Расширяемый обработчик хранилищ в MSDN.

  При каждом запуске службы UAL обработчик ESE выполняет "мягкое" восстановление. Дополнительные сведения см. в разделе Файлы расширяемого обработчика хранилищ в MSDN.

  Если выполнить "мягкое" восстановление будет проблематично, то ESE выполнит восстановление после сбоя. Дополнительные сведения см. в разделе Функция JetInit в MSDN.

  Если UAL все же не может запуститься с существующим набором файлов ESE, то все файлы в каталоге \Windows\System32\LogFiles\SUM\ будут удалены. После удаления этих файлов будет вновь запущена служба ведения журнала доступа пользователей и созданы новые файлы. В этом случае служба UAL продолжит работу, как если бы она функционировала на вновь установленном компьютере.

  Файлы в каталоге базы данных UAL никогда не должны перемещаться или изменяться. Если это случится, то будут инициированы действия по восстановлению, включая процедуру очистки, описанную в данном разделе. Если требуются резервные копии каталога \Windows\System32\LogFiles\SUM\, то необходимо архивировать каждый файл из этого каталога, чтобы стала возможной операция восстановления.

  Включение отслеживания использования лицензий рабочих папок

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

  Reg add HKLM\Software\Microsoft\Windows\CurrentVersion\SyncShareSrv /v EnableWorkFoldersUAL /t REG_DWORD /d 1 

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

  После включения ведения журнала 2 информационных события регистрируются в канал Windows Logs\Application каждый раз, когда клиент подключается к серверу. Для рабочих папок каждый пользователь может иметь одно или несколько клиентских устройств, которые подключаются к серверу проверяют наличие обновлений данных каждые 10 минут. Если с сервером взаимодействует 1000 пользователей, каждый из которых имеет 2 устройства, журналы приложений будут перезаписываться каждые 70 минут, что затрудняет устранение независимых проблем. Чтобы избежать этого, можно временно отключить службу ведения журнала доступа пользователей или увеличить размер канала Windows Logs\Application сервера.

  См. также

  Похожие публикации:

  1. Как вывести остатки в программе мой склад
  2. Как выделить в excel все строки содержащие значение
  3. Как посчитать количество файлов в папке linux
  4. Как преобразовать цифры из 1с в эксель