Sealeopard
(KiX Master)
2001-10-03 04:41 PM
HOW-TO: Running scripts with ADMIN powers

Everybody:

Every couple of days I'm reading postings about how to use SU.EXE to run something under an administrative account. A lot of people have difficulties getting it to work since it requires a service to be installed on the computer running SU. Additionally, providing the account name and password is not entirely secure.

I have been working on a client-server-based maintenance script for the last couple of weeks that runs under Kixtart 4.0.

I opted not to use the SUSS service and SU due to security concerns. Alternatively, one can set the scheduler service in Windows NT to run under an administrative account instead of the SYSTEM account. This is also not a practical solution if you're maintaining tens or hundreds of computers.
Fortunately, all our computers are running at least Microsoft Internet Explorer 5. IE 5.x+ comes with a component ('offline synchronization') that replaces the scheduler service with the 'Task Scheduler'. The task scheduler runs under the SYSTEM account which cannot be changed. The advantage of the task scheduler over the scheduler service is that the task scheduler allows to run scheduled commands under arbitrary user accounts.

What does that mean?
It means that I can scheduler a command to run every night under the user account COMPUTERNAME\Administrator. This command runs with all the rights of the assigned user regardless of whether another user is logged in or not. Additionally, the task scheduler prevents users to see what other users have scheduled. Thus, I can schedule administrative scripts without ordinary users knowing that there is something running in the background.

