логи rdp подключений windows 10
Очистка истории RDP подключений в Windows
Встроенный Remote Desktop Connection (RDP) клиент Windows (mstsc.exe) при каждом успешном соединении с удаленным компьютером сохраняет в системе его имя (или ip адрес) и имя пользователя, под которым был выполнен вход. При следующем запуске клиент RDP предлагает пользователю выбрать одно из подключений, которыми он уже пользовался ранее. Пользователь может выбрать из списка имя удаленного RDP/RDS сервера, и клиент автоматически подставляет используемое ранее для входа имя пользователя.
Это удобно с точки зрения конечного пользователя, но не безопасно. Особенно, когда вы подключаетесь к своему RDP серверу с общедоступного или недоверенного компьютера.
Информация о всех RDP сессиях хранится индивидуально для каждого пользователя компьютера в реестре, т.е. обычный пользователь (не администратор) не сможет просмотреть историю удаленных подключений другого пользователя.
В этой статье мы покажем, где в Windows хранится история подключений к удаленным рабочим столам и сохраненные пароли, и каким образом можно эту историю очистить.
Удаление журнала RDP подключений из реестра системы
Скрипт очистки истории (логов) RDP подключений
Выше мы показали, как вручную очистить историю RDP подключений в Windows. Однако делать это вручную (особенно на нескольких компьютерах) – занятие достаточно долгое. Поэтому мы предлагаем небольшой скрипт (bat-файл), который позволяет автоматически очистить историю подключений к удаленным рабочим столам.
Для автоматизации очистки истории RDP, данный скрипт можно поместить в автозагрузку, либо распространить его на компьютеры пользователей с помощью логоф скрипта групповой политики.
Последовательно разберем все команды скрипта:
Вы можете скачать готовый скрипт тут: CleanRDPHistory.bat
Как запретить Windows сохранять историю RDP подключений?
В результате mstsc просто не сможет записать информацию об RDP подключении в реестр.
Очистка Bitmap кэша RDP
В клиенте Remote Desktop Connection есть функционал кэширования изображений (persistent bitmap caching). Клиент RDP при подключении сохраняет редко изменяющиеся куски удаленого экрана в виде кэша растровых изображений. Благодаря этому клиент mstsc.exe загружает из локального кэша части экрана, которые не изменились с момента последней прорисовки. Этот механизм кэширования RDP уменьшает количество данных, передаваемых по сети.
RDP кэш представляет собой два типа файлов в каталоге %LOCALAPPDATA%\Microsoft\Terminal Server Client\Cache :
В этих файлах хранятся сырые растровые изображения RDP экрана в виде плиток 64×64 пикселя. С помощью простых PowerShell или Python скриптов (легко ищутся по запросу RDP Cached Bitmap Extractor) можно получить PNG файлы с кусками экрана рабочего стола и использовать их для получения конфиденциальной информации. Размер плиток мал, но достаточен для получения полезной информации для изучающего RDP кэш.
Вы можете запретить RDP клиенту сохранять изображение экрана в кэш, отключив опцию Persistent bitmap caching (Постоянное кэширование точечных рисунков) на вкладке Advanced.
В этом случае нужно очистить каталог RDP кэша или отключить опцию Bitmap Caching.
Удаление сохраненных RDP паролей
Если при установке удалённого RDP подключения, перед вводом пароля пользователь поставил галку Remember Me / Запомнить меня, то имя пользователя и пароль будут сохранены в системном менеджере паролей системы (Credential Manager). При следующем подключении к этому же компьютеру, RDP клиент автоматически использует сохранённый ранее пароль для авторизации на удаленном компьютере.
Вы можете удалить сохраненный пароль прямо из окна клиента mstsc.exe. Выберите в списке подключений тоже самое подключение, и нажмите на кнопку Delete. Далее подтвердите удаление сохраненного пароля.
Либо можно удалить сохраненный пароль непосредственно из менеджера паролей Windows. Перейдите в следующий раздел Панели Управления: Control Panel\User Accounts\Credential Manager. Выберите Manage Windows Credentials и в списке сохранённых паролей найдите имя компьютера (в формате TERMSRV/192.168.1.100 ). Разверните найденный элемент и нажмите на кнопку Remove.
В доменной среде вы можете запретить сохранение паролей для RDP подключений можно с помощью политики Network access: Do not allow storage of passwords and credentials for network authentication (см. статью).
Очистка RDP логов на сервере
Логи подключения так же ведутся на стороне RDP/RDS сервера. Вы можете найти информацию об RDP подключениях в логах Event Viewer:
Мониторинг активности и статуса подключенных удаленных клиентов.
Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016
примечание. Windows Server 2012 объединяет службу directaccess и службы удаленного доступа (RAS) в одну роль удаленного доступа.
Консоль управления на сервере удаленного доступа можно использовать для наблюдения за активностью и состоянием удаленных клиентов.
Для выполнения задач, описанных в этом разделе, необходимо войти в систему как член группы «Администраторы домена» или член группы «Администраторы» на каждом компьютере. Если вы не можете выполнить задачу, войдя в учетную запись, которая является членом группы «Администраторы», попробуйте выполнить задачу, войдя в учетную запись, которая является членом группы «Администраторы домена».
Мониторинг активности и состояния удаленных клиентов
В диспетчере серверов щелкните Средства и выберите пункт Управление удаленным доступом.
Вы увидите список пользователей, подключенных к серверу удаленного доступа, и подробную статистику по ним. Щелкните первую строку в списке, соответствующую клиенту. При выборе строки на панели предварительного просмотра отображается активность удаленных пользователей.
Windows PowerShell эквивалентные команды
Следующие командлеты Windows PowerShell выполняют ту же функцию, что и предыдущая процедура. Вводите каждый командлет в одной строке, несмотря на то, что здесь они могут отображаться разбитыми на несколько строк из-за ограничений форматирования.
Статистику пользователя можно фильтровать на основе выбора критериев, используя поля в следующей таблице.
Просмотр и анализ логов RDP подключений в Windows
В этой статье мы рассмотрим, особенности аудита / анализа логов RDP подключений в Windows. Как правило, описанные методы могут пригодиться при расследовании различных инцидентов на терминальных / RDS серверах Windows, когда от системного администратора требуется предоставить информацию: какие пользователи входили на RDS сервер, когда авторизовался и завершил сеанс конкретный пользователь, откуда / с какого устройства (имя или IP адрес) подключался RDP-пользователь. Я думаю, эта информация будет полезна как для администраторов корпоративных RDS ферм, так и владельцам RDP серверов в интернете (Windows VPS как оказалось довольно популярны).
Как и другие события, логи RDP подключения в Windows хранятся в журналах событий. Откройте консоль журнала событий (Event Viewer). Есть несколько различных журналов, в которых можно найти информацию, касающуюся RDP подключения.
В журналах Windows содержится большое количество информации, но быстро найти нужное событие бывает довольно сложно. Когда пользователь удаленно подключается к RDS серверу или удаленному столу (RDP) в журналах Windows генерируется много событий. Мы рассмотрим журналы и события на основных этапах RDP подключения, которые могут быть интересны администратору:
В результате у вас получится список с историей всех сетевых RDP подключений к данному серверу. Как вы видите, в логах указывается имя пользователя, домен (используется NLA аутентификация, при отключенном NLA текст события выглядит иначе) и IP адрес компьютера, с которого осуществляется RDP подключение.
При этом имя пользователя содержится в описании события в поле Account Name, имя компьютера в Workstation Name, а имя пользователя в Source Network Address.
Вы можете получить список событий успешных авторизаций по RDP (событие 4624) с помощью такой команды PowerShell.
Событие с EventID – 21 (Remote Desktop Services: Shell start notification received) означает успешный запуск оболочки Explorer (появление окна рабочего стола в RDP сессии).
При этом в журнале Security нужно смотреть событие EventID 4634 (An account was logged off).
Событие Event 9009 (The Desktop Window Manager has exited with code ( ) в журнале System говорит о том, что пользователь инициировал завершение RDP сессии, и окно и графический shell пользователя был завершен.
Ниже представлен небольшой PowerShell, который выгружает из журналов терминального RDS сервера историю всех RDP подключений за текущий день. В полученной таблице указано время подключения, IP адрес клиента и имя RDP пользователя (при необходимости вы можете включить в отчет другие типы входов).
Иногда бывает удобно с логами в таблице Excel, в этом случае вы можете выгрузить любой журнал Windows в текстовый файл и импортировать в Excel. Экспорт журнала можно выполнить из консоли Event Viewer (конечно, при условии что логи не очищены) или через командную строку:
WEVTUtil query-events Security > c:\ps\security_log.txt
Список текущих RDP сессий на сервере можно вывести командой:
Команда возвращает как идентификатор сессии (ID), имя пользователя (USERNAME)и состояние (Active/Disconnect). Эту команду удобна использовать, когда нужно определить ID RDP сессии пользователя при теневом подключении.
Список запущенных процессов в конкретной RDP сессии (указывается ID сессии):
На RDP-клиенте логи не такие информационные, основное чем часто пользуются информация об истории RDP подключений в реестре.
Просмотр и анализ логов RDP подключений в Windows
В этой статье мы рассмотрим, особенности аудита / анализа логов RDP подключений в Windows. Как правило, описанные методы могут пригодиться при расследовании различных инцидентов на терминальных / RDS серверах Windows, когда от системного администратора требуется предоставить информацию: какие пользователи входили на RDS сервер, когда авторизовался и завершил сеанс конкретный пользователь, откуда / с какого устройства (имя или IP адрес) подключался RDP-пользователь. Я думаю, эта информация будет полезна как для администраторов корпоративных RDS ферм, так и владельцам RDP серверов в интернете (Windows VPS как оказалось довольно популярны).
Статья применима при исследовании RDP логов как в Windows Server 2008 R2, 2012/R2, 2016, так и в соответствующих десктопных версиях Windows (Windows 7, 8.1, 10).
Как и другие события, логи RDP подключения в Windows хранятся в журналах событий. Откройте консоль журнала событий (Event Viewer). Есть несколько различных журналов, в которых можно найти информацию, касающуюся RDP подключения.
В журналах Windows содержится большое количество информации, но быстро найти нужное событие бывает довольно сложно. Когда пользователь удаленно подключается к RDS серверу или удаленному столу (RDP) в журналах Windows генерируется много событий. Мы рассмотрим журналы и события на основных этапах RDP подключения, которые могут быть интересны администратору:
В результате у вас получится список с историей всех сетевых RDP подключений к данному серверу. Как вы видите, в логах указывается имя пользователя, домен (используется NLA аутентификация, при отключенном NLA текст события выглядит иначе) и IP адрес компьютера, с которого осуществляется RDP подключение.
Вы можете использовать события с ошибками аутентфикации для защиты от удаленного перебора паролей к RDP. Вы можете автоматически блокировать на файерволе такие IP адреса простым PowerShell скриптом.
При этом имя пользователя содержится в описании события в поле Account Name, имя компьютера в Workstation Name, а имя пользователя в Source Network Address.
Обратите внимание на значение поля TargetLogonID – это уникальный идентификатор сессии пользователя с помощью которого можно отслеживать дальнейшую активность данного пользователя. Однако при отключении от RDP сессии (disconnect) и повторного переподключения в сессию, пользователю будет выдан новый TargetLogonID (хотя RDP сессия осталась той же самой).
Вы можете получить список событий успешных авторизаций по RDP (событие 4624) с помощью такой команды PowerShell.
Событие с EventID – 21 (Remote Desktop Services: Shell start notification received) означает успешный запуск оболочки Explorer (появление окна рабочего стола в RDP сессии).
При этом в журнале Security нужно смотреть событие EventID 4634 (An account was logged off).
Событие Event 9009 (The Desktop Window Manager has exited with code ( ) в журнале System говорит о том, что пользователь инициировал завершение RDP сессии, и окно и графический shell пользователя был завершен.
Ниже представлен небольшой PowerShell, который выгружает из журналов терминального RDS сервера историю всех RDP подключений за текущий день. В полученной таблице указано время подключения, IP адрес клиента и имя RDP пользователя (при необходимости вы можете включить в отчет другие типы входов).
Иногда бывает удобно с логами в таблице Excel, в этом случае вы можете выгрузить любой журнал Windows в текстовый файл и импортировать в Excel. Экспорт журнала можно выполнить из консоли Event Viewer (конечно, при условии что логи не очищены) или через командную строку:
WEVTUtil query-events Security > c:\ps\security_log.txt
Список текущих RDP сессий на сервере можно вывести командой:
Команда возвращает как идентификатор сессии (ID), имя пользователя (USERNAME)и состояние (Active/Disconnect). Эту команду удобна использовать, когда нужно определить ID RDP сессии пользователя при теневом подключении.
Список запущенных процессов в конкретной RDP сессии (указывается ID сессии):
На RDP-клиенте логи не такие информационные, основное чем часто пользуются информация об истории RDP подключений в реестре.
#Автоматизация #Технологии #Процессы #ИТ #Записки #Журнал #Блог #Форум
Форум для различных тем в большей части ИТ
Монитор внешнего входа и выхода пользователей Windows
Монитор внешнего входа и выхода пользователей Windows
Сообщение Артём Мамзиков » Вт янв 12, 2021 16:22 #1
Мониторинг внешнего входа и выхода пользователей Windows
Ключ в zabbix будет использоваться eventlog
Мониторинг журналов событий.
Журнал (лог)
Элемент данных должен быть настроен активной проверкой.
Обратите внимание, агент не может отправлять события из «Пересланные события» журнала.
Параметр режим поддерживается начиная с версии 2.0.0.
“Windows Eventing 6.0” поддерживается начиная с Zabbix 2.2.0.
Обратите внимание, что выбор не журнального типа информации для этого элемента данных приведет к потере локального штампа времени, а также важности журнала и информации о источнике.
Смотрите дополнительную информацию о мониторинге файлов журналов.
Изначально шаблон был взят с Windows Server Login monitor далее путь на гитхаб Server-Login-monitor-Zabbix
Для начала оригинальный шаблон автора который был скачен с гитхаба
# Server-Login-monitor-Zabbix
uses Microsoft-Windows-TerminalServices-LocalSessionManager windows log to find logins and logouts to server.
and fires alarm when a user logs in to a server
Simply import to zabbix and add the template to desired hosts.
#Сервер-Логин-монитор-Zabbix
использует журнал Windows Microsoft-Windows-TerminalServices-LocalSessionManager для поиска логинов и выходов на сервер.
и подает сигнал тревоги, когда пользователь входит на сервер
Просто импортируйте в zabbix и добавьте шаблон на желаемые хосты.
Имя шаблона Windows external login monitor
Группы Windows
Описание Monitor non administrator logins on server
Макросы
=> Administrator
(не проверять, не выводить триггер когда заходит пользователь Administrator)
Группы элементов данных
Log
RDP
Элементы данных
Имя Login to Remote desktop
Тип Zabbix агент (активный)
Ключ eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational». ^(21|23)$,,skip]
Тип информации Журнал (Лог)
Интервал обновления 15s
Период хранения истории 90d
Формат времени в журнале (логе) ddMMyyyy:hhmmss
Группы элементов данных
Log
RDP
Описание Monitor RDP login and logout
Активировано V
Предобработка
Шаги предобработки Имя Регулярное выражение Параметры User: (.*)\n Вывод \1
Для Русскоязычных систем Windows в Логе вместо User по Русскому пишется Пользователь получаем
Шаги предобработки Имя Регулярное выражение Параметры Пользователь: (.*)\n Вывод \1
Имя шаблона Windows external login monitor
Видимое имя Монитор внешнего входа Windows
Описание Monitor non administrator logins on server
Мониторинг Логинов без прав администратора на сервере
Макросы
<$HIDELOGINS>=> No я решил показывать все входы, не скрывая
Группы элементов данных
LOG-RDP&Local
Элементы данных
Имя Вход на удаленный рабочий стол
Тип Zabbix агент (активный)
Ключ eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational». ^(21|23|24|25)$,,skip]
Тип информации Журнал (Лог)
Интервал обновления 15s
Период хранения истории 90d
Формат времени в журнале (логе) ddMMyyyy:hhmmss
Группы элементов данных
LOG-RDP&Local
Описание
Login to Remote desktop
Monitor RDP login and logout
Вход на удаленный рабочий стол
Монитор РДП вход и выход
Скрыть вход добавить макрос <$HIDELOGINS>Administrator
Активировано V
Предобработка
Для Русскоязычных систем Windows в Логе вместо User по Русскому пишется Пользователь получаем
Шаги предобработки Имя Регулярное выражение Параметры Пользователь: (.*)\n Вывод \1
Дальнейшие доработки
Мало инфы в триггере 1.Пользователь который подключился 2.IP-адресс откуда подключился 3.Код Сеанса 4.Имя ПК с которого выполнено подключение
Отключенные пользователи которые не завершили сеанс, а просто его закрыли! Корректно нужно завершать сеанс, так же нужно проверять.
Сперва текущий актуальный шаблон на 12.01.2021, ниже как это делалось какие проблемы возникали и тд.
Имя шаблона Windows external login monitor
Видимое имя Монитор внешнего входа Windows
Группы Windows и Windows Server
Описание
Monitor non administrator logins on server
Мониторинг Логинов без прав администратора на сервере
Группы элементов данных LOG-RDP&Local
Элемент данных
Имя Вход в Windows LSM
Тип Zabbix агент (активный)
Ключ eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational». ^(21|23|24|25|39|40)$,,skip]
Тип информации Журнал (лог)
Интервал обновления 15s
Период хранения истории Storage period 31d
Формат времени в журнале (логе) ddMMyyyy:hhmmss
Группы элементов данных LOG-RDP&Local
Описание
Login to Remote desktop
Monitor RDP login and logout
Вход на удаленный рабочий стол
Монитор РДП вход и выход
Скрыть вход добавить макрос <$HIDELOGINS>Administrator
(Win+R) команду eventvwr.msc
Элемент данных
Имя Получаем предыдущее значение для Windows LSM
Тип Zabbix агент
Ключ system.run[«wevtutil qe Microsoft-Windows-TerminalServices-LocalSessionManager/Operational /c:2 /rd:true /f:text|FIND /I \»Event ID\»|find /n \»2\»|find /v \»1\»»]
Тип информации Числовой (целое положительное)
Интервал обновления 1m
Пользовательские интервалы Переменный
Период хранения истории Storage period 31d
Период хранения динамики изменений Storage period 31d
Отображение значения Как есть
Группы элементов данных LOG-RDP&Local
Описание
Получаем значение, для закрытия триггера на пользователь отключен
Поэтому смотрим предпоследнюю запись если она 23 триггер не срабатывает.
Предобработка
Шаги предобработки
1 Имя Обрезать Параметры [2] Event ID
2 Имя Обрезать Параметры :
(Win+R) команду eventvwr.msc
(Win+R) команду eventvwr.msc
На стороне заббикс агента в конфигурации прописываем следующее
Конфигурация агента ссылается на скрипт повершела
UserParameter=1, powershell C:\zabbix\Scripts\1.ps1
Теги
Trigger tags
Имя <
Срабатывает если последняя запись 24 и предпоследняя не равна 23
не создавалось множество указано diff
Теги
Trigger tags
Имя <
Локально: 21
Службы удаленных рабочих столов: Успешный вход в систему:
/Пользователь: COMPTV\Медиа
Код сеанса: 1
Адрес сети источника: ЛОКАЛЬНЫЕ
Посети: 21
Службы удаленных рабочих столов: Успешный вход в систему:
/Пользователь: COMPTV\Медиа
Код сеанса: 2
Адрес сети источника: 192.168.175.8
Посети: 25
Службы удаленных рабочих столов: Успешное переподключение сеанса:
Пользователь: COMPTV\Медиа
Код сеанса: 1
Адрес сети источника: 192.168.175.8
По сети: 24
Службы удаленных рабочих столов: Сеанс был отключен:
Пользователь: COMPTV\Медиа
Код сеанса: 1
Адрес сети источника: 192.168.175.8
Локально 23
Службы удаленных рабочих столов: Успешный выход из сеанса:
Пользователь: COMPTV\Медиа
Код сеанса: 1
Триггер RDP auth Пользователь: Домен\MamzikovAA источника: 192.168.175.8 Код сеанса: 4
21
Службы удаленных рабочих столов: Успешный вход в систему:
/Пользователь: Домен\MamzikovAA
Код сеанса: 4
Адрес сети источника: 192.168.175.8
23
Службы удаленных рабочих столов: Успешный выход из сеанса:
Пользователь: Домен\MamzikovAA
Код сеанса: 4
24
Службы удаленных рабочих столов: Сеанс был отключен:
Пользователь: Домен\MamzikovAA
Код сеанса: 4
Адрес сети источника: 192.168.175.8
25
Службы удаленных рабочих столов: Успешное переподключение сеанса:
Пользователь: Домен\Администратор
Код сеанса: 1
Адрес сети источника: 192.168.175.10
(Win+R) команду eventvwr.msc
Вход в Windows RCM-Remote Connection Manager
(Win+R) команду eventvwr.msc
Службы удаленных рабочих столов: Успешная проверка подлинности пользователя:
Пользователь: Администратор
Домен: FSServer
Адрес источника сети: 192.168.175.8
Открытие Срабатывание триггера отключённых пользователей происходить по 24 значению лога
а закрытие триггера по 23 значению лога
По отключенным триггер срабатывает если 24 и предыдущая строка не 23
Теги и регулярное выражение <
Добрый день! Поясните правильно ли я понимаю работу тегов или нет.
Есть элемент данных для мониторинга пользователей windows на основе лога
eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational». ^(21|23|24|25)$,,skip]
Запрашиваю каждую 1 минуту
В имени тега есть регулярка которая показывает код сеанса данного пользователя <
Суть вопроса в чем
Кто то отключился Сработал триггер, регулярка отработала присвоила триггеру тег например 2
Дальше у меня действие спустя 5 минут завершить сессию данного пользователя (мало ли просто обрыв инет пропал даю 5 минут ожидания)
Элемент за это время у нас еще отпроситься 4 раза, естественно там регулярки не будет, так как изменений в логе нет по этой сессии
Сам же отвечу пустые Логи не приходят, только идут по штампу времени значит значение тега сохраняется, так же если будут изменения лога присвоится другой ID и триггер закроется или сработает другой или действия.
И когда срабатывает действие выполнить команду logoff «
то макрос
Сам отвечу не будет пустым, выше ответ почему.
Открываем Журнал событий Run ( Win+R) команду eventvwr.msc
2. Microsoft-Windows-TerminalServices-LocalSessionManager/Operational eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational». ^(21|23|24|25)$,,skip]
3. Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operationa eventlog[«Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational». ^(1149|4624|4625)$,,skip]
Последнее значение элемента данных N-го элемента данных в выражении триггера вызвавшего это оповещение.
Поддерживается начиная с 1.4.3. Это алиас для <
> Оповещения, основанные на триггерах
> Имена триггеров и описания Последнее значение N-го элемента данных из выражения триггера, который вызвал оповещение.
В веб-интерфейсе раскрывается в *НЕИЗВЕСТНО*, если последнее значение истории собрано более чем ZBX_HISTORY_PERIOD секунд назад (задается в defines.inc.php).
Поддерживается начиная с 1.4.3. Является алиасом к <
Последнее значение N-го элемента данных в выражении триггера, если используется для отображения триггеров.
Историческое значение (точно когда произошло событие) N-го элемента данных из выражения триггера, если используется для отображения событий и оповещений.
Поддерживается начиная с Zabbix 1.4.3.
Имя узла сети N-го элемента данных из триггера вызвавшего это оповещение.
Поддерживается в оповещениях авторегистрации начиная с версии 1.8.4.
<$MACRO>
Пользовательские макросы. Поддерживается в именах триггеров и в описаниях элементов данных начиная с версии 1.8.4.
WshShell = Новый COMОбъект(«WScript.Shell»);
WshSysEnv = WshShell.Environment(«Process»);
Сообщить(«Имя компьютера «+WshSysEnv.Item(«CLIENTNAME»));
Работает только в терминальной сессии
для команды для текущего пользователя
reg query «HKCU\Volatile Environment»
Для конкретного пользователя
HKEY_USERS\S-1-5-21-3002483080-1650114603-3144430796-1000\Volatile Environment
реестр всех пользователей
C:\mkdir c:\Temp
Regedit.exe /e c:\temp\yourname.reg
Вычисляемый элемент
last(«eventlog[\»Microsoft-Windows-TerminalServices-LocalSessionManager/Operational\». ^(21|23|24|25|39|40)$,,skip]») не катит поле не числовое
logeventid(«eventlog[\»Microsoft-Windows-TerminalServices-LocalSessionManager/Operational\». ^(21|23|24|25|39|40)$,,skip]»,23) получаем 0 или 1
date
Текущая дата в формате ГГГГММДД. Поддерживаемые типы значений: любые Пример результата: 20150731
time
Текущее время в формате ЧЧММСС. Поддерживаемые типы значений: любые Пример возвращаемого значения: 123055
Имя Time diff
Тип Вычисляемое
Ключ system.localtime.fuzzytime
Формула fuzzytime(system.localtime,60)
Тип инфы Числовой (целое положительное)
Интервал 1m
Если 3 последних 0 т.е. 0+0+0 = 0 значит триггер срабатывает у нас есть расхождение более чем на 1 минуту
Триггер
system.localtime.fuzzytime.sum(#3)>=0
/c: Задает максимальное число событий для чтения.
/rd: Указывает направление чтения событий. может иметь значение true или false. Если значение равно true, то первыми возвращаются самые последние события.
/f: