MS AntiSpyware MSI with Group Policy
I managed to extract the MSI using <setupfile>.exe /A and then open the MSI in Wise to change the license agreement from "No" to "Yes" and save it. Then I created a GPO to deploy it by assignment and it seemed to work perfectly (appeared to install and no errors shown). I log in and the desktop icon is there, but try to run it and I get a nasty error 101 message saying it encountered a critical error and must close. The only solution is to do a repair/install (aka "update") from within Add/Remove Progs. That gets it working fine again. Should I not edit the MSI and just try to deploy it as-is or what? I can't use the EXE with a GPO, and I hate ZAP files, so I'd prefer to use an MSI approach if possible. Anyone have any suggestions?
0 Comments
[ + ] Show comments
Answers (4)
Please log in to answer
Posted by:
VikingLoki
19 years ago
Hmmm. If a repair from add/remove programs will get it working, that's a reinstall off the same MSI. The only difference between your GPO install and the repair is that the GPO install is running without the user profile that you're testing under, the repair has the user profile available that you're testing with. Sounds like you have a problem in either the HKCU registry hive or the Windows\Profiles file seciton. These are both user profile areas.
First you should make sure that you are doing a per-machine installation and not per-user. Normally that's setting ALLUSERS=1 in the properties table. See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/allusers.asp for details on ALLUSERS. This might be the root of the problem, but if not...
Open up your MSI and find out exactly what is going into HKCU and Windows\Profiles. Make sure that everything in there is in its own component and is the key file / registry entry for that component. If everything in HKCU and Windows\Profiles is tucked into another component that has a key file/regkey that is not in the user profile, then self-repair won't kick in if you change users and the app will run sans user profile stuff. Some apps don't like this at all. But, if the profile stuff is a component key, then windows installer will check for the profile stuff and automatically build it if it isn't there.
First you should make sure that you are doing a per-machine installation and not per-user. Normally that's setting ALLUSERS=1 in the properties table. See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/allusers.asp for details on ALLUSERS. This might be the root of the problem, but if not...
Open up your MSI and find out exactly what is going into HKCU and Windows\Profiles. Make sure that everything in there is in its own component and is the key file / registry entry for that component. If everything in HKCU and Windows\Profiles is tucked into another component that has a key file/regkey that is not in the user profile, then self-repair won't kick in if you change users and the app will run sans user profile stuff. Some apps don't like this at all. But, if the profile stuff is a component key, then windows installer will check for the profile stuff and automatically build it if it isn't there.
Posted by:
ds0934
19 years ago
Thanks! I checked again, and my GPO is assigning the software package per computer. ALLUSERS is set to 1 also. Hmmm... Your explanation makes sense, so I'll keep digging to find out where I'm missing something.
Posted by:
ds0934
19 years ago
The MS document link you provided describes ALLUSERS as being set to "" or even 2 might work better based on the first row in the given table. Does that make sense? I might try setting it to ALLUSERS="" (empty)
Posted by:
craig16229
19 years ago
If you feel the benefits of deploying it outweigh the baggage of the beta release, an ever increasing amount of information can be found here:
http://itninja.com/link/here
Craig --<>.
http://itninja.com/link/here
Craig --<>.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.