Unattended installations Throughout this article we will go through how to install software unattendedly. We will present solutions on how to: Install any type of software unattendedly without a management system. Repackaging non-MSI (Windows Installer) based setup programs into MSI packages for distribution with a management system or through group policies. Set per-user settings based on installed software. Create your own unattended custom exe-based installation packages for offline computers that include secure installation credentials. As a supplement to this article, please refer to this case study, which is distributing Microsoft Office 2007 through a logon script to all computers in a domain. Related pages Documentation overview Browse online documentation. Creating exe projects Learn how to convert your script and installation files into a single exe file. Creating msi projects Learn how to compile your script and setup files into an msi file.

Simple install script

Before we continue going into how to installed software unattendedly, there is one thing that we need to think about before constructing scripts to do so: Installing a piece of software is only half way there. In many cases, we cannot just install an application on a user's pc and hope that they like the vanilla installation. If we want to truly service our users, we would often need to apply some default user settings, which are per-user, which again means setting registry keys in each user's registry hive (HKEY_CURRENT_USER) and do other things that are related to each user's profile. This could be for example where the application saves by default (local drive versus network drive), default behavior or copying files into the profile; for example template office files into the user's documents dir. The problem with that is that there is not a 1:1 relationship between computers and users and we therefore need to be able to know at logon time, what is installed and what is not and whether or not user settings have already been applied for the current user.

FastTrack Scripting Host has built-in mechanisms to handle this problem. Let's go back to creating an installation script. Typically these are Windows Installer (MSI) packages, but we will start with a simple example to understand the basic mechanisms. We will go through a case where we:

• Create an installation script for a simple internal Windows based phonebook.
• Deploy it from the logon script to everyone.
• Apply default user settings.

The application itself is just a portion of files, so the script simply looks like this:

SyncDir Bin,[ProgramFilesDir]\Acme\Phonebook CreateShortcut [ProgramsDir],Acme Phonebook,[ProgramFilesDir]\Acme\Phonebook\Phonebook.exe RegisterInstallation Acme Phonebook,1,1

RegisterInstallation and UnregisterInstallations are the key elements to understand. They store or remove the information that tells whether the application is installed or not for querying in scripts.

For all other installations there is similar functionality under "Installations - Windows" in the script editor's "Engine Browser" tree that can be used the same way, but based on the Windows installation list instead. This works the same way and it might seem like a good idea to use these instead. You can choose to do this, but then you have to understand the pros and cons. The main reason why FastTrack Scripting Host keeps its own list of installed software based on the RegisterInstallation and UnregisterInstallation commands is simply that the Windows installation list is unreliable, because software vendors tend to change the listed names from version to version. On the other hand, if you need to set user settings for installations that are not scripted with FastTrack Scripting Host, this is the best alternative. For an example of installing applications based on the Windows installation list, please refer to this case study.

If you want an uninstall script also, it is up to you, if you want to use the same script for installation and uninstallation or you want to use two separate scripts. If you use one script, you can use a command-line parameter to control which one is actually executed, as shown below. You can use the /p switch to pass a command-line parameter to the script, which is extracted with the CmdParam function. So in this case, specifying "/p action=uninstall" will run an uninstallation and anything else will run the installer.

If [CmdParam Action]=Uninstall Then   DeleteDir [ProgramFilesDir]\Acme\Phonebook   DeleteFile [ProgramsDir]\Acme Phonebook.lnk   UnregisterInstallation Acme Phonebook Else   SyncDir Bin,[ProgramFilesDir]\Acme\Phonebook   CreateShortcut [ProgramsDir],Acme Phonebook,[ProgramFilesDir]\Acme\Phonebook\Phonebook.exe   RegisterInstallation Acme Phonebook,1,1 End If

Using the logon script

Now let's deploy the application through the logon script. Since everyone needs this application, we can simply put a few lines into the logon script:

If Not InstalledBuild Acme Phonebook,1 Then   RunScript \\AcmeServer\Installers$\Phonebook\Install.fsh, AcmeDom\AcmeInstall,"<encryptedpassword>" End If

