No - what I presented above is an admin script running on an admin's workstation. It enumerates a list of remote computers, placing and immediately executing a scheduled task. This allows you to run the deploymnet process with your admin credentials (allowing access to the remote computer) and perform a task on the remote system using specific credentials instead of your admin credentials.
In some sites, my admin account might allow me to access all workstations, but not write to certain areas. Other accounts have write access but are limited to "Log on as a batch job" but not "Access this computer from the network" rights. The example above works within those limitations. (I've worked for the Federal Reserve Bank and currently at a large international financial organization and some of the security settings can make your head spin!)
What I also mentioned is a tool I created and discussed here in the past. The user's login script performs a detection task - is this reg value set to "x" or is application XYZ installed? Both updates require admin access to modify or install, but only User access to determine the setting. If the update is necessary, the user writes a file to a "write-only" folder on a network share. A Kix-based service monitors that folder. When it detects a file, it looks inside to determine the task and any arguments that it represents. It then, using a task lookup table, can perform the task on the remote workstation in near real-time. It pushes up a small bat file, then creates the task using appropriate credentials to execute the local BAT file, and immediately executes the task. No "schedule" (trigger) is defined in the task event. In this case, simple things like reg or file updates can be performed and completed within 10-15 seconds of the login process starting. Of course, this depends on the cycle time of the monitoring service - I usually set that to 5 seconds.
Glenn
_________________________
Actually I
am a Rocket Scientist!
