After installing the new server, I am facing an issue.
I have lot of .vbs files, all need to run in wscript, reason, I use all those command like WScript.Echo "hello"
I want to be able to see the output when I double click the VBScript file.
But when I right click on the vbs file, I see console, I want to change the default to Windows host, globally!
How can I do that?
You can change the default scripting host to wscript.exe like so:
wscript.exe //H:wscript
If you wish to set cscript as the default host, that works in the same way:
wscript.exe //H:cscript
You can execute cscript.exe with the same arguments for the same result.
You can switch the default script engine with:
wscript //H:Wscript
Good luck!
I was able to solve it by using the following steps:
selecting the VBScript file that I want to open,
right click to select default program for this,
browse to C:/windows/windows32/wscript.exe, and select this.
In command prompt (as administrator):
To set windows script host as default script host enter:
wscript.exe //H:WScript
To set command line based script host as default script host enter:
cscript.exe //H:cscript
Check the Windows Explorer settings for the filetype *.vbs (something like tools->options->file types etc.) and change the "open with" setting to cscript.
Edit: I now advise caution with the recommendations I give below. After continuing to toggle and test my settings, I find I am unable to re-establish cscript as my default script host. (Note that I also retried the procedures given by other answers to this question.)
In addition, I tried using Process Monitor (a.k.a., "ProcMon") to find the reason for my difficulties, but unfortunately have not been unsuccessful.
Finally, I also considered going back to an earlier Windows 7 restore point, but this was complicated by the fact that I just yesterday changed my domain password. So, for now, I'm going to have to put my investigation to rest as other tasks are pressing.
On last thought...I have also considered the possibility that there are network policy security settings that are thwarting my efforts.
Original Answer: Enter the following line in a Windows batch file:
ftype VBSFile="%%SystemRoot%%\System32\WScript.exe" "%%1" %%*
Then, run a Command Prompt as an Administrator and run the batch file.
I believe the above will make the change for all users on the system. To make the change for only the logged in user, do the following (on Windows 7):
Control Panel => Programs => Default Programs => Associate a file type or protocol with a program
Then, in the Name column, scroll down to .vbs and click Change program... in the upper right. Then choose one of the Recommended Programs. If you do not see Microsoft ® Windows Based Script Host, browse to the following file:
C:\Windows\System32\wscript.exe
The guy above who right-clicked to choose the default program was right, however the path should be: C:\Windows\System32\wscript.exe
Related
How do I start/call a batch file from another, but with administrative privileges, so that it doesn't give me errors like the following?
Access is denied error code 5
Here is something like what I would like it to be.
echo PLEASE TYPE YOUR USERNAME AND PASSWORD IN THE FIELDS BELOW.
echo.
echo.
echo.
echo.
set /p u=Username:
echo.
set /p p=Password:
start next.bat %u% %p%
No matter which way you chose, You must accept run it with admin privilege, so the point is which way is shorter? You could Right Click > Run as administrator as jean-Michael said although I prefer james approach (using vbScript) but if you don't want to use another vbScript file and just want benefit of just click on batch file and accept run with admin privilege (Note you have one right click and left click less) I suggest you this:
create a shortcut from your batch file and right click on shortcut > Properties > Shortcut Tab > Advanced now check the Run as administrator check-box. every time you execute it from the shortcut you just have one click to accept run it with admin privilege.
Hope this help.
Sometimes third party utilities like AutoIt (see runas function) are not an option - but if you do have that option, check it out as that will let you do exactly what you're aiming to. You can then call the AutoIt script from your script and use its runas function.
Windows runas doesn't support providing a password unless you're happy with the /savecred option - which is fine if you're only running the task from a single computer. The first time it will ask you for a password, but after that it won't (though you still have to use /savecred option each time you use it). I've got a feeling using this could be a huge security hole. But since it seems this is for your own machine, in your batch use this:
runas /user:computername\username /savecred yourcommand.exe
Another way is to make a scheduled task that can be called by your script. You can make it using the GUI or from an elevated command line as described here.
You can then call it from your script like this:
SCHTASKS /Run /TN yourtaskname
Simply put the bat file into the Windows directory, and it will run as administrator. I tried this myself, and it worked:
C:\Windows\batch_file.bat
It should work like that.
Within the batch file itself there is no way to run as an administrator, however if you launch the batch file from within a .VBS file, you are able to specify a 'runas' parameter.
set shell=CreateObject("Shell.Application")
shell.ShellExecute "your_batch_file.bat",,"C:\path\to\thedirectory", "runas", 0
set shell=nothing
This will launch your batch file as an administrator, and you can enable or disable the shell display (this example hides it as i wanted my program to run in the background without being seen).
Right click -> Run as administrator.
I think microsoft made as much as they could to prevent batch script to get administrative privileges on their own.
#cmd, I posted an example (How can I test effective permissions of a user from a batch script?) to run another bat file with ShellExecute and elevated rights (only when it's needed).
Take a look if it's what you looking for and what you need. If not, let me know and we could adapt your script to make it work.
good luck
I actually joined just to answer this, the simplest way by far is to create a shortcut to the program you want to run, then set the shortcut to run as administrator and just call the shortcut from the batch file. This will run with the settings specified in the shortcut and you could place this shortcut in the same folder as your batch file or just call it from the start menu.
Example:
"C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Folder\Shortcut Name.lnk"
I'm trying to install a driver with a remote framework that lets me run shell commands spawned as children of the remoting/monitoring app on the remote machine, run as cmd /c "command". But the driver refuses to install due to a security feature which thinks the driver may be unsafe.
The driver also has quotes(spaces in path) so its something like
Dim command: command = "\\\\server\\driver\\folder\\Autorun.exe" /passive /norestart";
Set retVal = remote.Shell(command)
which runs
cmd /c " "\\server\driver\folder\Autorun.exe" /passive /norestart"
on the remote machine
I've tried and have had trouble using setx SEE_MASK_NOZONECHECKS 1 /m in a previous statement, I'm guessing that the subprocess don't see new global enviromental variables that weren't around when it's parent started, and won't work without a restart. I'd like to avoid a restart.
I tried running
cmd /c " set SEE_MASK_NOZONECHECKS=1 & "\\server\driver\folder\Autorun.exe" /passive /norestart"
but it doesn't seem to work. Any ideas?
You got a bit lost on the way SEE_MASK_NOZONECHECKS is used. It is not an environment variable and cannot be tinkered with from the command prompt, it is an option for ShellExecuteEx(). A winapi function that you indeed use to start programs. It isn't very clear what programming tools you have access to, using it in a batch file or VBScript isn't going to work. You'd need at least, say, VB.NET and pinvoke the function. You can get the required declarations from the pinvoke.net web site.
Let's talk about what's really going on, you might find a simpler solution. When you download a file from an Internet web site, Windows adds an extra stream to the file that indicates where the file came from. Which basically states "this file did not come from a safe place" and makes the driver installer balky. Which is rather an important feature if you think about it, your user is going to install software that can do a lot, you pretty much have free reign of the machine if you can get a driver installed.
If you right-click the file in Explorer and click Properties then you'll see this at the bottom of the window:
All that's needed is to click that Unblock button. So this is a simple way for your user to solve the problem. You could document the extra step in the install instructions. Also with the advantage that it is now the user that took responsibility of allowing potentially unsafe code to be installed.
Other ways to get the file unblocked is with PowerShell's Unblock-File command and the SysInterals' streams utility, -d option.
And you probably ought to consider the option of writing your own installer. Which will keep the driver packaged in the setup file so it won't be tinkered with by Windows. And the user gets the warning when he starts the installer instead. And it can be signed so the user has some confidence in where the file came from and that it didn't get messed with on its way to his machine. There are many utilities that help you write an installer, like InstallAware, InstallShield, NSIS, etcetera.
I beg to differ to Hans' answer:
Of course, SEE_MASK_NOZONECHECKS is as well a predefined environment variable. Changing it in a process and then starting a child process (e.g. msiexec.exe) which by defaults inherits the environment, has just the same result as using ShellExecuteEx() and providing SEE_MASK_NOZONECHECKS as a parameter to the SHELLEXECUTEINFO structure. The first method is preferred by admins or quick hacks, e.g. if you work with batch or script files which set the environment variable- or when the final call to the .msi file lying on the unsafe network drive is not done by your own code.
For example:
#echo off
set SEE_MASK_NOZONECHECKS=1
call msiexec.exe /i "\\MY_UNC_DRIVE\installs\mysetup.msi /qb /L*v "c:\logs\mysetup.log"
call "\\MY_UNC_DRIVE\installs\Just_another_setup.exe"
If you already use a ShellExecuteEx() in your code, then of course, go with the parameter as Hans mentioned, because this implementation it is more closed. (If you use CreateProcess(), think about using ShellExecuteEx() instead.
Getting back to the environment variable(s). Generally you cannot influence the environment of already started processes. You can set the default environment used by NEW processes by the "setx" command used in the question. But with "setx" you don't change the environment for your current process.This was the problem in question. For this you have to use "set" as shown. So either use both commands after each other or don't use setx at all because for running a setup on foreign machines, it is not clean to make permanent security changes without asking.
For more details on permanent changes/admin point of view, see:
https://superuser.com/questions/595211/removing-the-open-file-security-warning-in-windows-8/934283#934283
Important: As mentioned, there is no general way in Windows to influence processes which already run (only own-defined inter-process-communication maybe), so it is important to set the environment variable before starting the setup to be influenced.
One more thing: Some people think, one must use "SETLOCAL" in a batch file. Normally this is not necessary. Environment changes with "set" are not permanent, and do not incluence "other" processes- they are only inherited to subprocesses and, partly, to superprocesses. But, when the caller on first level ends, the environment is reverted to original state again.
I ended up setting "Launch applications and unsafe files" to enabled for Internet zone in Internet Explorer options under security(custom level) and then exporting the changes from HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3 to a registry file and adding it with regedit /s.
After that I can run the installer of the shared drive.
One of these days I'll pare the registry file down to the minimum I guess.
P.S. I believe this causes IE to default to a warning page on startup.
I believe you need to put everything within the same quotation:
cmd /c "set SEE_MASK_NOZONECHECKS=1 & \\server\driver\folder\Autorun.exe /passive /norestart"
You can try these and see the difference in the output:
cmd /c "echo foo & echo bar"
cmd /c "echo foo" & "echo bar"
On my main pc (Win 7 64bit) basic windows commands like ping and ipconfig suddenly need admin rights.
If I start a normal command-line window, these commands are not found anymore ("X is not recognized as an internal or external command, operable program or batch file.")
If I start the command-line window with "Run as Administrator" everything works as expected.
On my second PC (Win 7 32 bit) I do not need admin rights.
And I strongly believe that I did not need admin rights on my main pc a couple of weeks ago. Something must have changed, thus I think there must be some (registry) switch or something.
any ideas? thanks a lot
[edit]
I am still the admin user - just starting cmd normally, not with "run as admin"
[edit2]
It indeed was the PATH, variable. Problem was, that Path was saved as the wrong type of string in the registry
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\Path
has to be a REG_EXPAND_SZ as explained in this thread. Path being of the wrong type of string made it unable to expand %SystemRoot%. Make sure that both your system PATH as well as your user PATH environment variables are of type REG_EXPAND_SZ.
In an effort to narrow down the issue try the following:
open command prompt
make sure you are on the C:\ directory
type this: windows\system32\ipconfig /all
That will point to the default location for the command... You can also follow the path out to see if the ipconfig.exe is there in the first place. If that doesn't work or the file is not there, it could be corrupt or you could possibly have a virus designed to disable these commands.
Srart normal cmd prompt and look at output of the following commands
set path
dir %windir%\system32\ping.exe
dir %windir%\syswow64\ping.exe
dir %windir%\sysnative\ping.exe
Thought, they will show you a problem. May be ping is not found by %path% or somehow...
Ran into a problem today. I have a Windows Server 2003 with a bunch of .bat files that essentially start .vbs scripts. Every time an ECH is used in the script I get that annoying dialog box that contains content of an echo and requires to click ENTER all the time. How can I just disable the dialogs and keep ECHOs in the command prompt window only?
Force it to run under cscript instead of wscript
If you are running the script manually, just put cscript in front of it.
Otherwise, this might give you an approach:
http://www.robvanderwoude.com/vbstech_engine_force.php
Redirect the output somewhere else, i.e.
scriptname.vbs > textfile.txt
I want my Perl scripts to behave just like any other executable (*.exe file).
When I double-click on myscript.pl I want it to execute instead of opening in a text editor.
I want to run myscript.pl instead of perl myscript.pl.
I really want to run myscript instead of myscript.pl.
I want to run program | myscript instead of program | perl myscript.pl.
I want to be able to run my script via drag & drop.
There are a number of changes you have to make on Windows to make all of
these things work. Users typically stumble upon things that don't work one at
a time; leaving them confused whether they've made an error, there's a bug in
Perl, there's a bug in Windows, or the behavior they want just isn't possible.
This question is intended to provide a single point of reference for making
everything work up front; ideally before these problems even occur.
Related questions:
How do I make Perl scripts recognize parameters in the Win32 cmd console?
Running a perl script on windows without extension
Perl execution from command line question
How can I read piped input in Perl on Windows?
Perl on Windows, file associations and I/O redirection
How do I create drag-and-drop Strawberry Perl programs?
Note: The actions below require administrative privileges. For
steps utilizing the command prompt it must be launched via "Run as
administrator" on Windows Vista / Windows 7.
Associate *.pl files with perl
Run the following commands at a shell prompt:
assoc .pl=PerlScript
ftype PerlScript=C:\bin\perl.exe "%1" %*
Replace C:\Perl\bin\perl.exe with the path to your Perl installation. This
enables you to run myscript.pl instead of perl myscript.pl.
Default install locations are:
ActivePerl: C:\Perl
Strawberry Perl: C:\Strawberry
Add .PL to your PATHEXT environment variable.
This makes Windows consider *.pl files to be executable when searching your
PATH. It enables you to run myscript instead of myscript.pl.
You can set it for the current cmd session
set PATHEXT=%PATHEXT%;.PL
To set it permanently (under Windows Vista or Windows 7)
setx PATHEXT %PATHEXT%;.PL
Under Windows XP you have to use the GUI:
Right-click My Computer, and then click Properties.
Click the Advanced tab.
Click Environment variables.
Select PATHEXT, then click Edit.
Append ;.PL to the current value.
Make I/O redirection work
I/O redirection (e.g. program | myscript) doesn't work for programs started
via a file association. There is a registry patch to correct the problem.
Start Registry Editor.
Locate and then click the following key in the registry:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer
On the Edit menu, click Add Value, and then add the following registry value:
Value name: InheritConsoleHandles
Data type: REG_DWORD
Radix: Decimal
Value data: 1
Quit Registry Editor.
Warning: In principle, this should only be necessary on Windows XP. In my experience it's also necessary in Windows 7. In Windows 10 this is actively harmful—programs execute but produce nothing on stdout/stderr. The registry key needs to be set to 0 instead of 1.
See also:
STDIN/STDOUT Redirection May Not Work If Started from a File Association
Perl Scripts on Windows 10 run from Explorer but not Command Prompt
If patching the registry isn't an option running program | perl -S myscript.pl
is a less annoying work-around for scripts in your PATH.
Add a drop handler
Adding a drop handler for Perl allows you to run a Perl script via drag & drop;
e.g. dragging a file over the file icon in Windows Explorer and dropping it
there. Run the following script to add the necessary entries to the registry:
use Win32::TieRegistry;
$Registry->Delimiter("/");
$perlKey = $Registry-> {"HKEY_CLASSES_ROOT/Perl/"};
$perlKey-> {"shellex/"} = {
"DropHandler/" => {
"/" => "{86C86720-42A0-1069-A2E8-08002B30309D}"
}};
Convert your perl scripts into batch files using pl2bat once they are ready to be run by users.
The trick works through the perl -x switch which, according to perldoc perlrun, makes Perl search for the first line looking like #!.*perl.
After following the instructions in the accepted answer, a double click still led to .pl files opening with Notepad in Windows 10 — even when perl.exe was set as the default file handler.
After finding Jack Wu's comment at ActivePerl. .pl files no longer execute but open in Notepad instead I was able to run perl scripts on double-click as such:
Select and right-click a .pl file
Use the "Open With" submenu to "Choose another app"
Select "Always use this app to open .pl files" (do this now – you won't get the chance after you have selected a program)
Scroll to the bottom of the "Other options" to find "More apps", and select "Look for another app on this PC"
Navigate to C:/path/to/perl/bin/ and select Perl5.16.3.exe (or the equivalent, depending on which version of Perl you have installed: but not Perl.exe)
Then the Perl icon appears next to .pl files and a double-click leads to them opening in Perl every time, as desired.
I tried the assoc and ftype methods and they didn't work for me.
What worked was editing this registry key:
Computer\HKEY_CURRENT_USER\Software\Classes\Applications\perl.exe\shell\open\command
It was set to:
"C:\Perl64\bin\perl.exe" "%1"
When it should be:
"C:\Perl64\bin\perl.exe" "%1" %*
It is the same content as the ftype, but for arcane windows reasons, I had to set it there too.
Like some others, I had set 'assoc' and 'ftype', but also had set Notepad text editor via the GUI, and when I tried to execute a script via the command line, Windows invoked Notepad to edit the script instead of running my script.
Using the GUI to instead point the .pl file association to the script-running executable was not much of an improvement, since it would invoke the executable on my script, but would pass no command-line arguments (even when I invoked my script from the command line).
I finally found salvation here which advised me to delete some registry keys.
Key quote:
"The problem is that if you have already associated the program with the extension via the Open With dialog then you will have created an application association, instead of a file extension association, between the two. And application associations take precedence."
In my case, following the instructions to use RegEdit to delete
HKEY_CLASSES_ROOT \ Applications \ perl.exe
where perl.exe is the name of my Perl executable, and then also deleting:
HKEY_CLASSES_ROOT \ .pl
seemed to solve my problem, and then (after re-executing 'assoc' and 'ftype' commands as shown in other answers) I could then execute scripts from cmd.exe and have them run with access to their command-line parameters.
Some other related information here.