Windows PowerShell for Administration: The Personal Trainer (2015)

Chapter 7. Managing Windows Events and Logs

In Windows, an event is any significant occurrence in the operating system that requires users or administrators to be notified. Events are recorded in the Windows event logs and provide important historical information to help you monitor systems, maintain system security, solve problems, and perform diagnostics. It’s not just important to sift regularly through the information collected in these logs, it is essential. Administrators should closely monitor the event logs of every business server and ensure that workstations are configured to track important system events. On servers, you want to ensure that systems are secure, that applications and services are operating normally, and that the server isn’t experiencing errors that could hamper performance. On workstations, you want to ensure that the events you need to maintain systems and resolve problems are being logged and that the logs are accessible to you as necessary.

Working with Event Logs

The Windows service that manages event logging is called the Windows Event Log service. When this service is started, Windows logs important information. The logs available on a system depend on the system’s role and the services installed. Two general types of log files are used:

· Windows Logs Logs that the operating system uses to record general system events related to applications, security, setup, and system components

· Applications and Services Logs Logs that specific applications and services use to record application-specific or service-specific events

Logs you might see include the following:

· Application This log records significant incidents associated with specific applications. For example, Microsoft Exchange Server logs events related to mail exchange, including events for the information store, mailboxes, and service states. By default, this log is stored in %SystemRoot%\System32\Winevt\Logs\Application.evtx.

· DFS Replication On domain controllers using DFS replication, this log records file replication activities on the system, including events for service status and control, scanning data in system volumes, and managing replication sets. By default, this log is stored in %SystemRoot%\System32\Winevt\Logs\DFS Replication.Evtx.

· Directory Service On domain controllers, this log records incidents from Active Directory Domain Services (AD DS), including events related to directory startup, global catalogs, and integrity checking. By default, this log is stored in %SystemRoot%\System32\Winevt\Logs\Directory Service.Evtx.

· DNS Server On Domain Name System (DNS) servers, this log records DNS queries, responses, and other DNS activities. By default, this log is stored in %SystemRoot%\System32\Winevt\Logs\DNS Server.Evtx.

· Forwarded Events When event forwarding is configured, this log records forwarded events from other servers. The default location is %SystemRoot%\System32\Winevt\Logs\FordwardedEvents.Evtx.

· Hardware Events When hardware subsystem event reporting is configured, this log records hardware events reported to the operating system. The default location is %SystemRoot%\System32\Winevt\Logs\HardwareEvent.Evtx.

· Microsoft\Windows A group of logs that track events related to specific Windows services and features. Logs are organized by component type and event category.

· Security This log records events related to security, such as logon/logoff, privilege use, and resource access. By default, this log is stored in %SystemRoot%\System32\Winevt\Logs\Security.Evtx.

TIP To gain access to security logs, users must be granted the user right named Manage Auditing And Security Log. By default, members of the administrators group have this user right.

· Setup This log records events logged by the operating system or its components during setup and installation. The default location is %SystemRoot%\System32\Winevt\Logs\Setup.Evtx.

· System This log records events from the operating system or its components, such as the failure of a service to start, driver initialization, system-wide messages, and other messages that relate to the system. By default, this log is stored in %SystemRoot%\System32\Winevt\Logs\System.Evtx.

· Windows PowerShell This log records activities related to the use of Windows PowerShell. The default location is %SystemRoot%\System32\Winevt\Logs\Windows PowerShell.Evtx.

Events range in severity from informational messages to general warnings to serious incidents such as critical errors and failures. The category of an event is indicated by its event level. Event levels include:

· Information Indicates an informational event has occurred, which is generally related to a successful action.

· Warning Indicates a general warning. Warnings are often useful in preventing future system problems.

· Error Indicates a critical error, such as a DHCPv6 address configuration problem.

· Critical Indicates a critical error, such as the computer rebooting after a power loss or crash.

· Audit Success Indicates the successful execution of an action that you are tracking through auditing, such as privilege use.

· Audit Failure Indicates the failed execution of an action that you are tracking through auditing, such as failure to log on.

TIP Of the many event types, the two you’ll want to monitor closely are warnings and errors. Whenever these types of events occur and you’re unsure of the reason, you should take a closer look to determine whether you need to take further action.

In addition to having a level, each event has the following common properties associated with it:

· Computer Identifies the computer that caused the event to occur.

· Data Any data or error code output by the event.

· Date and Time Specifies the date and time the event occurred.

