4 replies to this topic

[twistedpair]

All,
I have an installer that works fine when installing as admin, but not when
deploying through AD. It seems to be timing out when registering a DLL.
Anyone run into this? How do I fix it?

Detection of product '{86BA3D18-DA4A-4656-9A8F-EFE7A8A5C77B}', feature
'WIFEAT00000001' failed during request for component
'{45763C8A-0F13-42A9-8E7A-C3E2D3ABC402}'


MSI (s) (88:C4) [18:36:02:628]: Executing op:
RegSelfReg(File=crtslv.dll,FileID=WIFILE00000300)
MSI (s) (88:C4) [18:36:02:746]: Executing op:
RegSelfReg(File=cubedefmodel.dll,FileID=WIFILE00000356)
MSI (s) (88:C4) [18:36:02:993]: Executing op:
RegSelfReg(File=filedialog.dll,FileID=WIFILE00000388)
MSI (s) (88:C4) [18:36:03:280]: Executing op:
RegSelfReg(File=objectfactory.dll,FileID=WIFILE00000410)
MSI (s) (88:C4) [18:36:03:418]: Executing op:
RegSelfReg(File=pageObjectModel.dll,FileID=WIFILE00000617)

Maybe I'm just reading the problem incorrectly? Any ideas? Also, I've ensured that it installs with elevated (system) privs through group policy.

Thanks!
Pair

[twistedpair]

Well whatever the problem was, I just turned off self-registration for the DLL's. I created the installer by doing a capture, so hopefully it captured all the necessary information to make windows THINK that it had already been registered.

HOPEFULLY.

-P

[Glytzhkof]

This could have been a registration order problem (interdependent files), or perhaps even a conditioning problem such as the use of AdminUser instead of Privileged in the conditions for the self reg action. Personally I always condition ISSelfReg type custom actions with the condition Not Installed AND Privileged to avoid the self registration from happening during self repair, and only take place during initial install.

[twistedpair]

Good tips! I'll give that a try as well. I am pretty sure it isn't a sequence issue. For that to happen, the sequence would need to change when doing a Group Policy deployment, versus manually which I would think would be fairly abnormal.

Hadn't thought of the conditions though, and it didn't occur to me that I needed to check that. Thank you!

-P

[Glytzhkof]

If the group policy deployment is also done in silent mode, this adds another potential cause of problems. The MSI could throw modal dialogs from custom actions (that don't obey the rules of a silent install) or there could be custom actions sequenced outside InstallInitialize and InstallFinalize that won't run properly and cause things to lock up. Generating a verbose log: http://www.installsi...ifaq/a/1022.htm
and using the MSI log analyzer tool helps most of the time: http://msdn.microsof...ilogutl_exe.asp