As we know that the script will issue a RegisterInstallation command on success, we can simple ask at logon time, if the computer has the installation or not. We could also add more logic to the condition like for example checking, if the computer is in a specific Active Directory group. We use the "InstalledBuild" instead of the simpler "Installed" condition in the example above. This is because in case there is a later correction or expansion to the script, the build can just be changed and this would trig a re-install on all computers, because the build number installed is different than the build number in the condition and the script.

The example uses binaries located at a share called \\acmeserver\installers$ and uses an administrative account named AcmeInstall in the AcmeDom domain. "EncryptedPassword" must be generated in the editor by pressing F8.

Let's also apply some user settings for the phonebook. Let's say that our Windows Phonebook application lets the user add comments and pictures to people in the phonebook and we want to store these on the user's personal share. Our application will read this location off the registry in the HKEY_CURRENT_USER\Software\Acme\Phonebook\FilePath key and default to the documents folder, in case the registry key does not exist. If we assume the logon script maps O: as the personal share, we can run this snippet as part of our logon script:

If UserSettingsOnceABuild Acme Phonebook Then   MakeDir O:\PhonebookData   WriteRegistry HKCU\Software\Acme\Phonebook\FilePath,O:\PhonebookData End If

If 10 users over time log on to a specific computer that has the phonebook, then this condition will run 10 times through the logon script on this computer. And every time we change the script build, the settings are applied again once per user.

If you have legacy scripts that are not FastTrack scripts, you can use the UserSettingsProgramOnce for a program that is listed in the programs list in the control panel to get the same "Run Once Per User" functionality like this:

If UserSettingsProgramOnce Adobe Reader Then Include Settings\ReaderSettings.fsh

This would find "Acrobat Reader 9" in case of Acrobat Reader 9 and include a file called ReaderSettings.fsh once per user per computer. If you later upgrade Acrobat Reader, the Once mechanism will run again when the text changes in the programs list.

Common install scripts

In the above example we just needed to deploy some flat files, but we are rarely that lucky. In almost any case, you get an installation package and this package we need to wrap in a script. The only criteria we have for the installer is that it can run without user intervention and preferably also without any GUI. And if you look hard enough, you will learn that any installer can actually run quietly or silently with the right switches. Most installers use MSI (Windows Installer), which allows you to run the installation itself quietly and we will use that in this case.

If you run into an installer that you think that you cannot run without user intervention, you should search the internet. There is always a hidden switch. You must find this instead of being tempted to use one of the snapshot-based re-packagers that are available. Repackaging is a dirty way of solving the problem, because it requires a common starting point. Let's say an application installer sets 100 registry keys and on the snapshot machine, it captures 98, meaning two are not in the new package. This is probably because those two are almost always set, but if they are missing on a few of the machines you deploy the package to, the installation is not complete. And a new version of Windows might break your scripts this way, because maybe these two keys are no longer set by default.

Let's create an install script for Acrobat Reader 9.0. The reason we choose an older Acrobat Reader version is to make a point. It is very common that you download just one exe file which is just a wrapper for the real installation files - as is also the case here. Run the exe file and observe that it starts by unpacking the actual installation files. When the installation prompts for start, you need to locate the real installation files. In this case they will be located under "Local Settings\Application Data\Adobe\Reader 9.0\Setup Files" in your profile. Copy these files and close the installer again, which removes the original files. In your copy of the files, you can see, that the "Reader9" directory is the actual installer and that it is in fact MSI. So scripting Acrobat Reader is now no different than all other MSI packages like Microsoft Office. To see the command-line switches for Windows Installer, simply run "MSIExec /?".

Now that we have the actual installer files, let's wrap them in a script that can install and uninstall. We will assume that you copied the "Reader9" files to a subdirectory called "Bin":

If [CmdParam Action]=Uninstall Then   Run MSIExec.exe,/X Bin\AcroRead.MSI /QN /NoRestart   If [LastExitCode]=0 Or [LastExitCode]=3010 Then UnregisterInstallation Acrobat Reader Else   Run MSIExec.exe,/I Bin\AcroRead.MSI /QN /NoRestart   If [LastExitCode]=0 Or [LastExitCode]=3010 Then RegisterInstallation Acrobat Reader,9.0,1 End If

