The general idea is that you have a client/server type of setup..
The user (without Admin rights) runs the login script. The script CHECKS if a program is missing, or some setting isn't present. It then writes a REQUEST to a central location - \\server\AdminTasks\@WKSTA.INI (for example) - that lists the things that need to be done.
A kix script runs as a service via SrvAny, with a domain account that has local admin access - not a DOMAIN ADMIN account!! This process monitors the folder every few seconds, finds the new file, and moves it to a Processed subfolder. It then kicks off a child task (run kix32 AdminTask.kix - for example). This child task has the proper rights to access the remote workstation, update its registry, copy files, etc. based on the requests in the config file. For more complex tasks, it can create a scheduled event on the remote PC (see tclib UDF library) and then issue an exec command. The remote task runs instantly with whatever local or domain credentials you want. If all of the remote tasks write logs to a central location, you can even collect that back to the central server.
Basically - you write a small script that says
Read this registry location, if the value is missing or less than X, write a code to the INI file.
The receiving script sees the code(s) in the INI file, knows which computer made the request, and performs the necessary tasks to resolve the issue - updating files or registry settings, or triggering an instllation.
We have a product that forms the framework of this process and it has been used to perform admin tasks on workstations in an environment of about 2500 users - nobody has local admin rights to their PC. Since it's a "framework", it provides the API calls to create and manage the requests, but you still need to write code to do the detection, make the calls, and then respond to the requests. This RunAdmin utility basically handles the request/response processing.
Glenn
_________________________
Actually I
am a Rocket Scientist!
