I have written a .cmd file which calls ten different .exe files. I am able to run this .cmd file locally, on my server, and it works fine.

When I use [gpedit.msc] (Group Policy Editor) for "Computer Configuration, Windows Settings" and set my .cmd file as a startup script, it seems to be okay.

When I reboot my server, the startup script is never called. I cannot figure out why. My goal is for this script to execute everytime I start up my server. (not login).

This server I am testing on is not the Domain Controller. I am unsure if that is related to the problem? Help?

p.s. these are EC2 Amazon cloud servers. A pain in my side.


Start with "Resultant Set of Policy" (rsop.msc) and see if the GPO containing your script is being processed. Most often, I find, problems with policy application end up being a discrepancy between the sysadmin's understanding of where to link a GPO and how the list of GPOs that apply to a given user or computer are actually calculated by the OS.

If the GPO is being processed but the script isn't executing I'd check to see that the permissions set on the script allow the computer account of the subject computer to read / execute the script and that the path referenced in the GPO resolves properly on the subject computer.


You're looking in the wrong place in the Resultant Set of Policy tool. "Software Settings" is the place in Group Policy where software can be "force" installed. You're interested in "Computer Settings / Windows Settings / Scripts (Startup/Shutdown)".

I'd be most interested to see if the GPO where you've specified the script is listed on the "General" tab of the "Properties" of the "Computer Settings" node in RSoP. I suspect that you're going to find that the GPO isn't listed there and, as such, isn't being processed.

Where did you link the GPO you created that specifies the Startup Script?

Edit 2:

So, you're seeing your script's path under the "Scripts (Startup/Shutdown)" node in RSoP. You should have an "Last Executed" column there. If there's a date / time listed there then the Group Policy client has attempted to execute your script. If there's no time listed then it hasn't attempted to execute it.

Hopefully you've looked at the Application Event Log and verified that there aren't any errors being logged re: executing the script. If you haven't, look there.

Assuming the script is being executed I'd consider adding a line to leave some kind of "mark" on the computer to positively verify that the script is executing. Something like an echo foo > %TEMP%\foo.txt would give you a file in the system-wide %TEMP% directory (typically "C:\WINDOWS\TEMP") that could tell you, conclusively, if the script is executing. I'm beginning to suspect that your script is executing but that the computer's SYSTEM context isn't able to access the EXE's you're trying to execute for some reason.

  • I ran [rsop.msc]. "Computer Configuration - Windows Settings - Scripts - Startup" and it does exist in RSOP. It is a filepath to my script, which does in fact exist there on the harddrive. I looked at the General tab settings for "Computer Configuration" and you're right, my policy does not exist. To set up my GPO, all I did was run gpedit.msc and added it to the startup folder. Is there anything I am missing to register it? And no errors in Application Event log. Also the RSOP shows "Last Executed" as yesterday at 3:45 PM. – D3vtr0n Mar 15 '11 at 17:38
  • 1
    @Devtron: Okay-- you added it to the local group policy. You didn't really create a GPO, you just edited one that exists on every computer by default (and is applied behind all other GPOs). Since you're seeing the script path in RSoP the script is being set to execute on startup. Based on everything you're saying it should be executing. I'm getting really suspicious that the script is executing but that permissions are preventing the script from doing what you want it to. Remember that the script runs as the computer's SYSTEM context when it does execute. – Evan Anderson Mar 15 '11 at 17:41
  • I believe your hunch is correct. I added the dos command to output text to a file, and the file is now there (when the server starts up). This leads me to believe my relative paths are incorrect. Thanks for helping me on this, you rock! – D3vtr0n Mar 15 '11 at 18:10
  • For this scenario, what would you recommend to use to replace this command? (I have ten of these): start "My title here..." /D "C:\MyFolder\Publish\MyDirectory" "MyExecutable.exe" "..\..\config\virtual.wfc" – D3vtr0n Mar 15 '11 at 18:23
  • 1
    @Devtron: I'd be wary of the relative path on the command-line for "MyExecutable.exe". I'd go for specifying the absolute path if you can get away with it. I'd also specify the absolute path for "MyExecutable.exe", too. – Evan Anderson Mar 15 '11 at 18:35

Since you won't be logged in when the script executes, it won't have the same environment you have when you are logged in. %variables may not work, etc. Make sure all the paths are local full paths, as it won't have access to network resources due to it running under the computer account as Evan mentioned.

If you're only running this on one machine, consider using Scheduled Tasks rather then GPO which has better logging for things like this, and you can run it as a user account of your choosing. You can even push Scheduled Tasks (and the .cmd itself) to computers through GPO's using Group Policy Preferences.

  • Thanks! Do you have an overview or link for "Scheduled Tasks"? – D3vtr0n Mar 15 '11 at 17:30
  • Look for the GUI named the same in the start menu. Just create a new task in the root and the built-in help should be self explanatory. Let us know if it works. – Bret Fisher Mar 15 '11 at 17:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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