Protecting and Restoring Applications

An application profile is used to protect an application. The profile lists the files, registry entries, ActiveX controls (.OCX), self-registered files (.OCX or .DLL), shortcuts, and environment variables that make up a working configuration of the application. Using this information, Diagnostics can take a snapshot of the application on a specific machine, and later use this snapshot to restore the application to working order.

You can automatically generate a profile from a Windows Installer package (.MSI) file, an InstallShield or Wise Installer project, or an existing installation. You can also use Diagnostics Console to manually edit the details of a profile.

Profiling and the Windows Operating System

When you profile an application, it is important that you test the profile on the two main families of the Windows operating systems:

Windows 95, 98, and Me.

Windows NT, 2000, and XP.

Depending on the version of Windows, some setup programs install different files and create different registry entries. Therefore, you may need two profiles, one for each of the main families of Windows.

You may also need separate profiles within a family (for example, separate profiles for Windows XP and 2000).

Building Profiles

Import a Windows Installer package (*.MSI) file

Import the project file for a install package

If you use InstallShield (5.x, 6.x), InstallShield Express, or Wise Installer to develop install programs for your applications, you can import the project files. You can also import Visual Basic projects.

Generate the profile from an application installation

when an application doesn’t use Windows Installer and you don’t have the source files for the setup, you can use an existing installation of the application.

Build the profile manually

This method is ideal for building profiles for collecting configuration information for performing system change analysis. For example, to troubleshoot problems with hardware components such as printers and video cards that have associated software.

For applications, building profiles manually requires considerable, detailed knowledge of the application.

Auto-profiling Applications

Specifying What to Include

The Files, Registry Entries, Self-registered files (for example, OCXs), and Shortcuts check boxes control what items are included in the generated profile.

Filtering Out Files and Registry Keys

As a general guideline, a profile should not exceed 1 megabyte in size. To control the size of a profile, use:

File extensions to ignore to specify which files you do not want to include in the profile.

Registry keys to ignore to specify which registry keys (for example, HKEY_CLASSES_ROOT) you do not want to include in the profile.

Filters are specified as a comma-separated list. You can include one or more spaces between commas to make the list more readable.

Copying Files

When you generate a profile automatically, you can generate a list of files (ASCII or binary) to retrieve from the remote PC. For example, you can retrieve .INI and other configuration files from a user’s PC.

The File extensions to process as Copy Files box is a comma-separated list of file extensions. When the profile is generated, all files with these extensions are added to the list of files to copy.

While copied files are not used to protect an application, they can be useful for performing change analysis.

If the install path is found in the registry, Auto Profile creates a variable for the application install directory.

Importing Windows Installer (MSI) Packages

Microsoft Windows Installer is a component of the Windows operating system that manages the installation and removal of applications. A package (.MSI) file stores information regarding the application setup and installations and is distributed to end users.

Generating a profile from an MSI file is more reliable than reverse engineering an existing installation of the application. Whenever an application uses Windows Installer, you should use its MSI file to create its profile.

To import an MSI package:

In the console tree, right-click Profiles, click New, and then click Profile.

This creates a public profile (a profile that is available to all users running a Diagnostics Console). To create a private profile, expand Profiles, right-click Private, click New, and then click Profile.

In the profile tree, click Auto Profile.

Click MSI. Diagnostics displays a list of the MSI packages found on your system (in the Installer subfolder of your Windows System folder, for example, C:\WinNT\Installer).

If you don’t see the package you want, click Browse to locate it.

