Archive for How To

Dell Openmanage Server Administrator is a really useful tool for configuring and monitoring server hardware but it lacks built in E-Mail alerting or notifications.

The software is capable of calling external programs or scripts when a server alert is triggered so I have written a simple script that provides E-Mail alert functionality.

There are a couple of scripts out there that do similar, but I wanted something self contained and capable of using SMTP Authentication with an external relay.

The other problem with OMSA is that you need to go into each individual alert to configure the settings which can be very time consuming, I wanted a way to add them all automatically as I am going to install the script on a number of servers.

Install the script by extracting the DellAlert.Vbs script file from this zip file:

Dell OMSA E-Mail Alerts

Once you have extracted the zip file you will need to edit the variables at the top of the script to make them appropriate for your environment:

The variables at the top define the e-mail settings and are hopefully self explanatory. If a remote SMTP server is not specified the local machine will be used to send the E-Mail.

Below these you can to decide what events you want to be notified of, just comment out any that you aren’t interested in, e.g:

AlertConfig(0)="powersupply|Power supply failure"
AlertConfig(1)="powersupplywarn|Power supply warning"
'AlertConfig(2)="tempwarn|Temperature warning"
'AlertConfig(3)="tempfail|Temperature failure"

I have included every alert available in OMSA 6.2 on a PE T710, some of these alerts won’t be available on older versions or machines.

After you have configured the script, I suggest you test that the E-Mail options by running:

cscript dellalert.vbs testemail

You should receive a test e-mail, if not something isn’t working properly.

When you have successfully tested e-mail, configure OMSA to send alerts by running:

cscript dellalert.vbs setup

You will then see the script go through and setup all the appropriate alerts as per your settings. This process can take a couple of minutes as the “omconfig” command takes a while. This step will not work if you do not have OMSA installed.

Once this is done you should be able to see that the script has been added into OMSA:

Now you need to generate some real alerts to test the script properly. How you do this will depend on the capabilities of your server, I was able to disconnect the redundant power supply and have an alert generated almost immediately. I think opening the case will also generate an event, but I am not sure as I didn’t test. Hopefully you should get something like this in your Inbox:

I have installed this on a few servers and it seems to be working well. I will update the script with any tweaks that I add as I roll it out further. Hope this is useful to someone else.

If you are using Exchange 2007…..

This script will not work properly until you register the 32-Bit version of cdo.dll.  Follow the instructions for doing this here:

http://blogs.msdn.com/mstehle/archive/2007/12/11/fyi-after-installing-exchange-2007-sp1-32-bit-cdosys-might-not-be-registered.aspx

Today I needed to FTP some files to a site that I have used on and off for a number of years. Because I have recently installed Windows 7 I needed to setup the site again in my FTP Client, Core FTP.

Although my old machine still has the connection setup I was not able to see the cached/saved password. Although it is possible to export the sites, the password remained encrypted and I wanted to document the actual password.

There are a lot of tools, some free and some which you have to pay for which will recover the cached FTP password for you. Some of these looked a bit questionable and as FTP is an entirely unencrypted service I thought it should be easy to sniff the password out of the FTP traffic itself.

Turns out that it really is very easy and the saved password can be retreived instantly using netmon.

So here is how to do it.

Create a new capture filter in netmon and enter the following:

tcp.Port==21 and property.TCPPayload.contains("PASS")

Should look like this:

Netmon FTP Password Capture

Then click on the start button to begin capture. Then open your FTP client which contains the cached password and connect to the FTP server.

As soon as you have made a succesful connection switch back to netmon and stop the capture. You should then be able to see the FTP password in clear text in the capture window, something like this:

I spotted a lot of posts from people trying to recover or export their saved FTP passwords from CoreFTP and CuteFTP and many programs are designed specifically for this purpose. This is quick and simple and does not depend on any 3rd party software and should work with any FTP client.

Hope this helps someone.

Categories : How To, Technical Posts
Comments (0)

Today a customer started to get a lot of their e-mails bounced. In fact they could not even e-mail me to let me know about the problem as my own mail servers were rejecting their messages.

