Using Internet Component Download in an Enterprise environment

Hi everybody!

As promised, here’s a blog post detailing how to make use of the Internet Component Download feature and a working example on how to benefit from its advantages together with the ActiveX Installer Service.

The most common way to invoke an ActiveX control from a webpage is to use the object element. This element has an attribute called codebase that indicates the browser where to download the control for installation. We provide a way to override how the codebase attribute is used to download a given control, by using Group Policy (CodeBaseSearchPath). The main goal of this setting is to redirect the search for downloading the control to an internal server, effectively allowing the administrator to limit the locations from where ActiveX controls can be installed.

The following article provides all the details on how the Internet Component Download feature works: https://msdn.microsoft.com/pt-pt/library/Aa741211.aspx

The Scenario

As mentioned in the previous blog post [Guidelines on enabling, configuring and troubleshooting ActiveX Installer service (Axis)], when the Internet Component Download mechanism tries to obtain a particular control, it sends a POST request with the CLSID in the body (amongst other information, like the version it’s looking after). This means that we need to have some logic on the server that handles this POST request, so the correct control can be serviced to the browser. This is basically what is called an object store. Moreover, it’s also important to handle the subsequent GET request the ActiveX Installer Service will issue: the following example also includes logic for that.

Code sample

One code example of an object store implementation can be found at https://controlstore.codeplex.com. There are multiple conditions we need to ensure, in order to have an implementation like this working, both on the client and on the server.

Client-side configuration

In the client, we just need to be sure that the CodeBaseSearchPath includes the URL that points to our object store. Below is a screenshot of the group policy where you can configure the code download path:

Figure 1: GPO Location: Windows Components\Internet Explorer\Corporate Settings\Code Download

The CODEBASE identifier above instructs the browser to use the codebase attribute in the respective object element from the webpage that tries to instantiate the control. The CODEBASE identifier can be remove from the search list, which will effectively force controls to be downloaded only from the local server. This solution will allow your internal clients to get the object from the server defined in option path.

Server-side configuration

This object store assumes the following pre-requisites on the server:

• The controls need to have the following naming convention: {CLSID}control_name.extension (the extension can be CAB, DLL or OCX)
• A folder under wwwroot needs to be created to host the controls, named "ActiveX" (The above configuration can be changed in the currentDir variable in the controlstore.aspx source sample to fit your needs)

Here’s how the folder hosting the controls would look like:

If you are uncertain on the CLSID value for a given control, there’s a few ways to obtain that information:

• Obtain it from the object element in the webpage where you install it from
• If a CAB file (the most common), the INF file inside it contains a clsid identifier for the control in the package

Wrapping up

The final step is to configure ActiveX Installer Service settings so your users can install the controls you wish. With this approach, you simply need to add the host where your object store is hosted to the “Approved Installation Sites for ActiveX Controls” policy setting, since all needed controls are hosted there. This allows for a simple configuration and an increased control over what exactly is available for the users to install.

This object store example doesn’t handle the installation of Non-Admin ActiveX controls: these types of controls are not commonly used and they don’t require administrative privileges to be installed, so the impact should be minimal.

Related Article:

Guidelines on enabling, configuring and troubleshooting ActiveX Installer service (Axis)

This blog has been provided to you by António Pinho, IE Support Engineer.

Comments

• Anonymous
  January 06, 2013
  Security is the primary reason one should use CodeBaseSearchPath redirection then add AXIS (Microsoft ActiveX Installer) and you have a complete solution. Too many admins get caught up in trying to configure the GPO's for AXIS only to find it isn't working because they missed a step :-(Good article but when it comes to managing the ActiveX Control deployment I find it much easier to use this 3rd party solution at CodeBaseSearch.      secure.codebasesearch.com