I was planning on using waitfor.exe as a go between the client side script and the logon_verification script (both scripts run client side), basicly use waitfor as a second check to make sure that the install request is a valid request called via the logon script. And not a second kix script that a "smart" user has launched to try to trick the system.... (maby this is over kill actual testing will find this out)

RCMD would have to be pushed down to the client from the server side script, but this is easy. copy the exe to the clients %systemroot%\system32 folder, use xnet to install the service under the correct security rights. This is where a choice must be made, run rcmd under the default system account, or run it under a domain account (i am really leaning to the domain account at this time).

If RCMD is ran under the system account, you will be limited to running programs from local resources only, access to network resources would not be allowed. ON the other hand.... running RCMD under a domain account has it's own "challenges". The domain account used will have to be placed in the local admins group, and will need the "LogonAsService" right granted to it on the client PC. Both of these changes could be made from the server side script via ASDI... i think (if not ASDI i know for a fact that it can be done using 3rd party tools) But getting ASDI onto a NT computer... from remote... might be a little tricky. This might require a 2 stage RCMD/ASDI install for NT computers. Install RCMD to run off of service account, install ADSI, modify RCMD using ADSI, to use domain account... All of this would be first time client initialization only....

As you can see i am still putting all of the pieces together in my head... But with the security part licked using tlist.exe... i think that this just might work.

Bryce