Issue with Environment Variables on VM - windows

I am having a weird issue with Environment Variables on a VM or may be there's something that I don't know about them.
I am setting few environment variables through the Azure DevOps release pipeline using the following command.
setx NameOfEnvVar ValueOfEnvVar /m
Post completion of the release pipeline the environment variable is visible through the System Properties -> Environment Variable Window.
However, when I am running the 'set' command from the command line(as Administrator) on the VM the 'NameOfEnvVar' is not showing up.

Related

Switching AWS profile via the AWS CLI in VS Code integrated terminal does not work

My different AWS profiles from various projects are stored in the standard config-file C:\Users\username\.aws\config.
According to the official documentation it should be as easy as executing the following commands in my integrated CMD-prompt terminal in VS Code.
setx AWS_PROFILE default
Using setx to set an environment variable changes the value in all
command shells that you create after running the command.
Next, open a new cmd-terminal session like so:
Checking the caller identity does not show what I expect to see:
aws sts get-caller-identity
An error occurred (ExpiredToken) when calling the AssumeRole
operation: The security token included in the request is expired.
Carrying out the reload window - command did also not resolve the issue:
Next thing I tried was the mere set- instead of the previous setx - command:
Using set to set an environment variable changes the value used until
the end of the current command prompt session, or until you set the
variable to a different value.
Carrying out this leads to the following output:
set AWS_PROFILE default
AWS_PROFILE=profile_name_from_other_project
Even if I delete all open (integrated) CMD-shell after using setx and opening a new one, the profile from the other project is still active:
Finally, I switched to my already open integrated bash - shell in VS Code and executed the command:
export AWS_PROFILE=default
This magically worked:
❯ aws sts get-caller-identity
{
"UserId": "A....",
"Account": "7.....",
"Arn": "arn:aws:iam::7....:user/username"
}
I'm still wondering why I cannot make it work in the integrated VS-Code CMD-terminal..

JMETER_HOME environment variable is not defined correctly but build is successful and the script works fine in Jmeter GUI and cmd prompt

I have created a jmeter jmx script and it is getting executed perfectly in GUI and non GUI mode. I have configured the same in Jenkins but I am getting the build success with an error message as "The JMETER_HOME environment variable is not defined correctly
This environment variable is needed to run this program"
I have also tried setting the JMETER_HOME as E:\apache-jmeter-4.0 in User variables and Path as E:\apache-jmeter-4.0\bin in System Variables and it didn't work.
I tried the below Questions but no luck.
'jmeter' is not recognized as an internal or external command, operable program or batch file
JMETER_HOME environment variable is not defined
Here is my command and error from jenkins
E:\apache-jmeter-4.0\bin\jmeter -jjmeter.save.saveservice.output_format=xml -n -t E:\JMeter Tutorial\JenkinsIntegration.jmx -l E:\JMeter Tutorial\JenkinsIntegrationResult.jtl
The easiest way of setting an environment variable is defining it under Manage Jenkins - Configure System - Global properties:
The better way would be using Environment Injector plugin
And last but not the least, you're getting this message because you're sitting at outdated JMeter 4.0, if you upgrade to i.e. JMeter 5.2.1 you won't be seeing this warning, moreover according to 9 Easy Solutions for a JMeter Load Test “Out of Memory” Failure article you should always be using the latest version of JMeter so in any case upgrade does make sense, check out what is the latest stable JMeter version and switch to it
I removed Jenkins and reinstalled as well as i deleted the old job and created a new job with default settings in jenkins (i dint do anything in the manage Jenkins) and it worked charm with both jmerer 4.0 and 5.3. java 1.8.0_251
with 5.3
with 4.0
as far i remember i just removed the space and added underscore in the below command from folder name JMeter Tutorial to Jmeter_Tutorial
E:\apache-jmeter-4.0\bin>E:\apache-jmeter-4.0\bin\jmeter.bat -Jjmeter.save.saveservice.output_format=xml -n -t E:\JMeter_Tutorial\JenkinsIntegration.jmx -l E:\JMeter_Tutorial\JenkinsIntegrationResult.csv

How to update Windows environment variables after Ansible's win_environment module?

I am using Ansible to configure our Windows Servers 2012.
I am using Ansible's Windows modules: win_xxx. All modules are working fine except for
win_environment
win_path
I think the win_path depends win_environment module in my case.
I am installing
JDK
Apache Ant
Apache Tomcat8.
Installation works fine and setting up the environment variables for
JAVA_HOME
ANT_HOME
is not working as expected. The server is not updated with the new environment variables. I need to sign out and sign in back to the server in order the new variables are updated. Is there any way to update the system in Ansible or in Windows Batch/Powershell without signing in and out?
just to remind that "User level environment" variables will be set, but not available until the user has logged off and on again.
check then either you have selected "user" as level on you win_environment module.

Jenkins: Master node doesn't see changed environment variables on slave node

We have a build job that runs on a Jenkins slave node (Windows machine).
The job uses environment variables defined in Windows on the slave.
Now, we had to change the values of some of the environment variables on the slave.
When we call 'set' on the slave machine it shows the changed values correctly.
But when we start the build job on Jenkins and call 'set' there (Windows Batch Command) then the log still shows the old values of the environment variables!
The same wrong values we see when we go to 'Jenkins' > 'Nodes' > '' > 'System Information'.
Do you know what causes the problem and how it can be fixed?
Thank you.
Environment variables are propagated to child environments at the time of the child environment creation. If you changed the environment variables on the machine, only new processes spawned after that moment will have the new environment variables.
If you haven't restarted the Jenkins Slave process on that machine since changing the variables, then it won't be picked up.
Well, starting Jenkins slave process didn't help. Sending slave in offline mode and then back to online didn't help, neither.
First as we started the master Jenkins process anew, the changes in envvars on the slave took effect and the master showed the proper envvar values. But starting the Jenkins app is not a proper solution...

System environment variable created during install not available to current user until reboot

I have a msi package generated by wix that creates a system environment variable by populating the Environment table.
<Environment Id="CreateEnvVar" Name="DATADIR" Action="set"
System="yes" Part="all" Value="[DATA_DIR]" />
The install successfully creates the environment variable at the system level. This was verified by viewing the Environment Variables dialog from System Properties
However the currently logged in user does not have access to the newly created environment variables until the machine is rebooted ( I'm assuming that logging out then back in would also work. Just have not tried it yet). Executing an application that was just installed fails because it does not have access to the DATADIR variable.
Also, opening up a command prompt after the installation is complete the DATADIR variable does not appear when executing the set command.
I understand that a process started before executing the MSI would not get the new variables. However, why wouldn't a process started after the environment variables are added get the new ones?
FYI, I am installing on Windows Server 2003 and I am logged in through remote desktop with a user in the Administrators group.
Are you installing via Remote Desktop? If so, ensure you are using the admin console session.
To do so, launch Remote Desktop using:
mstsc /admin
Or if you are using the latest version of RDP, it is now:
mstsc /console
Try installing it from this session (or locally) and let me know the result.

Resources