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: http://msdn.microsoft.com/pt-pt/library/Aa741211.aspx
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.
One code example of an object store implementation can be found at http://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.
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.
This object store assumes the following pre-requisites on the server:
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:
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.
Guidelines on enabling, configuring and troubleshooting ActiveX Installer service (Axis)