#68671 - 2002-07-29 06:45 PM
KiXtart Systems Management Server (Part III, The Client) [a.k.a The Complete Package]
|
Sealeopard
KiX Master
Registered: 2001-04-25
Posts: 11164
Loc: Boston, MA, USA
|
Kixtart Systems Management Server
Developed by Jens Meyer (sealeopard on the KIXtart BBS at http://81.17.37.55/board/ultimatebb.php)
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 system on a limited basis before deploying it to a whole in-production network.
Certain words and/or word-combinations/phrases might be trademarked/servicemarked/copyrighted/*marked in which case applicable legal provisions apply.
OVERVIEW
The Kixtart Systems Management Server (KSMS) consists of three main scripts, the login script, the server script, and the client script.
The login script is used to log every domain user into the domain.
The server script runs on a computer that serves as the distribution point for all files that are part of KSKS.
The client script runs on each computer that has been integrated into KSMS.
The server and client scripts as well as all support files should be located on a dedicated share on the KSMS computer.
Both scripts should run under a special administrative account that will be used to log the client script into a computer.
KSMS requires the presence of Task Scheduler under Windows NT/2000/XP and the client script runs automatically upon the first login of the day under Windwos 9x.
KSMS FLOWCHART
1) User runs login script and integrates computer into KSMS
2) Maintenance server script runs on a regular interval (like 1am each night) and schedules the client script on all clients that are not powered down. Powered-down computers will be sent a Wake-On-LAN packet in case the NIC supports Wake-On-LAN and the client script will be scheduled as soon as the client has completed to boot up.
3) Client maintenance script runs, checks for granted application install requests, checkes services, registry keys, applications, installs applications. Reboots computer if reboot is necessary and nobody is logged in or displays a reboot request.
4) User runs login script and grants/dceclines application update/install requests.
FUTURE OF KSMS
KSMS is currently being rewritten/modified for KiXtart 4.11 and will feature more functionality based on WMI and ADSI. A SQL-based inventory manager will most likely be included in the next release. Estimated date of release: Whenever it's done, or maybe a day earlier.
Download the complete package here: [url= http://s91376351.onlinehome.us/kixtart/ksms.zip] http://s91376351.onlinehome.us/kixtart/ksms.zip[/url] [830kb]
LOGIN SCRIPT (excerpt from readme_login.txt):
The script is controlled by a collection of .INI files therefore protecting the KiXtart code from modifications. Adapting the login script will only require modifications to the .INI files but not the script itself unless you'd like to take out code segments that do not apply to your environment.
The script itself works in interaction with a client-server based maintenance script system. The maintenance scripts are not necessary for the correct functioning of the login script though. The installation of certain software products and the creation of specific user directories is done by the maintenance script but activated by the login script. E.g. the user has to allow the installation of any software package that will require the computer to reboot automatically in order to finish the installation. Some of my users run multi-day number-crunching routines and I'm therefore preventing the computer from rebooting at an inappropriate time. Additionally, if there is a reboot scheduled the user will be warned upon login.
The script provides extensive logging options. Nearly every screen output (the output that the user sees in the login window) can be written into a unique log file, therefore enabling the administrator to read the exact output for debugging purposes. Additionally, most errors and warnings are trapped and written into a separate error log. Finally, a login log keeps track of each login attempt on a per-day basis, thus one doesn't need to check multiple domain controllers to see when a user logged into a specific computer. All these logging options can be enabled/diabled in the login script initialization file.
The login script has the ability to detect a users login location based on the IP address used (currently tested with single-NIC computers only). Drive and printer mappings can be initiated based on the detected location. The script demonstrates this by differentiating between a Class C subnet (the NT domain), a VPN connection through a Cisco 3000 VPN Concentrator, a dial-up connection, and a connection through a Class B subnet.
MAINTENANCE SERVER SCRIPT (excerpt from readme_maintenance_server.txt):
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.
MAINTENANCE CLIENT SCRIPT (excerpt from readme_maintenance_client.txt)
This is the third and last 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 described the server script for Windows 9X/NT/2K and can be found at http://81.17.37.55/board/ultimatebb.php?ubb=get_topic;f=2;t=002897.
This part gives an overview of the client script of the Kixtart Systems Management Server. It will illustrate the general technique used to manage a heterogeneous array of Windows OS-based computers.
This system is in production on a 80+ computer network and has been running stable for oven nine months.
The maintenance client script is located on a networked share on the same computer that is running the maintenance server script. This will prevent unauthorized changes to the script since regular users only require read access and only if Windows 9x workstations need to be supported. If only Windows NT/2000/XP computers are supported, then access to the maintenance script can be limited to the account that runs the maintenance script.
The client maintenance script should be run under a special account that has full local administrative rights on all targeted workstations. It should not be run under any regular account to prevent misuse and enable better auditing of the script.
The script is initalized by a batch file which is copied to the local workstation by the maintenance server script and scheduled to start at a certain time (preferably at night). When the client batch file starts, it connect to the KSMS share of the central computer and starts running the Kixtart script. It then goes through the different subroutines and executes them one by one, pretty much like a washing maschine cycle.
Certain subroutine check for the presence of applications. If an application cannot be detected or is determined to be outdated, an update/install request is written into the maintenance_list.ini .INI file. On a subsequent user login, this file is checked by the login script whether it contains any update/install requests. The login script then queries the user whether to permit the install/update. If the request is denied, the next user will get prompted again. If the request is granted, the maintenance client script will read the granted request during the next maintenance cycle. This will trigger the actual insta or update. Most of the time, the computer is then instructed to reboot after the maintenance script finished. This will allow the operating system to gracefully finish potential sections of an applicaton install that require a reboot, e.g. replacements of in-use file which is done during a reboot.
As a special case, if the Internet Explorer 5.x+ is being installed, the maintenance script will actually initialize an automatic log-in after reboot and finish setting up the Internet Explorer. It will also automatically clean up the auto-login settings and reboot again after a specific time.
Installation and update routines are provided for internet Explorer 5.5 Service Pack 2, Symantec Norton Antivirus 7.0, Adobe Acrobat 5.0, Adobe Acrobat Reader 5.0, StorageCentral QuotaAdvisor Snap-In, SPSS 10 Client, The Mathworks Matlab 6.1, and various Microsoft Office products. Most fo the information about creating unattended installations for differen application and installer program can be found at http://www.appdeploy.com. Additionally, Microsoft provides Resource Kits for Office and Internet Explorer that create unattended installs for various Microsoft products.
Download the complete package here: [url= http://s91376351.onlinehome.us/kixtart/ksms.zip] http://s91376351.onlinehome.us/kixtart/ksms.zip[/url] [830kb]
<small>[ 29 July 2002, 19:17: Message edited by: sealeopard ]</small>
Edited by Sealeopard (2007-02-17 05:05 AM)
_________________________
There are two types of vessels, submarines and targets.
|
|
Top
|
|
|
|
|
#68681 - 2002-08-27 02:42 PM
Re: KiXtart Systems Management Server (Part III, The Client) [a.k.a The Complete Package]
|
Howard Bullock
KiX Supporter
Registered: 2000-09-15
Posts: 5809
Loc: Harrisburg, PA USA
|
Curiosity is killing me. What aspects of my logon script framework did you like?
[ 27. August 2002, 14:43: Message edited by: Howard Bullock ]
|
|
Top
|
|
|
|
|
#68684 - 2002-08-27 06:00 PM
Re: KiXtart Systems Management Server (Part III, The Client) [a.k.a The Complete Package]
|
Fernando Madruga
Starting to like KiXtart
Registered: 2002-08-21
Posts: 149
Loc: Coimbra.Portugal.Europe.Earth....
|
3 secs here, another 3 elsewhere, and when you look again your logon time decreases substancially...
Especially when we're talking about "adding", that is, currently I have *NO* logon script for my users; if they start having to wait 20 seconds, that will be 20 seconds *more* than they were used to!
The second, "hidden" advantage would be to "conceal" those scripts from some prying eyes... Surelly, there could be still someone left that went all the way looking on the net for KIX32.EXE and finds out how to "uncompress" them, but hey, that simple way of "hiding" stuff from end users works with 99.99% of them!
Besides, if Kix had some compress/decompress routines built in, then it would very easy to copy the compressed DLLs,scripts,UDFs,OCX,whatevers and simply copy those (when needed) from the server... And then we'd be talking about some potencial major savings... ![[Smile]](images/icons/smile.gif)
Just my 0.02 € worth...
_________________________
Later,
[b]Mad[/b]ruga
|
|
Top
|
|
|
|
|
#68688 - 2002-08-29 06:36 PM
Re: KiXtart Systems Management Server (Part III, The Client) [a.k.a The Complete Package]
|
Lonkero
KiX Master Guru
Registered: 2001-06-05
Posts: 22346
Loc: OK
|
fernando, I have been thinking a little this comp thing...
one way could be converting the script by keywords in it.
say script has structure:
code:
$ReturnCode=writevalue("me_key","me_value","me_data","REG_SZ")
$ReturnCode=writevalue("me_key","you_value","you_data","REG_SZ")
$ReturnCode=writevalue("me_key","him_value","him_data","REG_SZ")
? "me_key written"
exit 0
translating this with keywords can be done with some udf stuff, reducing the functionnames to one char...
but found problem with that solution as shortening of commands do not worky...
so went other way.
make a reference of keywords used in the script and list them in ini-like way in the scripts bottom.
then the script could be got to:
code:
$code="1=2(3,4,5,6) 1=2(3,7,8,6) ..."
for each $line in split($code)
$t=""
for each $letter in split($line,"")
$t=$t+readprofilestring("@scriptpath"+"\@scriptname","k",$letter)
next
$e=execute("$t")
next
exit 0
[k]
1="$ReturnCode"
2="writevalue"
3="me_key"
4="me_value"
5="me_data"
6="REG_SZ"
7="you_value"
8="you_data"
9="him_value"
10="him_data"
11="?"
12="me_key written"
13=
as the basic idea...
I don't want to code the whole stuff directly to this bb-window but I think you get the idea...
[ 29. August 2002, 18:43: Message edited by: Lonkero ]
_________________________
!download KiXnet
|
|
Top
|
|
|
|
Moderator: Glenn Barnas, NTDOC, Arend_, Jochen, Radimus, Allen, ShaneEP, Ruud van Velsen, Mart
|
0 registered
and 700 anonymous users online.
|
|
|
![[Razz]](images/icons/tongue.gif){kind=icon}
![[Cool]](images/icons/cool.gif){kind=icon}
Just found about this KSMS today! It looks as if it's precisely what I've been looking for!! I'll sure be putting it to a BIG test, and should I decide to use it, I'll let you know later how does it behave in a 300 PCs over 12 locations kind of setup.
