Windows Vista : Deploying Applications - Planning Deployment

- How To Install Windows Server 2012 On VirtualBox
- How To Bypass Torrent Connection Blocking By Your ISP
- How To Install Actual Facebook App On Kindle Fire
9/19/2012 12:35:30 AM

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.

Figure 1. Prioritizing an application inventory in ACT 5.0.


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.


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.

Direct from the Source: No SME?

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


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.

  •  Windows Server 2003 : Active Directory - Understanding Directory Replication (part 3) - Spanning Trees and Site Links
  •  Windows Server 2003 : Active Directory - Understanding Directory Replication (part 2) - Update Sequence Numbers
  •  Windows Server 2003 : Active Directory - Understanding Directory Replication (part 1) - Time Synchronization, Replication Topologies, Handling Update Conflicts
  •  Windows Server 2003 : Active Directory - Understanding Operations Master Roles
  •  Windows Vista : Customizing Windows PE Boot Images (part 3) - Working with OSCDImg, Working with vLite
  •  Windows Vista : Customizing Windows PE Boot Images (part 2) - Working with an ImageX GUI, Working with PEImg
  •  Windows Vista : Customizing Windows PE Boot Images (part 1) - Working with ImageX
  •  How To Buy Graphics Cards!
  •  Windows 7 : Protecting Your Data from Loss and Theft - Creating a File and Folder Backup
  •  Windows 7 : Protecting Your Data from Loss and Theft - The All New Backup and Restore