I want to find location of 'cmd.exe' or 'powershell.exe' from remote computer. I want to execute a script from remote computer. To execute it I want location of 'cmd' or 'powershell.exe'. It is possible that windows is installed on any drive. so how to find where is my windows is installed.
It's available via WMI (Win32_OperatingSystem)
wmic.exe /NODE:<remote_computer> OS GET WindowsDirectory
To get the path + file of cmd.exe you can use this variable: %ComSpec%, which will return C:\Windows\System32\cmd.exe in most cases. To get only the path to that location, you can use for instance (in the cmd)
for /f %a in ("%ComSpec%") do echo %~dpa
or (in a batch-file)
for /f %%a in ("%ComSpec%") do echo %%~dpa
Use %WINDIR% environment variable
Example:
set "_path=%WINDIR%\system32\cmd.exe" --> sets _path variable
cd /d %_path% --> goes to _path folder
Related
The following illustrates a problem I found using for /f %l in ('<command>') do #(echo %l). (/f is the for command's parameter for "iterating and file parsing.") This works as expected when <command> is cd or chdir, but not when <command> is pushd:
C:\>cd
C:\
C:\>for /f %l in ('cd') do #(echo %l)
C:\
C:\>chdir
C:\
C:\>for /f %l in ('chdir') do #(echo %l)
C:\
C:\>pushd Windows
C:\Windows>pushd
C:\
C:\Windows>for /f %l in ('pushd') do #(echo %l)
C:\Windows>pushd > nul
C:\Windows>
I would expect the last command to print C:\ but it does not execute the do block at all. I added pushd > nul to check that pushd prints to stdout.
How can I process the output of pushd in a for /f loop?
Information about command processing by FOR /F
The usage of a for /F loop with a command enclosed in ' or in ` on using usebackq results in starting in background one more command process using %ComSpec% /c and the command appended as additional argument(s).
The usage of for /f %l in ('pushd') do #(echo %l) results in background execution of:
C:\Windows\System32\cmd.exe /c pushd
That can be seen by downloading, extracting and running the free Windows Sysinternals tool Process Monitor as administrator which logs the execution of two cmd.exe processes with different process identifiers on running the commands as posted in the question. There must be double clicked on any line in log of Process Monitor of second cmd.exe in the middle of the log to open the Event Properties window and selected the second tab Process to see the Command Line which was used by first cmd.exe to start the second cmd.exe for the execution of the command pushd.
There cannot be executed just a single command with a for /F loop. There can be executed an entire command line which can even have multiple commands. But it is necessary to take into account all the information given by the usage help of cmd output on running cmd /? in a command prompt window on using a complex command line with for /F and processing its output as written to handle STDOUT of in background started cmd.exe.
Command operators like &, && and || as well as redirection operators like |, 2> and 2>&1 in the command line to execute by for /F are processed by two cmd.exe, first the one executing the entire for /F loop and another one started in background with the command line of which output is of interest. That is the reason why many for /F loops with a complex command line are with the escape character ^ left to each & and | and > in the command line to get these characters interpreted literally by cmd.exe parsing and executing the entire for /F loop while being interpreted as command/redirection operators by the second cmd.exe started in background which is really executing the command line.
Information about output of PUSHD
The Windows command PUSHD outputs on execution without any directory path the list of directory paths pushed on stack of current command process.
There can be executed in a command prompt window following commands:
cd /D %SystemDrive%\
pushd %SystemRoot%
pushd inf
pushd
popd
popd
The fifth command pushd results usually for typical Windows installations in the output:
C:\Windows
C:\
But there is nothing output by using as fifth command instead of pushd the command line:
for /F "delims=" %I in ('pushd') do #echo %I
The reason is the execution of pushd by one more cmd.exe started in background which has no directory paths pushed on its stack. The internal command PUSHD does not output anything at all for that reason to handle STDOUT of in background started cmd.exe.
The command process running for /F cannot capture any output text. The for /F loop cannot process therefore any line after cmd.exe started in background finished the execution of pushd and closed itself.
How to process the directory paths pushed on stack?
It would be necessary to use the following command lines in the command prompt window to process the directory paths pushed on stack of the current command process:
pushd >"%TEMP%\DirectoryList.tmp"
if exist "%TEMP%\DirectoryList.tmp" for /F "usebackq delims=" %I in ("%TEMP%\DirectoryList.txt") do #echo %I
del "%TEMP%\DirectoryList.tmp" 2>nul
The redirection of the output of PUSHD executed by the command process which executed also the two pushd command lines before into a temporary file makes it possible to process the directory paths pushed on stack of current command process.
The for /F option usebackq is necessary to get the string inside " interpreted as file name of which lines to process by the FOR loop and not as string to process.
The for /F option delims= is necessary to define an empty list of string delimiters as a directory path can contain one or more spaces. There is by default split up a line into substrings using normal space and horizontal tab as string delimiters and assigned to the loop variable is just the first space/tab delimited string instead of the entire directory path. The line splitting is turned off by the definition of an empty list of delimiters. The entire directory path is assigned therefore always to the loop variable in this case with processing always full directory paths never starting with the default end of line character ; as the first character is always either a drive letter or a backslash in case of a UNC directory path.
Why does the command CD work with a FOR /F loop?
The command CD works also with for /F "delims=" %I in ('cd') do #echo %I because of cmd.exe calls the Windows kernel library function CreateProcess on starting the additional command process for execution of a command specified as set of a for /F loop with value NULL for the function parameter lpCurrentDirectory. The current directory of in background started cmd.exe is set by CreateProcess for that reason with the current directory of the command process executing the for /F command line. Both running command processes have the same current directory during the execution of the command of a for /F loop.
Information about environment variable ComSpec
ComSpec is an environment variable defined by default with %SystemRoot%\system32\cmd.exe (with s at beginning of System32 instead of S as the folder name is in real by default) as system environment variable stored in Windows registry under the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment.
It is really not advisable to ever modify or even delete the environment variable ComSpec neither in local environment of a running process nor in the Windows registry. That would cause a lot of programs to stop working normally as lots of executables depend internally on the correct definition of this environment variable including cmd.exe itself.
The reason is that many applications and scripts use internally the function system which uses the environment variable ComSpec to start on Windows cmd.exe for execution of a command line.
There are many batch files running internal command ver of cmd.exe to get the Windows version like:
for /F "tokens=2 delims=[]" %%G in ('ver') do for /F "tokens=2" %%H in ("%%G") do echo %%H
That works only for Windows NT based Windows versions using cmd.exe as command processor and not for older Windows versions using COMMAND.COM like Windows 95/98/ME for processing a batch file. It works only with enabled command extensions which are enabled by Windows default, but can be disabled by command setlocal DisableExtension in a batch file, on starting cmd.exe with /E:OFF or by a registry value which should be really never used and therefore not written here. The command ver must be really executed by %SystemRoot%\System32\cmd.exe because of in real is output the version of cmd.exe and not the version of Windows.
However, that command line is very good to demonstrate what happens on usage of for /F if the environment variable ComSpec is not defined in environment of cmd.exe on running the batch file with the two for /F loops.
ComSpec usage by cmd.exe on Windows XP
On Windows XP is always called C:\WINDOWS\system32\cmd.exe /c ver even on doing following:
Copying cmd.exe to the directory F:\Temp\system32.
Starting F:\Temp\system32\cmd.exe with a double click in Windows Explorer.
Running set ComSpec=F:\Temp\system32\cmd.exe and set SystemRoot=F:\Temp and set SystemDrive=F: and set windir=F:\Temp.
Verifying with echo %__APPDIR__% that F:\Temp\system32\ is output.
Running the batch file with the command line as posted above.
That can be seen with Process Monitor v3.61 on Windows XP x86.
There can be even modified the local environment variable PATH to begin with F:\Temp\system32 instead of C:\WINDOWS\system32 or the local environment variable ComSpec is deleted with set ComSpec=. The Windows Command Processor of Windows XP in directory F:\Temp\system32 calls nevertheless always C:\WINDOWS\system32\cmd.exe with the option /c and the command ver on running the batch file immediately after closing the batch file containing just the single command line in the text editor.
There cannot be seen in Process Monitor even a Windows registry access by cmd.exe of Windows XP to get any directory path.
Please read further why cmd.exe of Windows XP in a different directory than %SystemRoot%\System32\cmd.exe calls nevertheless the command processor executable in Windows system directory even after modification of local environment variable ComSpec or its deletion.
ComSpec usage of cmd.exe on Windows Vista/7/8/8.1/10/11
The same procedure as described above for Windows XP can be executed also on Windows 7 x64 and newer 64-bit Windows versions.
The double clicked 64-bit F:\Temp\system32\cmd.exe copied from C:\Windows\System32 outputs on Windows 7 and currently latest Windows 11 22H2 first:
The system cannot find message text for message number 0x2350 in the message file for Application.
(c) Microsoft Corporation. All rights reserved.
Note: The copyright message line depends on version of cmd.exe. The output above is from cmd.exe of version 10.0.22621.963 (Windows 11 22H2).
The Windows Command Processor cmd.exe of version 6.1.7601 of Windows 7 outputs additionally the line:
Not enough storage is available to process this command.
The execution of the internal command ver executed in the command prompt window opened with a double click on F:\Temp\System32\cmd.exe fails on Windows 7 and all later Windows versions up to currently latest Windows 11 22H2 which is the reason for the strange output on starting F:\Temp\System32\cmd.exe with a double click.
There can be redefined also the environment variables as described above and done on German Windows XP by me on my tests. A verification of the output of echo %__APPDIR__% works and shows F:\Temp\system32\ as expected. So, it works to access the string value of the internal dynamic variable of cmd.exe even on executed cmd.exe is not in the directory %SystemRoot%\System32.
But the batch file execution from within the command prompt of F:\Temp\system32\cmd.exe as on Windows XP results in no output at all.
In log of Process Monitor v3.70 or a newer Process Monitor version can be seen that on Windows 7 and Windows 11 22H2 is executed F:\Temp\System32\cmd.exe /c ver. That means it is indeed possible that another cmd.exe is executed instead of C:\Windows\System32\cmd.exe on Windows 7 and newer Windows versions.
But why is no version output?
Well, the execution of ver results in the output of the error message:
The system cannot find message text for message number 0x2350 in the message file for Application.
64-bit cmd.exe is not working in F:\Temp\system32 at all.
The usage of 32-bit cmd.exe copied from C:\Windows\SysWOW64 to F:\Temp\system32 makes no difference. The same error messages are output already on starting F:\Temp\system32\cmd.exe and on running next ver or the batch file after modification of local environment variable ComSpec.
Conclusion: cmd.exe of Windows Vista and newer versions are not fully working on being stored outside the appropriate system directory %SystemRoot%\System32 or %SystemRoot%\SysWOW64 while cmd.exe of Windows XP works fine in any directory.
Caching of ComSpec value
I found out with lots of further tests that the string value of the environment variable ComSpec is indeed used to find cmd.exe to run command ver on execution of the batch file with the for /F loop. But there is a caching mechanism on Windows Vista and newer Windows versions.
There must be run immediately set ComSpec=F:\Temp\system32\cmd.exe after starting F:\Temp\system32\cmd.exe before running the batch file. This results in calling F:\Temp\system32\cmd.exe /c ver. If there is next executed set ComSpec=C:\Windows\System32\cmd.exe to redefine the variable with correct value and run the batch file once again, there is nevertheless run now not working F:\Temp\system32\cmd.exe /c ver.
The same caching mechanism can be seen on starting F:\Temp\system32\cmd.exe, then running the batch file resulting in calling in background C:\Windows\System32\cmd.exe /c ver, next running set ComSpec=F:\Temp\system32\cmd.exe and running now the batch file again. There is executed once again C:\Windows\System32\cmd.exe /c ver although the value of the environment variable ComSpec is now F:\Temp\system32\cmd.exe.
It looks like cmd.exe of Windows Vista/7/8/8.1/10/11 reads the value of ComSpec only once and keeps its value in memory for further usage without reading the environment variable a second time on string value for the default command interpreter being already in its internal memory.
That is quite clever in my opinion. The string value of ComSpec is read only once from the environment variable on first usage and then is used that string internally on further usage because of the value of the environment variable ComSpec changes usually never as long as cmd.exe is running.
It looks like cmd.exe of Windows XP has nearly the same caching mechanism for the string value of the environment variable ComSpec. The difference is that cmd.exe of Windows XP reads the value of ComSpec already on starting it and not on first usage and so all changes done on local environment variable ComSpec of an already running cmd.exe have no effect on the execution of one more cmd.exe on processing a for /F loop with a command line to execute, capturing the output and processing it as I could find out with further tests on German Windows XP.
I have a requirement where i need to delete the contents of the temp folder on number of remote windows machines.
i tried below wmic command to delete
WMIC /node:...** /user:xxxx /password:xxxx path cim_datafile WHERE "path='%Winddir%\temp*.tmp' AND Extension ='tmp'" delete**
But it throws an error saying
ERROR:
Description = The RPC server is unavailable.
Please suggest me a way to delete temp folder contents on remote machine.
Most simple way - if you're not strictly forced to use WMI, you can do that with psexec:
PsExec.exe \\<computer> cmd /c "rmdir /s /q %windir%\temp\"
or, if you're not logged into domain admin or global workstations admin account -
PsExec.exe -u <user> -p <password> \\<computer> cmd /c "rmdir /s /q %windir%\temp\"
If should not completely delete the folder since Windows keeps some files open and locked inside it, but anything not read-only or locked would be deleted, both files and folders.
Then, to do this with a list of computers, just use a cmd file like this (list.txt contains just computer names/ips, without \:
for /F %%s in (list.txt) do (
echo %%s
start "" /min PsExec.exe \\%%s cmd /c "rmdir /s /q %windir%\temp\"
)
Start command makes all psexec processes run in parallel and minimized so you don't have to wait for each computer to finish before starting another
psexec.exe is a part of sysinternals package from M. Russinovich, I'd like to leave a direct link but don't know if it's permitted or not.
I think it should be able to connect to remote pcs if you have access to file shares and remote computer management (and admin rights of course)
I've been working on a batch file all day, that I can't get to work open through GPO (another day, another question). So I decided to do it manually with every computer. I have two exe's and one MSI. The exe's work perfectly fine. They get installed, and it all works out. The MSI, however, doesn't. It gives me the error: the installation package could not be opened. Verify that the package exists and that you can access it, or contact the application vendor to verify that this is a valid Windows Installer package.
Now when I go to the network share and use it from there, it works perfectly fine. So there must be an issue with my code.
Here's the code:
#echo off
IF NOT EXIST "C:\Program Files (x86)\Citrix\ICA Client\" (
pushd "\\KOPI-DC01\ACCURO Cloudwerx\ACCURO\1\"
.\CitrixReceiver-4.4.1000.exe /silent
)
IF NOT EXIST "C:\Program Files (x86)\triCerat\Simplify Printing\ScrewDrivers Client v4\" (
pushd "\\KOPI-DC01\ACCURO Cloudwerx\ACCURO\2\"
msiexec.exe /i ".\Screwdriver.msi"
)
IF NOT EXIST "C:\Program Files\Cloudwerx\CloudwerxPlugin\" (
pushd "\\KOPI-DC01\ACCURO Cloudwerx\ACCURO\3\"
.\cloudwerx-setup.exe /silent
)
pause
Any help would be greatly appreciated, thanks.
I am guessing that your problem is the distinction in powershell between the current location (set by the pushd command) and the working directory (unaffected by the pushd command). You can see the working directory of the powershell process using the [Environment]::CurrentDirectory property:
# C:\> [Environment]::CurrentDirectory = "c:\"
# C:\> [Environment]::CurrentDirectory
c:\
# C:\> pushd C:\Temp
# C:\Temp> [Environment]::CurrentDirectory
c:\
# C:\Temp> Get-Location
Path
----
C:\Temp
WHat is probably happening is that msiexec.exe is using the working directory (i.e. [Environment]::CurrentDirectory) and not the current powershell location at invocation. I would just specify the full path to msiexec:
msiexec.exe /i "\\KOPI-DC01\ACCURO Cloudwerx\ACCURO\2\\Screwdriver.msi"
MSI installation packages build with an older WIX utility would throw the error whenever installation was attempted from a batch script that was accessed on a shared drive using UNC path instead of a mapped drive letter. On the other hand whenever the batch file was executed with a mapped drive letter the installation would work normally.
I'm not blaming WIX here because I'm not certain whether they are responsible. I'm just describing symptoms here. It might just be the result of invoking plain vanilla Windows batch script that in turn executes msiexec with a bunch of command line parameters.
I am writing a batch script to use USMT to update computers from XP to 7. Because USMT has a scanstate component that needs to be run before the OS upgrade and a loadstate computer that has to be run after the OS upgrade I am trying to use an if statement to check what the operating system is and then run the proper commands. I am new to batch files but from everything I have been reading it seems like I am writing it properly but I am obviously messing up somewhere. I am getting a "Windows is unexpected at this time error." I also know that the variables are being set properly because of the pause commands that I included. I also tried using IF %WINVERSION% == %XP% goto XPTRUE/WIN7TRUE and enclosing everything within the brackets under a :XPTRUE/WIN7TRUE but that gives the same error.
::Don't have commands print...only outputs are printed
#echo off
:: Set constants
SET XP=Microsoft Windows XP [Version 5.1.2600]
SET WIN7=Microsoft Windows [Version 6.1.7601]
SET XPUSMTLOCATION=C:\Program Files\USMT\Binaries\v4\x86
SET 7USMTLOCATION=C:\Program Files (x86)\USMT\Binaries\v4\amd64
SET BACKUPLOACTION=\\[SERVER IP]\z$\UserAccountBackUps\Backups
SET LOCALBACKUPLOCATION=C:\Backup\USMT
SET NASBACKUPLOCATION=S:\UserAccountBackUps\Backups
#PAUSE
::Get the current version of Windows batch file is running on and store it in WINVERSION
FOR /f "delims=" %%A IN ('ver') DO #SET WINVERSION=%%A
echo %WINVERSION%
PAUSE
::Get the MAC address of the computer and store it in MACA
FOR /F %%A IN ('getmac') DO #SET MACA=%%A
echo The MAC Address is: %MACA%
:: Tell user about script
echo This is a script designed to migrate computers with one network card from Windows XP to Windows 7 using USMT, this script should not be used with computers that have multiple network cards
echo Xp is %XP%
echo 7 is %WIN7%
::Check to see if the current version is XP
PAUSE
IF %WINVERSION% == %XP% (
echo This is windows XP
::Change directory to the location of USMT files
cd %XPUSMTLOCATION%
::Run scanstate to create backup
scanstate.exe C:\Backup /i:"\\[SERVER IP]\z$\UserAccountBackUps\USMT_XML_Files\MigApp.xml" /i:"\\[SERVER IP]\z$\UserAccountBackUps\USMT_XML_Files\MigDocs.xml" /i:"\\[SERVER IP]\z$\UserAccountBackUps\USMT_XML_Files\MigUser.xml" /o /v:2
::Change directory to the location of where the USMT backup is
cd %LOCALBACKUPLOCATION%
::Rename the backup to the MAC Address
rename USMT.MIG %MACA%.MIG
::Map the NAS to a drive because xcopy can not take IP addresses
echo Mapping NAS to drive
::NAS is mapped to drive S, if S is used for something else change s below to different letter
net use s: \\[SERVER IP]\z$
echo Prepairing to copy backup to NAS
::Use xcopy to transfer backup file the /v ensures the files are identical
::This must be done this way because if USMT tries to backup directly to the NAS it tries to overwrite all existing files
xcopy %LOCALBACKUPLOCATION%\%MACA%.MIG %NASBACKUPLOCATION% /v
echo The copy has completed, run this batch file again after OS Upgrade
)
IF %WINVERSION% == %WIN7% (
echo This is Windows 7
PAUSE
)
When I run this on my Windows 7 computer I get this:
I get the same output on my XP computer except it tells me the current version is xp instead. Help would be greatly appreciated.
The line below:
FOR /f "delims=" %%A IN ('ver') DO #SET WINVERSION=%%A
stores in WINVERSION variable a string that contain several words separated by spaces, for example:
SET WINVERSION=Microsoft Windows [Version 6.2.9200]
This way, the line below:
IF %WINVERSION% == %XP% (
is expanded to:
IF Microsoft Windows [Version 6.2.9200] == Microsoft Windows XP [Version 5.1.2600] (
that, of course, cause a syntax error! Type: IF /? for further details.
The way to compare two strings that may contains spaces, is enclosing they in quotes:
IF "%WINVERSION%" == "%XP%" (
Is it possible to set a environment variable at the system level from a command prompt in Windows 7 (or even XP for that matter). I am running from an elevated command prompt.
When I use the set command (set name=value), the environment variable seems to be only valid for the session of the command prompt.
The XP Support Tools (which can be installed from your XP CD) come with a program called setx.exe:
C:\Program Files\Support Tools>setx /?
SETX: This program is used to set values in the environment
of the machine or currently logged on user using one of three modes.
1) Command Line Mode: setx variable value [-m]
Optional Switches:
-m Set value in the Machine environment. Default is User.
...
For more information and example use: SETX -i
I think Windows 7 actually comes with setx as part of a standard install.
Simple example for how to set JAVA_HOME with setx.exe in command line:
setx JAVA_HOME "C:\Program Files (x86)\Java\jdk1.7.0_04"
This will set environment variable "JAVA_HOME" for current user. If you want to set a variable for all users, you have to use option "/m" (or -m, prior to Windows 7).
Here is an example:
setx /m JAVA_HOME "C:\Program Files (x86)\Java\jdk1.7.0_04"
Note: you have to execute this command as Administrator.
Note: Make sure to run the command setx from an command-line Admin window
If you set a variable via SETX, you cannot use this variable or its changes immediately. You have to restart the processes that want to use it.
Use the following sequence to directly set it in the setting process too (works for me perfectly in scripts that do some init stuff after setting global variables):
SET XYZ=test
SETX XYZ test
For XP, I used a (free/donateware) tool called "RAPIDEE" (Rapid Environment Editor), but SETX is definitely sufficient for Win 7 (I did not know about this before).
System variables can be set through CMD and registry
For ex. reg query "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" /v PATH
All the commonly used CMD codes and system variables are given here: Set Windows system environment variables using CMD.
Open CMD and type Set
You will get all the values of system variable.
Type set java to know the path details of java installed on your window OS.
SetX is the command that you'll need in most of the cases.Though its possible to use REG or REGEDIT
Using registry editing commands you can avoid some of the restrictions of the SetX command - different data types, variables containing = in their name and so on.
#echo off
:: requires admin elevated permissions
::setting system variable
REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" /v MyVar /D MyVal
::expandable variable
REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" /T REG_EXPAND_SZ /v MyVar /D MyVal
:: does not require admin permissions
::setting user variable
REG ADD "HKEY_CURRENT_USER\Environment" /v =C: /D "C:\\test"
REG is the pure registry client but its possible also to import the data with REGEDIT though it allows using only hard coded values (or generation of a temp files). The example here is a hybrid file that contains both batch code and registry data (should be saved as .bat - mind that in batch ; are ignored as delimiters while they are used as comments in .reg files):
REGEDIT4
; #ECHO OFF
; CLS
; REGEDIT.EXE /S "%~f0"
; EXIT
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment]
"SystemVariable"="GlobalValue"
[HKEY_CURRENT_USER\Environment]
"UserVariable"="SomeValue"
Just in case you would need to delete a variable, you could use SETENV from Vincent Fatica available at http://barnyard.syr.edu/~vefatica.
Not exactly recent ('98) but still working on Windows 7 x64.