Skip to main content
  1. Posts/

ActiveX Considerations for Siebel HI deployments

·3 mins

High interactivity client started as the cutting edge technology to provide rich client functionalities during the early 2000’s. I will not getting into how much relevant to this age when JavaScript can create desktop applications, But it is suffice to say that HI had a crucial role to play for a long long time.

One of the headaches of HI is the Deployment. Though it is way better than deploying “true” client applications like a program with an installer, or even a Siebel remote client, it does have its idiosyncrasies.

One of them is the deployment of ActiveX controls to the client browser.

ActiveX controls best supposed to eliminate all client management problems by themselves. They get installed on the client browser on demand (e.g., when user accesses the application for the first time), they get upgraded without any involvement from the deployment team ( same procedure), and it is fairly easy to get everything back on track even if the client does something crazy (e.g. run “format c:” in command prompt).

But, ActiveX has been traditionally insecure since it enables nice privileges to the client like access to the locally installed applications. This has made organisations vary, and they typically prevent ActiveX controls to be installed on user machines.

This presents a problem to Siebel.

Enable client machines to accept ActiveX controls. #

First and foremost is the security aspect set in Internet Explorer.

Make sure signed/unsigned ActiveX controls can be downloaded and executed by the client computers. You choose a signed ActiveX controls if you sign the controls that you want to deploy using approved digital certificates. This is typically set as an enterprise-wide standard, and you’d have to make small adjustments to follow that standard.

ActiveX control Security settings in Internet Explorer

Plan for ActiveX updates during Siebel upgrades #

Typically the development team has admin access on their local computers. They do not end up testing how applications are deployed and used by the end-users.

When the final application gets deployed to the end-users, it is quite common to see the following error.

Your version of the Siebel High Interactivity Framework for IE, required for use of this Siebel application, may not be current. In order to download a current version of the Siebel High Interactivity Framework, please ensure that your browser security settings are correct and then log in to the application again. Consult your system administrator for details about the Siebel High Interactivity Framework and correct browser settings.

This happens due to mismatch between the installed ActiveX version, versus the expected ActiveX version.

Even if the users have admin rights on their computers, the message pop-up dialogue does not allow them to provide the permission and to the install directly.

It can be solved in three ways -

  1. Customize predeploy.htm file for the specific implementation. Include all ActiveX controls that are required (e.g., calendar, smartscript editor) And install ActiveX as an admin activity during the deployment process. You could also ask the user to navigate to to a specific URL that points to predeploy.htm.
  2. Ask the user to delete the older ActiveX controls, and try accessing the application once more.
  3. Alternatively, just hold the Ctrl key while accessing the application

Unless you deployed ActiveX controls to all client computers, your users would need superuser privileges in order to install them.

In secure implementations, I recommend creating a deployment utility that can be used by the Windows administration team to do any client computer changes.