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...
Related
I'm trying to write a batch file that will open computer management as an administrator (on a Windows 7 64 bit system). I have done this successfully with cmd but cannot get it to work with computer management.
The command I have for cmd is:
runas /profile /env /user:username#domain cmd
After I authenticate with my pw, I'm good to go.
The commands I've tried for computer mgmt are:
runas /profile /env /user:username#domain compmgmt.msc
After I authenticate I get an error telling me "compmgmt.msc is not a valid Win32 application.
runas /profile /env /user:username#domain mmc
After I authenticate I get an error telling me "The requested operation requires elevation"
If I run the good cmd option then type in either mmc or compmgmt.msc, the program will open as admin because I'm in cmd as admin already. I'm assuming there's a way to add onto the good cmd command to autopopulate that text into cmd and run it, but I don't know what it is. I'm also open to trying other options, really I just want a tool that works. I know that I can run my batch as admin and avoid all of this but the purpose of this tool is to not have to provide my admin username.
Suggestions?
runas /user:username#domain "cmd.exe /c \"start compmgmt.msc\""
If the .msc runs correctly from cmd, start cmd under the adecuated account and, from here, start the .msc
The problem is that you cannot run an .msc plugin without calling mmc.
The correct call should be in this format:mmc.exe \location of plugin
runas /u:domain\user "mmc.exe \windows\system32\compmgmt.msc"
The start command will also work but relies on the extensions being properly entered in the registry. I usually do mmc \plugin location due to the different windows operating systems we use and the fact that usually half the plugins I want to use are not registered on the system for some reason.
better you travel to that location and then execute that file
You can write batch file which will run:
(CompMgmtLauncher.exe or CompMgmt.msc)
It'll look like
C:\Users\Admin>cd\
C:>cd Windows
C:\Windows>cd System32
C:\Windows\System32>CompMgmtLauncher.exe
C:\Windows\System32>compmgmt.msc
C:\Windows\System32>
I am working on Windows 7 (logged in as session no.1), my Jenkins CI is running as windows service in session 0.
My problem is.. I want to open an Excel file through Jenkins CI in session 0, but want to display its GUI on session 1.
I know that session 0 is isolated in Windows 7, but is it possible to run a process in session 0 and then output in another session? please help.
Edit:
Took a little trial and error, but this is what finally worked for me (Windows 7 64-bit).
Download PsTools from Microsoft site
We only need psexec.exe, but you can extract everything. Extract to some location accessible by Jenkins, preferably without spaces in the path.
Open elevated command prompt: type cmd into Start's quicksearch, right click cmd.exe, select Run as Administrator.
Type C:\path\to\psexec.exe -accepteula and press enter.
Type C:\path\to\psexec.exe -i 1 cmd and press enter. (If you see a command prompt appear, all is good, close it now)
In Job configuration, configure Execute Windows Batch command step
Write the following:
C:\path\to\psexec.exe -accepteula && C:\path\to\psexec.exe -i 1 cmd /c start C:\PROGRA~2\MICROSO~1\path\to\excel.exe
Where:
C:\path\to is your full path to psexec.exe, unless it is in your %path%
-i 1 is the session ID that you want to launch in.
C:\PROGRA~2\MICROSO~1\path\to is your full path to excel.exe without spaces. Since most Office installations are going to be under paths with spaces, like "Program Files (x86), you have to figure out the short path, or place it somewhere without spaces.
Having excel.exe under %path% and working from regular command line was not enough.
A little explanation for those that care:
psexec needs to install a services first. For that, it needs to be run from elevated command prompt for the first time. This is a one-time installation step.
To make psexec work, you need to accept the EULA prompt. This is done per session/user. So even if you run psexec -accepteula in your command prompt, it doesn't help when Jenkins service (running as Local System in session 0) tries to use it. Therefore, you have to place that into the Jenkins job, along with the command. Technically, it only needs to be there once, and can be removed afterwards, but it definitely doesn't hurt to keep it there.
I've used cmd /k and running this command from my local cmd prompt to debug. This is what made me realize I couldn't find a way to escape the spaces (tried various quoting), so had to resort to short file names. Note that short file names are not required, this is just to escape spaces.
no its not-
plus any UI interactions requires you to run Jenkins as Java web start rather than a service or you can not interact with UI elements.
I've been trying to install the 64bit version of PostgreSQL 9.2 for Windows on my machine (Windows 7 64bit) and get this error:
The environment variable COMPSPEC does not seem to point to the cmd.exe or there is a trailing semi colon present.
I've installed it as Administrator.
I disabled the antivirus (Microsoft Security Essentials) and the firewall.
Running:
"%COMSPEC%" /C "echo test ok"
returned test ok
I've checked my System Environment Variables for trailing semi colon and I couldn't find any.
I then installed the 32bit version and managed to get to the end of the install with a different error message stating: Problem running post-install step. Installation may not complete correctly Error reading the C:\Program Files (x86)\PostgreSQL\9.2\data\postgresql.conf but there is no postgresql.conf file in that directory. It did install the application and when I try to connect the server with the red X on it it says fail at the bottom and it won't connect after I type in my password.
How can I connect to this server connection?
ComSpec is a generic error message for any installation failure.
Identifying the problem
Navigate to below path
c:\Users\XXXXXX\AppData\Local\Temp
Open 'bitrock_installer_XXXX.log'
Check, if you are getting below error:
Script stderr:
'"C:\Users\XXXXX\AppData\Local\Temp\POSTGR~1\TEMP_C~1.BAT"' is not recognized as an internal or external command, operable program or batch file.
Error running
C:\Users\XXXXX\AppData\Local\Temp/postgresql_installer_47b21c4ea1/temp_check_comspec.bat :
'"C:\Users\XXXXX\AppData\Local\Temp\POSTGR~1\TEMP_C~1.BAT"' is not recognized as an internal or external command,
operable program or batch file.
This is a problem with '8.3 file names and directories' (e.g. '\Postgres Install' -> '\POSTGR~1')
Microsoft article on disabling 8.3 file names and directories: https://support.microsoft.com/en-gb/kb/121007
Solution:
Open command prompt in admin mode
Execute following command to change the format based on your drive or all drives
Sample commands:
fsutil 8dot3name set 1" - disable 8dot3 name creation on all volumes
fsutil 8dot3name set C: 1" - disable 8dot3 name creation on c:
Execute the installation as a user having admin privileges
After install, consider resetting the 8dot3name setting to default (2) to avoid unintended consequences
Hope it solves the problem!
Very easy fix:
Just open Advanced System Settings in Control Panel and create a new System Variable( in the System Variable instead of User Variable section).
In the variable name, enter ComSpec and then in the variable value , enter C:\Windows\system32\cmd.exe.
Alternative fix:
If you have already the ComSpec variable in the System Variable section, remove the ;at the end of it this should fix it.
It's not COMPSPEC it's just COMSPEC. Please show the output of:
echo %COMSPEC%
Note that COMSPEC could be set to something different in the Administrator account you're running the installer as. I'm not sure how to find that out, but it might appear in the PostgreSQL installer log, so please upload that and link to it in your post. See Reporting an installation error for info on where to get the installer log.
See the PostgreSQL for Windows FAQ entry Check the COMSPEC environment variable.
Here's a report I made suggesting that the installer should test for this explicitly and here's my blog post on the topic.
I got the same problem, and i found in the log:
Script stderr:
'C:\Users\S300' is not recognized as an internal or external command,
operable program or batch file.
Error running C:\Users\S300 (i5)\AppData\Local\Temp/postgresql_installer_56caeadbd6/temp_check_comspec.bat : 'C:\Users\S300' is not recognized as an internal or external command,
operable program or batch file.
I change in User Variables TEMP to D:\TEMP and TMP to D:\TEMP.
And Solved My Problem.
In my case , the Installer was in %USERPROFILE%\DownloadsP{ Windows download folder}, I moved the installer to desktop and ran again. weird it worked lol.
I had a similar problem. After installation, the data folder contained no postgres.conf file. It only contained a single folder named "pg_log".
I described the solution that I used here: Postgres Installation Error reading file postgresql.conf
Basically, it would be helpful to check if the user has full permissions for the postgres folder, and run "init_db" and "pg_ctl start" commands again. If the path contains a space character, try using a relative path for the pg_ctl data folder argument.
I'm running Windows Server 2003 R2, and I have been unable to resolve this problem with the installer, so I resorted to using the binary PostgreSQL package. Hopefully this will be an alternative for others who do not want to perform an OS reinstall.
First, some background (hopefully useful to the developers)
It started out with the postgres service failing to start (the server had been running reliably for over a year). I assumed it was a corrupted PostgreSQL installation, so I uninstalled and attempted to reinstall. I encountered the following error:
There has been an error.
The environment variable COMSPEC does not seem to point to the cmd.exe or there is a trailing semicolon present.
Please fix this variable and restart installation.
However, the COMSPEC variable is set properly, verified with:
echo %COMSPEC%
C:\WINDOWS\system32\cmd.exe
and:
"%COMSPEC%" /C "echo test ok"
test ok
Since this is Windows Server 2003, there is no UCA wrapper around the Administrator account, so that is not causing the problem.
Manual Installation
NET USER postgres /ADD
C:\pgsql\bin\initdb.exe -U postgres -A password -E utf8 -W -D C:\pgsql\data
runas /user:postgres "C:\pgsql\bin\pg_ctl -D C:/pgsql/data -l C:/pgsql/logfile.txt start"
just do it run as administrator and change the environment system variable
like create a new variable 'ComSpec' and value type 'C:\Windows\system32\cmd.exe'.
If the installer exe is on a network share that mapped drive might actually not be accessible to the installer as it runs as administrator. This can often happen in some virtual machine arrangements such as running windows in a parallels VM. Copy the installer to a local drive first and you won't have a problem.
What worked for me after trying to enter the commandline given her in cmd.exe
I found it was named cmd1.exe in system32.. so i copied the file and renamed it as cmd.exe and installation finished
Open Environment Variables, you can do this on Windows 7 by typing environment variables in the Search program and files bar when pressing the start button at the bottom left of the desktop. And create a new System Variable(in the 'System Variable' instead of 'User Variable' section).
In the variable name, enter ComSpec and then in the variable value , enter C:\Windows\system32\cmd.exe.
That's all. Hope it works!
Alternative fix:
If you already got the ComSpec variable in the System Variable section, remove the ; at the end of it this should fix it.
First find the path to cmd.exe(mostly it is C:\Windows\System32\cmd.exe).
Go to the enviornment variable and add this path to system variable path.And also create new variable in user variable called ComSpec and add this path as value. And you are ready to go.
I have installed ActivePerl on my Windows OS. I have followed below URL
procedure to install
ActivePerl Installation
After having done that, I have tried to run "perl -v " on the command line. But it reports the following error.
The system cannot execute the
specified program
What do I need to do to solve these issues?
I was facing a similar issue... but the thing was that I could execute the file by right clicking the file and opening it with perl command line interpreter.... but still the perl-v command would give the error... all I had to do was execute this command
set PATH=C:\Perl\bin;%PATH%
This solved the issue...
You need to make sure the directory where the Perl executable lives (it might be C:\perl\bin, but basically wherever you told ActiveState Perl to be installed) is in your PATH environmental variable (you can find the variable value by typing set PATH command on command line prompt in Windows).
If you're not sure where you installed Perl to (and can't find it in the default C:\perl\bin), you can find the directory by going to Start menu, finding ActiveState Perl folder, and right-clicking on "Perl Package Manager" icon, then pick "Properties" from the right-click menu. Properties window (in the "Shortcut" tab) will have a "Target" line showing the directory.
I was getting a similar error after installing ActiveState Perl on Windows 8 x64 bit edition and trying to invoke 'perl' at the command line.
'perl' is not recognized as an internal or external command, operable
program or batch file.
I remember selecting the option during installation to add the Perl directory to the system PATH environment, and after checking the system properties, it was indeed showing in the system PATH.
I tried installing 'Microsoft Visual C++ 2008 x86 and x64 redistributable setup' files as suggested by a few places but it still did not resolve the issue, until I tried some of the suggestions in this thread.
At the command prompt I entered:
set PATH
And surprisingly it did not list the Perl directories as being included in the PATH variables.
So to remedy that I entered this into the command prompt and hit enter:
set PATH=C:\Perl64\bin;C:\Perl64\site\bin;%PATH%
(The directory paths are for the 64 bit edition of Perl, adjust according to your installation) the %PATH% portion is important and ensures your existing settings are kept and not wiped out and overwritten when you set the PATH.
That fixed it and entering 'perl -v' into command prompt successfully replies your Perl version. If you had a PowerShell window open before setting the PATH variable, you will need to close it and re-open another instance of PowerShell.
I believe the original underlying issue was something to do with different PATH variables for 32-bit and 64-bit environments and possibly some internal Windows redirection that takes place automatically.
This doesn't sound like a problem with PATH - I would expect it to give the message 'perl' is not recognized as an internal or external command, operable program or batch file.
I have not seen this error message, but http://nirlevy.blogspot.com/2008/03/system-cannot-execute-specified-program.html makes some suggestion for related programs.
Or maybe ask on an Active State forum.
I had the same error. I was able to solve it by changing the order of the Perl64 entries in the PATH variable in the Environment Variables. I moved the C:\Perl64\bin to be before C:\Perl64\site\bin and it worked.
I had a similar error which was solved by adding the .pl extension to the script name, which I had forgotten to do.
I could not get it to work otherwise even with my Perl's location (C:\Apps\Perl\bin) verified as in %PATH%.
The problem lies in the installation directory.
The Perl PATH variable will be set to C:\Program Files\perl (depends on 32 or 64 bit of course), BUT, the default installation directory is C:\perl. This is kind of sneaky actually as you would assume the installer would be more intelligent about this, but it sets the environment variable to that directory no matter WHERE you install the damned thing.
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