LAUNCHER 0.9h (beta)
CONTENT:
1. Introduction
2. How does it work?
3. Installation
4. Registry entries
5. Messages during
operation
6. System requirements
7. LauncherSetup program
8. Uninstallation
9. Notes
10. Bugs
11. History
12. Future
13. Contacts (with some details about the
author)
For users who have used version 0.9!
There are a number of changes in the registry and execution of the program!
Windows95 is not supported since it requires a different GinaDll as
provided in this archive!
PLEASE READ THE HISTORY FOR CHANGES SO YOU CAN CHANGE YOUR SETUP!
1. Introduction:
A user of NT is able to interrupt the LOGIN (.bat,.cmd) script which is
executed during login using the simple "CTRL-BREAK" key sequence. An administrator
has no way to stop the user doing so. (Except maybe moving the window to
some strange location but then there are no visible messages displayed!)
Launcher.exe simply executes this script and watches what the user does:
-
If the user does not interrupt the script, nothing happens.
-
If the user interrupts the login script s/he is logged out and the event
is logged to the machine specified in the registry.
-
If the user interrupts the login script and decides to press "NO" on batch
file termination s/he is either logged out or warned depending on a registry
entry and the event is logged to the machine specified in the registry.
Launcher works with:
-
Perl scripts
-
CMD and BAT files
-
KiXtart scripts
If you use PerlScripts and KiXtart scripts make sure you extend you PATHEXT
and ASSOCIATIONS otherwise
the scripts of perl and kixtart are not executed! You can still do
that using a CMD file specified in the
UserScript option and then start the perl script there using: d:\perl\bin\perl
\\PDC\NETLOGON\PerlScript.pl!
-
You can set PATHEXT in your AUTOEXEC.BAT file (requires enabling of the
autoexec.bat parsing).
Simply set eg for perl: set PATHEXT=.PL;.COM;.EXE;.BAT;.CMD!
-
You can set your associations using either ther utils provided by NT or
by the NTRESKIT!
I have tested this program on a NT network and it works for me. (I
have no Windows95/98 clients)
The program is designed and compiled on Microsofts Visual C++ 5.0 professional
edition with some of the latest patches installed.
Back to the top.
2. How does it work?
Simply place Launcher into the NETLOGON directory of your PDC, include
Launcher into the USER MANAGER PROFILE of EACH user into the "Logon Script
Name" and set the registry entries of Laucnher to point to the correct
SCRIPT and CMD PROC and let the user log in.
I suggest you use a test user first and see what happening!
Before you log in you must execute LauncherSetup once (or use the provided
REG files for Regedit or REGINI) to setup the registry entries. Once you
have done that and all the entries are set you can log in!
Upon login the user first sees the window of "Launcher.exe" which fills
out the entire desktop. It has NO SYSTEM menu nor other buttons and does
not respond to *ANY* keys or mouse events.
Launcher then disables the use of the Taskmanager and Ctrl-Alt-Del (SAS)
so the user cant bypass the script and the launcher itself (cause it needs
to run in the user context!).
-
If the taskmanager was disabled before it will stay disabled.
-
If the taskmanager was NOT disabled before the flag ill be reset to its
original state and users are able to use TaskManager afterwards.
Launcher then checks whether the user logging into the workstation has
the name set in "AllowedUsers" (see explanation below); if
the user is not found s/he is logged off (if this list is empty no
check is made by Launcher). This does not interfere with the list specified
in the USER MANAGER, which only allows you to log into certain workstation
and if you have many you havent got enough space. Using the "allowed Users"
entry you can allow only a few people to log into a workstation, eg my
SystemAdmin workstation (not the server) allows only 2 people to log on!
It just simply enables an admin to let only a limited number of poeple
log into a workstation but they can log into any other workstation (if
allowed in UserManager).
Launcher then starts the script using the command processor specified.
Launcher then observes whether the user interrupts the script.
If the user interrupted the script Launcher will decide what happens
next (Registry entries):
-
The user will be logged out
-
The user is warned not to do it again
-
An event is logged to a machine specified
Launcher has one command line parameter called "DebugOnly":
-
If specified:The logoff sequence is disabled.
LAUNCHER runs as normal but DOES NOT execute the logoff sequence.
Some messages are displayed instead so you can observe a few parameters..
This is used to set it all up and (as the parameter says) have a debug
option.
-
If NOT specified or incorecct parameter given: Launcher runs as normal.
See under System Requirements and
Registry Entries for the required setup.
Back to the top.
3. Installation:
Content of the archive for the LAUNCHER part of the programs:
-
Launcher.exe (in the launcher dir)
-
usercommandlauncher.reg for REGEDIT or usercommandlauncher.regini for the
REGINI util (part of NT resource kit)
-
LauncherSetup.exe (see: Launcher Setup
)
-
Launcher.HTML (this file)
-
Script files as test command files :
- test.cmd (example cmd file)
- test.pl (example perl script called by the
above cmd file!)
The file Launcher.exe *MUST* be located in the PDC\NETLOGON directory.
In the field "Logon Script Name" in UserManager include the name "Launcher.exe"
to start LAUNCHER instead of a user script. Do this for each user you want
Launcher to be active.
At startup Launcher scans the registry entries to find its setup options
and calls the specified script with the other parameters.
To set up the registry entries (which Launcher reads when working)
you have three options:
-
Use the provided LauncherSetup (See below in section
6)
-
Use the provided USERCOMMANDLAUNCHER.REG file so you can load them into
the registry via RegEdit.
-
Use the provided USERCOMMANDLAUNCHER.REGINI so you can load them via the
NT Resource Kit util REGINI.
The keys/values for Launcher can be found at
"HKEY_LOCAL_MACHINE\SOFTWARE\UserCommandLauncher".
Change the settings to suit your needs as explained below.
You can first try using the provided "test.cmd" and "test.pl" files
(inluded in the script subdirectory of this archive) and using the "DebugOnly"
command line switch. This will display messages only and does not log you
out and will display the startup options as well.
Start the LauncherSetup.exe program
which will make all the nesseccary keys in the registry with default settings.
You should then change the default values to suit your needs. See under
System Requirements and Registry
Entries for further setup requirements.
For the setup of a large number of machine I suggest to use the following
command to make it easy:
for /f "skip=3 eol=T" %i in ('net view') do regini
-m \\%i usercommandlauncher.regini
which would find all the machines on the network and "regini" would
set the registry entries on all machines found to the registry values found
in the file "usercommandlauncher.regini". I use this command quite often.
Running Setup
Use the "Setup.exe" in the archives "setup" subdirectory and follow
the instructions during the setup process.
During the process you will be asked:
-
which type of install you want; either "typical" or "custom".
(in case of the "custom" option you can select which parts to install)
-
where you want the files to be copied to (%systemroot%\Program Files\LauncherGina
is the default)
-
whether you want to start copying
Setup.exe then copies the files, creates the folders, makes the shortcuts
and creates the registry entries for you!
However, as it is impossible to find out during setup
-
where your "NETLOGON" directory resides
-
the name of your PDC
-
the name of your users
you need to change the Launcher Registry entries to suit your needs. Use
the provided "LuancherSetup" to do so and then use the Usermanager to enter
the name of Launcher instead of the user script.
You can read about the options you have using Setup.
Back to the top.
4. Registry entries:
NOTE:
If you bugger things up you can ALWAYS connect to the machine
with problems (Using regedt32) and change the REGISTRY settings on that
machine from another machine. If something goes wrong simply disable LAUNCHER
(in the settings for a user in USERMANAGER) until you found the problem.
The following registry entries are required for operation. (Please see
the included Launcher.reg(ini)!).
The key for the program can be found at:
HKEY_LOCAL_MACHINE\SOFTWARE\UserCommandLauncher
It has two subkeys:
-
SYSTEM: The system key is used by the Launcher program to find its
settings.
It should have security settings: read everyone, admins and system
full control!
-
USER: The user key is used by the Launcher program to set the UserScriptFinished
value once it is finished.
It should have security settings QUERY/SET for everyone since Launcher
runs in context of the user.
If you use REGINI from the NTResKit the security settings are provided
in the files for REGINI (regini extension).
The values within the keys are (examples are shown):
-
"AllowedUsers"=""
This is a string of users separarated by spaces which are allowed to
log into the workstation, no other person will be allowed to log on! If
the list is empty all users are allowed to log into the workstation. If
name(s) found ONLY user(s) found in the list are allowed to log in!
-
"CommandProcessor"="d:\\winnt\\system32\\cmd.exe"
This is the command processor executing the script. I have used this
to give people the option of using 4NT.
-
"CommandProcessorFlags"="/c"
Normally this should be set to "/c" which means that the process of
the command processor is stopped once the script (or whatever is executed)
is finished. Used for debugging if you set it to "/k" which means that
the window is not closed after the processor finishes. You can, of course,
include other flags as well.
-
"CommandFile"="e:\\DevStudio\\MyProjects\\Launcher\\test.cmd"
This is the name of the USER LOGIN SCRIPT. During testing I used the
given file so I could change some of the parameters passed back and to
the command file. In normal cases this can be *JUST* the name of the file,
eg "user.cmd"
-
"EventLogServer"=""
This is the UDC name of the server where the events should be logged!
If this is "" then the events will be logged LOCALLY!
-
"EventLog"="1"
If set to "1" it will log the events to the "EventLogServer".
If set to "0" it will *NOT* log events to the "EventLogServer".
-
"LogoffInBothCases"="1"
If set to "1" it will logoff the user in both events:
- user interrupted the script
- user interrupted the script but continued.
If set to "0" it will logoff the user ONLY for the case:
- user interrupted the script This has no influence if JustWarn
is set to "1".
-
"JustWarn"="0"
If set to "1" it will only warn the user.
If set to "0" it will log the user off!.
Make sure to set the following value for *EACH USER*: Find the key
HKEY_CURRENT_USER\Software\Microsoft\Windows
NT\CurrentVersion\Winlogon\
and set the value
"RunLogonScriptSync" (DWORD) = 1
or the desktop is loaded while Launcher is executing!
You can use the RegistryEditor using the -s switch at logon time, see
http://www.jsiinc.com for further info how to do this!
Back to the top.
5. Messages during operation:
During an error Launcher displays both:
-
the system returned error message
-
and error produces by Launcher
When the program starts it checks (and sets iff required) the TASK MANAGER
setting.
If it cannot set this key the user is logged off (except in debug mode).
Then the program checks for the "UserCommandLauncher" key.
If this key is not available you see a message about the missing key
and the user is logged off (except in debug mode).
Then it reads in this order the following values:
-
"AllowedUsers"
-
"CommandProcessor"
-
"CommandProcessorFlags"
-
"CommandFile"
-
"LogoffProgram"
-
"LogoffInBothCases"
-
"EventLogServer"
-
"JustWarn"
-
"NotEventLog"
If anyone of these keys are not installed, not readable you see a message
with the key name and whats wrong with reading it
as returned by <NT> and seen by "Launcher". The message is shown
to the user and logged off (except in debug mode).
When the user presses CTRL-BREAK and does NOT continue it is very easy
to determine what happened. If the user continues (especially when a second
cmd file is called) the exit codes get "lost" and its very difficult to
"find" the error code (not so with PERL!!!). So this error (returned from
NT) most of the time is "-1" for
two cases:
- something went wrong with the logon script.
- the user restarted the command file.
That is the reason why there the flag "LogoffInBthCases" was
included.
If set to "0" it does not log off when something went wrong
with
the script....
Back to the top.
6.System requirements
The following setup is required for Launcher 0.9h to work:
-
You need the GinaDll with the same version number (packed in the zip archive
as well)
-
Windows NT 4.0 (with any of the fixpaks)
I havent tried it on versions less then 4.0 as I do not have a copy.
-
Administrative user rights
Platforms supported:
Back to the top.
7. LauncherSetup:
Upon starting LauncherSetup checks whether the registry entries required
for LAUNCHER are available.
-
If they are available it displays the values in the field boxes
-
If they are not avialable it makes the registry entries and set them to
a default state (some are empty).
You can change the values simply by typing into the field boxes and then
press update to update the values in the registry. Pressing cancel will
close the setup program without updating the values.
Upon startup you see:
-
Remote Machine
If this is left empty the local machine will be used (startup default).
If this field is not blank (including a domain) a remote machine will
be used.
-
Update
If pressed writes the entries of the field into the registry.
-
Cancel
Does not update the registry entries and closes the dialog box.
All the other values are explained in Registry
Entries.
Back to the top.
8. UNINSTALLATION:
You must delete the "LAUNCHER.EXE" entry from the field "Logon Script Name"
in UserManager.
Do this for each user you want Launcher to be active. Then you can
delete the file Launcher.exe from the PDC\NETLOGON directory.
Then you can delete all the values and keys below
HKEY_LOCAL_MACHINE\software\UserCommandLauncher
If you delete these values before you delete the "LAUNCHER.EXE" entry from
the field "Logon Script Name" in UserManager they will reappear if Launcher
is still active for a USER!
If you delete the Launcher file but not the entry from the User Manager
you will still be able to login but no script will
be executed upon login!
For NTReskit Users:
If you have the NTResource Kit you can use the included "RemoveLauncherValues.cmd"
in the registry subdirectory of this archive to remove all the values from
the registry from a local or remote machine.
It uses the NTResourceKit utility "reg.exe"!
-
Make sure you have permissions do delete the keys, ie Administrative rights
for THAT machine!
-
Make sure the file REG.EXE and CHOICE.EXE are in the path specified by
the NTRESKIT environmental variable, these are checked before the util
executes!
-
Specify the COMPUTERNAME of the remote machine as parameter where you want
to delete the values or specify "local" if you want to remove them from
the local machine.
Back to the top.
9. NOTES:
There is NO checking done whether the PARAMETERS in the registry are correct!
Example: I do not check whether "NotEventLog" has a value of
"0" or "1".
So if something is not working check them first.
It is very difficult to find the error code (especially when a second
bat file is called).
This leads most of the time to a return value of "-1" coming from the
OS. Be aware of this!
This is the same error returned if you call a NON existing CMD/BAT
file!
I guess this is a limitation of the CMD processor (and the chaining
of those events!).
I started this program for my OWN use only and hence its a little "unhelpful"
and quick to design for me.
When running it in an every day operation this is not a problem, it
is only a problem when setting up (sometimes).
Once its running on one machine it will work for all machines!
Back to the top.
10. Bugs:
See above for the "-1" problem. I do not know yet whether this is a problem
of my program or whether this is a problem of the "system" command! If
somebody has a hint for me, please tell me! I tried the "LAST ERROR" stuff
and other things to dig down to find the actual error which is returned
from the (secondary) scripts. I just read somewhere to use another way
of calling the scripts and will do that in the next version.
The functionality of the program is not affected, it works very nicely
except that the error value returned from the script is a not quite as
informative as I would like it!
However, I do not know of any other bugs at this point in time and
that is a problem ........ I'd rather know some bugs!
Back to the top.
11. History:
0.0
|
used it for my own company with hardcoded settings |
0.1
|
bugfix as I forgot to pass on some messages. (It hung on occasions
one of my machines). |
0.2 - 0.8
|
Changes to the program
- registry use: away from hardcoded
- added readme file |
0.9
|
First release to "beta" testers.
- On my website: http://senna.eng.monash.edu.au/~jobst/WindowsNT
- It can be found in the FAQ: http://www.jsiinc.com |
0.9a
|
Added commandline parameter "DebugOnly" (see above for explanation)
Added registry entry AllowedUsers (see above for explanation)
Deleted registry key "LogoffProgram" and added internal handled LOGOUT.
Changed the RegistryKey NotEventLog to EventLog for better understanding
to get rid of the "negative" logic.
Added TASKMANAGER DISABLE while Launcher executes to stop people being
able to stop Launcher using the taskmanager! Note: If Taskmanager is disabled
by default, this is NOT changed! |
0.9b - 0.9g
|
internal updates and fixes.
Furthermore it took a while to update this as I my son was born last
year! Lots of nappy changes instead of code changes. |
0.9h
|
Made the program compatible with the new gina version
Added a setup program to make administration easier. (Although I dont
use it, I have my little script files in Perl). |
Back to the top.
12. Future:
In no particular order:
-
check the parameters found in the registry and produce an error message
if a value is found not in a certain range.
-
maybe I shouldnt display this big white window (bitmap maybe?)
-
Fix that "-1" problem!
-
If you think I should check the parameters in the registry give me a good
reason WHY I should do this. I thought that this little program was
written with SysAdmins in mind so I could "forget" some of the coding!
Back to the top.
13. Contacts:
The program was written for two reasons:
- Its pretty anoying the user can interrupt the script.
- I needed to learn the "Developer Studio" environment.
I have been programming for years in different environments including
various flavours of UNIX, OS/2 (Initor is one of my programs there) and
for my PhD (some 30000 lines of code!). I have been a Tutor/Demonstrator
for various languages including ASM, FORTRAN, PASCAL, COBOL, C and C++.
The program is written in C as it would be total overkill to write it in
C++!
I look after the LAN in our company (I own it 50%). We had OS/2 but
due to companies not providing code for Win3.1 anymore I needed to move
to NT. NT certainly has some good features and is better than OS/2, but
note(!) that in 3.5 years of OS/2 (WARP3) I had not ONE day where the system
wasn't working at *ALL* times and the only problem I had every now and
then is that an application send some funny chars to the printer and that
stopped it working (a little reset fixed that!).
Jobst Schmalenbach
Technical Director of Barrett Consulting Group PTY LTD and Part time
PhD student
PO Box 277
782 Glenhuntly Road
Caulfield South, Vic, 3162
Australia
Phone : 61 3 9532 7677
Fax : 61 3 9532 7388
Mobile: 61 41 161 1855
Email : jobst@senna.eng.monash.edu.au (and soon jobst@barrett.com.au)
Back to the top.
Enjoy the "Launcher".
Jobst Schmalenbach
Copyright March 1999