Ok Ninjas,I've been fighting a problem for several days, now and for the life of me I cannot find a solution. I'm hoping someone has come across this...We have a PACS software that we install on Radiology PCs. This software includes a "fat" client, as well as ActiveX controls for using a web-based client. The "fat" client is working fine. However, the ActiveX control will not load. The web interface just prompts us to download and install the software again. This is an EXE installer, not a standard ActiveX install prompt. This is on Windows 7 SP1 with IE9. It happens on both 32-bit and 64-bit.A little bit of background - We had previously been using a master image built on the Dell OEM install DVD. On that image, this software works perfectly. However, we just recently had to change over to an image built from Volume License install DVD. It's only on PCs built from this new image that have the problem. I prepared the images the exact same way, but I think I must have missed something.I have done all the usual ActiveX troubleshooting - site is in Trusted Sites zone, all the security for that zone is set to low - signed and unsigned ActiveX controls are pretty much all allowed. Scripting of controls is allowed, etc. The ActiveX is 32-bit only, so I've also made sure we're loading the site in the 32-bit browser.Here's where it gets strange, though... If I load up my pre-sysprep'd version of this image and install the software, the ActiveX controls work fine, even using the default settings for Security zones. Of course, with default settings, I get prompted to allow the control to run. I thought maybe something was getting changed by the sysprep process, so I again reverted back to the pre-sysprep snapshot (I used a VM to build it), sysprep'd it, then rebooted and allowed it to go through the process of booting. Once done, I again installed the software, and again it worked fine.The problem only seems to occur once I've captured and re-imaged from the K2000. Even just a basic deployment with only the minimal tasks of creating partitions.One clue as to what might be the cause on the deployed image is, after installing the software, the Allow prompt now shows it as "Control name is unavailable" from "Unavailable" insted of the actual control name and publisher name. The previous image, as well as my pre-sysprep'd new image show the control name and publisher just fine.EDIT: Thanks to PressAnyKey for suggesting running regsvr32 on the ocx file. As usual I was just overthinking the problem. However, from that comes a new question... why can't the installer register the OCX on it's own, as it clearly was able to do on my previous image, and also the pre-deployed version of my new image?
Answer Summary:
Cancel
1 Comment   [ + ] Show Comment

Comments

  • Sorry about the formatting, it was lost when I edited my question.
Please log in to comment

Answer Chosen by the Author

1
Hi,
silly question, but have you tried with regsvr32.exe %PathToActiveXControl% on your image?
It may be that not all required registry keys (CLSID, TypeLibs etc) are not present.
During the creation of the re-imaged OS are any user specific registry keys being removed automatically? Some ActiveX controls (dependent on the context) may be adding their information to HKCU...

Cheers
Phil
Answered 11/09/2015 by: Pressanykey
Red Belt

  • Wow... I feel really stupid now... That worked... The funny thing is, I thought about trying that, but at one point had done an export of the relavent registry entries on a working machine, vs a non-working machine and when I did a line by line compare I didn't see anything missing. The next question would be, though, why was the installer unable to register it on it's own?
  • I should also point out that this software is always installed AFTER the PC is imaged. This isn't being stored in the image.
    • It may depend on the context in which regsvr32 / installation routine is executed...
      • Didn't seem to make a difference. When the problem was initially discovered, it had been installed by the K1000, so the installer ran under the local system context. In my testing the installer was run by me logged in as local Administrator. When I ran regsvr32, it was also as local Administrator.
Please log in to comment

Answers

0
Is the fat client in the form of an MSI ?   If so, are you installing it with the ALLUSERS property set to 1 ?  
On the DELL image, are you able to check the registry for any RUN or RUNONCE entries before the machine boots for the first time  (You would need to copy the registry files from the image to another machine and mount them to check).

Anything that registers in "user" context cannot be achieved (easily) from a system based installation - it inevitably requires something to run later when the user account is loaded.
Answered 11/11/2015 by: EdT
Red Belt

  • The installer for the fat client also installs the OCX files. It comes in either an MSI for silent installs, or an EXE for interactive installs. We are using ALLUSERS=1 for the MSI. The web interface actually attempts to load 3 different ActiveX controls. It's only the initial one that required manual registration. The other two detected and ran fine after manually registering the first.
Please log in to comment
0
>why was the installer unable to register it on its own?
I'd wager it used Regsvr32 to do that. A properly-authored Installer would do things the right way, not the lazy way.
Answered 11/11/2015 by: VBScab
Red Belt

  • I'd suspect that, too, if all 3 OCX files installed required manual registration, but only the initial one needed it. The other two that are loaded by this application's web interface initialized fine.
Please log in to comment
Answer this question or Comment on this question for clarity