Desktop Technology Today

The Lab investigates the evolving desktop environment, starting with a look at Compaq Deskpro 4000N and Citrix WinFrame 1.7

Shopping for a Windows-oriented desktop system for a corporate environment is like going out to dinner. First, you have to decide on your main entree: Do you want a thin client, a lean client, or a fat client? Then you have to decide on the side dishes: Would you like a CD-ROM drive with your client? How about a floppy? Would you care for a local or remote boot? Keyboard or stylus input? Sound or no sound? You have a smorgasbord of options.

What's generating this desktop diversity? Right now, total cost of ownership (TCO) is the most visible driving force. But once you get past the dollars, you see three types of technology vying for acceptance:

As if having three competing technologies isn't confusing enough, you can mix and match aspects of each. For example, you might run a thin client program on a lean client system to access applications running on a multiuser server. Or you might use lean-client server-based management functions to manage fat clients.

In an effort to better understand the pros and cons of these corporate desktop strategies, Windows NT Magazine brought a representative sample of these technologies into the NT Lab for further inspection. The magazine will report the findings, starting with this month's look at Compaq's Network PC offering, the Deskpro 4000N, and the latest version of the Citrix multiuser Windows NT Server software, WinFrame 1.7.

Compaq Deskpro 4000N Network PC
The Deskpro 4000N is Compaq's entry into the NetPC market. Microsoft, Intel, Compaq, Dell, and HP developed the NetPC specifications to create a similarly priced alternative to network computers. (Note that shortly after this group finalized the NetPC specifications, Microsoft went on to endorse a thin client strategy through its Windows-based Terminal Server—formerly code-named Hydra—multiuser Windows project. But that's a story for another month.)

I reviewed the NetPC specifications so I could better understand what the Deskpro 4000N has to offer. (To review the specifications, take a look at the sidebar "The Network PC Requirements," on page 88.) The NetPC specifications define a desktop client as one that:

First Impressions
My initial impression of the Deskpro 4000N was mixed—I felt like I was setting up an ordinary PC desktop unit. First I unpacked the monitor, a Compaq P50 color model. Then I opened the system box and immediately encountered a standard-issue Compaq keyboard and mouse. It wasn't until I reached the system unit that I realized I was indeed dealing with something different.

The system unit has a much smaller footprint than a traditional desktop workstation (the monitor base nearly covers the unit). The system unit I received for evaluation has a 200MHz Pentium processor (with MMX, of course), 32MB of physical memory, and a 1.2GB hard disk. The unit also features one parallel port, two serial ports, two Universal Serial Bus (USB) ports, one keyboard port, and one mouse port. Either an Attachment Unit Interface (AUI) port (10 Mbps) or unshielded twisted pair (UTP) port (10/100 Mbps) handles Ethernet network connectivity.

The evaluation system unit has no visible floppy or CD-ROM drives, which is an obvious sign that you're dealing with a NetPC. This lack of floppy and CD-ROM input devices keeps the desktop user from inserting unwanted software or data into the unit. (Control freaks are going to love this feature.) Also notably absent are any speakers or audio input/output connections, so the Deskpro 4000N is quiet in more ways than one.

Because very little is on the outside of the unit, I popped open the case and looked inside. Armed with no information about the enclosure, I found two push buttons on the side of the cabinet that let me slide it open quite easily. At first that easy access bothered me­who wants users to get inside their systems so easily? Then I noticed that the Deskpro 4000N includes a locking mechanism you can install to prevent unwanted tampering. Inside the unit I found a clean-looking (but oddly shaped) motherboard, the IDE disk, and a single PCI expansion slot. The layout of these components was well organized despite the space limitations the cabinet imposed.

Pushing Buttons
When I turned on the Deskpro 4000N, it automatically started installing Windows NT 4.0 Workstation from its internal hard disk. (You can order the unit with Windows 95, which the system will also install automatically.) With the automated installation process, all I had to do was enter my name and company name. The installation process took care of the rest, including rebooting when necessary (and the installation process requires several reboots).

On one hand, the automated installation is pretty impressive. You can start the installation process, enter the basic name and company information, and then move on to the next system (or go have some coffee, for that matter). On the other hand, some of the choices Compaq configures don't impress me. For example, the computer name ends up as a bizarre-looking string of letters and numbers that correspond to the unit's serial number. And the automated installation process assigns the unit as part of a workgroup named Workgroup.

