Providing Windows Applications to Users: Nine Different Theories and Architectures

Longtime readers of my work know that I believe that IT exists for one single reason—to provide access to applications for end users. As little as ten years ago this was relatively easy.

Longtime readers of my work know that I believe that IT exists for one single reason—to provide access to applications for end users. As little as ten years ago this was relatively easy. All we had to do was install the applications on the users’ computers. But then came automated software distribution tools. Then Citrix. Then VMware, bladed PCs, and streaming.

In today’s world, the job of IT is more complex. We usually end up using whatever de facto technology method we’ve been using to give users access to their applications. But if we take a step back, we’ll see that there are actually quite a few different (and very real) ways to provide these applications to users.

In this article, I’ll look at nine different application access architectures that we can use to provide Windows applications to users, and I’ll evaluate the pros and cons of each.

The options are:

  1. The old way. Install each application on the end user’s computer.
  2. Automated Software Distribution. Use a tool like SMS or Altiris to remotely install and update applications on end users’ computers.
  3. Citrix / Server-Based Computing. Install the application centrally on a terminal server and provide RDP or ICA access from the client device.
  4. Application Streaming. Use something like Softricity to stream the application to the user’s device on demand.
  5. Operating System Streaming. Use something like Ardence to stream the entire disk image (OS and all) to the user’s client device.
  6. Bladed PC. Install Windows XP on a server blade and then provide 1-to-1 remote access via XP’s built-in RDP remote desktop functionality.
  7. VMware PC. Build a huge VMware server and divide it into multiple VMs, with each VM running Windows XP. Provide remote access via XP’s built-in remote desktop.
  8. VMware Clients within Terminal Server / Citrix Sessions. Build a server and install terminal services and Citrix. Install VMware Workstation (or Microsoft Virtual PC) as a publish application in Citrix. Then “publish” a VMware disk image for each user. Users connect to the published VM via ICA.
  9. The Future. Application execution components can execute on whichever backend systems they need (in a grid-like way), and presentation components can be displayed and consumed wherever they are needed.

Let’s take a look at each option more in-depth.

Option 1. The Old Way

Install each application on each end user’s computer, just like you’ve been doing for the past 20 years.

Pros

  • No application conflicts
  • We all know how to do this already
  • No servers are required

Cons

  • Applications need to be installed and updated manually
  • No way of knowing who has access to what
  • Applications can become corrupted or messed up by users
  • No easy backup
  • A single PC crash will take down that worker until IT can build a new PC.
  • Application access is based on physical machine (i.e. if a user walks up to a PC, they can use whatever is on it)

Option 2. Automated Software Distribution

Use a tool like SMS, Altiris, or ZENworks (does that even still exist?) to remotely install and update applications on end users’ computers.

Pros

  • Centralized management of applications
  • Applications installed on end user PCs can be inventoried

Cons

  • You have to learn how to package applications and updates
  • Applications can become corrupted or messed up by users
  • No easy backup
  • A single PC crash will take down that worker until IT can build a new PC.
  • Application access is based on physical machine (i.e. if a user walks up to a PC, they can use whatever is on it)

Option 3. Citrix / Server-Based Computing

Install the application centrally on a terminal server and provide RDP or ICA access from the client device.

Pros

  • Centralized management and configuration
  • Centralized backup
  • Connections from any device
  • Policy-based access (Only access certain application capabilities from certain clients in certain situations)

Cons

  • All application execution happens centrally, even when a client device is capable of doing work.
  • Requires major build-out of datacenter to create and add capacity (although this means that HP or IBM will invite you to their golf outings).
  • Client devices must be connected to the network in order to user their applications.
  • You have to learn how to install applications into multi-user environments
  • Not all applications will work (or will be practical) in multi-user environments


Option 4. Application Streaming and Virtualization

First of all, the terms “virtualization” and “streaming” are both trendy right now, and have both been taken over by many vendors to mean many different things. In this case, I’m referring to the ability of a client device to call for an application, and the application components are streamed on demand from the server to the client. All application execution happens on the client. In order to ensure that multiple streamed applications executing on the client do not conflict with each other, most of these products also employ some sort of virtualization or isolation technology that allows for different applications to execute on the client without conflicting with each other.

The most popular product in this space is Softricity’s Softgrid. Citrix has also announced something called Project Tarpon, although this is not a real product yet.

Softricity can be used to stream applications down to end user client devices. This can even happen outside of the firewall via a web portal that pushes down the Softricity agent and the applications to a new client computer.

Pros

  • A single applications package can be streamed to any client—end user devices or Citrix/Terminal Servers
  • No application conflicts
  • Clients can use the applications offline

Cons

  • You have to sequence / package all of your applications
  • Application communication across virtualization partitions can be tricky
  • Some applications won’t work.

Option 5. Operating System Streaming

Use something like Ardence to stream the entire disk image (OS and all) to the user’s client device. Explaining exactly how Ardence works would require an entire paper (coming soon), but the quick version is this: Ardence provides a network-based block-level disk redirection that redirects physical disks in client computers to virtual disk images sitting on network file servers. Client devices can each have their own vdisk files via 1-to-1 mapping, or multiple clients can share a single vdisk file.

A client computer boots to the network and the Ardence server recognizes it based on its MAC address and mounts the appropriate vdisk file.

Pros

  • Rebooting a machine resets everything back to the “gold” state
  • A single computer can do different things (by mounting different disk images) each time it boots. (Your Citrix server can become a backup server by night. Your receptionist’s PC can become grid node by night.)
  • Makes use of the power of all your PCs
  • Any client computer can act in any role

Cons

  • Must have network connectivity for this to work