How do I do it?
The easiest solution is to use the task scheduler wizard to set up a task for a specific user. This task is saved in a special task scheduler folder under %SYSTEMROOT% and can be copied for one computer to another.
Another solution is to download the Task Scheduler Command line Interface which is part of the Windows 2000 Resource Kit Supplement 3 (ftp://ftp.microsoft.com/reskit/win2000/jt.zip).

This CLI is the holy grail to the task scheduler and explaining every option is beyond the scope of this HOW-TO. Thus I will only hightlight features:
- remote scheduling of tasks
- load and save predefined tasks
- execute tasks once, daily, weekly, on-idle, at-startup, at-logon (useful features for laptops)
- delete tasks
- triggers

I really recommend downloading the CLI and reading the documentation, it comes very close to all the powerful *NIX schedulers.

Following is an example of how to use the CLI:
code:
$schedulercmd = 'jt.exe'
$schedulercmd = $schedulercmd + ' /CTJ StartDate=TODAY'
$schedulercmd = $schedulercmd + ' StartTime=NOW'
$schedulercmd = $schedulercmd + ' HasEndDate=0'
$schedulercmd = $schedulercmd + ' KillAtDuration=0'
$schedulercmd = $schedulercmd + ' Disabled=0'
$schedulercmd = $schedulercmd + ' Type=ONCE'
$schedulercmd = $schedulercmd + ' /SC DOMAIN\adminuser adminuserpassword'
$schedulercmd = $schedulercmd + ' /SJ ApplicationName="maintenance_server.bat"'
$schedulercmd = $schedulercmd + ' Parameters=""'
$schedulercmd = $schedulercmd + ' WorkingDirectory="%SYSTEMROOT%"'
$schedulercmd = $schedulercmd + ' Comment="Kixtart Maintenance Server Script"'
$schedulercmd = $schedulercmd + ' Creator="Administrator"'
$schedulercmd = $schedulercmd + ' Priority=Normal'
$schedulercmd = $schedulercmd + ' MaxRunTime=21600000'
$schedulercmd = $schedulercmd + ' DontStartIfOnBatteries=0'
$schedulercmd = $schedulercmd + ' KillIfGoingOnBatteries=0'
$schedulercmd = $schedulercmd + ' RunOnlyIfLoggedOn=0'
$schedulercmd = $schedulercmd + ' SystemRequired=0'
$schedulercmd = $schedulercmd + ' DeleteWhenDone=1'
$schedulercmd = $schedulercmd + ' Suspend=0'
$schedulercmd = $schedulercmd + ' StartOnlyIfIdle=0'
$schedulercmd = $schedulercmd + ' KillOnIdleEnd=0'
$schedulercmd = $schedulercmd + ' RestartOnIdleResume=0'
$schedulercmd = $schedulercmd + ' Hidden=0'
$schedulercmd = $schedulercmd + ' TaskFlags=0'
$schedulercmd = $schedulercmd + ' /SM \\'+@WKSTA
$schedulercmd = $schedulercmd + ' /SAJ maintenance_server_once.job'
$schedulercmd = $schedulercmd + ' /SAC maintenance_server_once.job'
$schedulercmd = $schedulercmd + ' /RJ'

shell $schedulercmd

The batch file I'm calling creates a drive share to the Z: drive and connects to a hidden fileshare on the PDC containing the Kixtart scripts and utilities. Thus, the real stuff is hidden from the user.

How to implement this?
I created an administrative group called KIXTART on my PDC and created a user KIXTARTUSER wich is a domain administrator. Thus, this user has full administrative rights on all client computers and has access to networked resources, something that a local administrator might not have. I'm running a script called MAINTENANCE_SERVER on my PDC which reads an INI file containing a list of Windows NT/2000 computers and the type of scheduler they are using (scheduler, or task scheduler). This INI file is updated throught a login script, thus if somebody logs into a computer, the information gets written into the INI file and tasks can be scheduler the next time the MAINTENANCE_SERVER script runs.
The server script checks whether the computer is accessible through an admin share ADMIN$. If this is not the case the server script sends a magic packet to the specified computer and if the computer has a WOL ethernet adapter, it'll start up. Then the server script waits a couple of minutes until either the computer woke up or no successful wake-up is detected (no access to ADMIN$ after five minutes).
If the computer is accessible the server script sends a task scheduler command via the JT.EXE CLI to the remote computer. The remote computer then executes the scheduled command at the specified time under the KIXTARTUSER administrator context. The maintenance client script does its thing, mainly adjusting registry keys in the HKEY_LOCAL_MACHINE part, installs software updates, and whatever other task requiring admin privileges. I'm also using the Kixtart SHUTDOWN command to reboot computers and use the auto-login to set up e.g. Internet Explorer 5.5 SP2 with a package prepared with the Internet Explorer Administrator Kit 5.5.

I hope this rather long post give you some food-for-thought. The setup I'm using in our production environment consists of a simle login script, the maintenance_server and the maintenance_client scripts. The maintenance scripts are only accessible to administrators, thus there is not chance that users will discover admin passwords since the Task Scheduler does not provide a clear-text display of the account passwords.

Jens

P.S.: I'm willing to sanitize my scripts a little bit and make them publicly accessible if there is interest. The complete package will be about 1 MB uncompressed and will contain the scripts, UDFs, required executables and some configuration files.

[ 02. June 2003, 21:51: Message edited by: sealeopard ]


Les
(KiX Master)
2001-10-03 05:22 PM
Re: HOW-TO: Running scripts with ADMIN powers

Jens,
You got my vote and interest on this topic. I'm all for anything that meets the needs without having to install anything on all the client's PC and that doesn't compromise security!

Looks good. can't wait to see what's "under the hood".

ShawnAdministrator
(KiX Supporter)
2001-10-03 05:33 PM
Re: HOW-TO: Running scripts with ADMIN powers

Yes, I'll second that Les's vote.

At first I was impressed by the idea and concept, then later impressed with your style and presentation ...

Is this kinda like a roll-you-own Tivoli ?

I was pondering the idea that Bryce threw out last night (custom SU service, taking requests only from authenticated logon script context) and how this would mesh with that idea. But really, your talking about different approach here ... I think both ideas have merit ...

-Shawn

Alex.H
(Seasoned Scripter)
2001-10-03 06:01 PM
Re: HOW-TO: Running scripts with ADMIN powers

Yeah, you hit the holy Grail !!
You get my vote too, and after digging into IE 4 SP2, it seems to have the same task scheduler, so maybe no need for IE 5.x
So long with a such possibility under our eyes, thanks Sealeopard to open them


Bryce
(KiX Supporter)
2001-10-03 06:40 PM
Re: HOW-TO: Running scripts with ADMIN powers

MS finaly released a command line interface for their new task scheduler sevice!

Yea the client/server model really is the best way to go.

Just a few keypoints, be sure to validate that the request are being generated from the logon script, this is easy to do using see this thread "finding a programs parrent process"


If i can help in any way, let me know!

Bryce

ShawnAdministrator
(KiX Supporter)
2001-10-03 07:18 PM
Re: HOW-TO: Running scripts with ADMIN powers

Bryce,

So what is the logon script's parent process (winlogo(i)n?) ... and could one "spoof" that ?

-Shawn

Bryce
(KiX Supporter)
2001-10-03 07:41 PM
Re: HOW-TO: Running scripts with ADMIN powers

yea, the winlogon would be the parent process of a logon script. a user ran script will show up under the shell (explorer, taskmgr, cmd.exe...).

I don't think that a user could spoof this.

Bryce

Sealeopard
(KiX Master)
2001-10-03 10:56 PM
Re: HOW-TO: Running scripts with ADMIN powers

You vultures of the Kixtart BBS. Here's a script to take apart, disect, piece back together and gain universal wisdom ;-)

Download the demo scripts that I talked about in my little how-to at this location: http://people.bu.edu/jenmeyer/kixtart/kixtart_demo.zip (This link will no longer work because the information contained in this ZIP file has been superseeded with the information in the following article: http://81.17.37.55/board/ultimatebb.php?ubb=get_topic;f=2;t=002897)

Please be advised that I do not take any kind of responsibility for lack of sleep resulting from the reading/implementing/disecting/reconfiguring of these scripts.

Enjoy,
Jens

[ 27 March 2002, 14:53: Message edited by: sealeopard ]


ShawnAdministrator
(KiX Supporter)
2001-10-03 11:11 PM
Re: HOW-TO: Running scripts with ADMIN powers

I'm not a vulture ... I'm a Dingo ... A dingo ate your script !!!

Sealeopard
(KiX Master)
2001-10-04 02:30 AM
Re: HOW-TO: Running scripts with ADMIN powers

I hope you had fun digesting it

Jens

NTDOCAdministrator
(KiX Master)
2001-10-04 05:23 AM
Re: HOW-TO: Running scripts with ADMIN powers

Wow Jens, quite a bit to digest.

Looks great from a minor review. Some great ideas for other things in here also. Looks like your almost running your own Policies from within a script.

Thanks for sharing the info and ideas, all I can say is SH*T great stuff. How long have you been working on this script?

Can't wait till a release version of KiXtart 2001 - There is some really cool stuff in the new version. I just can't deploy till it is a release version. But I will try to do some of these ideas in v3.63 code for now.

[ 04 October 2001: Message edited by: NTDOC ]

Sealeopard
(KiX Master)
2001-10-04 05:06 PM
Re: HOW-TO: Running scripts with ADMIN powers

NTDOC:

I originally started some work on it in May because I wasn't satisfied with the Kixtart 3.63 login script that I was using.

It first started out as a login script port to 4.0. Now I'm already using 4.0 RCx for about eight weeks in our production environment, and if you ask me, Kixtart is definitely ready for deployment (I'm not using WMI).

