Using 2X ApplicationServer to Publish Applications, Part 1

by [Published on 20 June 2007 / Last Updated on 20 June 2007]

The benefits of being able to host individual applications in a Terminal Service environment and the basic architecture involved in running 2X Application Server in an organization containing multiple Terminal Servers.

If you would like to read the other articles in this series please go to

In most cases, using the terminal services is an all or nothing situation. Typically, either your user’s entire desktop is hosted on a terminal server, or the entire desktop runs locally. Sometimes though, it would be nice to be able to host individual applications in a terminal service environment rather than having to host users’ entire desktops. This is especially true in situations in which users run a wide variety of applications and desktop configurations rather than using one standard configuration and set of applications.

Windows Server 2008 is designed to allow you to host individual applications through the Terminal Services, but as I’m sure you know, it is still in beta testing and probably will be for quite some time. Even if Windows Server 2008 were to be released tomorrow, it would probably still take some time before most companies implement it. If you want to be able to host individual applications on your terminals server today, then one option is to use 2X ApplicationServer (http://www.2x.com).

Like Windows Server 2008, 2X ApplicationServer allows you to publish an application rather than installing it locally on users’ workstations. This means that users can continue to use their current desktop and their currently installed applications right alongside hosted applications. Users will likely never even know that hosted applications are not installed locally.

Right now you might be wondering why you would ever want to publish an application through a terminal server if your other applications are installed locally on the workstations. There are several reasons why this type of configuration might be beneficial.

For starters, if an application is hosted on a terminal server, then there is only one copy of the application to maintain. This reduces costs because you do not have to install updates to the application or make repairs to the application on every workstation.

Another reason why hosting individual applications is beneficial is because applications can be deployed based on username, group membership, or even IP address. This means that if you hire a new employee, there is no need to take the time to install hosted applications on the employee’s workstation. Just add the new employee to a group for which the application has been made available.

A third reason why hosting applications on a terminal server is a good idea is because doing so allows you to get around desktop hardware limitations. For example, suppose that you needed to deploy a new application, but some of the older workstations lacked the memory or disk space to run it. You could upgrade or replace the older machines, but doing so tends to be expensive. If you were to run the application in a terminal service environment instead, the workstation hardware wouldn’t really matter so long as it was powerful enough to run the 2X client component (which I will talk more about later on). The application would be running on the server and only screen updates are sent to the client.

Just as hosting applications on a terminal server gets you around desktop hardware limitations, it also allows you to run an application on machines that are running an incompatible operating system. Remember that the application itself is actually running on the terminal server, and the workstation is simply running client software that allows it to receive screen images of the hosted application. Because 2X makes clients for Windows, Macintosh, and Linux, it becomes possible to run an application on all three platforms without the use of emulators or special versions of the applications.

One last reason why it might be beneficial to host individual applications is that doing so allows you to make a gradual transition to a thin client environment. Switching from an environment in which applications are running directly on the workstations to a thin client environment is a major undertaking. By hosting individual applications, you can make the move to a thin client environment one application at a time, without your users ever even noticing.

The 2X Components

Before I show you how to work with 2X ApplicationServer, you need to be aware of its basic components. The first of these components is the ApplicationServer and LoadBalancer. This component is made up of two sub components; the Publishing Agent Service and the 2X Management Console. As you have probably already guessed, the 2X Management Console is the GUI through which all configuration and management is performed.

The second component is the 2X Terminal Server Agent. The Terminal Server Agent’s job is to collect resource availability information from the Terminal Services and then report that information to the LoadBalancer. That way, ApplicationServer can always use the available Terminal Server resources efficiently.

The final component is the 2X Client Gateway. The 2X Client Gateway’s job is to tunnel all of the traffic related to hosted applications over a single, secure port.

Deployment Scenarios

After my quick breakdown of the 2X ApplicationServer components and sub components, it probably sounds as though the installation process is complicated and requires a lot of planning. The Setup program actually makes the installation process a lot easier than what I would have expected. At one point in the installation process, Setup simply asks you if you have a single terminal server or multiple terminal servers.

If you choose the single terminal server option, then Setup knows exactly which components need to be installed in order to make 2X ApplicationServer work with your terminal server. If you choose the Multiple Terminal Server installation option, then things get a bit more complicated. Setup asks you which specific components you want to install.

If you are deploying 2X ApplicationServer is an environment with multiple terminal servers, then 2X recommends installing only the Terminal Server Agent onto your terminal servers. They also recommend configuring another server to act as a gateway between your network clients and the terminal servers.

This gateway machine must run the Publishing Agent and the Client Gateway components at a minimum. This machine’s job is to listen for Remote Desktop Protocol (RDP) traffic from the workstations, and forward the traffic to a terminal server. Assuming that the machine is also running the LoadBalancer component, it will be able to select a terminal server based on its current workload. You can see a diagram of this type of deployment, shown in Figure A.


Figure A: This is the recommended deployment configuration for organizations with multiple terminal servers

One aspect of 2X ApplicationServer that I have not yet mentioned is that it allows you to host applications over the Internet. By default, the client gateway will tunnel Web traffic over localhost port 81. You can change the port number to 80, and also have the option of using SSL encryption over port 443. The Web port cannot be changed during the initial installation though. You can only change it once installation is complete.

Conclusion

In this article, I have explained some of the benefits of being able to host individual applications in a terminal service environment. I then went on to discuss the basic architecture involved in running 2X Application Server in an organization containing multiple terminal servers. In Part 2 I will continue the discussion by showing you how to configure 2X Application Server for operation once it has been installed.

If you would like to read the other articles in this series please go to:

Featured Links