In medium/large organizations, visiting each workstation to install the AuthLite software is not practical. This article contains pointers on deploying with Group Policy Objects (GPO)

This article contains notes on deploying the AuthLite_installer_Win32.msi and AuthLite_installer_x64.msi with Group Policy Objects (GPO) If you are already familiar with using GPO to deploy software, many of these points may be redundant to you. These notes highlight issues and decision points you may encounter, but should not be considered a replacement for a good grounding in GPO deployment concepts.

Prerequisites

The AuthLite installer will fail unless the Microsoft .NET framework version 2.0 or higher is installed on the system. If your workstations don't already have this installed, then you will need to create a GPO to install the framework as well. Follow the steps presented here to create an .msi file for the framework, then create a GPO to deploy it, using the pointers below.

You will need to make sure the framework .msi runs before the AuthLite .msi, otherwise the latter will fail. You can do this by setting the framework GPO's link number higher than the AuthLite GPO.

Setup EXE to MSI

The AuthLite version 1 core software is distributed as an .msi file wrapped inside a setup .exe file.

So, in order to apply the AuthLite install with a GPO, you need to get the actual .msi file. You can do this by one of two approaches:

  1. Extract the .msi file out of your AuthLite_Setup_Win32.exe or AuthLite_Setup_x64.exe. You can do this by opening the .exe as an archive with 7-zip and extracting the .msi inside the archive.
  2. Our customer support can give you links to download the latest .msi files from our web site.

AuthLite version 2 already ships with .msi install files.

GPO deployment tips

  • Your GPO's should assign the package to computers, not to the users.
  • To apply a policy to your workstations, the computer accounts need to be placed in an OU instead of the default "Computers" container in AD
  • The computer accounts of the workstations must be able to access the .msi files over the network. If your workstations' App or System event logs show error 1612, that means the installer could not be accessed! The recommended way to set this up is to create your own DFS share. For testing purposes you can put the .msi files in the SYSVOL area of the domain controller, which can then be assigned and accessed as \\YourDomainName\SYSVOL\your.domain.fqdn\AuthLite_installer_Win32.msi. Microsoft highly recommends not doing this in production, due to issues as noted in this kb
  • AuthLite uses a separate installer file for 32 and 64 bit machines. If you have 32 and 64 bit machines in your environment, you should create a separate GPO for each case, so you can use use a WMI filter to make sure the right installer is applied to the right machines. The correct WMI filter settings are, in the root\CIMv2 namespace:

    (32 bit): select * from Win32_Processor where Architecture = 0
    (64 bit): select * from Win32_Processor where Architecture = 9
  • Once you apply your GPO's to an OU containing workstations, those machines will try to install the software when they are next rebooted. Check the workstation event log for troubleshooting.
  • To make logons faster, workstations apply GPOs asynchronously by default, as noted here. This means if a user logs on right away, it may take an additional reboot before the install is attempted. To mitigate this, you can set the GPO item Computer\Policies\Administrative Templates\System\Logon "Always wait for the network at computer startup and logon". However if you are assigning that policy at the same time as the software install, then the "wait" policy itself will be applied asynchronously the first time, resulting in the same issue (another reboot needed).