Are Your Event Logs Recoverable and Viewable? - 21 Mar 2008

One means of ensuring successful event-log backups is to use WMI's Win32_NTEventLogFile class


Editor's note: This article was originally launched on the Scripting Pro VIP Web site. Thanks to Jim Turner for also making it available to Security Pro VIP readers.

Executive Summary:

Backing up event logs can be problematic because they're open and actively capturing and storing new events just about all of the time, even during backups. If you back up an active, changing file, you'll likely find that the backup file is corrupt and inaccessible. Fortunately, you can use the BackupEventLog method of the Windows Management Instrumentation's (WMI's) Win32_NTEventLogFile class to create recoverable and viewable copies of all your event logs. Here are two scripts that demonstrate how to use the BackupEventLog method.

With organizations' increasing security awareness comes an increasing demand on IT staff to produce event logs and other documentation to attest compliance to security policies and procedures. If there's a security breach or virus outbreak, you can pretty much count on having to recover event logs for in-house security administrators and auditors or even third-party auditors to review. During these high-pressured times, the last thing you want to hear is that the event logs you provided aren't viewable.

So, are your event logs recoverable and viewable? You might want to double check by restoring a few older event logs to a temporary folder and verifying that you can actually open and view them with Event Viewer. Hopefully, you'll have no problem restoring and viewing the files. However, there's a good chance that you won't if your backup software or procedure simply backs up event logs in their open state. If you find this to be the case, consider yourself better off discovering this in advance rather than after sending those files to security personnel.

The primary problem with backing up event logs is that they're open and actively capturing and storing new events just about all of the time, even during backups. If you back up an active, changing file (particularly one that isn't a text-based file), you'll likely find that the backup file is corrupt and inaccessible. You can see this for yourself by performing a simple test: Copy one of your event logs to a temporary folder and try opening that file with Event Viewer. You'll likely find that you can't open it. Some backup software includes methods that enable successful event-log backups and restores, but you need to test your software to find out for sure.

One means of ensuring successful event-log backups is to use Windows Management Instrumentation's (WMI's) Win32_NTEventLogFile class. By using a script or scheduled task that incorporates this class's BackupEventLog method, you can create recoverable and viewable copies of all your event logs. The event logs are static and not open during system backups, so when they're restored, you can count on them being accessible and uncorrupted.

To help ensure successful and restorable event-log backups, I created a script, EventLogBackup.vbs, that backs up event logs locally using the BackupEventLog method on all computers in a specified organizational unit (OU). I also created another script, EventLogBackupAndCopy.vbs, that not only performs the local event-log backup but also copies the backup files to a central location. Centralizing the event-log backup files makes it easier for security personnel to conduct the review process. You can download both scripts by clicking the Download the Code Here button at the top of the page. Because EventLogBackupAndCopy.vbs offers additional functionality, I'll discuss how to use that script and describe how it works.

How to Use EventLogBackupAndCopy.vbs
EventLogBackupAndCopy.vbs performs two main operations while cycling through all the computers in a specified OU. First, the script uses the BackupEventLog method on each computer to back up that machine's event logs, storing those backup files in a designated folder on that machine. Then, the script copies the backup files to a central server, which I refer to as the event-log collection server. The script records the results of the backup and copy operations in a transaction log, which resides on the event-log collection server. The transaction log identifies any errors encountered and contains the entries for all successful event-log backups and all successful file-copy operations.

Before you can use EventLogBackupAndCopy.vbs, you need to customize four paths in it so that it works in your domain. Here are the paths and the variables you use to you specify them:

  • The EventLogBackupDir variable, which callout A in Listing 1 shows, contains the path to the folder in which you want to store the local event-log backup files. This folder will reside on each machine contained in the target OU. The script will create the folder if it doesn't already exist. When you enter the path for this variable, keep in mind that the drive you specify must exist on all the computers in the target OU.
  • The Dest variable in callout A specifies the path to the event-log collection server. Note that this variable isn't used in EventLogBackup.vbs because that script only stores the backup files on the local machine.
  • The TransactionLogDir variable, which callout A in Listing 1 shows, contains the path to the folder in which the transaction log will be created. I've chosen to keep the transaction log in the same folder that will contain the event-log copies on the collection server.
  • Callout B in Listing 1 highlights the ADsPath to the target OU. Simply replace the ADsPath in callout B with the ADsPath to the OU that contains the computers you want to back up. If you don't have your computers organized within a specific OU, you'll need to modify this script to use an array or list of computers.

In callout A in Listing 1, you probably noticed another variable named ThisComputer. I use a scheduled task to run EventLogBackupAndCopy.vbs from the event-log collection server. I use the ThisComputer variable within the Dest variable to specify the collection server's name because it's much cleaner than hard-coding a server name. Plus, it makes the script more portable if I need to use it on another collection server. (You can, of course, specify a hard-coded path for the EventLogBackupDir and TransactionLogDir variables.)