Then I got out of control because of the flexibility that Kixtart UDFs allow. Finally, I found the Task Scheduler command line interface and went crazy over the options presented within.

The main thing I like about my solution is that most of the work has been moved outside the standard login script, making it fast and simple. Since our computers are switched on 24/7 it's very convenient to do the serious maintenance at night.

Finally, I tried to implement most of the stuff in such a way that it does not require changes to the scripts itself. It should be sufficient to change an INI file or e.g. add a link to the LNK directory in order to have that link installed on the client machine.

Jens

tech_guy
(Fresh Scripter)
2001-12-04 05:03 AM
Re: HOW-TO: Running scripts with ADMIN powers

First, I want to suck up. Not only is this Bulletin Board great software, the people on it are great as well!

I don't find jt.exe in my Technet stuff. Is there a *.chm to go with the jt.exe program? The download was only the exe and a license file.

Thanks again to the folks on this list that have helped me.


Mike

Sealeopard
(KiX Master)
2001-12-04 04:13 PM
Re: HOW-TO: Running scripts with ADMIN powers

No documentation whatsoever. I had to do a
code:
JT.EXE /?  >>c:\temp\jt_command.txt 

for each command in order to get a complete list of JT commands. Also, there is virtually no documentation on the Web (especially the Microsoft websites). It's almost as if microsoft doesn't want us to use the command line version. first not including it in the Reosurce Kit but in a supplement, then I had to download it from their FTP server, then I can't find any documentation,...

