Installations First let's make one thing clear. If you are the least bit ambitious, you cannot just install an application on a user's pc and hope that they like the vanilla installation; you often also need to apply some default user settings. The location where the application default saves, default behavior, template office files in the user's documents dir and so on are per user and there is not a 1:1 relationship between computers and users. FastTrack has build-in mechanisms to handle this very easily; we will demonstrate how this works later in the article. As a supplement to this article, please refer to this case study, which is a simple example of distributing Microsoft Office 2007 through a logon script to all computers in a domain.

Simple install script

Just to focus on the basic mechanisms first, let's go through the following simple 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 looks like this:

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

RegisterInstallation and UnregisterInstallations are key elements, as they store the information that the application is installed or uninstalled for later query in scripts.

It is up to you in general 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, which is done above. 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.

Now let's deploy the application. 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

The example uses binaries located at a share called \\acmeserver\installers$ and uses an administrative account named AcmeInstall in the AcmeDom domain. The "EncryptedPassword" is to be replaced with a string of encrypted data, which can be generated in the editor.

Let's say our Windows Phonebook application lets the user add comments to people in the phonebook and we want to store these on the user's personal share. 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

So every time we change the script build, the settings are applied once for every user that logs on to the network. Over time you will find that half of your scripts require some form of manipulation of the user's registry or files.

If you have legacy scripts that are not FastTrack scripts, you can use the UserSettingsProgramOnce for a program that is listet 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. If you later upgrade, the Once mechanism will run again for every user 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. Almost all installers today can actually run quietly or silently. Most installers today use MSI (Microsoft Installer), which allows you to run the installation itself quietly, which we will use in this case.

If you run into an installer that cannot be run without user intervention, you should search for it on the internet. In most cases there is in fact a hidden switch that someone has found. But if you run into a dead end, you need to repackage the installation into for instance an MSI package that can be run quietly. There are hundreds of these products on the internet for this, but Microsoft's "SMS Installer" is free and it is based on the "Wise Installer" engine. But! This has to be the last resort, 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. The same goes for system components. Fortunately today you might never run into this problem, because unattended installation is build into all common installers.

Now let's create an install script for Acrobat Reader 9.0. The reason we choose Acrobat Reader 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, which is also true in this case. 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 again. 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 no different than all other MSI packages like Microsoft Office. We assume your clients already have Microsoft Installer installed (if they don't, script it and install it on all machines), so we call the MSIEXEC directly. Simply run MSIEXEC with /? from your system directory to see all command-line switches.

Now that we have the actual installer files, let's wrap them in a script. We assume 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 Then UnregisterInstallation Acrobat Reader   If [LastExitCode]=3010 Then UnregisterInstallation Acrobat Reader Else   Run MSIExec.exe,/I Bin\AcroRead.MSI /QN /NoRestart   If [LastExitCode]=0 Then RegisterInstallation Acrobat Reader,9.0,1   If [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 without a management system

Common applications can be installed with just one line in your logon script like shown in the first example. For applications that are to be installed on specific computers we recommend you use an XML file in the same folder as your logon script to control the actual installations, 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:

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 in administrative context:


Now it would be the extremely easy to also handle uninstallations when computers are removed from the file, but be really really careful, if you malform the file, you will effectively uninstall everything on all computers! Also you could easily build in versioning, so you automatically upgrade when you create a new version or build of the install script.

Once you have established this way to distribute the 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!

Installations with a management system

If you have a management system, you simply package the installation as shown above, into a distribution package and deploy it with your management system instead of using the logon script. If you install some applications with your management system and some though the logon script, you need to report to your management system, that you have installed something. If there is a 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 also use it for anything you want to happen when an application gets installed or uninstalled. Inside the script you write whatever is needed to inform the management system, usually it is creating an XML file in a specific format on a specific location. The name of the application and the version can be extracted with the functions CurrentInstallName and CurrentInstallVersion.

But as you have seen above, it might be simpler to simply factor out your management system of installations depending on the size of your network. Management systems are really expensive and doesn't offer much functionality if you think about it. If you are a medium size company, you should consider if you actually need it if FastTrack handles all installations for you. You could write a few script lines in your logon script to collect basic inventory data in a common XML file and Windows has build in remote desktop, so all your left with is more or less some fancy reporting. Your inventory XML file can be imported into Excel for reporting, so if you rule out all of the above things, what do you actually get for your money from your expensive management system if you are not a really large company?