If you've used computers for any time, you've probably accessed another computer remotely, either by phone or by a network connection. In the beginning, the programs that made this capability possible were simple terminal-emulation programs that supported basic character displays.
Later, terminal programs let you use emulation, such as VT-100, VT-220, and Tektronix emulation, to display some rudimentary graphics. As GUIs began to gain market share, simple terminal programs were no longer adequate. Computer users wanted the same slick GUI and all its amenities, whether they ran programs locally or remotely. The UNIX community addressed this issue with the X Window System.
In the Windows and DOS markets, programs such as pcANYWHERE let you run native applications remotely. The programs executed on the remote machine--the host--and the results were piped to your machine--the client. These second-generation programs were slow and offered access to only one user at a time.
The multi-user problem had many interesting solutions. One vendor offered a PC full of cards that were individual computers--one computer for each user. Multiprocessor computers are commonplace now, but then they were quite a novelty. Specialized software gave each user access to his or her own virtual computer. The problem was that every time a screen changed, the host computer had to send all the information to the client computer. (Generally, the link wasn't too fast to begin with.) All this traffic caused lengthy delays and made the application an exercise in frustration for all but the most die-hard user.
Along Came Citrix
Citrix divided the problem into two parts: First, address the speed concerns. If you had to wait 1.5 to 3 minutes for a screen update, this technology's success was going to be limited. Second, reduce the cost per user. If more users could use the same machine at the same time, companies could amortize costs over those users.
Citrix developed a product that solved both parts of the problem: WinView ran on OS/2 and performed reasonably well. WinView made multi-user remote access possible at a reasonable speed, but the product wasn't really the one Citrix wanted to build. This situation was a case of Citrix being ahead of its time. OS/2 just didn't have the horsepower to do what Citrix had in mind.
We won't tell you that Windows NT's rapid rise and success saved Citrix. The truth is, the Citrix technology is so good that if NT weren't available, Citrix probably would have chosen some other platform. But in the end, NT is exactly what Citrix was looking for.
The result of this story is WinFrame for Networks. WinFrame is not a service that runs on NT; it's an extension to NT.
What? A proprietary version of NT? Well, sort of. When you install WinFrame, you are installing NT. Citrix has licensed the source code from Microsoft and extended the NT kernel to allow multiple simultaneous desktops for concurrent users. Sounds confusing, but it really isn't.
Building on NT's strengths, such as Remote Access Service (RAS), scaleability, symmetrical multiprocessing (SMP) support, security, and remote-node communications, WinFrame adds concurrent multi-user event tracking, messaging, and performance monitoring. In addition, it provides utilities for configuration and multiple concurrent profiles. The coup de gras is the Citrix Intelligent Console Architecture (ICA) protocol. This protocol is what makes WinFrame faster than other remote-node software.
Installation for WinFrame takes about the same time as installing Windows NT Server, and the installation program is the same. Currently, WinFrame runs only on Intel platforms. The Windows NT Magazine Lab chose a Telos 100-MHz Pentium with 64MB of RAM and a 2GB SCSI drive. A 3Com 3C589 EtherLink III card rounded out the mix.
We didn't experience any surprises. The beta version we tested didn't add the WinFrame icons to the Administrative Tools program group. But a quick call to customer support gave us a workaround and a promise to fix this oversight in the shipping product.
Next, you configure a WinStation, which is like a virtual machine. If five concurrent users will be logged on to your WinFrame machine, you need to configure at least five WinStations.
Configuration is straightforward. First, select the WinStation configuration icon from the Administrative Tools group. Next, choose the WinStation drop-down menu, and select New. Screen 1 shows a sample WinStation dialog. You tell WinFrame what network transport protocol to use in the Transport box, and in the Type box, you tell it what type of client computer will communicate over this link.
With the server taken care of, the client is next. WinFrame supports a variety of clients: DOS, Windows 3.11, Windows 95, and Windows NT. We focused on the NT client.
The omnipresent InstallShield program lets you install the client portion. Insert the disk, run the setup.exe program, supply a directory path for the executables (or take the defaults), and you're done. Then, you can open the WinFrame Client group and click on the Remote Application Manager icon, as you see in screen 2.
To add a new remote application, you need to know which network protocol to use and the name of the WinFrame server. You also need to supply a valid user ID, domain name, and password for automatic logon. If you don't, you must log on to the WinFrame server just like any other NT server. Once you establish the connection, you can run any program on the WinFrame server.
WinFrame's ability to save the connection as an icon on your desktop is an especially nice touch. If you enable the automatic logon feature, you notice little difference between a locally running application and a remote one. From the user's standpoint, all computing is occurring on the WinFrame server. Your local client receives and sends only a minimum of information. The result is remote application execution that rivals local execution. (You can also run Windows applications on the Internet at 28.8Kbits per second--Kbps--or even at Integrated Services Digital Network--ISDN--speeds, using the ICA protocol that makes WinFrame so fast. A beta version for this purpose is available from Citrix's Web site at http://www.citrix.com/hotspot.htm.)
So far, so good. WinFrame certainly passed the network connection test. But how well would it fare on dial-up? You can use two methods to access WinFrame via modem: RAS and the WinFrame Remote Application Manager. To access a WinFrame server via RAS, connect to the RAS server, which can be on the same physical machine as the WinFrame server. If you connect to the WinFrame server via NetBIOS, you must configure your RAS server and client to support NetBIOS.
Once you connect to the network via RAS, you return to the Remote Application Manager. Launch your remote application as if you were connected locally. Performance is considerably slower for screen updates because the ICA protocol is competing for bandwidth with the other protocols RAS is supporting.
A much better solution is to use Citrix's--you guessed it--Remote Application Manager and set up a serial connection, as in screen 3. You must initialize a WinStation to support dial-up connections--it's the default for adding new WinStations. Next, you need to add a dial-up connection in the Remote Application Manager, which you do the same way as a network connection. The major difference is that for a dial-up connection, you select a serial device and install a modem.
WinFrame uses the modem.inf file that comes with NT and, unfortunately, doesn't auto-detect your modem. (A nice feature would be to add auto-detection for the release version.) After you install the correct modem and specify the serial port and phone number, you're ready to go. You can provide a user ID, domain name, and password or let the user enter them on connection. Then, click your newly created Connection icon, and NT automatically dials the WinFrame server, establishing a connection. You will immediately notice an improvement over RAS.
While not as fast as a direct network connection, the ICA asynchronous connection is much faster than RAS. Citrix claims the connection is at least 50% faster. Although we didn't run any formal tests--this is a beta product--we have no reason to dispute that number.
Each of the different clients can access the WinFrame server and remotely execute programs that they might not be able to execute locally. Imagine a DOS client running Office 95! NT's Gateway for Macintosh service provides access to Novell networks, handling remote printing just like any other NT client.
WinFrame uses NT security: You have no secondary security scheme to deal with. We commend Citrix for this approach. Coping with the day-to-day tasks is hard enough for administrators, without having to maintain two separate security systems.
WinFrame's management is a hybrid. For ordinary functions, such as security, user administration, and resource management, NT provides the tools. However, to make applications available, see who's connected to your system, and manage WinStations, you use WinFrame's tools. The WinStation Administration program, which you see in screen 4, lets you track WinStations available on the WinFrame server, users who are currently accessing it, and the processes that remote users are using.
Now, recognize that when you install new software, you can't just install the software. First, you need to make sure you are logged on as the local administrator of the server, and execute the command changeuser/install from the console. This command puts WinFrame into a system-install mode and lets you install the application globally instead of individually for a specific user. After you install the software, you must run changeuser/execute from the command line to put WinFrame back into execution-only mode. Subsequent installations will then be treated as user-specific installs.
I was disappointed to find that WinFrame is available only for Intel-based systems. The idea of a quad-processor Alpha, MIPS, or PowerPC server has great possibilities.
That limitation aside, WinFrame provides a rock-solid remote-computing environment that is inextricably tied to NT. The features that you ordinarily find in separate programs are available in a single, scaleable package. Add central management and superb integration with NT, and you have a true enterprise solution for remote-computing needs.
|WinFrame 1.6 Beta|
Citrix Systems * 800-424-8749|
Email: [email protected]