The area with the most flexibility in the planning of your
application deployment is the method by which you are going to install
and run your workstation applications. Windows 7 and Windows Server
2008 R2 provide a variety of application deployment options, and
selecting one is in most cases not a decision you want to leave to the
end of the workstation deployment project. How you deploy applications
to your workstations and how the workstations run those applications
is all part of the fundamental philosophy you want to apply to your
network.
To illustrate with widely opposed examples, one enterprise might
decide to deploy powerful, fat-client workstations with a lot of
memory and large hard disks, so they can deploy all of their
applications locally, as shown in Figure 1. In this case,
the administrators must decide what method they want to use to install
the applications on each computer.
In contrast, another enterprise might choose to purchase
relatively minimal, thin-client workstations and run the applications
on their servers, as shown in Figure 2.
These opposing scenarios have ramifications that extend far
beyond the application deployment process. The fat-client model
requires workstations with greater hardware requirements, which makes
them more expensive to purchase. The administrators must install all
of the applications on each computer individually and maintain them
individually as well. By making the clients do most of the work, the
servers can be relatively small.
The thin-client model enables the organization to
purchase smaller, less expensive workstations, but at the same time,
they must provide much larger servers with enough power to run all of
the applications for all of the workstation users. The server hardware
is much more expensive in this case, but the administrators have to
install and maintain only one copy of the applications on each
server.
As you can see, virtually every phase of the workstation
deployment process is affected by this decision. Workstation hardware,
client configuration, server hardware, and software maintenance
procedures are just a few of the elements that enterprise
administrators must plan with the application deployment process in
mind. The following sections describe the application deployment
options available to the Windows 7 desktop administrator and the
circumstances in which it is most appropriate to use each one.
1. Scaling the Application Deployment Process
As with the operating system deployment process, the size of
the project is the first element that planners should consider when
planning an application deployment. Installing applications on 10
computers is a lot different from installing them on 100, and 100 is
very different from 1000. For the most part, the same rule applies
to applications as to operating systems: the more workstations you
have to install, the more you want to automate the process.
2. Using Server-Based Versus Client-Based Applications
The two basic options for deploying applications on Windows 7
workstations are to install them on a server or on the individual
workstations. As mentioned earlier, the ramifications of this
decision extend throughout the deployment process. To install
applications on the clients, you must have workstations with
sufficient hardware to run the applications, and you must perform an
installation of each application on each computer. In a server-based
deployment, you install a single copy of each application on a
server and deploy it to the clients using a technology such as
Remote Desktop Services.
Installing Applications on Clients
Client-based deployments require greater workstation
hardware expenditures and have more complicated administrative
life cycles, but they have distinct advantages as well. Because
each workstation has its own copy of the applications, a certain
level of performance is guaranteed, based on the local hardware
available to run them. A server or network failure might be a
temporary inconvenience to the users, but their work can usually
continue.
A client-based deployment requires the administrators to run
an installation process for each application on each workstation,
which can be a complicated undertaking. Maintenance is also
complicated because each workstation must receive all updates and
configuration changes individually. The amount of trouble this
causes depends on the application itself. Microsoft Office, for
example, requires frequent updates, but Microsoft Update enables
administrators to deploy them along with the regular operating
system updates.
Other applications might require administrators to download
and evaluate updates and then deploy them to each workstation.
This is the type of situation in which a network management application such as SCCM 2007 can be
extremely beneficial. You can use SCCM not only to deploy the
applications themselves, but also deliver updates to the
workstations automatically, on a schedule determined by the
administrators.
Installing Applications on Servers
Server-based application deployments might seem like a much
simpler solution than client installations at first, but they too
have both advantages and disadvantages. In a server-based
deployment, you install the applications on a Windows Server 2008
R2 server with the Remote Desktop Services (RDS) role
installed. Client workstations then access the application from
the server, using the Remote Desktop client supplied with Windows
7.
Because the application runs on the server, the workstation
needs sufficient hardware only to run the client program, which is
minimal. Because the server has only one copy of the application
that services multiple clients, only one installation is required,
and the administrators have to apply updates only once. The
deployment process is therefore greatly simplified.
Although convenient for the administrator, deploying
applications using RDS increases the burden on the server
substantially. A single server might have to maintain application
sessions for dozens or hundreds of users at once, which means that
the computer needs more and faster processor cores and a lot more
memory. Administrators also have to consider the amount of network
traffic generated by this application sharing process. The RDS
client/server traffic generated by one session is not that much,
but when you multiply that by hundreds of clients, the additional
strain on the network can be significant.
Running applications on servers also provides a single point
of failure. If an RDS server goes down, all of its clients are cut
off from their applications. The same is true if a network outage
prevents the clients from accessing the servers. There is an
economic factor to consider as well. RDS clients require an
additional license, which adds to the cost of the operating
system.
The decision of whether to use server-based or client-based
applications is more of a philosophical than a practical one. Both
methods are viable solutions, and both have advantages and
disadvantages. If you are deploying new workstations into an
existing enterprise, you must consider whether your servers and
your network are up to the task before you decide on server-based
applications. If you are deploying Windows 7 and new applications
onto existing workstations, you must determine whether they have
the hardware to support the configuration.
There is, of course, no need to deploy all of your
applications using one method or the other. You can install some
applications locally, while running others from servers. There are
frequently economic and licensing issues that affect this
decision. For example, you might want to install Microsoft Office
on each workstation locally because all of your users need it and
automating the deployment of the applications and their subsequent
updates is relatively easy. You might also have an application
that various users need only occasionally. Rather than installing
the application on every workstation and purchasing licenses for
everyone, you can deploy it on a server and purchase only enough
licenses to support the maximum number of users at any one
time.
