I've been experiencing a frustrating issue with Windows Run as Administrator. I have a program A which needs to be run as administrator. I also have a program B which is used to manage dependencies of other programs (mainly it creates Command Shells with the right environment variables). Now I don't have control over the B program, but for some reason it creates the Command Shell under a non-admin user even if I run it as admin. So when I start program A from the command shell, it fails because it doesn't run as admin. If I use the runas command to run it as admin, or if I set A's properties to always run as admin, when it starts it doesn't start in the environment created by B, so it doesn't get the PATH (and other environment vars). Does someone know if there is a way to use the runas command while preserving the current environment variables?
Have you tried the /env switch?
c:\>runas /?
[...]
/env to use current environment instead of user's.
[...]
Related
There are a lot of questions already asking similar things but none helped me:
Start new cmd.exe and NOT inherit environment?
Is there a command to refresh environment variables from the command prompt in Windows?
What i'm f.e. after is:
Create a batch- oder powershell script which
installs python to a system where python isn't installed (this works)
after a successful installation, run python with a python script as argument
(It should also work the same way for installing and using other apps like MSVC, git for windows, ...)
After installing python from a console, the path which has been added to the system environment variables isn't reflected in the current cmd instance environment.
But it's there when i start a new cmd or elevated cmd manually from the windows start menu and not from a script.
I tried the following without luck to update the environment of the existing console or create a new instance with the new user environment from script:
start /i/b&exit
start /i/b "%windir%\explorer.exe" "%windir%\system32\cmd.exe"
powershell -Command Start-Process -UseNewEnvironment -Wait -FilePath python -ArgumentList "test.py"
But for UseNewEnvironment it's documented that
the new process starts only containing the default environment
variables defined for the Machine scope. This has the side effect that
the $env:USERNAME is set to SYSTEM. None of the variables from the
User scope are included
and for start /i that
Ignore any changes to the current environment, typically made with SET. Use the original environment passed to cmd.exe
I think both approaches cannot be used for what i'm after.
Is there a simple possibility to automatically run a script in the new environment which the installer created without extensive code or third party binaries?
Ahead of time I am a newb at programming/scripting. I mainly research what I want and just edit it to fit my needs when possible.
Environment:
Windows 7
CMD
Usergroup = admin
Occurs when launching as user(admin) or launching cmd as administrator
When I use CMD to change an environment setting, it does not save to the system.
Example:
C:\Users\admin>SET TESTVARIABLE = "This is a test"
C:\Users\admin>SET
TESTVARIABLE = "This is a test"
C:\Users\admin>_
close out cmd, reopen, use SET and the testvariable is no longer there.
Going through System > Advanced System Settings > Environment Variables > System Variables is the only way I can positively make changes to the variables.
This is also affected by any .bat files I make. Mine don't actually get applied when they run but other peoples that I copy(entire .bat file, not just text/context).
This is occuring on my (all at work) desk pc(win10) and 2x Remote Desktop (win7). I am admin and I'm using admin users on these RDP's.
Anyone have any idea what is happening, what i'm missing, how I can research it or fix it?
Variables set using the "set" command are only available in the cmd's instance. To save variables persistently see this: Set a persistent environment variable from cmd.exe
I just installed scala but I can't call it from the command line. So I dutifully checked my path through the environmental variables of the control panel and saw the scala folder present. If I type scala from cmd within that folder, it works fine.
So I tried echo %PATH% from windows cmd to see any problem. If running a normal command window, I get almost the same path except it's missing the scala path item. If I run the command line (Admin), then the echoed path matches the environment variables version. Under this admin setting, scala works fine.
There is no user path variable defined, it's only a system variable.
I've never seen this before. Why is there a difference between admin path and non-admin path? And how do I access the scala path item from the non-admin command line?
Thanks!
I just had the same problem, it was caused by the environment variables not being refreshed. A reboot would have solved it, however there is a way to refresh the environment variables without a reboot.
Open cmd prompt window
Input set PATH=C
close and restart cmd prompt window
input echo %PATH% to check
This worked for me in Windows 10.
I'm using this new machine, so as usual I go and set the execution policy so that I can use my profile script, after doing that however powershell now opens all batch files in a new cmd.exe window.
I tried undoing this step but it's still the same so I think it has nothing to do with the script execution policy, also I still have the powershell window in which I originally set the execution policy and this one behaves normally, only new windows have this problem.
I may have installed some software, but nothing is related to windows, and I tried setting the PATH variable to its exact value in the working window but it does not work.
Batch files will open in a new window if the PATHEXT environment variable does not contain '.BAT' as one of the executable extensions.
To check the variable, enter the following at the PowerShell prompt: $env:PATHEXT
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.