Microsoft provides the free-to-download
Application Compatibility Toolkit (ACT) to help you get legacy
applications working on Windows 7. Using it, you can go through the
process of identifying your legacy applications, test them, track your
progress, and even create shims to fool those applications into
believing that they are running on Windows 7. You will now learn how to
plan for ACT, install it, and use it to resolve application
compatibility problems.
1. Choosing an ACT Architecture
To plan for ACT, you will need to understand how it
works. There are two basic ways to use ACT. It contains a number of
tools for creating shims to mitigate application compatibility issues. A
simple, quick installation of ACT allows you to do that. However, to
make the most of ACT, you will probably use the Application
Compatibility Manager (ACM) tool.
ACM allows you to deploy an agent called a data
collection package (DCP) to selected PCs, or even all of them, to gather
information about the applications and application versions that are
out "in the wild." The DCPs will create periodic data files and send
them to a file share of your choosing. A central ACT installation, the
Log Processing Service, will process the files from this file share and
store the information in a SQL database. Administrators and engineers
can use ACT to connect to the SQL database. This allows them to generate
reports, connect with Microsoft to download up-to-date information on
compatibility issues, and track the progress of the project. Finally,
ACT contains tools that can be used on test and development machines to
create shims to enable otherwise incompatible applications to work on
Windows 7.
ACT is pretty flexible, and you can architect your
configuration to suit the project and the organization you are working
in. The configuration can vary from the all-in-one-machine installation
to a multisite setup that allows dozens of people across continents to
collaborate on a corporate solution.
Figure 1 shows the most basic architecture that you might use while learning the product or while working in a small organization.
All of the ACT components are installed onto a single
machine with this basic installation, labeled as ACT Workstation. This
can be a single server, PC, laptop, or even a VM. Using the latter
option offers some advantages. Virtualization obviously reduces costs
for the organization. Consultants can even build a VM with no data and
reuse it in different customer sites, minimizing the time required to
start working on the solution for their customers.
The SQL installation that you use for the
single-machine and single-user architecture can be the free SQL 2008
Express. Only local users and applications can use this database, and
the database is limited to 4 GB. You will need to use one of the
paid-for editions of SQL Server 2008 if you need to use the database
remotely or if the database will be larger than 4 GB.
With the installation illustrated in Figure 1,
the administrator is doing all the testing and development work on a
single machine. That's not an ideal solution because you never know if
one application will contaminate the computer and affect the work you do
with other applications. It's for this reason that you should consider
using a number of test machines, as shown in Figure 2.
There are a few ways you can approach having test
machines. A cost-effective solution is to use virtualization.
Microsoft's Virtual PC for Windows 7 and Hyper-V Server 2008 R2 are free
products that you can use for this purpose. Virtualization allows you
to create a sample or template machine that you can redeploy for every
application solution that you work on. This is a speedy solution too.
Alternatively, you can use machines that are typical of the
organization. It's important to do this if you are working with
applications that integrate with the hardware.
Larger organizations may seek a different solution.
It may be necessary to have a large database and to allow many
administrators to work on it at once. Figure 3 shows how you can achieve this goal in a single network.
A paid-for edition of SQL is used to host the ACT
database in this scenario. It is possible to place the file share on the
SQL server or on a different machine. There's a good chance that you
will use an existing SQL server for the ACT database. The owners of that
machine probably won't like the idea of a file share being created on
it, so you can use another file server for this role.
The DCP that you deploy to the desktops and laptops
on your network will upload a file to the file share on a configurable
periodic basis. This file contains information about the applications on
the network. This process could cause an issue for your wide area
network (WAN). The files may be small, but few network administrators
will be thrilled about additional frequent traffic using up the WAN
bandwidth. You can create agents for each collection of machines that
you wish to target for data collection. This approach allows you to
specify a local file share in each branch office. You can see this in Figure 4.
All that remains now is to get the data back to the
central file share from the local file shares for processing by ACT. You
could use some file replication mechanism such as Distributed File
System Replication (DFS-R), schedule copy tasks during off hours using a
tool like Robocopy, or even burn a few weeks' worth of data on a DVD
and send it by courier.
Consider how the organization and the application
compatibility project will be run. Then choose the most suitable ACT
architecture. The great thing about ACT is that it is very modular and
will allow you to adapt to changes in the project. We're now going to
show you how to install ACT using the architecture shown previously in Figure 2.
