This is the second part in a series of Kixtart scripts. The complete series will illustrate how to create a complete Kixtart Systems Management Server (KSMS) using only Kixtart and various freeware utilities and programs which are part of the Windows operating system. KSMS enables an administrator to perform administrative tasks in off-hours and without being present at the remote computer. It can be used to install programs, remove programs, clean up the harddisks, and modify regitry entries. It does not cook coffee though. It is compatible with both Windows NT/2000 and Windows 9x.

The first part described a modular login script for Windows 9X/NT/2K. The latest version on the modular login script can be found at http://kixtart.org/cgi-bin/ultimatebb.cgi?ubb=get_topic&f=2&t=002682.

The second part covers the server part of the KSMS. The server part consists of one Kixtart script, two initialization files, and two function libraries. The MAINTENANCE_SERVER.KIX script calls various functions in those two UDF libraries. Nevertheless, all listed UDFs are used throughout KSMS.

The file COMPUTERS.DB is an .INI file that is created by the login script. The important entry for each computername (the name in the brackets) is the MAC address (used for Wake-On-LAN functionality). All other entries are for informational reasons only to get a quick idea what type of computer it is. They are not necessary for KSMS. Basically, each time the login script runs it writes/updates the current MAC address associated with the specific computer. More precisely, if a user elects to integrate the computer into KSMS, it'll update the information, otherwise that computer is treated as a guest computer (e.g. laptop computer of a visiting researcher in my case)

The file MAINTENANCE_LIST.INI is used mainly to communicate between the login script and the maintenance client script. The maintenance server script is using the MAINTENANCE_LIST.INI file to read the type of scheduling service for a specific computer and to write logging information into the file. Thus, it is possible to track down problems with the initialization of the computer maintenance on a computer.

In order for the maintenance server script to schedule maintenance it requires either the Task Scheduler or the Scheduler service. If the Scheduler service is used, then the service must be run under an administrative account since the SYSTEM account cannot establish network connections.

The maintenance server script is scheduled to run every night (1am seems to be a good time since virtually nobody is working at this time of day). It first initializes itself, loads its UDF libraries and sets the logging options. Each screen printout is also written into a log file to trace errors and monitor the script. One does not need to be logged into the computer that is running the maintenance server script as long as it is run through the Task Scheduler and is using a global administrative account. I created special KIX_SRV and KIX_CLI accounts for the server and client part of KSMS.

The server then reads a list of computers from MAINTENANCE_LIST.INI and the associated scheduler type. It checks whether it can access the admin share on each remote computer. If it cannot access it then the computer either has no admin share (therefore the client script will not be run) or the computer is not reachable. If the computer is not reachable the server script reads the MAC address and uses MAGIC.EXE to send a MagicPacket to the remote computer. This will trigger a Wake-On-LAN request for that computer if the NIC supports it. Then the script waits a little bit and checks wheter the computer is waking up by trying to access the admin share (with a 5 minute timeout). If the computer woke up successfully (admin share accessible) the script continues otherwise the script starts again with the next computer in its list.

If the remote computer is accessible through the admin share, the CLIENT_MAINTENANCE.BAT file is copied to the remote computer. This file contains a call to the CLIENT_MAINTENANCE.KIX script which does the maintenance on the remote computer. The Kixtart script sits on a server, thus is not accessible to a normal user. Also, if a user manipulates the CLIENT_MAINTENANCE.BAT then it will be overwritten with the version on the server the next time the client maintenance is initialized. This should effectively prevent tampering.

Finally, it schedules the execution of CLIENT_MAINTENANCE.BAT on the remote computer using either the Task Scheduler or the Scheduler service. The Task Scheduler is scheduled with JT.EXE from the Microsoft Windows 2000 Resource Kit Supplement 3 which is a CLI for the Task Scheduler. See also http://kixtart.org/cgi-bin/ultimatebb.cgi?ubb=get_topic&f=1&t=003208 and http://kixtart.org/cgi-bin/ultimatebb.cgi?ubb=get_topic&f=12&t=000060

This example of KSMS has been used for nine months to manage a computer network consisting of over 80 Windows 9x, NT, and 2000 computers. As part of the systems management all computers have been upgraded to Internet Explorer 5.5 Service Pack 2, an antivirus package has been distributed and various server-based applications have been installed (Microsoft Project, Microsoft Publisher, Microsoft Visio, SPSS). Additionally, system policies have been applied through the manipulation of registry entries and programs on the remote computers have been upgraded if necessary (e.g. Adobe Acrobat from 5.0.0 to 5.0.5). It is also used to essentially push specific applications to the remote computers.

The Kixtart Systems Management Server scripts and support utilities are provided on an AS-IS basis. There is no support for it and proper functionality is not guaranteed. It is advisable to test the systems on a limited basis before deploying it to a whole in-production network.