Option 6. Bladed PC

Install Windows XP on a server blade and then provide remote access via XP’s built-in RDP remote desktop functionality. Clients connect from thin client devices. In most cases you could store the users’ disk volumes on a SAN and mount them on-demand to the particular blade that the user connects to. (I've written about Bladed PCs in the past.)

HP has a product in this area called “Common Client Initiative (CCI).” In this case they can run multiple users off of a single blade, and they use special blade hardware that’s custom-designed for running Windows XP.

Pros

  • No application compatibility issues.
  • Better / easier security.
  • The clients run the "workstation" version of software.
  • Users have more control over their individual desktop.
  • Easier backups.

Cons

  • Must have network connectivity for this to work.
  • Management tools are needed to manage the software within each bladed PC.

Option 7. Centralized VMware PC

Build a huge VMware server and divide it into individual VMs, with each VM running Windows XP. Provide remote access via XP’s built-in remote desktop. Clients connect from thin client devices. (I've written about this in the past.)

This is a lot like Option 6, except this option has each user going to a Windows XP session in a VM instead of to their own native blade. Using VMware provides several options, mainly, that VMware sessions and be suspended (and unloaded from memory) and resumed later on (much like hibernating a laptop). For instance, imagine that after a 30-minute idle period, the user’s session is disconnected. Their session would remain active on the server for four hours, but after that the virtual machine is suspended and its memory contents dumped to disk. At this point that VM is consuming no server resources and can stay suspended forever. When the user finally comes back (even after several weeks), their session is just retrieved from disk and restored to any available server, and the user picks up right where they left off.

This will be really cool when Citrix gets involved. Even though they haven’t announced anything, you know that Citrix has to be thinking about this. For example, right now this technique involves a user connecting to a Windows XP workstation via RDP and the workstation’s built-in remote desktop functionality. This is a perfect opportunity for Citrix to come in with ICA, and to let the users connect to their desktop VMs via ICA.

Also, and more importantly, Citrix could provide the crucial middleware “glue” to hold all this together. This method requires that a user authenticates, and then the system has to figure out which VM host has capacity, find the users virtual disk files, fire up a VM using those files, and then connect the user via ICA to that VM. This is complex. However, Citrix has experience managing all of these issues in a Presentation Server world, so I would imagine it’s not too difficult to apply this technology to VMware. Look for major announcements from these two companies in this space.

Pros

  • Better performance.
  • No application compatibility issues.
  • Better / easier security.
  • You can "suspend" individual VMs and then move them from server to server.
  • The clients run the "workstation" version of software.
  • Users have more control over their individual desktop.
  • Users can take their sessions with them when they go offline (by “checking out” their disk images and running them on a local VM on a client device (like ACE).
  • Central backups.

Cons

  • A lot of server hardware is required.
  • Management tools are needed for the desktop VM.
  • Good luck if you want to do this today

Option 8. VMware Clients within Terminal Server / Citrix Sessions

Build a server and install terminal services and Citrix. Install VMware Workstation (or Microsoft Virtual PC) as a publish application in Citrix. Then “publish” a VMware disk image for each user. Users connect to the published VM via ICA. (Citrix has some articles about how to configure this.)

Pros

  • No application compatibility issues.
  • Better / easier security.
  • You can "suspend" individual VMs and then move them from server to server.
  • The clients run the "workstation" version of software.
  • Users have more control over their individual desktop.
  • Users can take their sessions with them when they go offline (by “checking out” their disk images and running them on a local VM on a client device (like ACE).
  • Central backups.

Cons

  • This seems like a stretch but it’s the best we can come up with now
  • One instance of VMware in each session? I wonder how that performance is?

Option 9. The Future

What’s the problem with today’s applications? They’re still running on a basic architecture that’s more than 20 years old. Current Windows applications are designed to run one at a time, within the walls of one single box, and with one (local) user interface.

Web applications do a great job of running on multiple servers, and a great job of separating the application execution from the user interface. Their main downside is the fact that they’re web apps and not Windows apps.

The Future: Terminal Server and Internet Information Server merge into a single product (called Microsoft Application Server). Applications execution components can execute on whichever backend systems they need and presentation components can be displayed and consumed wherever they are needed. The OS runs on the network and not a single computer.

Pros

  • This Rocks

Cons

  • Okay, it’s not “technically” possible (yet)

Combining Multiple Options

Of course the nine options presented above are not mutually exclusive, and they’ll change and evolve over time. For example, think about running Citrix servers in VMs. This would allow you to provide users with policy-based ICA access to individual applications while still having server flexibility on the backend.

Think it’s not possible for performance reasons? Simply wait another year or so until Microsoft releases Longhorn server with its built-in VM hypervisor and all Intel and AMD CPUs support hardware-level virtualization. (Imagine the advantages of virtualization without the performance penalties.)

Imagine using Softricity to stream applications to Citrix servers. This would allow you to provide users with policy-based ICA access to individual applications while still having server flexibility on the backend, AND you won’t have to install any applications onto any servers.

Now add Ardence to the picture to stream the Operating System to the server, and continuing using Softricity to stream applications to the server, and use Citrix to provide policy-based remote access to those applications. Go nuts and put this all in a VM!

The bottom line is that we’re moving into a world where any application can be executed on any backend server, and the user interface will be built for the user regardless of where they are. Some of the ideas in this article are just theoretical, but many are real today.

Did I get this right? Did I miss any pros or cons or did I miss a whole section? Share your thoughts below.

Dig Deeper on Virtual Desktop Clients

27 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchVirtualDesktop

SearchEnterpriseDesktop

SearchServerVirtualization

SearchVMware

Close