AAAAHHHHH!!!

Jens

[ 04 December 2001: Message edited by: sealeopard ]

Sealeopard
(KiX Master)
2001-12-04 06:57 PM
Re: HOW-TO: Running scripts with ADMIN powers

You can now find a simple task scheduler UDF at http://kixtart.org/cgi-bin/ultimatebb.cgi?ubb=get_topic&f=12&t=000060

Brian Parris
(Fresh Scripter)
2001-12-05 12:26 AM
Re: HOW-TO: Running scripts with ADMIN powers

MS needs to add the option of having the login script run as administrator, then kixtart could simply process it's commands as the user it's logging in unless you specify a username to run a command as. This method would be very secure as the workstation would get kix32 and the script right from the Domain Controller. While your script will help with alot of things, it will not work with items that need to run as administrator WHILE the user is logging in.

Sealeopard
(KiX Master)
2001-12-05 12:34 AM
Re: HOW-TO: Running scripts with ADMIN powers

Sorry, but I have to diagree. The user login script should be run under the suer context. If the login script needs to perform a certain task under an administrative account, then there are a couple of solutions for that. You could schedule the task via Task Scheduler, or use SU. Personally, I'm using a client-server maintenance script based on Kixtart. If the login script detects that something needs to be done on a certain computer that requires administrative privileges, then it's scheduled for nightly maintenance. This way, I'm currently distributing Office 200x updates, install/update Norton Antivirus, and make all kinds of configuration changes.

A user should never have administrative privileges for anything. There is always a workaround.

Brian Parris
(Fresh Scripter)
2001-12-05 12:48 AM
Re: HOW-TO: Running scripts with ADMIN powers

The user would not have administrative privledges with my suggestion, only the login processor would, and the login processor could allow the login script(not the user) to run certain commands as administrator instead of running them as the user. SU is a huge security risk, by doing that you are giving the user administrative rights, they can simply look at the script and get the administrator pass, duh.

Will Hetrick
(Hey THIS is FUN)
2001-12-05 02:54 PM
Re: HOW-TO: Running scripts with ADMIN powers

I am not sure if this is what you are talking about, but I have been using this kix script from my PDC to install Mcafee using the task scheduler. Take a look.
code:
     break on
? "Please input the Computer name to connect to. "
Gets $remote_pc
if @inwin=2 exit endif

Do

$tempfile = "timestamp.txt"
$source = "c:\source\*.*"

;'disconect j:\ and map j:\ to to remote pc's C$

$drive = "\\" + $remote_pc + "\c$"
use j: /delete
use j: $drive
if @error = 0
beep
? "Connected to Remote computer Successful."
else
? "Cannot connect to the share "
Goto getpc

endif

;'copy source of the program instal to remote C:\instaldir (including instal.bat) -----
;'You can leave the source also on a win95 share, but not on a NT share
;'that's because te remote NT scedule service runs under system acount
;'This acount can not logon to NT shares.
;'At least instal.bat should stand on c:\instaldir
;'Instal.bat (YOUR UNATENDED instal file) should install the program !
;'This script let the remote machine acount run instal.bat instead of the user
;'As users cann't install apps on NT, and users are potential security risks.

if exist("j:\instaldir\*.*")
else
md "j:\instaldir\"
endif
if exist("J:\instaldir\zcheck.txt")
else
? "Copying Files"
copy "$source" "j:\instaldir\"
endif

? "Finished Copying Files"

;' start the schedule service remotely ----------------
;' this part is later because need to give service time to enable itself

$runner = "SC.EXE \\" + $remote_PC + " start Schedule"
run $runner
sleep 10
? "Schedule is started."

;'retrieve remote time by reading remote file creation time stamp
;'That's a importend one of the clevar idea's behind it
;'Because my problem was always time differences between target and remote machines
;'now this works against the remote time
;'The function is a bit complex as remote time could be in different formats
;'And Also because of a bug in IExplorer 5.x need at least to schedule remote over 15 minutes
:gotime
$filetime = @TIME

$MINUUT = Val(substr($filetime,4,2))
$UUR = Val(substr($filetime,1,2))

if $Minuut > 44
$Uur = $Uur + 1
$Minuut = $Minuut - 45
else
$Minuut = $Minuut + 15
endif

