Recently in EventSentry Category

Most of the time I work on a Lenovo laptop running Windows 7, and I'm overall quite happy with the laptop (especially after the mainboard was replaced and it stopped randomly rebooting). However, a minor nuance had been bugging me for a while: If I plugged my computer into a LAN (I have a docking station at work and at home) while a wireless signal was also available (and configured on the laptop), Windows 7 would keep both connections active.


1. The Problem

So I'd have my laptop in the docking station, connected to a 1Gb Ethernet network, and yet the laptop would also be connected to a WiFi network. While not a big deal per se, it does have a few advantages to automatically disable the WiFi connection when already connected to Ethernet:

• Avoid potential connectivity issues
• Increase security by not transmitting data via Wifi when not necessary
• Increase battery life when connected to a LAN
• Because you can!
  

Now, Lenovo equips most (if not all) laptops with a software called "Access Connections", a pretty nifty and free tool! One of the things it can do, is disable a Wireless adapter when the computer is connected to Ethernet. However, it never re-enables it when you disconnect from the wired network (at least I haven't found a way), and besides not everybody has Lenovo laptop.

So how could I disable the WiFi connection automatically when I connected the laptop to an Ethernet, yet automatically re-enable it when there is no Ethernet connection?


2. The Research

After some intense brainstorming, I remembered two things:

1. Most Ethernet NIC drivers log event to the System event log when a network port is connected/disconnected.
2. A while back, I used the netsh command to configure DNS servers from the command line. Maybe one could toggle the state of network adapters with this tool as well?

3. Evidence Gathering

The first one was easy, a quick look at the system event log revealed the following event:

A similar event is logged when the "network link" has connected. The event shown here is specific to the driver of my laptop's network card (an Intel(R) 82577LM adapter), but most newer drivers will log events when a cable is disconnected or the link is otherwise lost. If you are already running EventSentry with its hardware inventory feature enabled, then you can obtain the name of the network adapter from any monitored host on the network through the hardware inventory page, an example is shown below.

Coming up with a way to enable and disable a particular network connection with netsh.exe was a bit more challenging, but I eventually cracked the cryptic command line parameters of netsh.exe.

Enable a connection
netsh interface set interface "Wireless Network Connection" ENABLED

Disable a connection
netsh interface set interface "Wireless Network Connection" DISABLED

And yes, you do need to specify the word "interface" twice. If you do find yourself wanting to automate network adapter settings with scripts and/or the command line frequently, then you should check out this link.


4. The Solution

So now that we have all the ingredients, let's take a look at the recipe. In order to accomplish the automatic interface toggling, we need to create:

• an embedded script called wifi_enable.cmd, using the command line from above
• an embedded script called wifi_disable.cmd, again using the command line from above
• a process action "Wifi Enable", referencing the above wifi_enable.cmd embedded script
• a process action "Wifi Disable", referencing the above wifi_disable.cmd embedded script
• an event log filter for event source "e1kexpress" and event id 27, triggering the "Wifi Enable" action
• an event log filter for event source "e1kexpress" and event id 32, triggering the "Wifi Disable" action
  

A couple of clarifications: First, you do not need to use embedded scripts, you can create the scripts in the file system too and then point the process action to those files. I prefer embedded scripts since I don't have to worry about maintaining the script, as it gets distributed to remote hosts automatically when needed. Second, the event source and event id will depend on the network card you have installed on your network, the above example will only work with Lenovo T410 laptops.

So what happens is pretty straightforward: When I connect my laptop to a LAN, the Intel NIC driver writes event id 32 with the event source e1kexpress to the system event log. EventSentry intercepts the event and triggers the Wifi Disable action, which in turns runs the netsh.exe process, disabling the WiFi connection.


5. Setting it up in the management console

Embedded Scripts
You can manage embedded scripts via Tools -> Embedded Scripts. Click "New", specify a descriptive name (e.g. wifi_enable.cmd) and paste the command line netsh interface set interface "Wireless Network Connection" ENABLED into the script content window. Then, do the same for the wifi_disable.cmd script, but this time use the netsh interface set interface "Wireless Network Connection" DISABLED command line. You can leave the interpreter empty as long as you give the filename the .cmd extension.

Actions

I recommend enabling both "Event Log Options", as this will help with troubleshooting. Now we just need the event log filters, and we are all set.

• Process Action
  
• Event Log Filters
  
• Embedded scripts
  

EventSentry v2.92
The main new features in version 2.92 are:

• Network Services component
• Embedded performance / environment charts
• HTTP action
• Hardware Inventory & Monitoring

Please see the release history or the documentation for a complete list of all bug fixes and new features.

Network Services
The network services component is the main new feature in EventSentry, and adds powerful functionality - the ability to receive SNMP traps - to our monitoring solution. Any network device that supports SNMP v1, v2c or v3 can be configured to send traps to EventSentry, which can then either forward the trap details via email, or log them to the database for archival and searching purposes.

Unlike other products, configuring the snmp trap daemon is easy and uncomplicated. Simply specify any MIBs you want to load, configure any SNMP communities and/or v3 users, and (optionally) setup text filters to include/exclude specific traps based on their content.

The network services component now also includes the syslog daemon, which was previously embedded in the EventSentry agent. This change includes higher availability, since the network services will cache incoming (snmp and/or syslog) packets if the main database is temporarily unavailable.

Another new "feature" is the ability to run the network services daemon on Linux and OS X operating systems. We developed all code in the network services to run on multiple platforms, and will continue to do so with all upcoming new components in EventSentry. Cross-platform functionality is still experimental, and as such we don't currently have an installer for non-Windows operating systems. If you are interested in running the network services daemon on Linux or OS X, then please send a request to our support team.

Visualizing performance and environment data with embedded charts
Performance monitoring and alerts have always been a popular and useful feature in EventSentry, but a numerical alert can only convey so much information. If an alert shows that the CPU usage has been exceeded, say 80% over a time period of 10 minutes, then it is often helpful to see the performance data in a chart. This would show whether the CPU usage spiked during the beginning of the 10-minute interval and is back in an acceptable range, or whether the CPU usage has been mostly constant. In the past, you would need to review the performance history through the web-based reporting (which is still an option and desirable for long-term analysis), but starting with v2.92 email alerts can now include an embedded chart which shows exact performance information from the monitored time interval.

For example, if your performance alert is configured to generate an alert when the CPU usage exceeds 90% for more than 30 minutes, then you can receive an attachment in addition to the text alert, showing performance data from the last 30 minutes.

Embedded charts are also included with temperature and/or humidity environment alerts, an example chart is shown below:

Even though Microsoft Exchange Server 2010 has already been released, many organizations still use Exchange 2003. In this article I'll explain how to thoroughly monitor the various Internet protocols that Exchange 2003 offers, including SMTP, POP3, IMAP (and NNTP for that matter). The reason why I'll only be looking at Exchange 2003 is because there is a significant difference in architecture between Exchange 2003 and later versions.

It is a common misconception that you can effectively monitor the W3SVC service (commonly referred to as IIS, though IIS encompasses a lot more than just a web server) and other services provided through IIS, such as SMTP and POP3, by simply monitoring their associated service. It's a misconception, because a given IIS-based service may contain multiple instances - most commonly the case with the World Wide Web Service which often hosts multiple independent web sites. The status of these instances can be controlled independently of the hosting service, though that service needs to be running of course.

Don't despair though, most server-based windows applications, fortunately, can be monitored by ensuring that their respective service is - well - running. For example, to ensure that the Apache service is up, you "simply" make sure that the Apache service is running. The same goes for countless other services such as MySQL - even SQL Server (of course you can still detach individual databases in SQL Server).

Exchange 2003, due its partnership with the Internet Information Services 6.0, is different though. Yes, IIS and Exchange 2003 are tightly coupled, and if you intend to have your Exchange Server 2003 communicate with any other server using a standard Internet protocol such as SMTP, then you will need IIS.

The screenshot above shows that the inetinfo.exe process hosts all the major services (bold name), and that each service can host one or more instance. For more details please see http://technet.microsoft.com/en-us/library/bb124674(EXCHG.65).aspx.

The three most common Internet services your Exchange 2003 server is running are probably SMTP, POP3 and IMAP4. While a lot of attention is being paid to the core Exchange services such as

  • Microsoft Exchange Information Store (MSExchangeIS)
  • Microsoft Exchange System Attendant (MSExchangeSA)

The services providing SMTP, POP3 and IMAP4 connectivity are usually similarly important, especially the SMTP service. Looking at the EventSentry service status page immediately reveals that the SMTP, POP3 and IMAP4 services are managed by IIS:

As you can see, IMAP4Svc, POP3Svc and SMTPSvc all use inetinfo.exe (Executable column) for their host process. So why is this important again?

Since all of these services support multiple instances INSIDE the service (inetinfo.exe), the host process will continue to run even when one or more instances inside the service are stopped. Since most installations only have one instance, stopping that one instance inside the service will still leave the service up and running. The effect of course is the same; the service is not available to the end users while the Windows service will happily continue to run.

A screen shot from the System Manager application shows instances listed inside:

As you can see with the IMAP4 protocol, we have two virtual servers setup that are both hosted inside the "Microsoft Exchange IMAP4" service. To stubbornly illustrate my point further I took a screenshot that shows both IMAP4 instances stopped while the service itself is running:

So I think we're all in agreement now that monitoring the POP3, SMTP etc. services in Exchange 2003 is not enough if you want to ensure that these services are actually available. So how do we monitor all of these instances?
The easiest way is actually with a VBScript, which is included below. VBScript works well since the cscript.exe interpreter is readily installed on Windows 2003, so no additional installation of tools is required. The script enumerates all instances of a given protocol, and checks whether they are running or not. If at least one instance is not running, the tool will return 1, thus setting the ERRORLEVEL to 1.

This VBScript can then be embedded into EventSentry, which will then run the script at set intervals using the application scheduler, notifying you via email (with the proper filter setup) when an instance is stopped. There's a screencast for that, you can view it at http://www.eventsentry.com/screencasts/eventsentry-application-scheduler/eventsentry-application-scheduler.htm. It shows you how to create an embedded script and setup EventSentry to notify you when the scripts returns an error. Note that the screencast uses an older version of the script which only monitored web sites (not SMTP, IMAP4, ...), but the process of setting up the script with EventSentry is exactly the same.

You should be able to use the script as-is, just configure which protocols are monitored by adjusting the values in the "Define which protocols to monitor here" section. The script always prints all installed instances and their status, and any stopped instance is prefixed with an asterisk. Below is what an email from EventSentry looks like:

The line with the stopped instance won't be yellow in the actual email, I just added this for readability. The script can also easily be modified to automatically start any stopped instances - simply add the line

Instance.Start

after line 102. This will still trigger an email (or error) to notify you that it was stopped, but a subsequent run of the script at the next monitoring interval should not trigger an error again if the start was successful.

A note of caution here though - I have seen the script hang indefinitely with this line added when an instance that is currently stopped can't be started because it's not configured correctly. Hence, it's not included by default.