Software Deployment

Ok, let's see...
If you deploy computer side / per machine, even if the HKCU keys are not written on install, when the user logs on, at first use of the app those HKCU keys should be self-healed. For that, there must be at least one HKCU key as a component's key, better if you separe the HKCU components in a top-level feature, assuring this way to self-heal everytime that you launch an advertised shortcut, if this msi has no advertised shortcuts then you should apply Active Setup, but I hope you have adv shortcuts...

As the user has rights to write in HKCU this won't be a problem.

to your side-note, they have not considered those possible troubles, they are happy... So it's your job to make this app able to be deployed over the network.

:)

KrisBcn

Hi JdotQ,
to make this scenario work, you need the this:
capture it as an installation, but be aware that this app seems to handle quite a few different version of Word (8-11) and Wordperfect (8-13). There are maybe different versions of files to install.
To make the HKCU entries work for all profiles, you need to deploy them via Active Setup. This needs some special treatments to the things that have to go to each profile.
Read the post from John McFadyen here: http://itninja.com/question/distribution-message21. Print it out and read it again and again (it's one of the best post, that has ever been made on this board. IMHO). This are essential things you have to learn, to make this type of installation a success.

In short:
- Identify everything that needs to go to the users profile (registry, files, ini-files).
- Install all the user-profile-files to location in Program Files (create one, if there is not all ready a entry for this app).
- Create separate Components for the Profile things.
- Create a separate Feature for the Profile things.
- Create entries in 'DuplicateFiles' for the files that go to the Profile.
- Create the Active Setup entries in the registry table: You need at least the following two lines:
RegHKLM1 2 SOFTWARE\Microsoft\Active Setup\Installed Components\[ProductCode] Stubpath msiexec /i [ProductCode] REINSTALL='YourUserSettingsFeature' REINSTALLMODE=up /qn 'YourComponent'
RegHKLM2 2 SOFTWARE\Microsoft\Active Setup\Installed Components\[ProductCode] Version 1,0 'YourComponent'

Hi Jdot,
I think it's not a best practice, but you could put those registry keys into the .DEFAULT section of HKEY_USERS, I've never tried this option but I've heard that in some cases it works...

Hope it helps

KrisBcn

Hmm...I just tried to manually create the value in the registry path described above, and I am able to do that successfully under the normal 'user' account. So I'm not sure permissions are an issue in the HKCU...

I browsed to the same path in HKEY_LOCAL_MACHINE, and tried to manually create a key, and was denied with a permissions error -- so it looks like it is trying to write to HKLM at this point, instead of HKCU...

Looking over the MSI in AdminStudio, it writes to both the HKCU and HKLM...from testing manually, the HKCU is not a problem (as verified with manually creating keys), but the issue resides in HKLM (cannot manually create keys).

Is there a way to temporarily grant write access to this path just for the install?

JdotQ,

A user should be able to write to the whole HKEY_CURRENT_USER registry key. However, they won't be able to write to HKEY_LOCAL_MACHINE. Are you sure it's trying to write to HKCU?

Also, have you checked that the registry path it's looking for exists?

Doug.

ORIGINAL: KrisBcn

Hi Jdot,
I think it's not a best practice, but you could put those registry keys into the .DEFAULT section of HKEY_USERS, I've never tried this option but I've heard that in some cases it works...

Hope it helps

KrisBcn

KrisBcn, thank you for the reply. After further testing, it appears it is a permissions issue in HKEY_LOCAL_MACHINE, rather than HKCU.

It might not be a bad idea to add it to .DEFAULT section of HKEY_USERS, and deploy via computer side of GPO -- that way access to HKEY_LOCAL_MACHINE is present, along with writing the user preferences portion to .DEFAULT

Thanks for the suggestion. I'll test and try it out.

Hi Jdot,
You can add a Custom Action to set permission on the needed registry branch/specific keys, but if you install this package as User, it won't work anyway... So if User keys are not the problem, then I'd better install per machine, so those user keys would be self healed (if at least one is a key reg, it should).

