Preparing the Lab
Planning
application deployment requires a lab environment for both
compatibility testing and application repackaging. Within an
organization, different teams that work on deployment (computer imaging,
application packaging, and so on) can and often should share a single
lab environment. Sharing a lab enables teams to more easily share
deliverables and integration-test their work with other components. In a
shared lab environment, however, each team must have its own workspace
on the file server and dedicated machines on which to work.
While the lab must have
access to the Internet, it should be separate from the production
network. However, if you don’t install any server components like
(Dynamic Host Configuration Protocol), separating the lab from the
production network is not a rigid requirement. Application repackaging
and compatibility testing do not require that the lab mirror the
production network. The lab must provide storage space for application
source files, repackaged applications, and application-compatibility
fixes.
The following list describes the recommended requirements for a lab used to compatibility-test and repackage applications:
Lab server configured as follows: Windows Server 2003 R2 A Microsoft Active Directory directory service domain Dynamic Host Configuration Protocol (DHCP) services Domain Name System (DNS) services Windows Internet Naming Service (WINS) services Microsoft SQL Server 2000 or Microsoft SQL Server 2005 Microsoft Virtual Server 2005
Lab test accounts (restricted users and administrator) Network hardware to provide connectivity Internet access (for downloading updates, files, and so on) Test computers that accurately reflect production computers Source files for all applications to be tested and repackaged Application Compatibility Toolkit 5.0 Software repackaging tools
Planning Deployment
Creating
an application inventory is the key task you must complete when
planning application deployment. You use the inventory to prioritize
applications, determining which are not compatible with Windows Vista,
which you must repackage for automatic installation, and so on. ACT
provides tools for collecting an application inventory based on the
production network. For more information about using ACT to inventory
applications, see the Application Compatibility Feature Team Guide in BDD.
After creating an application inventory, you must take the following planning steps for each application in the list:
Priorities
Prioritize the application inventory so that you can focus on the most
important applications first. While prioritizing the inventory, you
might discover duplicate applications (different versions of the same
application or different applications fulfilling the same purpose),
which you would eliminate. You may also discover many applications that
were used for a short-term project and are no longer required. Categories Categorize each application in the inventory as a core application or a supplemental application.
A core application is common to most computers (virus scanners,
management agents, and so on), while a supplemental application is not. Installation Method
Determine how to install the application automatically. Whether the
application is a core or supplemental application, you achieve the best
results by completely automating the installation. You cannot automate
the installation of some legacy applications; you must repackage them.
If so, the best time to choose a repackaging technology is while
planning deployment. Subject Matter Experts
You will not have the in-depth understanding of all applications in the
organization necessary to repackage them all. Therefore, for each
application, identify a subject matter expert
(SME) who can help you make important decisions. A good SME is not
necessarily a highly technical person. A good SME is the person most
familiar with an application, its history in the organization, how the
organization uses it, where to find the media, and so on. Configuration
Based on feedback from each application’s SME, document the desired
configuration of each application. You can capture the desired
configuration in transforms that you create for Windows Installer–based
applications or within packages you create when repackaging legacy
applications. Configuring legacy applications is usually as easy as
importing Registration Entries (.reg) files on the destination computer
after deployment.
BDD includes templates
for documenting and prioritizing the application inventory. These are
in %PROGRAMFILES%\BDD 2007\Documentation\Job Aids after installing BDD.
The file Inventory Template.xls helps you record and prioritize the
application inventory. The file Assessment Template provides a template
for recording the planned configuration and installation method of each
application.
ACT 5.0
provides data organization features that supersede the application
inventory templates in BDD, however. With ACT 5.0, you can categorize
applications a number of ways: by priority, risk, department, type,
vendor, complexity, and so on. You can also create your own categories
for organizing the application inventory. Figure 1 shows an example of an application inventory with the user editing an application’s priority.
Priorities
After creating an
application inventory, the next step is to prioritize the list.
Prioritizing the application inventory is not a task that you perform
unilaterally. Instead, you will want to involve other team members,
management, and user representatives in the review of priorities.
The priority levels you choose to use might include the following:
High High-priority
applications are most likely mission-critical or core applications.
These are applications that are pervasive in the organization or are
complex and must be addressed first. Examples of high-priority
applications include virus scanners, management agents, Microsoft
Office, and so on. Medium
Medium-priority applications are nice to have but not essential. These
are applications that are not as pervasive or complex as high-priority
applications. For example, a custom mailing-list program might be a
medium-priority application because you can replicate the functionality
in another application. To test whether an application is indeed a
medium priority, answer this question: What’s the worst that would
happen if all the high-priority applications are deployed but not this
application? If you foresee no major consequences, the application is a
medium priority. Low
Low-priority applications are applications that deserve no attention in
the process. Examples of low-priority applications are: duplicate
applications, applications that users have brought from home and
installed themselves, and applications that are no longer in use. When
prioritizing an application as low, record the reason for that status in
case you must defend the decision later.
Prioritizing the
application list helps you focus on the applications in an orderly
fashion. Within each priority, you can also rank applications by order
of importance. Ranking applications in an organization using thousands
of applications is a foreboding task, however. Instead, you might want
to rank only the high-priority applications or repeat the prioritization
process with only the high-priority applications.
Categories
After
prioritizing the application list, you must categorize each high- and
medium-priority application. You can drop the low-priority applications
from the list, as you have no intention of addressing them. The
following categories help you determine the best way to deploy an
application:
Core Application
A core application is an application common to most of the computers in
the organization, or one that must be available the first time you
start a computer after installing the operating system. For example,
virus scanners and security software are usually core applications,
because they must run the first time you start the computer. Mail
clients are core applications, because they are common to all users and
computers. The following list contains specific examples of what most
organizations might consider core applications: Adobe Acrobat Reader Corporate screen savers Database drivers and connectivity software Macromedia Flash Player Macromedia Shockwave Microsoft Office Network and client management software, such as OpenManage clients Terminal emulation applications, such as TN3270 Various antivirus packages Various Microsoft Internet Explorer plug-ins Various Microsoft Office Outlook plug-ins
Supplemental Applications
Supplemental applications are applications that aren’t core
applications. These are applications that are not common to most
computers in the organization (department-specific applications) and
aren’t required when you first start the computer after installing a new
operating system image. Examples of supplemental applications include
applications that are department-specific, such as accounting software,
or role-specific, such as dictation software. The following list
contains what most organizations consider supplemental applications: Microsoft Data Analyzer 3.5 Microsoft SQL Server 2005 Client Tools Microsoft Visual Studio 2005 Various CAD applications Various Enterprise Resource Planning (ERP) systems
Installation Methods
For each high- and medium-priority application, you must determine the best way to install it. For each, consider the following:
Automatic Installation
Most applications provide a way to install automatically. For example,
if the application is a Windows Installer package file (with the .msi
file extension), you can install the application automatically. Repackaged Application
If an application does not provide a way to install automatically. Repackaging applications is a complex process
and is quite often the most costly and tedious part of any deployment
project. Make the decision to repackage applications only after
exhausting other possibilities. Doing so requires technical experience with repackaging applications or using third-party companies to repackage the application for you. Screen Scraping
You can automate most applications with interactive installers by using
a tool that simulates keystrokes, such as Windows Script Host.Understand that this method is more of a hack
than a polished solution, but sometimes you’re left with no other
choice. Occasionally, the installation procedure may require the user to
use the mouse or otherwise perform some complex task that cannot be
easily automated. In these circumstances, automating the installation
process may not be feasible.
For each
application, record the installation method. Does the application
already support automated installation? If so, record the command
required to install the application. Are you required to repackage the
application? If so, record the packaging technology you’ll use and the
command required to install the application.
Subject Matter Experts
In a small organization
with a few applications, you might know them all very well. In a large
organization with thousands of applications, you will know very few of
them well enough to make good decisions about mitigating compatibility
issues or repackaging applications. Therefore, for each application you
must identify a subject matter expert (SME). This SME does not
necessarily have to be an expert with the application, despite the name,
but the SME should have the most experience with it. In other words,
each application’s SME will have insight into how the organization
installs, configures, and uses that application. The SME will know the
application’s history and where to find the application’s source media.
Record the name of each application’s SME in the application inventory.
|
In theory, finding an SME
sounds easy: Here are the applications; here are the people that use
them; and here is the SME for that application. (For some very organized
companies, it’s that easy.) However, for large numbers of enterprise
customers with hundreds and in some cases thousands of applications,
it’s not that simple—finding an SME who will take responsibility for
blessing that the application works is hard work; sometimes the SME you
get isn’t actually an SME at all.
There are two ways around this problem:
Use application help messaging in ACT
Create an application help message by using ACT that displays text and a
link saying that the application has not been SME-approved and allow
users to sign up to test the application. This gives you a nice
disclaimer while asking for assistance. Use two people for two days or five people for five days
Evens SMEs don’t catch everything, and if you don’t have an SME, you
still need someone to test the application. If it’s a small application
or you have a tight timeframe, deploy the application to two people for
two days; if they don’t generate any feedback, deploy to everyone else.
For large applications or larger communities that need the application,
deploy it to five people for five days; if no feedback is generated,
deploy to everyone else.
This process
works remarkably well and keeps the deployment process on track. It
still has user acceptance and interaction, as if you were using an SME,
and still limits the amount of risk. This process is particularly
helpful if the customer does not have an application-compatibility lab
at all.
Doug Davis, Lead Architect
Management Operations & Deployment, Microsoft Consulting Services
|
Configurations
During planning, with the SME’s help, you should review each application and record the following:
The
location of the installation media. Often, the SME is the best source of
information about the location of the source media, such as CDs, disks,
and so on. Settings
that differ from the application’s default settings that are required
to deploy the application in a desired configuration. External
connections. For example, does the application require a connection to a
database, mainframe, website, or other application server? Constraints associated with the application.
|
