Software Deployment

Hello Matt,

Here is what I would try...(1)I would export the .REG file and copy any other files needed to setup the application to a known directory. (2)Then I would create a batch file using the REG IMPORT command importing the .REG file to HKCU and copy the file(s) to its destination location... (3)Then I would create a String Value in HKLM\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUNONCE pointing to the batch file created. (4)Finally, I would add all of this to my .MSI forcing a REBOOT. Ensure the user needing the application logs in after the reboot. Worst case scenario you can have each user after the install run your batch file setting it up for them. If a user has already had the application you may need to delete a value out of the registry.

I hope this helps,

John

If I'm understanding you correct you're installing/Assigned through AD/GPO as Per Machine and installed before the user is logged on.

If the HKCU registry entries should be default for all users then add those to the package and make sure any entrypoint exist to trigger the self-heal to check for broken components. If this is not true that is, no entrypoint exist or can be used then use a Active Setup to run a script that will; check if reboot has occured (if not removes the "HKCU\Software\Microsoft\Active Setup\Installed Components" entry) and executes "msiexec /fu {ProductCode} /qb-!"

Hi, thanks for the replies.

John, would the values in the runonce key run for every user? So user A logs on and it runs, then user A logs off and user B logs on and it runs? From what I've read, the values in that key get deleted once executed.

AngelD, wouldn't the self-heal cause a delay everytime the user logs on, regardless of whether or not it's already run?

Hi Matthew,
have a look at the following pages:
http://itninja.com/question/distribution-message21
http://www.ewall.org/index.php?module=ContentExpress&func=print&ceid=23
This explains, how to install user side components very well.
Hope this gives you some ideas.
Regards, Nick

I would look at nheim links. It looks like you can leverage self-healing to accomplish this need. The RUNONCE key will only run one time and there are a couple of problems with this...If the user intending to use the app doesn't log in after the MSI reboots...the user will not get setup. Another problem is if a second or third profile needs the HKCU settings then they would have to manually have to run the batch file. Finally if a new profile gets setup they would have to run the batch file as well. This would be a quick fix but it would not accomplish all that the self-healing can. Thanks to all who has posted. On Monday I will be looking into this.

Thanks to all for passing on the knowledge,
John

PS- Matt please let me know how this turns out so I can grow from your experience...

ORIGINAL: Captain Matt

AngelD, wouldn't the self-heal cause a delay everytime the user logs on, regardless of whether or not it's already run?

The self-heal/repair would only occur once they hit an entrypoint such as a shortcut, file association, DCOM component and so on.
It will not execute be triggered during logon if not an entrypoint is triggered by example an executable in HKLM/HKCU\Software\Microsoft\...\Run or Startup (StartMenu) folder.
The delay may vary during checking for broken component(s) depending on where you have your "user" components. The minimum delay will occur if you have your user components in a top feature preventing the whole package from being checked.

About the runonce entry; it will get removed once executed if placed in HKCU. Should you store this in HKLM and users are not local admins this reg entry will not get removed and therefore execute each time they login.

Thanks a lot everyone, I've got an idea of how I'm going to do it now using the self-heal.

Unfortunately I have several different projects on at the moment, all of which have a higher priority than this. Hopefully I'll get a chance to try it at some point this week though. I'll be sure to let you know how horribly wrong I get it. [;)]


Cheers,
Matt

I have found the advantages to placing an entry in RUNONCE are:
* The String Value is removed after it runs helping with cleanup
* Makes supporting the configuration a little easier since you now have a .VBS, .BAT, .CMD that the Help Desk can run

The most important issue of the configuration setup is to know the user intending to use the app needs to log in after the reboot...Assuming you are making changes to HKCU. This is a one time run and if you have multiple user profiles needing this application configured you may need to have them run the batch file manually.

I am going to look into setting up a new Feature to see how it works. I have been hesitant with allowing any HKCU settings in my .MSI files especially with the annoyance of the self healing.

Matt, I will let you know how successful I am with the creation of the new Feature...

Good Luck,
John

So thank you thank you to all who have posted to this Posting. I have learned how to fish today and my tackle box has that many more gadgets and gizmos. I have successfully created a new Feature adding the HKCU setting(s) and this makes me very happy. Nheim your links have helped. I appreciate the time you all have taken to post. Consider X-mas cards are in the mail... [;)]

Matt, once the self-healing kicks off for a particular profile the .REG file is imported and the app is setup and configured. I loaded the app with an admin account...Ran the app and all was working as intended...Then I logged out and back in with an end user account...Just like magic...The self-healing kicked off and batta boom batta bing the application is configured and setup.

This will be a big tool I plan on using more of in the near future...

Happy Holidays,
John

So here is a problem I am having with self-healing...With end user permissions on an workstation the self-healing runs and installs the configurations I have set in the MSI. But with admin rights the self-healing doesn't run. I'm a little confused why? Any ideas?

Look at the component(s) holding the user stuff. You must use a HKCU registry entry as the keypath for this to work with admin accounts as they has the permission to read other users profile. When windows installer check for broken components (missing component keypath) and if the keypath is set as a file in a profile it will search all user profile folders and if found think it found the user's profile file and therefore not repair. Following best practise: always use HKCU registry on user components, even ICE validation will give you the error or warning (don't recall which one).

Thanks for your response AngelD. This has helped. I have been looking to create the key path but I was looking at the Keys rather than the String Value in the Feature - Condition - Registry Data I was creating. The self-healing is working great. Another issue I felt might become a problem was:

What if the registry on the intended workstation already has these values in HKCU. My work around was to create an empty String Value making it my key path. I noticed in one of nhiem's links it talked about placing a .TXT file (ie a signature file) in the users profile prompting the self-healing process to launch. Do you see a problem with creating an empty String Value?

Once again I appreciate the knowledge of the employees who work at managing this message board and at AppDeploy. This is a great site and I'm sure you will see my happy smiling jryan_su around.

Thanks,
John

Just to clear this out; we are not employees at AppDeploy, only Bob (Kelly) is ;)

Do you see a problem with creating an empty String Value
Do you mean creating a HKCU registry entry without any value?
If so, no.
Windows Installer will not trigger a repair on the value it-self but if the registry entry exist or not.
To make sure to have a uniq registry entry for the repair to trigger on just add a string entry as example HKCU\Software\Product Name\{ProductCode}="Dummy entry for repair"
or similar.

It's too bad your not paid. But I can see why you do it. I have a lot of fun working with MSI and scripting. It's like a puzzle to me.

You and I are on the same page and all is well with the app and the install. My MSI isn't even needed after the initial install. Parent - Child - Features - Components - Key Paths are huge. Understanding how is the name of this IT game...

Thanks again and I look forward to working with yourself and AppDeploy in the future.


John

Don't be sad, I get paid as any other MSI-junkie would when packaging for their customer(s) ;)