MSI doesn't know where to install it's reg keys?
I'm have a package thats installing as it should when installed from a simple shortcut/launching the MSI. When I install the same MSI through Zenworks it appears to run correctly but as it turns out none of the reg keys are being installed correctly.
With the working install it appears to be launching the action WriteRegistryValues as it should.......
WriteRegistryValues: Key: HKEY_CURRENT_USER\Software\Classes\CLSID\{FE38753A-44A3-11D1-B5B7-0000C09000C4}
........but when thought ZENWorks the same line (and all the others) the same line appears like this........
WriteRegistryValues: Key: \Software\Classes\CLSID\{FE38753A-44A3-11D1-B5B7-0000C09000C4}
.........without HKEY_CURRENT_USER at the start. (which is the same for all registry values.
Does anyone know if there is a property or something else that detemines this settings (ALLUSERS being set as 1/2 doesn't change anything apart from HKEY_CURRENT_USER becoming HKEY_LOCAL_MACHINE in the working install)?
I can post the two logs if required.
Any suggestions would be appreciated !
Cheers, Mike
With the working install it appears to be launching the action WriteRegistryValues as it should.......
WriteRegistryValues: Key: HKEY_CURRENT_USER\Software\Classes\CLSID\{FE38753A-44A3-11D1-B5B7-0000C09000C4}
........but when thought ZENWorks the same line (and all the others) the same line appears like this........
WriteRegistryValues: Key: \Software\Classes\CLSID\{FE38753A-44A3-11D1-B5B7-0000C09000C4}
.........without HKEY_CURRENT_USER at the start. (which is the same for all registry values.
Does anyone know if there is a property or something else that detemines this settings (ALLUSERS being set as 1/2 doesn't change anything apart from HKEY_CURRENT_USER becoming HKEY_LOCAL_MACHINE in the working install)?
I can post the two logs if required.
Any suggestions would be appreciated !
Cheers, Mike
0 Comments
[ + ] Show comments
Answers (4)
Please log in to answer
Posted by:
nheim
16 years ago
Hi Mike,
do not know ZenWorks, but i assume, it uses a own account with admin rights on the clients, to do its work.
Therefore, you would have to remove the 'ALLUSERS' property. See: http://msdn2.microsoft.com/en-us/library/aa367559.aspx
But this wouldn't make sense, because this settings would all go to the Zenworks account, where they would be useless.
But the best would be to let this settings go to the HKLM\Software\Classes hive, because the
HKLM\Software\Classes and the HKCU\Software\Classes hives are merged together to the HKCR hive. So, if this settings should go to all users on the machine, install them to HKLM.
As i see, this GUID belongs to the the MScomctl2 type library. Are you sure, you need it to install? This should be already on a actual system, i think.
Hope this gives you some ideas.
Regards, Nick
do not know ZenWorks, but i assume, it uses a own account with admin rights on the clients, to do its work.
Therefore, you would have to remove the 'ALLUSERS' property. See: http://msdn2.microsoft.com/en-us/library/aa367559.aspx
But this wouldn't make sense, because this settings would all go to the Zenworks account, where they would be useless.
But the best would be to let this settings go to the HKLM\Software\Classes hive, because the
HKLM\Software\Classes and the HKCU\Software\Classes hives are merged together to the HKCR hive. So, if this settings should go to all users on the machine, install them to HKLM.
As i see, this GUID belongs to the the MScomctl2 type library. Are you sure, you need it to install? This should be already on a actual system, i think.
Hope this gives you some ideas.
Regards, Nick
Posted by:
jmcfadyen
16 years ago
theres a couple of issues with Zenworks.
ZFD4 uses the local system account for deployment. (no access to network)
ZFD6 has the ability to use local system and or an elevated context which mimics a full administrator account. (optional)
If you have the ability to use ZFD6 then elevate the install context to full admin.
are you currently using an MSI object or a AOT based object ? This also determines how the installing user context works and as you know how the Zen healing crap works as well.
One thing you may or may not also be aware of is that Zen 4 doesnt perform user based self healing. So you need to implement active setup to handle all user state repair.
Zen 6 implemented a "bug" as a fix to handle the lack of forethough from the ZFD4 team. As such all MSI's initiate a full reinstall for ZFD6 as a "fix" for the lack of user state repair offered with Zen 4.
Im not sure which one is worse but I guess you can decide that.
ZFD4 uses the local system account for deployment. (no access to network)
ZFD6 has the ability to use local system and or an elevated context which mimics a full administrator account. (optional)
If you have the ability to use ZFD6 then elevate the install context to full admin.
are you currently using an MSI object or a AOT based object ? This also determines how the installing user context works and as you know how the Zen healing crap works as well.
One thing you may or may not also be aware of is that Zen 4 doesnt perform user based self healing. So you need to implement active setup to handle all user state repair.
Zen 6 implemented a "bug" as a fix to handle the lack of forethough from the ZFD4 team. As such all MSI's initiate a full reinstall for ZFD6 as a "fix" for the lack of user state repair offered with Zen 4.
Im not sure which one is worse but I guess you can decide that.
Posted by:
michaelnowell
16 years ago
Thanks for your replies.
nheim, I've tried installing with and without the ALLUSERS setting being present and it still makes no difference. I don't mind where the registry keys get installed, for some reason it's not installing them anywhere, either in HKCU or HKLM.
I'm currently using ZFD6 and installing via a MSI object. However, if I use an AOT object and simply launch the install from this then I still get the same problem.
jmcfayden, you mentioned evelating the install context to full admin. I assume that this is a setting that affects all installations in general and not just the application object that I have the problem with. I don't know where this setting can be changed? Would you be able to shed some light and let me know where I can change this? ;o) (I'm asuuming that it's the Excutable security level)
Cheers, Mike
nheim, I've tried installing with and without the ALLUSERS setting being present and it still makes no difference. I don't mind where the registry keys get installed, for some reason it's not installing them anywhere, either in HKCU or HKLM.
I'm currently using ZFD6 and installing via a MSI object. However, if I use an AOT object and simply launch the install from this then I still get the same problem.
jmcfayden, you mentioned evelating the install context to full admin. I assume that this is a setting that affects all installations in general and not just the application object that I have the problem with. I don't know where this setting can be changed? Would you be able to shed some light and let me know where I can change this? ;o) (I'm asuuming that it's the Excutable security level)
Cheers, Mike
Posted by:
jmcfadyen
16 years ago
I dont work on a Novell Site any longer but the setting is called
Run MSI in workstation context. This setting is often problematic if network is not setup correctly. In order for this setting to actually work the Workstations need rights back to the network resource (application file share)
So deploy the app via workstation group, running in workstation context, setting workstation permissions to the app folder share.
Incidentally using this method is one means to make the full reinstall of applicaiton per user. (just a screwed up Novell thing)
I tried to explain the issue to Novell support but they deemed it a feature not a bug. So eventually I gave up trying as it was clear they didnt have anyone on board whom understood msi's in the same context as myself.
Run MSI in workstation context. This setting is often problematic if network is not setup correctly. In order for this setting to actually work the Workstations need rights back to the network resource (application file share)
So deploy the app via workstation group, running in workstation context, setting workstation permissions to the app folder share.
Incidentally using this method is one means to make the full reinstall of applicaiton per user. (just a screwed up Novell thing)
I tried to explain the issue to Novell support but they deemed it a feature not a bug. So eventually I gave up trying as it was clear they didnt have anyone on board whom understood msi's in the same context as myself.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.