ENVIRONMENT Table
Within my MSI package, I am writing several system environment variables. Once the installation has finished I can see the new variables in the 'System -> Advanced -> Environments Variables' GUI.
BUT, if I open a command prompt (Start -> Run -> cmd -> [Enter]) and then type in SET to list all the variables, the new ones aren't there!
I resolve this by going into the GUI and clicking on OK (instead of Cancel).
According to the Windows Installer SDK, the environment variables should be available to any new processes...... but they aren't in this case!
Anyone ever come across this issue before?
Details:
Windows 2003 Server (Standard Edition) (No Service Packs [:'(])
Windows Installer 2.00.3790.0 AND Windows Installer 3.01.4000.1823
BUT, if I open a command prompt (Start -> Run -> cmd -> [Enter]) and then type in SET to list all the variables, the new ones aren't there!
I resolve this by going into the GUI and clicking on OK (instead of Cancel).
According to the Windows Installer SDK, the environment variables should be available to any new processes...... but they aren't in this case!
Anyone ever come across this issue before?
Details:
Windows 2003 Server (Standard Edition) (No Service Packs [:'(])
Windows Installer 2.00.3790.0 AND Windows Installer 3.01.4000.1823
0 Comments
[ + ] Show comments
Answers (9)
Please log in to answer
Posted by:
andler
18 years ago
Hi Mr B Hunter
I have just made a MSI where I set three system environment variables.
Two new variables and one adding to path.
I can see them in both GUI and CMD-shell.
I'm using InstallShield AdminStudio6 to make the MSI.
Could your problem be your MSI-tool?
br,
andler
I have just made a MSI where I set three system environment variables.
Two new variables and one adding to path.
I can see them in both GUI and CMD-shell.
I'm using InstallShield AdminStudio6 to make the MSI.
Could your problem be your MSI-tool?
br,
andler
Posted by:
brenthunter2005
18 years ago
Hello andler,
I have created MSI's in the past and another one just now with Environment variables, and all works perfectly. It was just this particular MSI that was updating the MSI's but not making them available to the system.
If you have a google, you'll find many people having the same problem too.
After some advice from EdT I have created a utility that broadcasts the environment variable changes and all works now.
It's just odd though. Its only happening with this one MSI, which is a huge one and I just don't know why its doing this... [&:]
Strange, very strange....
I have created MSI's in the past and another one just now with Environment variables, and all works perfectly. It was just this particular MSI that was updating the MSI's but not making them available to the system.
If you have a google, you'll find many people having the same problem too.
After some advice from EdT I have created a utility that broadcasts the environment variable changes and all works now.
It's just odd though. Its only happening with this one MSI, which is a huge one and I just don't know why its doing this... [&:]
Strange, very strange....
Posted by:
brenthunter2005
18 years ago
Can I also say that from google-ing myself, I feel that this issue is caused by the fact that I'm installing the MSI through Terminal Services.
[:@] [:@] [:@] [:@] [:@] [:@] [:@] [:@] [:@] [:@] [:@] [:@] [:@] [:@] [:@] [:@] [:@] [:@] [:@] [:@] [:@]
[>:][>:][>:][>:]
[:@] [:@] [:@] [:@] [:@] [:@] [:@] [:@] [:@] [:@] [:@] [:@] [:@] [:@] [:@] [:@] [:@] [:@] [:@] [:@] [:@]
[>:][>:][>:][>:]
Posted by:
AngelD
18 years ago
Sounds like permission problem as admins on terminal servers usual lock them down realy hard
Posted by:
brenthunter2005
18 years ago
No no no, its just a "feature" of installing MSI's under RDP/Terminal Services.
Posted by:
AngelD
18 years ago
eh think I missed something here [:D]
Do they not install applications manual on these (or using install mode)?
Edit: never mind this, must have had a brain fart when I wrote this
Do they not install applications manual on these (or using install mode)?
Edit: never mind this, must have had a brain fart when I wrote this
Posted by:
ZhuBaJie
18 years ago
Hi Brent,
Using registry keys you can set variables for the user....
\HKEY_CURRENT_USER\Environment
...and for the system.
\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment and
\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager\Environment
For system variables you have to set both CurrentControlSet and ControlSet001.
Marcel
Using registry keys you can set variables for the user....
\HKEY_CURRENT_USER\Environment
...and for the system.
\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment and
\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager\Environment
For system variables you have to set both CurrentControlSet and ControlSet001.
Marcel
Posted by:
dem3tre
18 years ago
I would recommend staying away from directly modifying the HKLM\SYSTEM\ControlSetXXX entries. I don't see the reason for having to set both CurrentControlSet and ControlSetXXX since writing to one updates the other automatically; the problem is there is no guarantee that CurrentControlSet is actually mirroring ControlSet001...it could actually be mirroring ControlSet003.
For a great article on how to identify what CurrentControlSet is really mirroring check out Aaron Stebner's blog:
http://blogs.msdn.com/astebner/archive/2004/10/13/242122.aspx
For a great article on how to identify what CurrentControlSet is really mirroring check out Aaron Stebner's blog:
http://blogs.msdn.com/astebner/archive/2004/10/13/242122.aspx
ORIGINAL: ZhuBaJie
Hi Brent,
Using registry keys you can set variables for the user....
\HKEY_CURRENT_USER\Environment
...and for the system.
\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment and
\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager\Environment
For system variables you have to set both CurrentControlSet and ControlSet001.
Marcel
Posted by:
ZhuBaJie
18 years ago
ORIGINAL: dem3tre
I would recommend staying away from directly modifying the HKLM\SYSTEM\ControlSetXXX entries. I don't see the reason for having to set both CurrentControlSet and ControlSetXXX since writing to one updates the other automatically; the problem is there is no guarantee that CurrentControlSet is actually mirroring ControlSet001...it could actually be mirroring ControlSet003.
For a great article on how to identify what CurrentControlSet is really mirroring check out Aaron Stebner's blog:
http://blogs.msdn.com/astebner/archive/2004/10/13/242122.aspx
Thanks for the info. I should have known this.
Marcel
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.