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.


The AuthLite installer will fail unless the Microsoft .NET framework is installed on the system (version requirements vary by AuthLite version). If your workstations don't already have this installed, then you will need to push the appropriate version.  If you do this with a GPO, make sure the framework install 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.

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_x64.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 AddressWidth FROM Win32_Processor WHERE AddressWidth ='32'

    (64 bit):
    SELECT AddressWidth FROM Win32_Processor WHERE AddressWidth ='64'
  • 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).