MSIEXEC returns 0 for success and 3010 for success, but reboot required, so we use this to determine success. Just like the first example, you might deploy it to everyone from your logon script and apply some default settings. In the case of Acrobat Reader, the language of the GUI is a per-user registry key, which you could set from your logon script too. You might do some more work with it like deleting the desktop shortcuts and such, but this can be used as a generic template for MSI packages, like Microsoft Office and all other Microsoft products.

Installations summary

If you are uncertain about the mechanisms above, consider watching the video below before reading on. Senior Technical Writer Steve Dodson from Binary Research International walks you through installing a Windows Installer (MSI) package through the logon script.

Installations without a management system

Common applications can be installed with just one line in your logon script as shown in the previous examples. For applications that are to be installed on specific computers, it is recommended that you use an XML file in the same folder as your logon script to control the actual installations. This will allow you to install software on additional computers without touching any scripts and will give you a management like overview of what is installed on which computers. The XML file could look like this:

<?xml version="1.0"?> <Acme>   <Applications>     <AcrobatReader Name="Acrobat Reader" InstallPath="\\AcmeServer\Install$\AcrobatReader\Install.fsh">       <ACMEPC0054 Install="Yes"/>       <ACMEPC0134 Install="Yes"/>       <ACMEPC0334 Install="Yes"/>     </AcrobatReader>     <Office Name="Microsoft Office" InstallPath="\\AcmeServer\Install$\Office\Install.fsh">       <ACMEPC0111 Install="Yes"/>       <ACMEPC0855 Install="Yes"/>     </Office>   </Applications> </Acme>

Then in the logon script, we can write just a few lines to handle it, to avoid having to do manual steps on each client:

Loop Application,[XMLSubNodes Applications.xml,Acme/Applications]   If [XMLAttribute Applications.xml,Acme/Applications/[var Application]/[ComputerName],Install]=Yes Then     SetVar Name,[XMLAttribute Applications.xml,Acme/Applications/[var Application],Name]     If Not Installed [Var Name] Then       SetVar Path,[XMLAttribute Applications.xml,Acme/Applications/[var Application],InstallPath]       SmallSplash "Installing [Var Name] ... please wait!"       RunScript [Var Path], AcmeDom\AcmeInstall,"<encryptedpassword>"     End If   End If End Loop

We look through the XML file for nodes under the "Application" node and then look if the current computer needs the application and has it installed. In this case, if ACMEPC0111 does not have Microsoft Office installed when someone logs in, they will see this splash screen while the installation runs unattended in the background:


It would be easy to also handle uninstallations when computers are removed from the XML file, but be very careful. If you malform the file, you will effectively uninstall everything on all computers! Versioning could also be added to automatically upgrade when a new version or build is available.

Once you have established this mechanism to distribute software, imagine how easy it would be to create an intranet application where people can request certain software. All the intranet application needs to do is to insert one line into the xml file!

User Account Control (UAC) You should always set your user settings through your logon script, but if you have User Account Control (UAC) for administrators, you will have to deploy the software differently. UAC is set per-machine and can only be distinguished between administrators and non-administrators. If UAC is not enabled for administrators in your company, you can skip this section. If you do have UAC enabled for administrators through your group policies, you cannot decide that a dedicated domain install user is not under UAC and thus you cannot deploy through your logon script, because the target administrative user has no session to ask for permission to elevate. If it is your company policy to have UAC enabled for administrators, you can install the software by using a startup script instead, as these are not under UAC control. Please refer to this page for more information on UAC and startup scripts.

Inventory If you don't have a management system, you don't know what is installed on what computers. You can read in the XML file, which computers have the programs installed that you control. You cannot see who has what other software. FastTrack Scripting Host 7.1 comes with a cloud-based inventory system that has no setup steps. Simply issue one command in your logon script, and you have full hardware and software inventory of your computers. FastTrack Inventory has no additional cost; it just requires your clients to be licensed and within maintenance period. Please refer to this page for more information on FastTrack Inventory.

