Software Deployment

If I've understood the problem correctly, do this:

1) Create an environment table entry.

http://msdn.microsoft.com/library/en-us/msi/setup/environment_table.asp

Do not an asterisk (*) in the name column (eg. "=-NUSER" without the quotes).

Sounds like your "Value" column should contain something like "[%Username]" (without the quotes).

2) Create an HKCU keypath for the component that contains the environment variable (you may need to invent a dummy key if you don't have any HKCU keys in your package).

3) Ensure that your entry points (at least the shortcut) are advertised.

4) Install your MSI "per-machine" (ALLUSERS=1).

That's it.[;)]

2) Create an HKCU keypath for the component that contains the environment variable (you may need to invent a dummy key if you don't have any HKCU keys in your package).

Ok everything is set as you describe. I have a feeling this dummy key would be what i need to create the sefl-heal to set the path. can you please elaborate more on this part. i have never set a dummy key. what would the path be for the HKCU and what type of key? a blank string or what?

thanks

This key can be any HKCU key you like, and of any type you like. The most important point is that it doesn't already exist before you install your MSI - so pick something appropriate such as:

"HKCU\Software\Vendor\Application\UserEnvDone"

The only reason for this key is to force a repair for every new user, so that the environment variable will be set.

In many ways, it might be best to use the registry key that corresponds to environemnt variable itself:

"HKCU\Environment\NUSER"

I'm not sure if this might be termed "best practice" or not to be honest, but is has the added (important) advantage of self repairing if the variable is deleted.

If you do use this method, don't worry about the value of the registry key, as the "WriteEnvironmentStrings" action comes after the "WriteRegistryValues" action - and will therefore overwrite the value.

Although I've got BIG issues even suggesting this, I'm going to anyway! I would however like to apologise in avance to anyone who may subsequently read this post.

You could theoretically use an ancient mechanism known by as the "autoexec.bat". You may or may not have heard of this depending on how old you are![:D]

You'll usually find this file in the root of your C-drive. You could add the following line:

Set NUSER=%UserName%

This should allow you avoid a self-repair for each user.

You would normally need a custom action to edit the "autoexec.bat", but you could cheat and use the "inifile" table. If you're using Wise you'll have to create the inifile in another folder, and then edit the "DirProperty" column of the "inifile" table manually to move it to the root. I used "TARGETDIR" when I tried it, but this won't work in all cases (depends on your environment). You should really create a property that reflects the actual drive that contains your "autoexec.bat" (eg: "C:\").

I used "Environment" for the "Section", "Set NUSER" as the "Key", and "%UserName%" for the "Value". Like so:

[Environment]
NUSER=%UserName%

Personally, I'd live with the repair!

By the way, do you use roaming profiles or redirected folders? If so, there may be a much better place to store your "CFG" file.

Where you've currently got it, the application may not work when the network is down, or when laptop users are away from the office.

Again, I don't know your circumstances, but another option would be to share the "%Username%" folders and map straiht to them. That way, you could have a machine environment variable something like "NUSER=W:\Myapp\Program.cfg".

Anyway, that's enough suggestions from me! I'll leave you to it.[;)]

I cant remap because this is in the users logon script for the domain already, and it wouldn't be practical to change any paths. Also, this was designed with an autoexec.bat before i started to package it :) i was trying to get away from it, but i may end up going back. First I will try this UserEnv dummy key in the registry though. Hopefully that works and i can avoid using the autoexec.
Thanks for all the tips,

Brandon

Well, it's possible to deploy Registry settings, (like map a network drive, assign a printer connection, define an environment variable, etc.) using Group Policy by creating or customizing administrative templates (.adm files), this is not a trivial procedure, but once you do it a few times you will find that .adm files are pretty useful.

that may be but im not an administrator on the domain or network so i have no control over that. Basically i am just packaging software to work with the current state of the department.

3) Ensure that your entry points (at least the shortcut) are advertised.

ok my test case worked :)... the step above is where i changed it some. The exe is in the complete feature, therefore i made the shortcut part of the complete feature but in the details dialog i told it to be part of the ENV feature. this is the feature i created with two components:
1) all my env variables
2) HKCU/Software/App/ENVDUMMY (note i kept the original HKCU intact in the complete feature)

then under the feature details for ENV i set:
parent: none
attrib: favor local
advertising: favor advertising
check required feature

Note: the favor advertising seems to be what made this work.

Thanks so much for all your ideas, im so glad i have this working now.

-Brandon

i should also add before any of this i did try W:\BLAH\%USERNAME%
this would make the most sense entered into the registry. For some vars this was working and others it was using a literal "%USERNAME%" instead of the actual users name. I have no clue why this was happening.

For variable expansion to work, the variable registry key must be of type "REG_EXPAND_SZ".

Check the keys under "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\" and you'll see that all the variables containing another variable are of that type.

However, I have the feeling that there may be an issue using "%USERNAME%" (and other user environment variables like "%TEMP%")? Maybe the order they're resolved in? User variables tend to take precedence over machine ones, which might suggest that they're resolved last? This is all guess work btw - I have no evidence of this.

It always appears to work with machine variables though. Even if you use a machine variable within a user variable.

Two more points:

1) If you really want a separate "Env" feature for your user stuff, and it's not the feature with the entry points, then I'd suggest you make it a parent of the entry point feature ("Complete"). Is there a functional reason for this to be a separate feature?

2) I'd suggest that your two components become one. This is because they are related and should be installed and removed as a group.

I don't understand what you meant by: "note i kept the original HKCU intact in the complete feature"?

ORIGINAL: schieb
that may be but im not an administrator on the domain or network so i have no control over that. Basically i am just packaging software to work with the current state of the department.
schiebschieb, Sorry for the red herring there. I push software mostly via GPO so I tend to think along those lines first.

Have you considered using Active Setup? (click the link for a text file with the "how to") Active setup is another method by which you could trigger a self heal, or a launch a scripted action on a per user basis.

i will have to try some of your suggestions WiseUser. This is such old software its amazing its even packaged, so thats a start. there are a few HKCU keys, i left them under the complete feature. I did not export then re imoprt them to the ENV feature.

Bob: i have read a little about it but i have never personally tried it. Iwas understanding its best used when there are no advertised entry points. maybe its time to take a look though.