Software Deployment

This is a common new packager dilemma. The thing here is that you need to alter your thought process from a scripting approach to a packaging approach. You obviously know the scripting process, the packaging process is different. MSIs are a database of what's supposed to be where, and if it isn't, make it so. The package will accomplish what you want in the following way: The packaging process (msi) install will install the file directly into the current user profile upon installation. If a different user launches the application who does not have that file in their user profile, when the MSI package scans its key files (which it does every time an app is launched through a shortcut in the MSI) it will discover that the file is missing from the current user profile. It will then initiate an automatic self-repair and place the file where you want it.

So, place the file in Windows\Profiles\Application Data (or wherever it should go in the profile), make sure it has its own component and the file is the key file for the component. (Self heal doesn't check non-key files) Also be sure the AllUsers property to 1 for a machine based installation. That's it. When a new user launches the app, it will go through a quick (automatic and unattended) self repair and put the file there. It will only do that the first time its launched, once the file is there the app will directly launch.

Thanks for the reply. You are right about the scripting!

What you said makes a lot of sense. I wan't sure if current user meant the user I was logged in as when I did the snapshot, or if it was whoever is currently logged on interactively in future..

When I origanlly created the msi I think I did copy the preference file to the current user application data directory, but that's all I did. I look into component and key files.

Would that prevent the wizard running though? It looks as though self heal looks at what file should be there, but before it copies the default it runs a wizard. How can I get around that, or shouldn't I have to?

That depends on what you mean by "The Wizard". Is that wizard part of the application you are packaging, or does it look like a Windows Installer window kicking in? If it's part of the application, it won't happen. The MSI integrity check and (if necessary) self repair runs & completes before the application is launched. If it looks like a Windows Installer window, that is how MSI is designed to work. That's the automatic self repair, it only occurs if a key component file or registry key is missing or altered. In your case, each time a user launches the app for the first time the self repair will kick in and configure their profile.

You can play around with it to see how it works. Pick a component, find the key file or reg key and delete it from a machine with the MSI installed. Next time you run the app, the self repair will kick in and change it back. This is why you want to check for conflicts between packages and the OS. If another package or Windows File Protection wants one of your files to be a different version or value, you'll have two self-repairs battling each other, each trying to "fix" what the other "broke".

Oh, and about your uncertainty with Current User, it can be both ways. If you set the MSI to a per-user installation, then it is current user at time of install. If you set the MSI to per-machine, then it is current user at install and any other time in the future. (i.e. anyone who is the current user at any point in time)

That worked a treat. Logged on as admin delete the file, fire up the app, and Windows Installer just puts its back again. Quality bit of kit.

Another probably basic question though. Logging on as user and running the app for the first time, I get a windows doesn't have access to modify the file error. What's best practise to get around file and registry permission changes?

Windows Installer remembers where packages were installed from. If a self repair needs to be performed, it will need to access the MSI file and it will look for it where it was during installation. It will also look for it in all the locations listed in the Source List within the MSI. Windows Installer just needs access under the User ID. Once the MSI can be accessed, actually installing files back in a repair should be performed in the SYSTEM context, not the user's.

Usually, the packages are put on a DFS share as an admin install point with users having read-only access. The network share makes it available to all users, and DFS gives the admins the ability to move or replicate the packages to another server but have the network share name remain the same. If you don't do that, and you are forced to move the MSI files to a different server for some reason (i.e. server failure), changing the \\SERVER\SHARE name will break the self repair of every application on every workstaiton. (Nice trap, huh?) If it's still at \\DOMAIN\DFSRoot\ then it's just a matter of repointing it to a different location and the workstations won't even notice the change.

Also, you won't have the problem of users finding the MSIs and installing software they shouldn't have because standard user IDs do not have the right to install software with Windows Installer, just repair.

If your security issues are in running the app under user level permissions, find out where your access denied is with FileMon or RegMon. Keep running them and opening up security to users as necessary until it works. You usually discover only 1 roadblock at a time and there may be many. You can modify most permissions within the MSI, but sometimes its necessary to build a local security template, add it to the package and launch SECEDIT in a custom action to apply the security template.