Armchair Sys Admin - Have Your Server Email You Logs

 

Participate in armchair system administration! Have your servers email you logs every morning, or however often you like.

Recently, a few users asked me questions that pertained to system administration on the server, which prompted me to write an article on using scripts to perform common tasks.

Checking daily logs is one of many repetitive tasks that a sysadmin has to go through. It is mundane enough that you wish you don't need to do it everyday, but is crucial enough that you cannot skip. Having your servers email you logs at a scheduled interval will help ease the need of you going to every server and retrieving the logs yourself.

Although scripts can be quite elaborate, performing many functions in a single run, we will start with a simple script. This sample script instructs the server to email you the log or any file. When combined with the at command, you can receive updates of the file at any time of the day.

 

Getting started

Make sure you have the latest script host to take advantage all the functionality. To check your version, type cscript at the command prompt and hit ENTER, you should see something similar to this:

Microsoft (R) Windows Script Host Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.

Along with Usage information. Windows Script Host (WSH) 5.6 is the current version at the time of this article and is downloadable at http://www.microsoft.com/windows/reskits/webresources.

For more information on WSH and other scripting languages, go to: Microsoft's Scripting Guide

http://www.microsoft.com/technet/treeview/default.asp??url=/technet/scriptcenter/scrguide/sagsas_overview.asp

 

Writing the script

To start writing the script, all you need is a plain text editor (i.e. notepad). In fact, a plain text editor is preferred so no formatting information is introduced into the file.

Sample script if SMTP is installed on the server:

' Script to send logs
Set objEmail = CreateObject("CDO.Message")
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objFile = objFSO.OpenTextFile("C:\serverlog.log", 1)
strResponses = objFile.ReadAll
objEmail.From = "server@company.com"
objEmail.To = "sysadmin@company.com"
objEmail.Subject = "Server Log"
objEmail.Textbody = strResponses
objEmail.Send
objFile.Close

This script tells the server to read the c:\serverlog.log file, put its content into the text body of the email and send to you at "sysadmin@company.com" with Subject "Server Log".

This script is certainly not limited to being run on the mail server, it is in fact quite universal and can be run on any server or workstation that has the proper script engine.

Here is a sample script if SMTP isn't installed on the server, be aware of any firewall or email relay issues at your organization:

' Script to send logs
Set objEmail = CreateObject("CDO.Message")
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objFile = objFSO.OpenTextFile("C:\serverlog.log", 1)
strResponses = objFile.ReadAll
objEmail.From = "server@company.com"
objEmail.To = "sysadmin@company.com"
objEmail.Subject = "Server Log"
objEmail.Textbody = strResponses
objEmail.Configuration.Fields.Item _
("http://schemas.microsoft.com/cdo/configuration/sendusing") = 2
objEmail.Configuration.Fields.Item _
("http://schemas.microsoft.com/cdo/configuration/smtpserver") = _
"smtp.company.com"
objEmail.Configuration.Fields.Item _
("http://schemas.microsoft.com/cdo/configuration/smtpserverport") = 25
objEmail.Configuration.Fields.Update
objEmail.Send
objFile.Close

The extra lines specify where to find the SMTP server, and in this sample script, it is set to smtp.company.com, port 25.

You may save this script with a .vbs extension (i.e. SendLog.vbs) or better yet, give it a custom extension (i.e. SendLog.xyz or SendLog.txt). We'll explain why later.

 

Running the script

Running the script is as simple as double-clicking on the .vbs file, or running it at the command prompt:

If you named it with .vbs:
C:\scripts>SendLog.vbs

or if you named it with a custom extension:
C:\scripts>cscript //E:\vbscript c:\scripts\SendLog.txt

The later method is preferred even though it looks clunky to run.
By using a "safer" extension (i.e. .txt), you reduce the risk of inadvertently double-clicking on the script file and execute it by accident. Imagine what happens if the script performs a "grooming" function? The //E:\vbscript argument tells cscript what kind of script engine is required to run the following script. This way, you're able to name your scripts with unconventional extensions (i.e. SendLog.xyz) as well.

 

Tweaking the script

You may tweak this script to suit your needs. Some logs are cycled within the same file, while some are cycled over a certain number of sets, still some are created with dates in the filename. Check out Microsoft's Scripting Guide

http://www.microsoft.com/technet/treeview/default.asp??url=/technet/scriptcenter/scrguide/sagsas_overview.asp

 

Scheduling the script

To schedule this script to run, we'll use the AT command, e.g. (all in one line):

C:\>at 7:00 /every:monday,tuesday,wednesday,thursday,friday,saturday,sunday cscript //e:vbscript c:\scripts\sendlog.txt

The command above instructs AT to run the C:\scripts\sendlog.txt script every day at 7am. You may increase its frequency to your likings, for example, you can have logs sent to you on the hour so if there is any suspicious event in the log you will take notice sooner.

To check if the schedule was committed -

By typing "at" (without quotes) at the command line will show you all the scheduled jobs under the current user (Administrator in this case)-

C:\>at
Status ID Day Time Command Line
------------------------------------------------------------------------------
1 Each M T W Th F S Su 7:00 AM cscript //e:vbscript c:\scripts\sendlog.txt

If the command is executed successfully, you should see the same line for ID 1. If the command failed during its last run, you will see ERROR listed at the Status column. For more information on using the AT command, you can type "at /?" at the command prompt.

Scripts can be quite powerful and can wreck havoc if not tested properly. So please try out your scripts, including the sample scripts above, in a test environment and verify their effects before running them in your production environment!