Comments

I just cannot seem to get self healing to work right. I read McFaydens blog, and some other info sites - self healing seems to work for me - per user , but then when I load it into SCCM and deploy it , it dosnt seem to work , no matter of the user.

It seems that self healing is the way to go as best practice for this type of situation.

Could someone help me figure this out?

My setup is very simple.

1. New msi
2. one feature with all files copied down
3. Start menu shortcut, desktop short cut
4. Write file "foundation.ini" for all users to %appdata%\Oracle Predictive Solutions
or AppData\Roaming\Oracle Predictive Solutions(for all users)
5. When I log on as any user, IF the file dosnt exist, then create it by self healing the MSI

When I hand install this MSI everything works! the files is created by self healing, I can delete it - re-launch it and it self heals and replaces the file/directory with a new default

Problem: When I deploy this through SCCM , is seems to break self -healing!
SCCM installs MSI using the "system" account

Can anyone please help? Im pounding my head on the wall - I do not want to use active setup, spawn of the devil ;)

Active Setup is far from being the spawn of the devil *IF* you know what you are doing.
First of all, you need to understand that the system account, be it the SCCM one or any other localsystem account, DOES NOT HAVE ACCESS to any user resources as these are specific to the user and only accessible when the user is logged in. If you use roaming profiles then chances are high that the user profile you might be trying to target is not even on the local machine, but on a network server that a localsystem account also cannot access.
Secondly, I would never ever ever use active setup to activate self healing from an MSI. I have seen all sorts of start up processes in corporate environments that involve some MSI activity. If your active setup tries to kick off an MSI self healing operation while another MSI process is running, your active setup will fail with the usual "Another installation is in progess" error, but active setup still marks the operation as completed and it will never run again.
If you need to install files to a user profile, place those files on the local hard disk as part of the initial install, and then use a VBScript (also copied as part of the initial install) to copy the required files to the user profile, and to create any user registry keys that might be required. Use Active Setup to run the vbscript by calling wscript.exe (or cscript.exe) as vbscripts run entirely asynchronously and will not conflict with any other startup or login process.

Answers

0

Hello,

Could you tell us , if you get your *ini files in the system profile folder :

" C:\Windows\System32\config\systemprofile\AppData "

Not sure, but I am thinking these will be there.

Maybe, if you want the msi put its files in the current userprofile, you have to use a Active Setup " . This mecanism used to repair the msi file at the start up session , and then put the files which not present.