Print Services Logs

[Hikedaya]

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

1. Нужный лог должен быть включен. Нужным является Microsoft-Windows-PrintService/Operational. Его требуется привести в состояние Enabled.
2. В случае Windows 2012 R2 должен быть установлен патч 2919355, после чего в групповых политиках должен быть корректно настроен следующий параметр:

Computer Configuration\Administrative Templates\Printers\Allow job name in Event logs

Его нужно включить. Пока этого не сделать, в логах вместо имени документа будет светиться подстановка "Print Document". Изначально эта подстановка была сделана в целях соблюдения конфиденциальности, мало ли какие документы с какими грифами выводятся на печать.

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

Document 7, Untitled - Notepad owned by admin on \\SPB-01-PS1 was printed on spb-01-500-ky1231 through port \\.\pipe\PDFPrint-3. Size in bytes: 1100. Pages printed: 1. No user action is required.

С этим уже можно работать, но как бы теперь вытащить необходимые данные (имя документа, имя пользователя, вот это все) в виде, например, csv-файла. Парсить само сообщение - та еще задачка. Ответ прост, парсить не нужно, это уже сделано. Нужно лишь распотрошить это сообщение в логе на составные части. А делается это вот так:

$event = Get-winevent -LogName Microsoft-Windows-PrintService/Operational | where {$_.id -eq 307} | select -first 1
$event.properties

Результатом будет вот такая аккуратненькая табличка:

Value                                                                                                                                        
-----                                                                                                                                        
7                                                                                                                                            
Untitled - Notepad                                                                                                                           
admin                                                                                                                                        
\\SPB-01-PS1                                                                                                                                 
spb-01-500-ky1231                                                                                                                            
\\.\pipe\PDFPrint-3                                                                                                                          
1100                                                                                                                                         
1  

И с этим уже можно работать, можно обратиться напрямую к любому из элементов данного массива, например $event.properties.value[1] для имени документа.

Ну а что именно делать с полученными данными - уже на усмотрение исполнителя. Хотя как по мне - правильнее повесить в Task Scheduler задачу по записи сведений о распечатываемом документе в какую-нибудь базу или файл при появлении в логе службы печати события с кодом 307. Как это сделать - инструкций в сети просто тонны, да и в этой записной книжке подобная тоже пробегала.

@музыка: Wolf and Raven - Cyber Samurai

@темы: PowerShell

Comments

[Линда Кайе]

WMI вроде бы позволял подписываться на журналы событий и генерировать события при поступлении новых событий ^^' Короче, скрипт бесконечно висит запущенным и при каждом новом сообщении в журналах событий выполняет под по парсингу.

[Линда Кайе]

Пример из sсript Center.

Creates a temporary event consumer that monitors event logs for events with an event ID of 533.

strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
    & "{impersonationLevel=impersonate, (Security)}!\\" & _
        strComputer & "\root\cimv2")

Set colMonitoredEvents = objWMIService.ExecNotificationQuery _    
    ("Select * from __instancecreationevent where " _
        & "TargetInstance isa 'Win32_NTLogEvent' " _
            & "and TargetInstance.EventCode = '533' ")

Do
    Set objLatestEvent = colMonitoredEvents.NextEvent
     strAlertToSend = objLatestEvent.TargetInstance.User _ 
         & " attempted to access DatabaseServer."
     Wscript.Echo strAlertToSend
Loop

[Линда Кайе]

Ответ прост, парсить не нужно, это уже сделано. Нужно лишь распотрошить это сообщение в логе на составные части.

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

[Hikedaya]

Короче, скрипт бесконечно висит запущенным

Почти шесть лет назад (е-мое, как время-то летит) мы это уже обсуждали ^^
hikedaya.diary.ru/p200623610_event-log-powershe...

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

[Линда Кайе]

Ну, журналы могут чиститься, поэтому важно вовремя перехватывать всё новое ^^'

е-мое, как время-то летит

Да уж ^^'