· Description Provides a detailed description of the event and can include details about where to find more information with which to resolve or handle an issue. This field is available when you double-click a log entry in Event Viewer.

· Event ID Details the specific event that occurred with a numeric identifier. Event IDs are generated by the event source and used to uniquely identify the event.

· Log Name Specifies the name of the log in which the event was entered.

· Source Identifies the source of the event, such as an application, service, or system component. The event source is useful for pinpointing the cause of an event.

· Task Category Specifies the category of the event, which is sometimes used to further describe the related action. Each event source has its own event categories. For example, with the security source, categories include logon/logoff, privilege use, policy change, and account management.

· User Identifies the user account that caused the event to be generated. Users can include special identities, such as Local Service, Network Service, and Anonymous Logon, as well as actual user accounts. The user account can also be listed as N/A to indicate that a user account is not applicable in this particular situation.

The GUI tool you use to manage events is Event Viewer. You can start this tool by typing eventvwr at the PowerShell prompt for the local computer or eventvwr ComputerName, where ComputerName is the name of the remote computer whose events you want to examine. As with most GUI tools, Event Viewer is easy to use, and you might want to continue to use it for certain management tasks.

PowerShell provides several commands for working with the event logs, including the following:

· Get-WinEvent Gets events from event logs and event tracing log files on the local computer or specified remote computers.

Get-WinEvent [-ListLog] LogNames {BasicParams}
Get-WinEvent [-ListProvider] ProviderNames {BasicParams}

Get-WinEvent [-Path] LogFilePath {BasicParams} {AddtlParams}
Get-WinEvent [-LogName] LogName {BasicParams} {AddtlParams}
Get-WinEvent [-ProviderName] Name {BasicParams} {AddtlParams}

Get-WinEvent –FilterHashTable Values {BasicParams} {AddtlParams}

{BasicParams}
[-ComputerName ComputerName] [-Credential CredentialObject]

{AddtlParams}
[-FilterXPath XPathQuery] [-Oldest] [-MaxEvents NumEvents]

REAL WORLD XPath queries help you create custom or filtered views of event logs, allowing you to quickly and easily find events that match specific criteria. Because XPath queries can be used on any compatible system, you can re-create custom and filtered views on other computers simply by running the query on a target computer.

· Clear-EventLog Deletes all entries from specified event logs on the local computer or specified remote computers. (Works with all standard Windows logs, but doesn’t work with logs under Microsoft\Windows or other non-standard logs.)

Clear-EventLog [[-ComputerName] ComputerNames]
[-LogName] LogNames

· Get-EventLog Gets a list of the event logs or the events in a specified event log on local or remote computers. (Works with all standard Windows logs, but doesn’t work with logs under Microsoft\Windows or other non-standard logs.)

Get-EventLog [-List] [-ComputerName ComputerNames]
[-AsString]

Get-EventLog [-ComputerName ComputerNames] [-LogName] LogName
[-AsBaseObject] [-After DateTime] [-Before DateTime]
[-EntryType EntryTypes] [-Index IndexValues]
[[-InstanceID] ID] [-Message Message] [-Newest NumEvents]
[-Source Sources] [-UserName UserNames]

· Limit-EventLog Configures limits on event log size and event retention for specified logs on specified computers. (Works with all standard Windows logs, but doesn’t work with logs under Microsoft\Windows or other non-standard logs.)

