I'm building an MSI installer for windows and sign the installer using signtool. When I run the .msi to test it, the UAC (User Account Control) prompt shows up to ask me if I want to allow the installation to proceed. That's fine, but the prompt shows a number of fields, and for the Program Name field it displays something like "403b3.msi". This is not the name of the msi I'm running.
How can I get the correct Program Name to be displayed?
Use the /d command line argument with the required program name when executing signtool to sign the msi.
It appears that the windows installer creates a temporary copy of the msi file and assigns it a generated name before running it. If you don't use /d with signtool, you get to see the temporary filename which isn't very useful for your users.
this is an applied version of #Scott-langham's comment.
this was directly from the PostBuildEvent of a visual studio installer project - VDPROJ file
set signtool="C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\signtool.exe"
set timestampurl=http://timestamp.digicert.com
set certpath="$(ProjectDir)CodeSigningCert.pfx"
:: Setup in your user environment variables
:: using something with low sort order to force off screen ZZCODECERTPASSWORD
if []==[%ZZCODECERTPASSWORD%] (
echo must set code signing certificate in ZZCODECERTPASSWORD environment variable. stopping build.
exit /b 2
)
:: need the filename with extension that is being generated
FOR /f %%i IN ("$(BuiltOuputPath)") DO (
SET outputfilename=%%~nxi
)
%signtool% sign /t %timestampurl% /f %certpath% /p %CODECERTPW% /d %outputfilename% "$(BuiltOuputPath)"
IF ERRORLEVEL 1 (
echo failed to sign MSI
exit /b 3
)
%signtool% sign /t %timestampurl% /f %certpath% /p %CODECERTPW% "$(ProjectDir)$(Configuration)\Setup.exe"
IF ERRORLEVEL 1 (
echo failed to sign boostrap setup EXE
exit /b 4
)
Related
I have created a code in batch, which works perfectly only when I run it as administrator. If not, some of the main functions of the code does not work.
On top of that, I would like to convert it to exe, so that I can put an icon on.
Can anyone tell me please, how can I convert a batch file to exe with administrator privileges? If it is possible without uac prompt?
By the way: I am administrator on my PC.
I have tried with some software:
Iexpress -> Temp-file was not found.
Bat to Exe Converter -> After starting the .exe file it does not run as administrator, although I run it as.
That's the code:
#echo off
start "" "C:\Users\Viktor\Documents\FreeFileSync Auftraege\RealTimeSync Auftraege\RealTime_(.minecraft-GoogleDrive)_[Mirror].ffs_real"
start "" "C:\Users\Viktor\Documents\FreeFileSync Auftraege\RealTimeSync Auftraege\RealTime_(.minecraft-Backupfolder)_[Mirror].ffs_real"
start "" "C:\Program Files (x86)\Minecraft\MinecraftLauncher.exe"
:Anfang
tasklist /v | find "MinecraftLauncher.exe"
if %errorlevel% == 1 goto Dead
tasklist /FI "IMAGENAME eq javaw.exe" 2>NUL | find /I /N "javaw.exe">NUL
if %errorlevel% == 0 goto Active
goto Anfang
:Active
tasklist /v | find "javaw.exe"
if %errorlevel% == 1 goto Dead
goto Active
:Dead
timeout 5
taskkill /F /IM "RealTimeSync_x64.exe"
exit
It works only with "run as administrator". Without, some functions like taskkill or tasklist does not work.
I succeeded with Bat to Exe Converter available here : https://www.majorgeeks.com/files/details/bat_to_exe_converter.html
Simple GUI to transform batch to exe with administrator privileges.
Here is how you can make your .bat to .exe file require administrator privileges to run:
Download Bat To Exe Converter from Softpedia.com:
https://www.softpedia.com/get/System/File-Management/Batch-To-Exe-Converter.shtml (Version 3.2 seems to be a good option due to it's easy layout/interface.)
Once downloaded, go through the install the application and run said application.
Input code into the IDE window, ensuring that you check the box (under the options tab) that says "Request Administrator Privileges"
Now click convert, and continue through the prompts and you will have your .exe file ready for use!
I wrote a batch file script in order to copy shortcut from the local network to the user desktop station. everything is working perfect except that the shortcut that is copied to the user desktop is without his icon. I have no experience writing batch files, i will be grateful if someone can advice me how to solve that issue.
that is the script:
#echo off
setlocal
set alias=Reg query "HKLM\Software\Microsoft\NET Framework Setup\NDP"
FOR /F "TOKENS=6 DELIMS=\." %%A IN ('%alias%') DO set .NetVer=%%A
if [%.NetVer] ==[] GOTO noDotNet
if EXIST C:\Users\%USERNAME%\Desktop\Partner_Projects_System.lnk GOTO ShortCutAllreadyExist
if not exist "\\netapp2\public\all\INTERNET PROJECTS\PMS_Shortcut_noWhite\Partner_Projects_System.lnk" GOTO noPermissionToDir
copy "\\netapp2\public\all\INTERNET PROJECTS\PMS_Shortcut_noWhite\Partner_Projects_System.lnk" "C:\Users\%USERNAME%\Desktop"
:loop
ping -n 1 -w 3000 1.1.1.1 > nul
IF EXIST C:\Users\%USERNAME%\Desktop\Partner_Projects_System.lnk (
GOTO startApp
) ELSE (
GOTO loop
)
EXIT
pause
:noDotNet
msg "%username%" DOTNET Framework is not installed on your machine please contact partner helpdesk team
EXIT
:noPermissionToDir
msg "%username%" you need to have read and write permission to the path \\netapp2\public\all\INTERNET PROJECTS\ please contact partner helpdesk team
EXIT
:ShortCutAllreadyExist
msg "%username%" the shortcut is allredy exist on the desktop
EXIT
:startApp
msg "%username%" SHORTCUT TO PROJECT MANAGMENT SOFTWARE WAS CREATED ON YOUR DESKTOP
start C:\Users\%USERNAME%\Desktop\Partner_Projects_System.lnk
A shortcut can specify a separate path to a icon that is different from the actual shortcut target. If this path is not valid on the new machine the icon might not display correctly.
You cannot manipulate shortcuts with a batch file but you can with Windows Scripting Host. Try this script to print the shortcut properties.
I have to execute the ewfmgr.exe which can be executed only when the Command window is opened as an Admin.
If I go to Start->type cmd.exe->Right click->Run as Administrator then the following Comand prompt windows appear. In this window, if I write ewfmgr.exe (which the EXE file that I have to execute), then the command is executed without any problem.
MY REQUIREMENT: My requirement is to execute the command through a script file (RunasAdmin.cmd file) and this script file will be executed through an NSIS Installer.
Since, the ewfmgr.exe can be executed only with Admin, so I have to escalate my script to get Admin rights. For this, I have the following script:
Script to Get Admin Right: "(RunasAdmin.cmd)"
::::::::::::::::::::::::::::::::::::::::::::
:: Elevate.cmd - Version 4
:: Automatically check & get admin rights
::::::::::::::::::::::::::::::::::::::::::::
#echo off
CLS
ECHO.
ECHO =============================
ECHO Running Admin shell
ECHO =============================
:init
setlocal DisableDelayedExpansion
set cmdInvoke=0
set winSysFolder=System32
set "batchPath=%~0"
for %%k in (%0) do set batchName=%%~nk
set "vbsGetPrivileges=%temp%\OEgetPriv_%batchName%.vbs"
setlocal EnableDelayedExpansion
:checkPrivileges
NET FILE 1>NUL 2>NUL
if '%errorlevel%' == '0' ( goto gotPrivileges ) else ( goto getPrivileges )
:getPrivileges
if '%1'=='ELEV' (echo ELEV & shift /1 & goto gotPrivileges)
ECHO.
ECHO **************************************
ECHO Invoking UAC for Privilege Escalation
ECHO **************************************
ECHO Set UAC = CreateObject^("Shell.Application"^) > "%vbsGetPrivileges%"
ECHO args = "ELEV " >> "%vbsGetPrivileges%"
ECHO For Each strArg in WScript.Arguments >> "%vbsGetPrivileges%"
ECHO args = args ^& strArg ^& " " >> "%vbsGetPrivileges%"
ECHO Next >> "%vbsGetPrivileges%"
if '%cmdInvoke%'=='1' goto InvokeCmd
ECHO UAC.ShellExecute "!batchPath!", args, "", "runas", 1 >> "%vbsGetPrivileges%"
goto ExecElevation
:InvokeCmd
ECHO args = "/c """ + "!batchPath!" + """ " + args >> "%vbsGetPrivileges%"
ECHO UAC.ShellExecute "%SystemRoot%\%winSysFolder%\cmd.exe", args, "", "runas", 1 >> "%vbsGetPrivileges%"
:ExecElevation
"%SystemRoot%\%winSysFolder%\WScript.exe" "%vbsGetPrivileges%" %*
exit /B
:gotPrivileges
setlocal & pushd .
cd /d %~dp0
if '%1'=='ELEV' (del "%vbsGetPrivileges%" 1>nul 2>nul & shift /1)
::::::::::::::::::::::::::::
::START
::::::::::::::::::::::::::::
REM Run shell as admin (example) - put here code as you like
ewfmgr c: -enable
pause
cmd /k
PROBLEM: If I execute the script (RunasAdmin.cmd) just by double clicking on it, the script is executed and get the task done without any error. But if I execute the script (RunasAdmin.cmd) through my NSIS installer (EWFMGR_Run.exe) then, I get an error that ewfmgr is not recognised as an internal or external command
NSIS Installer Code: (EWFMGR_Run.exe)
OutFile "EWFMGR_Run.exe"
section
ExecWait "D:\Disk\RunasAdmin.cmd"
sectionEnd
The Command window opened by NSIS installer after running the script (RunasAdmin.cmd) is following:
Queston: Both the command windows are opened as Admin and are into the same working directory. But how come the window opened by NSIS installer is not able to find ewfmgr.exe?
UPDATE-1: Bascially the problem is in the CMD window opened by the NSIS installer. Even if I move to the path C:\Windows\System32 manually using cd /D C:\Windows\System32 and try to execute ewfmgr.exe (which is available in that path), CMD does not recognize it.
References: The script file to elevate to Admin has been taken from Matt's answer given here.
What must be at least taken into account on elevating a command script (batch file) to administrator level?
The current directory changes in any case to %SystemRoot%\System32.
The environment could change completely if the current user is not in administrator group and therefore the user has to use a different user account to run the batch file with elevated privileges of an administrator, for example the local administrator account must be used instead of current user account. This affects environment variables and permissions on network resources.
The script is started initially always in environment of parent process which is on 64-bit Windows the 32-bit environment instead of the 64-bit environment in case of parent process is a 32-bit application.
The script could be executed with one or more arguments enclosed in double quotes which should be passed right to the script on execution with elevated privileges.
How to handle those 4 points?
1. Current directory
Many command line scripts (batch files) are coded to work with current directory and assume that the current directory is the same directory as the batch file. That the current directory is the same directory in which the batch file is stored is true on double clicking on a batch file stored on a local drive or a network drive, except the execution of batch files from network drives is disabled by security settings.
But Windows sets %SystemRoot%\System32 as current directory on running a cmd script as scheduled task using system account.
And Windows sets %SystemRoot%\System32 as current directory on using RunAs to run a cmd script with elevated administrator privileges.
And Windows sets %SystemRoot% as current directory after printing into console window the message below on executing a batch file with a double click which is stored on a network share opened using UNC path.
'\server\share\directory'
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported. Defaulting to Windows directory.
Using UNC paths as current directory could be enabled as described for example by an answer on How to run batch file from network share without "UNC path are not supported" message?
The best would be to write the entire script code to work independent on which directory is the current directory.
That means not using just the file name of a referenced file, but "Full path to\FileName.exe", i.e. the file name with file extension and with full path enclosed in double quotes.
In case of all files to run or referenced from within a cmd script are stored in an unknown folder, but are always in same folder as the cmd script, the simple method to get path for all files is using the command line:
set "SourceFolder=%~dp0"
%~dp0 expands to path of the batch file always ending with a backslash and never being enclosed in double quotes even if the folder path contains a space character or other command line syntax critical characters like an ampersand.
Then all files are referenced with using
"%SourceFolder%FileName.exe"
Note: There is no backslash (directory separator on Windows) as the environment variable SourceFolder holds the folder path already with a backslash at end.
Of course it is also possible to use cd /D "%~dp0" to set current directory to the directory of the cmd script, but this does not work for UNC paths.
But there is also the command pushd "%~dp0" working also with UNC paths if command extensions are enabled as by default.
For details on the commands CD and PUSHD run in a command prompt window cd /? and pushd /? and read the output help.
2. Environment variables
Windows creates a copy of the currently active environment table of current process whenever a new process is created.
But this is not the case when a batch file elevates itself to administrator level. Therefore it is not possible to define environment variables on initial run of a batch file, then elevate to administrator level, and access now the environment variables as defined before in initial environment. It could even happen that the batch file was initially executed in 32-bit environment on 64-bit Windows on initial execution, but runs in 64-bit environment after elevation to administrator level.
So everything which needs to be passed from initial execution to elevated execution must be parsed via command line arguments or via a file on a local drive fully accessible in all environments, i.e. for everyone.
3. 32-bit versus 64-bit environment
Sometimes a 32-bit installer is used for installing either a 32-bit or a 64-bit application depending on bit width of Windows because of running on all Windows. The batch file is processed by 32-bit cmd.exe in 32-bit environment on using a 32-bit installer even when executed on a 64-bit Windows.
At least the following three Microsoft articles should be studied carefully before reading further:
File System Redirector
WOW64 Implementation Details
Registry Keys Affected by WOW64
It is definitely no good idea to depend on value of environment variable PROCESSOR_ARCHITECTURE as its value is x86 when a 32-bit process is executed on 64-bit Windows in 32-bit environment.
It is also not good to query the architecture of the processor directly from Windows registry. It is not guaranteed that there is a 64-bit Windows running on a computer with a 64-bit CPU. It is not often done, but nevertheless possible to use 32-bit Windows on a computer with a 64-bit processor on main board.
The environment variable ProgramFiles(x86) is not defined by default on 32-bit Windows as it is on 64-bit Windows which can be used to determine if a command file script is running on 32-bit or 64-bit Windows.
And the file %SystemRoot%\Sysnative\cmd.exe exists only for 32-bit processes running in 32-bit environment on 64-bit Windows because of special alias Sysnative existing only for a 32-bit process in 32-bit environment on 64-bit Windows which can be used to determine in which environment the batch file is currently running.
4. Passing arguments
It is easy to elevate a batch file executed without any arguments to elevated administrator level.
It is also no problem to pass simple arguments which do not need to be enclosed in double quotes to batch file running elevated.
But passing one or more arguments containing at least one space character or one of these characters &()[]{}^=;!'+,`~<|> which require enclosing the argument string in double quotes is really not easy, especially on creating a Visual Basic script from within a batch file to elevate to administrator level.
It is a real nightmare to try to encode double quotes in batch file correct to be passed via the VB script to the same batch file executed with elevated privileges. Most solutions provided in World Wide Web simply don't support double quoted parameters. Matt's Elevate.cmd - Version 4 is no exception. Running a batch file using this code with "%ProgramFiles%\Installation Folder" as first argument results on initial execution in "C:\Program Files\Installation Folder" being the first and only argument and on elevated execution after removing argument ELEV in the three arguments C:\Program, Files\Installation and Folder.
5. Possible solution for this task
For this task a 32-bit NSIS installer is calling a command line script which must elevate itself to administrator level and should run on 64-bit Windows in 64-bit environment instead of 32-bit environment as on initial run.
I have once analyzed the batch and VB script code of Matt's Elevate.cmd - Version 4, have removed all useless code, have enhanced it to support also arguments enclosed in double quotes using a much easier method than other posted, and have commented the code completely so that others can also understand it for answering UNC paths as current directories in batch file where admin rights are requested.
The batch script posted there is written to work independent on what is the current directory for working also with batch file being executed from a network share using UNC path which of course works only if the network share is still accessible according to permission settings of the share after elevation to administrator level. I found out today after a comment by Richard on his answer on Open Command Window in Windows x64 mode that the web page SS64 - Run with elevated permissions contains nearly the same code as I developed without having ever read the code there.
The adapted batch file code below should work for this task. It expects the executable ewfmgr.exe in same directory as the cmd script or ewfmgr.exe is specified with full path as first argument on executing the script in case of being in a different directory.
#echo off
setlocal EnableExtensions DisableDelayedExpansion
cls
rem Define as application to run by default the file ewfmgr.exe in folder
rem of the batch file which can be a folder on a local drive or on a
rem network drive or even a UNC path.
set "AppToRun=%~dp0ewfmgr.exe"
set "vbsGetPrivileges=%TEMP%\OEgetPriv_%~n0.vbs"
rem The console application NET with parameter FILE can be executed
rem successfully only if the account used for running this batch file
rem has local administrator privileges. See the Microsoft documentation
rem https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-xp/bb490702(v=technet.10)
rem for details about NET FILE.
rem The output written to handle STDOUT on successful execution is redirected
rem to device NUL to suppress it. The exit code of NET assigned to ERRORLEVEL
rem is in this case 0 indicating a successful execution.
rem But on a failed execution because of not having administrator
rem privileges NET outputs to handle STDERR the two error messages
rem "System error 5 has occurred." and "Access is denied." which
rem are redirected from handle STDERR to device NUL to suppress them.
rem And exit/return code of NET is 1 indicating a failed execution.
rem Read https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-xp/bb490982(v=technet.10))
rem for details about using command redirection operators.
%SystemRoot%\System32\net.exe FILE >nul 2>nul
if not errorlevel 1 goto RunMainCode
if "%~1" == "ELEV" (
rem This condition is just for safety. If the batch file was started
rem already a second time with ELEV as first parameter and execution
rem of NET FILE failed nevertheless because of missing permissions,
rem the batch file outputs an error message, waits for any key press
rem by the user to make sure that the user had the chance to read the
rem error message and then exits the batch file processing without
rem doing anything at all.
echo %~nx0 should run already with elevated privileges, but it isn't.
echo/
echo Press any key to exit %~nx0 without doing anything ...
pause >nul
goto :EOF
)
rem This batch file can be started without any parameter resulting in %* being
rem expanded to nothing which results in environment variable BatchArgs being
rem deleted if already existing or with ewfmgr.exe with full path as parameter
rem which must be enclosed in double quotes in case of path containing
rem one or more spaces.
rem As the batch file needs to be executed once again in a separate command
rem process running as local administrator for full access at least on local
rem machine it is necessary to prepare the parameters/arguments list. Each
rem double quote in the arguments list must be doubled to be correct escaped
rem in the VB script file.
rem This is necessary as otherwise running this batch file with
rem "Full path to\ewfmgr.exe"
rem as first parameter would result in execution of the batch file by the
rem Windows Scripting Host as Full path to\ewfmgr.exe without the double
rem quotes as arguments for the batch file and therefore the first parameter
rem is on elevated execution "Full" instead of "Full path to\ewfmgr.exe" as
rem it was initially.
rem Many "run as administrator" solutions which can be found in World Wide Web
rem don't handle parameter strings correct which are enclosed in double quotes
rem because the parameter string has one or more spaces or other critical
rem characters requiring enclosing the parameter string in double quotes.
set "BatchArgs=%*"
setlocal EnableDelayedExpansion
if defined BatchArgs set "BatchArgs= !BatchArgs:"=""!"
rem Everything output by the ECHO command lines within the next command block
rem is redirected into the VB script file created in the folder for temporary
rem files of current user with name of batch file in VB script file name. This
rem makes it possible that multiple batch files with different names can run
rem at the same time using same code for creating a VB script file to run the
rem batch file once again as administrator with elevated privileges.
rem For details on ShellExecute parameters see the Microsoft documentation
rem https://learn.microsoft.com/en-us/windows/win32/shell/shell-shellexecute
rem The tricky part is quoting the arguments list correct which should be
rem finally passed to cmd.exe executed from the VB script. The command process
rem running the batch file with elevated privileges of local administrator
rem should automatically close after execution of batch file finished which
rem is the reason for first argument /C.
rem The second argument is the command to execute by `cmd.exe` which is
rem the batch file name with complete path which must be enclosed in double
rem quotes for safety in case of batch file name or path contains one or more
rem spaces. But additionally the batch file itself must be started with at
rem least two more arguments.
rem The first argument for the batch file is ELEV which is used as indication
rem to detect if this batch file is already started a second time via the
rem VB script using local built-in administrator account.
rem The second argument for the batch file is the application to
rem run with full default path which is the batch file folder.
rem And last all parameters passed to this batch file on initial run should
rem be also passed to second execution of this batch file under the different
rem environment of local built-in administrator account.
rem This nesting of batch file arguments in command processor arguments written
rem into a VB script file which requires additionally escaping each double quote
rem within a string with one more double quote results in a strange syntax for
rem the line to write into the VB script file.
(
echo Set UAC = CreateObject^("Shell.Application"^)
echo UAC.ShellExecute "%SystemRoot%\System32\cmd.exe", "/C """"%~f0"" ELEV ""!AppToRun!""!BatchArgs!""", , "runas", 1
)>"%vbsGetPrivileges%"
endlocal
rem Now the created VB script file can be executed with Windows Script Host.
rem Then the VB script file can be deleted as no longer needed and processing
rem of this batch file under current user account ends resulting in returning
rem to command process which results in closing the console window if not
rem executed by cmd.exe started with option /K to keep the console window
rem opened like on opening a command prompt window and running this batch
rem file from within the command prompt window.
%SystemRoot%\System32\WScript.exe "%vbsGetPrivileges%"
del "%vbsGetPrivileges%"
endlocal
goto :EOF
rem Here starts the main code of the batch file which needs to be
rem executed with elevated privileges of a local administrator.
rem First is checked if the first parameter of the batch file is ELEV
rem which indicates that this batch file was started a second time
rem using administrator privileges or local administrator account.
:RunMainCode
if "%~1" == "ELEV" (
rem In this case the second argument is the application to run with
rem batch file folder passed from initial run to this second run of
rem the batch file. The current directory is now not anymore the initial
rem current directory, but %SystemRoot%\System32 as set by Windows on
rem starting a command process using RunAs and administrator account.
rem This must be taken into account on further batch file processing.
rem For this batch file it does not matter what is the current directory
rem as it is written to work with path of the application to run defined
rem on starting the batch file (initially). So there is no need to use
rem CD /D "%~dp0" or PUSHD "%~dp0" as many "run as administrator"
rem solutions use to change the current directory to directory of the
rem batch file. There is also no need for CD /D "%~2" or PUSHD "%~2"
rem here which of course could be also used.
rem The two additionally added arguments ELEV and the application to
rem run are removed from the arguments lists by using twice the
rem command SHIFT to restore the initial arguments list.
set "AppToRun=%~2"
shift /1
shift /1
)
if "%ProgramFiles(x86)%" == "" goto RunApp
if not exist %SystemRoot%\Sysnative\cmd.exe goto RunApp
%SystemRoot%\Sysnative\cmd.exe /C ""%~f0" %*"
endlocal
goto :EOF
rem If this batch file was started (initially) with a parameter string,
rem interpret the first parameter string as application to run with
rem full path if the specified executable file exists at all.
rem Then run the application with full path and its parameters.
:RunApp
if not "%~1" == "" (
if exist "%~1" set "AppToRun=%~1"
)
"%AppToRun%" c: -enable
endlocal
6. Best solution for this task
But it turned out after I finished writing and testing the code above, writing this long answer and before posting it, reading the comment written by Richard on his answer on Open Command Window in Windows x64 mode, the best solution is most likely using the NSIS code as posted at
How do you request administrator permissions using NSIS?
And use in the command script just the few lines at bottom also posted as my answer on Open Command Window in Windows x64 mode to switch from 32-bit to 64-bit environment.
Try modifying RunasAdmin.cmd to use Sysnative instead of System32:
set winSysFolder=Sysnative
I am guessing that EWFMGR_Run.exe is launching a 32 bit cmd window and windows is forcing the c:\windows\syswow64 override on your attempted override of set winSysFolder=System32
According to this article, you should be using the Sysnative virtual folder instead.
The 'Sysnative' folder
As explained above, accessing the 64-bit System32 folder from a 32-bit application by simply inserting "\System32" in the folder path is not possible. A redirection to the SysWOW64 folder is made automatically by the system if you try that. But there is another folder name that can be used instead: Sysnative.
Sysnative is a virtual folder, a special alias, that can be used to access the 64-bit System32 folder from a 32-bit application or script. If you for example specify this folder path in your application's source code:
C:\Windows\Sysnative
the following folder path is actually used:
C:\Windows\System32
I'd like to point to an NSIS specific way about dealing with UAC and elevated rights.
If your NSIS installer needs to run anything with elevated permissions, you have to indicate that in your NSIS script like so:
RequestExecutionLevel admin
Once you do that, when you start the installer, it will pop up the UAC prompt and in succession won't have any problems running external scripts or programs which need elevated permissions.
This is pretty much in line with #5 of Mofi's answer - I still post this one as I think it boils it down to the need-to-know. NSIS seems to be the show-stopper here for you.
For reference:
NSIS - Could not write updated PATH to HKLM
I'm trying to uninstall a program EXE via batch file and am not having any success.
The uninstall string found in the registry is as follows:
C:\PROGRA~1\Kofax\Capture\ACUnInst.exe /Workstation
C:\PROGRA~1\Kofax\Capture\UNWISE.EXE /U
C:\PROGRA~1\Kofax\Capture\INSTALL.LOG
If I run that from CMD or batch it does nothing.
If I run C:\PROGRA~1\Kofax\Capture\UNWISE.EXE /U from CMD it will open up a dialog box to point to the INSTALL.LOG file and then proceed to uninstall.
At the end, it will ask me to click finish.
I need this to be silent, can you point me in the right direction? This is on XP and 7.
Every program that properly installs itself according to Microsoft's guidelines makes a registry entry in either HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall (for machine installs) or HKCU\Software\Microsoft\Windows\CurrentVersion\Uninstall (for user profile installs). Usually, the key for the program will be its GUID, or else the name of the program. Within that key will be an entry called UninstallString. This contains the command to execute to uninstall the program.
If you already know ahead of time what you will be uninstalling, it should be easy enough to just put that in your batch file. It gets tricky when you try to automate that process though. You can use the reg command to get data from the registry, but it returns a lot of text around the actual value of a given key, making it hard to use. You may want to experiment with using VBscript or PowerShell, as they have better options for getting data from the registry into a variable.
This might help you further.....
How to Create a script via batch file that will uninstall a program if it was installed on windows 7 64-bit or 32-bit
I've had the same problem and this is what I came up with.
Before you start using this method though, you might wanna look up the name of the application on WMIC using CMD so..
First you wanna do: WMIC product > C:\Users\"currentuser"\Desktop\allapps.txt
I'd recommend to output the command to an TXT file because it's really confusing to read it in the Cmd prompt, plus is easier to find the data you are looking for.
Now what you wanna do is find the actual name of the app... If you look at the code I put in, the app name says SkypeT because skype has "™" in the end of it and the command prompt can't interpretate that as it is.
After you got the app name, just put in the find in the 4th line and substitute, a few lines which contain my examples with skype...
Also you can probably creat a variable called %APP% and not worry as much, but at it's current it works just fine...
One thing to note! with me the msi /quiet command did not work, the program would not install or uninstall so I used /passive, which lets the users see what's going on.
#Echo off
CD %cd%
:VerInstall
for /f "tokens=12,*" %%a in ('wmic product list system ^| Find /I "SkypeT"') do (
if Errorlevel = 0 (
Echo Skype is installed! )
if Errorlevel = 1 ( Echo Skype is not installed, proceding to the installation!
Ping localhost -n 7 >nul
goto :Reinstall )
)
:Status
tasklist /nh /fi "IMAGENAME eq "APP.exe" | find ":"> nul
if errorlevel = 1 goto :force
goto :Uninstall
:Force
echo We are killing the proccess... Please do not use the application during this process!
Ping localhost -n 7 > nul
taskkill /F /FI "STATUS eq RUNNING" /IM APP* /T
echo The task was killed with success! Uninstalling...
Ping localhost -n 7 > nul
:Uninstall
cls
for /f "tokens=12,*" %%a in ('wmic product list system ^| Find /I "SkypeT"') do (
set %%a=%%a: =%
msiexec.exe /x %%a /passive /norestart
)
:DoWhile
cls
Tasklist /fi "IMAGENAME eq msi*" /fi "STATUS eq RUNNING" | Find ":" >nul
if errorlevel = 1 (
echo Installation in progress
Goto :DoWhile
)
echo Skype is Uninstalled
:Reinstall
msiexec.exe /i SkypeSetup.msi /passive /norestart
:reinstallLoop
Tasklist /fi "IMAGENAME eq msi*" /fi "STATUS eq RUNNING" | Find ":" >nul
if errorlevel = 1 (
echo Installation in progress
goto :reinstallLoop
)
echo Skype is installed
:end
cls
color 0A
Echo Done!
exit
One last thing. I used this as an Invisible EXE task, so the user couldn't interact with the command prompt and eventually close the window (I know, I know, it makes the whole echoes stupid, but it was for testing purposes).for that I used BAT to EXE converter 2.3.1, you can put everything to work on the background and it will work very nicelly. if you want to show progress to users just write START Echo "info" and replace the info with whatever you want, it will open another prompt and show the info you need.
Remember, Wmic commands sometimes take up to 20 seconds to execute since it's querying the conputer's system, so it might look like it's doing nothing at first but it will run! ;)
Good luck :)
We needed a batch file to remove a program and we couldn't use programmatic access to the registry.
For us, we needed to remove a custom MSI with a unique name. This only works for installers that use msi or integrate such that their cached installer is placed in the Package_Cache folder. It also requires a unique, known name for the msi or exe. That said, it is useful for those cases.
dir/s/b/x "c:\programdata\packag~1\your-installer.msi" > removeIt.bat
set /p RemoveIt=< removeIt.bat
echo ^"%RemoveIt%^" /quiet /uninstall > removeIt.bat
removeIt.bat
This works by writing all paths for 'your-installer.msi' to the new file 'removeIt.bat'
It then assigns the first line of that bat file to the variable 'RemoveIt'
Next, it creates a new 'removeIt.bat' that contains the path/name of the .msi to remove along with the needed switches to do so.
Finally, it runs the batch file which executes the command to uninstall the msi. This could be done with an .exe as well.
You will probably want to place the 'removeIt.bat' file into a known writable location, for us that was the temp folder.
When I open cmd on my laptop it is defaulting to the F: drive. This is troubling me does anyone know how it got that way or how to get it back to where it opens to the C: drive by default?
Use the command
C:
To change to the drive C. It would of course work for any drive letter.
Very minor nit: if you're using Windows 7 you don't need the cmdhere powertoy, it's built in to Explorer.
You just navigate to a directory in Windows Explorer then hold down the shift key and right click. "Open command window here" is one of the selections on the context menu.
When it comes to opening cmd.exe in a specific directory, I just create a shortcut to cmd.exe and then in the shortcut properties I set "Start in:" to the drive/directory I want it to start in.
Using a shortcut allows me to customize the cmd.exe windows depending on what I'm using it for. For normal file editing/viewing I use a 180x60 window and appropriate font, but when I want to read/search log files I have a shortcut that opens a 260x100 window with a smaller font. That way I can view most long log file lines without having to use the horizontal scroll.
http://blog.stevienova.com/2007/04/08/change-your-default-cmd-prompt-path/
Sometimes, your path when you go to start->run, CMD will be something
you don’t want. In active directory or on an NT domain, sometimes your
default home path might be a network drive. This isn’t so good when
you are offline or drop offline after being online. The CMD prompt is
set to a place where you can’t get to.
To change the path, you can edit the registry (at your own risk)
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USERSoftwareMicrosoftCommand Processor] “Autorun”=”c:”
This will change the path to your c: drive.
I believe it defaults to %HOMEDRIVE%\%HOMEPATH% so if you can muck about with those environment variables that might be an option. I can't edit these environment variables on my company's network, so I had to use the AutoRun to change it to something sane.
quick answer: cmd /k c:
long answer to make it "automagical":
http://windowsxp.mvps.org/autoruncmd.htm
In RegEdit.exe I created a String:
HKEY_CURRENT_USER\Software\Microsoft\Command Processor\AutoRun
The value I used for AutoRun was "D:"
On the start screen / menu, type in "cmd", right-click it and select "Open File - Location".
In the opened window, right-Click on "Command Prompt" icon, select "Properties", and edit the "Start In" property to your desired path. I used "C:\" as an example
If you are opening it from a shortcut change the working dir for the shortcut.
In addition to the other answers, there's a nice powertoy for XP called "open command window here." It adds an option to your right-click context menu when you click inside a folder to open a command window using that directory as the starting path.
http://www.microsoft.com/windowsxp/Downloads/powertoys/Xppowertoys.mspx
I ran into a similar issue where cmd would always open up in a particular directory (annoying when running scripts which invoke cmd). The best way to deal with this is to edit your autorun settings. Raymond Chen has a nice article about this here:
http://blogs.msdn.com/oldnewthing/archive/2007/11/21/6447771.aspx
The summary is that when you start a command shell, it checks the autorun registry key, and executes the commands stored there. The registry keys it checks are:
HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor\AutoRun
and/or
HKEY_CURRENT_USER\Software\Microsoft\Command Processor\AutoRun
Some answers already mentioned AutoRun as a solution.
But that can be very dangerous, as the AutoRun entry will be executed for any new cmd.exe instance (only pipes ignore the AutoRun).
A simple expample that fails:
cd /d E:\myPath
FOR /F "delims=" %%Q in ('dir') do echo - %%Q
With AutoRun=C:, this shows the content of the current path of drive C:
You can still use AutoRun, but it should be a batch script, that checks if it was called interactive, by FOR/F or by drag&drop.
#echo off
REM *** To enable this script, call it by <scriptName> --install
setlocal EnableDelayedExpansion
REM *** ALWAYS make a copy of the complete CMDCMDLINE, else you destroy the original!!!
set "_ccl_=!cmdcmdline!"
REM *** The check is necessary to distinguish between a new cmd.exe instance for a user or for a "FOR /F" sub-command
if "!_ccl_:~1,-2!" == "!comspec!" (
REM ***** INTERACTIVE ****
REM *** %1 contains only data, when the script itself was called from the command line
if "%~1" NEQ "" (
goto :direct_call
)
endlocal
doskey /macrofile="%~dp0\cmdMacros.mac"
echo ********************************************************************
echo * AutoRun executed from "%~f0"
echo * Macros loaded from "%~dp0\cmdMacros.mac"
echo ********************************************************************
cd /d C:\myPath
) ELSE (
REM *** Called by a FOR command, by an explorer click or a drag & drop operation
REM *** Handle PROBLEMATIC Drag&Drop content, if necessary
endlocal
)
exit /b
:direct_call
if "%~1" == "--install" (
reg add "HKEY_CURRENT_USER\Software\Microsoft\Command Processor" /v "AutoRun" /t REG_SZ /d "%~f0"
exit /b
)
if "%~1" == "--show" (
reg query "HKEY_CURRENT_USER\Software\Microsoft\Command Processor" /v AutoRun
exit /b
)
if "%~1" == "--remove" (
reg DELETE "HKEY_CURRENT_USER\Software\Microsoft\Command Processor" /v AutoRun /f
)
exit /b