These quibbles are relatively minor, but I really take exception to the choice of networking services. The automated installation process sets up the Deskpro 4000N for NetBEUI-only networks. Someone needs to tell Compaq that NetBEUI is past its prime and that TCP/IP is now the network protocol of choice. My advice to Compaq is simple: Have the automated installation process configure TCP/IP with Dynamic Host Configuration Protocol (DHCP)-assigned addresses. Trust me, that configuration will work in many more environments than a NetBEUI-only configuration.

I was able to add support for TCP/IP and have the unit join a real domain in a few minutes. The Deskpro 4000N stores the entire i386 directory and related Service Pack (SP) 3 files for NT 4.0 on the hard disk, so making system configuration changes poses no difficulty. What strikes me as odd is that Compaq automates so much of the installation process and then forces the administrator to configure some pretty obvious information.

Soft on Software
I have a mixed reaction to the management software that comes with the Deskpro 4000N. It breaks down into three layers: a Desktop Management Interface (DMI) layer, an alerting layer, and a user-interface layer. I have no complaints about the DMI support­the Deskpro 4000N DMI layer is DMI version 1.1 compliant. The alerting layer (called Intelligent Manageability) runs as a service and can generate local or network Simple Network Management Protocol (SNMP) alerts for a wide variety of internal problems (e.g., hard disk failure, temperature fault, and memory configuration change). Both the DMI and alerting layers are very important in deploying an easy-to-manage desktop environment.

What I don't particularly care for is Compaq's DMI browser, which serves as the user interface to the DMI layer (see Screen 1 for a view of the DMI browser in action). Maybe I'm spoiled after seeing DMI browsers for high-end workstations, but I find the Compaq browser to be downright boring—no moving fans, heat gauges, or other visual clues for interpreting information. The browser's functional enough, it just isn't particularly compelling. The good news is that if you don't like this browser, you can use a third-party product.

