Recently in Tools & Utilities Category
I'm happy to briefly announce the release of Gateway IP Monitor v1.40 which includes the ability to update a DynDNS host name. We received many feature requests over the last few months, and the ability to update a DynDNS host name was probably the most important one. This feature has been on the list for quite some time, and we finally got around to adding it.
We also cleaned up the user interface (we now have icons!), fixed a few bugs and added the ability to customize the email message.
Remember that Gateway IP Monitor runs as a service and can perform a variety of actions upon an IP address change:
Remember that we offer support for Gateway IP Monitor through our forums, and please do send us feedback.
Enjoy!
We also cleaned up the user interface (we now have icons!), fixed a few bugs and added the ability to customize the email message.
Remember that Gateway IP Monitor runs as a service and can perform a variety of actions upon an IP address change:
- Sends an email (SSL support)
- Updates a DynDNS host name
- Executes a program
- Logs the IP address to a file
Remember that we offer support for Gateway IP Monitor through our forums, and please do send us feedback.
Enjoy!
We decided to release a new version of our free NTToolkit to which we added three useful new utilities and fixed a few minor bugs. You will find that some of these utilities can already be used in conjunction with the Application Scheduler feature of EventSentry, extending its monitoring capabilities to verify database connections, web pages and more.
1. CheckDB
CheckDB, as the name implies, checks a database connection through ODBC. This lets you not only verify that a database server is up, but can also check that a database is online and you can optionally run a SQL statement of your choice.
2. CheckURL
CheckURL is the HTTP version of CheckDB, and allows you to detect changes in web pages (through checksums) and looks for text inside web pages. With CheckURL you'll know when a web page changes or when a particular string is or is not included in a page.
Both CheckDB and CheckURL can log output either to the console or the event log, making it easy to receive alerts from both utilities through EventSentry or any other log monitoring software for that matter.
The application scheduler feature of EventSentry can already log output from command-line utilities to the event log, even when those applications are not "event log aware". This feature is extremely convenient for SysAdmins that run a lot of scheduled scripts, since the output from a script can immediately be sent to you - for example via email.
But back to the NTToolkit. The third new utility is NTPClient.
3. NTPClient
NTPClient retrieves the time from a NTP server and optionally adjusts the local time to match that of the server. NTPClient supports the NTP up to version 3 and takes network latency into consideration when setting the local time. Please note that NTPClient does not run as a service, and as such will have to be called repeatedly if you wish to keep the time of a computer synchronized.
EventSentry v2.90 will actually include a new System Health feature based on this utility and allow you to keep the local time of a monitored computer in sync.
As always, we hope the three new utilities will help you get your job done more easily.
We have more software releases planned for this summer. EventSentry 2.90 will be released in early July and we will also be releasing a new version of AutoAdministrator (2.0), in June/July with a completely re-designed interface and several new features. I will report more on that in late June prior to the release.
1. CheckDB
CheckDB, as the name implies, checks a database connection through ODBC. This lets you not only verify that a database server is up, but can also check that a database is online and you can optionally run a SQL statement of your choice.
2. CheckURL
CheckURL is the HTTP version of CheckDB, and allows you to detect changes in web pages (through checksums) and looks for text inside web pages. With CheckURL you'll know when a web page changes or when a particular string is or is not included in a page.
Both CheckDB and CheckURL can log output either to the console or the event log, making it easy to receive alerts from both utilities through EventSentry or any other log monitoring software for that matter.
The application scheduler feature of EventSentry can already log output from command-line utilities to the event log, even when those applications are not "event log aware". This feature is extremely convenient for SysAdmins that run a lot of scheduled scripts, since the output from a script can immediately be sent to you - for example via email.
But back to the NTToolkit. The third new utility is NTPClient.
3. NTPClient
NTPClient retrieves the time from a NTP server and optionally adjusts the local time to match that of the server. NTPClient supports the NTP up to version 3 and takes network latency into consideration when setting the local time. Please note that NTPClient does not run as a service, and as such will have to be called repeatedly if you wish to keep the time of a computer synchronized.
EventSentry v2.90 will actually include a new System Health feature based on this utility and allow you to keep the local time of a monitored computer in sync.
As always, we hope the three new utilities will help you get your job done more easily.
We have more software releases planned for this summer. EventSentry 2.90 will be released in early July and we will also be releasing a new version of AutoAdministrator (2.0), in June/July with a completely re-designed interface and several new features. I will report more on that in late June prior to the release.
It's been almost 15 years since Microsoft released the first NT-based operating system, Windows NT 3.1, on July 27th 1993. So it came as a bit of a surprise to me that not even the brand-new Windows 2008 ships with an easy way to show the current uptime of the OS.
Linux/Unix users are probably quite familiar with the convenient uptime command, which shows how long the OS has been running and also includes a current load average.
Windows still doesn't ship with such a tool (I will refrain from posting sarcastic assumptions as to why they might not want to do that) which makes it difficult for any SysAdmin to quickly determine how long a machine has been up and running. One can of course dig through the System Event Log to find the 6009 event or create a script, but I'd hardly call that convenient.
That's why, a while back , we developed the free uptime.exe application which is included in our free NTToolkit. Simply run uptime.exe and it will show you the uptime of the system you are logged in as, and keep counting until you abort with CTRL+C:
Uptime: 11 days, 4 hours, 33 minutes, 4 seconds
Uptime.exe also accepts the /onetime parameter which just displays the current uptime and returns, and you can also display the uptime in seconds with the /secs command line switch. This might be useful if you want to use uptime.exe in batch files for example.
You can download uptime.exe from http://www.netikus.net/products_downloads.html, and if you choose the version without the installer then you don't even have to log in. The setup version of the NTToolkit allows you to extract the MSI however, which you could automatically deploy to all of your servers. You could then take advantage of all the tools in the NTToolkit without having to download or install anything.
The upcoming 2.90 release of EventSentry will also be able to track the uptime of all monitored servers, so that you can easily view and compare the uptime of one or more servers through our web reporting interface.
Are you looking for a small tool that would make your life as a SysAdmin easier? Just send an email to suggestions {{AT}} netikus [[DOT]] net.
Linux/Unix users are probably quite familiar with the convenient uptime command, which shows how long the OS has been running and also includes a current load average.
Windows still doesn't ship with such a tool (I will refrain from posting sarcastic assumptions as to why they might not want to do that) which makes it difficult for any SysAdmin to quickly determine how long a machine has been up and running. One can of course dig through the System Event Log to find the 6009 event or create a script, but I'd hardly call that convenient.
That's why, a while back , we developed the free uptime.exe application which is included in our free NTToolkit. Simply run uptime.exe and it will show you the uptime of the system you are logged in as, and keep counting until you abort with CTRL+C:
Uptime: 11 days, 4 hours, 33 minutes, 4 seconds
Uptime.exe also accepts the /onetime parameter which just displays the current uptime and returns, and you can also display the uptime in seconds with the /secs command line switch. This might be useful if you want to use uptime.exe in batch files for example.
You can download uptime.exe from http://www.netikus.net/products_downloads.html, and if you choose the version without the installer then you don't even have to log in. The setup version of the NTToolkit allows you to extract the MSI however, which you could automatically deploy to all of your servers. You could then take advantage of all the tools in the NTToolkit without having to download or install anything.
The upcoming 2.90 release of EventSentry will also be able to track the uptime of all monitored servers, so that you can easily view and compare the uptime of one or more servers through our web reporting interface.
Are you looking for a small tool that would make your life as a SysAdmin easier? Just send an email to suggestions {{AT}} netikus [[DOT]] net.
We have a Linux server running Samba on our network which we use mostly to store ISO images which can be mounted and served on-demand through Samba.
I was looking for a way to issue commands on the Linux machine through SSH yesterday when the Winbind daemon (which is part of Samba and ensures that Linux users are authenticated against our domain controller) on the machine was acting up again. Every time we reboot our Windows 2003 domain controller (which is fortunately not very often but security updates usually require this), the Winbind daemon starts logging a particular error message every 5 minutes to the Syslog daemon which in turn is forwarded to EventSentry by the Linux Syslog daemon.
Since warnings and errors are forwarded to me via email, getting this particular error message every 5 minutes starts getting old after about half an hour - especially when I'm out of the office and get them on my phone. Logging on to the Linux box and restarting the Winbind daemon however solves the problem - and this is what I have been doing for a long time now. Well, until recently.
I thought to myself that if there were a utility that could issue commands through SSH from a Windows box, then I could configure EventSentry to automatically restart the Winbind daemon as soon as the Syslog packet containing the error message is received.
I have been using the free SSH-Client PuTTY for quite some time now, but didn't know that it "included" Plink, a SSH utility that allows you to issue commands through the SSH tunnel and even see the output from the remote command. Perfect!
Setting up EventSentry to automatically restart windbind using plink is a straight-forward 3-step process, assuming you already have the Syslog Daemon in EventSentry up and running:
1. Create a batch file that issues the command you need to run. The batch file I created looks like this:
2. In EventSentry, create a process action that references the above script. You do this by right-clicking the Actions container and selecting Add Action. Then just select the Process tab and point to the batch file you just created.
3. Under the Event Log Packages container, add a filter in an existing package or create a new package. The filter will match the Syslog event that you want to trigger our script. The event source for that filter will always be Application, and the event id should be 9999. Since we don't want the process to be triggered every time a Syslog event comes in, we will also specify the text from the Syslog event - *winbindd*: cli_nt_setup_creds: request challenge failed* in my case. Then just select the process action you created in step 2 and you are all set.
There are a couple of things I need to point out of course. First, make sure that the batch file is secure as it contains the username and password to your Linux host - the appropriate NTFS permission might be enough in most cases. If you cannot keep it secure then you should create a user on the Linux box that is just used for the purpose of issuing particular commands through SSH. Second, make sure that plink.exe is present on the host where the EventSentry Syslog daemon is running, as the file will be executed on that host.
Plink of course is a great utility for automation in any case, regardless of whether you use EventSentry to consolidate Syslog messages. I hope this helps automate some tasks in Windows/Linux environments.
I was looking for a way to issue commands on the Linux machine through SSH yesterday when the Winbind daemon (which is part of Samba and ensures that Linux users are authenticated against our domain controller) on the machine was acting up again. Every time we reboot our Windows 2003 domain controller (which is fortunately not very often but security updates usually require this), the Winbind daemon starts logging a particular error message every 5 minutes to the Syslog daemon which in turn is forwarded to EventSentry by the Linux Syslog daemon.
Since warnings and errors are forwarded to me via email, getting this particular error message every 5 minutes starts getting old after about half an hour - especially when I'm out of the office and get them on my phone. Logging on to the Linux box and restarting the Winbind daemon however solves the problem - and this is what I have been doing for a long time now. Well, until recently.
I thought to myself that if there were a utility that could issue commands through SSH from a Windows box, then I could configure EventSentry to automatically restart the Winbind daemon as soon as the Syslog packet containing the error message is received.
I have been using the free SSH-Client PuTTY for quite some time now, but didn't know that it "included" Plink, a SSH utility that allows you to issue commands through the SSH tunnel and even see the output from the remote command. Perfect!
Setting up EventSentry to automatically restart windbind using plink is a straight-forward 3-step process, assuming you already have the Syslog Daemon in EventSentry up and running:
1. Create a batch file that issues the command you need to run. The batch file I created looks like this:
C:\Batch\plink.exe
root@mylinuxhost -pw SecretPass "/etc/init.d/winbind restart"
2. In EventSentry, create a process action that references the above script. You do this by right-clicking the Actions container and selecting Add Action. Then just select the Process tab and point to the batch file you just created.
3. Under the Event Log Packages container, add a filter in an existing package or create a new package. The filter will match the Syslog event that you want to trigger our script. The event source for that filter will always be Application, and the event id should be 9999. Since we don't want the process to be triggered every time a Syslog event comes in, we will also specify the text from the Syslog event - *winbindd*: cli_nt_setup_creds: request challenge failed* in my case. Then just select the process action you created in step 2 and you are all set.
There are a couple of things I need to point out of course. First, make sure that the batch file is secure as it contains the username and password to your Linux host - the appropriate NTFS permission might be enough in most cases. If you cannot keep it secure then you should create a user on the Linux box that is just used for the purpose of issuing particular commands through SSH. Second, make sure that plink.exe is present on the host where the EventSentry Syslog daemon is running, as the file will be executed on that host.
Plink of course is a great utility for automation in any case, regardless of whether you use EventSentry to consolidate Syslog messages. I hope this helps automate some tasks in Windows/Linux environments.
I recently stumbled across a lesser known Microsoft utility (again) called subinacl.exe that you should take a look at if you haven't already done so. It can be downloaded for free from Microsoft.
The tool is incredibly versatile and lets you change permissions of various system objects, such as files, printers, shares, services, registry keys and more from the command line.
I came across it because we needed a way to change the permission of the EventSentry service to allow a particular user account to read the current service status. So I'm only going to cover the service aspect of the tool in this post.
So how is this useful? Imagine you have a junior admin that you want to allow to manage a particular service on one or more of your servers. You don't want the guy to be a local admin or be able to control all services but instead only be able to control one (or more) particular service.
In this case Windows doesn't actually offer any native way of doing this without using a third party tool - with the exception of using group policy.
So let's say you have user "Johnny" and you want Johnny to be able to stop and start the World Wide Web Publishing service. Simply run the following subinacl.exe command:
subinacl /service W3SVC /GRANT=YOURDOMAIN\Johnny=TO
Obviously you will want to replace YOURDOMAIN with the name of your domain. The TO at the end are the identifiers that tell subinacl which actions you actually want grant to Johnny. T is used for "Start Service" and O is for "Stop Service". The complete list is here:
But don't stop there. Run subinacl.exe /help to see all the other options that are available to you. Of course you can also run the tool remotely by specifying the remote computer name.
You should also check out the MS KB article 288129 that has information on how to accomplish the same thing with group policies and security templates. This might be a better way especially if you have a large number of servers you want to apply this to.
Hope this is useful!
The tool is incredibly versatile and lets you change permissions of various system objects, such as files, printers, shares, services, registry keys and more from the command line.
I came across it because we needed a way to change the permission of the EventSentry service to allow a particular user account to read the current service status. So I'm only going to cover the service aspect of the tool in this post.
So how is this useful? Imagine you have a junior admin that you want to allow to manage a particular service on one or more of your servers. You don't want the guy to be a local admin or be able to control all services but instead only be able to control one (or more) particular service.
In this case Windows doesn't actually offer any native way of doing this without using a third party tool - with the exception of using group policy.
So let's say you have user "Johnny" and you want Johnny to be able to stop and start the World Wide Web Publishing service. Simply run the following subinacl.exe command:
subinacl /service W3SVC /GRANT=YOURDOMAIN\Johnny=TO
Obviously you will want to replace YOURDOMAIN with the name of your domain. The TO at the end are the identifiers that tell subinacl which actions you actually want grant to Johnny. T is used for "Start Service" and O is for "Stop Service". The complete list is here:
F : Full ControlSo after running the command, Johnny will be able to stop and start the service without having any other permissions on the system.
R : Generic Read
W : Generic Write
X : Generic eXecute
L : Read controL
Q : Query Service Configuration
S : Query Service Status
E : Enumerate Dependent Services
C : Service Change Configuration
T : Start Service
O : Stop Service
P : Pause/Continue Service
I : Interrogate Service
U : Service User-Defined Control Commands
But don't stop there. Run subinacl.exe /help to see all the other options that are available to you. Of course you can also run the tool remotely by specifying the remote computer name.
You should also check out the MS KB article 288129 that has information on how to accomplish the same thing with group policies and security templates. This might be a better way especially if you have a large number of servers you want to apply this to.
Hope this is useful!
