Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have Googled, and not yet found an answer.

Scenario: One of my GPOs have a Startup Script that takes a long time to finish. For some reasons, we have to run the scripts synchronously. Naturally, this causes slow startup time (sometimes as long as 15 minutes!) before the Logon screen appears.

After profiling and analyzing the perpetrator script, I conclusively determined that the step where it's taking a long time to finish will not affect the result of the succesive GPOs. In other words, that particular step (and all steps afterwards) can run in the background.

My Question: Is it possible for the Startup Script to just 'trigger' another script/program that will run to completion even when the Startup Script exits? That is, the "child processes" of the Startup Script continues to live even when the Startup Script's process ends?

Additional Info: The Domain Controllers are 2008 and 2008 R2's. The workstations are Windows XP.

share|improve this question
    
What kind of task are you running that will take 15 minutes that won't interfere with anything else. –  Zoredache Jun 20 '12 at 6:56
    
@Zoredache it's an antivirus, a locally made one that's very effective for local viruses. Yes, while scanning, of course users will be impacted. But I'm sure they will prefer working slowly rather than twiddling their thumbs waiting for the login screen. –  pepoluan Jun 24 '12 at 10:03
add comment

4 Answers

up vote 4 down vote accepted

Sorry for not answering (my own question) sooner.

So, this is how I finally settled my problem.

On Startup, the Startup Script creates an at job. Since Startup Scripts run as SYSTEM, the at job will similarly run under SYSTEM privileges. The at job is configured to run 2 minutes after creation.

The command in the at job is the actual workload script. which fires up whatever payload it should be doing. Since it starts as a scheduled job, it doesn't care who's logged in at the time.

Voila! Mission accomplished :-)

share|improve this answer
add comment

Faced with a similar situation at a previous job I found the best solution was to create a wrapper program for the script to be executed. The logon script started that program, which in turn ran the real script in a low priority mode.

That way users were unaffected because the script's speed of execution would be automatically adjusted by the OS depending on what else was running on the machine. Creating such a wrapper is of course outside the scope of this site.

share|improve this answer
    
Will the program survive the termination of the calling script? I tried calling a script from another script, and the called script was killed when the calling script ends. –  pepoluan Jun 22 '12 at 15:01
    
@pepoluan, yes it does. –  John Gardeniers Jun 24 '12 at 1:19
    
interesting... I guess my failure was due to how cscript (the Windows Scripting host) work. Thanks for sharing! –  pepoluan Jun 24 '12 at 9:59
    
Especially the tip about "Low Priority", that will surely be useful! –  pepoluan Jun 24 '12 at 10:11
add comment

Just for the sake of options, you can also try placing your script in a GPO at this point:

Computer Configuration\Policies\Administrative Templates\System\Logon\Run these programs at user logon

or

User Configuration\Policies\Administrative Templates\System\Logon\Run these programs at user logon

Specifies additional programs or documents that Windows starts automatically when a user logs on to the system.

To specify values for this setting, click Show. In the Show Contents dialog box in the Value column, type the name of the executable program (.exe) file or document file. To specify another name, press ENTER, and type the name. Unless the file is located in the %Systemroot% directory, you must specify the fully qualified path to the file.

Note: This setting appears in the Computer Configuration and User Configuration folders. If both settings are configured, the system starts the programs specified in the Computer Configuration setting just before it starts the programs specified in the User Configuration setting.

Also, see the "Do not process the legacy run list" and the "Do not process the run once list" settings.

share|improve this answer
    
It must be a Startup script, not a Logon script, since it must run using SYSTEM privileges. –  pepoluan Jun 22 '12 at 15:00
add comment

Assuming startup script is a batch file:

The CALL statement was introduced in MS-DOS 3.3

It is used to call other batch files within a batch file, without aborting the execution of the calling batch file, and using the same environment for both batch files.

http://www.robvanderwoude.com/call.php

share|improve this answer
    
Will CALL survive its CALL-ing script? I just tried using VBScript Wsh.Run(...,...,False) method, and the second script was terminated when the calling script ends. –  pepoluan Jun 22 '12 at 15:01
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.