I wrote a fixlet that adds a path to the PATH environment variable. (The script creates and runs a vbscript, which makes the change.) This works nicely, a look at the system environment variables or a newly-opened command prompt shows it worked.
Unfortunately the action always reports failed and the fixlet remains relevant until the next system restart. From my tests, it appears the BigFix client doesn’t see environment changes. I manually changed a system environment variable and BigFix still saw the old value.
Restarting the BESClient service doesn’t help. That surprised me, I assumed the client loads the environment when it starts and would load the new environment when the service restarted.
Is there a way to tell the client to update its environment without restarting the system?
We make environmental variable changes successfully with relevance that includes:
((not exists value “” of key “HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment” of registry) OR (exists value “” whose (it as string contains “”) of key “HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment” of registry))
not ((variable “Path” of environment as string as lowercase) contains “c:\folder”)
I’m trying, when possible, to cooperate with the OS and BigFix and use their information rather than do direct peeks into the registry. Is that a bad idea for environment variables?
I have never quite understood how/when the environment variables get stored when using the user vs. system accounts. I wouldn’t recommend using the environment variables to store state and instead use the registry.
Relevance tests the Path variable using the registry value. Action script creates a vbscript that changes the path in the environment, not in the registry. Since Windows writes the environment change to the registry the relevance evaluates false and the action is fixed.
The advantage of this over the all-registry approach is new processes get the revised environment without requiring a restart.