:)
KrisBcn

ORIGINAL: dgdavis

JdotQ,

A user should be able to write to the whole HKEY_CURRENT_USER registry key. However, they won't be able to write to HKEY_LOCAL_MACHINE. Are you sure it's trying to write to HKCU?

Also, have you checked that the registry path it's looking for exists?

Doug.

dgdavis,

Thank you for the reply. You are correct -- after further testing, writing to the HKCU is not an issue. Writing to HKLM is an issue, under a regular 'user' account in WinXP.

I was thinking to get around this is to add the HKCU keys under HKU > .DEFAULT, then deploying via GPO computer side (will allow for writing to HKLM and HKU...

OK, after more testing, adding the registry to HKU\.DEFAULT did not work. I was thinking an alternative would be to deploy via GPO computer side, and have some sort of runonce cmd once the user logs in, it will update the HKCU with the necessary keys? Good idea, bad idea?

hey, did you read my last post?

ORIGINAL: KrisBcn

hey, did you read my last post?

KrisBcn,
Yes, I attempted to install the software via GPO computer side with the HKU\.DEFAULT keys, and it did not work.

My problem is...

- Installing via computer side GPO, there is no access to HKCU
- Installing via user side GPO, there is no access to HKLM

If possible, I would prefer to deploy user side GPO. Anyone have any experience with the LockPermissions table? Would this be a good use for that? Setting explicit permissions on the HKLM keys that need to be written during the install?

ORIGINAL: KrisBcn

Hi Jdot,
You can add a Custom Action to set permission on the needed registry branch/specific keys, but if you install this package as User, it won't work anyway... So if User keys are not the problem, then I'd better install per machine, so those user keys would be self healed (if at least one is a key reg, it should).

:)
KrisBcn


I meant this last post ;)

Edit: All this without the .DEFAULT keys.

KrisBcn,

If I am reading your post correctly, including a custom action to set permissions on the HKLM registery will not work if deploying to user side GPO?

If going down the path of deploying computer side GPO, I'm not sure if would work since it needs to write to the HKCU for the user settings?

..on a side note, I was just speaking with TechSupport of this company. They said the program was not designed to be deployed over the network! [:@][:@] That could be the reasons of these troubles!

nheim,

OUTSTANDING link -- I agree completely, one of THE BEST posts I've read here on the forums. I indeed did print it out, read it, reviewed it, even made some drawings on paper to get the ideas into my head :) I think it is safe to say that I have a very good idea of how MSI repair works now.

After reading through the post a few times, I was able to create a new component under the main feature which contained registry keys for the HKCU. I also moved a file which was located in [AppDataFolder]\Microsoft\Word\STARTUP -- I moved to [ProgramFilesFolder]\Microsoft Office\OFFICE11\STARTUP. These were the two items which were attempted to be written to the user profile.

I was able to deploy computer side GPO, and when a normal 'user' tries to run the program for the first time, it performs a very quick 'repair' and all the registry changes are written!!!!!

THANK YOU BOTH KRISBCN & NHEIM!!!! [:D][:D][:D]

Hi JdotQ,
glad to read, it worked out for you. :-)
Keep MSI'ing. :-)
Regards, Nick

Me too :)

JdotQ,
Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders contains shell folder information maintained and controlled by the OS. You should probably not be modifying anything under this key. If you are looking to redirect users' shell folder paths, you should be doing so through a group policy. Assuming that you are packaging a relatively straightforward application, chances are that you picked up some registry garbage that doesn't belong in your package. Make sure you go through and clean up any unnecessary registry entries.

KrisBcn,
The .DEFAULT key contains the profile settings for the not-logged-on user. That is, it contains the settings to be used when you first boot up to the login screen. Settings from .DEFAULT are not typically applied to new or existing users when they log on. When a new user logs on, settings are copied from the Default User profile. An existing user has to be handled by other means (such as Active Setup or self-healing).

--Josh