View Full Version : ALLUSERS property.

05-22-2006, 09:29 AM
I just read Alison's thread on her ALLUSERS woes and I have something else that is affecting my installation but it's not the same problem or related. I'll explain: I built a very simple (basic MSI) installation. It does nothing more than install a simple text file, in other words something I threw together in a couple of minutes. I suppressed the installation interview that lets the user select if the installation is for the current or all users. Neither is there an ALLUSERS property in the property table.

On a desktop, logged in as A I ran the installation. If I open the ARP list I can see my test package TEST123 listed. I logged out, and then logged in as B. I open the ARP list and there is no entry for TEST123. Logged back in as A and I then uninstalled the package.

I then added ALLUSERS to the property table and important or not, I set its property value to 1. I rebuilt the package. I installed it logged in as A and as expected it's still in the ARP list. I then logged in as B and it also shows in the ARP list. This is what I was expecting (and hoping to see). The reason I need this behaviour is that our SA's in another country only grant us a limited time to use an account they set up for us. This weekend I had to upgrade six servers and these were installed using their name not the one they gave me. Logging in as me I could not uninstall as it was not listed in the ARP list. To get round this, I hacked the registry and restarted the server. Then I could install using my name. At some point, they will login as their name and they will not see the application in the ARP list.

I really want to force the package to be available for uninstallation no matter who the user is that's logged in. Creating an ALLUSERS property 'fixes' the problem but is it a safe assumption that it won't be negated by other login profiles. It's really important that the SA's can uninstall what I've put on when I handover another upgrade to them.

Advice appreciated.

Christopher Painter
05-22-2006, 09:53 AM
Just as windows isolates system data from user data in HKEY_LOCAL_MACHINE vs HKEY_CURRENT_USER, Windows Installer does the same thing for per machine and per user installs. The only way to get the behavior you want is to always deploy your product as AllUsers. A major upgrade can't change a package from Per User to All Users so the only way to get the job does is to go uninstall the previous installations and redeploy the package as ALLUSERS=1.

I used to do alot of enterprise distribution and this is the major reason that I always hardwired ALLUSERS=1 in the property table and bypassed the CustomerInformation Dialog. I just simply didn't need to support per-user installations and I didn't want to be bothered with it.

05-22-2006, 02:44 PM
Thanks Christopher. I respect your views. I can now change my package with confidence. It puzzled me why one server did let me uninstall but that was down to me installing it in the first place.

Edit: You have my curiosity aroused with MSI-Spy. I can guess what it might do but have you anything to say about it?

Christopher Painter
05-22-2006, 03:32 PM
MSI-Spy++ ( Probably should have called it MSI-SPY# but I like Spy++ ) is a MSI debug utility that I'm working on. It'll consist of a transform that sequences an async custom action that hosts a .Net remoting URI. Then you'll launch an external .Net remoting client that uses IPC to access the MSI Handle from out of process. The utility will do things like display and modify properties in real time, view database tables, evaluate conditions, invoke API calls. Anything that I can come up with a use case for.

Unfortunatly I havn't been able to spend much time on it ( the remoting and API interop piece is complete ) because my wife has been ill.


05-23-2006, 09:44 AM
That sounds really interesting. I'll be happy to beta test if you need a circus chimp. :)

Attend to you home matters first. Family is always the first priority in life.