Installations with a management system - generating MSI files

If you do have a management system or you prefer to use group policies to distribute common software, you will most likely have run into the problem that you can only distribute Windows Installer (MSI) files. If for example the software your company has selected as their VPN software is not Windows Installer based, you cannot distribute it through your management system or group policies. But as described in the previous sections, we can script any installation with FastTrack Scripting Host, as long as we know the command-line switches to do so. And from version 7.1, FastTrack Scripting Host can build a single self-contained MSI package based on any script and installation files, so you can simply script your VPN software installation and let FastTrack Scripting Host build an MSI files around it all to make it distributable. Please refer to this page for more information on building MSI files.

Post-installation notifications

If you install some applications with your management system and some through the logon script, you might need to report to your management system that you have installed an application. For this, you can use the FastTrack install handlers: If there is a script file named "PostInstall.fsh" or "PostUninstall.fsh" in the FastTrack directory, they are executed any time the script runs into RegisterInstallation or RegisterUninstallation. This is to enable you to inform your management system about installations, but you can of course also use these for anything you want to happen when an application gets installed or uninstalled. Inside the script, you can write whatever is needed to inform the management system, which is often creating an XML file in a specific format on a specific network location. The name of the application and the version can be extracted with the functions CurrentInstallName and CurrentInstallVersion.

Creating off-line installers - repackaging into a single exe file

For offline computers, it is possible to package your script and installation files into one single exe file that can be placed in a public location. There are a number of advantages to this over all other alternatives: First of all, the users cannot get a copy of the actual installation files and also the credentials to actually install the software can be safely included in the script, which the user can never see. If you are not familiar with creating exe file with FastTrack Scripting Host, please refer to this page for more information on how to compile your script and installation files into one single exe file.

If this exe file is put on a public location, we need to protect it from abuse. We could get by this by simply asking for a password that only internal users know. If we inserted this at the top of the script before getting to the script lines that actually perform the installation:

If Not [InputPassword Enter installation password]=Sesame Then   ShowErrorMessage The password is incorrect.   Exit End If

Then the user will see this, when running the exe file:


If the user did not enter "Sesame" in this case, then the user gets an error and the exe file exits.


If the offline users are local administrators, we can continue to the actual installation script lines that execute the installation. If the local user may be under User Account Control, we might need to elevate the user to be able to actually execute the installation. To handle this, we simply need to insert one script line before we start the installation:

ElevateUser

Please refer to the User Account Control page for more information on the ElevateUser command.

If the user is not local administrator, but we know the name and password of a local administrator account that is not under User Account Control, we can simply change the executing user before doing anything that requires administrative privileges:

ChangeUser LocalInstallUser,6orateocIkCmGChbGYLg0w==

What is important to understand is that all this will be compiled into a single executable file and the executing user will have no chance of getting any information from inside the script. Using the above "start password" example, the user does not know any account passwords. The output exe file can be put in a public location and the url and start password can be handed out. If you want to sign your output exe file in such a scenario, please refer to this page for more information on creating exe files and signing exe files.

Exe compilation example

This example is an extract from the Compiling your script into an exe file page, where a complete installation script and the installation files are compiled into one single custom exe file.

The movie below shows an example of converting the above Acrobat Reader example into one single exe file with a few mouse-clicks. The scenario is this:

• The network administrator wants to create a pool of common applications that users can self-service themselves to get installed, without consulting the IT department.
• Any one installation must be one executable file to avoid users copying the installation files.
• Executing users are not administrators.
• The process must be completely automatic without requiring user interaction, except asking to install or not.
• There is a local administrator account on all computers that have the same password known only to the network administrator.
• Executing users must not be able to get credentials of the local administrator account executing the installation.

In the example below, a single 90mb exe file is produced that will install Adobe Reader using a custom administrator account.

Advanced compilation example - MalwareBytes

The videos below are for automating the installation of MalwareBytes on clients, by re-packaging the installation files for true unattended deployment without leaving any footprinting from the re-packaging. Press play on the left video to see how this can be done.

Deploying MalwareBytes unattendedly with FSH	Creating the MalwareBytes deployment package