Logging

If an installation fails, Opsi alerts the administrator via the web interface for the package. Additionally, each client generates a detailed log that Opsi stores both centrally on the server and also locally on the client for diagnostics in the case of connection issues.

Optionally, Opsi can pass messages to a Syslog server. When you create a software package, you can also add a custom logfile. In the course of Opsi-controlled Windows installation over the network, logfiles are created on both the server and the client.

In enterprise environments, Opsi supports the use and central configuration of multiplex depot servers for software installation in distributed scenarios. Implementations of this kind seem to be fairly complex, and the manufacturer recommends signing a support agreement before setting up a multiplex depot server.

Scripting Language

When Windows boots, the Opsi service calls Winst.exe, which in turn installs the individual packages (Figure 5). An installation-ready Opsi package comprises the executable binaries, some metadata, and an installation script for updating and uninstalling.

Figure 5: A status display accompanies the installation of individual programs – in this case, Firefox.

Installation control relies on a special, semantically rich scripting language that is documented in a separate installation manual and reference card, along with details of the various installation programs, on the Opsi website [15]. A template supplied with the Opsi distribution is useful for help in getting started, and the wiki [14], with its collection of sample scripts, helps to explain the concept further.

The scripting language supports all known installation variants (i.e., snapshot, silent, script-based, and simulated keyboard input), which means that the underlying language does not change from program to program. The files have a similar structure to INI files; that is, they are divided into sections.

Opsi distinguishes between a primary section, which controls the basic flow of the script and the run-time behavior of Winst, and multiple secondary sections, which are called by the primary section (for an example, see Listing 1). A secondary section contains instructions, which in turn can reside in external functions or are drawn from external sources, such as programs or included scripts.

Opsi's scripting language includes conditions (if and else), for loops, and string lists to guide the installation, depending on the existence of certain properties. Also, it offers assignable variables, pre-defined functions, and global constants. The constants let you reference system paths, drive letters, operating system versions, environmental variables, and network settings in the script. Opsi automatically discovers the value of global variables at run time.

The code in the secondary section can make various changes to the system, such as copying and deleting files and directories, editing Registry entries, and creating or removing links in the start menu and on the desktop. Also, it is possible to launch external programs via the Windows API, or cmd.exe, and to reboot the target system depending on the file version, operating system, language, free disk space, and other factors.

Administrators can use configurable installation messages and graphics to modify the look of the Opsi service and even modify a system's restart behavior in a script. The Opsi scripting language provides file-patching functions for software configuration and supports INI, hosts, XML, BDE, and Mozilla configuration files, as well as text files.

Conclusions

Custom solutions make sense in some environments; however, you should not underestimate the initial setup effort or the maintenance overhead. Opsi gives you the freedom to decide how much to do yourself and what level of vendor support to rely on. The Opsi alternative also saves you the cost of a Windows server, and you can manage the software on your Windows clients from the stability and security of Linux.