? $minuut
? $Uur

$FILETIME = "$UUR:$MINUUT:00"
; $Filetime = "10:45:00"
$Command = "AT \\" + $remote_pc + " "

? $Filetime

shell $command + $FILETIME + " c:\instaldir\setup.exe -s"
; run $command + $FILETIME + " %windir%\zawsys\wkix32.exe %windir%\zawsys\rv-logon.kix"

?
? "Setup is scheduled"
?
sleep 5
;' Remove the temporaly mapped drive from this machine

use j: /delete

; Get another computer name

:getpc

? "Type exit to quit"
? "Please input the Computer name to connect to. "
flushkb
Gets $remote_pc

Until $remote_pc = "exit"

exit


[ 05 December 2001: Message edited by: Will Hetrick ]

Mills
(Lurker)
2002-01-21 04:19 AM
Re: HOW-TO: Running scripts with ADMIN powers

In the example scripts I noticed that the maintenance server scripts are located in a hidden share which may be readable to all users. The log and db directories within that share are written to from the login script.

What keeps a user from reading your maintenance scripts and getting the domain admin account you have there?

Anupam Agarwal
(Fresh Scripter)
2002-11-09 05:44 AM
Re: HOW-TO: Running scripts with ADMIN powers

Hi Jens,
Sorry for reopening this thread all over again.
I read your article in detail and followed it but
ran into a problem. I am sure you have a fix for it. So, here goes...

I took your code and put it in a batch file for
testing. Here is what batch file looked like:
code:
JT.EXE /CTJ StartDate=TODAY StartTime=NOW
HasEndDate=0 KillAtDuration=0 Disabled=0
Type=ONCE /SC domain\domadmin password /SJ
ApplicationName="test.exe" Parameters=""
WorkingDirectory="C:\WINNT" Comment="Test Script"
Creator="Administrator" Priority=Normal
MaxRunTime=21600000 DontStartIfOnBatteries=0
KillIfGoingOnBatteries=0 RunOnlyIfLoggedOn=0
SystemRequired=0 DeleteWhenDone=1 Suspend=0
StartOnlyIfIdle=0 KillOnIdleEnd=0
RestartOnIdleResume=0 Hidden=0 TaskFlags=0 /SAJ
Test.job /SAC Test.job /RJ

The credentials it is using in the JT.EXE command
line are of a Domain Admin account and I am
scheduling the job on the local computer with a
non-privileged account (that is how I am logged
on). It works great the first time and the job
executes and gets deleted when finished. The
problem is that when execute the same batch file
a second time, I get the following error:

code:
[TRACE] Created trigger 0
[TRACE] Setting account information
[TRACE] Setting job's properties
[TRACE] Adding job 'Test.job'
[FAIL ] ITaskScheduler::AddWorkItemn hr=0x80070005

Looking at the c:\winnt\SchedLgU.txt reveals the following problen:

code:
"Test.job" (test.exe) 11/8/2002 10:27:00 PM ** ERROR **
The attempt to retrieve account information for the specified task failed;
therefore, the task did not run. Either an error
occurred, or no account information existed for the task.
The specific error is:
0x8004130f: No account information could
be found in the Task Scheduler security database
for the task indicated.

Doing some research, found the following KB article at Microsoft:
Scheduled Task Does Not Run...

It sounds like even though the job is getting
deleted, the security descriptor is still being
kept in the database against that job name and
deleting ity is breaking it and can never be used
again.

So here I am seeking the advice of the masters of
this trade. Please help!

Thanks!

Anupam Agarwal

[ 09. November 2002, 05:56: Message edited by: Anupam Agarwal ]


Les
(KiX Master)
2002-11-09 05:46 AM
Re: HOW-TO: Running scripts with ADMIN powers

Anupam,
Please edit your last post and break the long lines as it really messes up the entire thread.


Howard Bullock
(KiX Supporter)
2002-11-09 05:56 AM
Re: HOW-TO: Running scripts with ADMIN powers

Long Line Police in action

Anupam Agarwal
(Fresh Scripter)
2002-11-09 05:56 AM
Re: HOW-TO: Running scripts with ADMIN powers

Thanks Les.
I just fixed it.


