Stabilizing
During the Stabilizing and Deploying Phases of the computer deployment project, the Application Management feature team focuses on quickly resolving any issues found in the customized installations.
Figure 20 shows the activities during the Stabilizing Phase.
.gif)
Figure 20. Activities during the Stabilizing Phase
.gif)
On This Page
.gif){kind=icon}
Roles and Responsibilities
Testing Deployed Applications
Milestone: Deployment Readiness Reviewed
Roles and Responsibilities
All six role clusters from the MSF Team Model play a role in this phase of the project. The Plan, Build, and Deploy Guide lists the roles and defines the focus areas for each role cluster. Table 14 defines these focus areas for the different role clusters for this project phase. For more information about MSF Role Clusters, see Microsoft Solutions Framework at https://www.microsoft.com/technet/itsolutions/msf/default.mspx.
Table 14. Roles and Responsibilities During the Stabilizing Phase
Role cluster |
Focus |
|---|---|
Product Management |
|
Program Management |
|
Development |
|
User Experience |
|
Test |
|
Release Management |
|
Testing Deployed Applications
One of the first steps in the Stabilizing phase is to test the deployment of the different packages created in the Developing phase. Testing will ensure that the core and supplemental applications can be deployed and will work correctly after deployment. Since core and supplemental applications depend on the operating system image deployment, testing of these packages has to be synchronized with the testing of the operating system image. For more information on testing deployed images, read the section titled “Performing Lab Tests and Pilot Deployment” in the Deployment Feature Team Guide.
Perform two types of testing to simplify isolating and troubleshooting compatibility problems:
Unit testing. Test specific features of an application on a clean computer to verify that the supplemental application functions in an ideal environment.
Integration testing. Test specific features of multiple applications on a computer that contains a more complex array of applications to more closely resemble production computers.
As Application Management feature team members conduct tests, they should evaluate and record the results. If testing reveals problems, first make sure they are compatibility problems rather than problems with the test environment or an existing application. Before you assume the problem is a Windows compatibility issue, always complete the following two steps:
Verify that the problem is not a test-environment issue. The problem might be the result of a hardware, software, or network-configuration issue rather than an application-compatibility problem.
Verify that the problem does not occur on the version of Windows currently in use. Perform exactly the same test on the version of Windows on which the application currently runs to see whether it works correctly there. If the same error occurs on the current platform, it is not a compatibility issue.
The testing process is an iterative process of testing, identifying problems, resolving problems, and retesting. The steps in the process vary depending on the nature of problems encountered and the nature of the resolution. Problems that are resolved by applying an application-compatibility fix, for example, are managed differently from problems resolved by modifying source code or obtaining vendor upgrades.
For problems that can be resolved by applying an application-compatibility fix, build a Resolution Phase into the Testing Phase. This means that, as Application Management feature team members encounters problems, they apply application-compatibility fixes and retest until the application is ready to deploy. If team members modify source code, the iterative process is the more traditional cycle of testing, debugging, coding and recompiling, and retesting. If an Application Management feature team member cannot identify an application-compatibility fix to resolve the problem and does not have access to source code, the team member can contact the application vendor for an application upgrade.
Figure 21 illustrates the testing process.
.gif)
Figure 21. The application testing process
Issue identification and tracking resolution are key to having a successful testing cycle. Resolving the issues is important, and adding these issues to a searchable knowledge base will greatly assist the User Experience Role Cluster when it is time to train help desk staff. Being able to demonstrate not only the issue and the resolution but also the troubleshooting process performed to correct the issue is invaluable. In addition, it is better to pass this knowledge on to others and encourage them be a part of the process rather than concentrating this knowledge in a few people.
This deployment of supplemental applications is just a small part of a project whose reach affects every person within and outside an organization. A good user experience gains acceptance and use, whereas a bad experience might damage not only the current project but future projects as well.
Applications can often have incompatibilities with other applications, particularly if the application is repackaged. Test for potential incompatibilities in any of three ways:
Manually test the deployment in a lab environment. Create a lab environment that has a variety of computers from your organization. The more closely these computers resemble actual client computers, the more reliable the testing. Ideally, Application Management feature team members will use clones of actual client computers for testing. Because different types of users may have different applications installed, it is imperative that team members test application deployment on a variety of client computers.
Test with non-Microsoft tools. AdminStudio Professional Edition and Wise Package Studio include the ability to simulate the deployment of a package and report back any problems, detect and resolve potential application conflicts, and perform Quality Assurance (QA) testing on applications after installation on target computers.
Test during a staged deployment. After Application Management feature team members have tested application deployment in a lab environment, they can test it on production computers by launching a limited, staged deployment. The deployment should install applications on a very few computers until the team is comfortable that the new package has no negative impact.
Troubleshooting Strategies
When troubleshooting software-installation issues, observe and identify the problems’ symptoms. Try to learn more about the circumstances under which problems occur and become familiar with system behavior when issues arise. Use the tools that Windows Server 2003 provides to troubleshoot software installation–related issues.
The strategies discussed in the following sections generally apply to Windows Installer packages. InstallShield-based Setup troubleshooting is discussed in “InstallShield Troubleshooting” earlier in this guide. For information about general troubleshooting strategies, see “Troubleshooting Concepts and Strategies” in the Microsoft Windows Server 2003 Resource Kit. Links to the resource kits can be found in the “Education and References” section later in this guide.
Validating Packages
Microsoft recommends validating every new or newly modified package before attempting to install it the first time. The Application Management feature team can use most Windows Installer authoring tools to perform package validation. For example, to validate your packages by using Orca, included with the Windows Installer software development kit (SDK), from the Tools menu, click Validate.
Most Windows Installer authoring tools use Internal Consistency Evaluators (ICEs) to perform package validation. ICEs are custom actions written in VBScript, Microsoft JScript®, or as a .dll or .exe file. When run, an ICE scans the package’s database to identify entries that are valid individually but that might cause incorrect behavior in the context of the entire database.
ICE custom actions return four kinds of messages:
Informational. Informational messages provide information from the ICE and do not indicate a problem with the database. Often, the information is about the ICE itself, such as a brief description. These messages can also provide progress information while the ICE runs.
Warnings. Warnings report database authoring that causes incorrect behavior in certain cases. Warnings can also report unexpected side effects of database authoring (for example, entering two separate conditions of the same property name spelled the same but with an uppercase/lowercase difference—such as High and high). Because Windows Installer is case sensitive, it treats these as two different properties.
Errors. Errors report database authoring that causes incorrect behavior. For example, duplicate component globally unique identifiers (GUIDs) cause Windows Installer to incorrectly register components.
Failures. Failures report the failure of the ICE custom action. Failures are commonly caused by a database with such severe problems that the ICE cannot run.
Event Logging
Event logging in Windows XP Professional and Windows Vista provides a standard, centralized way for applications and the operating system to record important software and hardware events. The event-logging service stores events from various sources in a single collection called an event log.
Windows Installer also writes entries into the event log, which records events such as:
Success or failure of the installation, removal, or repair of a product.
Errors that occur during product configuration.
Detection of corrupted configuration data.
Information about the missing components that cause an application to repaired.
If a large amount of information is written, the event-log file can become full. When this happens, Windows Installer displays the message, “The Application log file is full.”
Internal Logging
Windows Installer records errors and events in its own internal error log (Filename.log) and in the event log. The diagnostic information Windows Installer writes to these log files can help Application Management feature team members and users understand why an installation fails.
The type of logging that Windows Installer performs is determined when the logging mode is set. The Application Management feature team can use various means to enable the logging mode, such as:
The /L command-line option of Msiexec.exe
The registry
Using the /L command-line option of Msiexec.exe, Application Management feature team members can specify exactly what gets logged and where. Table 15 describes the arguments for logging when the /L command-line option is used.
Table 15. Arguments for Logging Using the /L Command-Line Option
Argument |
Effect |
|---|---|
I |
Status messages |
W |
Nonfatal warnings |
E |
All error messages |
A |
Startup of actions |
R |
Action-specific records |
U |
User requests |
C |
Initial UI arguments |
M |
Out-of-memory or fatal exit information |
O |
Out-of-disk-space messages |
P |
Terminal properties |
V |
Verbose output |
+ |
Append to existing file |
! |
Flush each line to the log |
* |
Log all information except for the V option; to include the V option, specify /L*V |
To create a normal log file for a command-line installation, append /L* LOGFILE.NAME to the Msiexec Command Prompt window. Doing so generates a normal log file with all arguments selected except for those marked with the V command-line option. For a verbose log, which contains much more detailed information, append /L*V LOGFILE.NAME to the Msiexec Command Prompt window, instead. The following syntax is an example of a normal log command:
Msiexec /i Testdbsetup.msi /l* msi.log
The following syntax is an example of a verbose log command:
Msiexec /i Testdbsetup.msi /l*v Msi.log
The following syntax enables verbose logging during an installation without any UI. The log file is Program.log and resides in the root of drive C:
msiexec /qn /l*v c:\program.log /i \\server\share\setup.msi
If the logging capability remains on at all times or if an installation is logged that is not run from the command line, such as an on-demand or self-repair installation, set the REG_SZ registry value Logging to icewarmup under the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer. To create a verbose log, set the registry value to icewarmupv.
Application Management feature team members should use this policy only if they have not enabled logging through the /L command-line option. If Group Policy is set in this case, a log file is created in the Temp directory with the following random name: .msi*.x.LOG.
Reading a Log File
Suppose the following command is used to launch an installation:
msiexec.exe /I <path>\myapplication.msi /Lpiwaeo logfile.log
Table 16 lists the logging arguments used in the preceding command.
Table 16. Log-File Arguments
Argument |
Effect |
|---|---|
p |
Terminal properties |
i |
Status messages |
w |
Nonfatal warnings |
a |
Startup of actions |
e |
All error messages |
o |
Out-of-disk-space messages |
By default, the Windows Installer does not use verbose logging. However, Application Management feature team members can instruct it to use verbose logging by using a command-line entry such as:
<path>\setup.exe /L*v c:\logfile.log
or
msiexec.exe /I <path>\myapplication.msi /Lpiwaeo logfile.log
When actions are completed successfully, a return value of 1 (one) appears for the action. For example, the following excerpt is from a non-verbose log:
=== Logging started: 5/17/06 13:55:41 === Action start 13:55:41: INSTALL. Action start 13:55:41: CheckOSandSPAction. Action ended 13:55:41: CheckOSandSPAction. Return value 1.
Return values are also specified in verbose logs along with more details.The following excerpt from a verbose log corresponds to the same actions as the preceding example:
Note Some parts of the following code snippet have been displayed in multiple lines only for better readability. These should be entered in a single line.
Action start 11:28:42: INSTALL. MSI (c) (D6:6E): UI Sequence table 'InstallUISequence' is present and populated. MSI (c) (D6:6E): Running UISequence. MSI (c) (D6:6E): Skipping action: ResumeInstall (condition is false). MSI (c) (D6:6E): Doing action: CheckOSandSPAction. Action start 11:28:42: CheckOSandSPAction. MSI (c) (D6:6E): Creating MSIHANDLE (1) of type 790542 for thread 110. Action ended 11:28:42: CheckOSandSPAction. Return value 1.
When an action cannot be completed until the next computer restart, a return value of 4 typically appears—for example:
Note Some parts of the following code snippet have been displayed in multiple lines only for better readability. These should be entered in a single line.
Action 14:18:30: InstallMMCExe. Action 14:18:33: ForceReboot. Action ended 14:18:33: ForceReboot. Return value 4. Info 1101. Error reading from file: ScriptsDisabled. System error 2. Verify that the file exists and that you can access it. Action 14:18:35: RollbackCleanup. Removing backup files. Action ended 14:18:37: INSTALL. Return value 4. Action ended 14:18:38: ExecuteAction. Return value 4. Action ended 14:18:38: INSTALL. Return value 4.
Table 17 lists possible return values.
Table 17. Possible Return Values
Value |
Description |
|---|---|
0 |
Action not invoked; most likely does not exist |
1 |
Completed actions successfully |
2 |
User terminated the action prematurely |
3 |
Unrecoverable error occurred |
4 |
Sequence suspended, to be resumed later |
Strategies for Troubleshooting
If the Application Management feature team uses a UI for software installation and the installation fails, an error message identifies the cause. If verbose logging is enabled, team members might find additional information about the error in the log. The log file can help determine the cause of the problem.
If an error is an internal error, documentation about the specific error code is available in the Windows Installer SDK. Typically, internal errors result from a problem with the package or with the Windows Installer service.
Error Messages
Start by searching for the word error in the Windows Installer log file. If a number follows the word error, the meaning of the error message appears in the “Microsoft Windows Installer Error Messages” topic in the Msi.chm help file included with the Windows Installer SDK. In the log file, use the error number to determine in which section the error occurs, such as a registry write or a file copy.
Because Windows Installer does not display all error messages and some messages do not appear in the logs, Application Management feature team members might need to use an alternative tactic to locate the problem. Unusual breaks in time stamps in the log statements, for example, might help determine the cause of the problem. These breaks would imply a network or hardware delay.
Remember that a verbose log provides more details, such as why a particular file was or was not copied—for example:
Note Some parts of the following code snippet have been displayed in multiple lines only for better readability. These should be entered in a single line.
MSI (s) (8B:82): Executing op: SetTargetFolder(Folder=D:\WINNT\inf\) MSI (s) (8B:82): Executing op: SetSourceFolder(Folder=G:\Windows\inf\) MSI (s) (8B:82): Executing op: FileCopy(SourceName=agtinst.inf,DestName=agtinst.inf, Attributes=8192,FileSize=7766,,,InstallMode=25427968, PerTick=32768,IsCompressed=0,,VerifyMedia=1,,) MSI (s) (8B:82): File: D:\WINNT\inf\agtinst.inf; Overwrite; Existing file is unversioned and unmodified
Rollbacks
Because Windows Installer Setups are transaction based, a rollback occurs if Setup is incomplete. Search for the string rollback in the Setup log. Ignore the line that says removing rollback files; rollback files are removed at the end of a successful Setup.
The following excerpt is from a log for an incomplete installation:
Note Some parts of the following code snippet have been displayed in multiple lines only for better readability. These should be entered in a single line.
1: exsec32.dll 2: C:\Program Files\Common Files\System\Mapi\1033\ Internal Error 2925. C:\Program Files\Common Files\System\Mapi\1033\exsec32.dll, -2147024865 Action ended 12:25:04: InstallFinalize. Return value 3. Action 12:25:08: Rollback. Rolling back action: Rollback:
Apparently, the rollback is occurring as a result of the error with the Exsec32.dll file. Find the error number (Internal Error 2925) in the “Microsoft Windows Installer Error Messages” topic in the Msi.chm help file, which is included with the Windows Installer SDK.
Computer Restarts
Unless computer restarts are intentionally suppressed, initial installations might require a computer restart. Make sure that the installation continues after the computer restarts.
Action start 16:47:38: ForceReboot. Action 16:47:38: GenerateScript. Generating script operations for action: Action 16:47:38: ForceReboot. Action ended 16:47:38: ForceReboot. Return value 4.
Milestone: Deployment Readiness Reviewed
Milestones are synchronization points for the overall solution. For more information, see the Plan, Build, and Deploy Guide.
This milestone, shown in Table 18, represents the successful review of the deployment environment and test results and has the following deliverables, which are the same as those for the previous milestone.
Table 18. Deliverables for Deployment Readiness Review Milestone
Deliverable ID |
Description |
|---|---|
Deployment Environment |
Deployment, data, and application servers are available on the production network and ready for deployments. |
Test Report |
Results of the testing process are documented. |
Download
Get the Microsoft Solution Accelerator for Business Desktop Deployment 2007
Update Notifications
Sign up to learn about updates and new releases
Feedback