MSI files typically have unfriendly names such as 4499fdf.MSI. To find the MSI file you want, point to the file until the tooltip appears, or add the Title column to the Details view of the dialog (right click a column header, click More, and select the Title check box.

Click a package and click OK.

Select the features you want to import into the profile and click Ok.

If necessary, set the advanced MSI import options:

To import ActiveX controls from the MSI package, Diagnostics needs to scan HKEY_CLASSES_ROOT.

To ignore files, OCXs, registry entries, and shortcuts that are listed in the MSI package but not found on the local computer, select the Import items only if found on this computer check box.

If necessary, type the correct installation folder or click

to locate the installation folder.

To ignore components based on the install conditions specified in the .msi file, type the install conditions in the Install conditions to ignore box. Use a semi-colon to separate each install condition.

Avoid building large profiles, which slow down auditing, protecting, and change analysis.

Selecting features allows you to build smaller profiles. For example, the top-level features of Microsoft Office are Word, Excel, Power Point, and so on. By selecting features, you can create separate profiles for each Office program instead of one large monolithic profile for all of Microsoft Office.

For each top-level feature, you may also want to create profiles with and without optional features that some users may not install. For example, you may want a profile for an installation of Microsoft Word without the spell checker, so that all the profile items related to the spell checker won’t be protected and identified as problems.

For complicated MSI packages, you may need to select shared components as well as the application. For example, to build a profile for Microsoft Outlook, you may need to select shared Office Tools components such as the Spell Checker. Otherwise you won’t be able to diagnose spell checker-related problems with Outlook.

When you import an MSI file, the self-registered DLLs are not listed in the ActiveX Controls section of the profile. Instead, the Registry section includes all the registry entries required by the DLLs.

MSI Files and Self-Registered DLLs

When you import an MSI file, the self-registered DLLs are not listed in the ActiveX Controls section of the profile. Instead, the Registry section includes all the registry entries required by the DLLs.

Importing Install Packages

If you have the source for an install package, you can use it to build a profile. Diagnostics can automatically import items from the following common install packages:

To import an install package:

Install Package	What you can import
InstallShield 5.x, 6.x InstallShield 5.x, 6.x Log File Wise Installer	Files Self-registered files Registry keys Shortcuts
InstallShield Express	Files Self-registered files Registry keys
Visual Basic Project (vbp)	Files Self-registered files

In the console tree, right-click Profiles, click New, and then click Profile.

In the profile tree, click Auto Profile.

Click Package.

In the Files of type box, select the type of install package you want to import.

Click an install package and click OK.

To import an InstallShield 5.x log file:

Load the log (ISU) file in the InstallShield 5.x log file viewer.

Save it as a text file. Diagnostics Console can read only the text version of the log file.

Installed Applications

Diagnostics can generate a profile from an existing installation of an application. After you select an installed application, Diagnostics scans your system for information about the application (such as files, registry entries, and shortcuts), starts the application to determine what ActiveX controls it uses, and then generates the profile.

To auto-profile an installed application:

In the console tree, right-click Profiles, click New, and then click Profile.

In the profile tree, click Auto Profile.

Click Application. Diagnostics displays a list of applications found on the local PC.

If you do not see the application you want to profile in the Installed Applications dialog, click Browse and locate the application executable on your computer.

Click an application and click OK.

ActiveX Controls

Diagnostics can determine only the ActiveX controls loaded at startup. ActiveX controls loaded on demand by the application are not included in the generated profile. If you are familiar with the application, you can manually add the missing ActiveX controls.

Too Many Files?

If the generated list of files is too large, add some file extensions to the File extensions to ignore filter and generate a new profile.

Files with No Path

If a file is listed with no path, it was probably found somewhere on your hard disk outside of the application installation directory and the standard Windows directories (for example, c:\temp). Generally, you can remove such files from the profile.

After You Auto Profile

Because not all applications follow standard rules for installations, profiles for installed applications may not be complete. Visually inspect the profile and verify that the files, registry entries, shortcuts, and so on make sense.

If the profile includes keys or values under HKEY_CURRENT_USER, the user must be logged on when you audit, protect, or repair the user’s computer. Otherwise, if no one is logged on, the current user will be the default user and the audited values will not reflect the user’s environment.

Make sure all paths to files and shortcuts use variables.

If the application depends on environment variables, you must add them by hand.

Check the Product attributes.

Collecting Information for Change Analysis

If you cannot restore a protected application to working order using automated repairs, you may need to perform a change analysis. Diagnostics can quickly identify changes in system and application configuration that may be the cause of the problem.

For example, you can easily collect configuration information on the operating system, system resources such as services, running applications, and memory, and hardware components. For details, see Collecting Information.

Protecting Applications

Protecting an application on a computer creates an audit and a snapshot. The audit represents the configuration of the application on a specific computer at a specific point in time. For example, the audit specifies the location and version of each file listed in the profile, the values of the registry entries, along with information on any ActiveX controls and shortcuts.

The snapshot is an archive of the files and ActiveX controls at that point in time, and is used to restore the application to a working configuration when a problem occurs.

An Audit and a Snapshot

To protect an application on a single PC:

In the console tree, expand the Entire Network and locate the computer.

Right-click the computer and click Protect.

In the Console dialog, double-click an application.

After the application is protected, an audit and a snapshot are added under the computer in the console tree. You can now view the audit details.

While Diagnostics protects the computer, you can perform other tasks in the Diagnostics Console. For example, you can protect the application on other computers.

If the protect request seems to be taking a long time to finish, check the Requests. If the request is listed there, it means that the Diagnostics Agent running on the target computer never picked up the request.

You can schedule jobs to protect applications at a more convenient time. See Scheduling Jobs for more information.

To batch-protect applications on the network:

On the Action menu, click New and then click Job.

In the box beside the task icon

, type a name for the job.

In the Command list, click Protect.

In the Select Machines box, select the Microsoft Windows Network check box. Or select the check box for one or more domains.

In the Select Products box, select the check boxes for the products you want to protect.

In the Job view toolbar, click

to save the job.

In the Job view toolbar, click

to run the job.

Restoring Applications to Working Order

When a user reports a problem with a protected application, you can automatically diagnose the problem and fix the application. All you have to do is use the application profile to audit the user’s computer. If any problems are detected during the audit, you can fix them by clicking a button.