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 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).

MST Transforms

With some deployment systems (such as Group Policy) you can apply a transform (.mst file) to affect the set of features and properties selected.  We have published a few common requests here:

  • Turn on the NFC feature: NfcOn.mst
  • Don't install any Shortcuts to the Start Menu: NoShortcuts.mst
  • Force a DC install to AVOID all partition operations. This is useful as one component of a DC automated deployment, but you must manually ensure all partition operations still get completed (i.e. using ntdsutil and ldifde).  NoPartitionOperations.mst

msiexec Switches

The AuthLite MSI installer is run by msiexec.exe, so you can use all flags supported by that tool.  See Microsoft's msiexec documentation.

Property Automation

You can set certain properties from the command line to control installer behavior.  Call like:

AuthLite_installer_x64.msi PROPERTY=VALUE
  • NOSHORTCUTS=1 : Prevent all Start Menu shortcuts from being installed. Overrides feature selection.
  • CREATESCHEMA=0 : Prevent installer from trying to check and update the forest schema to support the current installer.  If you use this option you must manage the schema manually.
  • CREATEPARTITION=0 : Prevent installer from trying to create the AuthLite application partition.  You can use this if you are sure the partition is already set up and working, but the installer is having problems passing that step.
  • MACHINETYPE=MemberWorkstation : If you are trying to pre-install on a workstation image which isn't joined to the domain yet, or trying to remove from a machine that was parted from the domain, you can use this property to trick the installer into running as though the machine was on the domain.  Note this will not allow you to actually use AuthLite on a workgroup machine. It will still only work on domain-joined machines.

Feature Selection

To control which features are selected from the command line, you can invoke the installer like:

AuthLite_installer_x64.msi ADDLOCAL=DataManager,Nfc

Where the comma separated list of features after ADDLOCAL will be installed.  At the time of writing, AuthLite v2.4.10 has the following feature options:

  • Replica: On a DC, attempts to set the DC to have a replica of the AuthLite application partition. If you do not specify this feature, you must manually manage your replicas with ntdsutil, to avoid data loss!
  • DataManager: Installs the AuthLite Token Manager application and associated start menu shortcut. 
  • AdminAPI: Installs a shortcut to launch AuthLite Admin Powershell prompt.
  • AdminShortcut: Installs a shortcut to launch the AuthLite Configuration application.
  • YubiKeyProgrammerShortcut: Installs a shortcut to launch the AuthLite YubiKey Programmer application.
  • SelfProvisionShortcut: Installs a shortcut to launch the Enroll with AuthLite self-service application.
  • Nfc: Installs NFC reader support.
  • AuthLiteDriver: Installs the AuthLite Kernel Driver

Note that presence/absence of executables or shortcuts does not actually grant or restrict the access for accounts to read/write settings or token records. Control who has token access from the Administrative Groups setting in AuthLite Configuration.