Added Value

When a version 4.0.1 appears after a 4.0 major release, you wouldn't expect anything special. But, this is not true of Opsi, an open source Windows client manager from uib GmbH in Mainz, Germany [1]. The improvements in Opsi 4.0 addressed environments with a large number of clients; the changes in version 4.0.1 relate to distributed environments.

Slow Line

The most important change is certainly the utility to integrate clients on slow lines. A typical Opsi client on the LAN contacts its Opsi server after booting to see if it has to install anything and, if so, it mounts a share with which it installs the software. The attempt to install something as banal as the Adobe Reader from an SMB share at the wrong end of a DSL line or, even worse, a UMTS connection, would lead to extremely long installation times and errors if the connection were interrupted. Apart from this, a traveling worker's laptop would be unable to reach its Opsi server for lack of a network connection. In other words, a totally different solution was needed.

Opsi uses local caching or installation files and configuration data. If an Opsi client on a WAN installs software, it first uses CIFS/HTTPS to load the required files and data onto its local disk. To avoid interrupting the user during work, this happens in the background with dynamic use of the available bandwidth. This means that the Opsi client will reduce its download speed if someone else is actively using the network interface.

If the connection is interrupted, the download continues at the next opportunity. This process continues until all the required files are available locally, then the user is informed of any imminent installation and prompted to reboot. The installation takes place in typical Opsi fashion before the log in; in this case, no network connection is required because all data is available locally. The installation results are cached locally and transferred to the server at the next opportunity (i.e., the next time a network connection is available).

Software is started at boot time (this can be disabled) as well as a number of other events that attempt to open a connection – for example, when a network interface is activated.

Safe in the Cloud?

The approach I cover here lets administrators not only cater to the laptops of an external sales force but also to integrate home offices or branches with just a few PCs at the other end of a WAN with centralized Opsi management. This means that you can now manage and maintain locations that could pose a security problem for lack of centralized updates.

Considering these new options, it only seems logical to use the Opsi server to manage larger numbers on distributed PCs, and the server could be located in the cloud for this purpose. The technology supports this approach, and Opsi has also put some work into improving security. The recently introduced authentication of servers and clients has definitely improved security for cases in which an attacker attempts to spoof an Opsi server and compromise the Opsi clients. Despite this, the vendor still advises administrators to deploy additional measures, such as VPNs, and to use consultancy services in the case of cloud applications. After all, if an attacker compromises the Opsi server, they can access all the clients connected to it.

Here and There

Free support for multiple sites is a frequently used feature in Opsi. External locations and a large number of clients tend to use their own decentralized software repositories. The clients of these locations can be assigned to a specific repository in a management interface. After doing this, the client then retrieves software in the future from a software repository rather than using the wide area network. But what if the client is a laptop that belongs to a road warrior? Again, the laptop will pick up its software from the assigned repository – even if it happens to be geographically close to another repository.

This is where the next new feature enters the scene: dynamic repository assignments. Although the client remains assigned to its home repository, you can also give it a list of repositories that contain the required software. By referring to an algorithm passed to it, the client can now decide which repository in the list is best. Because the algorithm is freely definable, you can base the choice on, for example, the network address or latency figures.

As You Like It

Deciding which software to deploy on enterprise clients is often a dilemma for the administrator: You will probably want to install as little unnecessary software as possible on machines belonging to your staff. But because you don't want your users to have administrative privileges, they have to call for IT support no matter how trivial the tool might be that they are missing. Software-on-demand is a useful answer to this. Administrators can assign a selection of products into the software-on-demand product group from which the users can request tools for installation on their PCs. The software is installed with administrative privileges by the Opsi client agent as defined by the administrator in the package.

Details

The new features I have looked at so far are fee-based co-financing projects, which means they will not become free and open source until the developers have recovered their development costs. Besides these commercial extensions, many smaller improvements have been added directly to the open source Opsi core. For reasons of space, I will only look at the most important of these improvements here.

I'll start with the more noticeable improvements to the management interface. You can now store the selection of data columns to be displayed for clients or products, rather than having to configure this each time you restart. The tool can also identify and display the clients that are online at the press of a button. Search forms help you find clients more easily and failed installations are displayed in a separate client group. A separate search form also helps you find clients that need an update of a specific product. See also the "Show Your Work" box.

Some improvements to detail have also been made server side: If you want to use Opsi Wake-on-LAN in a distributed environment, you will appreciate support for directed broadcasts. The configuration options for name resolution have been improved to keep clients reachable despite different DHCP and DNS configurations. You can also assign freely definable passwords for the boot image, which was not possible before, thus improving security.

Finally, the work the developers put into the wide area network extension for the Opsi client agent now allows for a more granular configuration of user interaction, even if you don't invest in the commercial extension.

All told, Opsi clearly has been improved as a professional client management tool, both with respect to details and application scope. It makes you wonder what the developers have in store for the next release – maybe even support for Linux clients?