djek
(Lurker)
2002-11-09 03:51 PM
Re: HOW-TO: Running scripts with ADMIN powers

quote:
The problem is that when execute the same batch file a second time,
I get the following error:

code:
[TRACE] Created trigger 0
[TRACE] Setting account information
[TRACE] Setting job's properties
[TRACE] Adding job 'Test.job'
[FAIL ] ITaskScheduler::AddWorkItemn hr=0x80070005

That's right, as a safety measure it wil not continue.
Comment the return if you don't want this feature.

; delete a potentially existing task
$shellcmd=$jtexe+' /SM \\'+$computer+' /SD +$taskname
shell '%COMSPEC% /e:1024 /c '+$shellcmd
if @ERROR
  $scheduletask=@ERROR
;  return
endif


Anupam Agarwal
(Fresh Scripter)
2002-11-09 04:38 PM
Re: HOW-TO: Running scripts with ADMIN powers

In my original post, I have the flag
code:
 DeleteWhenDone=1 

So the job gets deleted as soon as it is finished running.
If I run the above recommended script to delete the job,
I get an error because the job does not exist. I tried setting the flag
code:
 DeleteWhenDone=0 

and then run the above script to delete the job in which case,
the job gets deleted without errors. In either case,
my original script still fails with same error.

There are couple other interesting things to note:

1. Once I run my batch file with the specified credentials
and successfully schedule the job, run it, and delete it,
I cannot schedule any job with those credentials again
(that is, even if I change the job name). I get the same error.

2. I was able to run my batch file and schedule the job
this morning with the same credentials which was failing last night.
And now I cannot run it again. But I am sure it will start
working in several hours. Which tells me that the local security
database eventially purges the credentials. I don't know
what governs that time out or if I have any control over it.

3. Another piece of information is that when my batch file fails
and I get the error, the job still gets set in the scheduler
but with the logged on user's credentials instead of the credentials
supplied on the command line. And the job never runs either.
It just sits there and does nothing.

Sorry for these long emails but I think I need to explain
as much troubleshooting informatiuon as I already have.

Thanks you again for helping me out with this.

Anupam


Sealeopard
(KiX Master)
2002-11-10 03:18 AM
Re: HOW-TO: Running scripts with ADMIN powers

I've never seen this behavior, however I've never scheduled anything other than once-a-day schedules.

Nevertheless, it sounds more like a problem with either the Task Scheduler or the JT.EXE CLI. In any case, there's nothing I can do about.

I'll play around with JT.EXe a little bit and see what I can find.

Do you have the same behavior if you manually schedule tasks with the Task Scheduler wizard?

P.S.: It would have been better to create a new thread with this specific problem and reference this thread as outlined in ABC's of KiXtart board etiquette and message to new forum users

[ 10. November 2002, 03:20: Message edited by: sealeopard ]


Anupam Agarwal
(Fresh Scripter)
2002-11-10 09:34 AM
Re: HOW-TO: Running scripts with ADMIN powers

Jens,

Looks like the problem is with the scheduler service itself.
Scheduling the job manually using the wizard generates the exact same error.
However, if you are logged on with admin rights, everything works okay.

