In this Blog you will find instructions on how to locally enable, configure and troubleshoot the AXiS service. The ActiveX Installer Service (AXIS) was first introduced in Windows Vista and currently available in Widows 7 and Windows 2008 R2. The service purpose is to allow IT Admins deployment of ActiveX® controls by using Group Policy on computers in an organization. By default, standard user accounts do not have permission to install ActiveX controls. You can use this blog post to guide you on how to enable, configure and troubleshoot ActiveX Installer Service GPO deployment.
- One of the prerequisite is to review the document available in the following links: Administering the ActiveX Installer Service in Windows 7: http://technet.microsoft.com/en-us/library/dd631688(v=WS.10).aspx
- Second prerequisite is to have a standard local user account created so you can perform the test in step #2.
1. Configuring the AXIS Service Group Policy
|SUGGESTION: If you would like to experiment with a working and signed ActiveX control, you can use the Microsoft Catalog Update ActiveX control available from http://catalog.update.microsoft.com/v7/site/Install.aspx|
- Login to the PC as a local admin
- From Start / Run type GPEDIT.MSC to launch the Group Policy Editor console
- Go to Local Computer Policy / Computer Configuration / Administrative Templates / Windows Components / ActiveX Installer Service
- Double click on Approved Installation Sites for ActiveX Controls
- Click Show… button
- On the left column enter the desired host URL and on the right column enter “2,2,1,0” (To get familiar with the values, please review this document)
- If the host URL is” http://www.abccompany.com/testapp/activex” then only enter “http://www.abccompany.com” into the left side of the table.
- If the host URL is “https://app1.testapp.abccompany.com” then add “https://app1.testapp.abccompany.com”.
- If the host URL is “https://app2.abccompany.com/testapp2.htm” then add “https://app2.abccompany.com”
TIP: If you want to use wildcard please read the document referenced at the top of this blog post and search for “Configuring the ActiveX installation policy for the trusted sites zone”. Also pay close attention to the Security note in this paragraph that has important information as it has cause confusion.
- Click Ok. See Screenshot below:
- Click OK again
- Close GPEDIT
- From an elevated command prompt run “GPUPDATE /FORCE” <ENTER>
NOTE: The GPUPDATE /FORCE command is use to force the Group Policy update on the client, it may take 10-15 minutes for this to go into effect. Logging off and on again or restarting the machine after running the command may make it happen more quickly!
- FYI: Axis GPO Registry Location is under: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\AxInstaller
- Logout or Restart your machinePC
1.1 Testing the AXIS Configuration
Before we start testing, lets first do some pre-work on the client machine to help gather some data!
- Install Fiddler on the test PC (www.fiddler2.com)
- Select Fiddler2
- Configure Fiddler to intercept HTTPS traffic
- Launch Fiddler
- Click Tools > Fiddler Options
- Click on the HTTPS tab
- Enable the “Decrypt HTTPS traffic” setting
- Click YES to the “WARNING: Sharp Edges! Read Carefully!” box
- Click yes to the “Security Warning” box
- Click OK to the “Fiddler Options” box
- Close Fiddler
- If you receive an error that reads something to the effect of “The add-in failed to load properly” (or something similar) then the ActiveX control did not load correctly and you should consider gathering the following information and to help you investigate the situation.
2. Now, we are ready to start testing AXiS Configuration…
- Login as a user with Standard User rights
- NOTE: IT IS VITAL THAT YOU DO NOT LOG IN WITH A USER WITH LOCAL ADMIN RIGHTS OTHERWISE ALL TESTING WILL BE NEGATED!!!
- Launch Fiddler
- Click on icon in the Fiddler menu bar that looks like IE’s icon with the word “Browse” next to it. This will launch Internet Explorer.
- Clear the IE Temporary Files by using the Ctrl+Shift+X or from Tools / Clear WinInet Cache or by Clicking on the icon Clear cache
- Internet Explorer will open to a blank page (about:blank). Type the URL (Example: http://www.abccompany.com/testapp/activex/ ) to the web based application you are testing the ActiveX control and press <ENTER> to navigate the site as you normally would to trigger the ActiveX control to load. At some point you may see (depending on whether the ActiveX control is digitally signed and by who) a prompt towards the bottom of the browser screen to install the ActiveX control. Click the button/option to install the ActiveX control and follow any prompts you normally would.
- A popup on the bottom of your page may look like the screen below.
- Adding the site to the Trusted site will help bypass the warning in the screenshot below! The site will default to the Internet Zone, which has the highest restriction setting in IE.
- If the ActiveX control installs and works as expected then there is no further action is needed other than moving the steps to the production environment. If you encounter any issues, please use the Quick troubleshoot guide below.
3. Quick Troubleshoot guide you can use when troubleshooting the ActiveX Installer Service
Let’s assume you encounter some problems with the ActiveX installation and need to troubleshoot the scenario. Below are a few tips you can use to help collect some data.
- In the Fiddler application click File > Save > All Sessions Save the Fiddler log to your desktop and name it something easy to identify such as the name of the web application you are troubleshooting (i.e. MyApp.saz).
- Close Fiddler
- Enable Logging by: Click on Start > Run and type “EVENTVWR.MSC” and press <ENTER> to open the Event logs
- Navigate to Event Viewer (Local) / Applications and Services Logs / Microsoft / Windows / AxInstallService / Log.
- Right mouse click on Log and click on “Save All Events As”
- Save the Event Viewer log to your desktop and name it something easy to identify such as the name of the web app you’re troubleshooting (i.e. MyActiveXApp_AXIS_Event_Log).
- Select the option that reads “Display information for these languages” and click OK
- If you are having trouble isolating any issues with the AXiS Service, please consider opening a case with Support and sharing the collected data for further assistance.
- The Event Viewer log with the .evtx extension
- The Fiddler log with the .saz extension
- What is the ActiveX control you are trying to install
- Captured Screenshot of any errors
Additional things to look for:
- Identify what event logs are being generated by the ActiveX Control Service in the Event Viewer.
- The article Administering the ActiveX Installer Service in Windows 7: http://technet.microsoft.com/en-us/library/dd631688(v=WS.10).aspx outline the possible event log errors.
- Any script or windows popup errors?
- Get a screenshot of any script or window popup warnings or errors
- Understand if other group policies are being implemented that is preventing the users from downloading the ActiveX control?
- Is this a Terminal Server Implementation (Windows 2008 R2)?
- Is the Code Download error log generated in the Internet Temporary Files folder?
- Use the article How To Force Creation of an Internet Code Download Log http://support.microsoft.com/kb/271451 to help you get error logs.
Quick article reference:
- 2506591 Group Policy settings for the ActiveX Installer Service do not work on Windows 7-based computers when the Domain User group is added to specific local groups such as Network Configuration Operators
WHAT YOU MUST KNOW ABOUT THE ACTIVEX INSTALLER SERVICE (AxiS)
- It is important to point out that the AXIS component will only assist in installing ActiveX controls which contain CAB, OCX, and INF files for users with Standard User rights. It will NOT install ActiveX controls which attempt to kick off EXE, MSI, or any other type installation!
- The AXIS component which uses WinHTTP, will not install controls from locations that require Forms / Cookie based authentication!
- This is very important as many administrators invest lots of time looking for “What is wrong with the AXiS” implementation only to realize their Form Based Authentication is causing the implementation not to work. In addition, Basic Authentication scheme is not supported by the AXiS service and results in installation failures as well.
- Know that the AxIS installer is a separate process from IE, it cannot use credentials stored in IE’s credential cache.
- Please note that you can add ActiveX Installer Service Support to 2008 R2 with the following update: 2508120 an update that adds the ActiveX Installer Service to Windows Server 2008 R2- http://support.microsoft.com/kb/2508120/EN-US
- If you choose to add the exception list manually via the registry instead of using the group policy you must stop and restart the AxInstSV service. You must do this to get the new added items propagate to other registry keys.
- Beware that, notes from TechNet article “Administering the ActiveX Installer Service in Windows 7” contains wrong information regarding the parameters and values you can use. The information we found to be incorrect is under the Table 4: Value for HTTPS errors exceptions below the Sample Configuration.
The information from the TechNet article has created confusion on how to implement the 4 https certificate exception errors and in most cases, you will see customer using the incorrect parameter and values, like this one: 2,2,1,0×00000100||0x00001000||0x00000200||0x00002000
This is incorrect, as this the logical combination should be done in the calculator; and its result is then configured in the policy. For this example: 2,2,1,0×00003300 represents all 4 exceptions!
NOTE: A request to clarify the use of these parameters and values was submitted but in the meantime, we wanted to share it with you to help get things moving along when troubleshooting and deploying ActiveX controls using the ActiveX Service in your control environment. The basis is that the least secure configuration of the ActiveX Installer Service is when an administrator configures the service for a site with the following characteristics:
Lowest security settings
- Use an HTTPS site as the host URL.
- Automatically install ActiveX controls that are signed.
- Automatically install ActiveX controls that are signed by a certificate in the Trusted Publishers store.
- Prompt the user to approve the installation of an unsigned ActiveX control.
- Allow the following HTTPS connection-errors when downloading the control:
- HTTPS-certificate issued by unknown certification authority
- HTTPS-certificate has an invalid common name (CN)
- HTTPS-certificate has an invalid date (e.g. it has been expired)
- HTTPS-certificate has an improper certificate use.
The correct value for all 4 exceptions will look like this: 2,2,1,0×00003300
The simple math is:
When to use CODEBASE
We recommend that you consolidate the ActiveX controls you use in your organization to a central server. The location where a Web site hosts an ActiveX control is called a CODEBASE. Normally, the CODEBASE is specified in the Web page, and the installation process retrieves the ActiveX control from that location.
In managed enterprises, you can use Group Policy to override the CODEBASE that is specified within the Web page to redirect to an internal server. Using this setting allows you to easily manage which ActiveX controls users can install by consolidating the ActiveX controls onto a central server; if the server is an HTTPS server, you also satisfy the previous best practice, only use HTTPS host URLs.
You can configure a common Group Policy setting to redirect all ActiveX control installations to a central server in your organization. You can do this by using the CodeBaseSearchPath registry key. For more information on the CodeBaseSearchPath see Implementing Internet Component Download (http://go.microsoft.com/fwlink/?LinkId=90677).
We will come back with another blog that expands the use of ActiveX Service and implementing the Codebase solution for use in an enterprise environment.