|
Ok, so if we take Task Scheduler out of
the equation, what would be the recommended path? Custom .net app? Something
that would popup a window with a url. From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe > Interactive doesn't
help in LOCALSYSTEM context for GUI apps, only CMD.EXE can pop in
LOCALSYSTEM context. Not sure where you picked
this up, but it is incorrect. I have been doing this for a loooooong time. Try
this if you have SOON loaded soon 60 /interactive
"C:\PROGRA~1\INTERN~1\iexplore.exe -new http://www.joeware.net" If not, just create the
appropriate AT command. I just did it on an XP
SP2 with all of the latest patches and within a minute I had an IE window up
and running focused on my web site. However, just because it
can be done, isn't a recommendation to do it. In fact, for this particular
task, I would recommend against using the scheduler, it is added complexity
that isn't needed. > I like to as far as
possible, use the tools which come with os itself, so using Perl for this stuff
might be overkill. I like to think of
overkill as when you go overboard to accomplish something simple.
Either in terms of permissions or actions. Every method you list below messes
with changing user context and IMO added complexity in a case where it isn't
necessary. As for tools in the OS
itself, the work done in my other post with the perl script coupled with quiet
could be done in two _vbscript_ files. There is a WMI piece that will allow
you to launch additional processes including hidden processes. It
will just be longer than what I put in that post. For instance the the
string comparison I did for the current to desired date would need to be done a
different way or would probably take considerably more _vbscript_. But the fun
thing is that for such a simple script as that (and actually even much more
complex scripts), you only need two files from the perl distribution, perl.exe
and perl58.dll (for the current dist, older dists may need a different dll).
Both of which could be in the same folder where you have the script and
quiet.exe. I have had very complex share/printer reconnection perl scripts and
software delivery scripts running as logon scripts for thousands of users where
perl is never loaded on the clients, the two binaries are simply in the
netlogon share. I have also had entire server build scripts done this way
that take a server from nothing to fully loaded with all apps and tools in
place. As long as you aren't using modules you have to import you are fine
and it is very rare I use modules for that exact reason. Further, running a batch
file from one machine against others for this would be simple only for a small
number of machines, probably such a small amount that you could just stand up
and yell across the room what people should do. As you start to scale you need
far more error checking, is the machine up? Is the scheduler even running? Did
the job schedule properly? All of those then require either error reporting or
a loop back to hit them again. Plus it would just be plain slow unless you MTed
it which you won't be doing from BAT very soon. All added complexity. joe From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kamlesh Parmar Interactive doesn't help in LOCALSYSTEM context for
GUI apps, only CMD.EXE can pop in LOCALSYSTEM context. I like to as far as possible, use the tools which come
with os itself, so using Perl for this stuff might be overkill. Anyway, for scheduling it on many computers, 1) directly running schtasks.exe against list of
computers, (I suggest this method if count is small) a) create normal domain user account, with complex
password, for running the task. b)create a text file containing all the comps where
you want to schedule the job. say, comps.txt c) put the following text into batch file, and save
the batch file in same directory as comps.txt :: **** Start Copy Here **** @ECHO OFF for /F %%A in (comps.txt) do ( echo Scheduling the task on %%A ... schtasks /S %%A /create /SC WEEKLY /D
MON,TUE,WED,THU,FRI /TN mypopup
/TR "C:\PROGRA~1\INTERN~1\iexplore.exe -new http://www.domain.com" /ST 11:00 /IT /RU runuser /RP runpasswd /F :: **** End Copy Here **** d) Make appropriate changes in the script above, for
taskname(TN), username(RU), password(RP) now from your admin workstation, make sure you are
logged in with user, who has admin rights over all the comps in question. Run the batch file, it will connect to each computer
and schedule the task under specified user context. once, you verify that it is all scheduled, replace the
actual username, password from batch file with dummies, and save it for future
use. 2) If you want to use _vbscript_, coupled with GP
deployment, then u will have to hide the credentials. As others suggested, many ways to do it, make
actual app in VB, or use tools like CPAU from joeware, to encrypt the
credential. (http://www.joeware.net/win/free/tools/cpau.htm) I use AutoIt from (http://www.autoitscript.com/autoit3/index.php)
(damn cool replacement for VB apps for small tasks) If you choose to work with AutoIt, and get stuck, let
me know... -- Kamlesh On 10/8/05, joe <[EMAIL PROTECTED]> wrote:
Oh I just chased back
through this thread... You want to fire up IE, I didn't catch that before, I
didn't look that close at the specific process you wanted fire, just that you
wanted to fire a process. You should still be able to do this with a startup
script with AT as long as you specify interactive, it should pop in the current
interactive session but I would be concerned of the security context it runs in
which would be localsystem. In order to schedule something in the security
context of another ID you will need to be able to specify userid/password which
isn't fun either since someone will probably be able to see it if they are
bright. What you want is
something that opens an IE window in the context of the current user at a
specified time. I am not aware of anything that will do that. You
almost need a special app that can be launched by the user in the logon
script in their security context that will sleep until the specified time and
then fire the app. Here is a point where being an admin with programming skills
is nice though you may be able to do this with a script. Have the script fire
another process that hides itself from the task bar and pops into the screen at
the designated time. I will think
about this. There might be a way to pull this off with a perl script.
From: [EMAIL PROTECTED]
[mailto: [EMAIL PROTECTED]]
On Behalf Of
How would I use schtask
to assign to more than one computer. It seems like that may be our only
option. I can't believe its that
difficult to get a popup of IE on ALL users desktop at a specific time. - From: [EMAIL PROTECTED]
[mailto:
[EMAIL PROTECTED]] On
Behalf Of Kamlesh Parmar This is specific to opening the internet explorer with higher
privileges... (nothing to do with script runing at logon or startup) On 10/7/05, Kamlesh
Parmar <
[EMAIL PROTECTED]> wrote: At.exe will always reqire admin rights, but normal
user account can always schedule task using, Task Scheduler.. So use command line utility schtasks.exe, it should be
present on all XP box, don't know about win2K.. just see the help... schtasks.exe /create /? On 10/6/05, The problem is the at.exe
command can only be run by administrators. How can I allow non-admins to
run at.exe therefore allowing my script to work. From: [EMAIL PROTECTED]
[mailto:
[EMAIL PROTECTED]] On
Behalf Of Tim Vander Kooi What is your OS? Is it a
user specific task or a computer based task? If it is a task scheduled to run
after the user logs on I'm sure it is permissions, or lack there of. Tim Vander Kooi Microsoft Systems
Administrator Explorer Pipeline From: [EMAIL PROTECTED]
[mailto: [EMAIL PROTECTED]]
On Behalf Of I created a GPO for all Domain Users to run a .vbs
script to create a Scheduled Task. It works with Domain Admins, but not
with regular users. How can I fix this? Windows Systems Engineer Southern Wine & Spirits
- BSG 954-602-2469 __________________________________
|
- RE: [ActiveDir] GPO Permissions with .vbs Harding, Devon
- RE: [ActiveDir] GPO Permissions with .vbs joe
- Re: [ActiveDir] GPO Permissions with .vbs Kamlesh Parmar
- RE: [ActiveDir] GPO Permissions with .vbs Steve Rochford
