Problem after installing ActiveX Control using .msi installation package.

Question

I have customers on Windows 7 and IE8.  I have packaged my ActiveX Control using a .cab and .inf file so that when a user running IE with administrative privileges invokes the ActiveX Control, it installs in the Download Program Files directory in the normal way if it is not present or out of date.  So far this is well known behavior and has worked for years. 

So now, customers using Windows 7 want their users to be Standard users with no Admin privileges.  The standard download from IE using this method of course fails because the user doesn't have Admin privileges.  Again this is well known behavior.  I am working on a permanent fix to allow these Standard users to once again use this IE download as it always has.   In the meantime, of course, I need to get the customers running.  OK, so following all the great advice in these forums, I create an .msi file with everything embedded in it to install the ActiveX control in a subdirectory of the Program Files (x86) directory.  With our help, customers have figured out how to use this .msi to deploy the ActiveX control successfully on their client machines.   I even double-checked their registry, and all of the correct entries are there.  They are identical to mine after running the .msi.  If it would help I can reproduce the registry entries rather easily and post them.

However, when they go to use the ActiveX control, IE8 tells users that it wants to download the ActiveX using the original method.  It is like it is not recognizing that the proper CLSID of the ActiveX is already properly registered.  This behavior is identical whether the user logged into the client machine is an administrator or a standard user.  All users get this message on their Windows 7 client machines that used the .msi to install the ActiveX.

In my own Windows 7 machine, I can also run the same .msi from a network share, and it installs perfectly just like for the customers.  I have administrative privileges on my Windows 7 machine, and when I use the ActiveX control, it runs just like it always has recognizing the one installed by the .msi.  Of course customers, where the download is already known to fail, will have this new attempt to download also fail as expected. 

The trouble is, the user should never have been asked to download the ActiveX - it was already installed successfully.

So the scenario is simple.  .Msi is installed successfully on two machines.  In my case, I installed it - in the customers case, an administrative user installed it.  Now a user (a different user than the installer in their case) with administrative rights attempts to run the ActiveX.  In their case it keeps asking to download every time they try to run it.  Mine just runs as it always has.

So here is the kicker:  If they run IE as administrator, the request to download goes away, and it runs just like mine.  I am not running IE as administrator.

So here are my questions - Is there anything I can do to get this behavior on their machine to be like my machine?  Does the user who installed the ActiveX using the .msi have to be the same one to run it, so that this download request does not show up?

Can anyone tell me what specific right or permission is missing between running IE 8 normally and running it as administrator?  I do understand a bit about securty tokens and running elevated to get out of the IE sandbox.  Basically restated, why does IE8, running without the "Run as administrator" parameter, not recognize that the ActiveX is installed properly?

I see lots of questions in this forum about how to make msi's run automatically from IE with no administrative rights, but I am not trying to do that.  The .msi runs outside of IE prior to ever running IE.

Any insight would be very much appreciated.  Also if any more information would help, please let me know. I can even post my .inf file if it would help, although it looks very much like many others posted here for installing ActiveX controls.

Answer 1

Any chance it is the location that the msi file is installing the ActiveX in?  The msi installs in C:\Program Files (x86)\<MyControl>\<version>

What if the install directory was changed to C:\Windows\Downloaded Program Files?  Would this allow IE8 to recognize that the control was installed properly and not try to download it?

Answer 2

One other question I thought of for anyone that knows.  Does Running IE as administrator disable/override any of the UAC settings?  If so, is it specific ones or all of them?

Answer 3

Is there a chance a mismatch between the version requested from the IE page that is invoking the ActiveX vs the one being installed by the MSI could be causing this problem?

Why would starting IE as administrator cause this kind of problem to go away?

Stay tuned, I have corrected a version problem in a properties file of the Web App, and will test and report back whether that is the cause.  If that is it, will I ever be embarrassed.

The old adage of Garbage in - Garbage out still as relevant as it ever was.   :*)

Answer 4

Yes that was it.  The run IE as administrator "fixing" the problem was a red herring.

A property file holding the latest version of the ActiveX was set incorrectly.  It was 3 patch versions higher than actually existed.  It was set that way by the customer because a readme used for the installation of the last delivered patch had a typo in it. 

Version mismatch does make the most sense here too. 

Answer 5

Hi PJK_Ventyx,

I'm glad to see that you have worked out the issue. Meanwhile, thank you for sharing knowledge and experience here. That may help others who encounter similar questions.

Regards,

Damon

---

Damon Zheng [MSFT]
MSDN Community Support | Feedback to us