After you customize EventLogBackupAndCopy.vbs with your paths, all you need to do is set up a scheduled task to run the script. When the script finishes, spot check a few of the event logs you backed up on the local computers, check the destination folder on the event-log collection server for copies of the backup files, and review the transaction log for errors. Remember that if you just want to perform the event-log backups and don't want to have copies of those backups on a collection server, use EventLogBackup.vbs rather than EventLogBackupAndCopy.vbs.

How EventLogBackupAndCopy.vbs Works
Besides containing the variables you need to customize, Listing 1 contains several snippets of code that makes preparations for the backup and copy operations. Venturing down the listing just below callout A you'll see that I create the timestamper variable, which contains a date-like string that specifies the date and time when the script ran. I append this string to my transaction log's filename so it ends up looking something like EventLogCollection_10_14_2007_8_54_33PM.log.

Next, I create a FileSystemObject object and check to see whether the transaction log folder exists. If it doesn't, I create it. The next snippet of code creates the transaction log and writes a start time to it. I then use the FileSystemObject object again to check to see whether the destination folder exists on the event-log collection server. If it doesn't, I create that folder as well.

The last preparation in Listing 1 involves connecting to Active Directory (AD), using the WMI Query Language (WQL) SELECT statement to retrieve the computer names in the target OU, and creating a recordset to store those computer names. The script cycles through the names in the recordset, performing the backup and copy operations on each of the named computers.

Listing 2 contains the code that actually performs the backup and copy operations. In short, the code creates a WMI instance, creates an event-log backup folder if it doesn't exist, creates a collection of event-log objects, backs up each event log locally, and copies the backup files to the event-log collection server. All along the way the success or failure of each transaction is logged.

Let's take a closer look at some of the code in Listing 2. In callout A, notice the moniker I use when creating the WMI instance. Both the Backup and Security privileges are included. The Backup privilege is required because the script is backing up event logs. The Security privilege is needed to access the Security event log. After creating the instance, I check for the existence of the event-log backup folder and create it on the local computer if it doesn't exist (callout B).

In callout C, I create the collection of event-log objects for a machine by selecting all the objects of the Win32_NTEventLogFile class. For the most part, the collection will consist of a System Event Log item, an Application Event Log item, and a Security Event Log item. (Some servers might have more than these three types of event logs.)

After creating the collection, I start cycling through each item in it. For each item, I first check to see whether a previously created event-log backup exists. If so, I delete it. The OldEvtLog variable contains the pathname of the file that needs to be deleted should it exist. Deleting the file is necessary if you want to write newer event-log backup files to the same location. Unfortunately, overwriting existing files isn't an option because the BackupEventLog method will fail if a backup file with the same name exists.

The actual event-log backup takes place at callout D. The BackupEventLog method performs the backup operation. This method's syntax is straightforward because it requires only one parameter: the pathname for the backup file to be created. In this case, the pathname is formed through concatenation. The EventLogBackupDir variable provides the path to the folder in which the backup file is to be stored. The backup file's name and extension are obtained by using the Win32_NTEventLogFile class's FileName and Extension properties. The BackupLog variable holds the return code of the backup attempt. If the backup is successful, a value of 0 is returned.

Assuming the backup was successful, the backup file is copied to the event-log collection server. Callout E highlights this copy operation. I begin this section of code by setting up a variable named copythis, which will contain the full pathname of the backup file I want to copy to the collection server. In the concatenated pathname, note that I replace the colon in the EventLogBackupDir variable's value with a dollar sign. This is necessary when you don't have a share name present on all computers. In this case, I'm referencing the C$ admin share on the individual computers. With the backup file's full pathname in hand, I create an instance of the file by using the FileSystemObject object's GetFile method.

The last step is to use the FileSystemObject object's Copy method to copy the event-log backup file to the event-log collection server. You have some options concerning how the copies of the backup files are named and whether each computer's backup files will appear in its own separate folder on the collection server. There are three alternatives:

  • Alternative 1 tacks on the local machine's name to the backup files' names. When this alternative is chosen, all the event logs from every computer are copied into the same folder on the collection server. However, they're easily identifiable because the computers' names are in the filenames. Note that each file is overwritten on subsequent script executions.
  • Alternative 2 tacks on the local machine's name and a timestamp to the backup files' names. When this alternative is chosen, the backup files won't be overwritten because they'll always be unique because of the timestamp. Keep in mind, though, that this could consume a lot of space on your collection server.
  • Alternative 3 doesn't change the backup files' names but instead creates a separate folder for each computer on the collection server and copies that computer's backup files to that folder. This is the default action—that is, Alternative 3's code isn't commented out like the code is for the other two alternatives.

If you want to use Alternative1 or Alternative 2, simply uncomment the code under the desired alternative and comment out the code under Alternative 3.

A Step in the Right Direction
EventLogBackupAndCopy.vbs and EventLogBackup.vbs can help ensure that your event-log backups are recoverable and viewable in the event of a security breach or virus outbreak. The process I have described will help you create those backup files. However, you still need to perform your daily backups to tape or other media on top of what I've shown you.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.