I am trying to run the following commands on start up for particular computers in a particular OU:
del "file_destination"
REG ADD "registry_key" /v "value" /d "" /f
I created a batch file with the above commands, but I do not know if the batch file can run with the Group Policy shutdown feature.
When I run the .bat file manually, the commands do not complete due to permissions, but if I run the batch file as an administrator it opens and closes automatically with no sign of completion.
I just need to remove the same file and replace the same registry key on multiple computers in my domain; it does not need to be a batch file. Please assist. Thank you!
Thank you #mojo for your consistent assistance.
The Batch script from the OP worked just fine.
I complicated the issue by trying to run the batch myself.
Probably due to security settings I could not get the batch itself to run as intended by right clicking and selecting "Run as Administrator".
But once I copied the file into the domain*\shutdown directory the script ran just fine.
I am trying to develop a simple script that can run a second script as the machine's local administrator. As the first script I am currently trying:
set name=%computername%
runas /noprofile /user:%name%\Administrator "cmd.exe /c %cd%bg2.2.bat"
When I run the script it never seems to run the second script, which is located in the same directory. The second script is only for copying files.
del "C:\Windows\obh_logo.bmp"
copy "%cd%obh_logo.bmp C:\Windows\obh_logo.bmp"
When the first script runs I am prompted for the admin password as expected and once I enter it, a second command prompt seems to flicker on the screen then vanishes. It never appears to run the second script. What seems to be the reason for this not working?
%cd%will probably not point where you think it does, (just tested it, of course the variable gets replaced before the command gets called and does actually point to the first scripts dir, but the problem still persists in the second script)
the runaschanges the working directory for the cmd.exe instance you are starting, probably to C:\Windows\system32.
replace it with %~dp0, which yields the drive and path of the current batch file.
But! Your script will not run the second file elevated, just under the Administrator account, which is not the same. Manual confirmation is always necessary, see here for possible ways to request elevation from within your script.
I now assume the missing rights is the actual problem, add a pause statement in your second script to watch it, or call it with cmd /k so the console doesn't close.
I am a beginner in VBScript. I googled it & got to know that we can run VBScript from command line by executing below command:
For Example my vbscript name is Converter.vbs & it's present in folder D:\VBS.
I can run it through following methods:
CScript "D:\VBS\Converter.vbs"
OR
WScript "D:\VBS\Converter.vbs"
Now I would like to execute above VBScript without Cscript or Wscript command by simply typing the name of VBscript name i.e. Converter.
I DON'T WANT TO SPECIFY THE FULL PATH OF VBSCRIPT EVERYTIME.
Can anyone please guide me on how to do that ?
I'll break this down in to several distinct parts, as each part can be done individually. (I see the similar answer, but I'm going to give a more detailed explanation here..)
First part, in order to avoid typing "CScript" (or "WScript"), you need to tell Windows how to launch a * .vbs script file. In My Windows 8 (I cannot be sure all these commands work exactly as shown here in older Windows, but the process is the same, even if you have to change the commands slightly), launch a console window (aka "command prompt", or aka [incorrectly] "dos prompt") and type "assoc .vbs". That should result in a response such as:
C:\Windows\System32>assoc .vbs
.vbs=VBSFile
Using that, you then type "ftype VBSFile", which should result in a response of:
C:\Windows\System32>ftype VBSFile
vbsfile="%SystemRoot%\System32\WScript.exe" "%1" %*
-OR-
C:\Windows\System32>ftype VBSFile
vbsfile="%SystemRoot%\System32\CScript.exe" "%1" %*
If these two are already defined as above, your Windows' is already set up to know how to launch a * .vbs file. (BTW, WScript and CScript are the same program, using different names. WScript launches the script as if it were a GUI program, and CScript launches it as if it were a command line program. See other sites and/or documentation for these details and caveats.)
If either of the commands did not respond as above (or similar responses, if the file type reported by assoc and/or the command executed as reported by ftype have different names or locations), you can enter them yourself:
C:\Windows\System32>assoc .vbs=VBSFile
-and/or-
C:\Windows\System32>ftype vbsfile="%SystemRoot%\System32\WScript.exe" "%1" %*
You can also type "help assoc" or "help ftype" for additional information on these commands, which are often handy when you want to automatically run certain programs by simply typing a filename with a specific extension. (Be careful though, as some file extensions are specially set up by Windows or programs you may have installed so they operate correctly. Always check the currently assigned values reported by assoc/ftype and save them in a text file somewhere in case you have to restore them.)
Second part, avoiding typing the file extension when typing the command from the console window.. Understanding how Windows (and the CMD.EXE program) finds commands you type is useful for this (and the next) part. When you type a command, let's use "querty" as an example command, the system will first try to find the command in it's internal list of commands (via settings in the Windows' registry for the system itself, or programmed in in the case of CMD.EXE). Since there is no such command, it will then try to find the command in the current %PATH% environment variable. In older versions of DOS/Windows, CMD.EXE (and/or COMMAND.COM) would automatically add the file extensions ".bat", ".exe", ".com" and possibly ".cmd" to the command name you typed, unless you explicitly typed an extension (such as "querty.bat" to avoid running "querty.exe" by mistake). In more modern Windows, it will try the extensions listed in the %PATHEXT% environment variable. So all you have to do is add .vbs to %PATHEXT%. For example, here's my %PATHEXT%:
C:\Windows\System32>set pathext
PATHEXT=.PLX;.PLW;.PL;.BAT;.CMD;.VBS;.COM;.EXE;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.PY
Notice that the extensions MUST include the ".", are separated by ";", and that .VBS is listed AFTER .CMD, but BEFORE .COM. This means that if the command processor (CMD.EXE) finds more than one match, it'll use the first one listed. That is, if I have query.cmd, querty.vbs and querty.com, it'll use querty.cmd.
Now, if you want to do this all the time without having to keep setting %PATHEXT%, you'll have to modify the system environment. Typing it in a console window only changes it for that console window session. I'll leave this process as an exercise for the reader. :-P
Third part, getting the script to run without always typing the full path. This part, in relation to the second part, has been around since the days of DOS. Simply make sure the file is in one of the directories (folders, for you Windows' folk!) listed in the %PATH% environment variable. My suggestion is to make your own directory to store various files and programs you create or use often from the console window/command prompt (that is, don't worry about doing this for programs you run from the start menu or any other method.. only the console window. Don't mess with programs that are installed by Windows or an automated installer unless you know what you're doing).
Personally, I always create a "C:\sys\bat" directory for batch files, a "C:\sys\bin" directory for * .exe and * .com files (for example, if you download something like "md5sum", a MD5 checksum utility), a "C:\sys\wsh" directory for VBScripts (and JScripts, named "wsh" because both are executed using the "Windows Scripting Host", or "wsh" program), and so on. I then add these to my system %PATH% variable (Control Panel -> Advanced System Settings -> Advanced tab -> Environment Variables button), so Windows can always find them when I type them.
Combining all three parts will result in configuring your Windows system so that anywhere you can type in a command-line command, you can launch your VBScript by just typing it's base file name. You can do the same for just about any file type/extension; As you probably saw in my %PATHEXT% output, my system is set up to run Perl scripts (.PLX;.PLW;.PL) and Python (.PY) scripts as well. (I also put "C:\sys\bat;C:\sys\scripts;C:\sys\wsh;C:\sys\bin" at the front of my %PATH%, and put various batch files, script files, et cetera, in these directories, so Windows can always find them. This is also handy if you want to "override" some commands: Putting the * .bat files first in the path makes the system find them before the * .exe files, for example, and then the * .bat file can launch the actual program by giving the full path to the actual *. exe file. Check out the various sites on "batch file programming" for details and other examples of the power of the command line.. It isn't dead yet!)
One final note: DO check out some of the other sites for various warnings and caveats. This question posed a script named "converter.vbs", which is dangerously close to the command "convert.exe", which is a Windows program to convert your hard drive from a FAT file system to a NTFS file system.. Something that can clobber your hard drive if you make a typing mistake!
On the other hand, using the above techniques you can insulate yourself from such mistakes, too. Using CONVERT.EXE as an example.. Rename it to something like "REAL_CONVERT.EXE", then create a file like "C:\sys\bat\convert.bat" which contains:
#ECHO OFF
ECHO !DANGER! !DANGER! !DANGER! !DANGER, WILL ROBINSON!
ECHO This command will convert your hard drive to NTFS! DO YOU REALLY WANT TO DO THIS?!
ECHO PRESS CONTROL-C TO ABORT, otherwise..
REM "PAUSE" will pause the batch file with the message "Press any key to continue...",
REM and also allow the user to press CONTROL-C which will prompt the user to abort or
REM continue running the batch file.
PAUSE
ECHO Okay, if you're really determined to do this, type this command:
ECHO. %SystemRoot%\SYSTEM32\REAL_CONVERT.EXE
ECHO to run the real CONVERT.EXE program. Have a nice day!
You can also use CHOICE.EXE in modern Windows to make the user type "y" or "n" if they really want to continue, and so on.. Again, the power of batch (and scripting) files!
Here's some links to some good resources on how to use all this power:
http://ss64.com/
http://www.computerhope.com/batch.htm
http://commandwindows.com/batch.htm
http://www.robvanderwoude.com/batchfiles.php
Most of these sites are geared towards batch files, but most of the information in them applies to running any kind of batch (* .bat) file, command (* .cmd) file, and scripting (* .vbs, * .js, * .pl, * .py, and so on) files.
When entering the script's full file spec or its filename on the command line, the shell will use information accessibly by
assoc | grep -i vbs
.vbs=VBSFile
ftype | grep -i vbs
VBSFile=%SystemRoot%\System32\CScript.exe "%1" %*
to decide which program to run for the script. In my case it's cscript.exe, in yours it will be wscript.exe - that explains why your WScript.Echos result in MsgBoxes.
As
cscript /?
Usage: CScript scriptname.extension [option...] [arguments...]
Options:
//B Batch mode: Suppresses script errors and prompts from displaying
//D Enable Active Debugging
//E:engine Use engine for executing script
//H:CScript Changes the default script host to CScript.exe
//H:WScript Changes the default script host to WScript.exe (default)
//I Interactive mode (default, opposite of //B)
//Job:xxxx Execute a WSF job
//Logo Display logo (default)
//Nologo Prevent logo display: No banner will be shown at execution time
//S Save current command line options for this user
//T:nn Time out in seconds: Maximum time a script is permitted to run
//X Execute script in debugger
//U Use Unicode for redirected I/O from the console
shows, you can use //E and //S to permanently switch your default host to cscript.exe.
If you are so lazy that you don't even want to type the extension, make sure that the PATHEXT environment variable
set | grep -i vbs
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.py;.pyw;.tcl;.PSC1
contains .VBS and there is no Converter.cmd (that converts your harddisk into a washing machine) in your path.
Update wrt comment:
If you 'don't want to specify the full path of my vbscript everytime' you may:
put your CONVERTER.VBS in a folder that is included in the PATH environment variable; the shell will then search all pathes - if necessary taking the PATHEXT and the ftype/assoc info into account - for a matching 'executable'.
put a CONVERTER.BAT/.CMD into a path directory that contains a line like cscript p:\ath\to\CONVERTER.VBS
In both cases I would type out the extension to avoid (nasty) surprises.
I am wondering why you cannot put this in a batch file. Example:
cd D:\VBS\
WSCript Converter.vbs
Put the above code in a text file and save the text file with .bat extension. Now you have to simply run this .bat file.
Why don't you just stash the vbscript in a batch/vbscript file hybrid. Name the batch hybrid Converter.bat and you can execute it directly as Converter from the cmd line. Sure you can default ALL scripts to run from Cscript or Wscript, but if you want to execute your vbs as a windows script rather than a console script, this could cause some confusion later on. So just set your code to a batch file and run it directly.
Check the answer -> Here
And here is an example:
Converter.bat
::' VBS/Batch Hybrid
::' --- Batch portion ---------
rem^ &#echo off
rem^ &call :'sub
rem^ &exit /b
:'sub
rem^ &echo begin batch
rem^ &cscript //nologo //e:vbscript "%~f0"
rem^ &echo end batch
rem^ &exit /b
'----- VBS portion -----
Dim tester
tester = "Convert data here"
Msgbox tester
You may follow the following steps:
Open your CMD(Command Prompt)
Type 'D:' and hit Enter. Example: C:\Users\[Your User Name]>D:
Type 'CD VBS' and hit Enter. Example: D:>CD VBS
Type 'Converter.vbs' or 'start Converter.vbs' and hit Enter. Example: D:\VBS>Converter.vbs Or D:\VBS>start Converter.vbs
Run a batch file from Task Scheduler is not working with a java command inside the .bat file. If I run the .bat file manually its working good.
Here is the simple .bat file I'm trying to schedule
set JAVA_HOME=C:\Program Files (x86)\Java\jdk1.6.0_24;
set CMD= "%JAVA_HOME%\bin\java" -version
echo %CMD%
%CMD%
When you type batchfile.bat on the command line, you are telling cmd.exe to read the file and execute each line it finds in it. When you double-click on your batch file in explorer, it calls cmd.exe for you, after reading the file associations in the registry.
Task Manager is not so kind.
So for your task to work, schedule it like this (from memory, not on a Windows box right now) :
cmd /c "c:\full\path\to\your\batchfile.bat"
For extra robustness, you could make sure you batch file run from a known directory, like the one that it reside in, by adding this at the top:
pushd %~dp0
REM .... The original batch file goes here ....
popd
And finally you could disable CMD autorun entry by adding /d right after cmd like this:
cmd /d /c "c:\full\path\to\your\batchfile.bat"
If ixe013's suggestion doesnt work go to
'Actions'
'Edit' the task
'Start in (optional):' Put the path to the directory where the script is
So for the last one if you have 'C:\Users\Desktop\script.py' just put in 'C:\Users\Desktop\' in the 'Start in (optional):' field
What worked for me was running the task as "Users" ( computername\Users ). Once I did that, and "run with highest privileges" checked, it ran without a hitch.
Giving the full path of java.exe in the batch file fixed it for me. In a notepad, I typed the following line:
"C:\Program Files\Java\jdk1.8.0_40\bin\java.exe" -jar "C:\Users\usernameXXXX\Documents\NetBeansProjects\JavaApplication5\dist\JavaApplication5.jar"
Save this as a app1.bat file (C:\temp\app1.bat)
In the Actions tab of the task scheduler, give the path to the batch file, i.e, C:\temp\app1.bat
Also, be careful in the Conditions tab of task scheduler- make sure you uncheck "Start the task only if the computer is on AC power"
All other ways did not work for me, I followed this guide:
http://richardstk.com/2012/06/15/scheduled-task-to-run-a-batch-file/#comment-6873
In order to get the batch file to run, I had to set the "Program\script" box to contain just the name of the script (ie. script.bat) and set the the folder path of the script in the "Start in (optional)" box
I gave full permission to user Everyone from security tab from Properties of the folder in which batch file is. and it started working.
What a coworker discovered on something he had that wasn't working, and I have verified on the system I had that wasn't working is the following:
When the whole task is initially setup, you HAVE TO initially use the radio button "Run only when user is logged on". It will ask for your password for the change.
Now run the task.
Verify that whatever the batch was supposed to do, did happen.
And THEN change to the radio button BACK TO 'Run whether user is logged on or not."
This solved a problem for both of us that we had individually been working on for hours.
Side notes: both issues were also trying to elicit a 3rd party FTP app (WinSCP and WinFTP respectively) in each of our cases. Regular "inhouse" batch/tasks were having no issues.
I had the same problem, and to solve it, I put the next command line into the batch file:
cd "CURRENT_DIRECTORY"
where CURRENT_DIRECTORY is the directory where the batch file is located.
Example:
Suppose i have my batch file named test.bat located into c:\windows\system32\mytest
in my test.bat file, i introduce the next command line:
cd c:\windows\system32\mytest
We are a small office with a Linux appliance server (SAMBA) and Win7HP on the desktops. We have one machine that acts as a "backup server" and backs up the server nightly.
Writing what was supposed to be a quick & dirty addition to the backup script that would loop like this:
a. net use * /d /y
b. net use u: \\ourserver\userNN /u:userNN password
c. run sync util to sync u: to this user's storage space on backup server
d. repeat
If I manually create the above in a batch file, everything works fine. (However, for many reasons the procedure must be automated and tied into our existing backup scripts.)
If a script creates the identical batch file and runs it, the first user is logged-in and syncronized, but all subsequent net use attempts fail.
Similarly, if the script attempts to map the drive through code, this message is received:
Unrecognised network error #183
The above error suggests that the network drive/path is unavailable -- but a net use command typed at the command line using identical parameters is successful.
The "backup server" is a Win7HP box with UAC disabled. When cmd prompt is launched, all windows are preceded by the word: Administrator: -- however, when the script launches a command window to net use the drive, the cmd titlebar lacks that prefix.
Any thoughts / ideas?
In order for users to execute this code properly, they will need to have the proper credentials to do so. Also to automate this task, just use Task Scheduler and it should work fine.