Hello,

I am repackaging a program that was originally just a setup.exe into an MSI (WestCiteLink.exe & AdminStudio). Going through the process, it customizes some MS Word menu options, so it writes the changes to the HKEY_CURRENT_USER registry hive.

Using GPO and deploying user side is fine when deploying to a user with admin privileges -- but deploying to a user with regular 'user' rights, they cannot write to this section of the registry.

My thought was to deploy via GPO to the computer side - as it uses the SYSTEM account to install, so it should have the equivalent to admin rights. But, when deploying to the computer side using GPO, there is not a user logged on, so no HKCU is present.

Running through the install as a regular user, and logging the install;

Error 1406.Could not write value to key \Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders. System error . Verify that you have sufficient access to that key, or contact your support personnel.
MSI (s) (94:E4) [09:45:13:077]: Product: WestCiteLink -- Error 1406.Could not write value to key \Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders. System error . Verify that you have sufficient access to that key, or contact your support personnel.


Any ideas/suggestions of how to get around it?

I have searched the forums, but was unable to turn up any pertinent information -- I may be overlooking things, so if anyone could provide a link, that would be great too :)
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
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
Answered 03/20/2007 by: KrisBcn
Purple Belt

Please log in to comment
0
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?
Answered 03/20/2007 by: JdotQ
Senior Purple Belt

Please log in to comment
0
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.
Answered 03/20/2007 by: dgdavis
Orange Belt

Please log in to comment
0
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.
Answered 03/20/2007 by: JdotQ
Senior Purple Belt

Please log in to comment
0
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
Answered 03/20/2007 by: KrisBcn
Purple Belt

Please log in to comment
0
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...
Answered 03/20/2007 by: JdotQ
Senior Purple Belt

Please log in to comment
0
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?
Answered 03/20/2007 by: JdotQ
Senior Purple Belt

Please log in to comment
0
hey, did you read my last post?
Answered 03/20/2007 by: KrisBcn
Purple Belt

Please log in to comment
0
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?
Answered 03/20/2007 by: JdotQ
Senior Purple Belt

Please log in to comment
0
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.
Answered 03/20/2007 by: KrisBcn
Purple Belt

Please log in to comment
0
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!
Answered 03/20/2007 by: JdotQ
Senior Purple Belt

Please log in to comment
1
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
Answered 03/20/2007 by: KrisBcn
Purple Belt

Please log in to comment
1
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'
Answered 03/21/2007 by: nheim
Tenth Degree Black Belt

Please log in to comment
0
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]
Answered 03/21/2007 by: JdotQ
Senior Purple Belt

Please log in to comment
0
Hi JdotQ,
glad to read, it worked out for you. :-)
Keep MSI'ing. :-)
Regards, Nick
Answered 03/21/2007 by: nheim
Tenth Degree Black Belt

Please log in to comment
0
Me too :)
Answered 03/21/2007 by: KrisBcn
Purple Belt

Please log in to comment
0
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
Answered 04/01/2007 by: mazessj
Blue Belt

Please log in to comment
Answer this question or Comment on this question for clarity