NT required
Installing WinToNet is simple. The distribution consists of two executable programs: a server component and a Web component. You can install each separately or consolidate them on a single server. For our testing, we installed both modules on a single server, a Dell PowerEdge 2400 with 512MB of RAM running Windows NT 4.0 SP6. The installation process took five minutes from start to finish, including the obligatory reboot after installation. During installation, a WinToNet user account is automatically created; we had to perform one manual step to grant that account a Log On Locally right using User Manager.
WinToNet installs a sample site containing a few applications: Notepad, Minesweeper, and Calculator. Upon launching the first app, WinToNet downloads the Java client software to the local computer and prompts you for a Windows NT login. Users must log in to the Windows NT system using an NT-recognized username and password.
Serving Java
For our tests, we used the template provided during installation and modified it to add our own applications. On our NT server, we wanted to serve several Microsoft applications and network administrator utilities. With a few modifications to the template, we made the applications available via WinToNet in less than five minutes. WinToNet also includes a special Quick Launch window that appears automatically upon user login, so users can launch applications using that window rather than having to manually create a Web page to provide access them.
To add applications to the roster of available programs, WinToNet includes a series of installation utilities. Some applications, such as Microsoft Office, are not designed to function in a multiuser setting from a single server, so we had to take special care to make Office applications available. The utilities monitor the system to detect global changes (that is, Registry changes) and use this information when serving applications to individual users.
Nice features
One feature we particularly like is the concept of sessions. This feature allows a user to reconnect to the WinToNet server after a session has been interrupted by any type of disconnection. Upon reconnecting, all applications that had been running when the service was disrupted will be restored on the user's desktop. This excellent failsafe feature will help prevent data loss.
On the server, a special utility allows the administrator to monitor all WinToNet managed sessions and the applications currently running for remotely connected users. Similar to the Windows NT Task Manager, this monitoring utility lets the administrator terminate sessions and applications as necessary. It's also possible to service the Task Manager as a WinToNet hosted application to monitor the WinToNet environment remotely.
However, during testing, we found that some functions didn't work. For example, when editing a document in Microsoft Word, we were unable to access context, or right-click, menus. In fact, right-clicking didn't work in any of the applications we tested, although the vendor indicates in its release notes that it works inconsistently. Also, printing to a local printer didn't work without special setup, which consisted of making the local printer a network-shared printer and attaching it to the Windows NT server. We were able to get a local printer shared using SAMBA on our Red Hat system, mounted on the NT Server. Clearly, this workaround would not function over an Internet connection.
Sticker shock
There are two licensing programs for WinToNet: the single-user license costs $295 and a multiuser license is priced at $3,495 per CPU. There aren't any per-user licensing fees or additional per-platform charges, but the software can still be an expensive proposition considering how common dual-processor NT servers are today. An online demo is viewable at the company's Web site, but no downloadable demo version of the software is available at this time.
