Reading event logs from remote computers is crucial for network audit. Both Event Log Explorer and Windows Event Viewer applications allow the system administrators to read event logs remotely. However sometimes (mainly in no Active Directory environment) sysadmins have problems with accessing remote event logs. In this article, I’ll explain how to setup Windows to make event logs accessible over a network.
As a rule, you don’t need to change anything on your client computer (the computer on which you run Event Log Explorer or Windows Event Viewer). All the changes should be done on the audited computer.
First, you need to set up the firewall.
Run Windows application: Windows Defender Firewall with Advanced Security.
Select Inbound rules for your profile
Enable the following inbound rules:
Remote Event Log Management (RPC)
Remote Event Log Management (RPC-EPMAP)
Remove Event Monitor (RPC)
Remote Event Monitor (RPC-EPMAP)
Note that these settings are applied locally. If you run Active Directory and want to change these settings globally, you can do it in a similar way using Group Policy Management Editor.
Next, if you have a serverless network, you should check sharing and security model for local accounts. Open Local Security Policy, select Local Policies->Security Options in the left pane and make sure that the policy “Network access: Sharing and security model for local accounts” is set to Classic – local users authenticate as themselves.
Finally, you should grant permission to read event logs to your users. In no Active Directory environment, you can use Computer Management. In AD use Active Directory Users and Computers console.
Select the user under Local Users and Groups (or under your domain users). Double click on it to display Properties and select Member Of. Click Add and type Event Log Readers.
That’s all. If you modified Group Policy settings, you should apply your changes (e.g. by using gpupdate command).
Now you can start Event Log Explorer or Windows Event Viewer and open remote event logs.
Several years ago, I wrote an article about generating weekly reports about network issues. The main drawback of that method was the requirement to have Event Log Explorer running all the time (or at least running by the time when the scheduled task should be started). Since that time, we released new versions and editions of Event Log Explorer and now we can get the same result in a smarter way.
Let’s take the same task – getting reports about non-informational events in Application and System logs from different servers.
First, you need to install Event Log Explorer Enterprise Edition since Logexport utility is not available in Standard Edition.
After running Event Log Explorer, we should create a task which collects all non-informational events for the last 7 days. We can make this task from scratch, but we have template for this task (Admin events).
In the Objects tree browse for Task templates->Administrative and double click on Admin events.
Create task from template window will appear.
You can change the task name and task folder, but I will leave the default values.
Click Next and on Computer tab add your servers to the list
I will add only 2 servers, you can add any number of them.
You can optionally click Test connectivity button to check if the servers are accessible.
Click Next to proceed to the Logs page. Application and System logs are already in the list, but you can add extra logs. Click Next to proceed to the Filter page.
I will not change the filter setting taken from template, but you can modify them as you wish (e.g. change time interval to 1 day or exclude Waring events).
Click Next to review the column settings and then click Next again for the last step.
Now you should export your task into a file.
Consider that you have C:\Tasks folder for the task and exported documents, click Save button to save your task as “C:\Tasks\Admin Events.xml”.
Click Finish button – this will also create the task in the Objects tree.
Doubleclick on the task in the tree to review the events.
Open Command Prompt (or Windows Power Shell) and export task events to Excel
That’s it, the task is scheduled to 8:00 every Monday. You can use Windows Task Scheduler to modify or verify the task.
It is important to specify the username and password using /RU and /RP parameters since the task should be started even if no user logged on your OC. Alternatively you can start the task under System account, but provide the credentials as command-line parameters for logexport.exe. In this case you can use the following command to create the task:
Note that since you scheduled the task to start under the System account, you should run this command elevated (start Command Prompt or PowerShell as Admin).
Now you can run the task e.g. using Task Scheduler to make sure that it works correctly.
Recently we released a new beta of Event Log Explorer 5 and I will show you what features we added.
One of the great new features is a Task. The task defines what events will be picked, which computers from and how they will be displayed.
Example of a task: Display all warning, error and critical events from System and Application logs of VM2012 and SERV1 servers for the last day.
Let’s create it. To create this task, select Tree->Create Task from the main menu.
Input the task name (Sample task) and optionally describe
the task.
Press Next button.
Add names of the computers from which the application will
query events. Note that if you don’t add computers, Event Log Explorer will
query events from the local computer.
Press Next button.
Add event log names you want to get events from. We will
query Application and System logs only.
Press Next.
Now we should create an event query. We can simply use UI to
build the query or type the query manually in the box. In the most cases you
should not type the event query manually. So we will just tick Warning, Error
and Critical levels and enable option to get events for the last 1 day.
Press Next button.
Leave the columns configuration unchanged for this task and press Next.
The task is ready. Tick “Start task now” and press Finish.
The task is started and will be displayed in a view Sample Task.
Note that the task was also added to the Tree. So now you can run it from the tree anytime.
Predefined task templates
Event Log Explorer comes with a set of predefined task templates. These templates let your run standard administrative tasks without learning how to create them.
In the Objects tree browse to Task Templates->Audit.
You will find Audit logons template.
Double click on this template – it will create a new task
based on the template.
In this task just switch to Computers page, add the server name and press Finish button. A new task (Audit Logons) will appear in the tree. Double click on it to run it.
Voila! The event view displays not only logon events, but it also set up custom columns and displays custom columns – User name and Logon type.
Note that we are currently accepting your suggestions on what predefined templates we should add to the program. You can even create a template yourself. To create a template, just create a task, click Save button menu and select Save as template.
We look forward to your feedback and suggestions on the latest
version of Event Log Explorer. You can download it at https://eventlogxp.com/download.php
Sometimes you may need to display who logons your server except for the authenticated domain users. It could be authenticated users from the trusted domain, local users, system services, etc.
First, we define that we will filter the Security log by Event Id = 4624 (as we did before).
New logon group describes the details of a user who logs on.
Let’s display events 4624 where New Logon\Account name is not FSPro. It is very
easy to do using Event Log Explorer filter.
This method works well, but it has several drawbacks:
Filtering by description params works not so fast – Event Log Explorer parses the description every time and checks its params.
Filtering by description params depends on the Windows language. In non-English systems, param names like Account Domain could be translated.
This approach won’t work with Elodea – if you decide to make such a feed.
It works only with Event Log Explorer. In Windows Event Viewer this or similar functionality is not available.
XML Query doesn’t have these drawbacks, but it’s harder to
compose.
Double click on 4624 event and switch to XML tab.
We need to exclude events with TargetDomainName equals to
FSPRO.
You may consider that the XML query should look like
<QueryList>
<Query Id=”0″ Path=”Security”>
<Select Path=”Security”>
*[System[(EventID=4624)]]
and
*[EventData[Data[@Name=’TargetDomainName’] and (Data!=’FSPRO’)]]
</Select>
<Query>
<QueryList>
But this query is wrong. Clause “*[EventData[Data[@Name=’TargetDomainName’] and (Data!=’FSPRO’)]]” will return true in most cases since Data has multi values for the most events.
When you take the first look to Event Log Explorer, you may notice Type column in the event list. In the same time, Windows Event Viewer doesn’t have this column, which may confuse you.
If you worked with Windows Event Viewer in old times (with Windows XP or below), you could see the Type column. There were 5 types of events that can be logged in the classic Windows event log: Error, Warning, Information, Audit Success, and Audit Failure. The last 2 types were used for the Security log only.
Since
Windows Vista (Windows Server 2008), Microsoft removed Type from the event
schema and replaced it with Level. Windows uses the following levels: Critical,
Error, Warning, Information, Verbose (although software
developers may extend this set and add own specific levels). These levels define
event severity, but they don’t define auditing status (success or failure). There
is a new event attribute called keywords. Keywords is a 64-bit mask, every bit
of each may represent a keyword. 2 bits of this mask represent Audit Success
and Audit Failure events.
When a modern Windows Event Viewer displays the Security event log, it shows Keywords column and hides Level column by default. When it displays the other logs, it shows Level and hides Keywords. We believed that this behavior is not very smart and decided to leave classic behavior. So, we added Type column and removed Level and Keywords from the event list. When Event Log Explorer displays events, it defines the source of the event first. If this is an audit event from the Security log, it checks the keywords and displays either Audit Success or Audit Failure as the event type. If this event is not from the security log, it displays the event level as a type. We believe that this approach is better because we can merge security and other events in one list and show only one column for this. And this provides better compatibility with classic event logs as well.
Anyway, if
you need to access real level and keywords attributes, you can always doubleclick
on the even and check the XML representation of the event.
Download Event Log Explorer right now and check the benefits it brings in comparison with Windows Event Viewer.
Nowadays, Windows PowerShell is considered as a replacement of the classic Windows Console (Command Prompt) utility. In Windows 10, it can be set as a default console in Win+X menu
In most cases, when you run command-line utilities from PowerShell and Command Prompt, they will behave exactly the same. However, we discovered that sometimes our command-line utilities work incorrectly when starting from PowerShell, while there are no problems with CMD. After researching, we found that PowerShell may modify command line parameters.
I wrote a simple program which displays its own command-line string:
As you can see, the output of this program exactly matches the input.
Surprise! PowerShell
changes command line by removing the quotation marks when an argument has no
space and replacing single quotes with the double quotes. And this may affect
third-party utilities.
Why does
PowerShell do that?
PowerShell
is not just a console to run programs. It is a system to run scripts. And it
considers strings enclosed in quotes as PowerShell strings.
Workaround
First, if you come across such an issue, we recommend you contact the developers and report this issue. In our products, we will fix these incompatibility issues soon.
As a
workaround, you can enclose double quotes inside single quotes or use two
sequential double quotes:
All seems to be OK except ‘param 5’ parameter, but I believe It’s more important that param/6 and param/7 problems were fixed since they could conflict with command-line switches.
Event Log Explorer can export events into Excel, HTML, CSV and PDF files. The export is implemented as an option of user interface and it can be scheduled using internal Event Log Explorer scheduler. Some time ago, I wrote a couple of articles how to schedule export of events into Excel: https://eventlogxp.com/blog/exporting-event-logs-with-windows-powershell/
Both
methods are not without drawbacks. The Powershell method doesn’t work well with
multi-line descriptions, and Event Log Explorer scheduler requires you to have
Event Log Explorer running.
That’s why
we are removing the scheduler from Event Log Explorer and releasing a new command-line
utility to export events into document files. LogExport utility will be
included with new Event Log Explorer 5 and it’s designed to export Event Log
Explorer tasks (special event views). However, you can use it even right now to
export the whole event logs or log files.
LogExport utility (beta version) is available for download at https://eventlogxp.com/download/logexport.exe
LogExport can save your events in Microsoft Excel (XLSX), Open Document (ODS), CSV, HTML and PDF files. As a console utility, you can schedule it with Task Manager. The command-line interface is clear and well documented. The usage details are available when you run the utility without parameters.
Examples:
To export local
Security log into Excel file, just run it as follows:
logexport /LOGNAME:Security
Note that you
may need to run it as administrator to access the security log.
To export
Application log from server SERV1 into App.pdf file, run it as follows:
Event Log Explorer comes with 3 methods of opening event log files: Standard, New API and Direct. Such an abundance of options may confuse users when choosing the method.
“What
opening method should I use?” – a very common question of our customers.
The answer is very simple:
In most cases use New API method.
But what the
other methods for?
First, I
should remind that Event Log Explorer supports 2 formats of Event Log Files: classic
EVT and modern EVTX. Windows NT, 2000
and XP/2003 log events into EVT files. To access these files Windows introduced
a special Event Logging API which we call StandardAPI). Starting from Windows
Vista/2008, Windows uses EVTX format. In the same time a new Windows Event Log
API was introduced. For compatibility reasons, Windows allowed to open any file
with any API although since Windows 7 support of EVT files was terminated.
In addition
to Windows API, we developed our own way to access event files without using
any API (direct access).
So if you have a modern Windows PC and you want to read classic EVT files, you have no choice except Direct method. More details are available in this article.
And if you want to open EVTX files, always use New API method. Using Standard method would also work, but for some events it may give you incorrect details. You can use Standard method e.g. if you are a software developer and make your own logging. In this case you may check your log to verify how it will look in legacy event log viewers. Direct method for EVTX files was designed to access these files on old Windows XP machines or to access corrupted EVTX log files.
At the time, the US companies spend a total of $120 billion on printed forms annually, and each employee uses about 10,000 sheets of paper according to CompTIA. That’s why printer usage monitoring is very important to cut costs for printer supplies and their utilization. Another reason to know who and how uses corporate printers is to manage your resources and plan upgrades or downgrades of certain printers or print servers.
If you google for “printer usage” or similar phrases, you will find dozens of special software to monitor printers. As a rule, these programs are installed on print servers and most of them are not cheap.
However,
you can track printer usage without any third-party software by analyzing
Windows events of Print Spooler. And use of Event Log Explorer makes this
process much better.
To start monitoring you should enable logging to log \Microsoft-Windows-PrintService/Operational:
Start Event Log Explorer (or Event Viewer), connect to your print server from Event Log Explorer or Windows Event Viewer, browse to event log Microsoft-Windows\\Microsoft-Windows-PrintService/Operational, click right mouse button on it and select Properties.
In Log Properties dialog tick Enable Logging.
Or just run wevutil utility in the elevated prompt as follows:
I assume that you have a print server (Server_name) in your network (running Windows 2008 or higher) and your users print documents via this server. If you have printers connected directly to the user computers, you should consider these computes as print servers and enable logging to PrintService/Operational on them.
If you want to monitor what exactly your user print, I recommend enabling “Allow job name in event logs” policy to log documents name. If you run Windows 2012 or Windows 8, you may need to apply a Windows update as described here.
Now when a user prints a document, several events will be logged into PrintService/Operatinal event log.
The most interesting event for printer usage tracking is event 307 (document was printed). If you open event details of this event and switch to XML representation, you will get detailed information about printing.
Param1 is a print job identifier and can be used to link with other events in this log. Param2 is a document name (if you didn’t enable “Allow job name in event logs” policy, the document name will be “Print Document”. Param3 and Param4 define document owner and computer from which the document was sent to print. Param5 is a printer name. Param6 is a name of the print server port. Param7 is a document size in bytes sent to print server. Param8 is a total number of pages printed by this print job.
So, let’s display some of these details in Event Log Explorer. I will add a printer user (a document owner), printer name, and number of pages as event list columns.
First, we need
to filter unnecessary events out and display only events with event id = 307.
Press Filter button and type 307 in Event ID(s) filed of
the Filter window.
Now we should
add custom columns. Select View->Custom columns from the main
menu and add the first column (Printer user) as follows:
Column
title: Printer user
Value: {PARAM[3]}
Switch to
Column 2 tab and add the second column:
Column
title: Printer
Value: {PARAM[5]}
Switch to
Column 3 tab and add the second column:
Column
title: Pages
Value: {PARAM[8]}
Press OK to
finish and you will see 3 columns in the event list with your data.
Now you can
run Analytical Report and select Custom Column1 stats. This will summarize user print sessions and let
you detect users who print a lot. However, this summary doesn’t take into
account the number of pages, so I recommend using Excel for more accurate assessment.
To export
to Excel, select File -> Export Log from the main menu. Select Excel
2007 document as a target format, make sure that All events is
selected as export scope and tick fields Printer User, Printer and Pages. You
can untick other fields.
Press Export
button and save your data in XLSX document.
That’s it.
Now you can open your XLSX file in Excel and build summary reports from it.
P.S. Some companies may still use old Windows 2003 server to run their print servers. And Event Log Explorer will help in this case too. Print events for Windows 2003 are recorded into System log. Event source is Print, event id = 10. To display Printer user, Printer and page count as custom columns use {PARAM[4]} {PARAM[5]} and {PARAM[8]} respectively.
Update of May 18, 2020: It looks like Windows 10 1909 doesn’t have this issue.
Although era of Windows XP is over, there are still a great number of PCs running this operating system or Windows 2003 Server. According to different researches, in 2018 Windows XP market share was more than 4% of all desktop operating systems. Windows 2003 Server still has more than 10% of server operating systems. Moreover, Microsoft still supports Windows Embedded POSReady 2009 which is based on Windows XP.
This means
that millions of computers across the globe still run XP-based OS and log their
events in classic (evt) event logs.
When
Windows Vista appeared in 2007, it introduced a new event log format along with
new Event Viewer. This Event Viewer went through Windows 7, 8, and got to
Windows 10 practically unchanged. It was designed to open event log files in both
formats – new (evtx) and legacy (evt).
Unfortunately, Windows API doesn’t support evt files anymore and API function OpenBackupEventLog returns error 1500 (Log file is corrupted) when opening evt files. That’s why many third-party event viewers cannot read evt files on modern Windows. Event Viewer parses evt files and displays them like native evtx files. However, Windows 10 Event Viewer stopped working correctly. First, we noticed that it doesn’t display event date and time for evt log files exported with Event Log Explorer (our application can export events to legacy format). Suggesting that this issue could be a bug of Event Log Explorer, we took several event log files from Windows XP – we saved several event logs as files using Windows XP Event Viewer and got a couple of “live” legacy event logs. In every case, Windows 10 Event Viewer failed to display event datetime for these log files.
Since event
timestamp is a key field for any forensic examination, this makes impossible
using Windows Event Viewer as a forensic tool for legacy log analysis.
Event Log
Explorer doesn’t have this problem and displays event date and time correctly.
