autoit scripter   AutoIt is a freeware scripting language for Windows (see http://www.autoitscript.com/autoit3/ for details and documentation).

AutoIt Applications

See other uses and applications of AutoIt (VPN connections, setting IP addresses, securely erasing free space).

AutoIt Software Installations

AutoIt is one resource for automating Windows GUI installs. It can be used to programmatically step through installer windows without user input. This method is ideally designed for batch files and other automations. I currently use it to standardize and simplify Windows applications' installations. It not only installs faster and with less interaction, it maintains standardized settings and eliminates user error during installation.

Deployment Systems

To install software automatically, one must write a script for each installation (typically each product version). These scripts are run with the AutoIt executable one by one. By storing all of the various program files on the network, no CDs are necessary. By scripting product licenses keys to be typed in mechanically, one no longer needs to have a key written down in front of them. Software upgrades can be updated at one network location and deployed swiftly to any place with network access and privileges. This saves on media duplication, storage, security, and use. Machines do not require CD, DVD, floppy, or USB drives for software installation. For those operating the installation, since it is automated, no knowledge of settings or configuration is needed. Installation can be delegated safely to less experienced personnel. There are many wins for automating: time, hassle, standardization, and delegation.

To reap an even greater level of benefit, it is worthwhile to simplify the next logical level up, that is, simplify the execution of multiple scripts. That way, one need not run the AutoIt executable and each script manually. I've been involved in two instances of this project that have implemented this in different ways. Both generate a batch file to sequentially execute several scripts one after the other. As software installation can run into significant errors when multiple programs are installed simultaneously, sequentialism is important. The batch file ensures that the next script is not run until the last call returns.

Both systems require access to the network share (typically restricted so that access to licensed software is limited). The SQL backend allows for tracking software inventory and recording what programs a machine got the last time. The application installer requires far less infrastructure. The batch files call the AutoIt program and a particular script. The script downloads the installer from the network and runs it locally, stepping through windows, typing in user information/keys, and even checking for updates or cleaning up shortcuts in some cases.

PHP/SQL

The first instance of the project implemented a php website with a database backend. One could log in to a secure server and look up a computer and select software from a list. This list was generated with SQL queries so as each application and script path is added to the database it appears in the list. Selecting items and hitting the submit button would create a batch file with commands to execute the scripts for the programs selected. When this batch file is run on the local machine the software installs.

autoit with php

Application Installer

The second instance of the project implemented an application that would generate the batch file to the local desktop. One runs the Application Installer, selects the programs desired and hits the install button. The batch file is created on the desktop with execution commands for the programs selected. When this batch file is run on the local machine the software installs.

This process was modified with the release of Windows 8. Now that UAC is not easy to turn off, the Application Installer has been adapted to run with UAC on or off. Instead of creating a batch file to run each script sequentially, the batch file kicks off an AutoIt script that then runs each program install script sequentially. This is because UAC would prompt for each AutoIt call, and if they were pressed in quick succession, all the installs would be run at the same time. With UAC on, the batch file goes to the next line after the prompt is pressed instead of when AutoIt finishes the script. By encapsulating all the installation calls into one script, the user is only prompted once at the beginning. AutoIt then controls the execution timing and order of the installations (as written by the Application Installer). One is prompted for network credentials the first time on a machine, but not on subsequent runs. So the user experience has been streamlined from pressing yes to each escalation, to merely pressing yes once at the beginning of the suite of installs. This has been tested with Windows 7 and Windows 8.

Application Installer

Application Installer: checked boxes

The Application Installer itself is an AutoIt script that makes a graphical menu. This menu contains functions that, on submit, write the chosen program installation commands to the AppList file. This file is copied to the desktop and rewritten every time the Installer is run. AutoIt3.exe is copied locally to the user's temp folder. The application specific scripts are copied there. A batch file, 'menu_install.bat', is copied to the desktop for quick execution. One merely double-clicks the batch file to run the custom AppList on that computer. The Installer can write options after the installation to enable Microsoft Update (as opposed to the default Windows Updates) and to restart the machine. The restart is logged as a planned application maintenance. The Installer has installation types at the top to check pre-selected groups of applications that are installed often. Certain labs, configurations, or groups can remain consistent until policy for that group changes.

To simplify changes to the Application Installer, I also wrote a Builder, which reads two text files, Software_List.txt and Software_List_Checkboxes.txt. The first file, Software_List.txt, lists the programs to be shown in the Installer and their script name which will be used to install it. The second file, Software_List_Checkboxes.txt, lists which programs will be checked for each grouping. The Builder then rewrites the Application Installer accordingly. To remove programs that are obsolete one need only delete their one line from the software list file. To add new software, just add their display name and script name to the list. To change which programs are grouped in the categories, add or remove lines for that category. It saves a lot of time from coding the checkbox, function, and variables for each new item and updating the numbering of the old ones.

The Application Installer will also accept command line instructions. These instructions can be used to automatically run the Application Installer with a set category such as Standard Install. To do so, run the script and give it the argument "standard" after the script name. This would launch the Application Installer, check the Standard Install checkboxes, generate the batch file, and close the Installer. Current allowable arguments are "standard", "pal", "exp", "grad", and "125" corresponding to the install types. These can be changed in the Builder. The advantage of this is that the Application can be scheduled to run. Systems could update software automatically or system admins could at least have a manual process streamlined. This is used in our environment to make utilities which map the network share and call the Application Installer with the appropriate command line for the location, so that the batch file is generated automatically. Here is an example script of automatically mapping a network drive and running the Application Installer with the command line. AutoIt's "compile to .exe" feature can be used to make this an executable.

Scripting

In the process of both of these projects, I have written dozens of different scripts. I have been off and on in my AutoIt forum activity. I have faced a variety of challenges in installer behavior. This process has been updated over the course of three new operating systems.

Other professional uses for AutoIt scripts have been automating license key updates, mapping network drives, starting VPN connections, and logging computer maintenance routines. Due to the fact that scripts can be compiled into an executable that no longer requires the AutoIt program, they become highly portable. One such case is the need to put in a new license key for a particular program on every machine annually. Running the executable steps through the activation wizard again and types in the new key. This has saved tremendous amounts of clicking, typing, and remembering keys.

Preview Code

Menu_Install (txt)
Menu_Install_Builder (txt)

Here is a sample script for what the software installation scripts would look like. Each program or patch has its own script. Some are more complicated than others depending on the installer and how much must be done for licensing, configuration, or clean up when it is done.

Software_Installation_Generic (au3)

Download Code

Application Installer scripts require some of the AutoIt include files in a folder named "Include" in the same root as the scripts themselves (or the path in the scripts can be changed). There are two include files, VersionCompare.au3 and FileCopyProgress.au3, which are not standard to the AutoIt installation and will have to be copied if you have installed AutoIt already. These include files contain mouse, gui, and other pre-written functions for use with scripts. They are included with the zip file. You will have to change paths in scripts to the location of your installation files.

Application Installer files (1.9 MB zip)
- XP | Vista | Windows 7 | Windows 8 compatible
- Designed with Autoit 3.3.6.1
- Most scripts x32 and x64bit aware

Documentation

Adding Programs

To add a program to the list of the Application Installer:

  1. Add the program name and script name to the Software_List.txt file as follows:
    1. <Application Name>,<Application Script Name>
    2. Note that there is no space after the comma
    3. Note that the extension is not listed (assumed to be ".au3")
    4. List the applications in the order you desire them to be listed
  2. Run the Menu_Install_Builder.au3 using the AutoIt3.exe executable.
  3. Recompile the Application Installer with its executable and the new Menu_Install.au3 file using Aut2Exe

Removing Programs

To remove a program follow the same procedure as Adding Programs only delete the entries from Software_List.txt instead of adding them.

Adding Programs to Checkbox Lists

To add a program to one of the install type checkboxes:

  1. Add the checkbox name and script name to the Software_List_Checkboxes.txt file as follows:
    1. <Install Type>,<Application Script Name>
    2. Note that the install type is predetermined by Menu_Install_Builder, current options are {Standard, Current, Experimental, PAL, 125, Grad}
    3. Note that there is no space after the comma
    4. Note that the extension is not listed (assumed to be ".au3")
    5. The application order is not important.
    6. Note that if an application is not listed in Software_List.txt then it will not show up even if it is in Software_List_Checkboxes.txt
  2. Run the Menu_Install_Builder.au3 using the AutoIt3.exe executable.
  3. Recompile the Application Installer with its executable and the new Menu_Install.au3 file using Aut2Exe.

User Account Control (UAC)

The Application Installer displays whether UAC is on or not at runtime. Scripts with the "#requireadmin" line will function under UAC in Vista, Windows 7, and Windows 8. The user will be prompted for permissions to the network share and to run the executable. UAC changes batch file behavior when calling AutoIt. Instead of pausing until the installation script has completed (as is the case with UAC off), the batch file only pauses until the UAC prompt has been granted. Hence, to prevent all of the installations from running at once, one should only grant permission one at a time when the last install has finished. For this reason, and other security quirks, the Application Installer uses the AppList.au3 file and copies the AutoIt3.exe executable locally. (Note: Turning UAC off in the Control Panel in Windows 8 is merely equivalent to turning it to the lowest setting in Windows 7. This is not actually off as far as the AutoIt scripts are concerned.)

To overcome the UAC, the Application Installer aggregates the install scripts to be run into one script, the AppList. This results in only one UAC prompt at the beginning of the installs. AppList controls the install order and timing so that installations are done sequentially.

Installing from a non-administrative account

To install software from a non-administrative account, one will have to run the installer as an admin using the RunAs function. Note: this works best with UAC off as UAC adds additional restrictions on copying from network locations and running installers from certain locations. See an example of modifying the above scripts to install Firefox from a non-admin account: Firefox non-admin install (txt)

With UAC on, non-admin installation is tricky. Even using RunAs, the user will be prompted to allow (just the prompt to enter credentials is removed). I've gotten it to work running as both local and domain accounts but only if the installation files are locally present. (Note: execution from the TEMP or DESKTOP folder appears to be blocked, downloads to those locations work. Download to the PUBLIC DESKTOP seems to be blocked but execution works from there).

See an example RunAs using a local user with UAC on: (txt)
See an example RunAs using a domain user with UAC on: (txt)

Other uses for AutoIt

See other uses and applications of autoit (VPN connections, setting IP addresses, securely erasing free space).