#204732 - 2012-04-13 03:29 PM
Re: Execute script for everyone
[Re: Mart]
|
Glenn Barnas
KiX Supporter
   
Registered: 2003-01-28
Posts: 4401
Loc: New Jersey
|
I've found the scheduled task method to be the best for most situations. It's important to note that you DO NOT need to schedule it to run at a specific time. One of the products we deploy to our clients uses the login script to determine if an admin action is required, and then a service running receives the request and pushes out the scheduled event and immediately executes it with the appropriate credentials. all of this is done in Kix, including the system service.
You can do this easily with the tcLib function library...
You will have to have completed the "install" process so your script can locate JT.EXE. Then create a script with the following logic:
Load tcLib.kxf, then call tcInit() to initialize. You can then override
Create a list of systems you want to process. You can query AD if you want all systems to be configured.
Enumerate the list of systems. For each system, create a task EVENT. The event defines the process and security, but not the schedule. Immediately run the event. Here's the code to define and run a remote task using tcLib.; Init the arrays
tcInit()
; Create a task event, defining the APPlication and PaRaMeters
; This should be relative to the local system - either precopy a BAT file
; or point to a UNC-referenced share. DO NOT use drive letters mapped
; by th eusre environment as they will not exist!
; Set DWD to auto-delete the task after it runs
tcDefineTask('APP=C:\temp\test.bat PRM=-t -v DWD=1')
; Set the event credentials
tcDefineTask('USR=Admin PWD=AdminPass')
; Create the event on the remote system.
$ = tcSetEvent($RemoteSystem, 'AdminEvent')
; Execute the remote event
$ = tcExecute($RemoteSystem, 'AdminEvent') So, with just 5 commands, you can define and execute a process on any remote system that you are authorized to access, and run it using any credentials. Note that when you run the script from your workstation, it must be run as an admin user with (NetBIOS) access to each target system.
I've been able to update several thousand systems in a day in this manner. Push a small bat file out that runs under admin credentials. the bat file is 1-2 lines and references a more complex script from a central location. This insures that there's no overhead copying stuff to each PC or dealing with missing dependencies.
Glenn
_________________________
Actually I am a Rocket Scientist!
|
|
Top
|
|
|
|
#204736 - 2012-04-13 07:33 PM
Re: Execute script for everyone
[Re: Lonkero]
|
Glenn Barnas
KiX Supporter
   
Registered: 2003-01-28
Posts: 4401
Loc: New Jersey
|
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!
|
|
Top
|
|
|
|
Moderator: Jochen, Allen, Radimus, Glenn Barnas, ShaneEP, Ruud van Velsen, Arend_, Mart
|
1 registered
(mole)
and 494 anonymous users online.
|
|
|