I used to use Scheduled Tasks
to run all my systems
administration scripts. However,
in a few situations, I found that
Scheduled Tasks wasn't as
efficient as I would've liked.
Sometimes, I needed a script to run
continuously or I had to know
immediately when a script
failed. For these special
situations, I tried to use the Schtasks
utility as well as a script to
schedule and manage tasks.
Although Schtasks works well
for its intended purpose, I had
limited success in using it for
my purpose because it was
difficult to get the systems
administration scripts' results in the
format I wanted. And using a
script to schedule and manage
tasks only works when the task
is created using the Win32_ScheduledJob class or the At
utility.
So, I tried running a few of
my systems administration
scripts as services. When you
run a script as a service, the
script can run constantly. Plus,
you have several recovery
options available. Through the
Recovery tab in a service's
Properties dialog box, you can
configure the service to restart itself
if it stops. Alternatively, you can
configure the service to run
another script or similar type of
program to alert you when it
stops. Another option is to
restart the computer, but in a
production environment, that
isn't advisable.
Nowadays, I run scripts as
services in addition to using
Scheduled Tasks. (These two
approaches are complementary
rather than mutually exclusive.)
To make it easy to install a script
as a service, I created an HTML
Application (HTA). I chose to
create an HTA because I like the
Windows look and feel of HTAs.
More important, users know
exactly what information they
need to provide. And if they
happen to fill out a text box
incorrectly, they can just re-enter
the information (providing they
didn't click the Execute button).
In addition, with HTAs, you can
easily include Help information.
You can download my HTA
file, Install_service.hta, from the
Windows Scripting Solutions
Web site.
Before you use it, it's helpful to
know how the HTA's UI works,
how the HTA runs a script as a
service, and how to adapt a
script that you want to run as a
service.
How the HTA's UI Works
I knew that other people at my
company would use Install_
Service.hta, so I made it
straightforward to use. As Figure 1 shows, the HTA's UI has text boxes in which users specify the
name of the computer to install the
service on, the service's name and
description, the location of the script to
run as a service, and optional
credentials for remote connections.
Note the BROWSE button that's next to the text box in which users enter the script's pathname. When users click this button, they can browse for the file, just like they can do in most Windows applications. To achieve this functionality, the HTA uses the UserAccounts.
CommonDialog object. This object provides the standard File Open dialog box. Unfortunately, this object is available only in Windows XP. However, if you enter a network or local pathname, the HTA won't use this object, so the script will work on Windows 2000 and later OSs. (For information about the User-Accounts.CommonDialog object, go to http://www.microsoft.com/technet/scriptcenter/resources/qanda/jan05/hey0128.mspx.)
Besides the browsing capability, the HTA offers a built-in Help document, which users can access by clicking the help link on the UI. Instead of opening an Internet address, this link triggers an onclick event, which prompts the helpdoc subroutine to run. This subroutine opens a Microsoft Internet Explorer (IE) window and displays information about how to use the HTA.
When users click the Install Service button in the HTA's UI, the script calls the getfile subroutine, which Listing 1 shows. This subroutine searches the Admin$\system32 folder on the target computer for srvany.exe. Srvany.exe, which you can find in any Windows resource kit, is a Windows service that starts another application. (For information about how to create a userdefined service with srvany.exe, go to the article at http://www.support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/q137/8/90.asp& NoWebContent=1.)
If the getfile subroutine doesn't find srvany.exe, a message box appears, prompting the user to enter the file's location in the HTA's UI. After the user provides a pathname, the subroutine uses VBScript's InStr function to search that pathname for the string ftp to determine whether to look on a network or an FTP site for srvany.exe. (The company I work for has an FTP site on which we store utilities and other files.) When srvany.exe is on an FTP site, the subroutine uses the HttpRequest object (Microsoft.XMLHTTP) to download the file to the Admin$\system32 folder, as callout A in Listing 1 shows. When srvany.exe is on a network share, the subroutine uses the Microsoft Scripting Runtime Library's FileSystemObject object to copy the file to the Admin$\system32 folder, as callout B in Listing 1 shows. You're probably familiar with the FileSystemObject object but that might not be the case with the HttpRequest object, which is part of the Microsoft XML Document Object Model (DOM). So, I'll give a brief description of how the getfile subroutine uses this object.
You can use the HttpRequest object to send an HTTP request to a URL, receive the response, and have that response parsed by the XML DOM engine. In this case, the getfile subroutine directs the HTTP request to a file on an FTP site, then passes the response to a Stream object (adodb.stream). You can use the Stream object, which is part of ActiveX Data Objects (ADO), to read, write, and manage a stream of binary data or text. In this case, the subroutine uses the Stream object to write the response to a binary file on the client.
How the HTA Runs a Script as a Service
Now that you know how the HTA's UI
works, let's look at how the HTA runs
a script as a service. This feat is
accomplished by connecting to the
target computer on which the service
will run, creating a service on that
machine, configuring the service's
registry settings, starting the service, and
displaying the script's progress.