This tells me that the credentials are stored in tha local secutiry database.
The database purges old information after some time by itself (don't know how long).
Admin rights are needed to overwrite information in this database.

I am not sure where we go from here. The only thing I can think of is
to figure out a way to change the database refresh interval if possible
or delete the credentials from it when the job is deleted.

I guess I am expecting magic or miracle here. [Big Grin] [Big Grin]

Thanks,
Anupam


Sealeopard
(KiX Master)
2002-11-10 03:58 PM
Re: HOW-TO: Running scripts with ADMIN powers

Question: Did your problems start around the same time your computer switch 'Daylight Savings Time'? Then it is a documented problem with the Task Scheduler.

See also Scheduled Task Does Not Run After You Push the Task to Another Computer about a comment regarding the protected storage database.


Anupam Agarwal
(Fresh Scripter)
2002-11-10 05:31 PM
Re: HOW-TO: Running scripts with ADMIN powers

I hve seen that article. It was a link in the article I posted in my original post. Where is the article about the daylight savings problem? In my earlier posts, when I mentioned local security database, I was actually referring to the protected storage database. I was expecting that when the job is deleted, the password should also get deleted from the protected storage database. As I said earlier, the password does enevtually get dropped from it but I don't know if we have any control over the timing of it from the registry etc.

Thanks,
Anupam


Sealeopard
(KiX Master)
2002-11-10 06:10 PM
Re: HOW-TO: Running scripts with ADMIN powers

There are discussions in a couple of newsgroups about this issue, however no solutions. Use Google to search the newsgroups for your specific error code.

Anupam Agarwal
(Fresh Scripter)
2002-11-10 06:20 PM
Re: HOW-TO: Running scripts with ADMIN powers

I found the article about Daylight Savings Time issue with the Task Scheduler unless you were referring to a different one. According to this article, the problem only happens during the one hour of fall back and one hour of spring forward. So, I am thinking that this is probably not what is causing my issue.

Les
(KiX Master)
2002-11-10 07:13 PM
Re: HOW-TO: Running scripts with ADMIN powers

Jens,
If you want to prune off Anupam's portion from this thread then just ask Howard to move the entire thread to one you are moderator of, making sure he doesn't delete the original. You will then have two copies. On your copy, delete everything up to Anupam's first post, rename it, and move it back.

Howard could then delete Anupam's portion from the original and you'd have effectively split it into two separate threads.


Sealeopard
(KiX Master)
2002-11-10 07:20 PM
Re: HOW-TO: Running scripts with ADMIN powers

Les:

Sounds good. Just be aware that I'll be offline from about this post until around 6pm. I will then remove these last two posts in order to clean up the thread.


Anupam Agarwal
(Fresh Scripter)
2002-11-11 07:17 PM
Re: HOW-TO: Running scripts with ADMIN powers

Guys,
I am really sorry about messing up the old thread and making you guys go through all this work. I do want to put another update here.

I ran a test batch file that scheduled and deleted the job at one minute interval with the same credentials and recorded the time and status in a log file. It turns out that there are exactly 12 hours between successes which means that once a job is scheduled and deleted, it cannot be rescheduled with the same credentials for the next 12 hours.

Thanks,
Anupam


Sealeopard
(KiX Master)
2002-11-11 07:25 PM
Re: HOW-TO: Running scripts with ADMIN powers

Then why not set up a continous task that e.g. repeats itself every 4 hours or whatever else the interval is?

Les
(KiX Master)
2002-11-11 07:28 PM
Re: HOW-TO: Running scripts with ADMIN powers

If you setup one 'generic' task that runs a KiX script, you need only change the acompanying script. The task itself can remain.

Anupam Agarwal
(Fresh Scripter)
2002-11-11 09:31 PM
Re: HOW-TO: Running scripts with ADMIN powers

Both of those are good ideas but then I don't have as much control over when I want things to happen. For example, I wanted to add this in the logon script such that if there is a missing element on the workstation, it would fire off a job and make the required change which requires admin permissions. A set interval will only happen whenever the interval expires. I could live with it but not an elegant solution.

I wil continue my research on this and keep this (or the new thread if you decide to create one) posted for your information.

Thanks again for all the valuable help.

Anupam


Sealeopard
(KiX Master)
2002-11-12 03:03 PM
Re: HOW-TO: Running scripts with ADMIN powers

Take a look at KiXtart Systems Management Server (Part III, The Client) [a.k.a The Complete Package]

Les
(KiX Master)
2002-11-12 03:08 PM
Re: HOW-TO: Running scripts with ADMIN powers

Anupam,
What you might want to consider is to move the workload from the logon script to the scheduled one.

Why burden the users with it during logon? That is when they are the most annoyed. Also there's the issue of users that never logoff. You can't catch them until they logon again.


Noel Latsha
(Lurker)
2003-09-05 08:32 AM
Re: HOW-TO: Running scripts with ADMIN powers

I have two cents....

I have read all the info on getting the script to run with admin powers and what not. I haven't tried the scheduler, I will be trying that soon. But a little while ago I found a small scripting utility called AutoIt that will allow me to use the Win2K "run as" command. I use the login script to call the AutoIt script which in turn calls the kix script that needs admin privs, HKLM hacks and what not. It ships with a compiler so I just package it into an exe and put the exe on the domain controller. The compiler has a password feature so you can have some added protection.

Just a thought....