Limit-EventLog [-ComputerName ComputerNames]
[-MaximumKiloBytes MaxSize] [-OverFlowAction {DoNotOverwrite
| OverwriteAsNeeded | OverwriteOlder] [-Retention MinDays]
[-LogName] LogNames

· Show-EventLog Displays the event logs of the local computer or a remote computer in Event Viewer. (Works with all standard Windows logs, but doesn’t work with logs under Microsoft\Windows or other non-standard logs.)

Show-EventLog [[-ComputerName] ComputerName]

NOTE You can use Get-Event, Wait-Event, and Remove-Event to work with the PowerShell event log. When you are creating your own event logs, you can use New-EventLog, Register-ObjectEvent, Register-EngineEvent, Unregister-Event, Get-EventSubscriber, and Register-WmiEvent. New-EventLog works with all standard Windows logs, but doesn’t work with logs under Microsoft\Windows or other non-standard logs.

Monitoring system events isn’t something you should do haphazardly. Rather, it is something you should do routinely and thoroughly. With servers, you will want to examine event logs at least once a day. With desktop computers, you will want to examine logs on specific computers as necessary, such as when a user reports a problem.

Viewing and Filtering Event Logs

You can obtain detailed information from the event logs using either Get-EventLog or Get-WinEvent. Get-EventLog is handy for its versatility and simplicity. Use Get-WinEvent when you want to apply complex filters, such as those based on XPath queries or hashtable strings. If you don’t use complex filters, you really don’t need Get-WinEvent.

The basic syntax for Get-EventLog is

get-eventlog "LogName" [–computername ComputerNames]

where LogName is the name of the log you want to work with—such as “Application,” “System,” or “Directory Service”—and ComputerNames are the names of remote computers you want to work with. In this example, you examine the Application log:

get-eventlog "Application" –computername fileserver87, dbserver23

NOTE Technically, the quotation marks are necessary only when the log name contains a space, as is the case with the DNS Server, Directory Service, etc.

The output of this query will look similar to the following:

Index Time EntryType Source InstanceID Message
----- ---- --------- ------ ---------- -------
22278 Feb 27 10:54 Information DQLWinService 0 The description for Event ID '0' in Source 'DQL

22277 Feb 27 10:49 Information DQLWinService 0 The description for Event ID '0' in Source 'DQL

As you can see, the output shows the Index, Time, EntryType, Source, InstanceID, and Message properties of events. The Index is the position of the event in the event log. The Time is the time the event was written. The EntryType shows the category of the event. The Source shows the source of the event. The InstanceID shows the specific event that occurred with a numeric identifier (and is the same as the EventID field in the event logs). The Message shows the description of the event.

Because the index is the position of the event in the log, this example lists events 22,277 and 22,278. By default, Get-EventLog returns every event in the specified event log from newest to oldest. In most cases, this is simply too much information, and you’ll need to filter the events to get a usable amount of data. One way to filter the event logs is to specify that you want to see details about only the newest events. For example, you might want to see only the 50 newest events in a log.

Using the –Newest parameter, you can limit the return to the newest events. The following example lists the 50 newest events in the security log:

get-eventlog "security" -newest 50

One of the key reasons for using Get-EventLog is its ability to group and filter events in the result set. When you group events by type, you can more easily separate informational events from critical, warning, and error events. When you group by source, you can more easily track events from specific sources. When you group by event ID, you can more easily correlate the recurrence of specific events.

You can group events by Source, EventId, EntryType, and TimeGenerated using the following technique:

1. Get the events you want to work with, and store them in a variable, such as

$e = get-eventlog -newest 100 -logname "application"

2. Use the Group-Object cmdlet to group the event objects by a specified property. In this example, you group by EventType:

$e | group-object -property eventtype

Another way to work with events is to sort them according to a specific property. You can sort by Source, EventId, EntryType, or TimeGenerated using the following technique:

1. Get the events you want to work with, and store them in a variable, such as

$e = get-eventlog -newest 100 -logname "application"

2. Use the Sort-Object cmdlet to sort the event objects by a specified property. In this example, you sort by EntryType:

$e | sort-object -property entrytype

Typically, you won’t want to see every event generated on a system. More often, you will want to see only warnings or critical errors, and that is precisely what filters are for. Using filters, you can include only events that match the criteria you specify. To do this, you search the EntryType property for occurrences of the word error. Here is an example:

1. Get the events you want to work with, and store them in a variable, such as

$e = get-eventlog -newest 500 -logname "application"

2. Use the Where-Object cmdlet to search for specific text in a named property of the event objects stored in $e. In this example, you match events with the Error entry type:

$e | where-object {$_.EntryType -match "error"}

With the –Match parameter, the Where-Object cmdlet uses a search algorithm that is not case-sensitive, meaning you can type Error, error, or ERROR to match error events. You can also search for warning, critical, and information events. Because Where-Object considers partial text matches to be valid, you don’t want to enter the full entry type. You can also search for warn, crit, or info, such as

$e = get-eventlog -newest 100 -logname "application"
$e | where-object {$_.EntryType -match "warn"}

You can use Where-Object with other event object properties as well. The following example searches for event sources containing the text User Profile Service:

$e = get-eventlog -newest 500 -logname "application"
$e | where-object {$_.Source -match "User Profile Service"}

The following example searches for event ID 1530:

$e = get-eventlog -newest 500 -logname "application"
$e | where-object {$_.EventID -match "1530"}

Sometimes, you’ll want to find events that occurred before or after a specific date, and you can do this using the –Before and –After parameters. The –Before parameter gets only the events that occur before a specified date and time. The –After parameter gets only the events that occur after a specified date and time.

In the following example, you get all of the errors in the System log that occurred in July 2015:

$Jun30 = get-date 6/30/15
$Aug1 = get-date 8/01/15

get-eventlog -log "system" -entrytype Error –after
$jun30 -before $aug1

In the following example, you get all of the errors in the System log that occurred in the last seven days:

$startdate = (get-date).adddays(-7)
get-eventlog -log "system" -entrytype Error -after $startdate

You can automate the event querying process by creating a script that obtains the event information you want to see and then writes it to a text file. Consider the following example:

$e = get-eventlog -newest 100 -logname "system" $e |

where-object {$_.EntryType -match "error"} >
\\FileServer18\www\currentlog.txt

$e = get-eventlog -newest 100 -logname "application" $e |
where-object {$_.EntryType -match "error"} >>
\\FileServer18\www\currentlog.txt

$e = get-eventlog -newest 100 -logname "security" $e |
where-object {$_.EntryType -match "error"} >>
\\FileServer18\www\currentlog.txt

Here, you are examining the system, application, and security event logs and writing any resulting output to a network share on FileServer18. If any of the named logs have error events among the 100 most recent events in the logs, the errors are written to the CurrentLog.txt file. Because the first redirection is overwrite (>) and the remaining entries are append (>>), any existing Currentlog.txt file is overwritten each time the script runs. This ensures that only current events are listed. To take the automation process a step further, you could create a scheduled job that runs the script each day or at specific intervals during the day.

Setting Log Options

Log options allow you to control the size of the event logs as well as how logging is handled. By default, event logs are set with a maximum file size. Then, when a log reaches this limit, events are overwritten to prevent the log from exceeding the maximum file size.

You use Limit-EventLog to set log options. The basic syntax is

Limit-EventLog [-ComputerName ComputerNames] [-LogName] LogNames
Options

Here ComputerNames are the names of the computers you are configuring, LogNames sets the logs to modify, and Options includes one or more of the following:

· –MaximumSize Sets the maximum size in bytes of a log file. The size must be in the range 64 KB to 4 GB, in increments of 64 KB. Make sure that the drive containing the operating system has enough free space for the maximum log size you select. Most log files are stored in the %SystemRoot%\System32\Winevt\Logs directory by default.

· –OverFlowAction Sets the event log wrapping mode. The options are DoNotOverwrite, OverwriteAsNeeded, and OverwriteOlder. With DoNotOverwrite, the computer generates error messages telling you the event log is full when the maximum file size is reached. With OverwriteAsNeeded, each new entry overwrites the oldest entry when the maximum file size is reached, and there are no limitations. With OverwriteOlder, new events overwrite only events older than the value specified by the Retention property when the maximum file size is reached. If there are no events older than the minimum retention value, the computer generates error messages telling you events cannot be overwritten.

· –Retention Sets the minimum number of days that an event must remain in the event log.

In the following example, you configure the system log with a maximum size of 4096 KB, an overflow action of OverwriteOlder, and a minimum retention period of seven days:

limit-eventlog –maximumsize 4096kb –overflowaction
overwriteolder –retention 7 –logname system

If you are configuring multiple computers, you can use the –ComputerName property to specify the computer names. Or you can get the list of computer names from a text file as shown in the following example:

limit-eventlog -computername (get-content c:\data\clist.txt)
–maximumkilobytes 4096 –overflowaction overwriteolder
–retention 7 –logname system

Here, you get the list of remote computers to manage from a file called CList.txt in the C:\Data directory.

Archiving and Clearing Event Logs

On key systems such as domain controllers and application servers, you’ll want to keep several months’ worth of event logs. However, it usually isn’t practical to set the maximum log size to accommodate this. Instead, you should allow Windows to periodically archive the event logs, or you should manually archive the event logs. Logs can be archived in four formats:

· Event files (.evtx) format, for access in Event Viewer

· Tab-delimited text (.txt) format, for access in text editors or word processors or for import into spreadsheets and databases

· Comma-delimited text (.csv) format, for import into spreadsheets or databases

· XML (.xml) format, for saving as a structured Extensible Markup Language (XML) file.

The best format to use for archiving is the .evtx format. Use this format if you plan to review old logs in the Event Viewer. However, if you plan to review logs in other applications, you might need to save the logs in a tab-delimited or comma-delimited format. With the tab-delimited or comma-delimited format, you sometimes need to edit the log file in a text editor for the log to be properly interpreted. If you have saved the log in the .evtx format, you can always save another copy in the tab-delimited or comma-delimited format later by doing another Save As after opening the archive in the Event Viewer.

Windows creates log archives automatically when you select the event log-wrapping mode Archive The Log When Full, Do Not Overwrite Events. This mode is set in Event Viewer.

You can create a log archive manually by following these steps:

1. In Event Viewer, you should see a list of event logs. Right-click the event log you want to archive, and select Save Events As from the shortcut menu.

2. In the Save As dialog box, select a directory and type a log file name.

3. In the Save As Type dialog box, Event Files (*.evtx) is the default file type. Select a log format as appropriate and then choose Save.

4. If the Display Information dialog box is displayed, choose the appropriate display options and then click OK.

If you plan to archive logs regularly, you might want to create an archive directory. This way you can easily locate the log archives. You should also name the log file so that you can easily determine the log file type and the period of the archive. For example, if you’re archiving the system log file for January 2015, you might want to use the file name System Log January 2015.

When an event log is full and you want to clear it, you can do so using Clear-EventLog. The basic syntax is

Clear-EventLog [-ComputerName ComputerNames] [-LogName] LogNames

Here ComputerNames are the names of the computers you are configuring and LogNames sets the logs to clear, such as

clear-eventlog system

Writing Custom Events to the Event Logs

Whenever you work with automated scripts, scheduled jobs, or custom applications, you might want those scripts, tasks, or applications to write custom events to the event logs. For example, if a script runs normally, you might want to write an informational event in the application log that specifies this so that it is easier to determine that the script ran and completed normally. Similarly, if a script doesn’t run normally and generates errors, you might want to log an error or warning event in the application log so that you’ll know to examine the script and determine what happened.

Windows PowerShell includes built-in logging features that log events to the PowerShell event log. You can view events in this log using Get-EventLog. You control logging using the following environment variables, which must be set in the appropriate profile or profiles to be applicable:

· $LogCommandHealthEvent Determines whether errors and exceptions in command initialization and processing are logged

· $LogCommandLifecycleEvent Determines whether PowerShell logs the starting and stopping of commands and command pipelines and security exceptions in command discovery

· $LogEngineHealthEvent Determines whether PowerShell logs errors and failures of sessions

· $LogEngineLifecycleEvent Determines whether PowerShell logs the opening and closing of sessions

· $LogProviderHealthEvent Determines whether PowerShell logs provider errors, such as read and write errors, lookup errors, and invocation errors

· $LogProviderLifecycleEvent Determines whether PowerShell logs adding and removing of PowerShell providers

If you set a logging variable to $True, the related events are logged in the PowerShell log. Use a value of $False to turn off logging.

You can create custom events using the Eventcreate utility. Custom events can be logged in any available log except the security log, and they can include the event source, ID, and description you want to use. The syntax for Eventcreate is as follows:

eventcreate /l LogName /so EventSource /t EventType /id EventID
/d EventDescr

· LogName Sets the name of the log to which the event should be written. Use quotation marks if the log name contains spaces, as in “DNS Server.”

TIP Although you cannot write custom events to the security log, you can write custom events to the other logs. Start by writing a dummy event using the event source you want to register for use with that log. The initial event for that source will be written to the application log. You can then use the source with the specified log and your custom events.

· EventSource Specifies the source to use for the event, and can be any string of characters. If the string contains spaces, use quotation marks, as in “Event Tracker.” In most cases, you’ll want the event source to identify the application, task, or script that is generating the error.

REAL WORLD Carefully plan the event source you want to use before you write events to the logs using those sources. Each event source you use must be unique and cannot have the same name as an existing source used by an installed service or application. Further, you shouldn’t use event source names used by Windows roles, role services, or features. For example, you shouldn’t use DNS, W32Time, or Ntfrs as sources because these sources are used by Windows Server.

Additionally, once you use an event source with a particular log, the event source is registered for use with that log on the specified system. For example, you cannot use “EventChecker” as a source in the application log and in the system log on FILESERVER82. If you try to write an event using “EventChecker” to the system log after writing a previous event with that source to the application log, you will see the following error message: “ERROR: Source already exists in 'Application' log. Source cannot be duplicated.”

· EventType Sets the event type as Information, Warning, or Error. Audit Success and Audit Failure event types are not valid; these events are used with the security logs, and you cannot write custom events to the security logs.

· EventID Specifies the numeric ID for the event, and can be any value from 1 to 1,000. Before you assign event IDs haphazardly, you might want to create a list of the general events that can occur and then break these down into categories. You can then assign a range of event IDs to each category. For example, events in the 100s could be general events, events in the 200s could be status events, events in the 500s could be warning events, and events in the 900s could be error events.

· EventDescr Sets the description for the event, and can be any string of characters. Be sure to enclose the description in quotation marks.

Eventcreate runs by default on the local computer with the permissions of the user who is currently logged on. As necessary, you can also specify the remote computer whose tasks you want to query and the Run As permissions using /S Computer /u [Domain\]User [/P Password], where Computer is the remote computer name or IP address, Domain is the optional domain name in which the user account is located, User is the name of the user account whose permissions you want to use, and Password is the optional password for the user account.

To see how you can use Eventcreate, consider the following examples:

Create an information event in the application log with the source Event Tracker and event ID 209:

eventcreate /l "application" /t information /so "Event Tracker"
/id 209 /d "evs.bat script ran without errors."

Create a warning event in the system log with the source CustApp and event ID 511:

eventcreate /l "system" /t warning /so "CustApp" /id 511
/d "sysck.exe didn't complete successfully."

Create an error event in the system log on FileServer18 with the source “SysMon” and event ID 918:

eventcreate /s FileServer18 /l "system" /t error /so "SysMon"
/id 918 /d "sysmon.exe was unable to verify write operation."

Creating and Using Saved Queries

Event Viewer supports XPath queries for creating custom views and filtering event logs. XPath is a non-XML language used to identify specific parts of XML documents. Event Viewer uses XPath expressions that match and select elements in a source log and copy them to a destination log to create a custom or filtered view.

When you are creating a custom or filtered view in Event Viewer, you can copy the XPath query and save it to an Event Viewer Custom View file. By running this query again, you can re-create the custom view or filter on any computer running Windows or Windows Server. For example, if you create a filtered view of the application log that helps you identify a problem with SQL Server, you can save the related XPath query to a Custom View file so that you can create the filtered view on other computers in your organization.

Event Viewer creates several filtered views of the event logs for you automatically. Filtered views are listed under the Custom Views node. When you select the Administrative Events node, you see a list of all errors and warnings for all logs. When you expand the Server Roles node and then select a role-specific view, you see a list of all events for the selected role.

You can create and save your own custom view by following these steps:

1. Start Event Viewer by clicking Event Viewer on the Tools menu in Server Manager.

2. Select the Custom Views node. In the Actions pane or on the Action menu, click Create Custom View.

3. In the Create Custom View dialog box, use the Logged list to select the included time frame for logged events. You can choose to include events from Anytime, Last Hour, Last 12 Hours, Last 24 Hours, Last 7 Days, or Last 30 Days. You also can specify a custom range.

4. Use the Event Level check boxes to specify the level of events to include. Select Verbose to get additional detail.

5. You can create a custom view for either a specific set of logs or a specific set of event sources:

· Use the Event Logs list to select event logs to include. You can select multiple event logs by selecting their related check boxes. If you select specific event logs, all other event logs are excluded.

· Use the Event Sources list to select event sources to include. You can select multiple event sources by selecting their related check boxes. If you select specific event sources, all other event sources are excluded.

6. Optionally, use the User and Computer(s) boxes to specify users and computers that should be included. If you do not specify the users and computers to be included, events generated by all users and computers are included.

7. Click the XML tab to display the related XPath query.

8. Click OK to close the Create Custom View dialog box. In the Save Filter To Custom View dialog box, type a name and description for the custom view.

9. Select where to save the custom view. By default, custom views are saved under the Custom View node. You can create a new node by clicking New Folder, typing the name of the new folder, and then clicking OK.

10. Click OK to close the Save Filter To Custom View dialog box. You should now see a filtered list of events.

11. Right-click the custom view and then select Export Custom View. Use the Save As dialog box to select a save location and enter a file name for the Event Viewer Custom View file.

The Custom View file contains the XPath query that was displayed on the XML tab previously. Members of the Event Log Readers group, administrators, and others with appropriate permissions can run the query to view events on remote computers using the following syntax:

eventvwr ComputerName /v: QueryFile

Here ComputerName is the name of the remote computer whose events you want to examine and QueryFile is the name or full path to the Custom View file containing the XPath query, such as

eventvwr fileserver18 /v: importantevents.xml

When Event Viewer starts, you’ll find the custom view under the Custom Views node.