The reason for this was because their IP address had been listed on the CBL.

I had a poke around the server and everything seemed to be in good order; patched up to date, virus scanner had nothing interesting to report, netstat did not show any abnormal connections and Exchange queues seemed normal. So I assumed that the problem must be coming from one of the network PCs.

This customer has a dual nic SBS 2003 Standard edition server, not my preferred set-up, but the system had to be implemented in this way to fit in with existing infrastructure. It is not possible to see what traffic is passing through the NAT gateway on RRAS with the built in tools, but Microsoft Netmon 3.1 should be able to show up any strange network traffic. I installed it and ran the following filter:

Tcp.dstport == 25 and ipv4.Address != 192.168.200.1

192.168.200.1 is the IP address of the internet facing NIC on the SBS machine.

Within a couple of minutes this filter showed all the machines on the network sending SMTP based traffic except for the SBS server itself. Fortunately there was only one. I took remote control of the machine and from the command line ran:

netstat -ano |find ?��Ǩ?�:25?��Ǩ�?

The output of this command showed me the local processes which were attempting to communicate with other hosts on port 25 and gave me confirmation that this PC was definitely infected with some kind of mass mailing virus or worm. Killing the process listed by the netstat command stopped the mass mailer and gave some breathing space to find the cause of the problem.

Turns out the machine in question had its virus checker disabled. So I turned it back on and ran a full scan which turned up almost 6,000 files infected with W32/MyDoom.

Once the problem had been found it was easy to sort, but because I have so few customers with this set-up it had not occurred to me how little visibility you get over network traffic with the SBS 2003 standard edition tools.

The joys of travelling sales laptops :D

Categories : How To, Technical Posts
Comments (1)

I regularly use SSH to connect to customer systems and tunnel various different sorts of traffic through it (Telnet, ODBC, RDP etc). In certain cases, I have no other method of remote access to systems other than SSH.

This has not been a problem until I recently upgraded to Windows Vista which includes remote desktop connection v6, which will not allow connections to 127.0.0.1 on any port, it complains with the error message:

“The client could not connect. You are already connected to the console of this computer. A new console session cannot be established”

Which of course is true, if I were trying to connect to 3389.

So today after spending significant effort in the last couple of months I have found a simple solution to the problem:

  • Instruct your SSH client to listen on all interfaces for connections. For command line this means adding “-g” to your connection. I am using putty so ticking the box that says “local ports accept connections from other hosts” under Connection/SSH/Tunnels will do the job.
  • Putty

  • In the remote desktop client use 127.0.0.2 as the destination host and it will then happily pass through any tunnels you have created. For example 127.0.0.2:3390
  • I realize there probably are not that many people out there using SSH to tunnel RDP, but if you are then RDP 6 has been a real pain until now.

    Categories : How To, Technical Posts
    Comments (8)
    Jan
    28

    Exchange 2003 SP2 IMF Keyword Manager

    Posted by: Paulie | Comments (28)

    Exchange 2003 sp2 comes with an updated intelligent message filter. One of the new features of the updated IMF is the ability to add a custom weighting file that gives administrators more control over incoming mail.

    I have used this file a few times on customers systems, usually to allow certain automated e-mails through the IMF which were being incorrectly identified as spam.

    The problem is that Microsoft have not included a GUI to edit the MSExchange.UceContentFilter.xml file. ?Ǭ�So it must be generated by hand, and while this isn’t difficult, it is not very convenient and it is easy to make a mistake.

    I was looking for an excuse to have a play with Visual Basic 2005 and so I have made a little utility to make creating and managing the MSExchange.UceContentFilter.xml a little easier.

    Screenshot 1

    Becomes….

    Generated XML File

    The utility can be downloaded from here.(Requires .net 2.0).

    If you need more information on how to implement the custom weighting feature then see:

    Microsoft Exchange Server 2003 Service Pack 2 Release Notes

    Microsoft Exchange Server Intelligent Message Filter v2 Operations Guide

    Comments (28)