Creating Users and Enabling Applications

Before your users can start working with desktops or published applications, some preparations are still needed. After all, the system does not know any users to whom you could assign permissions for all or specific applications. To change this, go to the Users section and define some users of your own, or press the Populate button to create a couple of default users automatically. Alternatively, you can import your users from your directory service. For the corresponding configuration, go to Configuration | Domain integration settings.

After the users have been created or imported, you still need a user group and an application group. These groups are needed to map users and shared applications. To change this, go to Users | User Groups | Create a new group and click the Static radio button to create a new user group. In my test, I created a user group named All Users; then, I needed to add the desired users to the group by pressing the Add to this group button to the right of the username.

The steps are similar for the application group under Applications | Application Groups | Create a new group; for example, you can describe a group as Some Linux applications and then add the desired applications. In the test scenario, I added Adobe Reader, Firefox, Thunderbird, and LibreOffice to the subsystem apps application group (Figure  4).

Figure 4: Applications are grouped into so-called application groups, to which specific users or user groups are later assigned.

Finally, to release the applications to the user, you need to map users to application groups. This is done in Applications | Publications. In the test scenario, I associated the Default Users group with the subsystem apps application group. On the Status | Summary page, the users are listed with their assigned applications and access permissions. In Configuration | Session Settings, you can then make some global settings. For example, you can define time restrictions for user logins or desktop types (Windows, Linux, or Any).

Local Peripherals Only with Native Client

Your users can now log in for the first time. In the Premium Edition, they can do so using one of the native clients for Windows, Linux, Mac OS, Android, or iOS that are available for download [9] or the App Store. The usability of an OVD session in desktop mode is also very good on iOS and Android – assuming the display is large enough (Figure  5). You will want at least a tablet-sized screen, because a session on a smartphone is just too fiddly.

Figure 5: Mixed operation: Users can use OVD Desktop to work simultaneously with Linux and Windows applications, and data can be exchanged via the clipboard. (Screenshot from the Ulteo website)

Alternatively, you can use the URL https://<server_IP_address_mac_address>/OVD to connect to the desktop via your web browser using Java or HTML5, depending on whether Java is installed or according to the preferred connection method you specified in Advanced settings on login. The performance in HTML5 mode is very good; so much so, in fact, that users sometimes forget they are working in a browser session. This makes it all the easier to ditch the now extremely insecure Java technology.

The main difference or advantage in the use of native OVD clients is that drives and printers shared on the local computer are also connected in the OVD session. In this way, you can save documents on the local disk without going through a file server. Even users with a smartphone or tablet can connect to the session manager with an HTML5-capable browser. In the test in our lab, it worked well with the latest versions of Firefox, Chrome, and Safari on Android or iOS.

Sessions can thus be migrated easily from one device to another. If a user has opened programs on the desktop (e.g., with the native client) and the session is then terminated, they can continue to work seamlessly in the open programs with the browser after setting up the connection. However, only one user can open one session at any given time.

Adding More Application Servers

One of the most interesting features of Ulteo OVD is the ability to provide mixed Windows and Linux applications to the user. As the basis for the respective platforms, you need Windows and Linux servers on which the corresponding Ulteo server roles are installed. To operate a Windows (2003, 2008 R2, 2012  R2) server as an application server for Ulteo OVD, it can be a domain member but not the domain controller. Additionally, Terminal Services or Remote Desktop Services must be installed and configured. You must make sure that authentication is disabled at the network level. In the settings for Remote Desktop, you thus need to enable Allow connections from computers running any version of Remote Desktop (less secure).

Ulteo hid the download link for the appropriate setup program for Windows application servers [10] in the depths of the documentation. The setup itself is pretty unspectacular and requires no further settings beyond stating the Session Manager's IP address. After a reboot, the Windows server then appears with its applications on the Session Manager host below Unregistered Servers. A click on the Register button enables the Windows server for OVD; at this point, the Windows applications also appear in Applications and can immediately be used by authorized users on the desktop or in the portal view.

Adding a Linux application server is also easily done: Just add the Ulteo repository in ulteo_ovd.list as described earlier to your system configuration and install the ulteo-ovd-slaveserver-role-aps (application server only) package, the ulteo-ovd-slaveserver-role-fs (file server) package, or both. Again, the installer only asks for the IP address of the Session Manager. Unlike the Windows application server, you can easily change the IP address for the Linux application server in the server's configuration file /etc/ulteo/ ovd/slaveserver.conf in the section:

[main] session_manager = <IP-address>

The new application server and file server also appear below Unregistered Servers in the admin console and are added to the server pool by pressing Register. For the Windows applications, you would again create a separate Application Group (e.g., Windows Applications) and add the desired Windows programs (Figure  6). Then, again associate the application group with the All Users group in Applications | Publications. This gives all your users access to the Linux and Windows applications.

Figure 6: Windows applications are also grouped in Application Groups and then assigned to User Groups.