Custom Actions, Run Locations and Administrative Rights

Hi,

I have a really unique situation right now;  I am preparing to deploy out Internet Explorer 8 and have some 50 local policies, which are registries that need to be set.  Upon examination, the majority of the policies are in the SID-user registry, which is very hard to script.

Anyhow, I compiled an exe that writes all my registries, so I can have a custom action in a binary table,as I am creating my own wrapper for this install,even though I use IEAK to create the distribution, except I created the policies in HKLM and HKCU, not HKU/SID.

So, my problem and question is:  why won't the registry keys get created, even some of the HKCU keys are denied access to be written, while some HKLM keys will write, when you execute the custom action (exe/script that creates the policy registries) in a limitd user account.  This seems very odd to me.  

My 2d question is: what locations in the all the registry run/run once, where executables can be launched with admin rights regardless of being executed in a limited user account...The other part of this question is, do custom actions that launch an exe, also run with elevated rights? ie, the exe itself is executed with admin rights?  From what I experience, this is not the case, unless I am configuring something wrong.

I would like to know more because I might resort to using a capture and active setup entry...

Any comments are appreciated.
SugaBabyAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Vadim RappCommented:
The questions related to the installation are hard to tell without seeing the installation and knowing more details. The only question that can be answered more or less coherently is whether the custom actions run with admin privileges. Yes they are, if the installation itself runs as elevated. More at http://msdn.microsoft.com/en-us/library/aa368073%28v=vs.85%29.aspx

Could it be that instead of all these efforts to set registry settings you might turn to specifying them in group policy? assuming that this is related to Internet Explorer, I think it's hard to imagine a setting in it that is not in its administrative template.

Regarding HKCU, is the installation deployed per-user?
SugaBabyAuthor Commented:
Hey,

Only local polices are being used in my case; we do not have group policy/AD at our disposal for this package.  I would note that some of the settings, but not all settings are actually documented by Microsoft as policies.  

I think my problem has to do with the SID registry not getting updated, so I am working on writing a vbscript that loops through all user SID accounts/registry and updates the registry settings there so they get updated right away.  

So, basically, I am running an IEAK produced MSI, setting as much as the settings as I can from IEAK and adding additional registry keys as needed and including in the IEAK msi wrapper to run as a custom action. So I will see how this all works and comes together.  Thanks.

CSI-WindowsCommented:
Could you explain why you don't just put the registry keys in the Registry table of the .MSI ?

When your registry keys are located here they:
*) Are processed with the correct permissions (User perms for HKCU and System for HKLM).
*) [NOT for IE] The HKCU keys are automatically applied via self-healing upon the user launching the application.  This does not apply to IE because it does not have a Windows Installer shortcut, but I wanted to mention it so you know for other authoring projects.
Why Diversity in Tech Matters

Kesha Williams, certified professional and software developer, explores the imbalance of diversity in the world of technology -- especially when it comes to hiring women. She showcases ways she's making a difference through the Colors of STEM program.

SugaBabyAuthor Commented:
Hey,

In the case of IEAK, it is not intended to carry out self healing - the MSI is a simple wrapper that executes a custom action. Microsoft only started adding this function to their IEAK becuase of Active Directory deployments.  

There are no permissions needed, in my experiments the permissions did not affect anything in a positive way so they were be left as is.  

So the only two approaches I have here are the VBScript to run as a custom action and put in binary table of the msi wrapper produced by IEAK OR I will capture all settings and produce a 2nd msi wrapper of sorts that will run an active setup self repair for each users first logon to the computer.  Hopefully one of these things work.  
CSI-WindowsCommented:
I am aware that it is a wrapper, but if you're spending the time to embed a binary custom action into it, you might as well just use the registry table to keep it simplier.  Once built you could use Orca to export the registry table to an IDT and then it would be simple to merge your permissions in each time you regenerate the wrapper.

Since IE shortcuts are not MSI shortcuts, you might also consider pairing this with the old trick of an Active Setup key for msiexec /fu wrapperwithregkeys.msi.  Would need to test what else in the wrapper is a "per-user" resource and whether you want that running as well (my guess is there isn't anything else that would run with the /fu).

D.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
SugaBabyAuthor Commented:
Trying to implement policies in an MSI package is challenging because of the pol files, specific location for registry keys that are policies and upon inspection not all keys are polices - and even if you create your own adm/admx files...very tricky to make all this working.  Also, the IEAK setting names are not enough - the names of the settings do not match the policies in all cases.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Installation

From novice to tech pro — start learning today.