The final management-oriented software component on the Deskpro 4000N is Compaq's Diagnostics program. You can access the program from the Start menu. In the Control Panel, you'll find it under the name Compaq Insight Personal Edition. (I'm not sure why Compaq uses two different names and provides two different entry points to this program.) If you've used Compaq workstations in the past, you are already familiar with this program­it's a variation of the Compaq Diagnostics program, which ships with every Compaq system (see Screen 2 to view the opening menu for this program in the Control Panel).

That Vision Thing Again
To understand the Deskpro 4000N, keep reminding yourself of the ideal desktop environment. In this environment, you don't have to leave your chair to diagnose problems with desktop systems. Unfortunately, some administrative features of the Deskpro 4000N are in limbo, waiting for Microsoft to complete its Zero Administration for Windows (ZAW) initiative. (For more information, see Mark Minasi, "Zero Administration for Windows," December 1997.) For example, features such as remote boot and Wakeup on LAN are clearly beneficial to administrators, but the absence of native support for these features in NT Server makes capitalizing on them hard.

Two administrative features of the Deskpro 4000N that you don't have to wait to enjoy are OnNow and remote floppy boot. The OnNow feature lets the Deskpro 4000N enter a low-power-consumption state and spring back to life (in about three seconds by my testing) when you move the mouse. With this feature, you can leave your desktop system on all the time without worrying about the power bill.

The Right Choices
Although I clearly don't care for some aspects of the Deskpro 4000N, my dislikes fall in the areas of configuration and software and thus are easy to address. On the whole, I found the hardware to be as robust and powerful as any modern workstation, and I would gladly place a Deskpro 4000N on my desktop. I would miss having integrated sound and an integrated CD-ROM drive (though my nearest coworkers probably would be thankful). Trying to create a minimal but functional desktop workstation is tricky no matter how you look at it. From my perspective, Compaq has made the right choices with respect to the hardware content of the Deskpro 4000N.

Citrix WinFrame 1.7
WinFrame 1.7 is the latest release of the Citrix multiuser NT Server product. (See the sidebar, "Many Users, Many Products," on page 90, for a brief history of WinFrame and an overview of the multiuser NT market.) WinFrame lets you leverage the resources of a beefy application server across a wide range of client systems. WinFrame currently supports a variety of network computers and Windows terminals and connections from DOS, Windows, Windows 95, and Windows NT systems. Third-party products accommodate connectivity to Macintosh and UNIX systems.

Based on NT Server 3.51, WinFrame 1.7 introduces several features that improve WinFrame's ease of deployment and management and several price options. These new features let WinFrame function better in enterprise environments. The specific features added to the base WinFrame 1.7 product include:

The application publishing features and the two client-side features are available only to systems running WinFrame 1.7 client software. Existing network computers or Windows terminals cannot take advantage of these new capabilities.

Two additional features for WinFrame 1.7 are available as priced options. Load balancing and secure end-to-end transmission let you deploy WinFrame in larger and more sensitive organizations. Load balancing lets you interconnect multiple WinFrame servers to create application server farms. Any available server in the farm can respond to a new-connection request. Secure end-to-end transmission lets you use either domestic 128-bit encryption or international 40-bit encryption to encrypt client/server communications.

That Déjà Vu Feeling
I installed WinFrame 1.7 on a designated multiuser server system, a no-brand 133MHz Pentium system with 64KB of memory, two internal 2GB hard disks, and an NE2000-compatible Ethernet network adapter. I use this system for multiuser testing because NT Server 3.51 recognizes all its components. From my perspective, having to use an NT Server 3.51 base is the most annoying aspect of WinFrame. If you've ever tried to install NT Server 3.51 on a modern system with contemporary components, you know that it's no fun, because NT 3.51 usually won't work on today's hardware. (Few vendors develop NT 3.51 drivers for new hardware these days.)

For client-side testing I used a Wyse Winterm 2700 Windows terminal and my Compaq 5400 laptop system to run NT Server 4.0 and the WinFrame 1.7 client-side software. I used TCP/IP as the primary network transport between the clients and WinFrame server.

Although you need to do an extra licensing step, installing WinFrame 1.7 is not dramatically different from installing NT Server 3.51. You start with the three standard NT Server setup diskettes and a WinFrame CD-ROM that contains NT Server 3.51 and the WinFrame extensions. One big improvement in WinFrame 1.7 is a change in the way it handles licensing. In previous versions of WinFrame, you used a separate licensing diskette to enable WinFrame. This approach is vulnerable to a system crash­if your WinFrame system crashes after you apply the license, you have no way of recovering the license from the server and must plead for a new license diskette. This situation has happened to me more than once, so I've come to really hate diskette-based licensing.

With WinFrame 1.7, you get an activation key that gives you a 30-day grace period to secure a permanent license. You can get the permanent license over the phone or over the Internet. Because the NT Lab has a permanent Internet connection, I opted for that route. Now you would think that because WinFrame supports licensing over the Internet, Citrix would have included a 3.51-compatible version of Microsoft's Internet Explorer (IE) with the program. I thought that, and I was wrong. So the first thing I had to do before I could secure a license was to download the appropriate version of IE and install it on my WinFrame server.

After I installed IE and connected to the appropriate Citrix licensing page, I found out I needed the client-side software installed on my WinFrame server. Why? Because the licensing program runs on a WinFrame server and is accessed through a Web-enabled WinFrame session. So I quickly installed the client software and went back to the site. This time the browser fired up my WinFrame session with no problem and I stepped through the licensing process with ease. This approach is a big improvement over the old diskette-based licensing model.

Making Connections
Once I got WinFrame 1.7 up, running, and licensed, I ran (well, actually walked) over to our Wyse Winterm 2700 terminal and pointed it at the new server. I then initiated a connection from the terminal to the server. The WinFrame/Windows NT logon screen greeted me. I logged on to the WinFrame server and ran IE and most of the standard NT utilities (Notepad, Disk Administrator, and so on). All of these applications ran just fine.

I then moved back to my laptop and installed the WinFrame 1.7 client-side software. I was then able to initiate a session between my laptop and the WinFrame server and run IE and the NT utilities. At that point, I was convinced that the basic installation and configuration of my WinFrame environment was in order, so I moved on to test some of the new WinFrame features.

First, I played around with the client-side caching and compression settings. I could certainly tell when caching was enabled­whenever I revisited the WinFrame server and applications I had previously run, I saw a slight performance increase. This increase is very similar to what happens with caching on Web browsers. The increase is nothing spectacular, but it can make a difference. Client-side caching is clearly a logical and beneficial addition to the client-side software.

Compression proved to be a little more difficult to detect. Given the light load I was applying to the network (one client, one server), I could barely see any difference between the compressed and noncompressed modes. However, having read study after study of Independent Computing Architecture (ICA) versus X11 comparisons, I remain convinced that noncompressed ICA offers better overall LAN performance than compressed ICA. You just need a reasonable workload to see the difference.

The Joy of Publishing
The next feature I tackled was the new publishing capability application. This feature lets you publish an application from the WinFrame server in order to easily configure the client-side connection. You can then integrate the client-side reference to that application into the Start menu so the application appears as standard. When you start the published application, the WinFrame client software starts, establishes the connection to the WinFrame server, automatically logs on, and then starts the desired application. On the client system, all you see is the application starting.

The first step in publishing an application is to run the Application Configuration utility on the WinFrame server. Using this utility, you define the application on the WinFrame server that you want to make available as a published application. As shown in Screen 3, page 92, you configure the name of the application, what server it runs on (Working Directory), and where the program file resides on the server (Command Line). In my test, I defined IE as a published application and assigned it the name Explorer.

After you publish an application from a server, you go to the client system to complete the process. First, you launch the WinFrame 1.7 client-side Remote Application Manager program. To create a new client-side application link, you choose New from the Entry drop-down menu and select the Published Application option on the Add a new Remote Application dialog box, as shown in Screen 4, page 92. The client will then look on the network for the applications currently available on WinFrame servers. In my case, it came back with the name Explorer.

After you select the published application, you configure logon information (assuming you want automatic logon) for the WinFrame server, caching support, and compression support. Finally, you add the application to the Start menu. Once you've configured the application, you can start it either from the Remote Application Manager or from the entry on the Start menu (if you put it there). When you select the application, the WinFrame client software connects to the WinFrame server, logs you on (if you entered the logon information), and starts the application. All you will see is the application running on your desktop. Screen 5 shows the published Explorer application running on my desktop.

The application publishing feature is beneficial on several levels. First, application publishing makes configuring client systems easier for you. Instead of trying to remember what applications are available on what WinFrame servers, you let clients simply pick from the available published applications. Second, application publishing provides better integration with the client desktop. Instead of having to launch a WinFrame session, log on to the server, and start the application, you just launch the application from your desktop and it appears automatically. It works like any other application on the client desktop­it just gets launched across the network.

I think the application publishing feature of WinFrame 1.7 is the most compelling reason to buy WinFrame or upgrade from a previous version. This feature shifts the client's attention from client/server connectivity to the application access, which is where the client's attention should be. My only complaint about this feature is that you cannot use it from Windows terminals or network computers. You must use the WinFrame client to take advantage of application publishing.

Caught in the Web
The final WinFrame 1.7 feature I tested was client-side Web browser integration. This integration lets you place a file reference on a Web page and start a WinFrame session by clicking that reference. The file reference must point to an ICA file. An ICA file contains all the information you need to start a link to a WinFrame server and launch an application.

You create ICA files with the server-side Application Configuration utility. In brief, you follow the process to define a published file and then save the definition to a local (ICA) file. You can then move the ICA file to a Web server, generate an HTML reference to the file in a Web page (i.e., file://), and voilà, you're set. Well, almost.

For your browser to automatically start a WinFrame session, you must configure the browser to recognize the new file type (ICA) and act accordingly. The easiest way to configure the browser is to use an external helper program. Citrix provides a helper program (wfica32.exe) on its setup CD-ROM. When you run this program with the /setup option, the program registers with your default browser. Then, when you click an ICA file reference on a Web page, your browser launches the WinFrame helper and feeds it the file information. The helper program then connects to the WinFrame server and optional application as specified in the ICA file.

You can install the WinFrame client as a Netscape plug-in or an IE ActiveX component. If you have a simple Web page, these approaches end up looking like the helper program­the WinFrame session gets launched as a program external to the browser. However, you can also add some code to your Web pages to get the WinFrame plug-in component to run inside the browser. On its Web site, Citrix has a few examples of how the Web-page coding works.

For my tests, I ran the external helper program from both Netscape and IE. I also ran the Navigator plug-in, but I didn't set it up to run inside the Web page. I was amused by the results when I ran the WinFrame connection from Navigator. I was using my published Explorer application in my Web page, so when I clicked on it using Navigator, the helper program launched a WinFrame session that ran IE on my server. In other words, I used Navigator on the client to start IE on the server. (Hey, I'm easily amused.)

The one feature that wasn't available when I conducted my test was the Java-based interface to WinFrame. Although this interface will certainly be a welcome addition to the family of browser integration modules, I found the other methods worked just fine. Of course, if your client platforms aren't Intel systems running a Microsoft operating system, the Java interface may look very attractive to you.

Win with WinFrame?
WinFrame 1.7 is certainly the most interesting version of WinFrame I have tested. The application publishing and Web integration features work well and provide a means of making applications available to clients that are both easy to deploy and easy to manage. In my opinion, WinFrame 1.7 has only one drawback: It's based on NT Server 3.51. Although Citrix argues that many corporations continue to use 3.51 and many applications continue to run on it, finding hardware and software that is backward compatible with NT 3.51 gets harder every day. Still, if NT 3.51 is acceptable in your situation, you certainly can't go wrong with WinFrame 1.7. It is the best of breed in today's multiuser NT market.